给 AI 团队搭个“持久网络”：拓扑管理为什么重要

你要是用过多个 AI 编程助手，肯定踩过同一个坑：每次重启，所有 agent 就都失忆了。你得重新讲一遍上下文、重新梳理流程、重新同步上周的决定。就像每天早上都要给同一批外包重新做入职培训。

OpenRig 的思路是：把多 agent 协作当成基础设施来管理——因为它本来就是基础设施。

现在 AI 编码流程的麻烦

现在大多数人启动 AI agent 做开发，本质上都是在跑孤立的会话。Claude 刚写完一段代码，你一切换，GPT-4 又从零开始，对之前的事一无所知。没有共享记忆、没有固定身份、也没有真正的“团队”。

这种方式对付临时任务还行，但真到实际开发里就撑不住了。真实场景需要的是：

• 固定身份：同一个 agent 能连续工作好几天甚至几周
• 共享知识：多个 agent 能互相学习对方发现的内容
• 决策持久化：昨天定的架构方案，今天重启后还在
• 可扩展协作：十几个 agent 一起干活，也不乱套

这就像用裸机跑生产环境——理论上能跑，但现实里很容易翻车。

拓扑：给 agent 团队建基础设施

OpenRig 借用了基础设施即代码的思路，提出了 rig 这个概念——用 YAML 定义的一套 agent 拓扑结构，把它们当成一个整体来管理。

有点像 Terraform，但针对的是你的编码团队。

一个 rig 不是简单的 agent 列表，而是一个图结构。agent 会被分组到不同的 pod 里共享上下文，pod 之间通过定义好的边来通信。整个拓扑可以快照、持久化、恢复，就像一个完整的系统。

实际操作就是：

一个 YAML 文件，一条命令，整个团队就启动了。

pods:
  orchestration:
    agents:
      - lead (Claude Opus)
      - coordinator (Claude Sonnet)
  
  development:
    agents:
      - implementation (Claude Code)
      - review (Codex)
  
  research:
    agents:
      - explorer-1, explorer-2, explorer-3

这不是概念验证，而是实打实的基础设施定义。

几个改变游戏规则的功能

持久身份

agent 不再是临时工。同一个 agent 可以长期保持角色、知识和协作关系不变。当上下文窗口满了，agent 会把完整状态迁移到新会话里继续，而不是重新开始。

跨拓扑的共享内存

同一个 pod 里的 agent 可以把状态外部化并共享。当一个 agent 的上下文被压缩后，其他 agent 还能恢复这些知识。架构决策、代码模式、设计选择都能在整个网络里累积，而不是重启就清零。

单一协调入口

一个界面就能管理所有 agent。你甚至可以用 Claude 的远程控制在手机上查看整个 agent 舰队。不用在不同工具间切换，一个对话就能搞定整个拓扑。

真实案例：大家已经在用的拓扑模式

文档里已经出现了几种实际使用模式：

对抗式审查：两个 agent（Claude 和 Codex）从不同角度审查同一个 PR。不同模型能抓住不同类型的 bug，优势互补。

研究集群：四个 agent 平行探索同一个问题，没有层级结构。知识库在所有 agent 之间共享，实现真正的并行研究。

安全加固：攻击 agent 负责探测，防御 agent 负责修补，观察 agent 负责记录。三者作为一个整体迭代，直到攻击面清理干净。

持续重构：重构任务在夜间自动运行，审查 pod 负责检查回归问题。没有瓶颈，真正的异步工作。

agent 管理的基础设施：一个 agent 负责操作 HashiCorp Vault，为整个团队管理密钥。基础设施即代码，现在变成了基础设施即 agent。

这对你的架构意味着什么

传统工作流默认 agent 是用完就扔的。但当你真正做软件开发时，这个假设就站不住脚了：

• 知识累积更快：agent 记得之前学到的东西，决策质量会越来越好
• 上下文不重置：不用反复解释同一个需求五遍
• 专业化分工成为可能：一个 agent 专职测试，另一个专职重构，互不干扰
• 异步工作真正落地：你睡觉的时候，agent 还在改进代码，而且不会丢掉连贯性

这才是当 agent 网络拥有持久身份和共享内存时，才能实现的效果——不是更好的单个 agent，而是真正能像团队一样运作的团队。

如何上手：从发现到编排

OpenRig 内置了发现模式。如果你已经在 tmux 或其他环境里跑了 agent，rig discover 可以扫描现有会话，自动生成一份候选的 RigSpec（拓扑定义）。你不是从零开始，而是把已有的工作流正式化。

剩下的交给 CLI：启动、快照、恢复、可视化。一条命令就能把整个舰队上线。

对于在 NameOcean 或其他托管平台上做开发的工程师来说，这套思路很熟悉。你用 YAML 定义生产环境，版本控制它，清楚地知道有哪些资源存在。OpenRig 把同样的纪律带到了 AI 开发流程里。

更大的图景

OpenRig 是开源的，除了你已经在用的 Claude 或 Codex API key，不需要额外密钥。它是你能完全掌控的基础设施，而不是又一个黑箱厂商方案。

最初的问题是“怎么让 agent 不忘事”，结果演变成了更基础的东西：让 agent 团队能在真实工作中存活下来的基础设施原语。这种存活性，在 AI 领域往往被低估——它决定了你用的是玩具还是能真正交付的工具。

你的 agent 拓扑就是基础设施。要像对待基础设施一样对待它：定义它、版本控制它、恢复它、持续改进它。

这才是 OpenRig 真正带来的价值。

想了解持久化、协作式的 agent 团队怎么改进你的开发流程？可以查看完整的 OpenRig 文档，或者直接去 GitHub 仓库拉代码，启动你的第一个 rig。