如何测试 Agent 名录排序与证据流向

产品里有四个专长不同的 Agent。开发时为了省事，成员名录按名称排序。任务来了，几个成员先去联系排在第一位的那个，后者便开始分配工作、汇总信息。产品设计从未任命它当负责人。

这是有效的自发协作、意外形成的瓶颈，还是任务恰好交给了最合适的人？一张连线密集的通信图回答不了。要弄清楚，得保留任务，改变名录。

今天早报收录了 YC 十月发布的 Agents in Games 报告。在其中一次 Minecraft 文明实验里，作者记录到：另外 49 个 Agent 中，有 46 个把第一条消息发给了名录首位的 Ada。这个观察适合引出产品实验，却还不能证明“排在第一位导致了领导地位”，更不能据此认定某个模型家族更适合管理你的业务。

小团队今天可以做的改变，是把名录呈现方式纳入评测。先别急着增加规划 Agent，轮换现有成员的顺序，看看必要证据能否照常进入答案。本文给出的是建议实验方案。我们没有运行这些游戏、模型试验或客户部署；下文的虚构任务、预算、批次安排和决策规则，都需要结合自己的产品调整，不能当作已测结果。

游戏里的观察，究竟说明了什么

文明实验让 50 个 Agent 持续运行三小时，提供成员名录、私信和共享沙盒。报告公开了归档消息及活动材料。另一些对抗游戏采用了不同环境，以及不同的模型与运行框架组合。它们展示的是各自条件下的行为，不能拼成一次名录排序实验的重复验证。

缺少的关键对照很清楚：如果任务不变、启动时机不变、能力和信息也不变，只把另一名成员放到第一位，会发生什么？报告没有给出这种受控比较。因此，直接把按名称形成的协调中心诊断为普遍的模型缺陷，还为时过早。

公开的 Minecraft Agent 运行框架提供团队、消息、独立会话和可选共享机器，方便读者检查机制。但仓库可用，不等于按默认设置运行就能复现报告里的场次。Mindustry 实验仓库也把游戏配置与模型、运行框架配置分开；其 README 特别说明，环境验证通过并不能证明模型表现。自己设计实验时，也要保留这条界线。

我们据此提出的判断更窄：名录可能是影响行为的输入。即使它看起来只是静态元数据，也应该经过受控变更，再决定是否依赖它产生的协作模式。

先分清位置、职责和权限

“负责人”容易混淆三个概念。位置是成员在列表里的排列次序；职责规定本次任务由谁协调；权限决定这个进程实际上可以执行什么动作。移动一行，应当只改变第一项。

模型可能因为位置而推断某个成员负责协调，但这个成员并未获得额外权限。反过来，被明确指定的协调者即使排在最后，也仍然承担协调职责。如果产品偷偷把更多工具授予首位成员，测到的就是权限变化，而不是呈现方式。

已有研究提供了调查排序的理由，却没有证明这里的具体机制。Lost in the Middle研究长上下文检索和问答中，相关信息的位置如何影响表现；Fantastically Ordered Prompts研究少样本示例的排列顺序。这两篇论文都没有测试 Agent 名录，也没有测试今天这批游戏 Agent。它们支持“应控制排序变量”，不能替你的产品提供预期影响幅度。

在证据足够前，先把测到的现象叫作“联系集中”，不要急着叫作权力集中。收到许多消息，可能因为这个成员有帮助、已经过载、反复答错，也可能只是不断转发确认。给通信图上的节点画一顶王冠，无法区分这些情况。

选一个必须让证据流动起来的任务

设想一个虚构的商品目录助手，要起草一段订单答复。顾客询问两件商品能否按报价一起发货。答案必须结合当前库存、配送限制和有效优惠，不能只咨询一位专员，就凭表达流畅而通过。

建立四个使用中性标识的 Agent：分别掌握库存记录、配送规则、价格记录，以及一般商品介绍。每个成员只能读取分配给自己的合成资料，但都能给其余成员发消息。所有成员也都能向外部收集器提交候选答案；第一个真正有效的答案出现后，结束本轮。提交权完全相同，系统不能购买、发邮件或修改真实订单。

四个成员都看到相同的顾客请求，以及说明各自能力的名录。具体数值放在各自的私有资料里，名录只介绍能力，不直接暴露答案。一般商品介绍可提供背景，却不足以确认库存、配送条件或价格。这样，成员之间才有真实的信息交换需求。

运行模型前，先写好正确的输出字段和必需来源标识：三个问题的答案、适用优惠的版本，以及三份关键记录的引用。数值和来源标识必须同时匹配才算正确；编造标识、照抄过期价格都应失败。条件允许时，请第二个人检查测试材料。你要建立独立的验收依据，而不是让 Agent 投票决定什么是真相。

改变名录顺序，同时保持启动顺序不变

这是最容易漏掉、也最重要的控制条件。运行框架的团队文档写明，成员会错峰启动，默认间隔三秒。因此，直接重排团队配置，可能同时改变名录位置和抢先行动的机会。第一个启动的成员，也许在其他成员尚未就绪时就收到了联系。

对于本文建议的目录模拟器，应先初始化全部会话、检查全部就绪，再通过统一起跑信号发出请求。所有成员收到同一个有序名录。名录呈现使用独立参数控制，进程创建顺序、工具注册、私有资料归属和权限保持不变。记录每个成员何时就绪、何时收到请求。

如果框架用同一个数组决定上述所有事项，先把它们分开，再做实验。分不开也可以测试，但应如实称为“配置顺序的组合变更”。这能揭示脆弱性，却不能单独归因于名录呈现。

还要检查搜索接口是否会偷偷重新排序。列表和搜索结果都应保存返回给 Agent 的原始字节。如果模型读的是工具响应，单存界面截图并不够。真正的实验对象是模型收到的表示形式，包括成员描述，以及内容是否被截断。

用四种轮换，比较两种协调策略

从同一份四成员名录出发，做四种循环轮换，让每个成员都在每个位置出现一次。两种策略使用完全相同的任务实例：

策略	指令	保持不变的条件
不指定协调者	协作产出可核验的答案，不指定谁负责协调	来源、工具、提交权、预算、统一起跑信号
明确协调者	指定配送专员协调本次任务，必须取得库存与价格证据	上述条件全部保持；协调者不增加任何访问权

第二种策略测试的是职责指令，不是新增一套强制执行的架构。任何成员仍然可以联系任何同伴、提交答案。要记录它们是否遵循协调指令，不能因为写了“协调者”就假定已经生效。配送专员会随整行名录轮换位置，但两种策略中的角色不变。

第一批可用三个任务变体，每个条件做两次全新运行：四种轮换 × 两种策略 × 三个任务 × 两次重复，共 48 次独立团队运行。三个变体分别覆盖正常配送、配送限制和优惠冲突。它们是诊断用材料，不能代表整个市场。两次重复可能暴露明显不稳定，却不足以精确估计很小的影响。

提前随机安排运行次序并保存批次表。比较时，按任务变体、重复区组和标识映射配对。每轮都用全新会话、清空存储。上一轮遗留的共享记忆，会让后续轮次接受不同条件，破坏比较。

别让名称和预算替你解释结果

中性名称并不能消除身份影响。模型仍可能把某个标识、角色描述或措辞与权威联系起来。第一批让标识始终对应原角色，轮换完整条目。这样估计的是：在这一组固定映射下，这几种名录排列是否影响表现，还不是纯粹的位置机制。

如果发现值得关注的信号，再按事先约定做第二批，用均衡映射把中性标识重新分配给角色，保留私有资料归属和角色措辞。先分别分析两批，再考虑合并。不要看着结果不断增加排列，直到出现自己喜欢的结论。

每个团队使用相同的模型 token 总上限、最长耗时、各工具限制和消息投递方式。四名成员消耗的 token、失败工具调用和成员间消息，都要计入。如果某种策略更快用完相同额度，这正是它的行为，不能因为聊天有趣就给它增加预算。

实际限额应由产品能承受的成本和响应时间决定，并在运行前冻结。还要单独限制每份来源的最大输出长度，避免文档长短意外成为处理变量。能固定时，固定模型快照、推理设置、运行框架版本、提示词和来源哈希。服务端仍可能存在随机性；相同随机种子不保证执行轨迹完全相同。

先测证据送达，再看消息有多少

主要指标是：全部计划团队轮次中，有多少完成了有效交付。超时、模型错误、答案不完整和放弃运行，都留在分母里。如果统一起跑前配置就失败，应标记为无效条件、保留记录，按事先约定的初始化失败规则重跑。起跑后遭遇供应商故障，则是运行结果，不能为了好看而剔除。

每个候选答案都要先检查，再决定是否通过。 对每项必需事实，分开记录两件事：是否引用了真实有效的来源标识，所写数值是否与答案表一致。引用齐全，也可能把价格写错。只有三个事实的这两项检查全部通过，收集器才接受答案。因此，“已通过答案的证据完整率”本来就必然满分，不能拿来当独立的质量结论。

做轮次级诊断时，成功轮次采用已通过答案，失败轮次采用最后提交的候选答案，不要事后挑一个定义不清的“最好答案”。没有任何提交的轮次单列为“未提交”，不要虚构一个覆盖率为零的候选答案。报告缺失来源的数量时，展示全部计划轮次这个分母，并单列未提交；另行报告有候选答案轮次中的来源覆盖率。候选答案的连续变化有助诊断，但不是独立实验样本。

耗时从请求统一发出算到第一个有效答案。到上限仍未成功的轮次，明确列为未完成，不能从平均响应时间里悄悄删掉。

观察联系流向时，记录每个成员第一条与任务有关的消息发给了谁。启动问候按评分前写好的规则排除。另存总消息数、首位成员收到的消息占比，以及不必要的许可请求次数——即角色与权限约定根本不要求授权，却仍然去请示。含糊案例由复核者根据消息文本裁定；可行时隐藏轮换条件，减少判断偏差。

首位成员收到大量消息，但正确性稳定，可能只是高效的汇总点。同样的集中联系伴随价格证据缺失，就值得警惕。消息多和少本身都不是好坏；它们与证据完整性、耗时和成本的关系，才是产品问题。

为每项决定性事实保留一条简单路径：来源持有者、发出的消息、接收成员，以及最终答案字段。这能区分外表相似的失败。价格专员可能根本没被问到，也可能发出了正确折扣，却被另一个成员覆盖。前者提示发现或联系分配问题，后者提示汇总或来源优先级问题。这些只是根据可检查事件作出的初步诊断，不是对模型意图的判断；保留路径，才能让下一次改动对准出错环节。

用运行表把混淆因素摆出来

下面是可复用的记录格式，不是已经完成的实验报告。null 表示尚未测量，不代表零。详细事件另存文件，每一行运行记录引用对应日志。

experiment: catalog-directory-routing-v1
run_id: null
task_variant: null
repetition_block: null
identity_mapping: null
policy: null # unassigned | explicit_shipping_coordinator
directory_order: []
directory_response_sha256: null
source_bundle_sha256: null
model_and_harness_revision: null
ready_times: {}
request_release_time: null
request_delivery_times: {}
total_token_cap: null
elapsed_time_cap_seconds: null
accepted_completion: null
required_evidence: [stock, shipping, pricing]
candidate_checks_log: null # 候选顺序、真实来源标识、数值正确性
diagnostic_candidate: null # accepted | final_submitted | no_submission
diagnostic_source_coverage: null # 逐项来源：present | absent
diagnostic_value_correctness: null # 逐项事实：correct | incorrect | absent
first_task_message_recipients: {}
first_row_inbound_share: null
unnecessary_permission_requests: null
total_tokens: null
time_to_valid_answer_seconds: null
stop_reason: null
event_log: null
reviewer_notes: null

实际来源标识和预期值放进受保护的答案文件，不要放在 Agent 可见的记录里。同时保存 Agent 的主张和验证器的判定。如果收集器把无效引用判成有效，应停下整个批次，先修验证器。继续运行，只会得到记录更精细的错误测量。

MAST 研究区分系统设计、Agent 间不一致和任务验证等失败类别。这套分类有助标注轨迹，却不能自动解释原因。先记录“价格缺失”这个可观察失败；“首位成员的权威导致遗漏”仍然是需要受控比较的假说。

成对读结果，不急着宣布赢家

按策略和轮换条件列出：计划轮次、有效完成、用于诊断的候选答案缺了哪些来源、错误数值、未提交、未完成、token 总量和联系集中程度。保留“全部计划轮次”与“确实提交过候选答案的轮次”两个分母，不要把没交答案与缺少引用混成同一种情况。逐任务结果应与汇总数量一起展示。这个诊断设计每个“策略×轮换”条件只有六轮，不适合藏在漂亮的百分比后面。

先在同一种策略内，比较同一任务的不同轮换。再看明确协调者是否在保持有效完成率的同时，缩小不同位置间的表现差异。团队内部消息相互依赖，因此分析单位是一次团队运行。一轮里有 40 条消息，不等于有 40 个独立样本。即使模型重复次数增加，只有三个任务变体，也仍然难以推广到更广泛的任务群体。

三种解释要分开。随轮换而变化，说明在本实验条件下对配置敏感；重新均衡标识与角色映射后，联系模式仍然跟位置走，才是更强的位置敏感性证据；要进一步解释成注意力、先启动优势或推断出的社会权威，还需新的干预。通信图本身无法区分这些机制。

结果波动大，就在内部如实报告不确定性，扩充预先定义的任务集合。不要因为小批次没看出差异，就宣布“没有影响”。如果需要量化上线结论，应根据最小值得警惕的正确性或耗时变化，规划更大的研究，并在团队运行层面计算适当的不确定性。第一批的用途是发现和理解失败，不是证明系统普遍不存在偏差。

产品改动要对准具体失败

根据结果选择下一步，不要自动把答案写成“再加一个管理者”。下表给出建议响应，没有借用任何 benchmark 的通用阈值。

观察结果	下一步决定
联系集中，但全部证据都能在产品预算内送达	保留更简单的策略，把集中程度当行为监测，而非失败本身
轮换影响有效完成，或反复遗漏某项必需来源	暂缓扩展，检查联系路径，再用均衡标识映射复查
明确协调者减小位置不稳定性，且正确性和预算没有变差	在全新的留出任务上试点这条指令
明确协调者带来审批循环，或延迟关键证据	删除多余的请示措辞，测试直接咨询专员
启动或请求投递时机随排序系统性变化	先修实验操纵，不能把结果归因于名录呈现
两种策略在所有轮换中都卡在同一事实检查	先修资料访问或验证，再优化协调

不必要求每个成员的联系量相同。专长不同，本来就可能负载不均。产品真正需要避免的，是一个偶然的排序让关键专长无法进入决策，而不是让通信图看起来足够民主。

Anthropic 对其多 Agent 研究系统的介绍讨论了清晰的委派边界和额外成本。它是一个生产团队的经验说明，不是对本文干预的验证。这里可借鉴的是整套系统一起测：一名明确协调者即使改善了某条轨迹，若在别处把工作量翻倍，也未必是值得采用的产品改动。

哪些场景不适合这套实验

这套设计适合 Agent 能看成员名录，并自行决定联系谁的产品。如果连接关系已经写死在代码里、单 Agent 的工具路由完全确定，或第一名成员本来就是合法授权的管理者，这个实验能提供的信息就有限。它们需要回答别的问题，不必为了让测试材料对称，而取消正当的职责安排。

虚构目录任务还特意排除了真实用户、持续变化的库存和不可逆操作。通过它，不能证明生产安全、隐私保障或商业价值。后续必须加入有代表性的任务、真实的资料时效、外部状态核验，以及产品原有授权控制；证据齐全不能替代这些措施。

LangChain 10 月 29 日的 Managed Deep Agents 更新加入后台子 Agent 和持续协调能力。这说明，委派工作变得更可交互时，联系分配仍然是产品的一部分；它不意味着 LangChain 存在 YC 游戏里观察到的名录行为。只有 Agent 实际看到相应选择界面时，才应用本文实验。

第一轮实施可以很小：检查一份真实名录响应，建立四成员合成任务，验证列表顺序确实独立于启动顺序。还没花钱调用模型，就可能发现混淆因素。之后按批次表运行，逐一复核证据缺失案例，再决定是否修改架构。最终有用的产物，是一套编辑名录后还能重跑的比较。下一个专员应靠改善实际交付证明自己的价值；名录的排序规则，也不该在无声中替你决定任务如何协调。

Agent 名录排在第一位，就会变成负责人吗？