锚点：Door-Lock Rechecking — LLM 在多次独立实验中对同一关键产物自发重复提交，prompt 中没有此指令。

在一个多 Agent 协作系统里，我们观察到一个没人教过的行为：

Agent 在完成一份关键产物后，会再次调用提交工具提交同一份文件——内容没有变，哈希 完全相同。这个动作没有任何指令要求它这么做。

你出门后，会不会停下来，转身，再拧一下门锁确认上了？

这不是记忆力的问题。

工程复盘说明：本文基于有限样本的复现与观察，重点是总结可被提前捕捉的失败模式， 不构成模型榜单或通用能力排名。

不同的大模型不只是“做得不一样”。在同一套多智能体协议约束下，它们的协作方式 也会不一样。

我们在完全相同的协议约束下跑了 54 次多智能体会话，覆盖 4 种提供方配置。结果呈现出 可复现的“行为指纹”：在这类场景里，协议合规（在正确的时间发出正确的协议信号） 往往是区别于“原始能力”的关键变量。

验证全通过，我们一集成就崩了。

日志里没有任何异常。

（工程复盘：基于有限样本的复现与观察，结论未必可泛化。）

我们的多 Agent 协作系统有一套完整的验证协议：Agent 生产代码，下游 Agent 验证，验证通过后冻结产物。整条链路运行良好——事件日志里全是 pass，流程三轮稳定收敛。

然后我们把六个 Agent 的产物拼在一起运行，游戏直接崩溃了。

日志里没有任何异常。

问题#

我们研究的系统是一个多 Agent 协作平台。六个 Agent 各自负责一个模块（物理引擎、关卡数据、玩家控制、敌人行为、游戏状态、集成入口），通过一套结构化协议协作：

1. PRODUCE – 每个 Agent 生产自己的代码模块
2. VERIFY – 下游 Agent 验证上游的产物
3. FREEZE – 系统根据验证结果决定是否冻结产物

所有协调事件写入一个共享事件日志。我们对这条日志做实时分析，计算协作健康度指标，检测失败模式。

在两次独立运行中，我们遇到了同一类致命问题：

第一次（Run 1）： Agent B 实现了 loadLevel() 函数，返回关卡数据时做了"归一化"——只保留旗帜的 {x, y} 坐标，丢弃了 width 和 height。Agent E 的 checkWin() 用 AABB 碰撞检测判断通关，需要 flag.width 和 flag.height。flag.width 是 undefined，flag.x + undefined 等于 NaN，碰撞判定永远为 false。结果：游戏可以运行，但永远无法通关。

第二次（Run 2）： Agent E 实现了 getDifficulty() 函数，返回一个对象 { speedMultiplier: 1.0, senseMultiplier: 1.0 }——从设计角度看完全合理，对象比单个数字更具扩展性。Agent F 的 game.html 拿到返回值后执行 difficulty.toFixed(1) 显示难度。对象没有 .toFixed() 方法，TypeError 抛出，构造函数中断，游戏循环未启动。结果：打开页面只有蓝色天空背景，无任何游戏元素。