从“能做”走到“有权做”中间隔着的是生产级 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 的动作治理链路用户目标→Planning提出建议→Proposed Action待执行动作→Policy / Risk Check规则与风险检查↓Auto低风险Confirmation确认意图Approval业务授权Block明确禁止↓Execution只执行被允许的动作→Verification检查现实结果→Audit Log记录为何能够发生采购 Agent 分析以后认为应该批准 Supplier B。以前可能直接调用approve_purchase_order()现在它应该先生成一个 Proposed Action准备批准哪张订单供应商是谁金额多少为什么推荐用了哪些 EvidenceVerification 是否通过。然后不要执行。先进入规则检查。所以真正应该落到架构里的链路是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 AuthorityAgent 对一个搜索关键词只有 60% 把握可以让它搜。搜错了再换一个就行。但 Agent 对一笔 500 万美元付款有 99.9% 把握也不代表它可以自己付款。因为正确率高不会自动产生决定权。所以真正合理的自动化逻辑不是只看 Confidence而要同时看 Consequence。风险 / 置信度置信度较低置信度较高低风险可以尝试并通过 Verification 校验适合自动执行高风险停止、补证据或升级人工即使很确定也可能仍需审批这张表比“95% 就自动执行”更接近真实生产系统。真正好的 Agent不应该追求“什么都自动”讲到这里很容易走到另一个极端。既然 Agent 有风险那所有东西都找人审批好了。听起来安全。真正用两天就知道有多荒唐。读文件要你确认。搜资料要你确认。生成报告草稿要你确认。写一条内部备注也要你确认。最后人的工作没有减少。只是从“自己做”变成了不停帮 Agent 点确认。这不是我们想要的人机协作。真正好的设计应该是低风险的事情让 Agent 自己完成风险真正升高的时候再让人介入。普通查询可以自动。读取非敏感资料可以自动。生成草稿可以自动。可轻易撤销的小操作也可以自动。但对外正式承诺、付款、合同、大额采购、生产环境变更就要提高控制级别。有些明显不应该让 Agent 做的事情直接 Block。所以一个生产级 Agent 的目标从来不是Automation 100%。而应该是该自动的充分自动该停的必须停。“确认”和“审批”其实不是一回事这两个词在产品里经常被做成同一个按钮。但它们背后的责任完全不同。比如你自己对 Agent 说“帮我给 John 发邮件说会议改到下午三点。”Agent 写好以后问“现在发送吗”你说“发。”这叫 Confirmation。因为动作本来就是你要求它做的。系统只是在真正影响现实之前再确认一次你确实要把这件事变成现实对吧但另一种情况采购 Agent 自己分析完以后告诉采购负责人“我认为应该批准 Supplier B 的订单是否同意”这不是简单确认。这是 Approval。因为这一次的业务决定是 Agent 根据分析主动提出的。真正拥有这项业务决定权的人需要判断这条建议能不能生效。维度ConfirmationApproval谁提出动作用户已经明确要求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 检查订单状态是否真的已经改变。整个链路才算完成。采购案例从分析到授权执行120 家供应商报价输入↓2统一报价口径币种 / 单位 / MOQ / 条款 / 运费 / 税费 / Packaging Basis↓3Supplier B 最优领先 8.7%↓4Verification检查通过↓5Proposed Action订单金额 184,300 美元↓6Policy Check超过自动授权边界↓7采购负责人 Approval业务决定↓8ERP 执行 Verification确认状态已更新最值得注意的是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 系统也一样。职责分离不要让同一个主体既当运动员又当裁判Planning提出建议→Policy Engine判断边界→Authorized Human业务授权→Executor执行已授权动作→Verification检查现实结果→Audit还原决策链真正意义上的控制不是模块多。而是决定权没有集中在同一个主体手里。到这里Agent 出现了第三个 Loop第十二课已经有两个 Loop。第一个Execution Loop。它解决的是这一次任务怎么做完。第二个Learning Loop。它跨越多个任务解决的是这次发生的事情怎样让下一次做得更好。第十三课开始出现第三个 LoopGovernance Loop。它解决的是Agent 提出动作以后先判断影响和风险再根据规则决定自动执行、用户确认、业务审批或者直接禁止执行以后留下 Audit再用真实运行结果反过来检查规则是不是合理。三个 Loop各管一件事Execution Loop把这次事情做完Learning Loop让下一次做得更好Governance 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 → VerificationPlanning 负责的是“我认为下一步应该做什么。”它不再天然拥有“那我就做了。”这一点比写多少行审批代码都重要。Audit 从这一课开始真正重要起来假设三个月以后有人问“为什么这张订单当时能被 Agent 处理”一个成熟系统不能回答“因为模型当时觉得可以。”它应该能够重新还原谁发起任务Agent 当时看到了哪些数据加载了哪个 Skill 版本为什么推荐这个供应商Proposed Action 是什么当时使用哪一版 Policy为什么自动通过或为什么要求 Approval谁批准最终执行结果Verification 是否通过。你会发现Audit 保存的已经不只是发生了什么。而是在保存这个决定为什么能够发生。这才是生产系统里真正有价值的审计。Skill 和权限规则必须是两个系统现在重新看 Skill 和 Policy你会发现它们根本不是同一种东西。Skill 告诉 Agent这件事怎样做得更好。例如比较供应商报价之前要先统一各种价格口径。Policy 告诉 Agent你最多可以自己做到哪里。例如即使已经确定某个供应商最优只要金额超过边界就仍然需要审批。所以Skill → CapabilityPolicy → 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 真正开始具备生产价值的那一刻。