多Agent协作开发有感

Tue, 20 Oct 2026 00:00:00 +0000

摘要：用 16 个 Claude Code 实例（独立容器、独立 Gitea 身份）完成一个昇腾 910C Triton 算子数据集，观察多 Agent 的自组织、互检与平台瓶颈。

1. 引言

最近RSI相关的研究比较热门，我手上正好有一些vLLM的推理资源，平时用来做主力大模型用感觉有些慢，所以恰巧可以拿这些资源来做一些多Agent协作的研究和探索。

初步的实验发现：多Agent协作确实可以做到一些单Agent做不到的事情，但是仍然存在很大的问题，这可能也是多Agent协作还没形成非常完整的工具链形态的原因之一吧。

多Agent协作最Naive的想法就是每个Agent都有独立的任何和独立的上下文关系维护，没错，我现在也是这么干的，后端的Agent工具使用Claude Code，通过SDK把他接入群聊会话，但是在实现的路上也遇到了一些别的问题和思考：

CC没有Hermes那样的独立Profile，默认情况下所有实例共用同一份配置目录。仅通过环境变量拆分工作目录，在放开权限后仍不能保证实例不会越狱。一旦某个实例的上下文被污染，并且污染被写入本地文件或Memory，很容易在实例之间连续传播。

采用的方式比较简单：1. 一个Agent一个Docker 容器；2. 容器之间共享同一份CC二进制文件；3. 工作目录、Memory、History各自独立。

这样可以保证即使某个Agent的上下文被污染，影响范围也被限制在它自己的容器内。

实测发现，污染主要发生在Memory和本地文件这条路径上。如果污染是通过Agent之间的消息传播的，其他Agent反而更倾向于质疑、复现和纠正，这一点和预期相反。

多 Agent 协作首先需要解决身份问题。如果所有 Agent 共用一个git身份，会出现两类问题：1. 把其他 Agent 的提交认成自己的；2. 否认自己实际做过的提交。

任务越长，这种身份错乱越严重，并且会加重幻觉。因此每个 Agent 都需要独立的 Gitea 账号、独立的 token，以及对应的 git user.name 和 git user.email。谁提交、谁评审、谁验收，必须能对应到具体身份。

平台主要提供三类工具面（独立的运管平台）：

但是实际上测试的时候发现，即便有这样的软约束，一旦Agent之间达成共识，也是按照他们的共识进行项目管理。（当然，并不是说这种方式不好，只是他们会在Git里面提交大量的实验日志和实验记录，并不太符合我的预期。）

向 Agent 下发一条约束：作业必须使用单机 8 卡提交。没有规定它们如何验证。