Tokyo AI Dad

AI Agent Harness Engineering：模型外面的运行系统

Tokyo AI Dad•••6 分钟阅读

中文生成式 AI 数学本质AI 投研
中文日文英文

**先说结论：**AI Agent harness engineering 指的是模型外面的运行系统设计：给它什么上下文、允许调用哪些工具、保存哪些记忆、通过什么评估、拥有什么权限，以及在哪些环节必须由人审批。模型再强，也需要可靠的 harness 才能进入真实工作流。

前两篇我们讲 scaling laws：模型、数据、算力之间的关系，像 AI 工业时代的预算公式。

今天这篇换一个角度。

Lilian Weng 新写的《Harness Engineering for Self-Improvement》讲的不是“模型参数怎么变多”，而是另一个更接近产品和工程的问题：

当基础模型已经足够聪明时，模型外面的系统如何让它更可靠、更会做长任务，并且逐步改进自己？

这篇文章的关键词是 harness。

它不好直接翻译。你可以先把它想成：

  • 给模型的学校
  • 给模型的工具箱
  • 给模型的记忆本
  • 给模型的考试系统
  • 给模型的安全边界

模型本身像“大脑”。Harness 是大脑外面的整套学习、行动、记录、检查和纠错系统。

Harness 不是模型本身，而是模型外面的运行系统

图 1：基础模型只负责产生智能行为。Harness 决定模型看到什么、能调用什么工具、如何保存记忆、如何检查结果、哪里需要人类介入。

这件事为什么重要？

因为短期内，AI 的自我改进很可能不是从“模型直接修改自己的权重”开始，而是从更现实的一层开始：

AI 先改进自己工作的环境；更好的环境让同一个模型做出更好的事；这些轨迹、失败和评估再反过来帮助下一轮改进。

这就是 harness engineering 的商业价值。

先讲清楚：什么是 Harness？

最简单的公式可以写成：

y=Hh(M,x)y = H_h(M, x)

这里：

  • MM 是基础模型，比如一个会读写、推理、写代码的 LLM。
  • xx 是任务，比如“修这个 bug”“复现这篇论文”“分析这份财报”。
  • hh 是 harness 的设计，比如工具、流程、记忆、评估、权限。
  • HhH_h 是把模型放进这个系统里运行后的整体函数。
  • yy 是最后产物。

普通聊天像这样：

y=M(x)y = M(x)

也就是把问题丢给模型，让模型直接回答。

Agent harness 像这样：

y=Hh(M,x,c,T,R,E)y = H_h(M, x, c, T, R, E)

多出来的东西很关键：

  • cc：上下文，模型当前应该知道什么。
  • TT：工具，模型能搜索、读文件、写代码、运行命令。
  • RR：记忆，任务历史、失败日志、实验记录。
  • EE：评估器，测试是否通过、答案是否可信、有没有回归。

这就像一个学生不只是有脑子，还拥有课本、草稿纸、实验室、错题本、模拟考试和老师。

所以真正的问题不是“这个学生聪不聪明”，而是：

这个学生被放在什么学习系统里？

为什么它和自我改进有关？

“递归自我改进”听起来很玄，好像 AI 会突然改写自己，指数爆炸式变强。

现实路径通常没有那么戏剧化。

更近的路径可能是：

  1. 当前 harness hth_t 让模型完成一批任务。
  2. 系统保存轨迹、失败、代码 diff、测试结果。
  3. 模型或另一个 agent 分析失败模式。
  4. 它提出一个小的 harness 改动 h′h'。
  5. 用 held-in 和 held-out 任务做回归验证。
  6. 通过才合并，失败就记录但不启用。

可以写成：

ht+1={h′if Jin(h′)>Jin(ht) and Jout(h′)≥Jout(ht)htotherwiseh_{t+1} = \begin{cases} h' & \text{if } J_{\text{in}}(h') > J_{\text{in}}(h_t) \text{ and } J_{\text{out}}(h') \ge J_{\text{out}}(h_t) \\ h_t & \text{otherwise} \end{cases}

这条式子的意思很朴素：

只有当新方法真的修好了已知问题，而且没有把未知问题搞坏，才允许升级。

这不是魔法。它更像软件工程里的自动化回归测试。

Self-harness improvement loop animation

图 2：自我改进不是“想改就改”。好的 harness 会把失败挖出来，提出小改动，再用回归测试决定是否接受。

三个最重要的设计模式

Lilian 文章里先讲 harness design patterns。我把它压缩成三个核心设计。

模式一：工作流自动化

一个 agent 不能只靠一次回答。长任务需要循环：

计划 → 执行 → 观察/测试 → 反思 → 修改计划 → 再执行

比如写代码：

  1. 读需求
  2. 搜文件
  3. 修改代码
  4. 跑测试
  5. 看报错
  6. 修 bug
  7. 再测试
  8. 总结结果

这就是 coding agent 能工作的原因。它不是只会“生成一段代码”，而是被放进了一个能读文件、改文件、运行测试、检查差异的循环。

商业翻译：

企业买到的不是聊天框，而是一个会在业务流程里循环工作的运行时。

模式二：文件系统当作持久记忆

长任务最怕一件事：上下文爆炸。

如果模型把所有聊天、工具输出、代码 diff、报错、实验日志都塞进 prompt，很快就超过上下文窗口。就算没超过，也会变成噪音。

正确做法是：

  • 当前 prompt 里只放最相关、最压缩的信息。
  • 详细历史保存在文件系统里。
  • 需要时再用搜索、读取、摘要取回。

可以写成：

ct=compress(qt,Rt)s.t.∣ct∣≤Wc_t = \text{compress}(q_t, R_t) \quad \text{s.t.} \quad |c_t| \le W

这里 WW 是上下文窗口上限，RtR_t 是持久记忆库。

意思是：

每一轮都从完整记忆里挑出当前最有用的信息，压缩进有限窗口。

Context and memory lifecycle

图 3：原始历史会越长越大。Harness 的职责不是把所有东西塞进窗口，而是把完整历史放进文件，把当前窗口保持清醒。

这就是为什么文件、日志、轨迹、实验记录会成为 agent 系统的核心资产。

模式三：子 agent 和后台任务

人类做研究时不会永远单线程工作。我们会同时查几条线索、跑几个实验、让同事帮忙看不同部分。

Agent 也一样。

如果任务可以拆成多个互不污染的小问题，harness 可以启动子 agent：

  • 一个查文献
  • 一个跑实验
  • 一个审代码
  • 一个写摘要
  • 主 agent 负责合并

时间上可以从：

Tserial=∑itiT_{\text{serial}} = \sum_i t_i

变成近似：

Tparallel≈max⁡iti+TmergeT_{\text{parallel}} \approx \max_i t_i + T_{\text{merge}}

但这里有代价。子 agent 太多会带来：

  • 状态难管理
  • 结果难合并
  • 错误难追踪
  • 成本上升
  • 主上下文被污染

所以好的 harness 要像一个小型操作系统：能启动任务、看日志、取消失败任务、保存结果、恢复现场。

Harness 和模型能力，到底谁更重要？

这不是二选一。

一个强模型放进差 harness，会像聪明学生被关在没有资料、没有草稿纸、没有考试反馈的房间里。

一个弱模型放进强 harness，也有上限。流程再好，学生看不懂题也没用。

可以用一个简单函数表示：

Success=σ(aM+bH+cMH−d)\text{Success} = \sigma(aM + bH + cMH - d)

这里：

  • MM 是模型能力。
  • HH 是 harness 质量。
  • MHMH 是二者的相互放大。
  • σ\sigma 是把分数压到 0 到 1 之间的函数。

Model and harness success surface

图 4：模型能力和 harness 质量是乘法关系。强模型需要好 harness 才能稳定落地，好 harness 也需要足够强的模型来执行。

这解释了为什么同一个模型，在不同产品里体验差别巨大。

模型像发动机。Harness 像车身、方向盘、刹车、仪表盘、导航和驾驶规则。

只比较发动机马力，不足以判断一辆车能不能安全跑长途。

Harness Optimization：优化对象从 prompt 变成系统

Lilian 文章里有一条很重要的进化路线：

prompt → 结构化上下文 → 工作流 → harness 代码 → optimizer 代码

这句话非常关键。

早期大家优化的是 prompt。后来发现，prompt 只是系统的一小部分。真正可优化的东西包括：

  • 哪些信息进入上下文
  • 工具什么时候调用
  • 失败如何归类
  • 哪些日志保存
  • 哪些改动允许自动合并
  • 哪些任务必须人类审批
  • 子 agent 如何分工
  • 评估器如何设计

因此目标函数可以写成：

J(h;M,D)=Ex∼D[score(Hh(M,x))]−λCost(h)−μRisk(h)J(h; M, \mathcal{D}) = \mathbb{E}_{x \sim \mathcal{D}} \left[\text{score}(H_h(M,x))\right] - \lambda \text{Cost}(h) - \mu \text{Risk}(h)

它说的是：

好 harness 不只是分数高，还要成本可控、风险可控。

这也是企业落地 AI 时最容易漏掉的部分。Demo 只看第一项，生产系统必须同时看三项。

上下文工程：让模型有一本会更新的错题本

Lilian 提到 ACE 和 MCE 这类 context engineering 工作。

你可以先不用记缩写。核心思想是：

不要让上下文变成越滚越长的聊天记录，要把它变成结构化、可更新、可去重的工作手册。

ACE 的三件事可以这样理解：

角色做什么学生类比
Generator生成任务轨迹学生做题
Reflector从成败中提炼经验复盘错题
Curator把经验整理进结构化上下文更新错题本

MCE 再往前走一步：不只是优化“错题本内容”，还优化“怎么写错题本的方法”。

原文里的双层优化可以写成：

Inner: cs∗=arg⁡max⁡csJtrain(cs;s)\text{Inner: } c_s^*=\arg\max_{c_s}J_{\text{train}}(c_s;s)
Outer: s∗=arg⁡max⁡s∈SJval(cs∗)\text{Outer: } s^*=\arg\max_{s\in\mathcal{S}}J_{\text{val}}(c_s^*)

解释成人话：

  • 内层：给定一种记忆管理方法 ss，找出最好的上下文 csc_s。
  • 外层：比较不同记忆管理方法，看哪种在验证集上更好。

这就像：

不是只问“这本错题本写了什么”，还要问“这套整理错题本的方法是不是更好”。

Workflow Design：让 agent 自己搜索工作方法

工作流也可以被优化。

例如：

  • AI Scientist 把研究拆成想法、代码、实验、论文、评审。
  • ScientistOne 强调每个结论都要能追溯到证据。
  • Autodata 让 challenger、弱 solver、强 solver、verifier 共同生成“刚好有难度”的数据。
  • ADAS 让 meta-agent 自动设计新的 agent 工作流。
  • AFlow 把工作流看成图，用搜索算法找更好的图结构。

这里的数学本质是搜索。

一个工作流可以看成图：

W=(V,E)W = (V, E)
  • VV 是节点，比如“调用模型”“运行代码”“检查答案”。
  • EE 是边，比如“如果测试失败就回到修改代码”。

优化目标是：

W∗=arg⁡max⁡WJ(W)W^* = \arg\max_W J(W)

意思是：

在许多可能的工作流里，找出最能完成任务、成本可控、风险可控的那一个。

这就是为什么 agent 产品未来不会只拼模型，也会拼 workflow library、evaluation、trace data 和 runtime。

Self-Harness：让 Harness 改自己，但不能越权

Self-Harness 的核心循环很适合作为生产系统原则：

  1. 挖掘失败模式
  2. 提出小范围 harness 改动
  3. 用 held-in 测试看是否修复已知问题
  4. 用 held-out 测试看是否引入未知退化
  5. 通过才合并

这听起来保守，但正是保守让它有机会进入生产。

危险在于：如果系统可以随便修改自己的运行环境，就像程序可以随便改操作系统。抽象边界会破掉。

所以需要三道边界：

边界作用
可编辑区域只允许改 harness 的一小部分
权限控制关键资源不能由循环内部随意改
外部评估评估器和安全规则不能被被评估者自己修改

这对企业尤其重要。

能自我改进的系统，不等于能自我放权的系统。

进化搜索：很多候选一起跑，只留下更好的

有些问题很难求导，也没有清楚的梯度。

比如“怎样设计一个更好的 agent 工作流？”这个问题很难写出可微函数。但我们可以评估一个候选方案好不好。

这时进化搜索很有用。

基本流程是：

  1. 保留一群候选 harness。
  2. 选出几个表现较好的父代。
  3. 让模型对它们做小改动，产生子代。
  4. 运行评估。
  5. 保留高分、低风险、有差异的候选。

选择概率可以粗略写成：

P(hi)∝exp⁡(βJ(hi))1+niP(h_i) \propto \frac{\exp(\beta J(h_i))}{1 + n_i}

这里 J(hi)J(h_i) 是分数，nin_i 是这个候选已经产生过多少子代。

意思是：

高分候选更容易被选中，但不能永远只围着一个赢家打转，否则会失去多样性。

Evolutionary harness search animation

图 5：进化搜索不是只找最高分，还要看风险和复杂度。真正有价值的是逐渐向右上方移动的 Pareto 前沿。

这解释了 AlphaEvolve、Darwin Gödel Machine 这类工作的吸引力：只要任务可评估，系统就可以不断生成候选、测试候选、保留更好的候选。

但局限也很清楚：

  • 评估慢，就很贵
  • 评估模糊，就容易自欺
  • 奖励设计错，就会 reward hacking
  • 只追高分，就会牺牲长期可维护性

最大难点：评估器没有你想象中可靠

Self-improvement 的核心不是“能不能生成新方案”，而是“能不能判断新方案真的更好”。

如果评估器是单元测试，agent 可能过拟合测试。

如果评估器是另一个模型，agent 可能学会讨好这个 judge。

如果评估器是 benchmark，agent 可能利用 benchmark 漏洞。

可以写成：

优化方向=∇hJproxy(h)\text{优化方向} = \nabla_h J_{\text{proxy}}(h)

但你真正想要的是：

∇hJreal(h)\nabla_h J_{\text{real}}(h)

危险就在两者不一致：

Jproxy≠JrealJ_{\text{proxy}} \ne J_{\text{real}}

这就是 Goodhart 定律在 agent 时代的版本：

一旦一个指标变成目标，它就可能不再是好指标。

所以未来真正值钱的不是“我有一个 agent”，而是：

  • 我有可信评估
  • 我有 held-out 测试
  • 我有轨迹审计
  • 我有失败分类
  • 我知道什么时候让人类介入

为什么 AI 还不是科学家？

Lilian 文章最后讲了一个很清醒的问题：AI Scientist 类系统很强，但“写出像论文的东西”和“真正科学发现”不是一回事。

自主研究系统常见失败包括：

  • 依赖训练数据里的旧习惯
  • 实现复杂时偷偷换成简单方案
  • 长任务中忘掉关键细节
  • 把噪音说成成功
  • 缺少领域手感
  • 实验能跑，但没有回答真正重要的问题

这句话对商业也成立：

能产出一份报告，不等于做出了正确决策。

AI workflow 的真正价值，不在于“生成看起来像成品的文本”，而在于：

  • 证据链是否完整
  • 实验是否可信
  • 失败是否被保存
  • 假设是否被更新
  • 人类是否在正确层级监督

对企业的启示

第一，别只买模型，要买运行系统。

企业真正需要的是：

  • 可重复的 workflow
  • 可审计的 trace
  • 可回放的失败记录
  • 可验证的评估集
  • 可控的权限系统
  • 和业务数据连接的工具层

第二，日志和轨迹会变成资产。

每一次 agent 做任务，都会留下：

  • 读了什么
  • 调了什么工具
  • 哪里失败
  • 怎么修复
  • 哪些路径没用
  • 哪些测试暴露问题

这些不是垃圾日志。它们是下一轮 harness 改进的训练材料。

第三，AI 组织要从“prompt 管理”升级到“harness 管理”。

Prompt 可以放在文档里。Harness 更像软件系统，需要版本控制、权限、测试、监控、回滚和审计。

对投资判断的启示

下面不是投资建议，只是分析框架。

如果模型 API 逐渐商品化，真正能复利的地方会往系统层移动。

AI moat matrix for harness engineering

图 6：模型权重和 API 接入会承受更强商品化压力。更长期的价值可能来自评估体系、轨迹数据、工作流所有权、权限与合规能力。

看一家 AI 公司，不要只问“用哪个模型”，要问：

问题好信号危险信号
有没有专属评估体系？有 held-out 测试和回归基准只展示 demo
有没有轨迹数据？保存失败、工具调用、修复路径只有最终答案
Harness 能否自我改进？小改动、可验证、可回滚让 agent 随便改系统
是否有权限边界？安全层在改进循环外部被优化对象能改评估器
是否嵌入工作流？连接真实业务系统只是聊天入口
成本是否可控？任务路由、缓存、并行管理每个任务都调用最贵模型

长期看，AI 产品的护城河可能来自这几类资产：

  • 行业工作流
  • 专有评估集
  • 任务轨迹数据
  • 工具集成深度
  • 人机协作节点
  • 合规和权限系统
  • 对失败的系统性学习

裸模型能力会越来越强，但也越来越容易被替代。

能把模型变成稳定生产力的 harness，反而可能更难复制。

一句话总结

上一篇 scaling laws 讲的是：

AI 能力增长要看模型、数据、算力怎么配。

这一篇 harness engineering 补上另一半：

AI 能不能长期可靠地做事，要看模型外面的运行系统怎么设计、怎么评估、怎么记忆、怎么限制、怎么改进。

真正的自我改进，不一定一开始就是模型改自己的权重。

更现实的路径是：

更好的 harness → 更好的任务轨迹 → 更好的评估和记忆 → 更好的 harness

这条循环听起来没有科幻电影那么刺激，但它可能更接近今天 AI 产品真正发生复利的地方。

下一篇可以继续讲：当 agent harness 变成生产系统之后，评估器、权限、审计、trace data 和人类监督，为什么会成为 AI 公司最重要的基础设施。

References

相关文章