Harness：模型之外，决定 Agent 真实表现的那层外壳 - AI 小课

本文基于 Lilian Weng 的博客 Harness Engineering（2026-07-04）提炼整理。

这是什么

很多人以为 AI Agent 的能力 = 模型本身。但实际跑起来的 Agent（比如 Claude Code、Codex 这类编程助手），模型之外还有一整层系统，它和模型一样重要、甚至更关键。这层系统就叫 Harness（外壳）。

一个 harness 是围绕基础模型（base model）构建的系统，负责：

编排执行：决定模型怎么思考、怎么规划
调用工具与行动：怎么读文件、跑命令、搜网页
感知和管理上下文：把什么放进模型的”工作记忆”
存储制品：代码、日志、中间结果放哪
评估结果：怎么判断这一步做对了没有

打个比方：模型是大脑，harness 是身体 + 工作台 + 神经系统。大脑再聪明，没有手、没有工具、没有记忆、没有反馈循环，也干不成事。

为什么重要

理解 harness，能解释几件你常见的事：

同样的模型，表现天差地别。Claude Code 之所以好用，不只是模型强，更是它的外壳把”读文件 / 改代码 / 跑测试 / 看 git”这套循环打磨得很好。换个粗糙的外壳包同一个模型，效果会差很多。
它比”agent = LLM + 记忆 + 工具 + 规划 + 行动”更进一步。老公式停留在 prompt 层；harness engineering 还包括工作流设计、评估、权限控制、持久状态管理——它更接近运行时和软件系统设计，而不是写 prompt。
它是 AI 走向”自我改进”的近路径。让模型直接重写自己的权重还太远，但让模型改进”自己运行的那层外壳”，是眼前就能做的事。优化的对象在演进：提示词 -> 结构化上下文 -> 工作流 -> 外壳代码 -> 优化器代码。

一句话：改进 Agent，往往不是换更强的模型，而是改进 harness。

怎么用

文章总结了三大设计模式，几乎适用于任何长任务 Agent：

1. 工作流自动化（Workflow Automation） 把 Agent 跑成一个目标导向的循环：计划 -> 执行 -> 观察 / 测试 -> 改进 -> 再执行，直到达成目标。关键是用一个”运行时”驱动它迭代，而不是丢一个静态 prompt 就完事。

2. 文件系统作为持久记忆（File System as Persistent Memory） 长任务里，实验日志、代码改动、错误轨迹会很快超过模型的上下文窗口。别把所有东西塞进 context——把持久状态写成文件，让模型用读写文件来”记住”。文件读写本就是 LLM 的基础能力，这条路天然受益于模型变强。

3. 子代理与后台任务（Sub-agent & Backend Jobs） 主 Agent 可以派生多个子代理并行干活（搜多个假设、跑多个实验）。关键设计：让并行显式且可检查——输出存成文件 / 日志 / 状态记录，而不是只活在临时对话里。这样中断后能恢复，模型也能复盘自己的执行历史。

还有一个贯穿性的洞察：代码是定义 harness 的通用语言。harness 本质上就是”编排 prompt、工具调用、子代理、控制流、记忆、工作流”的一段代码。如果让 LLM 去优化这段代码，它能触及的设计空间比手写 prompt 大得多——这正是 STOP、Meta-Harness、ADAS、AFlow 等研究在做的事：把 harness 本身变成可搜索、可优化的对象。

练习

打开你用的编程 Agent（Claude Code / Cursor / Codex），观察它的”外壳”包含哪些工具：文件读写、shell、git、搜索、子任务？对照文章列的工具表，理解它不只是”聊天 + 改代码”。
反思你给 AI 的任务：是停在”一个 prompt 等回答”，还是有一个”计划 -> 执行 -> 看结果 -> 改进”的循环？
挑一个你反复做的 AI 任务，试着把它的流程固化成代码或一个 skill 文件，而不是每次从头重新 prompt——你就在做最基础的 harness engineering。

小结

Harness = 模型之外、决定 Agent 真实表现的那层系统。
同样的模型，外壳决定上限；改进 Agent 的近路径，常常是改进 harness，而不是换模型。
把 harness 当代码、当优化目标，是走向”AI 改进 AI”的钥匙。

-> 想深入 Agent 工程？走 Agent 开发进阶路径。想亲手做出一个能跑的 Agent 产品？看训练营。