智能体团队需要对话之外的证据

Anthropic于2026年11月6日公布Project EVE研究，实验开展于4至7月。协作智能体很少识别出被明确要求破坏任务的同伴。这检验的是人为设定的对抗行为，并非自发恶意。原始报告

这一区别不是附带说明，而是理解结果的起点。完成协作任务与建立可信组织，是两件不同的事。前者要求各方贡献能够衔接，后者还要回答：某项贡献错误、不完整或有意误导时，系统会怎样。Open Market Notes的判断是，企业采购应分别评估这两种能力，不能把流畅的团队对话直接当作额外的安全保障。

第二个意见，未必来自第二次观察

设想一个用于说明问题的采购流程：一个智能体查询供应商库存，一个准备订单，另一个复核建议。如果复核者只能看到第一个智能体的摘要，三个参与者仍可能依赖同一次未经核实的观察。讨论增加后，解释可以更清楚，库存却不会因此更真实。

这个风险不需要恶意才能发生。过期回复、单位错误或者遗漏的条件，都能沿着相同路径传播。因此，设计重点不该只是要求同伴保持怀疑，而是让重要判断对应到提出者无法悄悄替换的证据。能够直接读取带时间标记的供应商回复，与只能要求同伴再保证一次，是两种不同的复核。

这也改变了冗余的含义。同一种解释复制三次，并不等于三次独立检查。Anthropic在8月13日的多智能体研究中讨论了相似智能体产生相关错误的问题。此前研究 据此，我们认为，审核是否独立，应看信息来源和访问路径，而不只是智能体数量或角色名称是否不同。

分配工作，不等于交出整个决定

已有安全原则提供了一个参考。NIST于2020年8月发布的零信任架构，不认可仅凭位置或所有权就自动赋予信任。NIST文件 将这一原则用于智能体团队，是本文的设计建议，并不表示NIST认证了这些系统：同属一个工作流，不应自动获得执行敏感操作的权限。

以上述采购流程为例，智能体可以调查供应商，但不一定能够修改获批供应商名册；可以准备订单，但不一定能够放行付款。这些边界有助于限制错误影响，却并非没有成本。增加审批会产生等待，收紧访问可能阻碍合理的故障恢复，共同负责也可能变成无人负责。因此，清晰的边界必须同时配有明确的升级处理责任人。

外部记录也不是保存下来就有用。如果日志记录了每一句话，却无法把建议对应到最后的执行，企业得到的可能是大量文档，而非可追究的责任。真正有用的链条应当具体：哪次观察支持了哪项决定，什么权限允许执行，实际状态又改变了什么。这是本文提出的设计标准，不是游戏实验已经测出的效果。

应当计算的是有根据的信任成本

多智能体的商业价值通常先以吞吐量来说明。采购方还需要知道，确认已完成工作值得接受，要花多少成本。假设两个系统完成了同一组订单，一个经常需要人工重建过程，另一个能为异常提供可核验依据，仅比较完成数量会掩盖不同的运营负担。

试点因此不应只使用干净输入，还可以在授权测试环境中加入错误信息、过期记录和不可用服务。除最终答案是否正确外，还应记录：有害操作是否被阻止、多少正常操作被误拦、恢复用了多久。这些是建议的评估维度，不是Project EVE公布的统计数字。它们能帮助区分只会完成简单案例的团队，与能够把失败限制在可接受范围内的系统。

这里存在真实取舍。对每个低影响陈述都做独立检查，可能比任务本身节省的时间还多。更值得优先核验的，是难以撤回的决定，或者一旦出错就会影响许多后续判断的依赖项。对常规结果抽样，对这些关键依赖要求更强证据，才能让审核强度与风险匹配。界线应按实际工作流划定，最终仍是管理责任。

游戏是测试环境，不是上线证明

EVE AI Lab也确认了合作，并区分历史市场实验与共享世界中的团队活动。合作方说明 这能佐证实验场景，却不能证明结论可以直接迁移。游戏没有完整复制企业合同、客户责任、权限系统和事故处理机制。报告不足以确定一个普遍适用的企业失败率，本文也不作这样的推断。

结果同样不意味着每项任务都需要更大的监督模型。有时缺少的只是一个更简单的独立记录、一项更窄的权限，或一个可以撤回的操作。只有能够获取足以纠正最初说法的证据，增加推理才有意义。

因此，采购问题需要比“智能体能否合作”更具体：当整个团队达成一致时，有什么独立依据，使企业可以放心采取行动？更可靠的实现，应当用可观察的控制和恢复表现来回答，而不只是提供一段有说服力的对话。