一个智能体是工具,四个智能体是团队
单个 AI 智能体已经很有用——问一个问题,得到一个答案。但大多数真实工作并不是一个问题。它是一个循环:研究某件事、起草一个变更、审查它、把它写下来。一个通才型智能体会把四件事都做了,但哪一件都做得不特别好,到一半它的上下文还会开始混乱。
Office Claws 就是为同时运行多个智能体而构建的。每个智能体都有自己的 VPS、自己的系统提示词,以及像素办公室里自己的工位。有意思的问题不是你能不能同时运行四个智能体,而是每一个该做什么。
一个简单的四角色设置
下面这个设置是我们大多数日子里内部使用的。每个角色都有狭窄的职责范围,以及专为该范围写的提示词。
研究员
系统提示词专注于寻找和总结信息。没有代码,没有观点——只有带来源的事实。
适用于:浏览长帖、收集 API 文档、提取发布说明、比较库。
把它和拥有较大上下文窗口的模型搭配使用。Claude Sonnet 4.6 是一个合理的默认选择。
构建者
系统提示词专注于写代码和改代码。它应该被允许运行测试、读取文件和做小的 commit,但不能 push 分支。
适用于:修 bug、小功能、在单个文件内完成的重构。
把你承担得起的最强编码模型交给这个角色。一次糟糕补丁的时间成本,高于一个更好模型的 token 成本。
审查员
系统提示词专注于阅读构建者的 diff 并找出问题。它从不写代码。它写关注点——安全、正确性、清晰度——并指向具体的行。
适用于:捕捉那种你会漏掉的错误,因为你累了,而 diff 有 400 行。
记录员
系统提示词专注于把已完成的工作变成文字——发布说明、内部更新、commit 信息、博客草稿。
适用于:那段否则会被跳过的、无聊的最后一公里。
为什么分开的提示词比分开的模型更重要
人们很容易以为诀窍是用四个不同的模型。通常诀窍是用四个不同的提示词。同一个模型在「你是高级审查员,不写代码,只找问题」下的行为,几乎完全不同于在「你是有帮助的结对编程伙伴」下的行为。
这里的关注点分离是真正的工程原则,而不仅仅是组织卫生:
- 聚焦的系统提示词占用更少的上下文开销,为实际工作留出更多空间
- 狭窄的职责范围让智能体更容易评估——你知道好的输出长什么样
- 出问题时,你知道该怪哪个智能体、该调哪个提示词
工作如何在智能体之间流转
Office Claws 目前还没有自动的智能体间交接。你就是路由器。实际操作看起来是这样的:
- 问研究员一个问题,复制总结
- 把总结粘贴给构建者,并给出具体指令
- 把得到的 diff 粘贴给审查员,问「你会改什么?」
- 当构建者第二轮落地后,把最终 diff 粘贴给记录员写发布说明
在纸面上这看起来笨拙,实际用起来却意外地自然。像素办公室在这里帮了大忙——每个智能体都有自己的工位,所以你始终知道哪个上下文属于谁。没有浏览器标签页,不会出现「等等,API 文档在哪个对话里来着?」。
成本说明
跑四个智能体并不等于跑一个的四倍成本。大部分成本是 token,而 token 的规模取决于你和一个智能体说了多少话,而不是存在多少个智能体。
在自托管方案下,每个智能体都是一个独立的 DigitalOcean droplet,所以你是要为基础设施付费的。每个智能体每月 4 美元的基础 droplet 累积起来不是小数,但仍然明显低于大多数 SaaS 座位费。在托管方案下,每增加一个智能体每月 14.99 美元。
如果只是在试水,就从两个开始:一个研究员和一个构建者。等你确认自己真的需要时,再加上另外两个。
不要做什么
- 不要让某个智能体来「管理」其他智能体。 目前还没有智能体到智能体的协议,让一个智能体去协调其他智能体,只会让它臆想出工作流
- 不要把每种工具都给每个智能体。 审查员不需要写文件的权限。记录员不需要编译器
- 不要换个名字却用同一个系统提示词。 如果两个智能体用同一个提示词,你就不是有两个智能体——你是有一个智能体在为两台 droplet 付费
下一步方向
我们正在做几件事,让多智能体设置不那么手动:
- 保存好的角色预设 —— 一键完成「研究员」「构建者」「审查员」配置
- 跨智能体复制 —— 选中一个智能体的输出,不离开应用就发给另一个
- 智能体到智能体的消息 —— 实验性的、受限发布的,只有等我们确认它不会单纯放大错误时才会上线
在那之前,手动流转是一个特性,不是限制。真正知道工作是什么的人,是你。