自研AI团队OpenRig爆火GitHub：停不下来的协作实验

一位海外开发者的副业项目 OpenRig 意外冲上 GitHub trending，PR 蜂拥而至，逼得他把自己的 AI 智能体团队扩容三倍来应对。这场"幸福的烦恼"最终演变成一套关于上下文工程与智能体协作的系统性思考，值得每一个正在搭建 AI 工作流的人细读。

OpenRig 是什么：把代码智能体编成"团队"

OpenRig 是一个开源工具，核心思路是把 Claude Code、Codex、Pi 这类编码智能体放进一个可编排的系统里，组成他称为 rig 的团队。每个智能体有明确的角色（相当于岗位）和地址（相当于邮箱），彼此之间可以直接通信，跨多台机器运行，形成一个协同的智能体网络。

设计哲学很朴素：取最好的现成工具，变成可组合的积木（primitives），削减它们之间的摩擦，然后看会发生什么。由此涌现出一个模式——你只需和一个 lead 智能体对话，它背后有一群智能体替你干活。这个"和一个 agent 说话"的模板，后来成了他扩容的基础单元。

GitHub trending 带来的压力测试

视频发布后，OpenRig 冲上 trending，star 和 PR 一起涌来。原本只是他和自己的智能体在安静地"公开构建"，突然变成一群人一起参与。他坦言自己没为发布做过规划，事后觉得应该加一句"不适合新手"的免责声明。

更现实的问题是：副业项目突然冒出 20 倍的工作量，注意力成了最稀缺的资源。他没有把它当麻烦，而是当成一次花钱验证系统能否扛住规模的机会。做法是给"和一个 agent 对话"的模板加算力——增加 VPS，每个 VPS 上跑不同类型的 rig，团队规模扩到约 3 倍，同时保持在自己注意力能覆盖的范围内。据他描述，两周的 trending 期间，他必须搭起一套审阅和 QA 所有外部贡献的系统。

真正的难题：智能体的"重复造轮子"

加 agent 只是战斗的一半，另一半是这些 agent 到底靠不靠谱。他遇到的核心问题是智能体反复重新发明轮子——在已有实现旁边并行造一套新的。

最典型的例子是 Slack 集成。功能几乎完成，搁置一个月后他让一个 agent 收尾。agent 搜了一下 Slack，然后"按要求"建好了集成，一切能跑——但它从零发明了一套完全独立的通信系统，再把 Slack 接上去，和他记忆中的实现完全不同。这已经是第上百次发生类似的事，他试过图数据库、AI 记忆方案，都撞在同一堵墙上。那一刻他意识到：它们不知道自己不知道什么。

文档和上下文其实都在，但除非手把手引导，agent 不知道去哪找、甚至不知道该问什么问题。搜索能力再强也没用——问题出在搜索之前。让 agent 写一条"已存在 Slack 集成"的备注没有意义，那是打地鼠游戏，你无法预判所有场景。需要的是能泛化的方案。

用"世界构建"重构上下文

他把问题拆到知识本身的第一性原理。一个实用线索贯穿始终：给 agent 好例子，效果远胜一堆事实和规则。为什么例子比事实管用？他借用了"连点成线"的比喻——每个点是一条信息，连起来才有图景，这个图景叫 arrangement。一堆没有连接的事实推不动任何事情，而这正是 agent 自然积累的东西。

新 agent 进入项目时，自带大量训练知识（白点），但没有像你那样连起来（蓝线），还存在训练数据里根本没有的新点（蓝点）。这个增量他比作 PR 里的 diff。人类这边，他引用《Moonwalking with Einstein》的记忆宫殿法，说明大脑为三维地形中的寻路而优化——世界构建、渐进式披露（progressive disclosure）正是利用这一点，agents.md 和 skills 已经在做类似的事。

他认为，人类与 LLM 共享语言这个基底，可称"认知表亲"。如果共享媒介只对 agent 友好而对他不透明，他本人就会成为瓶颈甚至被踢出回路。Markdown 之所以流行，正因为它处在认知重叠区：LLM 能读写、能写小程序操作其结构，人也能直接读改。世界构建有望占据类似的中间地带，实现认知互操作性。

渐进式披露（progressive disclosure）源自交互设计与技术写作，指不一次性呈现全部信息，而是先给出概览与入口，用户或读者按需逐层展开细节。在 AI 上下文工程中，它对应这样一种策略：智能体启动时只加载一张“地图”或一段路由说明，而非整个知识库；只有当它判断需要深入某个领域时，才去读取对应的文件或唤起相应的 agent。这样一来，有限的上下文窗口被留给真正相关的信息，token 消耗也可控。文章提到的 skills 机制与 agents.md 都属于这种思路的实践——用标题和描述充当“门牌”，诱使智能体在恰当时机打开正确的门。

上下文拓扑的四个维度

他把知识组织拆成一套可操作的术语：实体（ontology 中的知识点，即点）、关系（连接）、拓扑（连接形成的形状）。顺着链接在 Wikipedia 里点来点去，就是在导航这种拓扑，agent 检索信息本质相同。

问题仍然是：怎么知道从哪看起？他的答案是给一张更广角的地图——"一英寸深、一千英里宽"，用宽度换深度。让人知道某物存在，比知道它的一切省太多 token。目标是一种最低可行胜任力（minimum viable competence）：agent 能定位自己、开始工作、并在需要时知道该深入还是该扩大范围。做代码审查的 agent 和做架构的 agent 需要的图并不相同。项目变大时，就叠加更多地图构成层级，并让 agent 知道地图的边界之外还有世界。

地图放在旅程的起点，比如 agents.md，再路由到 OpenRig 的上下文库，或通过 router skill 选择进入哪个领域。可寻址性是关键：agent 有地址，上下文也有地址（文件路径），甚至可以通过引用 Markdown 头部让文件内内容可寻址，还能组合出定制视图。他追求的是一种从根到叶的可达性——从 agent 启动处一路追溯到它需要的知识。skill 的标题和描述要像"好标题党"，诱使 agent 打开路由，进入整个世界。

第三个维度是认识论（epistemology）：知识从底层的日志和"markdown 废料"，经过观察、现场笔记、洞察，逐步成熟为 canon——项目视为既定知识的部分。canon 看的是确立程度而非新旧，一个新发现可以立刻成为 canon。知识点的成熟度构成高度，把二维地图变成三维地形。第四个维度是时间：关系变化、成熟、位移，给每个时刻拍快照再排成序列，本质上就是故事。

本体（ontology）一词借自哲学与知识工程，在计算机领域通常指对某一领域中概念、属性及其相互关系的显式形式化描述。文章把它落到了很朴素的层面：本体中的每个知识点就是一个“实体”，也就是拓扑中的“点”；实体之间的链接构成“关系”，关系整体铺开形成的形状则是“拓扑”。之所以需要本体层面的自觉，是因为智能体要能定位自己、判断某条知识是否存在、以及它与哪些其他知识相连，前提是这些实体有稳定且可寻址的身份。没有本体，知识就只是一堆无结构的文本，检索无从谈起。

上下文压缩（compaction）是长会话智能体系统中的常见机制：当对话历史或上下文接近模型窗口上限时，系统会把较早的内容摘要、折叠或丢弃，只保留关键结论，从而为后续交互腾出空间。它让 agent 能持续工作而不会“撑爆”窗口，但代价是细节的丢失——某些路径、约定或历史教训可能在压缩后不再显式存在。文章提到部分路线“在 compaction 后才浮现”，正说明压缩会改变智能体对世界的可见性，因此关键知识需要有稳定的地址与外部存储，而不能只依赖会话记忆。

例子即压缩：从"狗屋月球基地"说起

既然故事就是排列的排列，那好故事的标准也就是好例子的标准。他此前讲过一个故事：让 agent 建狗屋，回来发现是月球基地——agent 一步一个合理决策，造出了没人想要的东西。这个故事被放进工作区的 lore 文件夹，作为代代智能体之间传承的经验。

lore 可以属于一个 rig、一个 pod，甚至一个座位，且有地址。在初始化和上下文压缩（compaction）后，他都会讲一遍狗屋月球基地的故事；agent 再犯时，一句"moonbase"就能让它识别问题，无需展开整个故事。好例子是一个压缩成单条知识的、运动中的世界，能把教训带到完全不相关的场景，像原则一样泛化——这也是它比逐条写规则更可扩展的原因。

他同时提醒别过度旋转：地图不是疆域。本体是磁盘上的文件、Markdown 标题、链接和 OpenRig 命令，仍要打开文件、读代码、确认系统实际在做什么。

分布式的知识网络：文件、智能体与人

他回到 Slack 集成的例子演示系统如何运作。关于"消息如何集成"的知识只存一份、有固定地址，变更时地址不变，agent 查阅时读到新版。它还会发现当初做 Slack 的 agent 仍在线，用 rigsend 直接问它为什么这么实现。

知识不只是一个文件或文件的一部分，更是一个在拓扑中持续可用的"心智"。工作中没人会读遍所有手册，而是知道谁是领域专家、重要的事直接问。OpenRig 让 agent 既能把上下文看作文件，也能看作其他 agent——一切可寻址、可追溯、可路由。他手上有数千个休眠 agent，用 rigask 一条命令就能查它们的 JSONL 会话文件，或唤醒它回答一个问题。他自己也是拓扑中的一个 agent，有自己的地址，问题会经 Slack 路由给他——这才是他当初想做 Slack 集成的原因。

这就是他所说的分布式上下文工程：组织一整群智能体知道什么、知识存在哪、如何触达。每个专家深谙自己的领域，同时持有足够宽的全局地图，知道何时该问别人；专家之间互相知晓，构成一张网络。人类本来就在做这件事，只是不可编程；有了 agent，只要把一切建成拓扑，它就变得可编程。

JSONL（JSON Lines）是一种每行一个独立 JSON 对象的文本格式，适合追加写入和流式读取，常被用作日志与会话记录的存储格式。在 OpenRig 的语境下，每个智能体的会话历史以 JSONL 文件保存，意味着这些交互记录本身就是磁盘上可寻址、可检索的数据。作者提到用 rigask 一条命令查询休眠 agent 的 JSONL 会话文件，正是借助这种格式让“过去的对话”变成可被再次访问的知识源，而不必唤醒 agent 重新推理。

规模化的落到实处：可复制的胜任力单元

回到这次爆火。社区、构建、集成与发布被拆成不同团队，有的跑在办公室的 Mac mini 上，有的在 VPS 上，全部通过 Tailscale 通信。这是一个可重复的"胜任力单元"，像积木一样往外扩，他在自己需要且负担得起的范围内停下。他只需和一个 lead 对话，lead 之间再对话，把只有他这个层级能做的决策往上递。

他在自建的 observatory UI 里观察团队交付。一个真实例子：外部贡献者在 Slack 中加上了回答 agent 提问的按钮，团队负责审阅与合并。

压力测试也暴露了问题：部分新 agent 在初始化时缺少通往世界某些部分的路线，有的路线在 compaction 后才浮现。因为能在脑中可视化这个世界，他可以在"火线"中问出简单问题——是知识缺失，还是路断了？再让 agent 帮忙追踪并修复路径。这正是让人可读的世界带来的回报：系统在运行和扩张中仍可维护。

rig spec 与 rig bundle：把整个团队打包分享

另一条并行线是让人类更容易上手 OpenRig。团队共享已有 skills 机制，但若要分享一整个团队——agent 名字、规格、技能、插件、启动上下文、治理方式与协作方式——OpenRig 提供了 rig spec：一个描述这些如何拼合的 YAML 文件；rig bundle 则是完全水合的版本，蓝图加所需文件，打包成单个仓库甚至 zip。他用它跨新机器扩容，把团队空投到一台 VPS 上并宣布"你是构建团队、你是审查团队"。

他在 openrig.dev 的 rigs 页面开放提交，类似 skill 注册表。他推荐其中的 workshop——一个基于模板的四 agent 开发团队 rig bundle，实际用于构建 OpenRig 本身。动机很直接：既然 PR 洪流是开源项目的普遍问题，给想帮忙的人一个起点去创建或审查 PR 会很有价值。这个 bundle 也是他如何拼接各部分的参考，可自定义或提交自己的 rig。他眼下最需要的是对更多 harness 的支持，这对他个人测试很难，正好用这个模型做实验——看它能否成为帮助其他开源项目的可复制方式。

一个尚未终结的问题

重复造轮子这个问题，开始好笑，然后烦人，最后变成一堵不解决就无法扩张的墙。答案不是再加一个搜索工具，因为问题发生在搜索之前——agent 根本不知道该问什么。世界构建的思路是：由他决定地图上有什么、并说明如何找到地图之外的东西，让智能体在不被逐条解释的情况下也能胜任工作。他在视频里也在对观众使用这套技巧：你已经知道 ontology、城堡、故事、道路，他只把陌生概念放进一个世界并连到你已知的事物上，剩下的连接交给你的大脑完成。在他看来，这正是上下文工程接下来要去的地方。

说明：本文基于单一视频来源整理，其中关于工具命名、命令与机制的细节以原作者表述为准，实际使用请以项目文档为准。