从 Prompt 到完成工作：一套可复现的 Holon 工作流

这是一套实用工作流，不是“Agent 可以替代审阅”的承诺。Agent 能修改什么、结果是否可接受，仍由你决定。

很多 Agent 演示在模型给出一段自信的回答时就结束了。真实工作往往从这里才开始。

你还需要检查仓库、修改正确的文件、运行检查、等待命令或审阅结果，并判断交付物是否值得保留。如果终端在中途关闭，你还需要回到同一项工作，而不是重新拼接整段对话背景。

Holon 面向的正是这个间隙。它是一套用于持续工作的本地 Agent 工作台。运行时会保留 Agent、工作区和被跟踪的任务，让任务可以继续执行、等待，或在需要时向你请求输入。

本文演示一套小而可复现的流程：

1. 选择一项边界清楚的仓库任务；
2. 以持久模式启动 Holon；
3. 创建 Agent 和 WorkItem；
4. 让 Agent 在你断开连接后继续工作；
5. 回到工作区，检查结果证据。

重要的交付物不是更长的对话，而是一个可以检查的结果。

先选一项有明确终点的工作

第一次尝试持久工作时，任务应该是真实的，但要小到让你能判断结果是否正确。合适的例子包括：

• 增加一条校验错误信息及其测试；
• 更新文档中的命令并检查链接；
• 修复一个有现成回归测试覆盖的窄问题；
• 审阅一个 Pull Request，并记录仍存在的问题。

不要一开始就说“改进整个代码库”，也不要从没有边界的研究项目开始。持久运行时可以保存大任务，但不能让一个模糊的目标更容易审阅。

下面假设你要改善仓库中“配置值无效”时显示的错误信息。具体文件会因项目而异，但边界不应该改变：

先检查仓库当前如何处理无效配置值。
为这项修改创建一个被跟踪的 WorkItem。
完成最小有效实现，并增加或更新一个聚焦测试。
运行相关检查。
最后列出修改过的文件、运行过的检查，以及仍需要我决定的事项。
不要做无关的清理。

这个 Prompt 给 Agent 一个目的和停止条件。它没有要求模型在检查仓库以前就假装工作已经完成。

选择一次性执行，还是持久执行

Holon 支持快速的一次性命令：

holon run "What is Holon?"

当任务可以在一轮内完成，也不需要保存生命周期时，这种模式很合适。如果任务可能跨越多个命令、会话、等待条件或人工输入，就使用后台服务：

holon daemon start
holon daemon status

后台服务独立于 TUI 连接保持运行。终端是你与任务交互的方式，不等于任务本身。

这里需要把边界说清楚。终端断开并不意味着所有任务都会自动继续。后台服务、模型提供商、工作区和权限仍需正确配置并保持可用。但在正常情况下，TUI 断开不再等同于放弃任务。

给任务分配 Agent 和 WorkItem

如果需要一个明确角色，可以从已安装或同步的模板创建命名 Agent：

holon agent create builder --template software-developer

然后连接运行时：

holon tui

在 TUI 中，把任务描述为需要被跟踪的工作，而不只是一个问题：

我需要改善这个仓库中无效配置值的错误信息。
请创建一个带简短计划和验收检查的 WorkItem。
先检查当前行为，完成最小修改，运行聚焦测试；
如果范围或实现选择不清楚，就停下来等待我的输入。

WorkItem 是 Holon 中被持久跟踪的工作单位。它保存目标、计划、进度、等待状态和完成条件。这样，命令完成或人重新连接后，Agent 有一个可以回到的工作对象，而不是只有一段 Prompt。

你不需要为每个问题创建 WorkItem。官网参考文档建议：当工作跨越多轮、需要可恢复进度、等待外部状态，或有值得明确跟踪的验收条件时使用它。快速解释通常直接使用 holon run 更简单。

离开终端，但不要丢掉任务

当 Agent 已创建 WorkItem 并开始执行后，可以断开 TUI：

Ctrl+C

后台服务和 Agent 会独立于这条连接继续运行。之后可以从另一个终端检查命名 Agent：

holon agent status builder

也可以重新连接 TUI：

holon tui

有用的问题不是“模型有没有又发一条消息”，而是“这项工作现在处于什么状态”。Agent 可能正在修改文件、等待命令、等待你的决定，或等待外部事件。

让等待成为工作流的一部分

长任务很少会在一轮模型调用中不间断完成。构建可能需要时间；实现选择可能需要你批准；CI 可能稍后才返回。

Holon 会把这些情况表示为明确的等待条件。

等待命令结果

当 Agent 运行构建、测试或 lint 命令时，命令可以作为后台任务继续运行，Agent 则休眠或处理其他工作：

运行聚焦测试，等待结果后再写完成总结。

关键在于：测试结果成为工作状态的一部分。“我觉得测试通过了”不等于有一条真实的命令结果。

等待你的决定

如果 Agent 找到两种合理方案，它可以让 WorkItem 保持需要输入，而不是悄悄替你做决定：

我找到了两种处理无效值的方式：
方案 A 保留现有错误类型，只改善错误信息。
方案 B 新增一个错误变体。
你希望保留哪条边界？

你可以稍后通过 TUI、CLI prompt 或 HTTP API 回复。决定会附着在持续进行的工作上，而不是留在已关闭的终端里。

等待外部事件

对于 CI、Webhook 或定时事件，Holon 可以等待外部触发：

分支已经准备好。等待 CI 检查完成后，再建议下一步。

运行时会记录等待对象和等待原因。配置好的事件唤醒 Agent 后，它可以检查新的状态并继续；如果检查失败，也可以更新 WorkItem。

回来时检查证据，而不是只看自信程度

当 Agent 说任务完成后，要同时检查仓库里的结果和工作记录。一个有用的审阅会问：

• 哪些文件发生了变化？
• 修改是否仍在请求范围内？
• 哪条命令或测试真正运行过？
• 命令是否成功结束？
• 是否存在仍需决定的事项、失败检查或已知限制？
• 其他人能否从 WorkItem 和完成简报理解发生了什么？

Holon 的完成简报就是为了把最后的交接明确记录下来。长任务指南展示了包含目标、修改和验证结果的简报。你也可以随时查看完整记录和 Agent 状态：

holon transcript
holon agent status builder

如果这类工作会反复出现，可以要求每次都使用同一份简短交接格式：

结果：用一句话描述最终结果。
修改：列出改动过的文件或外部记录。
检查：列出运行过的命令及其结果。
等待：如果还有决定、事件或后续动作，写清楚它们。

这样你就能快速浏览多项已完成工作，而不必重新阅读每一轮模型调用；如果任务需要再做一轮，下一位执行者也能马上找到开始的位置。

最后的判断仍属于你。打开 diff，阅读相关测试；如果修改值得更严格的确认，再运行额外检查。完成简报是关于工作过程的证据，不是工程判断的替代品。

这套流程能做什么，不能承诺什么

当 Prompt 只是工作的开始时，这套流程很有用。它给任务一个持久的归属，让等待状态可见，并在连接断开后保留回到工作区的路径。

它不能保证 Agent 选择了正确实现，也不会赋予 Agent 原本没有配置的权限。它不会把外部系统自动变成可信输入，也不会替你合并代码或批准发布。如果你要把运行时暴露到本机之外，应遵循部署和访问控制文档，不要把“持久运行”当作“隔离”。

从一个你能写出验收检查的任务开始。把工作区和权限保持在必要范围内。当 Agent 需要决定时，让它停下来。然后检查它交回来的结果。

下一步

先按创建第一个 Agent安装 Holon、配置模型提供商；如果任务需要在断开连接后继续，或需要等待结果，再阅读运行长期任务，并把上面的 Prompt 改成适合你仓库的版本。