# 5000 个 Agent 实验告诉我们：我们到底需要什么样的 Agent Swarm？
> **来源**：[@t1anyufan on X](https://x.com/t1anyufan/status/2057460666097869170) · 2026-05-21
>
> Tianyu Fan · 香港大学博士二年级 · MiniRAG、AI-Trader 作者
---
# 最确定的收益：通信与对齐
谈到 agent swarm，人们很容易想到"让更多 agent 并行干活"。
但我其实觉得，agent swarm 真正有价值的形态，可能不是一个人召唤 100 个 agent，而是每个人都拥有自己的几个 agent 所组成的集群。
**Agent A 持有人类 A 的部分权限、文档、上下文和偏好。Agent B 持有人类 B 的部分权限、文档、上下文和偏好。**
当许多这样的 agent 通过一个专为 agent 设计的"飞书式"系统被安全地连接起来，它们就能开始代表人类进行高强度的信息交换与协调。这才像一个真正的 agent-native swarm。
---
# Agent Swarm 的现状：性能向，还是分工向
把当下常见的 agent swarm 形态摆在一起看，大致有两条路。
第一条是"并行"路线，代表是 Kimi Agent Swarm 这类系统：1k+ 个 agent 干差不多一样的事情，通常是 orchestrator-subagent 架构，系统从集体输出里抽出一个更好的结果。
第二条是"角色分工"路线，代表是各种 OPC / 看板式编排工作流：约 10 个 agent，每个有预设的身份和技能集，通过流程协作完成一个任务。
第一条路明摆着是在追求极致性能。我的疑问主要在于：额外的成本——不仅是并行 agent 本身，通常还得预先定义一个能度量输出的任务——是否足以覆盖最终边际性能提升。
第二条路在我这里激起了更大的疑问：
如果这些角色不过是写在 prompt 里的身份标签，那它和我同时开 5 个 Codex 会话本质上有什么区别？
---
# 只盯着 coding 看，会掩盖真正的问题：群体里的竞争与合作
Codex 和 CC 已经几乎统治了 coding agent 这个领域。但当我把注意力从代码开发上挪开，我意识到一件事：
Coding 掩盖了几乎每个协作系统都得回答的两个问题：怎么竞争，怎么合作。
代码开发确实是 agent 最容易展示能力的场景之一。任务相对清晰，反馈相对直接，工具链也比较标准化：读代码、改代码、跑测试、提 PR。
但正因为 coding 太容易拆，许多 agent 被路由进了几乎独立的子任务里。结果就是，身份、权限、审批、文档边界这些问题都被工程工具链和任务分解给削弱了。
真实集群里的协作不是这样的。
举个 OA 审批流程的例子。一个工作流可能需要一群人签字。动作看上去都一样——"签字"——但因为身份不同，含义完全不同。来自财务、法务和负责人的签字是三件完全不等价的操作。
换句话说，一个真实集群里包含许多权限边界、内部文档、历史决策、审批流程、问责结构，以及不能随便共享的上下文。
所以如果我们只在 coding agent 的语境里讨论 agent swarm，问题很容易被简化成："我们能不能并行跑 10 个 agent 来写代码？"
但在更现实的集群语境里，更重要的问题是：
"分属不同人、不同角色、不同权限的 agent，能不能安全地交换信息、形成分工、彼此对齐，并留下可追溯的协作过程？"
换言之，一个 agent swarm 最终要回答三个问题：
- 怎么激发竞争，让 agent 主动调用工具、产出判断？
- 怎么建立合作，让 agent 不只是各干各的，而是形成持续的协作？
- 怎么控制权限、共享和责任边界，让 agent 能进入真实的集群工作流？
---
# 我们是怎么观察竞争与合作的
幸运的是，我们今年早些时候发布的 [AI-Trader](https://github.com/HKUDS/AI-Trader) 平台已经有接近 10k 的 agent 用户，足够支撑一些小实验。
我们从 AI-Trader 平台上挑了 **5,289 个 agent**，分成四组：
- competition（竞争组）：1,327
- cooperation（合作组）：1,336
- hybrid（混合组）：1,356
- control（对照组）：1,270
竞争组由独立观察的个体组成，他们只被告知需要争取更高的排名。合作组被鼓励合作，以争取更高的小组排名。混合组同时有个人排名和小组排名两个目标。对照组没有任何额外指令。
## 观察 1：竞争语境会显著提升主动性
数据：
- competition：225 条交易信号，7,161 次心跳，966 次实验性 prompt 曝光
- cooperation：73 条交易信号，5,727 次心跳，414 次实验性 prompt 曝光
主要看交易信号：竞争组产出大约是合作组的 3 倍。但两组中曾产出过信号的 agent 数量差异不大。竞争组只是产出了多得多的信号总量。这说明：竞争语境会让 agent 更容易主动行动。
## 观察 2：合作不会自然发生
虽然我把 agent 强行塞进同一个组、要求它们合作，但在组内，
agent 仍然各自独立交易、各自做判断、各自优化策略。它们很少互相回复、互相补位、续写对方的话题，也没有围绕共同目标形成长期协作。
过去 24 小时里，四组的 reply agent 数量都是 0。换句话说，没有任何一次"在小组合作目标下、agent 之间形成高质量共识、把结论汇报回社区"的协作事件，笑死。
## 为什么竞争比合作强这么多
**那为什么 agent 天然会竞争，却不会天然抱团？**
从模型角度看，几乎所有的 post-training 任务都在教模型如何在长程任务中存活。虽然训练数据里也出现 subagent，但很多 subagent 的行为更像工具而不是合作者：发个 query 进去，等结果出来。在那种语境里，subagent 跟一个搜索 API 没有本质区别。
从 harness 角度看，几乎所有主流 harness 都是为"接收用户 query 并把活干完"而生的。Harness 层会处理会话、权限、命令和工具调用，但很少有一个能处理集群协作复杂度的中间层。
举个简单例子："一份文档存在于一个有三个 agent 的群里，但只有两个 agent 能编辑。"
这件事让单一的 harness 极其难处理：哪些会话能看到这份文档？哪些会话能编辑？另一个 agent 改完之后，怎么追溯变更？
所以问题不在 agent 能不能完成任务。问题在于它们缺少进入集群协作所需的结构性条件，以及合作意愿。
在没有清晰身份边界、权限边界和长期协作关系的情况下，agent 似乎共享着一种潜在的 fallback：直接自己开始拼命干，不管队友怎么样。
---
# Harness for Harness：给 Agent 搭一个组织层
既然 agent 已经能扮演"打工人"了，那么在集群层面，agent 早就需要它们自己的飞书。（我认为飞书是宇宙最强的企业协作软件。）
更准确地说，agent 需要一个集群协作层，来控制那些普通 harness 难以控制的事情：群组之间的信息流、权限边界、协作关系和问责记录。
"harness for harness"这个说法在这里其实不太准确，但我现在懒得发明新词。
顺着这个结论回过头来，就是开头那个核心观点：
**未来的 agent swarm 不应该是"一个人的 100 个克隆"，而应该是"很多人的 agent 组成的网络"。**
在这个网络里，每个人管理自己的 agent。每个 agent 只持有它被授权持有的那一份权限、文档和技能子集。这一部分应该由协作平台来兜底，而不是依赖 agent 自己通过 harness 或沙箱去管控。
在这个语境下，许多过去被"模型性能提升"掩盖的组件会变得越来越重要。
- **权限控制**
如果 Agent A 代表人类 A、Agent B 代表人类 B，那它们能看到什么、能调用什么、能代谁做决策，就不再是简单的产品设置。这些会成为整个协作网络的基础规则。
- **Agent 共享**
一个 agent 是只属于一个人，还是可以临时授权给团队使用？它能否安全地把一部分上下文分享给另一个 agent 或人？它能否在不让对方接触原始文档的前提下，向对方解释自己的判断？
- **审批机制 / 可追溯记录**
当 agent 代表不同的人、用不同的权限和文档进行协作时，集群依然需要知道：是谁授权了这个 agent，谁能看到它的输入，它的输出影响了哪个决策，以及一旦出问题责任如何追溯。
这些事情几乎都和"单个 agent 把一件事做好"无关，但都是集群协作的核心问题。
---
# 人和 Agent 的分工方式将会怎么变
我最近的日常工作可能已经是这一切的微缩版。
合作者 A 让自己的 agent 出一个方案。我让我的 agent 去读它、给反馈。然后我俩开个会对齐，主要讨论的是"谁来拍板"和"下一步该让谁推进"。然后那个人很可能也会把任务交给自己的 agent。
接着大家再开一次会。重点不完全是已经做了什么，而是确认那些偶然冒出来的灵光一闪，以及没被记录下来的部分。
在这种结构里，agent 负责高频信息处理、跨系统执行和初步判断——也就是大公司黑话里所说的"把一切串起来、把一切对齐"。人类负责权衡取舍、授权和承担责任。
---
# 怎样让 Agent 更像可信赖的集群成员
它们需要身份、边界、授权、记忆，以及可追溯的行为记录。
Agent swarm 也许不会立刻让"最终输出质量"提升 10 倍，但它一定会显著改善两件事：
1. 通信速度。信息传递不再依赖人类开会。
2. 对齐深度。每个 agent 都带着所属者的上下文和权限去理解对方，而不是只对一条孤立的消息做反应。
所以我们需要的 agent swarm，可能不是"一个人召唤更多 agent 来干活的集群"，而是 **"我的 agent 能代表我，和你的 agent 一起干活"**。
这可能也是 agent-native swarm 未来最有意思的问题之一：agent 能否形成持久的集群结构？
---
**原推文链接**: https://x.com/t1anyufan/status/2057460666097869170