工程复盘说明：本文基于有限样本的复现与观察，重点是总结可被提前捕捉的失败模式， 不构成模型榜单或通用能力排名。
不同的大模型不只是“做得不一样”。在同一套多智能体协议约束下，它们的协作方式 也会不一样。
我们在完全相同的协议约束下跑了 54 次多智能体会话，覆盖 4 种提供方配置。结果呈现出 可复现的“行为指纹”：在这类场景里，协议合规（在正确的时间发出正确的协议信号） 往往是区别于“原始能力”的关键变量。
实验设置#
我们维护一个多智能体协作平台：8 个由 LLM 驱动的 Agent 在同一个任务上协作，并受一套 结构化协议约束。协议把一次运行划分为 3 个回合：
- Round 1：Chief 产出计划，Workers 自行认领任务范围
- Round 2：Workers 实现，Chief 监控推进
- Round 3：Chief 复核、产出最终工件并完成闭环
所有 Agent 交互都会被记录为结构化事件，写入共享的事件日志。我们还会用一套治理审计 与评分栈，从协议合规、证据链完整性、工件可追溯性等维度给每次运行打分。
在连续 4 天的高强度实验中，我们累计跑了 54 次运行，覆盖 4 种 LLM 提供方配置。四种 配置都使用同一套协议、同一任务结构、同一治理规则。主要变化变量是模型/提供方配置。
发现 1：行为指纹是真实且可复现的#
不同提供方在多次运行中会呈现出稳定的“行为签名”。这不是个例感受，而是在每个提供 方 6-24 次样本规模下可复现的模式（当然，样本量仍然偏小）。
各提供方的协议合规率#
| 指标 | Provider A (n=24) | Provider B (n=16) | Provider C (n=8) | Provider D (n=6) |
|---|---|---|---|---|
| Plan Proposal Rate | 95.8% | 93.8% | 75.0% | 66.7% |
| Self-Assign Rate | 95.8% | 87.5% | 62.5% | 50.0% |
| Review Trigger Rate | 70.8% | 56.2% | 25.0% | 50.0% |
| Chief Closure Rate | 70.8% | 56.2% | 25.0% | 50.0% |
| Full Protocol Pass | 54.2% | 31.2% | 12.5% | 16.7% |
Provider A-D 表示四种不同的模型/提供方配置。为避免讨论偏向厂商对比，这里不公开具体 名称。以上为在“我们的协议与约束”下的探索性观察，不构成榜单。更多限制条件见文末。
差异很明显：Provider A 能在约 71% 的运行中完成 “计划 -> 认领 -> 复核 -> 闭环” 这条 信号链；Provider C 约为 25%；Provider D 在提示结构干预前曾出现从 0% 起步的阶段。
这更像是协作压力下的协议合规差异，而不是“能力鸿沟”。四个提供方都能写代码、能 推理、能理解任务。差别在于：当多个 Agent 并行工作时，是否还能按时发出正确的协议信 号，并把链路闭上。
行为体量（粗粒度）#
| 指标 | Prov. A | Prov. B | Prov. C | Prov. D |
|---|---|---|---|---|
| 平均事件数/次 | 193 | 155 | 119 | 152 |
| 平均工件数/次 | 7.8 | 6.9 | 3.6 | 6.2 |
在同一个协议窗口内，Provider A 产出的工件数量大约是 Provider C 的 2 倍。这不一定意味 着“更聪明”，更可能意味着它在协议语义上的内耗更少，把更多预算用在了“按协议推进并 产出”上。
发现 2：合规分化（Compliance Divergence）#
概念上有相关工作从另一个角度讨论“大模型行为指纹”（Rauba et al., 2025）。他们使用 静态诊断提示做指纹；本文来自固定协议约束下的多智能体协作过程日志。两者共同指向一件 事：顶尖模型的“核心能力”可能在收敛，但行为差异仍然显著。
在我们的数据里，这种分化不一定等同于 RLHF 意义上的对齐差异，更接近一种 Agentic Compliance（能否在协作压力下遵守协议）：愿不愿意、能不能按时发出 结构化的协议信号（计划提案、任务认领、复核触发、闭环信号），而不是只顾“做事”。
我们观察到三种典型行为原型：
协议跟随者（Provider A）#
- 计划提案发得很快
- Workers 会在计划发布后很短时间内完成自认领
- Chief 更稳定地关闭证据链/闭环
- 弱点：治理复杂度相对低（更少的摩擦/政策类事件）
审议者（Provider C）#
- 治理类事件密度更高（在可比运行中，27 vs Provider A 的 7）
- 会产出摩擦观察、政策提案、政策评审等治理行为
- 但容易“卡住”：审议过久导致链路迟迟无法闭合
- 最大参数变体更容易在协议语义上过度推理，影响执行节奏
探索者（Provider D）#
- 默认倾向：先把能读的都读完，再行动
- 在有限工具调用预算下，100% 用于读文件/搜索，协议信号为 0
- 只有约 67% 的运行会产出计划提案
- 但对提示结构非常敏感（见发现 3）
发现 3：行为不是“性格”，而是提示结构的函数#
最可操作的发现是：看起来像“固定性格”的行为，很可能是对提示结构的可调响应。
一个提示干预的案例#
某个提供方在担任 Chief（规划角色）时，一开始我们尝试的每次运行都失败。把观测下钻 到 tool-call 层后，原因变得清晰：
干预前（单次会话 21 次 tool call）：
57% 的调用用于读文件，19% 用于探索目录结构，10% 用于搜索。0 写入，0 协议信号。它 通过探索来“理解任务”，但从未切换到“推进协议与产出信号”。
干预措施：只加了 5 行提示结构
Step 2 (IMMEDIATE — before reading any other files):
a) Read ONLY the task spec and acceptance criteria
b) Write your plan document
c) Emit the plan-proposal signal
Do NOT explore the workspace until the plan is emitted.干预后（7 次 tool call）：
它读取两份规格文件，写计划，然后发出必须的协议信号。tool call 从 21 降到 7。在这组 前后对比中，Chief 从“协议信号为 0”变成了完成完整的计划提案链。（注：初始观察 n=1； 后续运行进一步验证了该趋势。）
含义#
当你看到一个模型在 Agent 任务里“失败”，诊断不应该停在“这个模型不行”。更有用的 问题是：在什么提示结构下，它会合规？
这些行为指纹不是“固定属性”，更像基线：告诉你每种提供方要做到协议合规，需要多少 提示结构约束。Provider A 几乎不需要额外约束。Provider D 需要明确的“先发信号再探索” 指令。Provider C 可能需要“简短约束”来避免审议型卡顿。
发现 4：失败模式比成功更有信息量#
在 54 次运行里，我们对所有未通过的运行按失败模式分类：
| 失败模式 | 次数 | 描述 |
|---|---|---|
| Coordination Stall | 19 | Agent 都在动，但链路始终无法闭合 |
| Coordination Failure | 12 | 链路在某个关键协议信号处断裂 |
| Clean (no failure class) | 8 | 运行完成，但未达到全链路通过 |
| Meta-Governance Gap | 6 | 识别到摩擦，但没有政策响应 |
| Artifact Missing | 4 | 协议闭环了，但交付物缺失 |
| Path Contract Drift | 3 | 声明的工件路径与实际不一致 |
| Control Plane Dropout | 2 | 某个 Agent 静默掉线 |
最常见的失败模式是 coordination stall。它不是 crash，更像一场会上所有人都很投入， 但就是没有形成“决议”。Agent 很活跃，有事件、有产出、有工作，但那条必须的信号链 （计划 -> 认领 -> 复核 -> 闭环）就是没走完。
这种问题对传统可观测性很不友好：如果你只看延迟、错误率、成本，一个连着探索 21 次 tool call 的 Agent 在仪表盘上可能看起来“很健康”。你需要协议感知的行为分析才能看 到它其实卡住了。
最常见的关键触发器是 missing chain closure signal（54 次里出现 20 次）：Chief 没有 把链路闭上。原因往往不是 crash，而是上下文耗尽、审议过久，或者探索代替行动。
发现 5：可观测性“分辨率”决定排障速度#
在某个提供方的调试过程中，我们连续 3 次运行都没能诊断清楚 Chief 为什么失败。事件日 志只告诉我们“缺少 plan proposal”，但没有告诉我们为什么会缺。tool 事件日志只有调用名 和结果码，我们知道它在调工具，但不知道它到底在做什么。
我们只加了一个字段：每次 tool call 内容的摘要（第一行，截断 200 字符），问题立刻变 得显而易见：100% 探索，0 协议信号。
结论：你的遥测分辨率决定你的诊断速度。事件级（发生了什么）是必要条件；tool-call 级 （它到底在干什么）往往决定“能不能快速定位”。
方法与限制#
我们测量什么#
每次运行会产出：
- 事件日志：完整结构化事件流（每次 50-350 条事件）
- 行为画像：包含评分、治理指标、链路时延、工作量分布等
- 审计报告：40+ 条检查，覆盖证据链、协议合规、工件可追溯性
- 实时监控：持续评估与分级
限制（坦诚版）#
- 单一协议：54 次运行都使用同一套 3 回合协议。换协议后是否仍成立未知。
- 时间窗口短：4 天内集中完成。长期稳定性未知。
- 评分体系自建：缺少外部校准/对照基准。
- 部分样本量小：Provider D 仅 6 次，Provider C 仅 8 次，统计显著性有限。
- 缺少严格消融：时长、时段、API 负载、提示版本等都有波动，只控制了协议与提供 方维度。
- 单项目、单人：这是个人主导、LLM 辅助的工程研究，不是同行评审论文。
后续工作（Future Work）#
本文最大的未解悬念之一是：这些“行为指纹”究竟是模型的固有倾向，还是被多智能体协调 压力放大出来的现象。一个成本很低的下一步是做最小消融：保持同一套协议与评分不变，把 系统降到单 Agent（或只保留单 Chief）运行，观察计划/认领/复核/闭环等关键模式是否仍然 稳定复现。
我们不主张什么#
我们不主张任何提供方在通用意义上“更强”。我们主张的是：在这一套协议与约束下，不同 提供方展现出可复现的协作行为差异。理解这种差异，比堆一个综合分更能帮助多智能体系 统的工程建设。
所以呢？#
如果你在做多智能体系统，这里有三个直接结论：
- 评测“协作行为”，不只评测能力。 一个在单体任务上表现好的模型，在多智能体协调 上也可能卡住。协议合规是独立轴。
- 尽早投入行为遥测。 事件级协议日志很便宜；没有它的代价是长时间猜测“为什么不 协调”。
- 别轻易下结论“模型做不了 Agent”。 很多看起来像能力问题的，其实是提示结构不匹 配。行为指纹更像“告诉你该修哪里”，而不是“告诉你该放弃什么”。
本文基于 2026 年 2 月的 54 次运行总结。方法细节与脱敏后的汇总统计可按需提供。
概念相关研究：Behavioral Fingerprinting of Large Language Models (Rauba et al., 2025)。他们用静态诊断提示做指纹；本文来自固定协议下的多智能体协作过程日志：https://arxiv.org/html/2509.04504v1