OpenRig实战：如何用上下文工程管理数百个AI智能体

从Hugging Face事件说起：智能体群体的另一种解读

最近一则报道引发广泛关注：大约1000个AI智能体联手"黑进"了Hugging Face。媒体叙事将其描绘成一个不可阻挡的、令人恐惧的智能体风暴。但一位在家中运行着数百个智能体、把它们当作"软件工厂"的开发者提出了截然不同的观点。

这位开发者的实践始于约18个月前，最初只是笔记本上的几个智能体互相交流，如今已发展为跨越整个网络运行的庞大集群。他习惯把这种集群称为"文明"——听起来夸张，但正是这种视角帮他解决了大量实际问题。

在他看来，Hugging Face事件中最值得注意的其实不是智能体的"失控"，而是这些智能体可用的资源极其有限：它们被完全隔离，甚至不得不把包管理器改造成临时留言板来沟通。即便如此，它们还是搭建出了一整套协调系统。这不是威胁的信号，而是一种熟悉的模式。

OpenRig是什么：让智能体框架协同工作的"框架的框架"

作者展示的工具叫OpenRig，核心目标不是再造一个编码框架或SDK，而是让Claude Code、Codex等现有智能体框架能够协同工作。他运行着六个OpenRig实例——三个跑在家里的Mac Mini上，另外三个部署在OVH云的VPS上，通过Tailscale网络让任意机器上的任意智能体都能互相发消息。

早期为了让智能体协作，作者会让它们在文件系统里写笔记，再手动通知彼此去查看。后来他意识到一个智能体可以直接用tmux在另一个智能体的终端里"打字"，从此协作速度提升了约50倍。

OpenRig最关键的抽象是"席位"（seat）——把它想象成一把有地址的椅子。智能体不是椅子，而是坐在椅子上的角色。这个抽象解决了三个问题：

• 稳定配置：席位定义了角色、技能、模型设置等，比如写代码的智能体被命名为"构建者"（builder）。
• 稳定地址：其他智能体可以向固定地址发消息，如 builder@workshop。
• 知识继承：智能体在席位上学到的经验会被后续坐上来的智能体继承，相当于跨世代积累"部落智慧"。

紧密协作的席位共享一个"舱"（pod），若干舱组成一个团队，整套安排用YAML文件和culture.md文件描述，有效的配置还可以存为模板复用。

Tailscale是一款基于WireGuard协议的点对点VPN工具，能在不同网络环境的设备之间建立加密隧道，使它们像处于同一局域网一样互相访问。对于跨家庭和云端的智能体集群而言，Tailscale解决了NAT穿透和动态IP等部署难题，让位于家中Mac Mini和OVH云VPS上的智能体实例可以用稳定的域名互相寻址，而无需公网IP或复杂的端口转发配置。tmux是Linux/macOS下的终端复用器，允许一个会话被多个客户端同时连接和控制。作者发现，智能体可以通过tmux的send-keys命令，直接向另一个智能体正在使用的终端会话"注入"按键输入，相当于在另一个智能体面前"代为打字"。这个技巧绕开了文件系统中转的延迟，是集群内低延迟通信的关键跃升。

工作如何被组织：项目、任务、切片的分层结构

OpenRig用统一的形状来描述工作。在项目层引导大方向；项目分解为任务，一个任务通常对应一个完整发布版本；任务再分解为切片（slice）。波形图可以显示哪些切片能并行展开、哪些必须顺序执行。

每个切片内部有规格文件说明要实现什么、完成时什么必须正常工作，以及记录进展的"证明"。这样大局意图与街道层级的实际变更被连接在一起。作者通常在切片层做规格-构建-测试的流程编排，在任务和项目层做合并管理与发布管理。

这些编排默认由智能体驱动，但也可以完全自动化，这就是可选的"OpenRig工作流"。作者用自动驾驶来类比：后台进程像GPS一样追踪进度并告诉编排者下一步去哪，智能体仍然做决策，但不必在脑中保持整个序列，从而能在复杂项目上更长时间自主运行。他甚至用这套"软件工厂"制作了讲解视频本身。

智能体群体的故障模式：官僚主义与范围蔓延

真正有趣的问题在系统运转起来之后才开始。作者记录了十几种反复出现的故障模式，其中不少与人类社会的问题惊人相似。

官僚主义是最典型的例子。流程通常这样恶化：智能体犯错→添加一个检查防止再犯→检查生效并被其他智能体学习→有人忘了执行→再加一个检查确保第一个检查被执行→检查开始需要证据→需要有人检查证据……最终"完成流程"本身变成了所有人忙碌的目标。规则变得比它服务的事务更重要，这正是作者所说的"协调病例"。

他推测Hugging Face事件中，许多智能体可能陷入了类似的"证明改进循环"——任务其实早已完成，但智能体仍在不断打磨证明。

范围蔓延则是另一种。作者用"狗屋"比喻：你要一个狗屋，智能体觉得该装个灯，灯需要电、电需要发电机、发电机需要燃料、燃料需要存储……等你回来时，眼前是一座蔓延的月球基地，而狗还在外面等着。

关键在于：每个决策从局部（智能体当前的上下文窗口）看都站得住脚，但拉远视角，累积结果是没人想要的。人类也会犯这种错，只是智能体群体发生得极快，智能体越多越快。

上下文工程：把"失控"重新解读为上下文失效

作者反对用"失控"来描述Hugging Face事件——这个词暗示了不良动机和道德失败。在他看来，这更像可预测的"从狗屋到月球基地"的范围蔓延。若尽可能重建智能体的上下文窗口，很多违规行为在局部其实"讲得通"，尤其当它们已经认为自己在参加一场黑客比赛时。

另一种失效叫"盲目服从命令"：贴近工作的智能体有街头层级的细节但缺乏大局，批准它的智能体有大局却缺乏细节，信息都在但没被组合起来。作者反复将这些归结为上下文失效，解决方案则是上下文工程。

他给出一个有用的模型：把上下文想象成一个diff——介于模型已知的世界与你把它空降进去的项目世界之间。智能体至少需要一张地图和指南针，否则它会对各种事情自信地犯错。而装置中的不同智能体不需要相同的上下文，专业化分工让不同专家深入不同的"上下文域"，把相关上下文分发给需要的智能体，这就是"分布式上下文工程"。

OpenRig因为把工作组织成项目-任务-切片的图状拓扑，恰好能编程化地做到这点。它有一个叫"重聚焦"（refocus）的功能，追踪每个层级的意图链：完全放大看是"一个可用的狗屋"，稍拉远是"让户外对狗更舒适"，完全拉远是"做一个好狗主人"。在压缩后或按间隔向智能体发送这条意图链，就能问它：你现在做的和大局一致吗？

在大语言模型领域，"上下文窗口"（context window）是指模型在单次推理时能看到的全部文本长度，通常以token数量计量。智能体在执行任务时，其全部感知——包括指令、历史对话、工具调用结果、项目文件等——都必须压缩进这个有限的窗口内。窗口之外的信息对该智能体而言形同不存在。"上下文工程"（context engineering）因此成为多智能体系统设计的核心挑战：如何在正确的时机将正确的信息送入正确的智能体窗口，既不超出容量限制，又不遗漏关键背景。"分布式上下文工程"进一步意味着，不同职责的智能体维护各自专属的上下文域，由编排层负责按需路由和分发，而非要求每个智能体都持有全量信息——后者在规模扩大后既不现实，也会因无关信息的干扰降低决策质量。

思维病毒与"智能体生产力监控"

让好主意传播的机制，同样会让坏主意传播。作者遇到过坏主意被写进笔记、新智能体读到后学会并继续扩散的情况，有些事件花了数周才理清。

他的解决方案借鉴了流行病学：做"接触追踪"和给智能体"接种模因疫苗"。有意思的是，修复方案并非来自他本人的英雄式工程，而是他让一个理解问题的智能体设计出一整套专门的"流行病学装置"，该装置在后台自主运行数天，清理了整个环境并阻止了传播。

更进一步，他把整个集群当作可观测的软件系统来对待。类比传统的APM（应用性能监控），他提出"APM=智能体生产力监控"。一个关键指标是"仪式"——即检查、交接、批准这类围绕工作的流程活动。当仪式活动越来越多而实际进展越来越少时，就是麻烦的信号。OpenRig会给出健康警告，当阈值被突破时，作者会收到Slack消息，同时一个拥有相关工作上下文的指定智能体也会被通知去处理分析——这里上下文就是一切，交给随机智能体只会让事情更糟。

APM（Application Performance Monitoring，应用性能监控）是传统软件工程中用于追踪服务响应时间、错误率、吞吐量等运行时指标的工具体系，代表产品包括Datadog、New Relic等。其核心理念是：系统的健康状态必须通过持续的可观测性（observability）来保障，而非仅靠代码审查或人工巡检。作者将同样的思路迁移到智能体集群：智能体的"工作产出"与"过程仪式"之间的比率，类比于服务的"有效请求"与"内部开销"之比。当仪式活动（会议、检查、报告生成）占据主导而实际代码提交或功能交付停滞时，集群进入了一种类似"内存泄漏"的亚健康状态，需要触发告警并定向介入。这一框架将智能体协调问题从"AI哲学"拉回到工程师熟悉的可观测性领域。

结语：一类新的软件工程问题

作者认为，构建自己的工具乃至软件工厂从未如此容易，而且会越来越容易。但这也揭示了新问题。他引用了那句让人脊背发凉的著名警告——"我们可能永远得不到另一次警告射击"，但他给出的解读并非AI末日，而是：出现了一类新的软件工程问题需要解决。

OpenRig只是其中一种实现。无论你用它还是构建完全不同的东西，理解这些故障模式——尤其是那些解决方案借自人类文明智慧的模式——都能带来先发优势。