Harness 三大设计模式
工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务，构建 Agent 运行时的三个基石
本页解决的问题
先给结论「Harness 三大设计模式」要解决的关键问题是什么？
工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务，构建 Agent 运行时的三个基石
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
- Plan → Execute → Observe/Test → Improve → Execute again：每一轮生成都是下一轮优化的起点。
- 分析自身轨迹：优秀的 Agent 会回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个 Prompt。
- 强调运行时迭代：改进发生在 Agent 执行过程中，不依赖人类事先写好的静态模板。Agent 在每次执行中学习、适应、优化。
- 失败是信号，不是终止：测试不通过、命令报错、输出不符合预期，这些都是 Agent 自我纠正的触发条件。
- 制品种类繁多：实验日志、代码 diff、论文摘要、错误追踪记录、过去的完整执行轨迹，这些都是有价值的状态，但塞不进上下文。
- Harness 的正确做法：把持久状态存在文件系统中，让 Agent 学会按需读写。不要试图把全部工作历史压入 Prompt。
- 文件读写是 LLM 基础技能：读写文件系统不需要复杂的外部工具链，它受益于核心模型能力的提升。模型越聪明，文件管理越高效。
- 结构化存储：好的 Agent 会自己维护 scratchpad、todo 列表、实验记录，像人类程序员一样管理工作区。
放文件系统中：历史实验结果、累积的错误日志、已完成子任务的摘要、长期策略和规则，这些是需要持久保存但不必时刻在视野中的信息。
关键原则：上下文是工作记忆，文件系统是长期记忆。好的 Harness 像人脑一样，在两者之间智能地搬运信息。
- 父 Agent 作为进程管理器：启动子任务、检查日志和进度、取消失败的分支、合并成功的结果。这是操作系统层面的思维。
- 并行性必须显式且可检查：不能「发射后不管」。父 Agent 需要能查看每个子 Agent 的状态、输出和错误。
- 子 Agent 输出持久化：每个子 Agent 的结果存为文件、日志或状态记录（而不仅是返回到父 Agent 的上下文中），这样即使中断也能恢复。
- 容错与恢复：后台任务可能超时、崩溃或产出低质量结果。Harness 需要设计重试策略和优雅降级机制。
| 工具分组 | 核心能力 | 典型工具 |
|---|---|---|
| File System | 读、写、搜索、编辑文件；管理工作区状态 | Read, Write, Edit, Glob, Grep, StrReplace |
| Shell Execution | 执行终端命令、运行测试、安装依赖 | Shell, BashExec, RunCommand |
| I/O | 与用户交互、确认操作、展示结果 | Ask, UserConfirm, ShowResult |
| External Context | 获取外部信息、文档、API 响应 | WebFetch, ReadURL, DocSearch |
| Web Search | 搜索互联网获取最新信息 | WebSearch, BingSearch |
| Artifacts | 生成、管理和版本化制品 | CreateFile, SaveArtifact, VersionControl |
| Backend Processes | 后台运行长任务、监控进程状态 | BackgroundShell, AwaitProcess, Monitor |
| Agent Delegation | 生成子 Agent、分配并行任务、合并结果 | Task, Subagent, Fork, ParallelRun |
文件系统记忆为循环提供了硬盘：让每轮迭代的成果不会丢失，即使上下文被清空。
子 Agent 并行为循环提供了多核：当任务可分解时，用并行加速取代串行等待。
三者组合，一个 Agent 就具备了迭代优化 × 长期记忆 × 并行扩展的能力。这正是当前最强编码 Agent 的共同架构。
「从循环到记忆，从单体到多体：Harness 的三大基础设施模式」如何改变一次回答
「工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务，构建 Agent 运行时的三个基石」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务，构建 Agent 运行时的三个基石」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- Plan → Execute → Observe/Test → Improve → Execute again ：每一轮生成都是下一轮优化的起点
- 分析自身轨迹 ：优秀的 Agent 会回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个 Prompt
- 强调 运行时迭代 ：改进发生在 Agent 执行过程中，不依赖人类事先写好的静态模板。Agent 在每次执行中学习、适应、优化
先保留会改变判断的内容
可以用「工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务，构建 Agent 运行时的三个基石」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「从循环到记忆，从单体到多体：Harness 的三大基础设施模式」走到「Pattern 1」
「从循环到记忆，从单体到多体：Harness 的三大基础设施模式」先把问题落在「Lilian Weng（2026.07）在 "Harness Engineering for Self-Improvement" 中提炼出三个反复出现在成功 Agent 系统中的设计模式：工作流自动化、文件系统做持久记忆、子 Agent 与后台任务。它们不是可选优化。它们是任何生产级 Agent 的 结构性需求」上；到了「Pattern 1」，讨论继续推进到「1 Workflow Automation 工作流自动化 核心思想：Agent 是一个 目标导向的循环 ，不能当成执行一次就结束的脚本。 Plan → Execute → Observe/Test → Improve → Execute again ：每一轮生成都是下一轮优化的起点。 分析自身轨迹 ：优秀的 Agent 会回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个 Prompt…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「从循环到记忆，从单体到多体：Harness 的三大基础设施模式」：Lilian Weng（2026.07）在 "Harness Engineering for Self-Improvement" 中提炼出三个反复出现在成功 Agent 系统中的设计模式：工作流自动化、文件系统做持久记忆、子 Agent 与后台任务。它们不是可选优化。它们是任何生产级 Agent 的 结构性需求
- 「Pattern 1」：1 Workflow Automation 工作流自动化 核心思想：Agent 是一个 目标导向的循环 ，不能当成执行一次就结束的脚本。 Plan → Execute → Observe/Test → Improve → Execute again ：每一轮生成都是下一轮优化的起点。 分析自身轨迹 ：优秀的 Agent 会回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个 Prompt…
- 「最后的要点」：制品种类繁多 ：实验日志、代码 diff、论文摘要、错误追踪记录、过去的完整执行轨迹，这些都是有价值的状态，但塞不进上下文
最后的「最后的要点」把讨论落到「制品种类繁多 ：实验日志、代码 diff、论文摘要、错误追踪记录、过去的完整执行轨迹，这些都是有价值的状态，但塞不进上下文」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。