agent-harness — 把「包住模型的那层软件」当成一等研究对象 #

1. 主题缘起 #

这个主题成立的直接触发点是一次归因转移：agent 的自主性瓶颈不只在基座模型的推理能力，

也在于把模型输出连接到长程动作与持久状态的那套软件的可靠性——工具、API、sandbox、

memory、validator、权限边界、执行循环、反馈通道 [2605.18747]。

这个判断如果只是修辞，主题不会成立；它成立是因为有一个可量化的杠杆：在模型权重完全

冻结的前提下，仅改动包裹模型的那层代码，就能在同一个 benchmark 上造成最高 6× 的

性能差 [2603.28052]。

主题横跨的不是一个 category，而是四条本来互不说话的线，这正是它必须被当作跨域主题

而非单域评价来写的原因：

• agent runtime 线给出了控制回路与多智能体编排的抽象

[2308.08155]，以及「执行即判据」的评测契约 [2310.06770]；

• model / prompting 线贡献了这层软件所要承载的推理表征——把 thought 定义为对环境

无副作用、只重写自身上下文的一等动作 [2210.03629]；

• algorithm / 上下文工程线给出了让这层软件在有限窗口下可扩展的机制：把辅助上下文

全部落盘、按需 grep，MCP 重度会话省 46.9% token [blog-dynamic-context-discovery]；

• code / 生产实现线给出了真实出货的形态：MIT 许可、43 个工具、三模式权限、

持久记忆、原生与 Docker 双 sandbox 的开源 Python 实现

[HKUDS-OpenHarness]。

促成聚合的第二个信号是时间上的收敛。2026 年这一层同时出现了三种把它当成对象而非背景

的做法：直接在代码空间里搜索它 [2603.28052]、在生产里重写它的上下文层

[blog-dynamic-context-discovery]、以及用 8 周 13K star 把它开源化

[HKUDS-OpenHarness]。随后出现的横向普查论文并不是这条曲线的

开局而是它的收尾——它的角色是命名者与诊断者，而不是范式发起者

[2605.18747]。

主题的技术核心随之收窄成一句可操作的诊断：**看一个多智能体编码系统，先问它的共享程序

状态是什么、agent 能不能查询它**——如果答案是「最近一次对话上下文里的那份代码」，那么

它后续所有的拓扑创新与上下文工程都应被读作代偿而非进步

[2605.18747]。

2. 覆盖的 category 分布 #

分布本身就有信息量：**主题的规范性主张几乎全部产自 agent 侧，而唯一带生产 A/B 数字的

证据来自 algorithm 侧，唯一可以逐模块核对的实现来自 code 侧**。这解释了后面 §6 里的

多数分歧——不同 category 的目标函数（任务成功率 / 上下文成本 / 可维护性）从未被放在

同一张表上比较。

需要显式说明的一处不对称：ReAct 的归属是 model 而非 agent

[2210.03629]，因为它不发布权重也不改架构，其贡献是一次表征选择；

但它恰恰是本主题所有控制回路的公共前身。category 边界在这里是失真的，主题层的谱系

（§4）比 category 归属更能反映真实的技术流向。

3. 时间线 #

时间线上最值得注意的是 2023 年末到 2026 年初这段近乎空白的间隔——被读的条目里没有任何

一篇填补它。这不是领域停摆，而是这段时间的进展主要以闭源产品形态发生，直到 2026 年才

以论文、开源仓库与生产 A/B 三种形式同时回到可引用的公共记录里

[2605.18747]。

4. Evolution timeline（技术谱系） #

§3 是事件流水；这一节画的是技术本身的血缘，重点在分叉点与汇合点，节点后缀标出它所在的

category。

三处分叉与两处汇合值得单独点名：

分叉 1（ReAct → 三条线）。 同一个表征选择被三种方式接手：Reflexion 把它包进跨 trial

的外层优化，AutoGen 把它复制成多个会话实体，SWE-bench 则不接手回路而是给它立了一把尺子

[2310.06770]。三者从此不再交流，直到 PEV 才被重新缝到一起。

汇合 1（Reflexion + SWE-bench → PEV）。 PEV 的三段并非新发现：Plan/Execute/Verify

在 Reflexion 里已经是 Actor / Evaluator / Self-Reflection 三个可换模块，换 Evaluator

就能覆盖三类任务族 [2303.11366]；在 SWE-bench 的评测流水线里已经是

retrieve → generate → apply → run tests 的状态机 [2310.06770]。

真正的增量是把 escalation 与权限分层并进同一个控制过程

[2605.18747]。

分叉 2（AutoGen → 表征层级批评）。 AutoGen 的 artifact 是消息，多智能体的协调靠

message passing；后来的主张恰恰相反——防御性设计必须靠共享 artifact 而非消息传递

[2605.18747]。AutoGen 因此同时是这条线最广泛部署的实例和它最主要的

批评对象 [2605.18747]。

汇合 2（惰性文件 + Reflexion → Meta-Harness）。 proposer 需要读远大于自己窗口的

历史，用的正是文件系统作惰性接口这一机制 [2603.28052]，而它读历史的

目的（把下游失败归因到早期决策）是 Reflexion 式反思在 harness 尺度上的放大

[2603.28052]。

收束点（OpenHarness）。 生产实现同时吸收了工具循环、权限、惰性上下文与多 agent 协调

[HKUDS-OpenHarness]，因此它是核对上述所有规范性主张

覆盖率的唯一现成样本——虚线正是这两次核对。

5. 技术线交错 #

（1）推理表征（model）决定了这层软件能验证什么，也决定了它必须付的代价。

把 thought 定义为对环境 no-op 的动作，好处是推理能被真实 observation 纠偏；代价是

harness 拿不到任何关于中间推理的可执行证据。这一取舍有精确数字：接地把 HotpotQA 的

hallucination 从 CoT 失败的 56% 压到 0%、假阳性从 14% 压到 6%，但 reasoning error

从 16% 升到 47%，另有 23% 的失败来自检索无信息 derail 了推理

[2210.03629]。也就是说，"code 优于纯文本推理" 这条主张在收益侧

成立、在代价侧从未被计入 [2605.18747]。

（2）backbone 强度（model）决定了哪一类机制值得建。 多 agent 相对单 agent 的 F1

增益在 GPT-3.5 上 +35%、在 GPT-4 上只有 +8%，即弱 backbone 处收益更大

[2308.08155]；而跨 trial 自反思在 starchat-beta 上是 0.26 → 0.26，

方法在能力阈值以下完全无效 [2303.11366]。两条证据方向相反，是因为

它们测的是两类不同机制：能力替代型（角色分解、确定性传感器、权限门）在弱模型上就

有效，能力放大型（反思、critique、因果归因）依赖 backbone 的自诊断能力

[2605.18747]。这个区分目前只存在于横向比较里，没有任何

单篇工作把它做成可证伪的网格。

（3）上下文机制（algorithm）既是这层软件的可扩展性来源，也是它被诊断为「代偿」的对象。

把辅助上下文全部外置到文件、用 rg/tail/jq 按需取，价值恰恰来自没有引入新抽象

[blog-dynamic-context-discovery]；同一机制在 harness 搜索里被当作

proposer 访问全保真历史的通道 [2603.28052]。但在表征层级的排序里，

file-only 被放在最低端 [2605.18747]。两个排序不冲突，因为目标函数

不同——一个排的是表达力与可查询性，一个测的是上下文成本，而后者的全部价值来自不引入新

抽象 [2605.18747]。

（4）评测契约（agent）反过来给状态形式化提供了现成的度量空间。 关于共享程序状态的

唯一形式支点是 belief 与真值状态的偏离 $\lvert B_k - S_k \rvert$，但论文自承其量纲未

定义、绝对值号是隐喻性的 [2605.18747]。而执行判据侧早已给出一个完全

确定的状态签名：FAIL_TO_PASS ∪ PASS_TO_PASS 的逐测试通过/失败向量

[2310.06770]。在这个空间里偏离幅度可以直接定义为汉明距离——这条连接

在被读的工作里从未被做出 [2605.18747]。

（5）编排抽象（agent）与下层执行（code / serving）之间存在真实的抽象泄漏。

把控制流藏进 auto-reply 循环是通用性的来源 [2308.08155]，

但下游调度系统不得不把 program 结构逆向重建一遍才能优化

[2308.08155]。同一张力在生产实现里以另一种形式出现：subagent 是新进程

加全新会话，父子之间没有可查询的共享程序状态

[HKUDS-OpenHarness]。**藏起来的结构，最终要么被

下层猜、要么被上层重造。**

（6）生产实现（code）是所有规范性主张的现实检验，结果并不好看。 一个 13K star 的

生产 harness 具备 sandbox、三模式权限、hooks、跨会话持久记忆与 swarm 协调

[HKUDS-OpenHarness]，但循环终止靠 max_turns

（默认 8）而非验证 [HKUDS-OpenHarness]。它干净地落在

file-only + implicit convergence——这支持中心 gap 的判断，却同时削弱其因果解释：

max_turns 是显式的成本与安全预算，不是「没有判据只好数轮数」

[2605.18747]。

6. 共识与分歧 #

6.1 共识（被读的全部条目都同意的） #

共识 1 — 确定性执行反馈是承重构件，不是装饰。 评测侧把它写成判据：解决当且仅当应用

补丁后每个 FAIL_TO_PASS 与 PASS_TO_PASS 测试都通过 [2310.06770]。

系统侧把它写成模块：被反复援引的正面范例里，承重的 Test Executor 不是 LLM 而是一段普通

确定性 Python 脚本 [2605.18747]。算法侧用消融证明它是使能条件：

去掉自生成测试后 HumanEval Rust 最难 50 题从 0.60 掉到 0.52，低于 base

[2303.11366]。搜索侧证明反馈保真度不可压缩：只给 score 或

score+summary，median 从 50.0 跌到 34.6 / 34.9 [2603.28052]。

共识 2 — 文件系统是事实上的持久底座。 永不覆盖写的 file store 让 fresh-context

的 agent 链得以成立 [2605.18747]；harness 搜索的全部历史以

目录形式暴露给 proposer，按需 grep/cat 而非整体塞进 prompt

[2603.28052]；生产 harness 用 MEMORY.md 做跨会话记忆

[HKUDS-OpenHarness]；上下文层则把五类辅助内容统一

落盘 [blog-dynamic-context-discovery]。四者从未互相引用，却收敛到

同一个载体。

共识 3 — 终止判据在整个主题里全线缺失。 单次贪心生成、连循环都没有

[2310.06770]；max_consecutive_auto_reply 加 system message 里

说 "TERMINATE" [2308.08155]；$\Omega \in [1,3]$ 的记忆窗

与最大 trial 数 [2303.11366]；max_turns 默认 8

[HKUDS-OpenHarness]；固定约 20 轮评估约 60 个候选

[2603.28052]。规范要求「终止由验证决定、不由模型置信度决定」

[2605.18747]，但在这个样本里零命中

[2605.18747]，连自家代表性表格的 15 行里也只有 1 行覆盖完整的

Plan+Execute+Verify [2605.18747]。

6.2 分歧（各自有证据、根源在假设不同） #

分歧 1 — 瓶颈在这层软件，还是在基座模型。 归因转移是主题的前提命题

[2605.18747]。反向证据：能力阈值之下方法完全无效，自诊断能力是涌现的

[2303.11366]。同向证据：弱 backbone 处协作收益更大

[2308.08155]。根源是把能力替代型与能力放大型两类机制混在同一个词

里；前提在第一类上成立，在第二类上不成立

[2605.18747]。判定它所需的机制 × backbone 二维网格，

两条轴的方法论在被读的条目里都是现成的 [2308.08155]

[2303.11366]，但没人做过。

分歧 2 — 诊断反馈该压缩还是该保全。 一侧转述 LLM 逐步模拟解释器、不真跑代码即可在

MBPP 上达 98%+ precision/recall，据此开出「语言推理走快路径、执行只在特定失败模式上作为

oracle」的处方 [2605.18747]。另一侧的受控消融显示把原始

trace 压成摘要就会塌掉，且摘要完全不能恢复 trace 的诊断信号

[2603.28052]。根源是尺度不同：前者说的是任务态的单次判定（失败

模式浅），后者说的是 harness 态的跨轮因果归因（把下游失败归因到很多步之前的设计决策）

[2605.18747]。还有一层削弱：98%+ 是在一个已知偏松的判据

上取得的——同一域自生成单测的假阳率是 MBPP 16.3% vs HumanEval 1.4%

[2303.11366]。反向也有削弱：所谓「不可压缩」只测了单次 LLM 摘要，

没测结构化或分离式压缩，结论过强 [2603.28052]。

分歧 3 — 共享越多越好，还是刻意分区才对。 表征层级把 File-only 排在最低端、

Blackboard 排在最高端，暗示单调优劣 [2605.18747]。但消息可见性

隔离（board agent 与某玩家的对话对另一玩家不可见、role-play 使各 agent 记忆隔离）被其

作者称为多 agent 正确性的隐形前提，用来防分心、幻觉与走捷径

[2308.08155]。这是故意不共享，四级层级里没有位置放它

[2605.18747]。

分歧 4 — 控制流该藏起来还是该导出。 一方主张去掉显式编排器、让控制流由 auto-reply

隐式涌现，这是通用性的来源 [2308.08155]；另一方（下游执行层）认为

藏起来的控制流等于对调度器不可见的结构，必须显式还原

[2308.08155]。根源是优化目标不同：一个优化开发者

表达力与任务成功率，一个优化批量同构 workflow 的吞吐。

分歧 5 — 被动惰性取，还是主动维护常驻工件。 生产上下文层默认「agent 需要时自己去

grep/read」[blog-dynamic-context-discovery]；相邻方案论证对反复查询

同一大上下文的工作负载，被动取不够，必须主动维护一份常量大小的常驻 map

[blog-dynamic-context-discovery]。根源是工作负载

假设不同（单次多样任务 vs 同一语料 n 次重复查询），两者是 workload-dependent 的互补而非

真冲突。

分歧 6 — 精巧的控制回路是不是必要的。 主题的整个规范性叙事建立在「回路越完整越好」

之上，但同一篇自己转述的反例是：在 SWE-bench 上有竞争力且不需要复杂 agentic 控制

[2605.18747]。评测侧的历史也指向同一方向——早期 <5% 的

悲观数字是非交互单次协议的产物，而非任务本身的性质

[2310.06770]。

7. Open challenges（根本性困难） #

以下五条不是「没人做」，而是做不动——每一条都需要至少两个 category 协同，且已知的

局部尝试都能说清为什么不够。

7.1 给共享程序状态一个度量空间 #

为什么难。 仓库状态是离散结构（文件树 + 内容 + 版本），没有天然的度量；关于状态的

唯一形式支点自承量纲未定义、绝对值号是隐喻性的 [2605.18747]。这不是

工程遗漏，而是「程序状态的距离」本身需要一个语义等价判据——语法距离（diff 行数）与

行为距离（测试向量）在同一份补丁上可以完全相反：模型补丁平均 19.6 行 / 1.0 文件，

而参考补丁 44.1 行 / 1.2 文件，短补丁却常常改对了函数、改错了条件

[2310.06770]。

需要谁协作。 agent（定义信念状态）+ code（提供可版本化的真值）+ 评测侧（提供可计算

的行为签名）。现成的部分解是逐测试通过/失败向量 [2310.06770]，

在其上定义汉明或加权距离，然后问一个可证伪的问题：偏离幅度能否在失败发生前若干步预测

失败 [2605.18747]。为什么仍不够：这个代理只在有完整测试套件的

仓库任务上存在，对 GUI/具身/科学发现域完全不适用。难度地平线：单域内 1–2 年，

通用定义未知。

7.2 长轨迹上的失败归因 #

为什么难。 这是信息量与成本之间的硬取舍，不是缺方法。压缩掉原始 trace，归因能力

就塌（median 50.0 → 34.6 / 34.9）[2603.28052]；不压缩，单次评估

可产生高达 10,000,000 token 的诊断信息，而代表性优化器每步可用上下文只有

100–30,000 token，差三个数量级 [2603.28052]。现状的量化结果是：

step-level 失败归因的最佳准确率只有 14–53%，遥测机制堆了这么多，仍无法可靠指出长轨迹里

是哪一步坏的 [2605.18747]。

已知的局部尝试为什么不够。 语言化的反事实归因（定位错误动作、合成修正计划、写成

第一人称教训）确实是承重成分——去掉它增益归零 [2303.11366]——但它

依赖 backbone 的自诊断能力，在阈值之下无论怎样做回路工程都补不回来

[2303.11366]。另一侧的证据是 proposer 能在 7 轮内识别

出「结构性修复被共享 prompt 改动 confound」并隔离变量

[2603.28052]，但这建立在闭源强模型加全保真历史之上，成本与可复现性

都未被算清 [2603.28052]。

需要谁协作。 agent（归因算法）+ algorithm（自适应压缩策略）+ code（可 grep 的 trace

落盘格式）。难度地平线：5 年以上，因为它同时受限于模型的自诊断能力上界。

7.3 验证 oracle 本身既不可靠也不便宜 #

为什么难。 整套规范把 linter / test / CI / fuzzer 当作确定性传感器

[2605.18747]，但 agent 自生成的测试并不确定：同一方法在 MBPP

Python 上因 16.3% 的假阳率反而低于 baseline（0.77 < 0.80），而 HumanEval Python 只有

1.4% [2303.11366]，因此设计被迫偏向「宁可假阴不要假阳」

[2303.11366]。而让执行真正可信的代价已被量过：逐 release

手工构建可执行 conda 环境、逐仓库写日志解析器、diff 前后日志认证至少一条 fail→pass

[2310.06770]。

为什么这不只是工程量。 oracle 可靠性是领域相关的常数，无法用更好的算法消除；

它决定了 Verify 能否自动接受还是必须升级给人，而这个参数目前在任何 escalation 设计里

都不是一等输入 [2605.18747]。需要谁协作：agent + code + 评测侧。

难度地平线：不会被「解决」，只会被显式建模——把该域自生成 oracle 的假阳率做成门控

变量是 1 年内可做的最小步。

7.4 静默无效动作没有传感器 #

为什么难。 失败可以表现为无效状态转移或静默执行错误——机器人去抓一个够不着的物体，

不会抛任何 runtime exception [2605.18747]。它的文本对应物在主题里

出现过两次：纯行动基线对着 sinkbasin 1 反复取物、观测恒为 "Nothing happens" 却不换

策略 [2210.03629]；跨 trial 自改进的主导基线失败类是幻觉持有某物

[2303.11366]。三者是同一个缺失传感器：**动作执行后状态是否真的

改变了**。

为什么它比看起来难。 检测器本身不难（比对动作前后的状态签名），难的是「状态签名」

依赖 §7.1 尚未解决的度量空间；在没有签名的域里，no-op 与「有效但慢」不可区分。

需要谁协作：agent + code。难度地平线：有测试向量的域 1 年内可做，其余绑定

§7.1 [2605.18747]。

7.5 共享与分区的联合设计 #

为什么难。 真实的多 agent 系统同时需要两件相反的事：哪些工件必须全局可查询，

哪些必须 agent 私有以防分心与走捷径 [2308.08155]。

现有的表征轴是单调的「越形式化越共享越好」[2605.18747]，分区在这

条轴上没有位置 [2605.18747]。这不是补一格的事——共享度与正确性的关系

很可能是非单调的（信息越多越容易分心），而没有任何工作把它当成一个设计维度

[2605.18747]。

附带的三个具体缺口：并发写冲突与读时快照语义在惰性文件方案里完全没被处理

[2605.18747]；惰性加载把「该不该取」的决策推给模型，其漏读率至今没有

任何基准 [blog-dynamic-context-discovery]；而「任何模型都会用文件

工具」这一前提对弱模型很可能不成立

[blog-dynamic-context-discovery]。难度地平线：设计维度的提出

1 年内，原则性的划分未知。

8. 成熟度判断 #

整体判断：migrating（迁移中）——机制层已经生产就绪，协调底座仍在研究前沿。

已生产就绪的部分（证据最硬）。

• 工具循环、权限、sandbox、文件支撑的记忆：一个 MIT 许可的开源实现同时具备 43 个工具、

三模式权限、PreToolUse/PostToolUse hooks、MEMORY.md 持久记忆、原生与 Docker 双

sandbox [HKUDS-OpenHarness]，并支持 10+ 后端

[HKUDS-OpenHarness]。

• 上下文层的惰性化：生产 A/B 且统计显著的 46.9% token 下降

[blog-dynamic-context-discovery]，证据等级是这条主题里最强的一类

[blog-dynamic-context-discovery]。

• 编排抽象：已从一篇论文固化为一层基础设施假设，下游系统把它当作必须兼容的既有标准

而非竞争对手 [2308.08155]。

• 评测契约：已成为社区的规范编码工作负载，连服务与调度类工作都拿它当主要测试床

[2310.06770]。

仍在研究前沿的部分。

• harness 搜索：在竞争性长 horizon benchmark 上已能胜过手工设计（Opus 4.6 上 76.4%

排第 2、Haiku 4.5 上 37.6% 排第 1）[2603.28052]，但 outer-loop

与 proposer 实现均未公开、proposer 是闭源模型，短期难被直接复用

[2603.28052]。

• 共享程序状态的形式化：唯一带形式记号的实例在被普查的七个系统里只有一行

[2605.18747]。

尚未成熟的部分（用数字说话）。

• 完整控制回路的覆盖率：15 行代表性系统里只有 1 行被标为完整的 Plan+Execute+Verify

[2605.18747]。

• 端到端自主率：生产级 issue-resolution 的公开参照点是 16.9% 完全自主 / 43.3% 需人工

介入 [2605.18747]。

• 可观测性：step-level 失败归因最佳准确率仍只有 14–53%

[2605.18747]。

• 生产实现自身的工程债：3M 字符代码只有 114 个单元/集成测试、5 周 9 个发布、

91KB 的单文件 CLI [HKUDS-OpenHarness]。

趋势方向：加速中，但增速来自采用而非原理突破。 8 周 13K star、约 1,600 star/周

[HKUDS-OpenHarness] 是采用侧的加速；能力侧的加速则体现在

同一评测上从最好模型（即使给定精确文件）也只解决 4.8%

[2310.06770]，到后续 agent 脚手架越过 50% 的历史

[2310.06770]。

但需要一个减速信号作平衡：同一批证据里既有「精巧回路不必要」的反例

[2605.18747]，也有「多 agent 的补能力价值随 backbone 变强

而缩水」的外推 [2308.08155]。**因此这条主题的加速是工程采纳曲线，

不是科学进展曲线。**

引用价值与实现价值必须分开看。 横向普查条目本身 478 条引用、0 实验、0 代码，唯一

配套产物是一份论文清单仓库 [2605.18747]；相比之下主题内每一个

其余条目都带可复现产物或生产数据 [2605.18747]。它的正确用法是索引与诊断

清单，而不是方法来源。

9. 邻接 topic #

可能的未来拆分：如果 Verify 侧继续积累（oracle 可靠性、传感器成本、静默失败检测），

verification 有独立成题的体量；目前它的条目全部落在本主题内部，拆分为时过早。

10. 参考 #

主题内最值得先读的三条路径：

1. 想理解回路本身 → 表征选择 [2210.03629] → 反馈闭环

[2303.11366] → PEV 与权限分层

[2605.18747]。

2. 想理解为什么系统会脆 → 中心 gap [2605.18747] → 生产实现的

实际落点 [HKUDS-OpenHarness] → 竞争解释

[2605.18747]。

3. 想动手改进 → 反馈保真度消融 [2603.28052] → 惰性上下文机制

[blog-dynamic-context-discovery] → 可 grep 的共享黑板这一最明确

的可造物 [2605.18747]。