Holon 是什么：让多个 Agent 在你的工作环境里持续做事

文中的任务指令用于说明使用方式，实际实践见团队案例。

Holon 是供多个 Agent 持续工作的本地工作台。把它运行在自己的电脑或远程开发机上，你可以让不同 Agent 负责开发、审阅、文档和运维，通过终端或浏览器交代工作、查看进展，在需要时介入。

Agent 使用那台机器上的项目和工具。你可以交给它一次修改，也可以让它长期负责一类工作：遇到需要等待的测试、反馈或人工确认，先保存进度，条件满足后再继续。

为什么要有这样一个工作台？

写代码、查资料、运行命令，已经有很多好用的 Agent 工具。我们做 Holon，关注的是这些能力怎样成为日常工作的一部分：负责审阅的 Agent 能不能保留它的职责和约定？一项工作停下来之后，能不能找到它在等什么？开发环境在远程机器上时，能不能换一个操作入口，继续使用原来的 Agent 和项目？

这会影响你组织工作的方式。你可以在一台开发机上维护几个各有分工的 Agent，随时连接；也可以把调查、审阅等共同职责交给团队服务器上的共享 Agent，让结果进入团队已有的 Issue 和测试记录。

当你希望把“帮我审一下”变成“持续负责这个仓库的审阅”，就需要保留职责、项目环境和未完成的工作。Holon 把这些放在一起管理，让一次次临时请求逐渐成为可以长期交给固定角色的工作。

把一项工作交出去，需要时再接入

以持续审阅为例：你希望 reviewer 检查 PR，跟进后续修改和 CI，在满足约定条件后完成合并，而不只是给出一次审阅意见。下面用一项委托说明这个过程。

找到负责这件事的 Agent

打开客户端，你可以选择要合作的 Agent。与其每次建立一段没有分工的新对话，不如把重复发生的工作交给固定角色：开发 Agent 处理修改，reviewer 检查风险，文档 Agent 维护说明。

假设你已经为 reviewer 配置好仓库访问权限，并授权它在审查通过、CI 满足要求且没有阻塞反馈时合并 PR。选择它，交代本次的范围：

跟进这个 PR：〈填入 PR 链接〉，重点检查兼容性和回归风险。运行必要的本地检查，记录问题并跟进修改。合并前重新核对最新提交、CI 和阻塞反馈；满足约定条件后合并，报告审阅与合并结果。遇到有争议的取舍，或需要跳过检查时，先问我。不要发布。

这里不用重新讲一遍 reviewer 的全部职责。长期的审阅标准和授权范围可以保留在它的配置里，你只补充这一次要检查什么。我们实际使用的 holon-reviewer 和 tuptup-reviewer 都承担了这种有条件合并的职责；新建一个 reviewer 并不会默认获得同样的授权。

让它在后台跟进

reviewer 进入项目，阅读变更，调用本地工具执行检查，并为这次持续跟进建立工作项，记录目标、计划和进度。发现问题后，它留下审阅意见，等待开发者修改；新提交到达后，再核对问题是否解决。

本地测试还在运行、CI 尚未结束、开发者还没提交修改，都可能让工作暂时停下来。reviewer 保留进度，等到有结果再继续，不需要你守着对话窗口反复催问。若要跟随 GitHub 上的 CI 或新提交唤醒，需配置相应事件接入；也可以先由你把结果交给 Agent。

后台服务和宿主机保持运行时，关闭终端或浏览器不会结束这项委托。无需你判断的部分可以继续推进；遇到有争议的兼容性取舍，reviewer 则说明问题，等你决定。

随时接入，查看和调整工作

把工作交到后台，不应意味着只能等它发回结果。你需要知道它做到哪一步，卡在什么地方，也需要一个能补充判断、调整要求的入口。Holon 的终端 TUI 和 Web GUI 让你连接到原来的 Agent 与工作项，不必为了一次介入重新建立任务。

打开工作项，可以看到计划、检查清单和等待原因。如果是在等 CI，你可以了解进度后离开；如果需要你决定兼容范围，就直接补充要求，让它继续。下图展示了 reviewer 已复核新提交、正在等待 CI 结果的状态。

Web 工作台演示：新提交已复核，正在等待 CI，后续步骤保存在同一个工作项中。截图使用演示数据，点击可查看大图。

如果需要判断兼容范围，你可以确认“保留旧接口，补充回归测试”，reviewer 就按这一要求继续跟进后续修改。目标、已有发现和待检查项仍属于同一项工作。如果你另外授权它安排修复，它也可以把修改委托给子 Agent，再接回结果复查。

完成后，留下可核对的结果

满足合并条件后，reviewer 完成已获授权的合并，留下本次交付：审阅的是哪个版本，发现的问题怎样解决，哪些检查通过，以及对应的 PR 与合并记录。如果没有完成合并，也要说清楚还缺什么条件，而不是只回复“审阅完成”。

Holon 将这份完成报告与内部执行轨迹分开。你可以从报告进入实际的变更、测试结果和工作记录；需要追查某个判断时，再查看工具输出与执行依据。

这也是一项工作明确结束的地方。Agent 可以继续承担下一次审阅，但这次工作的范围和结果应留下独立记录。

让这种工作方式可以反复使用

一次演示可以在一个窗口里做完。日常使用则需要让角色、项目和未完成的工作在窗口之外继续存在。Holon 在这几个地方做了相应的安排。

工作环境常驻，操作入口可以更换

Holon 的后台 Runtime 管理 Agent 的执行和工作状态，终端 TUI 与 Web GUI 是连接它的入口。项目和工具跟着运行环境走，而不是跟着某个客户端窗口走。

这对远程开发很直接：编译器、仓库和测试环境已经在开发机上，就让 Agent 在那里运行。你从浏览器查看结果，或通过终端继续交代要求，连接的仍是同一个后台。

后台与宿主机需要保持可用，关闭客户端和关闭运行环境是两回事。图中的机器边界说明运行位置，不代表额外的权限隔离。

这里的“本地”指运行 Holon 的那台机器，可以是笔记本，也可以是远程服务器。你决定项目、工具和工作记录放在哪里。

为什么需要不同角色，而不只是多个聊天窗口

让两个 Agent 讨论同一份代码，并不等于建立了协作。谁负责修改，谁判断修改是否回应了问题，意见不一致时由谁决定？如果这些没有约定，再多一轮对话也可能只是重复争论。

角色首先要划清决策边界。沿用熟悉的 PR 工作流就能说清楚：开发 Agent 提交修改并回应问题，reviewer 检查风险与验证依据，在授权范围内判断是否可以合并；有争议或超出范围的取舍交给你决定。前面的示例授权了条件合并，没有授权发布。这些约定来自你交给它的职责，而不是“reviewer”这个名字。

另一个理由是工作可以独立推进。开发 Agent 修复接口时，文档 Agent 可以检查已经稳定的使用说明。但如果一次改动紧密牵涉前后端，放在同一个 Agent 里完成可能更直接，不必为了分工增加交接。

长期角色还值得保留各自的经验。测试 Agent 可以维护容易遗漏的回归场景，运维 Agent 可以记录日志位置、排查步骤和需要人工确认的操作。这些材料需要随着实际工作修订；它们比每次从头说明职责更适合反复合作。

把角色和经验留在 AgentHome

每个 Agent 有自己的 AgentHome，用来保存职责、记忆和自身材料。其中的 AGENTS.md 可以记录角色契约：负责什么、哪些事情可以直接做、哪些必须请你确认。这份文件记录已有授权，不会因为 Agent 改了文字就扩大实际权限。

角色约定与项目规则也有区别。reviewer 的审阅职责放在它自己的 AgentHome；某个仓库如何构建、怎样测试，则留在对应工作区。这样，换到另一个项目时可以沿用审阅方法，同时遵守那个项目的具体要求。

创建角色时，可以从模板开始；重复使用的方法可以整理成 Skills，例如审阅步骤、文档检查或日志排查。临时需要一次独立复核，也可以委托子 Agent，接回结果后结束，不必为每个小任务都维护一个长期角色。配置方式见 Agent 模板与 Skills 参考。

把未完成的事留下来，等有条件时继续

在 Holon 中，长期存在的是 Agent，有起点和验收条件的是一项项工作。WorkItem 就是这样的工作记录：它保存目标、计划、进度、等待条件和最后的完成报告。

有了这份记录，“等待测试结果”和“已经交付”便是不同的状态。Agent 等待时让出执行；任务结果、操作者输入或已接入的外部事件到达后，Runtime 再安排它继续。模型不需要一直循环询问结果有没有出来。

这适合跨越多次反馈的审阅，也适合分阶段确认的文档、调查和验收。普通问答仍然可以直接结束，不必为解释一条命令建立完整工作项。

WorkItem 不是无限上下文或无损恢复的保证。它提供需要持续维护的工作依据，让 Agent 和人都能检查目标是否改变、下一步是否仍然合理。有关保存内容与等待机制，另见《Holon 的 WorkItem 架构：把工作状态从对话中分离》。

让 Agent 直接在你的项目里工作

Agent 可以直接使用运行 Holon 那台机器上的仓库、shell 和工具链。接入已有项目后，它按项目规则修改文件、运行测试；起草文档后，可以构建站点检查页面。你拿到的是工作区里的实际修改和验证结果，可以继续编辑、审阅或提交。

一个 Agent 可以绑定多个工作区，并在它们之间切换。比如新增一个接口，需要先修改服务端，再更新 SDK，最后调整使用它的应用。开发 Agent 可以围绕同一个目标，逐步完成各仓库的修改和验证；各项目的代码、构建方式和指导文件仍留在各自目录里。需要隔离修改时，还可以为对应仓库创建独立 Git worktree。具体用法见工作区参考。

模型与图片工具可按工作需要配置，例如为文档准备配图、读取页面截图做检查。使用远程模型时，请求仍会发送到相应服务，需要按项目的数据要求选择模型和发送的材料。支持范围和所需凭据见模型参考、图片理解与图片生成参考。

团队共享的，是职责和工作结果

个人可以用 Holon 组织自己的远程开发环境。团队则可以把共同需要的角色放到服务器上，让成员围绕同一项工作交接，而不必每个人都从头调查一次。角色分工不替代系统权限与访问控制；服务器的网络、凭据和实际访问范围仍需由部署者管理。

在小团队的 Agent Native 实践中，共享 Agent 已经承担调查、审阅、运维和验收跟进。设备出现故障后，调查 Agent 根据日志与问题记录整理分析，把结果写进 GitHub Issue；修复后的版本可测时，测试 Agent 继续核对，把必须真机操作的部分交给测试人员，再接回反馈。

这里的协作发生在团队原有的工作记录里。开发者继续使用自己的编码工具，Agent 跟进共同职责，测试人员完成设备操作。怎样接收工作、结果写到哪里、遇到阻塞找谁，都需要明确安排。第四篇记录了这些具体交接，而不仅是团队里有几个 Agent。

如果你想先尝试一项更窄的职责，可以从 一个 PR，一个工作项 中的持续审阅流程开始，再根据团队需要增加角色。

从一个 Agent 和一个新项目开始

你不必先准备一个项目，再启动 Agent。按第一个 Agent完成安装、模型配置并创建 Agent，就可以让它帮你建立接下来要维护的项目：

帮我创建一个个人笔记网站。先给出最小方案和项目目录建议，等我确认后再初始化 Git 仓库，把项目接入你的工作区并切换过去，完成一个可本地预览的首页。运行必要检查，告诉我如何预览；不要对外发布。

收到方案后，可以先断开客户端，再重新连接，找到原来的 Agent 和工作项。确认方案与目录，让它继续创建项目、接入工作区并完成首页。最后按它提供的方式预览，检查文件是否写进新仓库、验证是否通过。

这次尝试不需要预先接入 GitHub 事件。你可以在方案阶段介入，确认后让 Agent 继续执行；项目也是在这个过程中建立的。项目完成后，Agent 仍然存在，可以继续维护这个网站，也可以接手下一个项目。