Agent Harness 速览（2023 ~ 2026）
把 LLM 变成能在真实仓库里干活、跑长任务的 coding agent 的那层「运行时」· 产品（Codex / Claude Code / Kimi Code / Pi / DeepSeek）+ 学术（2025-至今）· 检索时间 2026-08-23 · 每篇 = 配方 + 一句话
零基础读法：模型之外，真正让 agent 干活的是这层「运行时」
定义：大模型只能生成文本；coding agent 要能读仓库、改文件、跑命令、看测试结果，并在多轮循环里持续推进任务。包在模型外面、把这些能力接起来的工程层就叫 harness。
方法：关键设计包括给模型的行动接口（CLI、文件 diff、测试反馈）、工具与沙箱、权限审批、上下文压缩、子代理分工和跨 turn 记忆。目标是让模型少浪费 token、少做危险操作，并能在长任务里保持状态。
模型：产品侧有 Codex、Claude Code、Kimi Code、Pi、DeepSeek 等；学术侧有 SWE-agent、Harness-1，以及各种 MCP/工具生态研究。
算法：不是只调模型权重，而是设计 loop：观察 → 规划 → 调工具 → 观察结果 → 再规划。Harness 需要管理 context、审批、错误恢复和任务状态，很多问题出在接口和状态管理，而不是模型能力。
评测：常看 SWE-bench Verified 的 resolved rate、Terminal-Bench、多轮工具调用成功率，以及端到端成本、延迟和人工通过率。一个 harness 好不好，不能只看最高分，还要看长任务里是否稳定、易操作。
读每篇时问：它改了模型和环境的哪个接口？它把什么状态从模型搬到了环境里？这样做省了什么、牺牲了什么？
0. 记法（这个领域的「最大公约数」）
agent harness = 包在语言模型外面的那层运行时工程：它管「模型和环境的接口、上下文、工具、审批、迭代循环」。核心问题只有两个：给 agent 什么样的行动接口（ACI），以及怎么在长任务里维持状态、不崩。配方围绕这两轴：
| 记号 | 意思 |
|---|---|
aci | Agent-Computer Interface：agent 和环境的行动接口（命令/文件编辑/diff/测试） |
tools / sandbox / approval | 工具调用 / 沙箱执行 / 审批权限边界 |
context / compaction | 上下文管理 / 压缩（长任务里 context 会爆） |
subagent / memory | 子代理分工 / 跨 turn 记忆 |
mcp / AGENTS.md | Model Context Protocol（工具生态）/ 项目上下文文件 |
state-externalize | 把「例行状态」从模型搬进环境（Harness-1 的思路） |
self-evolve | harness 自己改进自己（见 recursive-self-improvement） |
reward / verifier | agent RL 的奖励/验证器（跑测试、可执行） |
配方格式：harness -> 能力/结果 + 关键机制。例：SWE-agent: aci(命令+文件编辑+测试) -> SWE-bench 涨点 [自研 ACI]。
一句话主线：早期大家以为瓶颈是模型，结果发现「给模型什么工具、什么上下文、什么循环」这层 harness 常常比模型本身更决定成败——Agentless 用简单流水线打败复杂 agent，SWE-agent 证明调好 ACI 能大幅涨点。所以 2025 年的重心从「更强的模型」转向「更好的 harness」，甚至「让 harness 自己进化」。
1. 主线：从「调模型」到「调 harness」
- 基准奠基（2023）：SWE-bench 定义「真实 GitHub issue 修复」这个任务，让 coding agent 可量化。
- ACI 概念（2024）：SWE-agent 提出 Agent-Computer Interface，证明「接口设计」决定成败；Agentless 反向证明「简单流水线」就够，复杂 agent 未必更好。
- 产品化（2025）：Codex CLI、Claude Code、Kimi Code、Pi 等终端 harness 爆火，把 harness 工程推到台前。
- harness 工程学术化（2025-2026）：多篇综述（Code as Agent Harness、From QA to Task Completion）把「harness」立成独立研究方向，开始系统研究 context/工具/subagent/state 怎么设计。
- agent-native / 自我进化（2026）：Harness-1 把例行状态搬进环境、Kimi-Dev 用 agentless 训练当 skill prior，harness 和训练开始合流。
一条主轴：性能的决定因素从「模型能力」转向「模型 × harness 的交互」。交点是一个开放问题：harness 的哪部分该进模型（训练/蒸馏），哪部分该留环境（运行时）？
2. 先读这三篇（综述 + 定义）
按规范先读 survey。这三篇把「agent harness」从松散的工程黑话立成有定义的学术对象，是建立地图的入口。
Code as Agent Harness（2605.18747，UIUC/Meta/Stanford 2026，102 页）
survey -> 代码作为 agent 的运行基底 [代码从「输出」变「执行基底」]
问题 代码不再只是 agent 的输出、而是 agent 推理和行动的运行基底，这个转变怎么理解；方法 102 页综述，追问 agent 放进长期任务环境后 harness 怎么设计；核心 把「code as harness」立成主题，是这一章最权威的地图。
From Question Answering to Task Completion: Survey on Agent System and Harness Design（2606.20683，2026）
survey -> 四个范式的演进 [prompt → workflow → harness → agent-native]
问题 agent 从「问答」到「完成任务」，这条演进线怎么梳理；方法 把 LLM agent 的发展分成 prompt engineering → agentic workflow → harness engineering → agent-native training 四个范式；核心 核心洞察是「性能越来越由模型 × 运行时的交互决定，而非模型单独决定」。
What Makes a Harness a Harness（2606.10106，2026）
theory -> harness 的充要条件 [给「harness」下严格定义]
问题 「harness」一词被滥用——有时指整个产品、有时指中间件；方法 用五个研究问题给「agent harness」下充要条件定义；核心 把黑话变成可证伪的学术概念，是后续研究的概念锚点。
3. 产品 harness（Codex / Claude Code / Kimi Code / Pi / DeepSeek）
2025 年终端 coding agent 爆火，几家产品的 harness 设计成了事实标准。这些大多是工程/博客/系统卡而非单篇 arXiv，但它们是「harness 工程」最真实的标本。
Codex（OpenAI）（Codex as a platform · openai/codex）
harness(开源 Rust) -> 上下文/工具/审批/跨 turn [沙箱 + 审批策略 + AGENTS.md]
问题 怎么让 coding agent 在配置边界内可靠工作；方法 开源 Rust harness：管会话状态、流式执行、工具调用、沙箱与审批策略、跨 turn 推进；核心 把「harness engineering」做成产品——配套 GPT-5.1-Codex-Max 和系统卡，Codex 的开源 harness 也是它 IDE/桌面/云端形态的统一内核。
Claude Code（Anthropic）（Effective harnesses for long-running agents，2025-11）
harness(Claude Agent SDK) -> 长任务稳定 [subagent + compaction + 文件工具]
问题 长任务里 context 会爆、agent 会失焦，怎么维持稳定；方法 Claude Agent SDK + 子代理分工 + 上下文压缩 + 细粒度文件工具，工程博客系统总结「effective harness」实践；核心 被多篇综述引为「harness 工程」的权威工程文档，Claude Code 的 harness 是行业参照。
Kimi Code（Moonshot）（Kimi-Dev 论文 · Kimi Code CLI）
harness + agentless 训练 -> 60.4% SWE-bench Verified [agentless 当 skill prior]
问题 SWE-agent（多轮交互）和 Agentless（单轮可验证步骤）两派怎么统一；方法 用 agentless 训练当 skill prior，训出 72B 开源模型 Kimi-Dev；配 Kimi Code CLI（MCP、/init 生成 AGENTS.md）；核心 产品 + 学术二合一，证明「训练一个 agentless skill prior」能喂出 SOTA 工作流 agent。
Pi（earendil-works/pi）（github.com/earendil-works/pi）
harness(自扩展) -> 统一 LLM API + agent loop [self-extensible 编码 agent]
问题 开源 harness 怎么既统一又自扩展；方法 开源 agent harness：统一 LLM API、agent loop、TUI、coding agent CLI，强调「self-extensible」；核心 独立开发者主导的开源 harness（libGDX 作者 Mario Zechner），是「非大厂 harness 设计」的代表标本。
DeepSeek Harness（安全评估 2608.16393 · V4 报告）
harness(agent 后训练) -> agent 能力 [领域 expert + on-policy 蒸馏]
问题 DeepSeek 的 coding agent 怎么训、harness 安全边界如何；方法 V4 报告里的 agent 后训练（各领域独立 RL 出 expert、再 on-policy 蒸馏整合）+ 有第三方对其 harness 做间接提示注入安全评估；核心 说明「harness」已进入大厂模型后训练流程，且安全成为 harness 的一等议题。
4. 地基（2023-2024，任务与接口的定义）
harness 研究的地基：SWE-bench 定义了任务、SWE-agent 定义了「接口即性能」、OpenHands 定义了开源平台、Agentless 泼了「复杂 agent 未必好」的冷水。
SWE-bench（2310.06770，Jimenez et al. 2023）
benchmark -> 真实 GitHub issue 修复 [issue + PR + 测试判定]
问题 coding agent 怎么量化；方法 收集真实 GitHub issue + 对应修复 PR，用「跑测试」判定是否修好；核心 让 coding agent 可评测，是整个 harness 生态的起点；后续 SWE-bench Verified 指出原版含污染/易破解样本，抽干净子集——评测协议被修正、任务定义被保留。
SWE-agent（Agent-Computer Interface）（2405.15793，Yang et al. 2024）
aci(命令 + 文件编辑 + 测试) -> 大幅涨点 [自研 ACI 是核心贡献]
问题 agent 在 SWE-bench 上表现差，卡在哪；方法 提出「Agent-Computer Interface」概念，精心设计命令/文件编辑/diff/测试等接口，让 GPT-4 从 3% 涨到 12%；核心 「接口设计」这一概念的开山，证明 harness 的 ACI 比换模型更关键；后续 Agentless 指出复杂多轮 agent 未必更好，但 ACI 概念被保留为 harness 研究的核心轴。
OpenHands（2407.16741，Wang et al. 2024）
platform -> 通用 agent 平台 [开源 + 可插拔]
问题 缺一个能跑通用 agent 的开源平台；方法 开源平台，代码执行、事件流、agent 抽象可插拔；核心 harness 研究的公共实验台，很多后续工作在上面做。
Agentless（2407.01489，Xia et al. 2024）
流水线(定位+修复+选补丁) -> 简单打败复杂 agent [三段式非交互]
问题 复杂自主 agent 一定比简单流水线好吗；方法 用「定位、修复、选补丁」三段非交互流水线，不用多轮 agent；核心 简单流水线超过当时多数 agent，泼了「agent 复杂度 = 性能」的冷水。
5. 2025-2026 学术（harness 工程的深入）
harness 从「工程直觉」走向「系统研究」：纵向量化 harness 进化的贡献、总结终端 agent 的教训、把状态搬进环境、把 agentless 训练当 skill prior、以及更难的 live/真实经济基准。
Don't Blame the LLM（How Agent Harness Evolution Shapes Quality）（2607.03691，2026）
analysis(纵向) -> harness 进化贡献大 [系统提示/工具/上下文/循环]
问题 coding agent 变好，到底靠模型还是靠 harness；方法 纵向分析多个 harness 的发布历史，拆开系统提示、工具执行、上下文管理、迭代循环的各自贡献；核心 结论「别怪模型」——harness 进化本身就在塑造质量，把 harness 贡献量化了。
Building Effective AI Coding Agents for the Terminal（2603.05344，2026）
harness(终端) -> 长程开发教训 [scaffolding + context + 工程实践]
问题 终端 native 的 coding agent 怎么做才稳；方法 从 IDE 插件到终端 agent 的转变，总结 scaffolding、harness、context engineering 的教训；核心 工程实践的系统化总结，和 Anthropic 那篇博客互为印证。
Harness-1（State-Externalizing Harnesses）（2606.02373，Google 2026）
harness(状态外置) -> 20B 搜索 agent 打平更大模型 [例行状态搬进环境]
问题 搜索 agent 被训成「长 transcript 上的策略」，被迫同时管搜索决策和例行状态；方法 把例行状态（哪些证据有用、哪些检查过）从策略搬进环境侧的工作记忆；核心 20B agent 八个检索基准 0.730，打平甚至超过更大模型——「state-externalizing harness」的新方向。
Kimi-Dev（Agentless Training as Skill Prior）（2509.23045，Moonshot 2025）
agentless 训练 -> skill prior [单轮可验证步骤先学技能]
问题 SWE-agent 多轮交互和 Agentless 单轮可验证两派能否统一；方法 用 agentless 训练当「技能先验」，再喂给 SWE-agent；核心 开源 72B、60.4% SWE-bench Verified，工作流派 SoTA——证明「先学单轮技能」是训练 coding agent 的有效配方。
SWE-bench Live（2505.23419，2025）
benchmark(实时) -> 防数据泄露 [持续更新 issue]
问题 SWE-bench 被刷爆、有数据泄露；方法 持续采集新 issue，实时评测；核心 让 coding agent 评测「活起来」，防过拟合。
SWE-Lancer（2502.12115，2025）
benchmark(真实经济) -> 百万美元任务 [真实 freelancer 单子]
问题 合成/仓库 issue 之外，真实自由职业软件任务做得如何；方法 用真实 freelancer 任务（upwork 类），按经济价值评测；核心 把 coding agent 的经济价值量化，离真实工作更近。
MLGym（2502.14499，2025）
benchmark + framework -> AI 科研 agent [13 个开放科研任务]
问题 AI 做科研的 agent 怎么系统评测；方法 13 个开放科研任务 + 统一框架；核心 把 harness 从「写代码」扩展到「做科研」，AI Scientist 类工作的评测底座。
6. 共识与分歧（速记版）
共识：
- harness（接口/上下文/工具/循环）常常比模型本身更决定 coding agent 的成败。
- ACI 设计是核心杠杆：命令 + 文件编辑 + diff + 测试这套接口（SWE-agent）成为事实标准。
- context 管理和 compaction 是长任务的第一瓶颈（Claude Code / Codex 都把它当核心工程）。
- 评测从静态 SWE-bench 走向 live / 真实经济任务（SWE-bench Live / SWE-Lancer），防过拟合。
- harness 开始和训练合流：agentless 当 skill prior（Kimi-Dev）、状态外置（Harness-1）、agent-native training。
分歧 / 难点：
- 多轮自主 vs 单轮流水线：Agentless 证明简单流水线能打，Kimi-Dev 想把两者统一，但「什么任务值得多轮交互」仍未定。
- 状态放哪：把例行状态放模型（长 transcript）还是放环境（Harness-1 的外置），是 2026 的新分歧。
- harness 该进模型还是留运行时：蒸馏/训练进权重（subterranean agent）vs 留运行时，边界未定。
- 评测真实性：SWE-bench 高分 ≠ 真实工作能力，live/经济基准更难但嘈杂，缺统一标准。
- 安全：sandbox、审批、间接提示注入（DeepSeek Harness 安全评估）成为 harness 的一等议题，但规范未形成。
说明：产品（Codex/Claude Code/Kimi Code/Pi/DeepSeek Harness）多为工程博客/开源仓库/系统卡，无单一 arXiv，已按官方一手来源引用；学术论文（Code as Agent Harness、From QA to Task Completion、What makes a harness、Don't Blame the LLM、Harness-1、Kimi-Dev 等）已读摘要，arXiv 号逐一核对。「pi」= earendil-works/pi（开源自扩展 agent harness），非 Inflection Pi。agentic RL（tool calling / multi-turn / 环境奖励）与本主题相邻，建议单独成篇。