--- title: “从 Prompt 到完成工作：一套可复现的 Holon 工作流” summary: “给 Agent 一项真实的仓库任务，让它在 Prompt 结束后继续工作，并在回来时检查结果。” order: 50 --- # 从 Prompt 到完成工作：一套可复现的 Holon 工作流 Holon Agent 工作台展示持续进行的任务、进度和待检查结果。 > 这是一套实用工作流，不是“Agent 可以替代审阅”的承诺。Agent 能修改什么、结果是否可接受，仍由你决定。 很多 Agent 演示在模型给出一段自信的回答时就结束了。真实工作往往从这里才开始。 你还需要检查仓库、修改正确的文件、运行检查、等待命令或审阅结果，并判断交付物是否值得保留。如果终端在中途关闭，你还需要回到同一项工作，而不是重新拼接整段对话背景。 Holon 面向的正是这个间隙。它是一套用于持续工作的本地 Agent 工作台。运行时会保留 Agent、工作区和被跟踪的任务，让任务可以继续执行、等待，或在需要时向你请求输入。 本文演示一套小而可复现的流程： 1. 选择一项边界清楚的仓库任务； 2. 以持久模式启动 Holon； 3. 创建 Agent 和 WorkItem； 4. 让 Agent 在你断开连接后继续工作； 5. 回到工作区，检查结果证据。 重要的交付物不是更长的对话，而是一个可以检查的结果。 ## 先选一项有明确终点的工作 第一次尝试持久工作时，任务应该是真实的，但要小到让你能判断结果是否正确。合适的例子包括： - 增加一条校验错误信息及其测试； - 更新文档中的命令并检查链接； - 修复一个有现成回归测试覆盖的窄问题； - 审阅一个 Pull Request，并记录仍存在的问题。 不要一开始就说“改进整个代码库”，也不要从没有边界的研究项目开始。持久运行时可以保存大任务，但不能让一个模糊的目标更容易审阅。 下面假设你要改善仓库中“配置值无效”时显示的错误信息。具体文件会因项目而异，但边界不应该改变： ```text 先检查仓库当前如何处理无效配置值。 为这项修改创建一个被跟踪的 WorkItem。 完成最小有效实现，并增加或更新一个聚焦测试。 运行相关检查。 最后列出修改过的文件、运行过的检查，以及仍需要我决定的事项。 不要做无关的清理。 ``` 这个 Prompt 给 Agent 一个目的和停止条件。它没有要求模型在检查仓库以前就假装工作已经完成。 ## 选择一次性执行，还是持久执行 Holon 支持快速的一次性命令： ```bash holon run "What is Holon?" ``` 当任务可以在一轮内完成，也不需要保存生命周期时，这种模式很合适。如果任务可能跨越多个命令、会话、等待条件或人工输入，就使用后台服务： ```bash holon daemon start holon daemon status ``` 后台服务独立于 TUI 连接保持运行。终端是你与任务交互的方式，不等于任务本身。 这里需要把边界说清楚。终端断开并不意味着所有任务都会自动继续。后台服务、模型提供商、工作区和权限仍需正确配置并保持可用。但在正常情况下，TUI 断开不再等同于放弃任务。 ## 给任务分配 Agent 和 WorkItem 如果需要一个明确角色，可以从已安装或同步的模板创建命名 Agent： ```bash holon agent create builder --template software-developer ``` 然后连接运行时： ```bash holon tui ``` 在 TUI 中，把任务描述为需要被跟踪的工作，而不只是一个问题： ```text 我需要改善这个仓库中无效配置值的错误信息。 请创建一个带简短计划和验收检查的 WorkItem。 先检查当前行为，完成最小修改，运行聚焦测试； 如果范围或实现选择不清楚，就停下来等待我的输入。 ``` **WorkItem** 是 Holon 中被持久跟踪的工作单位。它保存目标、计划、进度、等待状态和完成条件。这样，命令完成或人重新连接后，Agent 有一个可以回到的工作对象，而不是只有一段 Prompt。 你不需要为每个问题创建 WorkItem。官网参考文档建议：当工作跨越多轮、需要可恢复进度、等待外部状态，或有值得明确跟踪的验收条件时使用它。快速解释通常直接使用 `holon run` 更简单。 ## 离开终端，但不要丢掉任务 当 Agent 已创建 WorkItem 并开始执行后，可以断开 TUI： ```text Ctrl+C ``` 后台服务和 Agent 会独立于这条连接继续运行。之后可以从另一个终端检查命名 Agent： ```bash holon agent status builder ``` 也可以重新连接 TUI： ```bash holon tui ``` 有用的问题不是“模型有没有又发一条消息”，而是“这项工作现在处于什么状态”。Agent 可能正在修改文件、等待命令、等待你的决定，或等待外部事件。 ## 让等待成为工作流的一部分 长任务很少会在一轮模型调用中不间断完成。构建可能需要时间；实现选择可能需要你批准；CI 可能稍后才返回。 Holon 会把这些情况表示为明确的等待条件。 ### 等待命令结果 当 Agent 运行构建、测试或 lint 命令时，命令可以作为后台任务继续运行，Agent 则休眠或处理其他工作： ```text 运行聚焦测试，等待结果后再写完成总结。 ``` 关键在于：测试结果成为工作状态的一部分。“我觉得测试通过了”不等于有一条真实的命令结果。 ### 等待你的决定 如果 Agent 找到两种合理方案，它可以让 WorkItem 保持需要输入，而不是悄悄替你做决定： ```text 我找到了两种处理无效值的方式： 方案 A 保留现有错误类型，只改善错误信息。 方案 B 新增一个错误变体。 你希望保留哪条边界？ ``` 你可以稍后通过 TUI、CLI prompt 或 HTTP API 回复。决定会附着在持续进行的工作上，而不是留在已关闭的终端里。 ### 等待外部事件 对于 CI、Webhook 或定时事件，Holon 可以等待外部触发： ```text 分支已经准备好。等待 CI 检查完成后，再建议下一步。 ``` 运行时会记录等待对象和等待原因。配置好的事件唤醒 Agent 后，它可以检查新的状态并继续；如果检查失败，也可以更新 WorkItem。 ## 回来时检查证据，而不是只看自信程度 当 Agent 说任务完成后，要同时检查仓库里的结果和工作记录。一个有用的审阅会问： - 哪些文件发生了变化？ - 修改是否仍在请求范围内？ - 哪条命令或测试真正运行过？ - 命令是否成功结束？ - 是否存在仍需决定的事项、失败检查或已知限制？ - 其他人能否从 WorkItem 和完成简报理解发生了什么？ Holon 的完成简报就是为了把最后的交接明确记录下来。长任务指南展示了包含目标、修改和验证结果的简报。你也可以随时查看完整记录和 Agent 状态： ```bash holon transcript holon agent status builder ``` 如果这类工作会反复出现，可以要求每次都使用同一份简短交接格式： ```text 结果：用一句话描述最终结果。 修改：列出改动过的文件或外部记录。 检查：列出运行过的命令及其结果。 等待：如果还有决定、事件或后续动作，写清楚它们。 ``` 这样你就能快速浏览多项已完成工作，而不必重新阅读每一轮模型调用；如果任务需要再做一轮，下一位执行者也能马上找到开始的位置。 最后的判断仍属于你。打开 diff，阅读相关测试；如果修改值得更严格的确认，再运行额外检查。完成简报是关于工作过程的证据，不是工程判断的替代品。 ## 这套流程能做什么，不能承诺什么 当 Prompt 只是工作的开始时，这套流程很有用。它给任务一个持久的归属，让等待状态可见，并在连接断开后保留回到工作区的路径。 它不能保证 Agent 选择了正确实现，也不会赋予 Agent 原本没有配置的权限。它不会把外部系统自动变成可信输入，也不会替你合并代码或批准发布。如果你要把运行时暴露到本机之外，应遵循部署和访问控制文档，不要把“持久运行”当作“隔离”。 从一个你能写出验收检查的任务开始。把工作区和权限保持在必要范围内。当 Agent 需要决定时，让它停下来。然后检查它交回来的结果。 ## 下一步 先按[创建第一个 Agent](/zh-CN/getting-started/first-agent)安装 Holon、配置模型提供商；如果任务需要在断开连接后继续，或需要等待结果，再阅读[运行长期任务](/zh-CN/guides/run-long-lived-task)，并把上面的 Prompt 改成适合你仓库的版本。