Agent 的下一道门槛不是“能做什么”，是“敢让它做什么”

过去一年，Agent 领域的竞争集中在两件事上：接更多工具，跑更长的任务。厂商比的是“能做什么”。但在企业里，Agent 项目卡住的地方往往不在这里。一个能自动发消息、改工单、回写系统的 Agent 做好了，业务部门问的第一句话是：出了事算谁的？这个问题不解决，能力再强也只能停在演示。

问答、检索、起草这类只读的用法，错了成本很低，人看一眼，重问一次就行。写入类动作不一样：消息发出去收不回来，字段改了下游已经在用，通知打出去客户已经收到。事后的审计日志能告诉你发生了什么，救不回已经发生的事。

所以企业敢不敢让 Agent 动手，取决于两件事有没有写清楚：它在什么条件下可以做什么，以及出了问题怎么止损。写不清楚，保留人工审批是唯一理性的选择；写清楚了，人工审批可以只留在真正需要的地方。这也是我们的一个基本判断：保留人工闸门不是自动化程度不够，而是约束的体现。

我们主张，每一个交给 Agent 的写入类动作，上线前都要填满五个字段。签名：输入什么对象，产生什么后果，是读还是写。前置条件：哪些判断必须为真，比如客户身份已核验、数据在有效期内。人工闸门：哪些情况必须转人工，谁有权批准；它是一个配置项，不是流程图上画的一个框。幂等键：同一个对象、同一个动作重复触发时怎么办，防止一个客户被触达两次。爆炸半径：单次运行、单日、单账号允许执行的动作上限，是失控时的止损阀。

五个字段填不满，说明我们对这个动作的理解还没到能交给机器的程度。填满以后，业务方签的不是一段抽象的定义，而是一张例子表：这几种情况该执行，这几种不该，那几种转人工。争议在具体的行上发生，不在定义的措辞上。例子表同时就是回归测试：定义一改，签字失效，重新跑一遍。

动作定义好了，新版本怎么放出去，我们用四道关，缺一道不放量。影子运行：新版本只算不发，看它想对谁做什么。干跑对比：新旧版本的结果逐条比对，差异逐条解释。灰度放量：小比例真实执行，盯着批准率、驳回率和投诉率。版本差异：说清新版本会多触达谁、少触达谁，业务方看得懂才签字。

把控制放在前面，是因为触达类动作一旦发出就不可撤回；控制放在事后，只剩追责。

以一条常见的风险预警处置链路为例：风险发现、信息核验、分层触达、人工处置、审计回写。对照上面的做法，每一步先声明对象和动作，线索和打分、客户身份和核验是不同的对象；“数据源在有效期内”“已获得核验授权”“风险分层已确定”这些前置条件由规则判定，不由模型看着办；人工处置是强制闸门，触达有频次上限；回写业务系统前，先确认这个个案对应的是哪个系统的哪个主键；事后能重放当时为什么触达了这个人，用的是哪个版本的定义。

不同行业的人机分工落在同一条规律上。在保险、汽车金融、反诈这些场景里，标准问答、提醒、材料引导、状态查询交给 AI；涉及责任认定、资金和处置的决定，留给人或有授权的主体。

这不只是我们的判断。9 月 15 日发布的决策模型 Jev，把“模型知不知道自己哪次会错”当作自动化的前提，每个判断都附校准概率，为的就是让系统能按把握程度决定哪些交给机器、哪些交给人。Palantir 今年把本体的说法改写成“企业控制的对象、动作和权限”，讲的也是同一件事：本体的价值不在描述企业，在约束行动。模型侧和平台侧都在向行动层靠拢，企业侧要做的，是把动作的定义握在自己手里。

Agent 能做的事只会越来越多。决定它在企业里走多远的，是有没有一套让人敢签字的定义。我们认为这是企业 AI 未来两年最重要的基础工作，也是我们正在做的事。