系统内的 AI 智能体：哪些事智能体可以独自完成，哪些必须由人批准，以及如何在不失控的前提下起步

AI 智能体是一种语言模型，它可以请求你的软件运行函数，也就是执行查询一笔付款、更新一张工单或发起一笔退款这类操作。模型只负责提出请求。是否执行由你的系统决定，你的控制权正握在这里。从一项范围很窄的任务开始，让智能体自己读取数据、准备草稿。凡是涉及资金划转、修改客户记录或发往公司外部的内容，都由一位指定的人批准。

用通俗的话说，什么是 AI 智能体？

语言模型，也就是 ChatGPT 背后的那类 AI，产出的是文本。智能体则是连接到你系统中各项函数的语言模型，所以它的输出既可以是一个回答，也可以是一个操作。

Anthropic 为其 Claude 模型编写的文档写道：“工具使用（也称为函数调用）让 Claude 能够调用由你定义或由 Anthropic 提供的函数。”对于你定义的函数，模型会“返回一个由你的应用程序执行的结构化调用”。模型写出请求，由你的软件执行或拒绝。本文所有来源均于 2026 年 11 月 2 日查阅。

智能体会循环重复这一过程。它调用一个函数，读取结果，再选择下一步，直到任务完成。Anthropic 工程博客 2024 年的一篇文章把智能体描述为“通常只是在循环中根据环境反馈使用工具的 LLM。”LLM 是大语言模型（large language model）的缩写，工具就是它可以调用的函数。

所以，智能体只能做它的函数所允许的事。函数清单就是它的岗位职责说明，也是你首先要索取的文件。

智能体是读取数据还是修改数据，为什么这很重要？

因为读取不会改变任何东西。如果智能体调取客户最近五笔付款时弄错了一笔，结果只是一份有错的草稿，而人可以发现它。

写入会改变模型之外的东西：一笔退款付了出去，或者一封邮件到了客户手里。其中有些改变是无法撤销的。

OpenAI 关于构建智能体的指南建议，“根据只读还是写入权限、可逆性、所需的账户权限以及财务影响等因素”，把每个函数评为低、中或高风险。只有当智能体无法把读到的内容发送到任何地方时，读取才算低风险。关于提示词注入（一种把指令藏进邮件或文档的手法）的那一节说明了原因。

哪些操作智能体可以独自完成，哪些需要人参与？

把每个函数归入以下三组之一：

• 智能体独自完成：读取数据、搜索文档、打标签，以及撰写草稿，这些草稿在有人使用之前一直留在你的系统里
• 智能体提议，由人批准：任何涉及资金划转、修改客户记录或状态，或向公司外部发送消息的操作
• 绝不交给智能体：修改访问权限、限额或银行账户信息，以及监管机构要求由指定人员作出的决定

对大多数函数来说，以下四个问题决定它属于哪一组：

• 这个操作能否撤销，由谁来撤销？
• 它是否会划转资金，或改变客户应付的金额？
• 客户、合作伙伴或监管机构会看到结果吗？
• 法律、牌照条件或你自己的政策是否规定必须由人来决定？

OpenAI 的指南对中间那一组给出了同样的建议：“敏感、不可逆或利害重大的操作应当触发人工监督，直到对智能体可靠性的信心增强为止。”它举的例子包括“取消用户订单、批准大额退款或进行付款。”

OWASP Top 10 for LLM Applications 2025 是 OWASP 安全项目发布的一份风险清单，其中有一项叫作过度代理（excessive agency）。它讲的是，当智能体拥有的函数、权限或自由度超出任务所需时可能造成的损害。它列出的控制措施之一是“要求在执行高影响操作之前由人批准。”

这在客服、开户、支付和报告中是什么样子？

在每个领域里，智能体负责读取和起草，决定权留在人手里。你自己的清单取决于你的系统，以及你的监管机构的期望。

• 客服：智能体给工单打标签并起草回复。起初每一条回复都由人批准，退款和费用减免则始终需要批准。智能体绝不修改客户的邮箱或电话号码，因为谁掌握了它们，谁就能重置客户的登录
• 开户：智能体检查文件中是否有缺失字段，并为分析师整理摘要。风险评级的变更要等待批准，是否接纳客户则始终由人决定
• 支付：智能体把银行对账单的各行与发票逐一匹配，并标出对不上的地方。放行一笔被暂扣的付款要等待批准，而收款人的银行账户信息永远不由智能体修改
• 报告：智能体起草月度报告，并注明每个数字的来源。凡是发给客户、董事会或监管机构的内容，都由人批准

审批这一步应该放在哪里？

把审批放在运行函数的软件里，而不只是写在提示词里（提示词就是模型收到的那组指令）。模型可能忽略提示词中的某一句，也可能被人说服而不再遵守。一个没有批准人点击就不会运行的退款函数，则不会被任何话说服。

OWASP 的指导意见也是如此：“在下游系统中实施授权，而不是依赖 LLM 来判断某个操作是否被允许。”

一个好用的审批界面会向批准人展示：

• 操作内容、它要修改的记录以及金额
• 修改前后的记录
• 智能体所依据的证据，比如工单或对账单上的那一行
• 批准人每次驳回时都必须填写理由

如果每条提议都在几秒钟内获批，说明大家已经不再检查了。EU AI Act 给这种现象起了个名字：自动化偏差。其关于人工监督的条款规定，监督高风险系统的人必须能够始终意识到“自动依赖或过度依赖输出的可能倾向”。每周抽查一批已批准的操作，重新核对。

智能体的账户应该有哪些权限？

智能体的账户应当只允许其清单上的函数，别无其他。在它接触的每个系统里，都给每个智能体开一个专属账户，绝不使用管理员账户或某位员工的登录。把这些权限设置在系统本身，让模型无法更改。密码和密钥留在你的软件里，不让模型看到。

OWASP 举的例子是一个推荐商品的智能体，它“可能只需要对‘products’表的读取权限”。OWASP 还提醒不要使用开放式的函数，比如在服务器上运行任意命令，而是倾向于使用每个只做一件事的窄范围函数。

当智能体为某一位员工工作时，用 OWASP 的话说，它应当“在该特定用户的上下文中、以所需的最低权限”行事。这样它能看到和能做的就不会超出那个人。

什么是提示词注入，为什么它对智能体的影响更大？

提示词注入是指把指令藏进智能体会读取的文本里，比如一封邮件、一张工单或一份上传的文档。模型可能会照着这些指令去做，就像它们来自你一样。这些指令可以对人类读者隐藏，而一旦涉及智能体，它们就可能变成实际操作。OWASP 在其 2025 年的清单中把提示词注入列在第一位，并表示“目前尚不清楚是否存在万无一失的提示词注入防范方法。”

OWASP 关于过度代理的条目描述了这样一个助手：它读取邮箱，为收到的邮件生成摘要。它所用的插件也能发送邮件。一封精心构造的邮件骗它在收件箱里搜索敏感信息，并把这些信息转发给攻击者。

OWASP 给出的修复办法，首先是只能读邮件的函数和对邮箱的只读权限。此外，必须有人“手动审阅 LLM 扩展起草的每一封邮件，并亲自点击‘发送’。”既然无法排除提示词注入，就要为智能体已经被骗的情况做好准备，并把它可能造成的损害控制在小范围内。

我们应该记录什么，出了错又如何撤销？

记录每一次函数调用。每条记录写明：哪个智能体、哪个函数及其输入、结果、引发这次调用的文本、模型和提示词版本，以及由谁、在何时批准。开发团队以外的人应当能够读懂日志，并说清某位客户身上发生了什么。

OWASP 指出，日志记录和速率限制无法防止过度代理，“但可以限制所造成损害的程度”。速率限制规定智能体在一定时间内最多能执行多少次同类操作，这样一连串错误操作就能早早停下来。

上线之前，写清每个会修改数据的函数要如何撤销，以及由谁来撤销。优先选择那些只生成待处理事项的函数，比如在队列中等待处理的退款。待处理事项可以删除，而已经发出的付款很难追回。保留一个开关，无需发布新版本软件就能立即关闭智能体的全部函数，并在上线前测试这个开关。

法律是否规定必须由人批准？

在欧盟，AI Act 对其列为高风险的 AI 系统规定了人工监督规则。这些规则在第 14 条，附件 III 则列出了高风险用途。清单中包括评估个人的信用状况或确定其信用评分，但用于检测金融欺诈的系统除外。清单中还包括人寿和健康保险中针对个人的风险评估和定价。欧盟委员会的 AI Act Service Desk（AI 法案服务台）给出的日期是：附件 III 所列高风险系统的规则自 2027 年 12 月 2 日起适用。这个日期反映了 Digital Omnibus on AI（关于 AI 的数字综合法案）所作的修改。这类日期可能变动，所以在据此做计划之前，请先核实当前的时间表。

第 14 条规定，就系统而言，监督措施“应当与风险、自主程度和使用情境相称”。负责监督的人必须能够“在任何特定情况下决定不使用该高风险 AI 系统，或以其他方式忽略、推翻或撤销其输出”。他们还必须能够通过“‘停止’按钮或类似程序”让系统停下来。

这些规则只适用于该法案所列的高风险系统，客服和运营中的许多智能体都不在其列。不过，同样的控制措施对这些智能体仍然有意义。你的系统是否受这些规则约束，是你的律师要回答的问题。本文不构成法律意见，只涉及欧盟规则。

如何在不失控的前提下起步？

先问一问：这项任务到底需不需要智能体。Anthropic 的工程文章建议“寻找尽可能简单的解决方案，只在必要时才增加复杂度”，并补充说：“这可能意味着根本不去构建智能体系统。”对许多任务来说，向模型发一次请求，或者走一套固定的步骤，就足以完成。固定的步骤也比自行选择步骤的智能体表现得更可预测。

挑一个每周案例量大、规则清晰、出错后修正成本低的工作流程，比如客服工单分类和起草回复。然后分阶段推进：

• 衡量这个工作流程目前的运行情况：每个案例的耗时、需要返工的案例比例，以及每周的积压量
• 让智能体在真实案例上以影子模式运行。它提出建议，员工照常工作，然后你比较两者的结果
• 切换到审批模式，由人批准每一个操作，并记录批准人修改或驳回的频率
• 只在被修正次数最少的那几类操作上让智能体独自行动，并继续每周抽样检查

事先约定哪些数字达标后智能体才能进入下一阶段，以及由谁来决定。OpenAI 的指南最后写道：“从小处着手，用真实用户验证，再逐步扩展能力。”Anthropic 的文章建议“在沙箱环境中进行大量测试”，也就是在你系统的一份副本里测试，在那里犯错不会造成任何损失。

智能体上线之前，我们应该核查什么？

• 每个函数都归入三个组别之一，并在你这一方有一位指定的负责人
• 有人在每个系统中用智能体的账户尝试过被禁止的操作，并确认操作失败
• 夹带了隐藏指令的工单和文档都让智能体处理过，结果没有发生任何超出分组许可范围的事
• 对任何一位客户，日志都能显示智能体做了什么、由谁批准
• 新的模型版本只有在同一套测试重新跑过之后才能上线

代码、提示词和日志归谁所有？

应当归你的公司所有，而且合同里应当写明。代码只是智能体的一部分。提示词、函数清单、审批规则和测试用例决定了它的行为方式。把它们全部列为交付物，并存放在你公司掌控的存储上。

日志中含有客户数据，所以日志需要与它们所描述的记录相同的访问规则和保存期限。如果模型运行在外部服务商那里，要问清这家服务商是否会存储智能体发给它的内容，以及存多久。

我们应该向负责开发的公司问些什么？

• 我们能否看到智能体将要调用的每一个函数，以及每个函数所属的组别？
• 审批在哪里强制执行：在我们的系统里、在你们的代码里，还是只在提示词里？
• 智能体在每个系统中使用哪个账户，你们如何测试过它无法越权？
• 你们如何测试提示词注入，如果某次测试中注入成功了，会怎么处理？
• 我们的合规团队能否在没有你们帮助的情况下读懂日志？
• 每个操作如何撤销，我们能多快把智能体关掉？
• 最后我们拥有什么：代码、提示词、函数定义、测试用例和日志？

amBrain 在其中处于什么位置？

amBrain 在自己的产品中使用智能体。它对这款产品的描述是：“我们自己的产品 shyash.ai 由研究、撰写、检查和衡量的 AI 智能体运行，依托同一份公司事实的共享记忆。所有发出的内容都由人批准。”

amBrain 公开描述的唯一一个涉及语言模型的客户项目是：“我们已在一家客户的金融科技边界之内，将一项 LLM 集成投入生产：把非结构化的经纪商与交易场所通知——公司行动、金融工具与保证金变更——抽取并规范化为交易系统所消费的结构化记录。”

本文不是案例研究，除上面那句话之外，不描述任何客户项目。那句话没有提到智能体或审批，本文也并未声称 amBrain 为客户构建智能体系统。文中来自客服、开户、支付和报告的例子是一般性的，并非取自 amBrain 的工作。

本文提到的公司和组织均引自它们公开发布的页面。本文并不声称 amBrain 与它们中的任何一方有任何关系，也不给出 amBrain 的任何价格或工期。

amBrain 自 2019 年起开发软件。它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”上面这些问题适用于你考虑的任何一家公司。