边界不清的 Agent 项目为什么容易失败

01核心判断CORE JUDGMENT

从公开的项目复盘和行业观察看，失败的 Agent 项目里很少见到"模型能力不足"这个死因。更常见的路径是：演示很成功，试点很顺利，接入真实业务后出了一次没人能解释的错，信任崩掉，项目搁置。出问题的那一环，几乎总能归到五件被省略的事情上：权限、异常、审核、日志、回退。

这五件事有一个共同点：它们都不增加演示效果，都在为"出事的那一天"做准备。于是在赶进度的项目里，它们天然是被牺牲的对象——直到出事的那一天真的到来。

所以核心判断是：Agent 项目的成败在开工前就大半决定了，取决于团队把边界当成设计输入，还是当成上线后再补的手续。能画清边界的团队，才能把 demo 变成可以承担后果的系统。

演示环境是一个被剪裁过的世界：输入是准备好的，路径是排练过的，出了错可以重来，没有真实的客户、真实的钱和真实的责任人。在这个世界里，边界确实没有用武之地——没有人会越权，没有异常需要回退，没有后果需要追责。

真实业务是另一个世界。输入会脏，接口会挂，用户会用你没想过的方式使用系统，而每一个对外动作——一封邮件、一次报价、一条写库——都有人要为它负责。原型和生产系统的鸿沟，本质上不是功能差距，而是后果承担能力的差距。

这解释了一个常见现象：为什么"再加几个功能就能上线"的项目总是上不了线。缺的不是功能，是那五件在演示里看不见的东西——而它们没法"加上去"，只能设计进去。

模型接上工具之后，能力边界会突然变得很大：能读文件就可能读到不该读的，能发请求就可能发到不该发的，能写库就可能覆盖不该覆盖的。权限设计要回答的问题不是"Agent 能做什么"，而是"在这个业务里，它应该被允许做什么"。

实践上就是最小权限：工具用白名单而不是黑名单，读和写分级授权，高风险动作单独审批，环境之间隔离。这些做法在传统系统工程里是常识，在 Agent 项目里却常被"先跑起来再说"跳过——而 Agent 恰恰比传统系统更需要它们，因为它的行为空间更难穷举。

一个有用的自检：把 Agent 当成一个刚入职、能力很强但完全不了解公司的新人。你不会在第一天给新人生产库的写权限，也就不该给刚上线的 Agent。

边界不清的项目通常只设计了成功路径，失败靠"应该不会吧"兜底。但长任务、多工具、真实输入的组合意味着失败不是小概率意外，而是日常运行的一部分。失败路径需要和成功路径同等级别的设计：哪些错误重试、哪些升级给人、哪些直接停下。

回退能力决定了系统敢做什么。可以撤回的动作（生成草稿、打标签、写入暂存区）可以放给 Agent 大胆做；不可撤回的动作（对外发送、改生产数据、付款）必须在前面设人工确认。动作按可撤回性分层，比按"模型准确率"分层可靠得多——准确率再高，也兜不住那一次撤不回来的错。

没有回退设计的系统，出错之后只剩两个选项：硬扛后果，或者整个下线。常见的结局是后者，这就是"一次事故杀死一个项目"的机制。

Agent 的输出进入业务动作之前，要经过一个明确的问题：谁确认的？系统里要能回答——这条建议是 Agent 给的，这个修改是某人做的，这次发送是某人批准的。审核不是给流程添堵，而是给责任找落点；没有落点的责任，最后会落在整个项目头上。

日志是审核的另一半。没有日志，复盘只能停留在"模型当时为什么这样说"的猜测；有日志，每一次事故都变成一次系统改进的输入。要留的不只是模型的输入输出，还有工具调用、权限判定、人工修改和最终动作——一条能从结果回溯到起点的链。

这条链平时没人看，出事时值回全部成本。它也是 Agent 项目和"接了个 API 的脚本"的分界线：前者可以被审计，后者只能被信任——而信任在第一次事故后就没有了。

把边界理解成"法务要求的免责文案"，是对它最大的误读。边界是产品能力：权限分层让系统敢接更多工具，回退设计让系统敢做更多动作，审核闭环让系统敢进更核心的流程。边界画得越清楚，系统能安全触达的范围反而越大。

这也是为什么"能画清边界"是一个团队工程成熟度的信号。它说明团队想过失败、想过责任、想过这个系统在最坏情况下的行为——而这些思考本身，比任何框架选型都更能预测项目的存活率。

邮件场景的具体版本见 N-001：同样的五件事，落到"业务 Agent 该不该自动发邮件"这个问题上，答案自然浮现。