从脚手架到自我改进系统 · Harness 三大设计模式 · 解读与音频稿件

本集对应模块 T6（Harness 与自我改进）的两节课：「从脚手架到自我改进系统」「Harness 三大设计模式」。

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本集要解决什么

观念层面：Harness 不只是包裹模型的外壳，它正在成为 AI 递归自我改进（RSI）的核心引擎。

架构层面：好的 Harness 有清晰的模式语言——三个核心模式覆盖了当前最强 Agent 系统 90% 的架构决策。

地基判断：Harness 层与原始模型智能同等重要。一个平庸的模型加上优秀的 Harness，往往胜过裸露的更强模型。

能力地图

能力	落点	一句话
Harness 定义	模型周围的运行时	决定思考/工具/上下文/制品/评估
RSI 路径	不改权重，改外围	改部署系统、工作流、上下文管理
三步预测	管线 → 元方法论 → 正反馈	Harness 本身成为优化目标
模式 1	工作流自动化	目标导向循环：plan→execute→observe→improve
模式 2	文件系统做持久记忆	上下文是工作记忆，文件系统是长期记忆
模式 3	子 Agent 与后台任务	独立沙箱 + 文件输出 + 轮询协调
工具全景	八组接口	文件系统/外壳/IO/外部上下文/搜索/制品/后台/委派

逻辑拆解

一、什么是 Harness

Harness = 模型周围的一切编排系统。它是围绕基座模型的运行时系统，决定模型如何：

• 思考与规划
• 调用工具与行动
• 感知与管理上下文
• 存储制品
• 评估结果

二、RSI 的演进

时间	人物	内容
1965	I. J. Good	「Ultra-intelligent machine」：能设计更好机器的机器。理论设想
2008	Yudkowsky	正式提出 Recursive Self-Improvement：AI 用自身智能改进产生智能的认知机制
近期	—	Self-play、合成数据、Test-time training 等早期尝试，模型开始改善自己的训练数据
当下	Harness 工程	成为 RSI 核心路径：模型不直接改写权重，改进的是围绕自身的部署系统、工作流和上下文管理

本篇章框架、概念与案例源自 Lilian Weng 于 2026 年 7 月发表的长文《Harness Engineering for Self-Improvement》。观点与功劳属于原作者。

三、为什么 Harness 是近期 RSI 的实际路径

三步预测：

1. 模型不会直接改写自己的权重，但能改进训练管线和部署系统，使下一代模型更强。

• 支撑理由：改权重的验证成本极高，改外围系统的验证成本很低。

1. Harness 工程走向元方法论 — 改善的对象从答案本身，变成得到更好答案的机制。Harness 本身成为优化目标。
2. 成熟 Harness + 智能模型 = 正反馈循环 — 更好的 Harness 催生更强模型，更强模型又让 Harness 不必过度工程化。这个循环是自我收敛的。

与 Prompt Engineering 的类比：随着指令微调和推理能力提升，手动 Prompt 技巧变得不那么核心，但指定目标、约束、上下文和评估的需求并没有消失，只是换了个地方存在。同理，最终很多 Harness 改进会被内化为模型行为，但与外部上下文和工具的接口将永远存在。

提示1 · 把优化对象从答案提升到机制

改善 Agent 的方式不只是改提示词，还可以改它得到答案的那个流程。这是递归自我改进在当下最现实的落地方式——不需要改模型权重，只需要改围绕模型的那一层。

三大设计模式

Pattern 1 · Workflow Automation（工作流自动化）

核心思想：Agent 是一个目标导向的循环，不能当成执行一次就结束的脚本。

Plan → Execute → Observe/Test → Improve → Execute again

三个要点：

1. 分析自身轨迹 — 回头看前几轮做了什么、哪里失败、为什么失败，然后调整，避免重复同一个 Prompt；
2. 运行时迭代 — 改进发生在执行过程中，不依赖人类事先写好的静态模板；
3. 失败是信号，不是终止 — 测试不通过、命令报错、输出不符预期，都是自我纠正的触发条件。

提示2 · 不要把 Agent 设计成一次性回答器

让它拥有自己审查自己的能力：看到测试失败后自动分析原因、看到 linter 报错后自动修复、看到用户反馈后调整策略。把反馈循环内置到系统里。

Pattern 2 · File System as Persistent Memory

核心问题：长期运行的 Agent 中，制品会迅速超出上下文窗口。

制品种类：实验日志、代码 diff、论文摘要、错误追踪记录、过去的完整执行轨迹——都有价值，但塞不进上下文。

为什么用文件系统：文件读写是 LLM 基础技能，不需要复杂外部工具链，直接受益于核心模型能力提升。模型越聪明，文件管理越高效。这比很多精巧的外部方案更值得押注，因为它是顺水推舟的。

放哪里	内容	判据
上下文	当前任务指令、即时工具调用结果、最近 2-3 轮对话	需要即时参考
文件系统	历史实验结果、累积错误日志、已完成任务摘要、长期策略与规则	需要持久保存但不必时刻在视野中

上下文是工作记忆，文件系统是长期记忆。 好的 Harness 像人脑一样，在两者之间智能地搬运信息。

Pattern 3 · Sub-agent and Backend Jobs

核心思想：一个 Agent 不够用时，生成多个子 Agent 并行执行，同时监控后台长任务。父 Agent 作为进程管理器——这是操作系统层面的思维。

四条纪律：

1. 并行性必须显式且可检查 — 不能「发射后不管」，父 Agent 要能查看每个子 Agent 的状态、输出和错误；
2. 子 Agent 输出持久化 — 存为文件/日志/状态记录，而非仅返回到父上下文，中断也能恢复；
3. 容错与恢复 — 设计重试策略和优雅降级；
4. 核心取舍 — 并行带来速度，也带来复杂性。

成功实现的共同原则：每个子 Agent 在独立沙箱中工作，输出到明确的文件路径，父 Agent 通过轮询文件状态协调，不做内存共享。

提示3 · 不做内存共享，是性价比最高的一个决定

把子 Agent 结果写到明确路径、父 Agent 轮询文件状态，等于把并发控制里最难的共享状态一致性问题直接从架构里删掉了。这是三个模式里投入产出比最高的一条。

三种架构跑同一批任务的差距

架构	上下文占用	表现
全部塞进上下文	92%	第 4 轮就开始丢信息，输出质量骤降
每轮写文件 + 释放上下文	35%	可持续运行数十轮不退化（上下文大小恒定）
主 Agent 派发 + 子 Agent 独立沙箱	28%	速度 ×3，5 个任务 3 轮完成（串行需 5 轮）

差别不在模型，在怎么组织模型周围的那一层。

三层叠加，无需三选一

• 工作流自动化提供执行的脊椎（循环结构与反馈机制）；
• 文件系统记忆为循环提供硬盘（成果不丢失，即使上下文被清空）；
• 子 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

这份表是一份现成清单。搭自己的 Harness 照着八组配齐基本不漏；反过来说，缺的那一组往往就是能力短板的来源。

两个容易忽略的视角

视角一 · 循环型 vs 一次性，是两套验收标准

一次性回答器的验收标准是「首次输出够不够好」；循环型 Agent 的验收标准是「它能不能收敛到够好」。

• 前者关注单次采样质量 → 导向的工程投入是拼命堆提示词；
• 后者关注迭代收敛性 → 导向的工程投入是补测试、补日志、补可观测性。

你想优化什么，取决于你把系统定义成什么。

视角二 · 工具分组的趋同不是巧合

几家互相独立的产品收敛到了几乎一样的八组工具，这通常意味着那个形状是被问题本身的性质决定的，而非被某个团队的品味决定。

另外注意最后两组（后台进程、智能体委派）正是模式三的落地形态：前六组是单体的能力边界，后两组是突破单体的手段。很多系统做到前六组就停了，然后困惑于能力上不去——答案往往就在缺的这两组里。

审查清单

1. Agent 是循环还是一次性回答器？失败是触发自我纠正还是直接抛给用户？
2. 有没有让 Agent 分析自身轨迹、避免重复同一个 Prompt？
3. 长期状态是不是存在文件系统而非上下文里？
4. 上下文/文件的划分符不符合「即时参考 vs 持久保存」的判据？
5. 子 Agent 是不是在独立沙箱中工作？输出是不是写到明确路径？
6. 父 Agent 是不是轮询文件状态协调，而非内存共享？
7. 后台任务有没有重试策略与优雅降级？
8. 八组工具接口有没有缺项？
9. 优化对象是不是还停留在「改提示词」而非「改流程」？

约束说明

• 出处约束：本篇章框架、概念与案例源自 Lilian Weng 2026 年 7 月《Harness Engineering for Self-Improvement》，观点与功劳属于原作者。本集为教学化演绎。
• 百分比数据约束：92% / 35% / 28% 与「速度 ×3、5 任务 3 轮」为演示中的示意性对比数据，用于说明架构差异的方向，不是基准测试结果。不同任务、不同实现下数值会明显变化。
• 「90% 架构决策」约束：这是原作者的概括性判断，指三个模式的覆盖广度，不是可测量的精确比例。
• 三步预测约束：这是预测性论断而非已验证事实，尤其第三步「正反馈循环」属于对趋势的判断，应保留怀疑。
• MoE/模型无关约束：本集不涉及具体模型权重改造，RSI 路径限定在「改外围系统」这一现实路径上，不代表学术界对直接权重自我修改的研究不存在。
• 模式适用范围约束：三个模式提炼自「成功的编码 Agent 系统」，迁移到其他领域（如对话式产品、嵌入式场景）时需重新评估适用性。
• 取材约束：本集只使用本集素材内资料，不跨集引用，不虚构源文档未出现的数据、案例与引文。

一句话总结

Harness 设计不是随机拼凑工具。它遵循三个结构性模式：目标导向的自动化循环（让 Agent 能自我纠错）、文件系统做长期记忆（突破上下文窗口限制）、子 Agent 做并行扩展（把串行瓶颈变成多线程）。理解这三个模式，就掌握了构建生产级 Agent 系统的架构语言。

可带走的设计原则

1. 把 Agent 设计成循环，不是一次性回答器。 失败是信号，不是终止。
2. 上下文是工作记忆，文件系统是长期记忆。 别把全部历史压进提示词。
3. 并行必须显式且可检查。 独立沙箱 + 文件输出 + 轮询协调，不做内存共享。
4. 别低估 Harness 层的价值。 效果上不去时，先判断是模型不行还是模型周围那一层太薄。
5. 把优化对象从答案提升到机制。 这是 RSI 当下最现实的落地方式。

---

音频与稿件

• 音频：si01-播客.mp3
• 字幕：si01-播客.srt
• 口播稿：script.txt
• 集页：https://xueai-podcast.pages.dev/t/si01/

本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

来源：xueai.miyang.cn（小山学堂 · 洛小山）