AI Agent 不是员工替身：真正的分水岭，是能否对结果负责

凌晨一点，群里弹出一条消息：“部署已完成。”第二天早上，值班工程师发现服务没有上线，配置只写进了测试环境；一项补偿脚本还多跑了一次。没有哪个 Agent 偷懒，也没有哪一步完全失控。问题是它把一条看起来顺畅的执行轨迹，当成了一个已经交付的结果。

这类场景很快会成为越来越多公司的日常。AI 已经会写代码、读文档、调用浏览器、查数据库、跑测试、发起工单。它比过去的聊天机器人更像一个能动手的同事。于是，“把流程交给 Agent、让少数人监管”听上去顺理成章。

可真正的工作从来不只是把动作排成一列。工作要面对模糊的目标、临时变更、相互打架的规则、权限边界，以及失败后的代价。一个人能否被称作靠谱的员工，不取决于他会不会按按钮，而取决于他是否知道什么算完成、哪里不能碰、遇到不确定时何时停下、出了问题谁来收场。今天的 Agent 在前半段进步很快，在后半段仍然很不稳定。

别把“能做一步”误读成“能接管一件事”

理解 Agent 的一个简单办法，是把能力拆成四层。

• 第一层是回答。把信息组织成一段像样的文字、代码或建议。大模型在这一层已经非常强，很多时候比普通人快得多。
• 第二层是行动。调用工具、填表、搜索、写文件、提交代码、运行脚本。Agent 的“能干活”主要来自这里。
• 第三层是闭环。动作完成后，去外部系统确认结果；结果不对时找到原因、回滚、重试或升级，而不是只在对话框里宣布成功。
• 第四层是负责。在目标互相冲突、信息不完整、风险难以量化时，做出取舍并承担后果。

市场上最容易被夸大的，是把第二层的惊艳表现直接等同于第四层。一个 Agent 可以写出很好的 SQL，却未必理解这次查询会不会碰到敏感数据；可以修改一处代码，却未必知道它和三个月前的灰度策略相撞；可以连续调用十个工具，却未必知道第八个工具的返回值已经让原先的计划失效。

这不是“提示词再写好一点”就能抹平的缝。提示词能约束习惯，不能凭空生成组织记忆、清晰的权责、可回滚的业务流程和成熟的风险判断。真正需要补上的，是系统工程。

长任务不是把短任务简单相加

人们很容易被一次成功的演示说服：模型能查一个资料、改一个函数、订一张票，为什么不能连起来完成一整天的工作？难点恰恰在“连起来”。每多一个步骤，就多一次状态丢失、接口误解、权限变化、环境波动和错误累积的机会。

METR 对长任务能力的研究给了一个很直观的刻度。以人类完成同类任务所需时间衡量，当时测试中的前沿模型对人类少于四分钟即可完成的任务，成功率接近 100%；任务长度超过约四小时，成功率则低于 10%。这不是说模型四小时后突然“失聪”，而是说明可靠性不是线性下降。链条变长后，一个本来不大的失误会被后续动作放大。

因此，企业不该只问“它能不能做”，而应该问：“在什么成功概率下，它能稳定做多久？”“失败发生时，能否留下一条完整可追溯的证据链？”“这个失败是否可逆？”把这些问题问清楚，很多“全自动替代”的承诺会立刻从一个漂亮口号，变成一张可以工程化的任务清单。

多 Agent 最怕的，不是不会说话，而是接口没人负责

把一个 Agent 拆成一群 Agent，不会自动得到一支团队。UCL 一项对 1,902 次多 Agent 编程运行的测量，抓到了一个很现实的故障：八个步骤被一人一步地分开后，十次运行全部失败，卡在税费计算和最终格式化之间的舍入规则。每个 Agent 都能为自己的局部解释辩护，大家也反复讨论过这个问题，但没有任何一个角色拥有最后的接口决定权。

这比“模型变笨了”更值得警惕。人类团队靠会议、文档、负责人和经验，仍会把接口搞错；Agent 团队会以更快的速度、更低的摩擦复制同一种错误。消息越多，不等于共识越多；加一个名叫“协调者”的角色，也不等于真的出现协调机制。

Google Research 的受控评估得出了相近但更有用的结论：在可并行的任务里，集中协调的多 Agent 架构可以显著优于单 Agent；但在严格依赖前一步结果的连续任务里，所有测试过的多 Agent 架构都出现了明显下降。关键不在于“单 Agent 还是多 Agent”，而在于任务是不是能被真正切开，以及错误能否在交接点被拦住。

所以，正确的拆分单位不是“让不同 Agent 各干一段”，而是“让每一段都有明确输入、输出、验收者和退路”。没有这四项，所谓 Agent 团队只是把一个不稳定的长任务拆成更多不稳定的小任务。

代码产量很容易骗人

AI 编程最危险的指标，是提交量。代码行数、变更次数、工具调用次数都很显眼，也很容易被做进周报。可它们不等于用户拿到了价值。

Meta 的组织转型试验把这个落差摆在了桌面上。路透社看到的内部材料显示，AI 使用高峰期，内部平台和基础设施的代码变更同比增长 220%，真正送达用户的新功能或升级只增长 36%；重大技术与安全事件同比增加 40%，员工用于“救火”的时间增加 70%。这些数字是针对一家公司的内部情境，不能直接套到所有团队。但它们清楚地说明了一件事：自动化会先放大动作，再决定是否放大价值。

如果一家公司的验收、测试、权限和回滚能力没有同步升级，Agent 只会让它更快地产出待核验的东西。人并没有消失，只是从创建者变成了审稿人、排雷者和事故处理者。表面上省下来的操作时间，可能被验证、返工、沟通和修复吞掉。

“只是循环”也说错了重点

面对炒作，另一种说法也常见：Agent 不过是 for 循环、while 循环，反复找案例、调工具、继续往下跑。这个说法抓住了一个关键事实：当前系统没有人类式的自我意识，也没有天然的价值判断和责任感。它不会因为“这件事影响很大”就自动形成可靠的审慎。

但把它贬成普通循环，同样看轻了风险和价值。Agent 的模型部分能在不完全相同的情境中归纳，工具部分可以实际改文件、调接口、执行命令。它的错误因此不只是聊天框里的错别字，也可能是生产环境的变更、客户数据的暴露或一笔无人注意的成本。正因为它并非玩具，才更不能用玩具级的治理方式来部署。

现阶段最值得做的，不是裁人，而是重做任务

真正能从 Agent 获益的团队，通常不是最早宣布“无人化”的团队，而是最认真重画工作流的团队。可以从下面五件事开始。

• 先给任务分级。低风险、可复核、可回滚的任务，优先交给 Agent：资料初筛、测试草稿、文档整理、代码建议、内部工单路由。资金、隐私、生产权限、法律承诺和对外发布，应保留明确的人类闸门。
• 把“完成”写成外部证据。不要接受一句“已经处理”。要求链接、文件差异、测试报告、数据库回执、监控截图或审批记录。一个 Agent 可以生成结论，但系统必须能证明结论已经落地。
• 把验收与执行分开。执行 Agent 不应该自己宣布成功。至少要有独立验证步骤；高风险场景还需要不同权限、不同上下文甚至不同模型的复核。
• 为异常预留升级路径。当输入缺失、规则冲突、置信度不足、操作不可逆或成本超阈值时，系统应停下来找人，而不是为了“自主”硬做下去。会停，比会继续更难，也更值钱。
• 改掉只看效率的报表。除了节省时间，还要持续记录一次通过率、人工复核率、返工时长、事故率、回滚率和单位有效结果的成本。没有这些，任何“替代了多少人”的结论都只是猜测。

别急着给 AGI 排日期

AGI 的定义尚未统一：有人强调跨领域的能力，有人强调经济工作表现，也有人强调独立学习与自我改进。把一个尚无共同标准的概念，当作眼前组织重构的唯一依据，并不稳妥。

更合理的判断是两句话同时成立。第一，AI 能力会继续增长，长任务可完成的范围也可能以很快的速度扩展；把它当成一阵噪音，会错过真实的生产力变化。第二，能力曲线不是组织替代曲线。技术要进入岗位，需要的还包括数据权限、流程标准、责任划分、法律边界、客户信任和人类对异常的处理能力。

未来几年，最稀缺的不会只是“会写提示词的人”，而是能把业务目标翻译成可验收任务、能为 Agent 设边界、能从证据里看出问题并承担最后责任的人。Agent 可以是很强的执行层；在它能稳定地识别自己的不确定、知道何时停手、能解释并承受错误之前，把它当成完整员工，仍然太早。

参考来源

• UCL：When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding
• Google Research：Towards a science of scaling agent systems
• METR：Measuring AI Ability to Complete Long Software Tasks
• Reuters：Meta Project OT 调查报道