编码智能体中的harness：从概念到动态策略落地实践

1. 为什么编码智能体突然开始讨论“harness”这件事

最近有一类问题在开发者社区里反复出现：同样是调用一个很强的大模型，为什么别人做的编码智能体可以自动修 issue、改 bug、过测试，而自己搭的 Agent 却经常“跑偏”，要么改错文件，要么改完代码不跑测试就宣称完成？

答案往往不在模型本身，而在模型外面那一层“什么该看、什么该做、什么时候停”的控制逻辑上。这个控制逻辑，在 Anthropic 的 Codex 相关讨论、OpenAI 的 Agent 方案、以及最近热起来的各种开源编码智能体项目中，被统称为 harness。

从搜索热词也能看到，deepseek harness、harness engineering、harness 安装、harness 教程这一类关键词在近期快速升温。说明社区已经意识到：编码智能体的效果瓶颈，可能正在从底层大模型的能力，转移到 harness 的设计质量上。这也是 openJiuwen 论文标题里把“动态 harness”和“长程编码智能体”放在一起的原因。

本文围绕这几个问题展开：

• harness 到底指什么，和 Agent 是什么关系；
• 为什么一个设计良好的 harness，能在 SWE-bench Verified 这类真实软件工程评测上带来显著收益；
• 静态 harness 和动态 harness 的区别在哪里；
• 社区里已经出现的 harness 工具形态和实践误区；
• 如何在自己的编码智能体项目里，落地一个最小可用的 harness 设计。

整篇不是论文复述，而是一份从概念到实践的解读与落地指南。

2. harness 是什么：编码智能体的“操作边界”

2.1 从字面理解：类似登山绳和安全带

harness 英文原意是“背带、挽具、安全带”。在高空作业、攀岩场景中，安全绳把人和锚点连接起来，决定了你能走到哪、能跨多远、一旦失足会被拉回到哪里。

编码智能体里的 harness ，作用类似。它是在模型与代码仓库之间搭起的一层工程框架，负责定义模型可以执行哪些动作、以什么顺序执行、如何观察结果、什么条件下算完成、什么条件下必须停止。

没有 harness 的编码智能体，本质是一个“只会说不会做”的对话模型：收到自然语言指令后，直接生成一段代码回复给你。你把代码复制到项目里，手动编译、手动跑测试、手动检查影响范围。这种方式对单文件修改勉强够用，但面对多文件、跨服务、带上下文依赖的长程任务，几乎没有可行性。

有了 harness 之后，模型不只输出代码，还能输出结构化的动作指令，比如“读取某个文件”“编辑某个函数”“在指定目录下运行测试命令”“查看报错输出后再次修改”。harness 负责解释这些指令、在真实终端或文件系统里执行、把结果返回给模型，形成“思考—行动—观察—再思考”的循环。

2.2 harness 具体管哪些事

用一个实际场景来理解。假设任务描述是：“修复api-client.js中鉴权过期后不自动刷新的问题”。

无 harness 的做法是：模型直接给出一段修复后的代码，至于这段代码放在哪个文件、是否与现有模块兼容、测试是否通过，全部交给开发者处理。

有 harness 的做法是：模型先通过工具读取仓库结构，定位api-client.js和相关的鉴权模块；随后通过编辑工具精确修改代码；再执行项目已有的测试用例。一旦某个测试失败，模型通过 harness 拿到失败信息，回到代码中继续排查。整个流程中，harness 负责约束模型的每一步操作，避免它跳过测试或修改无关文件。

更具体地说，harness 通常包含这几个子系统：

• 工具层：模型可以调用的工具集合，例如读文件、写文件、执行 Shell 命令、检索代码语义、查看测试结果；
• 状态管理层：记录当前仓库 diff、当前工作目录、任务目标、已执行过的动作和结果，让模型在长程任务中不“失忆”；
• 策略层：决定什么动作在什么阶段允许执行，比如“测试未通过之前不允许提交”“改动公共工具函数之前必须确认调用方”；
• 终止与恢复机制：判断任务完成条件，或者在一个循环陷入死胡同时触发回退。

把 harness 理解成“给 Agent 装上操作边界和安全绳”，比理解为“一个插件”或“一套工具函数”要更接近本质。

2.3 harness 为什么能显著影响评测结果

这是真正值得展开的点。同一个模型，在不同 harness 下跑 SWE-bench，效果可能差异很大。原因在于，软件工程的真实任务不是“生成一段答案”，而是在一段很长的工作流中连续做决策。

长程编码智能体的难点主要有三个：

第一，上下文会迅速膨胀。初始任务描述只有几句话，但 Agent 在修复过程中会不断读取文件、查看报错、搜索引用，每步都把新内容塞进上下文。如果没有 harness 对上下文做裁剪和检索增强，模型很快会被大量无关信息干扰。

第二，动作空间很大且不可逆。Agent 可以编辑多个文件、运行测试、安装依赖、甚至修改配置文件。动作一多，很容易出现“改了这个文件导致另一个功能挂掉”的连锁问题。harness 可以对这些动作设置约束和检查点，比如在关键改动前要求先跑一遍已有测试，建立“基线”。

第三，完成条件不明确。模型会说“修复完成”，但代码是否真的能通过测试、是否满足项目原有风格，模型自己不知道。harness 通过接入测试框架和静态检查工具，用具体信号来判断完成状态。

所以，同样的模型能力下，harness 的设计直接决定了智能体的流程完整度。openJiuwen 论文标题中强调“动态 harness”，正是因为在长程任务中，静态规则无法适应不同任务的变化。

3. 动态 harness 与静态 harness：真正的分水岭

3.1 静态 harness：按固定剧本执行

静态 harness 的典型工作方式是：开发者预先定义好一套固定流程，比如“先读 README -> 再跑测试 -> 修改代码 -> 再跑测试 -> 输出 diff”，模型只能沿着这个流程走。

它的优点是逻辑简单、行为可预期，适合任务类型比较固定的场景。比如一个专门负责“给 Python 项目补充单元测试”的智能体，完全可以采用静态 harness：定位测试文件，读取被测模块，生成测试代码，运行测试，输出报告。

它的缺点是应对不了长程任务的复杂性。真实 issue 的根因可能在多个文件里，可能在依赖配置里，可能在数据库迁移脚本里。如果 harness 固定要求 Agent 先跑测试，而这个项目测试环境根本起不来，Agent 就会卡在第一步。

3.2 动态 harness：按任务状态调整策略

动态 harness 不再使用固定剧本，而是根据当前任务状态、环境反馈、历史动作效果，实时调整下一步动作集合和执行顺序。

用通俗的话说，动态 harness 里的“剧本”不再是写死的，而是模型与 harness 协同时实时生成的。harness 仍然负责安全边界和核心约束，但具体走哪条路径、先看哪个文件、什么时候换工具，可以根据任务动态变化。

这种设计带来的直接收益是：

• 任务类型发生变化时，Agent 不需要人工重写流程；
• 模型在遇到阻塞时可以灵活切换策略，而不是永远卡在同一个固定步骤；
• harness 可以根据模型的行为质量实时收紧或放松约束，例如在模型连续犯错时，要求更小步的代码修改和更频繁的测试验证。

3.3 “动态”不是让模型自由发挥

这里有一个常见误解：动态 harness 就是把所有控制权交给模型，让它随便调用工具。事实恰恰相反，动态 harness 的动态性体现在“约束策略”的动态调整，而不是“取消约束”。

模型在每一步仍然只能调用 harness 注册过的工具，仍然受安全规则限制，仍然要在完成条件满足后才能收尾。动态变化的只是：在不同任务阶段，允许调用哪些工具、执行顺序如何选择、哪些操作需要额外确认。

可以类比为自动挡汽车和手动挡汽车的区别。静态 harness 像手动挡：档位是固定的，司机（Agent）只能按顺序切换。动态 harness 像自动挡：换挡逻辑由系统实时计算，但系统依旧不能违反物理极限和安全规则。模型可以更专注于问题本身，而不是被固定流程拖累。

4. SWE-bench Verified 82.6% 意味着什么

4.1 先了解 SWE-bench 是做什么的

SWE-bench 是普林斯顿大学团队提出的数据集，旨在评测大模型在真实软件工程任务上的能力。任务不是写一段独立的算法代码，而是给定一个真实 GitHub 仓库、一个由真实 issue 转化来的问题描述，要求模型修改仓库代码，使仓库通过对应的测试用例。

为了让任务更接近软件开发中的真实协作场景，数据集中的每个实例都包含：

• issue 描述：描述用户遇到的 bug 或希望添加的功能；
• 原始仓库代码：修复前的完整代码快照；
• 测试补丁：修复后项目应通过的测试，评测时会隐藏起来，模型看不到完整测试代码；
• 参考补丁：人工或项目维护者实际提交的修复代码，用于对照但不参与打分。

模型要在这类任务上拿高分，不能靠“记忆训练数据”，因为每个仓库、每个 issue 都是独立的。它必须能真正理解代码库结构，准确定位问题根因，修改正确位置，并保证不破坏其他功能。

SWE-bench Verified 是经过人工筛选后的一个子集，去掉了描述模糊、复现困难、测试不稳定的实例，分数更能反映模型在真实问题上的能力。

4.2 82.6% 的成绩说明了什么

从标题信息来看，openJiuwen 论文中报告的是通过动态 harness 方案，在 SWE-bench Verified 上达到 82.6% 的通过率。这个数字在没有额外跑分细节的情况下不适合做过度的横向对比，但它传递了一个明确信号：编码智能体的性能上限，很大程度上可以由 harness 设计来抬升。

SWE-bench 的典型任务是长程任务。模型可能要先浏览几十个文件，找到相关函数，理解调用链，修改代码，然后运行测试，根据失败信息再调整。任何一个环节缺少 harness 支持，成功率都会明显下降。

82.6% 这个结果的价值在于：他不是通过更换更大参数量模型、也不是通过扩充训练数据来硬顶上去的，而是通过改进“模型与环境交互的方式”实现的。这意味着，在模型能力不变的前提下，harness 工程化也能带来指数级的效果提升。对于没有资源训练自己模型的团队来说，这是一个非常值得关注的方向。

4.3 对这个分数保持理性

需要提醒的是，SWE-bench 是一个评测基准，不代表真实商业软件工程的全部复杂度。真实项目还涉及代码评审机制、多人协作冲突、历史包袱、部署回报验证、产品需求歧义等问题。一个能在 SWE-bench 上拿到高分的 Agent，也不一定可以直接无人值守地跑在你们的正式仓库上。

更合理的判断是：SWE-bench Verified 82.6% 说明这套 harness 方案在“给定独立 issue、给定可验证测试、需要长程代码修改”的任务上具备很强的流程控制能力。这类任务与真实开源维护和内部 bug 修复有很高的重合度，所以实践参考价值也很高。

5. 为什么长程任务特别吃 harness

5.1 长程任务的失败模式

所谓长程编码任务，是指需要多轮工具调用、多文件修改、带状态累积和验证反馈才能完成的任务。这类任务的失败模式非常典型：

• 遗忘初始目标：模型在探查代码时被细节带走，忘记了最初要修什么问题；
• 局部最优陷阱：模型总是盯着第一次发现的疑似根因改，即使后续测试证明问题不在那里，也不愿意跳出原有思路；
• 重复无效动作：模型反复读同一个文件、跑同一个失败测试，不产生新信息却停不下来；
• 上下文污染：探查过太多无关文件后，模型对代码结构的判断被噪声信息带偏；
• 验证缺失：模型没有跑测试就宣布任务完成，或者把“测试命令执行成功”误认为“业务逻辑正确”。

这些失败模式，很难靠提示词层面的“请你谨慎一点”解决，必须靠 harness 在机制层面做约束。

5.2 harness 如何对抗这些失败模式

针对遗忘目标，动态 harness 可以在循环中维护一个“任务状态对象”，每次模型调用工具前，系统都把初始任务目标以摘要形式注入上下文，让模型每步都明确“我在修什么、我为什么在修”。

针对局部最优，harness 可以通过记录模型的尝试历史，当发现同一位置被修改多次仍未解决问题时，主动触发策略切换，提示模型扩大搜索范围，或者把控制权交还给更上层的规划模块。

针对重复无效动作，harness 可以计算每步是否引入了新信息。如果连续 N 步的观察结果没有变化，就不再让模型继续请求同一个工具，而是强制模型切换方向或总结失败原因。

针对上下文污染，harness 可以做“上下文预算管理”。模型每次读取的文件内容不会全部保留，而是按任务相关性评分后截断或摘要，必要时把旧文件内容移出上下文，只保留 Diff 概览和关键符号表。

5.3 长程任务中“验证”优先级极高

动态 harness 的一个重要设计理念，是让“验证”成为一个高优先级动作，而不仅是可选项。

以修复 bug 为例。模型在给出修复方案后，harness 并不是直接结束任务，而是自动触发以下验证链：

静态检查（编译/语法） -> 相关模块单元测试 -> 全量测试（可选） -> diff 影响面确认

每一步失败都会作为反馈重新输入给模型。只有在全部验证信号都通过后，harness 才把任务标记为“完成”。这不仅是工程上的严谨，也是长程任务效果提升的关键原因：模型无法再“说谎”，只能真实地解决测试暴露出的问题。

6. 让 harness 思想落地的工程实践

这一节从抽象原理走向具体操作。无论是使用社区中已经出现的 harness 工具，还是自己搭一套轻量级的 Agent 框架，几个核心设计点是一致的。

6.1 工具集合设计：不是越多越好

很多初做 Agent 的团队，第一反应是把所有能调用的 API 都注册成工具。实际上工具放的越多，模型的选择难度越大，误用概率也越高。

推荐的做法是分层开放工具。核心层工具服务于当前任务类型，比如“编辑代码”场景只开放读文件、写文件、执行测试三个工具。扩展层工具按需开放，比如只有检测到前端项目时才开放“构建工具”。动态 harness 的优势就在这里：工具集可以随时按任务阶段增删，而不是一次性堆给模型。

{ "core_tools": [ "read_file", "edit_file", "run_test", "list_directory" ], "extended_tools": [ "search_symbol", "install_dependency", "run_linter", "git_diff" ], "tool_selection_rule": "core_tools always available; extended_tools enabled based on task stage and project type" }

6.2 状态管理：给 Agent 一个“工作记忆”

长程任务中，模型自带的上下文窗口是无状态的。模型不会自动记住 20 步之前观察到的一条关键线索，所以 harness 需要显式地维护任务状态。

一个实用的状态对象应包含：

• 任务目标摘要；
• 当前问题根因假设；
• 已尝试的方案和结果；
• 当前代码 Diff 摘要；
• 验证结果记录。

每次 Agent 发起新的工具调用前，harness 把这些关键状态以结构化文本注入上下文。这样即使上下文被大量文件内容覆盖，模型也始终能回到主线。

# 文件路径：harness_demo/state.py from dataclasses import dataclass, field from typing import List @dataclass class TaskState: goal: str current_hypothesis: str = "" attempted_solutions: List[str] = field(default_factory=list) diff_summary: str = "" validation_results: List[str] = field(default_factory=list) def to_prompt_context(self) -> str: sections = [ f"任务目标: {self.goal}", f"当前假设: {self.current_hypothesis}", f"已尝试方案: {'; '.join(self.attempted_solutions) if self.attempted_solutions else '无'}", f"当前改动摘要: {self.diff_summary or '无'}", f"验证结果: {'; '.join(self.validation_results) if self.validation_results else '未验证'}", ] return "\n".join(sections)

核心逻辑是：把状态从模型上下文的外面拿出来，由 harness 统一持有，再按需注入。这样模型每次看到的都是迁移后的、结构化的任务纪要，而不是原始对话历史的堆叠。

6.3 动态决策：用简单规则驱动策略切换

动态 harness 不等于必须引入复杂强化学习。在很多场景下，一组阈值触发的规则策略就能表现出足够的“动态性”。

比如定义以下策略切换规则：

- 如果连续 3 次测试失败，切换到“深度分析模式”：禁止再次修改代码，必须先输出根因分析； - 如果修改文件数超过 5 个但测试仍未通过，切换回“最小改动模式”：要求模型检查是否修改范围过大； - 如果工具调用超过 30 步，自动输出任务简报，提醒开发者介入； - 如果验证链任一环节失败，任务状态禁止标记为完成。

这些规则可以在 harness 中以声明式配置实现，也可以写成一个简单的策略引擎。对于大多数团队来说，从规则策略起步已经能获得明显的稳定性提升，不必一上来就上强化学习方案。

6.4 一个最小可用的 harness 循环

这里给出一个极简的 Python 示例，展示 harness 如何控制 Agent 的“思考-行动-观察”循环。示例简化了模型调用部分，重点展示循环控制逻辑。

# 文件路径：harness_demo/loop.py import os from typing import Callable from harness_demo.state import TaskState class SimpleHarness: def __init__( self, model_fn: Callable[[str], str], execute_tool: Callable[[str, str], str], max_steps: int = 20, ): self.model_fn = model_fn self.execute_tool = execute_tool self.max_steps = max_steps self.history = [] def run(self, task: str) -> TaskState: state = TaskState(goal=task) for step in range(self.max_steps): context = state.to_prompt_context() recent = "\n".join(self.history[-3:]) prompt = ( f"{context}\n\n" f"最近执行记录:\n{recent}\n\n" "请输出下一步动作，格式: TOOL: 工具名 | ARGS: 参数\n" "如果任务已完成，输出: FINISH" ) response = self.model_fn(prompt).strip() if response.upper().startswith("FINISH"): return state if "|" not in response: self.history.append("ERROR: 动作格式错误") continue tool_line, args_line = response.split("|", maxsplit=1) tool_name = tool_line.replace("TOOL:", "").strip() args = args_line.replace("ARGS:", "").strip() observation = self.execute_tool(tool_name, args) # 记录尝试与观察结果 self.history.append(f"动作: {tool_name} {args}\n观察: {observation[:500]}") state.attempted_solutions.append(f"{tool_name}: {args[:100]}") if "TEST_RESULT: FAIL" in observation: state.validation_results.append("最近一次测试未通过") state.validation_results.append("达到最大步数，需要人工介入") return state

这个示例的重点不是生产可用，而是演示 harness 的核心控制结构：状态注入、动作解析、工具执行、结果记录、终止判断。实际工程中，model_fn 可以换成任意大模型的 API，execute_tool 可以换成真实的文件系统和终端调用。

6.5 社区中的 harness 工具形态

根据搜索热词中出现的deepseek harness、codex harness、agent harness等关键词，社区中已经出现了一些围绕 harness 的工程化尝试。它们大体可以分为三类：

第一类是模型厂商自带的交互框架。比如 OpenAI Codex 系列讨论中提到的 harness 逻辑，重点是让模型在沙箱中执行代码、查看执行结果、迭代修 bug。这类 harness 目的是让模型和代码环境之间形成闭环反馈。

第二类是第三方 Agent 框架中的 harness 模块。很多开源 AI 编程助手项目开始抽出“工具调用循环”这一层，把它做成可配置的模块。开发者可以自定义工具列表、执行策略、安全限制。

第三类是桌面端工具和插件。一些 harness 项目以插件形式存在，可以挂载到 IDE 或聊天工具中。搜索热词里的deepseek harness 插件、harness 插件中心说明这类工具开始走向普通开发者的日常流程。

从整体趋势看，harness 正在从“大模型项目的内部实现细节”变成“可以独立安装、配置、二次开发的工程层组件”。这是编码智能体走向工程化的标志。

6.6 一个容易踩的坑：插件和配置加载失败

搜索热词中有这样一条：harness failed to load plugins web boot: 1 entry did not activate @nanmicode。这是一个非常典型的 harness 工程化问题。

任何 harness 如果支持插件机制，都会遇到插件加载失败的情况。常见原因有三个：

• 插件入口声明不正确，指定的入口文件不存在或导出格式不符合规范；
• 插件依赖的某个 npm 包、Python 包或系统库缺失；
• 插件与当前 harness 版本不兼容，激活函数签名发生了变化。

排查这类问题时，优先级应该是：先看 harness 启动日志中是否打印了加载失败的具体堆栈，再确认插件清单中声明的入口路径是否真实存在，最后检查插件依赖和版本。不要一上来就重装整个 harness，那样大概率会掩盖真正的问题。

如果自己设计插件机制，建议在插件清单里加入版本号、入口文件、依赖列表和最低 harness 版本要求，并在加载失败时输出结构化错误信息，而不是只抛一个“entry did not activate”。

7. harness 设计中的常见问题与排查方法

这些问题的共性是：表面上像“模型能力不足”，实际上很多都是 harness 的控制逻辑存在缺口。优先修正 harness，往往比更换更大模型更有效。

8. 最佳实践与工程建议

8.1 从静态规则起步，再逐步动态化

不要一开始就设计一个充满策略切换和自适应逻辑的动态 harness。先写死一套简单规则，跑通端到端的流程，再去观察阻塞点在哪里。比如先用“读文件-改文件-跑测试”的三板斧固定流程，积累一定量的失败样本后，再针对高频失败模式加入策略切换。动态化不是目标，解决问题才是。

8.2 工具注册表要显式声明权限边界

harness 中每个工具都应有四件套：工具名、功能说明、参数 schema、权限等级。权限等级至少区分“只读”“受限写”“高风险写”“外部命令执行”。在工具调用前，harness 必须做一次权限校验，而不是把工具的调用权完全交给模型。

{ "tool_name": "edit_file", "description": "修改仓库内指定文件的指定区域", "parameters": { "file_path": {"type": "string"}, "start_line": {"type": "integer"}, "end_line": {"type": "integer"}, "new_content": {"type": "string"} }, "permission_level": "restricted_write", "allowed_paths": ["/workspace/repo"], "blocked_paths": ["/workspace/repo/.git", "/workspace/repo/vendor"] }

8.3 记录每一步动作，形成可回放的操作日志

编码智能体一旦开始多次调用工具，就会产生大量副作用的动作。最好的做法是把每一步动作、参数、观察结果、耗时都记录为结构化日志，并且支持回放。这样既方便排查“为什么 Agent 做了某个改动”，也方便做策略复盘。

推荐记录的最小字段：

• 步骤号；
• 时间戳；
• 工具名；
• 传入参数；
• 返回结果摘要；
• 当前任务状态摘要；
• 触发该动作的模型推理片段（截断）。

8.4 验证链必须可配置，但默认从严

不同项目的验证成本差异很大。一个大型 Java 项目的全量编译可能需要几分钟，而一个 Python 小项目的单测可能只需要几秒。因此验证链要支持按项目配置，比如：

validation_chain: - type: syntax_check enabled: true - type: module_test enabled: true command: "pytest tests/test_auth.py" - type: full_build enabled: false

但建议“修改影响范围的测试”默认开启，不能因为耗时被关掉。如果模型改动了 10 个文件却只跑过一次测试，这个任务根本不应该标记为完成。

8.5 高风险的“写操作”必须设置护栏

写文件在编码智能体里属于高风险操作。推荐的护栏包括：

• 写文件前自动生成备份，或者至少要求确认目标文件的原始内容；
• 禁止直接修改.git目录下的内容；
• 删除文件、批量替换、修改依赖锁文件这类操作默认禁止，除非任务目标明确说明；
• 引入新依赖时，harness 应强制检查依赖来源和许可证。

这些护栏不是限制能力，而是保证 Agent 在真实仓库上运行时，不会因为一次“顺手”的操作造成不可逆的破坏。

8.6 团队使用时要设计人工介入点

即使动态 harness 能处理很多问题，真实项目里仍应保留人工介入节点。至少有两个节点建议必须有人确认：

• 涉及删除文件或修改 CI/CD 配置时；
• 涉及变更公共 API 或数据库结构时。

实现方式可以是在 harness 中定义“pending_review”状态。当动作被判定为高风险时，harness 先暂停，输出变更预览，等待人工确认后才继续执行。

8.7 用离线 workload 回归测试 harness 本身

harness 是代码，也会被改坏。建议把一批有代表性的历史任务固化为回归测试集，每次修改 harness 的策略或工具层之后，都跑一遍回归验证。这样可以尽早发现“策略调整提升了一个任务，却破坏了另外一类任务”的回归问题。

9. 后续学习和实践方向

harness 这个方向目前还在快速发展期，论文、开源项目、插件工具每天都在更新。对于想深入实践的人来说，建议从三个方向入手：

第一，把一个开源编码智能体项目跑起来，重点阅读它的工具调用循环和状态管理代码，看它如何处理“模型输出 - 工具执行 - 结果反馈”的闭环。这比读抽象的理论文章更能形成直觉。

第二，准备一个自己的私有测试任务集。选 10 个有代表性的 bug 修复任务，手动记录模型当前在哪些环节失败，针对失败环节设计 harness 策略。每轮改进后都重新跑一遍任务集，观察成功率变化。

第三，关注 SWE-bench 评测和类似基准的更新。编码智能体的发展速度很快，评测集本身也在不断修订。了解最新评测任务的特点，有助于判断一个 harness 方案的实力边界，而不是被单一数字带节奏。

回到开头的问题：为什么同样的模型，别人做出来的编码智能体效果更好？现在的答案更清晰了——模型负责“聪明”，harness 负责“可靠”。一个结构设计良好的 harness，可以把模型的能力稳定地转化为代码仓库里的真实修改。SWE-bench Verified 82.6% 这个数字，提醒我们的不是某一篇论文有多强，而是这个共识已经开始形成：编码智能体的下一阶段竞争，将从模型层扩展到工程层，harness 正是工程层的核心抓手。