推理时扩展、Harness 与 Agent

这一页只看第三阶段：

模型已经训练好了之后，为什么还能在单次任务里继续花计算，把效果往上推。

这就是 inference-time scaling。

最容易误解的是把 prompt、harness、agent 看成三件互不相干的事。
更好的理解方式是：

它们都是在推理阶段追加算力，只是追加算力的层级不同。

先把 prompt、harness、agent 看成一条连续谱

层级	额外投入什么	反馈回路怎么形成	代价主要是什么	适合什么任务
Prompt	更长的上下文、更明确的步骤、更强的约束和样例	人工先把任务拆好，模型按结构执行	额外 token 很少	边界清晰、一次调用能完成的任务
Harness / Workflow	规划、检索、测试、judge、重试、回滚	外部 verifier 或 evaluator 把错误反馈回当前轨迹	更多模型调用、更多工具调用、更多 wall-clock time	可验证、失败代价高的任务
Agent	模型自己决定下一步、自己调用工具、自己调整路径	环境反馈和工具结果持续进入循环	状态管理、调试、预算控制、长尾错误	开放式、多步、步骤数难预先写死的任务
Multi-agent	把规划、执行、审查、搜索并行拆给多个上下文	多角色之间通过工件、状态或协调器形成更大回路	token、协调复杂度和系统开销急剧上升	高价值、可并行、需要吞吐和广度的任务

所以 prompt engineering 不是“雕花技巧”，而是最便宜的一层推理时扩展；
harness 和 agent 也不是“更高级的新物种”，而是把更多算力和更多反馈回路压进单次任务里。

为什么它会有效

可以先把三件事分开：

• 数据与训练：做出更强底座
• 后训练：把底座整理成更可交付的模型
• 推理时扩展：在每次任务里再给模型更多信息、更多工具、更多检查、更多重试

所以 prompt engineering、RAG、tool use、self-reflection、evaluator、agent loop，本质上都可以看成推理时扩展的不同形态。

这条线真正有用的原因，不是“token 变多了”，而是：

模型得到了更多信息、更多环境反馈，也有了更多次修正自己的机会。

如果用工程语言粗写，可以记成：

任务效果
≈ 模型本体能力
+ 当次获取的信息质量
+ 当次投入的推理计算
+ 反馈回路把错误拉回来的能力

Agent 设计的精髓，不是“会自己动”，而是“能持续收到可操作反馈”

很多人会把 agent 理解成“模型自己到处点按钮”。
但工程上真正决定 agent 好不好用的，通常不是“自主感”，而是下面几件事：

1. 目标要清楚，而且要有 done definition。没有明确完成定义，agent 很容易过早宣布胜利。
2. 必须拿到环境里的 ground truth。代码任务靠测试、浏览器、执行结果；研究任务靠搜索结果、引用和来源质量；没有这些，agent 只能自我感觉良好。
3. 生成和评估最好分开。让生成器自己给自己打分，通常会过度宽容；独立 evaluator 才会把错误变成可操作反馈。
4. 状态要能持久化和交接。长任务里最贵的不是一次失败，而是每次失败后都得从头恢复上下文。
5. 工具接口要像给新工程师写 docstring 一样清楚。很多 agent 的瓶颈不是模型不够强，而是工具难用、描述模糊、边界不清。
6. 必须有预算、停止条件和观测。没有预算控制，agent 会无限探索；没有 trace，你也不知道它为什么失败。

所以所谓 agent design，核心不是“人格化”，而是：

让模型在一个可观察、可验证、可回滚的环境里不断收敛。

为什么它和后训练强化学习在本质上相似

这也是为什么 后训练 RL 和 harness 虽然发生在不同阶段，本质却很像：

它们都在建立反馈回路。

维度	后训练强化学习	Harness / Agent 回路
反馈来自哪里	reward model、人类偏好、judge、自动 verifier	测试、浏览器、工具结果、独立 evaluator、人工审核
钱花在什么时候	主要是离线花钱，一次训练后摊给很多请求	主要是在线花钱，每个高难任务都要重花一遍
改变了什么	改模型权重，让某类行为内化	不改权重，只改这一次任务的执行轨迹
适合优化什么	通用、可反复复用的偏好和能力	私有数据、专用工具、场景化、一次性高价值任务
风险	训练成本高，反馈不一定覆盖真实环境	成本和时延直接暴露给线上，错误会在长链路里累积

所以更准确的说法不是“RL 和 harness 谁更高级”，而是：

• RL 是把常见反馈内化进模型
• Harness 是把场景化反馈外化到运行时

前沿模型越强，越多原本必须靠 harness 的能力会被后训练吸收进去；
但只要任务要接私有系统、私有工具、私有标准，最后一公里仍然得靠 harness。

现实世界里，大家是怎么用更多推理算力换更好效果的

Anthropic：Harness 不是“包一层壳”，而是在造显式反馈回路

Anthropic 在长任务编码上给了两组特别好的公开例子。

第一组是 2025 年的 long-running harness：他们发现即使用 Claude Agent SDK 做多上下文循环，模型仍会出现两种典型失败：

• 一次想做太多，导致上下文中途断裂
• 做到一半就过早宣布完成

他们的解法不是“再喊模型聪明一点”，而是加了显式 scaffolding：initializer agent、feature list、progress file、git 记录，以及端到端浏览器测试。这里的关键不是工具本身，而是把“完成定义”和“环境反馈”做成了稳定工件。

第二组是 2026 年的 harness design 实验。这里 Anthropic 进一步把系统拆成 planner + generator + evaluator 三个角色：

• 在复古游戏编辑器实验里，solo 运行只花了 20 分钟 / 9 美元，但产物核心玩法是坏的；完整 harness 花了 6 小时 / 200 美元，却能把一行提示扩成 16 个功能、10 个 sprint，并做出真正可玩的应用。
• 在后续基于浏览器的 DAW 实验里，更新后的 V2 harness 运行了 3 小时 50 分钟，花费 124.70 美元，生成了带 arrangement view、mixer 和 transport 的可用音乐制作程序，QA 还会把“哪些功能只是 stub、哪些核心交互仍然缺失”明确打回给生成器。

Anthropic 这组实验最值得记的不是价格本身，而是：

planner 负责扩大规格，generator 负责实现，evaluator 负责制造外部反馈；质量不是靠一次更强的回答，而是靠反馈回路反复逼出来的。

OpenAI：把一部分 harness 逻辑直接写进模型和异步执行环境里

OpenAI 的两个例子说明了另一条路。

Deep Research 本质上是在把多步浏览、搜索、回溯、Python 分析这些行为，直接通过端到端强化学习写进模型和产品形态里。OpenAI 明确说它是按真实浏览与 Python 任务训练出来的，单次运行通常需要 5-30 分钟，目的是让系统为一份报告持续投入更多推理计算，而不是像普通聊天那样尽快结束。

Codex 则展示了异步软件工程 agent 的产品化形态：每个任务都在独立环境里运行，可读写代码、跑测试、跑 lint 和 typecheck，并把终端日志与测试输出作为“可验证证据”返回。OpenAI 自己也在用它卸载范围明确但容易打断注意力的任务，并建议把范围明确的任务并行分配给多个 agent。

这条路线说明：

• 一部分推理时扩展，已经可以被 RL + 产品封装 内化
• 但一旦进入真实代码库，仍然要靠隔离环境、测试、日志和人工审核来闭环

Cursor：专用 harness 往往比“裸推理模型”更关键

Cursor 的例子更直接地说明了 harness 的价值。

PlanetScale + Bugbot 这组案例里，PlanetScale 认为随着 agent 让代码生成变便宜，真正的瓶颈已经后移到代码评审。Bugbot 作为专门的 review agent，能在 2000+ PR / 月 的量上工作，约 80% 的评论会在合并前被处理，并为团队节省相当于 2 FTE 的代码审查投入。更重要的是，PlanetScale 明确说：单纯把一个前沿推理模型丢去审查分支，并不能稳定发现 Bugbot 抓到的那些关键问题，真正起作用的是专用 harness 和它背后的构建方式。

Cursor 的 self-driving codebases 研究则把这条路推进到更极端：他们用成千上万的 agent 协同做浏览器工程实验，一周里跑了 1000 万次工具调用，峰值吞吐约 1000 commits / 小时。他们最终得出的结论也很典型：纯共享状态的多 agent 很快失控，稳定系统必须重新引入角色划分、freshness 机制、可观测性、吞吐量权衡，以及对“小错误率但快速收敛”的接受。

Cursor 这两条线共同说明：

agent 不是魔法，专用 harness、角色分工、评审层和可观测性，常常比“再换一个更强模型”更决定上限。

什么时候只用 prompt，什么时候上 harness，什么时候上 agent

一个实用判断框架可以是：

1. 只用 prompt：任务边界清晰、一次调用能完成、失败代价低。先把目标、输出格式、标准和样例写清楚。
2. 上 harness：结果可验证、失败代价高、你能写出 judge/test/contract。代码修复、表单生成、检索报告都常见。
3. 上 agent：步骤数不确定、必须与环境持续交互、需要模型自己决定下一步。研究、跨系统操作、长程 coding 是典型。
4. 上 multi-agent：任务真的可并行、单 agent 的上下文或吞吐不够、任务价值足以覆盖高 token 和高协调成本。

这也是 Anthropic 反复强调的那句话：

先找最简单可行的方案，只有在它不够时，才继续加复杂度。

结论

• prompt、harness、agent 不是三套互斥哲学，而是推理时扩展的三种层级
• agent 设计的精髓不是“像人”，而是“有明确目标、有 ground truth、有 evaluator、有预算、有状态交接”
• 后训练 RL 和 harness 本质上都在造反馈回路；前者把反馈写进权重，后者把反馈留在运行时
• Anthropic、OpenAI、Cursor 的例子都说明：真正把效果拉开的，往往不是单轮回答，而是愿不愿意在单次任务里继续花更多 token、更多工具调用、更多验证和更多 wall-clock time

参考资料

• Anthropic: Building effective agents
• Anthropic: Effective harnesses for long-running agents
• Anthropic: Harness design for long-running application development
• Anthropic: How we built our multi-agent research system
• OpenAI: 隆重介绍深入研究功能
• OpenAI: Codex 简介
• Cursor: PlanetScale 通过 Bugbot 保障生产环境可靠性
• Cursor: 迈向自动驾驶代码库
• Cursor: 发现真实缺陷的 AI 代码审查