企业真的需要 AI Agent 吗：何时应让模型决定下一步
目录
核心速览（TL;DR）
多数企业任务并不需要 Agent。只有当处理路径难以预先写死、每一步都有可用反馈、错误造成的影响能够控制在一定范围内，而且收益足以覆盖新增成本时，企业才值得把“根据情况决定下一步做什么”的权力交给模型。即使值得采用，安全落地也不能只靠一句“请谨慎”，而要用硬性规则给它戴上紧箍咒，圈出明确的行动边界：
- 管住权限：不能让 Agent 拥有超级特权。员工本人能做什么、当前任务允许做什么、工具接口放行什么，Agent 才能做什么；能连上系统，不代表可以直接修改数据。
- 防止添乱：执行关键操作前必须再次确认最新状态，避免按照旧信息行动；遇到网络超时，也不能盲目重试。每一次查询、判断和操作都应留下可复核的记录。
- 算清细账：评估价值要看 Agent 相比原有流程多创造了多少收益、少造成了多少损失，并把失败、重试和人工复核的成本计算在内。不能把经手的业务流水直接算成收益，也不能把完成几个任务直接换算成裁减多少岗位。
- 小步放权：先让它只看不动，再让它提建议、打草稿，最后才允许它在明确边界内执行操作。每次只放宽一项限制，再根据实际效果决定继续扩大、暂停还是收回权限。
早上九点，一名员工准备开始工作，却发现昨天还能打开的系统，今天突然提示“无权访问”。
这类问题可能出现在办公室的项目平台、门店的后台系统、仓库的扫描设备或外勤人员使用的移动应用。员工通常只知道自己“突然进不去了”，于是截一张图，向 IT 服务台提交一张标题为“权限有问题”的工单。
IT 人员收到工单后，通常需要反复询问：员工无法访问哪个系统，使用什么设备，从哪里登录，昨天是否还能使用，最近有没有更换岗位或直属经理。技术人员随后需要检查企业身份系统、用户组、软件许可、设备合规状态和业务系统日志。原因可能包括登录状态失效、用户组同步失败、设备不再符合安全要求，或者员工尝试访问尚未获批的新权限。
在大型企业中，这类请求会反复出现。真正占用 IT 人员时间的，不一定是最后那一步修复，而是收集信息、判断问题类型、查询多个系统，以及把工单转给正确的团队。
RAG（检索增强生成，Retrieval-Augmented Generation）可以找到相关文档，固定工作流可以收集信息并创建工单；AI Agent（智能体，下文简称 Agent）则可以根据每一步的反馈继续调查，动态决定下一项检查。它可以先检查服务状态，再核对员工身份、设备和原有权限，并根据结果指导重新验证、运行企业预先批准的检查程序或创建恢复申请。若员工要求新权限，系统应停止自动处理，转交直属经理或数据负责人批准。
Agent 不能因为员工说“我昨天还能用”，就把他加入新用户组、停用安全措施或照搬他人权限。身份、历史授权和当前任务范围仍须由企业系统校验。
前一篇文章《企业 RAG 值不值得做：从场景选择到持续治理》讨论了企业如何让模型利用内部知识：RAG 主要回答系统可以知道什么，固定工作流按照预定路径处理任务，Agent 则根据状态变化选择下一步。员工看到的可能只是一个更快的 IT 助手，企业交出去的却是选择下一步行动的权力。
因此，企业评估 Agent 时，真正需要回答的不是模型会不会调用工具，而是这项业务是否值得把“根据反馈选择下一步”的权力交给模型；如果值得，系统的行动范围应该有多大。
一、Agent 改变了“下一步由谁决定” #
许多业务软件早已能跨系统自动执行多步操作，例如处理订单、更新物流，或者在服务异常时重启进程。这些系统却不一定属于本文讨论的 Agent。
Anthropic 将工作流（Workflow）和 Agent 区分为两种系统：工作流按照预先写好的代码流程调用模型和工具；Agent 则由模型根据当前状态推进任务，并动态选择处理步骤和工具[1]。OpenAI 的相关指南也强调，Agent 使用模型管理任务执行，根据当前状态选择工具，并判断任务是否已经完成[2]。
两种定义共同指向一个容易被忽略的变化：过去由工程师预先写进代码的处理路径，现在可能改由模型在运行时决定。
固定工作流可以表示为：
输入 → 按照预定条件选择分支 → 执行步骤 → 输出
Agent 更接近一个反馈循环：
观察当前状态 → 选择下一步 → 调用工具查询或改变状态
↑ ↓
└────── 读取结果并重新判断 ──────┘
本文后续将以权限故障作为贯穿场景：Agent 每完成一项检查，就根据服务状态、员工身份、设备、许可和历史审批等结果决定下一步。它可以运行企业预先批准的检查程序，也可以准备权限恢复申请；新权限仍由确定性系统和获得授权的人决定。
这正是 Agent 的价值来源，也是风险来源。固定程序的错误通常来自规则、代码或输入数据；Agent 还可能在每一轮重新解释目标、筛选信息并决定行动。一次判断不会停留在回答里，而会改变下一轮看到的世界。
补货则是风险更高的对照。如果系统把一次团体采购误判为消费需求上升，并据此追加订单，下一轮读取的库存和在途数量已经改变。单个步骤看似合理，连续行动却可能逐渐偏离原始目标。
因此，企业不能仅凭系统是否调用工具，就判断一项业务是否适合采用 Agent 架构。真正的分界在于：任务路径是否需要在运行中根据反馈重新决定，以及企业是否愿意让模型承担这部分路径选择。
工具和协议只提供连接，不授予行动权 #
工具（Tool）只是用于完成一次查询、计算或业务操作的接口，例如查询服务状态、读取设备合规结果或创建权限恢复申请。Agent 决定是否调用，工具本身并不理解整体目标，也不会决定主任务的后续路径。
当前主流的智能体连接技术分别解决了不同的连接问题：
- 模型上下文协议（MCP）：让 AI 应用以统一、标准化的方式发现和读取本地或远程的资源与工具[3]；
- 任务移交机制（Handoff）：允许主智能体在识别出特定需求时，将后续处理权与上下文动态移交给垂直领域的专业 Agent[4]；
- 智能体间协作协议（A2A）：让不同类型的 Agent 自动发现彼此的能力、在不同系统之间传递消息并协同处理任务[5]。
核心结论：连接协议只决定什么工具可以被调用，不决定什么操作被允许执行，更不能证明这项业务适合采用 Agent 架构。
二、哪些业务值得把路径选择交给模型？ #
Agent 并不适合所有复杂任务。它更适合目标相对清楚、步骤难以事先穷举，而且系统能够根据及时反馈调整行动的任务。税率计算即使规则繁多，只要条件能够明确编码，规则引擎通常更可靠；跨部门审批只要顺序、权限和例外已经确定，工作流平台也能完成。即使引入大语言模型（LLM，Large Language Model），固定路径仍只是 LLM 辅助工作流，并不需要让模型掌控动态行动循环。
企业可以依据以下四个条件判断是否值得把路径选择交给模型。
路径是否真的难以预先确定 #
Agent 更适合处理输入形式多变、信息分散、例外组合很多的任务。例如，同一个“无权访问”问题，可能来自服务故障、身份状态变化、设备不合规、许可过期或用户组同步失败。下一步取决于上一步发现了什么，很难提前写成一棵完整的决策树。
如果任务实际上只有几个稳定分支，例如已验证身份后按固定步骤重置密码，引入 Agent 只会把原本可以写成代码并充分测试的判断逻辑变成概率性判断。
每一步是否能够获得有用反馈 #
Agent 需要知道采取行动后发生了什么。权限排查 Agent 可以重新读取身份、设备、许可和用户组状态；代码 Agent 可以运行测试并观察结果；客服 Agent 可以确认工单是否创建成功。
若系统无法及时获得反馈，它就不能可靠地调整后续行动。模型可能仍依据已经过期的状态继续判断，表面上完成了多步任务，实际却不知道第一步是否真正生效。
错误影响能否被限制 #
Agent 早期部署通常会遇到测试没有覆盖的情况。如果系统出错时最多只会生成一份权限调查报告或恢复申请草稿，企业就能以较低成本发现并纠正错误；如果系统一次判断错误就能授予新权限、向全部门店下单或触发对外付款，试错空间就很小。
因此，企业起步时通常应选择出错后影响较小的场景，或者确保底层系统能够撤销操作，并通过补偿流程修复已经造成的后果。企业不应因为某项任务“最有价值”，就直接选择后果最严重的环节作为首个 Agent 应用场景。
预期收益能否覆盖新增成本 #
Agent 会增加模型调用、状态管理、评估、监测和异常处理成本。如果人工原本只需两分钟确认一次建议，企业很难通过复杂的自主系统获得明显回报。相反，如果员工每天需要跨多个系统收集信息、反复判断下一步并等待反馈，Agent 才可能真正减少调查和协调所花的时间。即使前三个条件成立，企业仍需证明这种动态路径带来的收益能够覆盖新增成本。这里的判断只用于排除明显缺少收益空间的场景，不能代替对项目实际投入和业务结果的测算。
综合考虑路径变化、反馈质量、错误影响和净收益，企业可以选择合适的解决方案：
| 任务特征 | 更可能适合的方案 |
|---|---|
| 路径稳定，判断条件明确 | 普通代码或规则引擎 |
| 需要理解非结构化材料，但步骤固定 | LLM 辅助工作流 |
| 只需寻找和解释内部知识 | 知识问答型 RAG 系统 |
| 路径随反馈变化，结果可观察，错误影响可限制 | 具备行动能力的 Agent |
| 处理路径不固定，但结果难以验证且错误后果严重 | 保留人工主导；AI 仅提供分析和选项 |
Anthropic 建议从能够解决问题的最简单方案开始：Agent 以更高的成本和延迟换取灵活性；如果检索、单次模型调用或固定工作流已经足够，就没有必要再让模型自主决定更多步骤[1]。
国内一位一线现场部署工程师（Forward-Deployed Engineer，FDE）在口述访谈中分享过一个典型案例：某教育集团希望把学校调研和报告生成“全链路 AI 化”，专业团队用三个月搭建了四个 Agent，但系统要求一线校长改变录音、填表和上传资料的习惯。由于输入不完整，最终输出质量不稳定，实际使用者也很少。相反，一名参加过培训的老校长保留原有人工流程，只用一个简化工具生成报告模板，反而更容易被其他校长接受[6]。
这段经历不是受控研究，也不能证明简单方案普遍优于 Agent。它说明的是：如果一套系统必须先迫使一线人员重建工作习惯，所谓“全链路 AI 化”可能只是把操作成本转移给用户。企业应先找到最小但有效的 AI 使用环节，再判断是否真的需要让模型控制整个任务路径。
三、Agent 项目的收益能否覆盖额外成本？ #
技术上适合使用 Agent，不等于项目在经济上值得投入。没有运行记录时，企业可以先按单一模型估算预算，并利用 token 放大系数进行压力测试；取得真实运行记录后，再按调用类别计算模型成本，并把工具、运行时和人工复核纳入每个成功任务的总成本。
Token 成本只是预算起点 #
先计算单一模型的参考预算 #
企业可以用以下公式估算单一模型、单一计费档位下的月度 token 成本。成本估算中最容易被低估的是 \(A\)：用户提交一次业务任务，不等于系统只调用一次模型。设每月用户任务总量为 \(N\)，月度计费模型调用量为 \(M\)，则：
\[ \begin{aligned} N &= U \times D \times Q \\ M &= N \times A \\ C_{\mathrm{token}} &= M \times \left( \frac{T_{\mathrm{in}}}{1{,}000{,}000} P_{\mathrm{in}} {}+ \frac{T_{\mathrm{out}}}{1{,}000{,}000} P_{\mathrm{out}} \right) \end{aligned} \]各符号的英文含义、单位和统计口径如下：
| 符号 | 含义（英文） | 单位／统计口径 |
|---|---|---|
| \(U\) | 用户数量（Users） | 位 |
| \(D\) | 每月活跃天数（Active days per month） | 天／月 |
| \(Q\) | 每位用户每个活跃日的任务数量（Task quantity per user per active day） | 项／用户／活跃日 |
| \(N\) | 月度业务任务总数（Monthly business tasks） | 项／月 |
| \(A\) | 每项任务平均计费模型调用次数（Average billable model calls per task） | 次／任务 |
| \(M\) | 月度计费模型调用总数（Monthly billable model calls） | 次／月 |
| \(T_{\mathrm{in}}\)、\(T_{\mathrm{out}}\) | 每次调用平均输入和输出 token（Average input and output tokens per call） | token／调用 |
| \(P_{\mathrm{in}}\)、\(P_{\mathrm{out}}\) | 每百万输入和输出 token 的价格（Input and output prices per million tokens） | 货币单位／百万 token |
| \(C_{\mathrm{token}}\) | 月度 token 成本（Monthly token cost） | 货币单位／月 |
\(U\)、\(D\) 和 \(Q\) 应来自实际任务量，\(A\) 和 token 数应通过原型测试或实际运行记录估算，价格则取决于模型、计费档位、缓存和地区。取得真实数据以前，企业应使用多个情景。
团队可以用统计期内的计费模型调用总数除以用户提交的业务任务数，计算 \(A\)：
\[ A=\frac{\text{统计期内计费模型调用总数}}{\text{统计期内提交的业务任务数}} \]这个口径还应纳入托管 Agent 服务内部产生的计费调用；数据库查询、MCP 工具或普通业务接口若另行收费，则单独计算。按照当前定义，如果部分提交任务在调用模型前被规则系统拒绝、合并或直接处理，平均 \(A\) 可能小于 1。因此，本文把 \(A=1\) 作为“每项任务平均触发一次模型调用”的单调用参考情景，而不是普遍成立的理论下限。只有把分母限定为至少触发一次模型调用的任务时，\(A=1\) 才是下限。
以下只是容量规划示例，不代表典型使用量。假设有 500 位用户、每月 20 个活跃日、每人每天提交 10 项业务任务：
\[ N=500\times20\times10=100{,}000 \]为了展示价格怎样代入公式，先使用 \(A=1\) 构造单调用参考情景。以 Gemini 3.7 Flash Standard 的付费标准档为例，截至 2026 年 8 月 30 日，输入和输出价格分别为每百万 token 0.75 美元和 3.75 美元，输出价格包含推理 token（thinking tokens）[7]。再假设每次调用平均使用 8,000 个输入 token 和 2,000 个计费输出 token。这些数字只用于容量规划，不代表行业平均值。
\[ \begin{aligned} C_{\mathrm{token}} &=100{,}000\times1\times\left( \frac{8{,}000}{1{,}000{,}000}\times0.75 {}+ \frac{2{,}000}{1{,}000{,}000}\times3.75 \right)\\ &=600+750\\ &=1{,}350\text{ 美元} \end{aligned} \]在相同任务量下，如果进一步假设每次调用都使用 8,000 个输入 token 和 2,000 个输出 token，并且只改变 \(A\) 与模型标价，就可以得到以下价格敏感性比较。截至 2026 年 8 月 30 日，结果如下：
| 模型及计费口径 | 输入价格／百万 token | 输出价格／百万 token | \(A=1\) 月度成本 | \(A=5\) 月度成本 |
|---|---|---|---|---|
| Gemini 3.7 Flash Standard[7] | 0.75 美元 | 3.75 美元 | 1,350 美元 | 6,750 美元 |
| GPT-5.6 Terra[8] | 2.00 美元 | 12.00 美元 | 4,000 美元 | 20,000 美元 |
| Claude Sonnet 5[9] | 2.00 美元 | 10.00 美元 | 3,600 美元 | 18,000 美元 |
| DeepSeek V4 Pro，缓存未命中，非高峰至高峰[10] | 0.66–1.32 美元 | 1.98–3.96 美元 | 924–1,848 美元 | 4,620–9,240 美元 |
DeepSeek 一行按照官方公布的非高峰和高峰价格给出区间；其余模型采用公开的标准价或基础价。表中没有计算缓存、批处理、搜索、收费工具和存储。不同模型的 tokenizer、推理 token、缓存机制和任务完成质量并不相同，因此这张表只能说明相同 token 假设下的标价差异，不能作为性能或性价比排名。
多 Agent 系统按调用类别计算 #
初步估算时，可以先把所有调用按单一模型的平均用量计算；如果主 Agent、子 Agent、路由和复核使用不同模型或计费档位，则应按调用类别分别计算。子 Agent 独立探索后可能只把压缩后的结果返回主 Agent，这会同时改变调用次数和每次调用的上下文长度[11]。设 \(j\) 表示调用角色或模型类别索引（Call role or model category index），详细公式为：
\[ C_{\mathrm{token}} =N\sum_j A_j\left( \frac{T_{\mathrm{in},j}}{1{,}000{,}000}P_{\mathrm{in},j} {}+ \frac{T_{\mathrm{out},j}}{1{,}000{,}000}P_{\mathrm{out},j} \right) \]其中，\(A_j\) 是每项业务任务对第 \(j\) 类模型的平均计费调用次数（Average billable calls to category \(j\) per task，单位为次／任务），其他带 \(j\) 下标的变量分别采用该类调用的平均 token 数和价格。只要所有主 Agent、子 Agent、路由、复核和重试调用都进入相应的 \(A_j\)，就不需要再乘一个统一的“多 Agent 系数”。Agent 之间传递消息本身不一定产生模型费用：它触发新的计费模型调用时计入 \(A_j\)，进入后续调用的上下文时则反映在 \(T_{\mathrm{in},j}\) 中。
尚无运行记录时只做压力测试 #
如果企业尚未取得实际运行记录，可以先估算总体 token 放大系数 \(F_{\mathrm{token}}\)（Overall token amplification factor，无量纲），用来与一个可比的普通聊天任务进行压力测试。设 \(A_0\)、\(T_{\mathrm{in},0}\) 和 \(T_{\mathrm{out},0}\) 分别为基线聊天任务的平均调用次数、每次调用的平均输入和输出 token，则在采用相同 token 统计口径时：
\[ F_{\mathrm{token}} =\frac{\displaystyle\sum_j A_j\left(T_{\mathrm{in},j}+T_{\mathrm{out},j}\right)} {A_0\left(T_{\mathrm{in},0}+T_{\mathrm{out},0}\right)} \]如果基线聊天只有一次调用，即 \(A_0=1\)，那么 \(F_{\mathrm{token}}\) 同时取决于 Agent 系统的调用次数和每次调用的 token 数。只有当各类 Agent 调用的平均 token 数都与基线相同时，\(F_{\mathrm{token}}\) 才近似等于每项任务的总平均调用次数 \(\sum_j A_j\)；在只有一类调用时，它才进一步简化为 \(A\)。更一般地，在上述 token 用量相同的条件下，\(F_{\mathrm{token}}\approx\sum_j A_j/A_0\)。跨模型 tokenizer 或计费 token 口径不同时，原始 token 数也不能直接相加比较。
Anthropic 在其 Research 系统中观察到，单 Agent 的总 token 消耗通常约为普通聊天的 4 倍，多 Agent 系统约为 15 倍[12]。这个数字是整个任务的 token 消耗比，不是每项任务的模型调用次数 \(A\)；系统指令、工具定义、历史和工具结果也会进入上下文[13][14]。因此，4 倍和 15 倍只能作为特定系统的参考压力情景，不能直接设为 \(A=4\) 或 \(A=15\)。
因此，成本估算有两种方法，但不能叠加使用：
- 自下而上估算：取得原型测试结果或实际运行记录后，使用 \(A_j\)、\(T_{\mathrm{in},j}\)、\(T_{\mathrm{out},j}\)、\(P_{\mathrm{in},j}\) 和 \(P_{\mathrm{out},j}\) 的详细公式，分别计算每类调用的成本。
- 自上而下压力测试：尚无运行记录时，只有在 Agent 与基线使用相同模型、输入输出比例相近、任务和验收标准可比的条件下，才可以近似使用：
其中，\(C_{\mathrm{baseline}}\) 是可比聊天基线的 token 成本，\(C_{\mathrm{scenario}}\) 是压力情景下的 token 成本。以上文 Gemini 的 1,350 美元单调用情景作为基线，\(F_{\mathrm{token}}=4\) 和 \(15\) 分别对应约 5,400 美元和 20,250 美元。这只是预算压力测试，不是对一般 Agent 系统的成本预测；一旦已经采用详细公式，就不能再乘 \(F_{\mathrm{token}}\)，否则会重复计算。
前文公式只是 token 预算的起点；完整的运行成本还包括收费工具、托管环境、编排系统、向量数据库、监测、人工复核与事故处理。
用成功任务和盈亏平衡点判断价值 #
先定义成功任务和可归因价值 #
系统结构确定以后，团队需要用运行数据替换上述预算假设。下面所有变量都按同一统计期计算；示例以一个月为统计期：
| 符号 | 含义（英文） | 单位／统计口径 |
|---|---|---|
| \(C_{\mathrm{total}}\) | 总成本（Total cost） | 货币单位／统计期 |
| \(S\) | 成功任务数（Successful tasks） | 项／统计期 |
| \(C_{\mathrm{success}}\) | 单个成功任务成本（Cost per successful task） | 货币单位／成功任务 |
| \(v\) | 每个成功任务的平均可归因增量价值（Value per successful task） | 货币单位／成功任务 |
| \(V_{\mathrm{total}}\) | 可归因总价值（Total attributable value） | 货币单位／统计期 |
| \(S_{\mathrm{break-even}}\) | 盈亏平衡所需成功任务数（Break-even successful tasks） | 项／统计期 |
| \(\mathrm{ROI}\) | 投资回报率（Return on investment） | 百分比 |
\(C_{\mathrm{total}}\) 包括模型、工具、运行时、基础设施分摊和人工复核的总成本，前文的 \(C_{\mathrm{token}}\) 只是其中一项。如果 Agent 只做前期排查，随后由人工独立完成，结果不计入 \(S\)，但已产生的模型、工具和转交成本仍计入 \(C_{\mathrm{total}}\)。每个成功任务的总成本为：
\[ C_{\mathrm{success}}=\frac{C_{\mathrm{total}}}{S} \]在权限故障场景中，工单关闭不等于成功：员工必须恢复原有且合法的访问，或者系统把新权限请求连同必要证据转交给有权审批的人，而且工单没有因处理错误而重新打开。使用成功任务数 \(S\) 作为分母，可以让未竟任务、无效重试和转交前的排查成本都进入核算。
同一统计期内的可归因总价值为：
\[ V_{\mathrm{total}}=S\times v \]投资回报率（ROI）为：
\[ \mathrm{ROI}=\frac{V_{\mathrm{total}}-C_{\mathrm{total}}}{C_{\mathrm{total}}}\times100\% \]理解 \(V_{\mathrm{total}}\) 的关键，是区分账面业务流水与可归因增量价值。Agent 经手一笔 100 美元的交易，不等于创造了 100 美元价值；只有相对原有流程减少的损失、节省的实际工时，或者增加的利润贡献，才能归因于 Agent。对权限故障 Agent 而言，这可能包括缩短员工停工时间、减少 IT 排查工时和降低重复工单；理论时间节省只有真正释放产能、减少支出或避免可测量损失以后，才能计入价值。
用盈亏平衡点检查回报假设 #
假设企业每月提交 100,000 项任务，Agent 系统的月度总成本为 10,000 美元，每个成功任务产生 0.50 美元可归因增量价值。为单独观察成功任务数量怎样影响回报，以下示例暂时保持任务量、总成本 \(C_{\mathrm{total}}\) 和单任务价值 \(v\) 不变。这些数字只是计算情景，不代表行业平均值。盈亏平衡所需的成功任务数为：
\[ \begin{aligned} S_{\mathrm{break-even}} &=\frac{C_{\mathrm{total}}}{v}\\ &=\frac{10{,}000}{0.50}\\ &=20{,}000 \end{aligned} \]在这组假设下，100,000 项月度任务中至少要有 20,000 项达到验收标准并产生增量价值，项目才能盈亏平衡：
| 成功任务数 \(S\) | 占提交任务比例 | 单个成功任务成本 \(C_{\mathrm{success}}\) | 可归因总价值 \(V_{\mathrm{total}}\) | ROI |
|---|---|---|---|---|
| 15,000 | 15% | 约 0.667 美元 | 7,500 美元 | -25% |
| 20,000 | 20% | 0.500 美元 | 10,000 美元 | 0% |
| 40,000 | 40% | 0.250 美元 | 20,000 美元 | 100% |
\(\mathrm{ROI}=0\%\) 表示价值刚好覆盖成本，负数才表示没有收回投入。这张表并不预测系统成熟后会怎样：成功任务增加也可能推高工具、监测、复核和事故处理成本，任务组合还会改变 \(v\)。企业必须用运行数据持续更新各项变量。
这里计算的只是统计期内的运行回报。评估整个项目时，还要计入前期开发与流程改造成本，并测算投资回收期（Payback Period）。
自动化吞吐量不等于岗位替代 #
自动化吞吐量也不能直接折算为岗位替代。澳大利亚联邦银行引入 AI 语音机器人后宣布削减 45 个客服岗位；工会提出争议后，银行承认岗位需求并未减少，撤回决定并道歉。工会称，机器人上线后人工客服工作量反而增加[15]。该系统不是本文严格定义的 LLM Agent，但它说明企业还要观察重复来电、转人工、复杂问题处理时间和剩余工作量。
同一篇 FDE 访谈中的家装企业希望把 6,000 多人缩减到 3,000 人，实施团队三个月内落地七个 Agent；但受访者认为，多数系统只改善了部分任务，只有一个销售 Agent 可能增收，无法直接对应岗位缩减目标[6]。这只是单一实施者的口述，却同样说明：岗位同时包含信息处理、沟通、异常处置和责任承担，企业应以具体任务作为核算与验收单元，而不能用 Agent 完成一个环节推断整个岗位已经消失。
因此，企业需要证明的不是 Agent 调用了多少模型或可能替代多少岗位，而是它能否以可接受的总成本持续交付更多合格结果。即使项目值得投入，企业仍要把工具、数据、参数和状态变化落实为明确边界。
四、企业真正需要设计的是 Agent 的行动边界 #
传统权限控制通常回答“谁可以使用哪个系统”。Agent 还需要更具体的 行动边界（Action Envelope）：企业不必提前规定它的每一步，却必须限定在当前目标、状态和时间范围内可以采取哪些行动，以及参数能够变化到什么程度。
行动边界必须由确定性系统执行 #
权限故障中的行动可以先分成三类：
- 诊断类：查询服务、身份、设备、许可和历史审批，不改变访问状态；
- 恢复类：把系统恢复到已有审批记录所允许的状态，例如重新验证会话；
- 新授权类：新增用户组、管理员权限或跨部门访问，必须进入正式审批。
针对这些行动，一个权限故障排查 Agent 的边界可能包括：
| 维度 | 需要限定的内容 | 示例 |
|---|---|---|
| 数据范围 | 可以读取哪些人和系统的信息 | 仅访问当前员工、设备、目标系统和历史审批 |
| 工具范围 | 可以查询、建议还是直接写入 | 可以查询状态和创建恢复申请，不能批准新权限 |
| 参数范围 | 行动影响的账户、系统和对象 | 仅处理发起人和指定系统，不得批量修改用户组 |
| 时间范围 | 任务授权与临时访问的有效期 | 授权只用于当前请求，到期后自动失效 |
| 资源范围 | 可使用的调用次数、费用和外部资源 | 限制状态查询、重试和子 Agent 调用次数 |
| 状态范围 | 可以从当前状态进入哪些下一状态 | 待排查可进入已恢复或待审批，不能跳过审批 |
| 升级条件 | 何时必须暂停并转交人工处理 | 管理员账号、身份冲突、新权限或跨部门访问必须转交 |
行动边界与一句“请谨慎操作”的提示词不同。提示词仍要由模型自行理解和遵守；行动边界必须落实到工具接口、身份系统、规则引擎和业务状态机（State Machine）中，并由确定性代码强制执行。
模型与确定性代码在这里承担不同职责：
| 更适合交给模型 | 必须由确定性系统控制 |
|---|---|
| 理解非结构化输入，提出可能原因和调查路径 | 身份、权限与当前任务授权 |
| 根据新证据选择下一项调查 | 参数上限、预算和调用频率 |
| 整理证据并解释候选行动 | 符合业务规则的状态变化、幂等与并发控制 |
| 发现信息不足并请求补充 | 写入确认、审计、暂停与回滚 |
核心结论：模型可以提出“下一步值得做什么”，但确定性代码必须决定“这项行动现在是否允许生效”。
模型可以选择诊断路径并提出恢复方案；恢复类行动仍须校验身份、历史批准和任务范围。涉及新授权时，Agent 只能整理证据，再把请求提交审批。
Agent 的有效权限取决于用户、Agent、任务和工具的交集 #
企业通常不会有意把超级权限的共享服务账号长期开放给所有员工。更现实的风险出现在系统从验证环境进入生产环境时：团队为快速完成概念验证（Proof of Concept，PoC）或集成测试而临时使用高权限账号，却因环境隔离不完整、发布清单未要求降权，或临时授权缺少负责人、到期时间和交接要求，让测试配置随系统进入生产。《在关系与规则之间：怎样在不完善的组织里做成事》讨论过，临时安排需要转化为可交接的组织能力；在 Agent 项目中，就是把账号用途、负责人、到期时间、环境隔离、权限降级和账号回收纳入可验证的发布与交接流程。
一旦这种账号进入生产，业务系统原有的门店、区域、部门及字段级权限控制就可能被击穿。一个只能查看华东区域库存的员工，可能会借由 Agent 间接查询全国数据；一个能够阅读供应商档案的人，也可能通过自然语言触发原本无权执行的订单操作。
更合理的做法，是让系统在每次任务中记录发起用户、执行任务的 Agent，以及本次任务的授权范围。实际可用权限应当取多个边界的交集：
有效权限 = 用户权限 ∩ Agent 权限 ∩ 当前任务授权 ∩ 工具策略
其中，用户权限决定了发起者本人能看什么；Agent 权限规定系统本身最多可以调用哪些能力；当前任务授权规定了本次访问的特定目的与时效；工具策略则在执行前最后检查数据范围、参数上限和状态流转规则。只要任一层的授权条件不满足，模型应当停止操作，不应尝试通过改变问法、切换工具或转交任务来绕过限制。
系统需要分别落实以下几类控制：
| 需要控制的问题 | 企业应采用的机制 |
|---|---|
| 谁能使用哪个 Agent | 企业身份登录、用户组、角色和允许使用的业务场景 |
| 用户能让 Agent 看哪些数据 | 沿用源系统的行级、列级和对象级权限，在数据进入模型上下文前过滤 |
| Agent 能调用哪些能力 | 按 Agent 和场景配置工具白名单，区分读取、写入与审批权限 |
| 本次任务能做什么 | 短时授权、目的与范围绑定、金额和数量限制、到期失效 |
| 子 Agent 能继承什么 | 明确授予完成任务所需的最小权限，不转发管理 Agent 的完整凭证与上下文 |
| 敏感结果怎样输出 | 脱敏、字段级过滤、下载限制和防止跨会话泄露 |
权限校验必须由数据源、MCP 服务器或业务接口执行；模型不能根据用户自述判断身份。MCP 的授权机制要求受保护服务器验证访问令牌及其目标资源和授权范围[16]。企业还应分别验证最终用户、执行任务的 Agent 和委托关系，并在资源和工具层面落实最小权限原则；客户端隐藏工具只能减少模型看到它的机会，不能充当安全边界。
数据最小化原则同样适用。排查一名员工对指定系统的访问时，不应把其他员工的权限、完整人事档案或无关业务数据一并放进上下文。
哪些行动需要重新授权或人工批准？ #
人工批准应在越过边界前触发 #
数据访问只是行动边界的一部分。Agent 一旦可以调用写入工具，企业还要根据操作是否会长期改变业务状态、能否撤销，以及影响范围有多大，决定是否允许系统执行。
NIST 汇总的 Agent 工具研讨会成果提出，可以从读取或写入权限、行动是否产生持续影响、能否撤销、监测能力和自主程度等维度分析风险[17]。这些维度共同说明，仅看工具名称无法判断风险。同样是“更新订单”接口，只能修改一份草稿和能够批量改变已确认订单，两者对应的行动能力完全不同。
行动边界还要绑定当前任务。系统即使具备创建权限恢复申请的能力，也只能用于目标、发起人、数据范围、工具范围和有效期都符合本次授权的任务；每次行动前都要检查参数是否仍在原始授权范围内。
这也解释了人工批准应该放在哪里。企业不必让人逐条批准低风险查询，却可以在 Agent 准备越过行动边界时要求确认。审批人应当批准一项具体变更，例如“依据审批记录 Y，把员工 A 恢复到用户组 X，权限有效至某日”，而不是笼统地允许系统“修好权限”。
Anthropic 在 Agent 产品实践中也讨论了逐项批准操作与先审查整体计划之间的取舍。用户可以批准一个边界清楚的计划，并且可以在执行过程中随时介入；这比面对大量缺乏上下文的确认提示更能让人工监督真正发挥作用[18]。
没有必要让人工批准每一个步骤。如果系统为常规查询和微小调整频繁弹窗，一线人员容易产生审批疲劳（Supervision Fatigue），最终不再认真判断。企业可以按行动是否越过既定边界区分处理方式：
| 行动类型 | 处理方式 |
|---|---|
| 边界内的低风险查询 | 由确定性系统校验后静默执行 |
| 参数、主体或权限范围出现异常变化 | 展示结构化差异和依据，要求重新确认 |
| 新授权、管理员权限或身份冲突 | 停止自动执行，转交有权人员处理 |
这样的设计把人工注意力留给真正需要判断的变化，避免批准机制沦为形式上的“橡皮图章”。
用户授权不等于平台授权 #
Agent 能否代表用户行动，不能只由用户单方面决定。Perplexity 的 Comet Agent 可以登录用户账户、比较商品并代为下单。2025 年，Amazon 起诉 Perplexity，指控该 Agent 隐瞒自动化身份、访问用户的私人账户，并带来数据安全和购物体验方面的风险；Perplexity 否认这些指控，认为 Amazon 在限制用户选择。2026 年 3 月，地区法院一度颁布初步禁令；同年 8 月，第九巡回上诉法院撤销禁令并发回重审，认为 Amazon 在现有记录下尚未证明 Perplexity 构成相关法律所指的“访问”[19]。
案件尚未最终解决，却已经说明行动授权不是单向关系：用户同意 Agent 代为购物，不等于零售平台已经允许这个 Agent 代表用户操作；平台允许用户登录，也不等于允许第三方系统以用户身份自动访问账户和下单。企业需要验证用户、Agent 和委托关系，并明确谁同意交易条款、谁承担误购和数据访问责任。
身份恢复必须依赖确定性验证 #
IT 服务台的真实事故也说明，恢复访问并不是“回答对问题”这么简单。2025 年，Clorox 在诉讼中指控其 IT 服务提供商 Cognizant 的服务台在未按约定验证来电者身份的情况下重置了凭证，攻击者随后借此进入公司网络；Reuters 报道称，Clorox 索赔约 3.8 亿美元。Cognizant 否认责任，并称其工作范围仅限服务台，不包括网络安全[20][21]。
这不是 AI Agent 事故，诉讼指控也不等于法院已经认定事实。这个案例真正说明的是：只要一项行动涉及凭证恢复，身份就必须依据可信、可核验的信息进行验证，不能依赖来电者自述，更不能让模型自行判断“看起来像本人”。
审计记录必须还原授权、行动和状态变化 #
聊天记录本身不足以审计 Agent。它可能显示用户提出了什么要求，却没有说明系统实际检索了哪些对象、某次工具调用使用了谁的权限、任务移交以后由谁接手，以及业务状态最终发生了什么变化。
一条可供企业复核的审计链，至少要完整记录三类因果信息：
- 身份与委托链路：明确记录谁发起了任务、系统以哪位用户的权限运行、下发给子 Agent 时剥离了哪些凭证；
- 调用与审批轨迹：精确记录 Agent 实际读取了哪些数据、调用了哪些工具与参数、哪位人工审批者在何时确认了变更；
- 状态迁移与异常记录：记录操作前后的业务数据变化、中间发生的失败与重试，以及出现异常时的回滚与补偿日志。
对高风险写入操作，企业还应保留防篡改的独立存证。这样，审计团队既能从业务数据异常追查到具体任务，也能从单次任务追踪到底层系统的具体状态变化。
审计日志本身可能包含提示词、客户数据、访问令牌或商业信息，因此不能无差别永久保存。企业需要对日志中的敏感字段进行脱敏，实行分级访问，防止日志被篡改，并规定保存期限；安全与审计团队可以查看必要证据，但不应因此获得所有原始业务数据。审计的目标是建立责任链，而不是复制一套风险更高的数据仓库。
行动边界能够限制模型可以做什么，却不能保证边界内的每一步都正确。Agent 的另一类风险，恰恰来自许多看似合规的小动作在循环中相互影响。
五、Agent 的错误为什么不会停在一次回答里？ #
在不涉及工具调用或数据写入时，普通问答系统的回答错误只停留在屏幕上，不会直接污染外部系统的状态。但 Agent 的决策会转化为具体工具的输入参数，进而写入业务系统。一旦数据被修改，被污染的状态又会成为下一轮循环的输入，错误随之开始滚雪球式地传播。
诊断错误可能只影响建议，恢复类行动却会改变身份与访问状态。下一轮运行时，系统必须区分哪些变化由 Agent 造成，哪些来自管理员或源系统，以及哪些操作仍在等待生效。补货中的重复下单会带来更直接的财务影响，但放大机制相同。
几种机制尤其容易放大错误。
| 风险层面 | 错误怎样放大 | 主要控制 |
|---|---|---|
| 状态与执行 | 检查后状态变化，或者超时重试造成重复恢复或重置 | 执行前重新校验、幂等键、状态版本 |
| 目标与信息 | 局部指标替代整体目标，模型推断被下游当成事实 | 平衡指标、数据来源标记、置信状态 |
| 多 Agent 协作 | 不同状态快照、重复执行和循环委托 | 任务所有权、唯一任务 ID、事务与顺序控制 |
| 评估与恢复 | 最终答案看似正确，却掩盖过程中的越权或无效行动 | 轨迹评估、确定性检查、回归测试 |
状态与执行为什么会失去同步 #
检查结果已经过期。 Agent 查询员工身份和原有审批后，员工岗位、设备合规状态或访问授权可能已经发生变化。检查时成立的条件，在执行那一刻未必仍然成立。这种“检查时与执行时不一致”（Time-of-Check to Time-of-Use，TOCTOU）问题并非 Agent 独有，但任务步骤越多、运行时间越长，出现该问题的概率就越高。
系统绝不能只在任务开始时做一次性验证。在执行关键写入操作的前一刻，必须重新读取核心数据字段，再次确认当前状态是否仍符合原来的执行条件。
超时重试造成重复操作。 工具调用超时后，Agent 往往无法判断权限恢复申请或会话重置是否已经生效。如果它因为“没有收到成功结果”而盲目重试，就可能产生重复申请，甚至让刚刚生成的新凭证再次失效。
企业必须确保写入操作具有幂等性（Idempotency）：相同的业务请求即使重复到达，也只能生效一次。如果缺乏幂等键和明确状态校验，智能体的自动重试机制就会把普通的网络超时演变为严重的业务故障。
目标和信息怎样在循环中偏移 #
局部指标替代整体目标。 如果企业只要求权限 Agent “尽快关闭工单”，系统可能过早认定问题已经解决，或者通过恢复过宽的权限来缩短处理时间。关闭速度提高了，重复开单和未授权访问风险却随之上升。这并非智能体违反了什么规则，而是它在一个定义不完整的目标函数下做出了局部最优、全局受损的决策。
此类问题无法通过在提示词中追加“同时注意成本”来解决。企业需要在系统中同时设置相互制约的指标、硬性上限和停止条件，并持续监测 Agent 是否只优化了表面指标。
模型推断被下游当成事实。 智能体写入“身份已验证”或“经理已批准”之类的摘要，极易被后续的其他 Agent 或业务系统作为“客观事实”读取。如果系统没有区分原始身份记录、人工确认结果和模型生成内容，早期的概率性推断就会在下游链路中被误当成权威证据。
因此，所有模型生成的内容都必须注明来源与置信状态；未经核实的推断绝不能直接写入会被下游系统作为事实依据的数据字段中。
多 Agent 为什么会增加协调错误 #
单个 Agent 的行动循环已足够复杂，多智能体协作则带来了更多因共享状态引发的冲突。身份、设备、许可和应用系统子 Agent 可能基于不同时间点的状态提出互相矛盾的结论，甚至同时创建两份权限恢复申请；一个 Agent 把推断写进摘要，另一个 Agent 则把该摘要当成已核实的数据。如果缺乏明确的任务所有权（Task Ownership），任务极易在 Agent 之间陷入循环委托或无人收尾的尴尬境地。
多智能体系统不能仅仅记录“谁调用了谁”。每次委托都必须绑定唯一的任务 ID、状态版本、当前负责人和明确的完成条件，同时利用事务机制和顺序排队来解决并行写入冲突。
评估必须检查行动轨迹 #
OWASP（开放式 Web 应用程序安全项目）2026 年智能体应用（Agentic Applications）风险清单把记忆与上下文污染、工具误用、不安全的 Agent 间通信以及级联失败列为重要风险，并特别强调最小权限、行动级验证、预算限制和持续监测[22]。Agent 的错误往往会在状态变化和多步调用的共同作用下被放大，因此评估绝不能仅看最终文本答案是否顺畅，而必须审查完整的运行轨迹（Tracing）[23]。
结合这些风险，以及前文对成本和行动边界的讨论，企业可以把轨迹评估整理为四类检查：
- 环境与版本：每次运行都要固定并记录基础模型、系统提示词、工具 schema、权限配置和评测数据集的版本，并精确记录模型调用次数、token 消耗（输入、输出与缓存）和外部收费 API 开销，确保成本异常与质量回归可复现、可定位。
- 决策与工具轨迹：检验模型是否选择了合适的工具、是否发生死循环、无效重试或结果冲突，以及是否依据已过时的业务快照作出判断。
- 确定性边界：由确定性代码自动检查运行轨迹中的越权访问、边界违规、重复写入、高危参数和异常工具组合。
- 业务结果与成本：将技术完成率与实际业务改善挂钩，综合衡量人工修正量、剩余工作量、异常发生后的恢复时间，以及重复工单率、未授权访问和员工停工时间，防止出现“完成率虚高但整体运维成本暴增”的情况。
只有把这些指标用于持续评估，它们才能成为扩大行动权的依据。团队可以根据真实任务、历史错误和边界情况整理测试集，先记录人工流程或现有自动化的基线，再在不改变业务状态的环境中检查 Agent。
权限、参数、格式、重复写入和状态转换适合用确定性规则验证；工具选择和任务路径需要检查行动轨迹；没有唯一答案的建议可以由人工判断，或交给经过人工校准的评估模型。高风险业务结果仍应由专业人员复核。
每轮测试以后，团队需要判断错误主要来自模型、数据、工具还是流程，再决定修改提示词、补充数据、收紧工具权限或调整工作流。实际运行中新出现的失败案例，也要补进回归测试集。
六、企业应该怎样分阶段开发和部署 Agent 应用？ #
人们经常用模型能够独立工作多久来衡量它的自主性，并据此判断它是否“更像 Agent”。但企业实际部署的是由模型、工具、权限、状态和监督方式共同组成的系统。因此，这里的“开发和部署”不只是完成编码和上线，而是让系统从不改变业务状态的测试逐步走向受控执行，并在证据不足时暂停，或者退回前一阶段。
Anthropic 对实际 Agent 使用的研究也认为，自主程度取决于具体部署方式，而不是模型自带的固定属性。相同模型在不同工具权限和人工监督下，会表现出不同的自主程度和风险[24]。该研究的数据主要来自单一模型提供商，软件工程任务占比较高，不能直接代表所有行业；但它提醒企业，不能脱离具体部署讨论“模型有多自主”。
从影子运行到受控执行 #
企业不应一次性全量上线 Agent，而应沿四级阶梯推进：
- 第一级：影子运行（Shadow Mode）。系统基于历史或当前的脱敏权限工单生成轨迹，但禁用所有写入工具；团队将结果与现有流程比对。
- 第二级：决策建议（Decision Support）。Agent 执行诊断并给出证据，由 IT 人员判断并执行；如果审核比人工排查更慢，系统尚未产生实际提效。
- 第三级：草稿模式（Drafting Mode）。Agent 为恢复类或新授权类行动准备结构化申请和变更 diff，仍由人工提交和批准。
- 第四级：受控执行（Controlled Execution）。系统只在边界内执行低风险、可撤销且有有效批准依据的恢复类行动；新授权类行动仍必须转交人工。
Microsoft 的企业 IT Agent 模式把密码重置、访问开通和设备故障列为常见服务台任务，同时明确建议为授予访问等敏感行动保留人工审批，并提供问题升级和人工接管机制[25]。这与上述分级的关键区别一致：Agent 可以动态排查，但“找到可能原因”并不会自动产生“有权修改权限”的结论。
正面案例也更适合放在人工仍握有决策权的阶段。ServiceNow 发布的 EY 客户案例称，EY 服务台每年处理超过 100 万张工单；其生成式 AI 会起草解决记录交给人员批准。该案例报告每张工单约节省五分钟，一个月生成 10.3 万份记录，其中 70% 未经修改即被接受[26]。这些数字来自厂商发布的单一客户案例，不能作为行业平均值；但它说明，企业可以先让生成式 AI 准备可复核草稿，在不交出最终行动权限的情况下验证实际价值，再判断是否需要进一步引入 Agent 的动态调查与执行能力。
扩大权限前检查什么 #
企业可以扩大处理规模、放宽参数范围、延长运行时间或减少人工确认，但应把它们作为彼此独立的部署变量。只有当任务质量、人工修正量、边界违规率、成本和恢复时间均符合预设门槛，企业才有证据继续扩展；关键指标恶化时，则应退回原来的模型、策略或权限范围。
企业可以把这些检查汇总为扩大、维持或收回权限的决策表：
| 检查维度 | 比较基线 | 可以扩大权限的证据 | 应暂停或收回权限的信号 |
|---|---|---|---|
| 业务结果 | 人工流程或现有自动化 | 合格结果增加，重复处理减少 | 只提高吞吐量，返工或投诉增加 |
| 行动边界 | 已批准的权限和参数范围 | 没有严重越界，异常能够被拦截 | 出现未授权写入或边界绕过 |
| 人工负担 | 原有审核与处理工时 | 修正和接管工作减少 | 人工持续修补系统或机械批准 |
| 单位成本 | 单个成功任务成本与 ROI 目标 | 增量价值能够覆盖完整成本 | 工具、复核和事故成本持续上升 |
| 恢复能力 | 预设恢复时间和演练结果 | 回滚与补偿流程经过验证 | 错误无法及时停止或恢复 |
| 系统稳定性 | 前一模型、策略或权限等级 | 质量与成本在观察期内稳定 | 结果变化无法归因于单一调整 |
具体门槛和观察期应由企业根据业务风险设定，本文不提供通用数值。每次仍然只扩大一个变量，才能判断结果变化来自模型、工具、数据还是权限调整。
同一项任务中的诊断、恢复和新授权可以采用不同的自主程度。企业交出的不是整项工作的控制权，而是若干边界清楚、可以重新收回的行动权。
美国国家标准与技术研究院（NIST）的人工智能风险管理框架（AI Risk Management Framework，AI RMF）要求把治理、场景识别、风险衡量和持续管理贯穿 AI 系统生命周期，并明确人机协作与监督责任[27]。业务负责人不能只提出自动化目标，技术团队也不能独自决定组织愿意承担多大的行动风险；正式制度必须明确谁定义边界、批准扩大权限、监测异常并暂停系统。
谁定义、执行、监督并承担结果？ #
同一个口述访谈中的另一个项目更直接地暴露了责任问题。企业高层购买了一个要求交付多个 Agent 的项目，却没有指定具体业务场景，也没有安排对业务结果负责的需求方。负责执行的人无法取得一线数据，只能围绕演示和汇报材料推进，最终连“做到什么程度才算验收”都没有形成共识[6]。阻碍项目的首要原因不是模型能力，而是企业缺乏明确的任务负责人、业务基线与验收标准。
Agent 可以在已经定义的任务内选择下一步，却不能替企业决定为什么做、什么状态才算完成，以及谁承担结果。技术团队也不能独自决定哪些流程值得改变、哪些一线习惯可以被打破。行动边界与监督机制必须落实到具体角色，不能只写成“业务与技术共同负责”。
| 主体 | 定义或决定什么 | 执行或监督什么 |
|---|---|---|
| 业务负责人 | 业务目标、基线、验收标准、行动边界和风险底线 | 协调一线人员参与，并提供必要的数据访问条件；批准扩大权限，在指标恶化时暂停或收回权限 |
| 一线人员 | 提供真实流程、例外情况和使用反馈 | 对边界外或高风险行动作出批准、修改或拒绝，并反馈系统缺陷 |
| 技术与现场实施团队 | 将岗位拆成任务，判断代码、工作流、RAG 或 Agent 哪种方案更合适 | 落实身份权限、状态机、幂等、熔断、回滚和恢复，并用真实任务分步验证 |
| 风险与审计人员 | 规定日志、证据、抽样和保存要求 | 独立复核运行轨迹，检查责任链并持续校准边界 |
责任划分也需要与项目激励保持一致。如果管理层把 Agent 宣传为“减员替代”，一线人员可能因为担心被替代而不愿提供非结构化背景信息，甚至隐瞒非正式经验或绕过系统，Agent 随之失去高质量输入。企业更适合把它定义为减少机械性排查、支持复杂判断的协同工具，并把主动发现边界缺陷和异常轨迹作为值得鼓励和奖励的行为。
用户复核不等于责任转移。只有当使用者拥有充分的信息、时间、权限与专业判断力时，人工批准才有实质意义；技术团队与业务负责人仍须设置合理的默认权限与自动熔断，防止单次误操作演变成系统性风险。
结语 #
核心结论：企业采用 Agent，不必追求抽象的“更自主”，而要决定哪些行动权限值得交出，又凭什么证据扩大、暂停或收回这些权限。
大模型和 Agent 进入企业，不是给现有软件增加一个对话入口，也不是简单部署一项新技术，而是一次系统级升级。业务流程、身份与权限、数据流转、状态管理、评估与恢复机制，以及业务、技术和管理者之间的责任分工，都要随之调整。
在市场热潮中，许多公司急于推出各种面向企业的 Agent 产品。演示中的系统能够调用工具、连续执行任务，看起来似乎已经具备落地条件；真正进入生产环境后，企业才会面对系统集成、权限边界、异常恢复和组织协作等难题，而这些挑战往往被低估。
因此，决定 Agent 能否落地的，不是它能展示多少能力，而是动态选择能否比固定流程创造更多价值，以及企业能否观察和验证每次行动，并在出错后恢复业务状态。只有满足这些条件，Agent 才适合从回答问题走向改变业务状态。
未来，模型会处理周期更长的任务、调用更多工具，也会更频繁地与其他 Agent 协作，系统看起来会越来越自主。但它能否进入采购、财务、客户权益和基础设施等核心业务，并不取决于模型能够连续工作多久，而取决于企业的身份验证、权限控制、状态管理、评估和恢复机制能否同步升级。模型能力越强，企业越需要用外部约束把这种能力转化为可控、可追责、可恢复的业务行动。
参考文献 #
[1] Anthropic. Building Effective Agents. 2024. https://www.anthropic.com/engineering/building-effective-agents
[2] OpenAI. A Practical Guide to Building Agents. 2025. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
[3] Model Context Protocol. What Is the Model Context Protocol (MCP)? 2026-07-28. https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro
[4] OpenAI. Orchestration and Handoffs. Accessed 2026-08-28. https://developers.openai.com/api/docs/guides/agents/orchestration
[5] Google. Announcing the Agent2Agent Protocol (A2A). 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
[6] AI闹. 硅谷最火职位在中国：好苦，好痛，正在救火路上. Accessed 2026-08-29. https://mp.weixin.qq.com/s/aM3AqRksDV-w-1RYwZUeNA
[7] Google. Gemini Developer API Pricing. Accessed 2026-08-30. https://ai.google.dev/gemini-api/docs/pricing
[8] OpenAI. GPT-5.6 Terra Model. Accessed 2026-08-30. https://developers.openai.com/api/docs/models/gpt-5.6-terra
[9] Anthropic. Pricing. Accessed 2026-08-30. https://platform.claude.com/docs/en/about-claude/pricing
[10] DeepSeek. Models & Pricing. Accessed 2026-08-30. https://api-docs.deepseek.com/quick_start/pricing/
[11] Anthropic. Effective Context Engineering for AI Agents. 2025-09-29. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[12] Anthropic. How We Built Our Multi-Agent Research System. 2025-06-13. https://www.anthropic.com/engineering/multi-agent-research-system
[13] Google. Understand and Count Tokens. Accessed 2026-08-29. https://ai.google.dev/gemini-api/docs/tokens
[14] OpenAI. Prompt Caching. Accessed 2026-08-29. https://developers.openai.com/api/docs/guides/prompt-caching
[15] Australian Broadcasting Corporation. Commonwealth Bank Backtracks on AI Job Cuts, Apologises for ‘Error’ as Call Volumes Rise. 2025. https://www.abc.net.au/news/2025-08-21/cba-backtracks-on-ai-job-cuts-as-chatbot-lifts-call-volumes/105679492
[16] Model Context Protocol. Understanding Authorization in MCP. 2026-07-28. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/authorization
[17] NIST. Lessons Learned from the Consortium: Tool Use in Agent Systems. 2025. https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
[18] Anthropic. Trustworthy Agents in Practice. 2026. https://www.anthropic.com/research/trustworthy-agents
[19] U.S. Court of Appeals for the Ninth Circuit. Amazon.com Services, LLC v. Perplexity AI, Inc. 2026. https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf
[20] Reuters. Clorox Accuses IT Provider Cognizant of Enabling Devastating 2023 Cyberattack. 2025. https://www.investing.com/news/stock-market-news/lawsuit-says-clorox-hackers-got-passwords-simply-by-asking-4146778
[21] The Clorox Company and Clorox Services Company v. Cognizant TriZetto Software Group, Inc. Complaint. 2025. https://storage.ghost.io/c/6b/16/6b16ac9c-cd67-432f-b0f3-bbec941084ff/content/files/2025/07/07-22-redacted-clorox-complaint.pdf
[22] OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026. 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
[23] OpenAI. Evaluate Agent Workflows. Accessed 2026-08-28. https://developers.openai.com/api/docs/guides/agent-evals
[24] Anthropic. Measuring AI Agent Autonomy in Practice. 2026. https://www.anthropic.com/research/measuring-agent-autonomy
[25] Microsoft. Workplace and IT Services Pattern. Accessed 2026-08-30. https://learn.microsoft.com/en-us/agents/adoption-patterns/pattern-workplace-it-services
[26] ServiceNow. EY Uses AI Agents to Transform Employee Support. Accessed 2026-08-30. https://www.servicenow.com/customers/ey-ai.html
[27] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://doi.org/10.6028/NIST.AI.100-1