长时应用开发的 Harness 设计

导读

本文围绕长时应用开发讨论 harness 设计：如何把目标、状态、工具、验证和恢复机制组织起来，让 agent 能跨多轮持续推进真实软件工程任务。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• 长时应用开发不是一次 prompt 能解决的问题，而是持续规划、执行、观察和修正的闭环。
• harness 的职责是把模型能力包进可靠工作流，而不是替模型写死所有路径。
• 状态需要分层：任务目标、当前计划、已知约束、代码事实和验证结果应分别管理。
• 工具接口要支持可恢复操作，避免一次命令失败就丢失整轮上下文。
• checkpoint、diff、测试和运行日志是长时 agent 的事实来源。
• 好的 harness 会限制破坏性动作，同时让低风险探索尽量顺畅。
• context compaction 应保留决策原因和未完成问题，而不只是摘要聊天记录。
• 人类介入点应放在需求澄清、架构选择、权限提升和发布前验证。

正文

原文主线

本文围绕长时应用开发讨论 harness 设计：如何把目标、状态、工具、验证和恢复机制组织起来，让 agent 能跨多轮持续推进真实软件工程任务。

为什么应用开发需要 harness

应用开发任务往往跨越多个文件、多个测试循环和多个设计决策。模型如果只依赖当前 context window，很容易忘记早期约束，或者在修复一个 bug 时破坏另一处行为。harness 的作用，是把这种长链路工作组织成可观察、可恢复、可验证的系统。

与短任务不同，长时开发的难点不只是生成代码，而是持续维护问题边界。agent 需要知道当前目标是什么、哪些假设已经被验证、哪些命令失败过、哪些文件属于修改范围，以及何时应该停止。

状态分层

一个实用 harness 应把状态分成几类：用户目标、实现计划、项目事实、执行日志、测试结果和开放问题。用户目标通常变化慢，执行日志变化快；把它们混在同一个聊天历史里，会让 context 变得嘈杂。

更稳的做法是让 agent 在关键节点写出结构化 notes，例如当前策略、已修改文件、失败测试、下一步动作和需要用户判断的问题。compaction 时优先保留这些结构化事实。

工具与验证

开发 harness 的工具不应只是 shell。它还需要清晰的读文件、搜索、patch、测试、截图、服务启动和 diff 查看能力。每个工具返回值都应该帮助下一步决策，而不是把无关日志全部塞进 context。

验证是 harness 的中心。没有测试命令、构建命令或手工验收步骤，agent 会倾向于把“代码看起来合理”误认为完成。长时任务里，每个阶段都应该有局部验证，最终再做全局验证。

恢复与人类介入

长任务一定会失败：命令超时、依赖缺失、测试 flaky、需求理解偏差、权限不足。harness 应把失败转化为可恢复状态，而不是让 agent 不断重试同一路径。checkpoint 和 rewind 可以让探索保持低成本。

人类介入不应只在失败后出现。更好的点位是：需求含糊时、需要修改公共接口时、需要提升权限时、需要删除数据时、以及准备发布前。这样 harness 既保护系统，也不会把 agent 绑到无法行动。

深度解读

这篇主题的关键，是把 agentic coding 从“模型会写代码”推进到“系统能持续承载开发过程”。长时任务中，真正稀缺的不是单次生成能力，而是连续性：目标连续、状态连续、验证连续、责任边界连续。harness 就是这种连续性的工程化载体。它不应该过度控制模型，而应该给模型一个可靠的工作台：能查事实、能动手、能验证、能回滚、能在不确定时找人。做到这一点，agent 才能从代码补全工具变成真正的开发协作者。

落地启示

• 给每个长时任务定义明确验收条件，而不是只等 agent 自报完成。
• 把关键事实写入结构化 notes 或 session log，避免只依赖压缩后的聊天历史。
• 为测试、截图、构建和 diff 设计一等工具，让验证成为默认路径。
• 对删除、发布、权限提升等动作设置明确人类确认点。
• 保留失败命令和失败原因，帮助后续恢复而不是重复踩坑。