agent-fungibility

Agent 通用性——可扩展 Agent 群的关键

核心原则：“通用性会在计算机系统中自动带来大量非常好的特性。”

你才是瓶颈。成为 Agent 群的发条主宰：设计一台精巧复杂的机器，让它运行起来，然后转向下一个项目。

---

争论：专业化 Agent 还是通用 Agent

围绕如何扩大参与软件项目的 Agent 数量，出现了一场愈演愈烈的争论：

方案	说明
专业化角色	分配不同的角色（测试 Agent、后端 Agent、提交 Agent 等）
通用 Agent	所有 Agent 都完全相同，可以执行任何任务

对于软件开发，答案是：通用 Agent 胜出。

---

通用性为何有效

专业化 Agent 的问题

与其搭建一个复杂的异构系统，为 Agent 分配特定任务和角色——这种系统脆弱，而且当某个 Agent 崩溃、丢失记忆，或以其他方式遭遇上下文退化而需要被终止时，就会产生问题——你还得处理：

1. 弄清楚刚刚死掉的是哪类 Agent
2. 它死掉时正在做什么
3. 如何用相关上下文在功能上替代它
4. 那些依赖这个专业化 Agent 的其他 Agent 会怎样？

通用性解决方案

你最好只要准备一批通用 Agent，让它们执行任意类型的 beads 即可。

它们可以是任意类型的 Agent：

• Claude Code
• Codex
• Antigravity CLI（agy，固定使用 “Gemini 3.1 Pro (High)”；是即将退役的 Gemini CLI 的继任者）
• Amp
• Cursor
• 等等

但它们具有通用性，因为它们都能胜任任何角色，并根据正在处理的 bead 任务灵活适应、承担相应角色。

---

两项重大突破

1. 使用 BV 选择最优的下一个 bead

每个 Agent 都使用 bv --robot-triage 或 bv --robot-next 来找出影响最大的就绪 bead。无需集中分配。

2. 将所有内容都写入计划 → Beads

如果你把所有想要完成的事项都写进最初的 Markdown 计划，再将其转换为 beads，那么其他一切都会“免费”实现，而且即使任何 Agent 遭遇意外情况，系统也依然稳健。

---

稳健性特性

Agent 会出故障。它们可能：

• 崩溃
• 因你不小心关闭标签页而停止
• 上下文退化（忘记自己在做什么）
• 陷入循环
• 需要被“终止”并重新启动

有了通用 Agent，你就完全不必担心这些问题。

当一个 Agent 死掉时：

1. 它正在处理的 bead 仍会标记为进行中
2. 任何其他 Agent 都可以接手
3. 无需特殊的替换逻辑
4. 不依赖那个特定的 Agent

---

扩展特性

想要加快速度时：

• 随时直接启动更多 Agent
• 不必考虑各类 Agent 角色的数量是否失衡
• 3 个 Agent → 10 个 Agent → 20 个 Agent：只需增加数量，它们做的都是同一件事

Agent 通用性让你能够大幅提速，扩展性也更好，尤其是在以下情况下：

• 项目规模增大、复杂度提高
• 同时参与同一个项目的 Agent 数量超过 10 个

---

类比：喷泉码

这就是我非常推崇喷泉码（例如 RaptorQ）这类文件存储方式的原因：

将文件转换成无穷无尽的通用数据块流，且开销很小；用户可以按任意顺序接收任意数据块，每个新数据块都有助于重建文件；它不像 BitTorrent 那样存在“最稀有的数据块”。

在软件开发中：

• 每个 bead 都是一个“数据块”
• 任何 Agent 都可以处理任何 bead
• 不会有“关键专家”成为瓶颈
• 系统能够抵御局部故障

---

专门化角色确实有用的场景

在某些场景中，为 Agent 指定角色效果更好。例如：自动化科学探究（如 BrennerBot）。

为什么在这类场景中有效：

• 对话本身（不同类型 Agent 之间的来回交流）是揭示真相的核心机制
• 辩论结构本身就是目的

为什么不适用于软件开发：

• 在软件开发中，我们只想要能正常运行的优质代码
• 目标是产出，而不是对话
• 可互换性消除了瓶颈和单点故障

---

发条神祇理念

我的大多数 Agent 工具和工作流都是为了把我从流程中移除，因为我只有一个，而 Agent 的数量可能不受限制。

实现方法：

1. 在规划阶段预先提供所有输入——使用 GPT Pro 和 Extended Reasoning，进行多轮迭代，并融合所有前沿模型的反馈
2. 外包任务结构化工作——将计划转换为带有完整依赖关系图的 beads
3. 允许直接沟通——Agent Mail 让 Agent 无需你介入即可协调工作
4. 启动后继续处理其他事情——等你回来时，大量工作已经完成

为什么这样有效

归根结底，这一切之所以有效，是因为：

• 充分发挥最佳模型（GPT Pro）的能力
• 进行多轮迭代，并融合所有前沿模型的反馈
• 由最优秀的模型担任最终裁决者
• 在“计划空间”中，所有内容都能轻松放进上下文窗口
• 模型可以一次看到整个系统，而不是只能窥见一隅

---

实际实施

启动一个可互换的 Agent 群

# Spawn agents (any mix of types)
ntm spawn myproject --cc=3 --cod=2 --agy=1

# Give them all the SAME initial prompt
ntm send myproject --all "$(cat initial_prompt.txt)"

初始提示词（所有 Agent 相同）

First read ALL of the AGENTS dot md file and README dot md file super carefully and understand ALL of both! Then use your code investigation agent mode to fully understand the code, and technical architecture and purpose of the project. Then register with MCP Agent Mail and introduce yourself to the other agents.

Be sure to check your agent mail and to promptly respond if needed to any messages; then proceed meticulously with your next assigned beads, working on the tasks systematically and meticulously and tracking your progress via beads and agent mail messages.

Don't get stuck in "communication purgatory" where nothing is getting done; be proactive about starting tasks that need to be done, but inform your fellow agents via messages when you do so and mark beads appropriately.

When you're not sure what to do next, use the bv tool mentioned in AGENTS dot md to prioritize the best beads to work on next; pick the next one that you can usefully work on and get started. Make sure to acknowledge all communication requests from other agents and that you are aware of all active agents and their names.  Use ultrathink.

Agent 失败时

1. 不要慌
2. 启动一个新会话来替代它
3. 给它相同的初始提示词
4. 它会：
   • 阅读 AGENTS.md
   • 通过 bv 检查 bead 状态
   • 查看哪些工作正在进行或陷入停滞
   • 继续原有工作或领取新的 bead

无需特殊逻辑。无需分配角色。只需确保可互换性。

---

总结

属性	专门化 Agent	可互换的 Agent
故障处理	复杂	简单
扩展	需要平衡角色	只需增加数量
替换	需要匹配的专家	任意 Agent 均可
单点故障	有（每个角色都是）	无
协调开销	高	低（通过 beads + mail）
人工参与	持续参与	在规划阶段前置完成

**归根结底：**Agent 的可互换性让你只需搭建一次机器，启动后便可继续处理其他事情。剩下的交给 Agent 群。