摘要Agent 本地跑通不等于生产可靠。本文给三道闸——架构分层、可观测、人审——把想和做拆开、给每一步留审计轨迹、把不可逆操作锁在人审之后并用 ThinkingBox 的静默失败数据说明为什么不能信 Agent 那句done。你本地把 Agent 跑通了产品说一句上生产。刚开始挺顺。后来客户来投诉说数据状态不对。你翻日志Agent 回得漂漂亮亮“任务已完成。”这就是 demo 和生产之间那条沟。前面几篇我写过工具怎么管、边界画在哪、模型怎么路由那都是在Agent 怎么干活里打转。今天换个位置Agent 进了生产怎么不让它裸奔。三道闸架构、可观测、人审。demo 能跑不代表生产可靠你可能会问本地都跑通了上线怎么会翻车Gartner 有个预测常被引用到 2027 年底超过 40% 的代理式 AI 项目会被取消。原因列出来——成本不清、业务价值不明、风控不足。注意没有一条是模型不够聪明。更朴素的数学在另一边。一个单步正确率 95% 的 Agent已经算不错了。给它一个二十步的流程拉工单、查客户、核权益、查三个系统、对账、起草回复、发出去。0.95 的二十次方约等于 0.36。这个优秀 Agent完整跑对这个活的概率只有三成六。demo 跑的是 happy path一次数据还是你自己挑的。生产跑的是长尾几千次还有半夜的脏数据和被气疯的用户。这条沟填的不是模型能力是工程纪律。架构分层把想和做拆开很多 Agent 一上来就把模型推到最前面模型直接调工具、直接改库、直接发邮件。问题不在于模型不会想而在于它的想和做是同一股力——它觉得自己做对了就真去做了。把推理层模型加循环负责想)和确定性执行层工具、权限、状态负责做)分开是治理的第一道闸。模型只发意图“把订单改成已发货”。执行层来校验这个意图有没有权限、参数对不对、改完要不要留痕。模型不再直接碰生产资料它递的是一张工单。授权能只写在 prompt 里吗我之前写过 SKILL.md 里写不下授权根因就在这prompt 里的你不可以删库挡不住一个被注入的指令。要把权限落到工具契约上每个工具调用带一个最小权限的 token零信任思路是这次调用被授权不是这个 Agent 被授权。可观测给 Agent 装一条审计轨迹Agent 跑飞了第一反应都是查日志。但多数 Agent 的日志只有模型的自言自语和工具返回的片段串不起来它到底调了哪个工具、参数是什么、改了哪条记录、改之前什么样。怎么知道 Agent 到底干了什么可观测这道闸是让每一步都留痕。三个东西要抓牢链路trace一次任务里所有工具调用按时间串成一条线哪步慢、哪步错一眼定位。状态变更state diff重点看它改了什么而不只是它说了什么。成本cost把花销归因到具体任务而不是摊进一个全局 token 池。为什么不能信 Agent 那句done微软和 Hugging Face 刚发的 ThinkingBox 给了硬数据507 个有状态业务流程每个模型跑 20 次结果 67.24% 的失败跑完时没有任何工具报错——它是静默失败的数据库已经脏了回复还写得理直气壮。这个框架的评分标准就是以数据库终态为准而不是看对话文本。你生产里也该这么查别问 Agent 完没完去 diff 它留下的状态。人审哪些活必须人点头不是所有活都值得人审也不是所有活都能放手。把多自主落成一张分级表反而比一句关键时刻人工确认管用。必须人审的不可逆写操作打款、删库、对外发邮件、权限变更、合规敏感动作。这些错一次就要救火闸门值得设。可以放手的只读查询、草稿、内部低频操作。这类你让其自跑反而把人从疲劳里解放出来。那审批又防什么真正要防的不是该审没审是审了等于没审。微软 2026 红队报告里人为绕过审批闸门HITL bypass是被利用得最频繁的一类弱点——不是被黑客攻破是审批请求来得太密、给的上下文太少人变成了一个两秒点一次的自动盖章机。防线很具体给审批人看完整动作摘要加风险级加下游影响而不是一个孤零零的批准/拒绝再监控审批延迟和通过率如果某人两秒内通过了 95% 的请求那道闸已经失效了。三道闸怎么串成一条线分开讲是三道闸落到系统里是一条控制面。数据面跑业务Agent 发意图执行层干活。控制面跑治理每一次工具调用都过审计、过策略引擎判风险高风险的自动升级到人工。跑飞了不要让它空转——加熔断最大步数、成本上限、明确失败态到点就升人工而不是卡在那儿烧 token。这套结构和网络圈的控制面 / 数据面分离是同一个思路业务流别把治理逻辑搅成一团治理才有地方插手。不光是写代码的 Agent。客服 Agent 要改工单、财务 Agent 要对账、运维 Agent 要动线上配置——只要它碰到真实数据逻辑一模一样谁碰生产数据谁就得过这三道闸。Java 后端怎么落地如果你和我一样是 Java 后端别把它想得多玄。零信任 token用 Spring Security 或 Sa-Token给每个工具调用发一个 scoped token权限精确到这一次的这个动作。审计切面在所有工具入口统一加一个操作日志切面记谁、调了什么、改了哪条记录、前后值是多少。终态断言关键的写操作前加一条断言测试去 diff 状态而不是信返回码。之前聊过 Java 后端的四道门禁编译、契约、状态、链路那是质量门。今天这三道闸是治理门——权限、审计、人审。质量门保代码对治理门保动作可控两样都得有。最小可行治理清单列清 Agent 能碰的工具和数据把边界画出来。工具调用全部带最小权限 token别用Agent 被授权糊弄。每步留审计日志谁、调了什么、改了什么。关键写操作前加终态断言别信那句done。不可逆操作必须人审且给审批人完整上下文别让他当盖章机。上线前每个流程跑至少 10 到 20 次重复评测看 20/20 的全过率覆盖所有可能而不是一次通过率。Agent 能不能进生产不取决于它有多聪明取决于你给它装了几道闸。参考资料Microsoft Hugging Face. microsoft/thinkingbox。Shunyu Yao 等.τ-bench(2024-06). 最早提出 pass^k 指标并以数据库状态评分是 ThinkingBox 的方法前作。Microsoft AI Red Team.2026 Agent Failure Taxonomy.Gartner. 代理式 AI 项目预测逾 40% 将于 2027 年底前被取消主因为成本、价值与风控。Beyond the Leaderboard(2026-07). 多个综述文献、基准将 agent 失败聚为工具调用、规划、长程退化、多体协调、安全、评测有效性六类。作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。