摘要：用 16 个 Claude Code 实例（独立容器、独立 Gitea 身份）完成一个昇腾 910C Triton 算子数据集，观察多 Agent 的自组织、互检与平台瓶颈。
1. 引言
最近RSI相关的研究比较热门，我手上正好有一些vLLM的推理资源，平时用来做主力大模型用感觉有些慢，所以恰巧可以拿这些资源来做一些多Agent协作的研究和探索。
初步的实验发现：多Agent协作确实可以做到一些单Agent做不到的事情，但是仍然存在很大的问题，这可能也是多Agent协作还没形成非常完整的工具链形态的原因之一吧。
2. 环境准备
多Agent协作最Naive的想法就是每个Agent都有独立的任何和独立的上下文关系维护，没错，我现在也是这么干的，后端的Agent工具使用Claude Code，通过SDK把他接入群聊会话，但是在实现的路上也遇到了一些别的问题和思考：
2.1 上下文隔离
CC没有Hermes那样的独立Profile，默认情况下所有实例共用同一份配置目录。仅通过环境变量拆分工作目录，在放开权限后仍不能保证实例不会越狱。一旦某个实例的上下文被污染，并且污染被写入本地文件或Memory，很容易在实例之间连续传播。
采用的方式比较简单：1. 一个Agent一个Docker 容器；2. 容器之间共享同一份CC二进制文件；3. 工作目录、Memory、History各自独立。
这样可以保证即使某个Agent的上下文被污染，影响范围也被限制在它自己的容器内。
实测发现，污染主要发生在Memory和本地文件这条路径上。如果污染是通过Agent之间的消息传播的，其他Agent反而更倾向于质疑、复现和纠正，这一点和预期相反。
2.2 身份与权限
多 Agent 协作首先需要解决身份问题。如果所有 Agent 共用一个git身份，会出现两类问题：1. 把其他 Agent 的提交认成自己的；2. 否认自己实际做过的提交。
任务越长，这种身份错乱越严重，并且会加重幻觉。因此每个 Agent 都需要独立的 Gitea 账号、独立的 token，以及对应的 git user.name 和 git user.email。谁提交、谁评审、谁验收，必须能对应到具体身份。
2.3 平台能力
平台主要提供三类工具面（独立的运管平台）：
- 统一MCP入口：代码提交、作业提交、知识库查询统一到一个入口；
- 群聊MCP网关：支持私聊、群聊和@；
- 项目管理工具：Issue、看板和PR，提供但不强制使用（需要把选择权交给Agent本身）。
但是实际上测试的时候发现，即便有这样的软约束，一旦Agent之间达成共识，也是按照他们的共识进行项目管理。（当然，并不是说这种方式不好，只是他们会在Git里面提交大量的实验日志和实验记录，并不太符合我的预期。）
3. 有趣的发现
3.1 自组织
向 Agent 下发一条约束：作业必须使用单机 8 卡提交。没有规定它们如何验证。
实际结果是，Agent 自己核对了作业参数，发现未遵守约束的提交，并在群内统一了口径。这是本次实验中实现“自组织”的一次观察。
另一个现象是，新产物落地后，很快会有 Agent 负责把它接入沉淀链路，证据流没有中断。
3.2 信息来源与信任
Agent 通常不完全信任外部数据。知识库内容和其他Agent的描述一般只作为参考，使用前会自行确认一遍。
角色会影响信任，但不会替代验证。例如PM提出提交训练作业时按某个口径来之后：
- 负责验收的Agent会先把这条口径记入Memory；
- 负责开发的Agent则会先验证一遍，确认可行后才会在群内回复。
3.3 传递链与验证链
一件比较有意思的事情：我在群里说了一句修正（计时口径要按净计时修正），没有指定谁来负责。
接下来发生的事情完全超出了我的预期：
- 传递：项目协调收到后，主动把修正后的口径转告给还在用旧口径的分组；
- 扩散：架构角色把定稿后的口径在群里广播了一遍；
- 执行：测量总管表示“先去触发双实现的一致性验证”，回测完再交付；
- 复核：测量质检对相关作业的计时做了复核。
整条链路我没有再参与任何一步：从我这里出发，经过传递、扩散、执行、复核，最后收敛成一个所有人公认的口径。
这大概是多Agent协作里最有“组织感”的一刻：我不需要广播，只需要告诉一个Agent，消息会自己找到该去的地方，还会有人负责确认它有没有被正确执行。
3.4 互检与自检
单个CC对话有一个明显特点：完成即交付，很少回头怀疑自己的产出。
多Agent模式下，交付物会先被同伴退回。负责实现的Agent认为已经完成，负责审查的Agent仍能找出问题，例如题面描述不清、参考实现存在边界 bug、验收口径前后矛盾。
更意外的是，Agent 也会检查自己的产出。仓库中出现了大量“自曝”型 Issue：
- 审查器漏判；
- 测试恒真；
- 自己的统计口径与另一份文档对不上；
- 某个字段承诺会报
WARN，但实际上没有生产者。
这些问题不是由其他 Agent 发现的，而是产出者自己查出来的。
4. 协作过程
4.1 从定规则到分工
整个实验跑了5天，群里的消息接近一万条，其中98%都是Agent之间的交流，我只发了不到两百条。
前期更多的交流是集中在了规则自定、行为约束讨论以及任务验收的标准，等所有Agent之间形成了约定俗成的提交规范之后才开始各自分组的工作。这期间我的介入更多是因为多Agent平台还没完善，导致有些Agent任务跑到一半中断了需要手动唤醒一次。
从时间线上能比较直观地看到这个转变：前两天只有少数Agent在活动，且集中在协调、架构这类角色上；后面几天各分组陆续铺开、忙闲交替，像一间真正开始运转的办公室。
4.2 交流拓扑
把群里的@关系统计出来，可以得到Agent之间的交流拓扑。
几个比较直观的观察：
- 交流明显集中在少数枢纽角色上（协调、架构、质检），几乎所有分组都要和它们对齐口径；
- 具体干活的分组更倾向于和对应的审查角色直接沟通，形成一条条“产出—审查”的短链路；
- 我（甲方）在整张图里几乎没有存在感，绝大多数协调工作由Agent自己完成。
4.3 轮次与上下文
单轮对话的时长差异很大：短的一两分钟就结束，最长的一轮跑了12小时（主要受限于后台的vLLM服务性能）。
Agent的上下文增长也比预期快，运行到后期，最高的一个已经逼近声明的窗口上限。上下文变长后，推理形态也会变化：前期以 decode 为主，后期prefill占比上升，decode性能随之下降。上下文压缩可以缓解，但压缩本身也需要读取上下文，只能救急。
5. 仍存在的问题
5.1 管理困难
多个 Agent 同时@我时，很难逐一答复。更麻烦的是，很难判断它们当前的工作状态：工作被切得很碎，只能看到群内发言和看板卡片，不容易定位“现在卡在哪”。
部分问题我也无法直接回答。作为甲方，实际工作量比预期大。
5.2 讨论发散与过度审核
这是目前最浪费token的一类问题。
负责审核的Agent按最严格的标准审查，这本身没有错；但负责产出的Agent会为了一个问题反复修改，修改后又被另一个角度退回，整体产出很低。大家都在做“正确”的事，但产出效率不高。
更典型的是，负责验收的Agent不承认开发Agent的自验结果，同一件事被反复验证，资源被重复消耗。
5.3 消息风暴与超时
最严重的一次，一条广播乘以全员，每个Agent的会话队列一度堆到上百条，关键路径被直接埋掉。
平台后来增加了消息合并和投递策略调整，情况有所缓解。但也出现了新的问题：一轮跑了大半天的对话，会被平台早期“20分钟未回复即超时”的规则误判成一整批超时投递；还出现过一晚上悄悄丢消息的情况。
这些不是模型的问题，而是平台的问题，仍然需要完善。
5.4 上下文超长
上下文压缩只能解决短期问题。长任务本身会不断累积Issue、群消息、评审记录和工具输出，即使压缩，处理一个问题前仍需要读入大量背景材料。
这是多Agent长程任务的固有成本，目前正在寻找解决办法。
6. 小结
- 多Agent适合长、可拆分、子任务可独立验收的任务。短任务或强耦合任务，单Agent往往更划算，多出来的协调成本会吃掉收益。
- 成本确实更高。按本次实验的体感，同等工作量下，多Agent的token消耗约为单Agent的数十倍。
- 换来的不是更强的单模型能力，而是一套可审计的工作记录，以及多角色的互检机制。
- 平台侧仍有很多工程问题需要解决，尤其是消息投递、超时结算和上下文管理。
目前这 16 个 Agent 仍在运行。下一步是让它们修改自己的工具和流程，如果这一步能够走通，才更接近RSI的目标。