Agent 原理（十三）：真正的生产级门槛，不是“会不会做”，而是“谁有权决定”

从“能做”走到“有权做”，中间隔着的是生产级 Agent 最重要的一道治理边界。

前面十二课，我们一直在想办法把 Agent 变强。

Planning 解决的是：它不是不会做，而是不知道下一步先做什么。

Verification 解决的是：做错并不可怕，真正危险的是做错以后还一本正经地告诉你“已经完成”。

Memory 和 Skill 被拆开以后，我们又开始区分：记住过去发生过什么，和真正掌握一套以后还能复用的方法，到底是不是同一回事。

到了第十二课，事情又往前走了一步。

Agent 做完任务以后，可以从 Experience 里找 Evidence，再 Reflection，形成 Candidate，经过 Validation，最后才决定这条经验有没有资格进入 Knowledge Update。

也就是说，我们第一次认真允许：

过去发生过的事情，改变 Agent 未来做事的方法。

这听起来很强。

但也正因为它越来越强，第十三课必须马上补上一条更硬的边界。

因为当 Agent 不只是会做事，还开始会提出建议、改变方法、影响现实以后，我们必须问一个比“它聪不聪明”更重要的问题：

它凭什么替你做决定？

先想一个人，不要先想 Agent

假设公司新来了一名采购分析师。

能力很强。

你给他 20 家供应商报价，他没有像普通人一样只看 Excel 里的单价，而是先把币种、计价单位、最低采购量、贸易条款、运费、税费、包装计价基础全部拉到同一口径，再重新计算真实采购成本。

最后他说：

Supplier B 最划算。

比 Supplier A 便宜 8.7%。

交期满足。

质量也满足。

你不放心，又让另外三个人复核。

结果完全正确。

现在问题来了。

这个分析师能不能因为自己分析得完全正确，就直接进入 ERP，批准一张 500 万美元的采购订单？

显然不能。

为什么？

不是因为他不会操作 ERP。

不是因为他的计算不可信。

甚至不是因为他的结论有问题。

真正的原因只有一个：

这件事，本来就不是由他决定的。

这就是第十三课的起点。

过去我们一直在问：

Agent 会不会做？

现在必须再加一句：

就算它会做，而且做得完全正确，这件事情是不是应该由它决定？

这是两个完全不同的问题。

会做，不等于有权做

一件事情交给 Agent，可以拆成三个层次。

第一层：

它会不会做。

比如它知道怎样写邮件，也知道怎样调用发送邮件的工具。

第二层：

系统有没有把这个工具给它。

比如这个 Agent 确实可以访问企业邮箱。

第三层：

这一次具体动作，它有没有资格真的执行。

前两个答案都可以是“是”，第三个仍然可以是“否”。

所以真正进入生产环境以后，最重要的一条式子其实很简单：

Capability + Tool Access ≠ Execution Authority

一个 Sales Agent 能发邮件，不代表它可以替公司对客户承诺合同条款。

一个 Procurement Agent 能改采购系统，不代表它可以批准大额订单。

一个 DevOps Agent 能调用部署接口，也不代表它可以随时改生产环境。

工具一样。

真正不同的是：

这一次动作会让现实世界发生什么变化。

为什么只做“工具权限”远远不够

很多 Agent 系统一开始都会这样设计：

• Research Agent：搜索、读文件；
• Sales Agent：读 CRM、发邮件；
• Procurement Agent：读报价、改采购系统。

这当然比“什么都开放”好。

但还不够。

因为同一个“修改采购系统”，可能只是改一条内部备注；也可能是改采购数量；还可能是正式批准一张百万美元订单。

Tool 没有变。

Action 的后果完全变了。

所以生产级 Agent 不能只问：

这个工具危险吗？

而要进一步问：

这一次动作危险吗？

不需要一开始就做一套很复杂的数学模型。

先把几个最朴素的问题问清楚：

• 它准备改什么？
• 影响范围有多大？
• 做错以后会发生什么？
• 能不能恢复？
• 是测试环境还是真实生产环境？
• 有没有碰到钱、客户、合同、敏感数据或生产系统？

如果一定要把这套思路压成一个“工程上方便讨论的近似式”，我更喜欢这样写：

Action Risk ≈ Impact × Scope × Irreversibility × Context Sensitivity

它不是为了算出一个漂亮的小数。

它真正提醒我们的是：

风险属于动作，不属于工具。

一个最简单的例子：删除文件

假设 Agent 有一个能力：

删除文件

它删除本地测试目录里的test.csv，和它删除生产系统正在使用的客户订单文件，调用的可能是同一个程序。

但你显然不会给它们同样的处理方式。

为什么？

不是因为“删除文件”这个 Tool 突然变得更危险了。

而是因为：

对象变了。

环境变了。

影响范围变了。

恢复难度变了。

后果也变了。

所以一个成熟的 Agent，最终一定不能只理解：

我调用了什么工具。

还必须理解：

我准备对什么对象，在什么环境里，造成什么改变。

第十三课最关键的一刀：Planning 完以后，不要马上执行

前面的 Demo 很容易长成这样：

用户目标 → Planning → 执行

做演示当然没问题。

但到了真实企业环境，这条链路必须被切开。

Planning 得出的结果，不应该再被理解成：

“我要执行这个动作。”

而应该理解成：

“基于目前的信息，我建议下一步执行这个动作。”

只改了几个字。

整个架构却完全不一样。

生产级 Agent 的动作治理链路

↓

↓

采购 Agent 分析以后认为应该批准 Supplier B。

以前可能直接调用：

approve_purchase_order()

现在它应该先生成一个 Proposed Action：

• 准备批准哪张订单；
• 供应商是谁；
• 金额多少；
• 为什么推荐；
• 用了哪些 Evidence；
• Verification 是否通过。

然后不要执行。

先进入规则检查。

所以真正应该落到架构里的链路是：

Planning → Proposed Action → Policy Check → Execution → Verification

这一刀切开以后，Agent 的“判断能力”和“行动权”才终于不再绑在一起。

为什么不能让 Agent 自己判断“这次需不需要审批”

有人会说：

何必这么麻烦？

直接在 Prompt 里写一句：

“遇到重要操作时要谨慎，必要时先找人确认。”

不就行了？

问题是：

什么叫重要？

什么叫谨慎？

什么叫必要时？

最后还是谁解释？

Agent 自己。

于是系统就会出现一种非常奇怪的结构：

Agent 先提出动作。

Agent 自己解释公司规则。

Agent 再判断“我觉得这次风险不高”。

最后 Agent 自己批准自己继续执行。

换成人类场景就知道多离谱。

一个员工提交 100 万元付款，然后自己在审批意见里写：

“经本人判断，本次无需经理审批。”

这不叫 Governance。

这只是让同一个主体同时做申请人和审批人。

所以真正重要的规则，不能只存在于 Prompt 里。

它必须逐渐变成系统里独立、可测试、可审计的一道边界。

例如：

• 采购金额超过某个范围，需要采购负责人批准；
• 涉及客户正式承诺的邮件，需要人工确认；
• 删除生产数据，默认禁止；
• 普通查询可以自动完成。

只有规则独立以后，我们才真正能测试：

什么应该通过。

什么应该停。

什么必须找人。

Agent 有 99% 把握，也不代表它可以自己决定

还有一个特别容易混淆的概念：

Confidence 和 Authority。

很多系统会给 Agent 一个置信度。

例如：

95% 以上自动执行。

看起来很科学。

但它把两个完全不同的问题混在了一起。

第一个问题：

Agent 有多确定自己的判断是对的？

第二个问题：

如果它判断错了，后果有多严重？

这两件事根本不是一回事。

High Confidence ⇏ Decision Authority

Agent 对一个搜索关键词只有 60% 把握，可以让它搜。

搜错了，再换一个就行。

但 Agent 对一笔 500 万美元付款有 99.9% 把握，也不代表它可以自己付款。

因为：

正确率高，不会自动产生决定权。

所以真正合理的自动化逻辑，不是只看 Confidence，而要同时看 Consequence。

这张表比“95% 就自动执行”更接近真实生产系统。

真正好的 Agent，不应该追求“什么都自动”

讲到这里，很容易走到另一个极端。

既然 Agent 有风险，那所有东西都找人审批好了。

听起来安全。

真正用两天就知道有多荒唐。

读文件，要你确认。

搜资料，要你确认。

生成报告草稿，要你确认。

写一条内部备注，也要你确认。

最后人的工作没有减少。

只是从“自己做”，变成了：

不停帮 Agent 点确认。

这不是我们想要的人机协作。

真正好的设计应该是：

低风险的事情，让 Agent 自己完成；风险真正升高的时候，再让人介入。

普通查询，可以自动。

读取非敏感资料，可以自动。

生成草稿，可以自动。

可轻易撤销的小操作，也可以自动。

但对外正式承诺、付款、合同、大额采购、生产环境变更，就要提高控制级别。

有些明显不应该让 Agent 做的事情，直接 Block。

所以一个生产级 Agent 的目标从来不是：

Automation = 100%。

而应该是：

该自动的充分自动，该停的必须停。

“确认”和“审批”，其实不是一回事

这两个词在产品里经常被做成同一个按钮。

但它们背后的责任完全不同。

比如你自己对 Agent 说：

“帮我给 John 发邮件，说会议改到下午三点。”

Agent 写好以后问：

“现在发送吗？”

你说：

“发。”

这叫 Confirmation。

因为动作本来就是你要求它做的。

系统只是在真正影响现实之前，再确认一次：

你确实要把这件事变成现实，对吧？

但另一种情况：

采购 Agent 自己分析完以后告诉采购负责人：

“我认为应该批准 Supplier B 的订单，是否同意？”

这不是简单确认。

这是 Approval。

因为这一次的业务决定，是 Agent 根据分析主动提出的。

真正拥有这项业务决定权的人，需要判断这条建议能不能生效。

看起来都只是“找个人点一下”。

实际上完全不是一回事。

人工审批最怕的，不是没人审批，而是人根本不知道自己在批什么

假设系统只弹一句：

是否批准 PO-2026-0813？

下面两个按钮：

批准。

拒绝。

看起来已经 Human-in-the-loop 了。

但这种审批几乎没什么价值。

因为正常人的第一反应一定是：

哪家供应商？

多少钱？

为什么选它？

第二名差多少？

币种统一了吗？

MOQ 检查了吗？

运费算进去了吗？

包装计价基础一致吗？

有什么风险？

所以真正有价值的人工介入，不是：

把最后一个按钮交给人。

而是：

把做决定需要的上下文一起交给人。

一个好的 Approval Request，至少应该包含：

• Proposed Action：准备做什么；
• Target：作用在哪个对象；
• Impact：金额、范围和后果；
• Reasoning Summary：为什么建议这么做；
• Evidence：关键证据；
• Verification：哪些检查已经通过；
• Policy Trigger：为什么这一步需要人工审批。

这时候人做的才是判断。

不是替 Agent 点鼠标。

把整个采购案例重新跑一遍

用户给 Agent 一个任务：

“分析这 20 家供应商报价，选择最优方案。如果结果明确，就处理。”

Agent 开始工作。

它加载上一课已经更新过的 Supplier Quote Skill。

这个 Skill 已经知道：比较报价之前，不要只看单价，而要先统一币种、单位、MOQ、贸易条款、运费、税费和 Packaging Basis。

最后 Agent 得到结果：

Supplier B 的真实综合成本最低。

比第二名低 8.7%。

Verification 也通过。

注意。

到这里我们只证明了一件事：

Agent 的建议是合理的。

还没有证明另一件事：

Agent 有权批准订单。

于是 Agent 不直接执行。

它生成 Proposed Action：

建议批准 Supplier B。订单金额 184,300 美元。统一所有口径后，Supplier B 的真实综合成本最低，其他约束满足要求，关键检查已通过。

系统接下来检查采购规则。

发现这个金额已经超过自动处理边界。

于是 Agent 停下来。

完整分析被送到采购负责人。

负责人审核以后同意。

系统这时才真正执行订单批准。

然后 Verification 再去 ERP 检查订单状态是否真的已经改变。

整个链路才算完成。

采购案例：从分析到授权执行

最值得注意的是：

Agent 的能力一点都没有减少。

读取报价是它做的。

计算是它做的。

比较是它做的。

检查也是它做的。

建议依然是它提出的。

我们只是没有让：

“我认为应该批准”

直接变成：

“所以我现在就批准。”

这就是第十三课真正要建立的边界。

治理的不只是 Tool Call，而是所有“状态变化”

如果这一课只停留在：

发邮件之前审批。

付款之前审批。

删数据库之前审批。

那其实还没有碰到最深的地方。

还记得第十二课吗？

Agent 已经可以从真实任务里学习。

它发现原来的 Supplier Quote Skill 漏掉了 Packaging Basis。

它生成改进方案。

拿历史任务重放。

结果新的方法确实更好。

那么下一步呢？

是不是应该自动把这个 Skill 上线？

不一定。

因为：

“已经验证有效”和“允许进入生产环境”，不是同一件事。

一次邮件发送，只影响一次任务。

但一个错误 Skill 被激活以后，可能影响未来几百次任务。

所以：

修改 Agent 的行为规则，本身也是高影响动作。

再往上抽象一层，你会发现真正需要 Governance 的，其实不是某一个 Tool。

而是：

任何会让现实发生状态变化的决定。

批准采购，改变商业状态。

发送客户邮件，改变外部沟通状态。

付款，改变财务状态。

部署程序，改变生产系统状态。

激活 Skill，改变 Agent 未来的行为。

修改 Policy，则更加危险：

它改变的是 Agent 未来“可以做什么”。

所以这些看起来完全不同的动作，本质上都在问同一个问题：

谁有权让这个变化发生？

最危险的情况：Agent 开始给自己扩权

假设采购 Agent 已经运行半年。

它发现过去 50 次大额订单审批，采购负责人最后全部批准。

于是它从历史数据里总结：

“这 50 次人工审批都没有改变结果，看起来这一步效率很低。”

然后它提出建议：

“以后 10 万美元以下采购，我可以自动批准。”

甚至它还认真做了 Validation。

拿过去 50 个 Case 重放。

全部没问题。

从 Learning Loop 的角度看，这条建议可能很合理。

但能不能让它自己修改权限？

不能。

把 Agent 换成人类员工就明白了。

员工跑来告诉老板：

“我过去 50 次申请你都批准了，所以以后我决定不申请了，我自己批。”

这当然不成立。

因为：

过去一直被批准，不代表批准权已经转移给你。

Agent 可以发现审批规则也许太严格。

可以给出历史数据。

可以模拟规则变化会造成什么结果。

可以提出建议。

但最终是否扩大 Agent 的权限，不能由 Agent 自己批准。

否则一个越学越聪明的 Agent，最后很可能把自己的安全边界一起学没了。

为什么真实企业一定会做职责分离

假设一个 Agent：

自己提出付款。

自己判断风险。

自己判断“不需要审批”。

自己执行付款。

最后又自己检查：

“付款成功，任务完成。”

技术上看，模块全都有。

Planning 有。

Policy Check 有。

Execution 有。

Verification 也有。

但本质上：

从头到尾还是同一个主体说了算。

真实企业为什么会把申请人、审批人、付款人、审计人拆开？

不是因为大家特别喜欢流程。

而是因为后果足够大以后：

不能让同一个人既当运动员，又当裁判。

Agent 系统也一样。

职责分离：不要让同一个主体既当运动员又当裁判

真正意义上的控制，不是模块多。

而是决定权没有集中在同一个主体手里。

到这里，Agent 出现了第三个 Loop

第十二课已经有两个 Loop。

第一个：Execution Loop。

它解决的是：

这一次任务怎么做完。

第二个：Learning Loop。

它跨越多个任务，解决的是：

这次发生的事情，怎样让下一次做得更好。

第十三课开始出现第三个 Loop：

Governance Loop。

它解决的是：

Agent 提出动作以后，先判断影响和风险，再根据规则决定自动执行、用户确认、业务审批或者直接禁止；执行以后留下 Audit，再用真实运行结果反过来检查规则是不是合理。

三个 Loop，各管一件事

三个 Loop 的职责可以压成三句话：

Execution：把事情做完。

Learning：以后做得更好。

Governance：即使越来越会做，也不能因此越来越越权。

这才是 Agent 从“聪明工具”走向“生产系统”的关键一步。

写13_governance.py时，真正重要的不是代码量

这一课当然可以写代码。

但真正应该实现的，不是一个巨复杂的审批系统。

而是一条清晰的架构边界。

以前你的代码思维可能是：

Planning 得到动作 → 执行动作

现在应该变成：

Planning 得到建议动作 ↓ Policy / Risk Check ↓ Auto / Confirm / Approve / Block ↓ Execution ↓ Verification

如果需要 Approval，就停在这里。

如果明确 Block，就不执行。

只有被允许的动作，才交给 Executor。

所以完整一点的任务链是：

用户目标 → Planning → Proposed Action → Policy & Risk Check → Execution → Verification

Planning 负责的是：

“我认为下一步应该做什么。”

它不再天然拥有：

“那我就做了。”

这一点，比写多少行审批代码都重要。

Audit 从这一课开始真正重要起来

假设三个月以后有人问：

“为什么这张订单当时能被 Agent 处理？”

一个成熟系统不能回答：

“因为模型当时觉得可以。”

它应该能够重新还原：

• 谁发起任务；
• Agent 当时看到了哪些数据；
• 加载了哪个 Skill 版本；
• 为什么推荐这个供应商；
• Proposed Action 是什么；
• 当时使用哪一版 Policy；
• 为什么自动通过，或为什么要求 Approval；
• 谁批准；
• 最终执行结果；
• Verification 是否通过。

你会发现，Audit 保存的已经不只是：

发生了什么。

而是在保存：

这个决定为什么能够发生。

这才是生产系统里真正有价值的审计。

Skill 和权限规则，必须是两个系统

现在重新看 Skill 和 Policy，你会发现它们根本不是同一种东西。

Skill 告诉 Agent：

这件事怎样做得更好。

例如：

比较供应商报价之前，要先统一各种价格口径。

Policy 告诉 Agent：

你最多可以自己做到哪里。

例如：

即使已经确定某个供应商最优，只要金额超过边界，就仍然需要审批。

所以：

Skill → Capability

Policy → Authority Boundary

一个系统在提升能力。

另一个系统在约束决定权。

这两个东西必须分开。

因为：

越来越聪明，绝不意味着应该自动获得越来越大的权力。

Demo Agent 和企业 Agent 的分水岭

Demo 最喜欢问：

Agent 能不能一个人把整个流程跑完？

到了真实企业，问题应该换成：

Agent 应该自己跑到哪一步？

只差几个字。

架构完全不同。

有些步骤本来就应该全自动。

有些步骤 Agent 可以做完 95%，最后 5% 交给真正有决定权的人。

有些步骤 Agent 只能给建议。

还有些事情，从一开始就不应该允许它做。

所以真正优秀的 Agent，不是永远只会：

继续执行。

继续执行。

继续执行。

它还必须拥有另一种能力：

知道什么时候应该停。

有时候，一个 Agent 最正确的下一步，不是再调用一个 Tool。

而是说：

“分析已经完成，但这一步超出了我的决定权，需要你批准。”

这句话没有“全自动 Agent”那么炫。

但从生产系统角度看，它高级得多。

如果第十三课只记住一个判断方法

以后每次准备给 Agent 增加一个动作，都问三个问题。

1. 它会不会做？

这是 Capability 问题。

2. 它做得对不对？

这是 Verification 问题。

3. 就算它会做，而且做对了，这件事情应该由它决定吗？

这才是 Governance 问题。

可以把它压成最后一个公式：

Production Agent = Capability + Verification + Governance

少任何一个，都很难真正进入生产环境。

最后，把前十三课重新串起来

Memory 解决的是：

过去我知道什么。

Skill 解决的是：

这类事情以后应该怎么做。

Planning 解决的是：

面对当前目标，下一步先做什么。

Verification 解决的是：

我刚才到底有没有真的做对。

Learning Loop 解决的是：

这一次的真实经验，有没有资格改变下一次的行为。

而第十三课终于补上最后一个问题：

即使我知道怎么做，也确定应该这么做，这一步到底是不是由我决定。

到这里，一个 Agent 才不只是“模型 + Tools”。

它开始真正接近生产系统。

因为真实世界从来不只关心你聪不聪明。

还关心：

谁能做什么。

谁能决定什么。

什么情况下必须停。

第十二课教 Agent：

不是所有经验都值得学。

第十三课要再教它一个更难的东西：

不是所有正确的决定，都应该由你来做。

真正成熟的 Agent，不是没有边界。

而是它非常清楚自己的边界在哪里：

边界以内，尽可能自主。

越过边界之前，可靠地停下来。

这才是 Agent 真正开始具备生产价值的那一刻。