Coding Agent生产级调优：Harness如何让通过率从30%到70%

1. 从“能跑”到“好用”到底差了什么

Vibe Coding 这个词从去年火到现在，很多人已经过了“哇，Agent 能自己写代码”的新鲜期，开始进入一个更务实、也更痛苦的阶段：Demo 跑得通，生产环境一用就露馅。我自己在团队里推 Coding Agent 落地的时候，最深的一个感受就是——模型能力只是入场券，真正决定它能不能在真实项目里干活儿的，是外面那一层“壳”，也就是现在大家常说的Harness。

这次想聊的，是我在华为 CodeArts 体系下做生产级 Coding Agent 效果调优的一段实录。核心场景很具体：让 Agent 在真实工程仓库里完成多文件修改、跑通测试、通过Multi-SWE-bench这类评测，并且稳定到可以交给团队日常使用。标题里说的“最后一公里”，指的就是从“模型能生成正确代码片段”到“Agent 能在工程约束下稳定交付”之间那段最磨人的距离。

如果你正在做 Coding Agent 的落地，或者被 Harness 和 Agent 的区别绕得有点晕，又或者你已经在用 DeepSeek Harness、Codex 这类工具但总觉得效果差口气，那这篇内容应该能给你一些可以直接抄作业的思路。我会把调优过程中踩过的坑、试过的参数、以及那些文档里不会写的经验都摊开讲，尽量让不同基础的人都能拿走点东西。

先说一个我自己的判断：Coding Agent 的效果调优，本质上是在调“信息流”和“约束流”。模型再强，如果喂给它的上下文是脏的、约束是模糊的、反馈是延迟的，它就会像一个能力很强但沟通不畅的新人，产出忽好忽坏。下面我按几个关键环节拆开讲。

2. 整体设计思路：为什么 Harness 比模型更值得花时间

2.1 Harness 和 Agent 到底差在哪

很多人第一次听到 Harness 这个词会懵，觉得不就是个“外壳”吗。我刚开始也这么想，后来发现这个理解太浅了。用个生活化的类比：Agent 是司机，Harness 是整辆车加上路况系统。司机技术再好，如果车没有方向盘助力、仪表盘不显示油量、路上没有车道线，他也没法稳定把你送到目的地。

具体到工程实现上，Agent 通常指的是“决策循环”——它决定下一步做什么，是读文件、改代码、还是跑测试。而 Harness 负责的是这个循环之外的一切：上下文怎么组装、工具怎么调用、结果怎么回传、失败怎么重试、状态怎么保持。我见过太多团队把精力全砸在换模型上，结果 Harness 层做得稀烂，最后效果还不如一个中等模型配一套精心设计的 Harness。

在华为 CodeArts 这套体系里，Harness 的价值尤其明显。因为企业级仓库往往有几个特点：代码量大、依赖复杂、有内部规范、测试链路长。这些都不是模型本身能解决的，必须靠 Harness 去“翻译”和“约束”。

2.2 为什么选 Multi-SWE-bench 作为调优标尺

调优最怕的就是没有客观标尺，全靠“感觉好像好了一点”。我们选Multi-SWE-bench作为主要评测集，原因有几个。第一，它是多语言、多仓库的，比单一语言的 benchmark 更接近真实工程场景。第二，它的任务形式是“给一个 issue，让 Agent 去修”，这跟生产环境里 Agent 实际要干的事高度一致。第三，它有明确的通过标准，通常是测试用例全绿，这就避免了“看起来改对了”这种主观判断。

我个人的经验是，调优一定要有一个能自动跑的、结果稳定的评测集。哪怕这个评测集不完全贴合你的业务，它也能帮你排除掉大量“改了 A 结果 B 退化”的情况。Multi-SWE-bench 在这点上帮我们省了很多扯皮的时间。

2.3 调优的三个核心目标

整个调优过程，我脑子里始终盯着三个目标，按优先级排：

• 正确性：改出来的代码要能通过测试，这是底线。
• 稳定性：同一个任务跑三次，不能一次成功两次失败，方差要小。
• 效率：在保证前两者的前提下，减少无效的工具调用和 token 消耗。

这三个目标是有冲突的。比如为了稳定性加很多重试和校验，效率就会下降。所以调优的过程，其实是在这三者之间找平衡点。下面我按实操顺序，把每个环节的关键细节展开。

3. 核心细节解析：上下文组装与工具调用

3.1 上下文不是越多越好，而是要“刚刚好”

这是我在调优里花时间最多、也最有收获的一块。刚开始做的时候，我的直觉是“把能塞的上下文都塞进去”，结果发现效果反而变差。原因很简单：上下文里噪音太多，模型会分心。

后来我总结了一个原则：上下文要围绕“当前决策点”来组织，而不是围绕“整个任务”来堆砌。具体做法是，Harness 在每一轮决策前，只组装这几类信息：

• 当前 issue 的描述（精简版，去掉无关的讨论）
• 与 issue 相关的文件片段（通过检索定位，而不是全量塞入）
• 最近几轮的操作历史和结果（保持短期记忆）
• 当前仓库的关键约束（比如代码风格、测试命令）

这里有个细节值得说：文件片段的检索质量，直接决定 Agent 的起点。我们试过纯关键词检索、向量检索、以及两者混合。实测下来，在代码场景里，基于符号（函数名、类名、文件名）的检索比纯语义检索更稳。因为代码的语义和自然语言不一样，一个函数名往往比一段注释更能定位到关键位置。

提示：如果你在用 DeepSeek Harness 或者类似的工具，先去看看它的上下文组装逻辑是不是可配置的。很多默认配置是“全量塞入”，这在生产仓库里基本不可用。

3.2 工具调用的粒度设计

工具调用的粒度，是另一个容易被忽视但影响巨大的点。太粗，Agent 一次调用做太多事，出错难定位；太细，Agent 要来回很多轮，效率低还容易迷路。

我们的做法是，把工具分成三层：

实测下来，中粒度是主力。粗粒度容易误伤，细粒度太琐碎。Harness 需要根据任务类型自动选择合适的粒度，而不是让模型自己猜。

还有一个经验：工具返回结果要结构化，不要返回一大坨原始文本。比如跑测试，不要直接把整个测试输出丢回去，而是解析成“哪些用例通过、哪些失败、失败原因是什么”。这样模型下一轮决策会准很多。

3.3 约束的显式化

生产环境和 Demo 最大的区别，就是约束多。代码规范、目录结构、依赖版本、测试要求，这些如果不在 Harness 里显式化，模型就会按自己的“习惯”来，结果就是改出来的代码风格五花八门。

我们的做法是，在 Harness 里维护一份约束清单，每轮决策前注入。清单内容包括：

• 代码风格（缩进、命名、注释要求）
• 禁止修改的文件（比如配置文件、生成代码）
• 必须运行的测试命令
• 提交前的检查项

这份清单不用很长，但一定要具体、可执行。比如“遵循 PEP8”就不如“函数名用 snake_case，行宽不超过 120”来得有效。

4. 实操过程：从 30% 到 70% 通过率的调优记录

4.1 基线测试：先搞清楚差在哪

调优第一步，永远是先跑一个基线。我们拿 Multi-SWE-bench 的一个子集，大概 200 个任务，跑了一遍原始配置。结果通过率只有 30% 出头。这个数字其实不意外，意外的是失败原因的分布。

我们把失败案例分了类，发现大致是这么个比例：

• 定位错误：Agent 找错了要改的文件或函数，占 40%
• 修改不完整：改对了一部分，漏了关联改动，占 25%
• 测试失败：改完了但测试没过，占 20%
• 格式/规范问题：逻辑对但不符合规范，占 10%
• 其他：占 5%

这个分布很关键。它告诉我们，最大的问题不在“写代码”，而在“找位置”。所以后续调优的重心，就放在了检索和定位上，而不是去换更强的模型。

4.2 第一轮调优：强化检索定位

针对定位错误，我们做了三件事。

第一，引入符号索引。在仓库初始化的时候，Harness 会扫描所有代码文件，建立函数、类、变量的符号表。当 issue 里提到某个功能时，先通过符号表定位到候选文件，而不是全文检索。

第二，多轮检索确认。Agent 定位到候选文件后，Harness 会要求它先读文件、确认是否相关，再决定是否修改。这一步看起来多余，但实测能减少很多“看错文件就动手”的情况。

第三，issue 描述预处理。很多 issue 描述里夹杂着大量无关讨论，我们用一个轻量模型先做摘要，提取出“要改什么、在哪改、验收标准是什么”三个要素，再喂给主 Agent。

这一轮调优后，通过率从 30% 提到了 45% 左右。提升主要来自定位错误的减少。

4.3 第二轮调优：修改完整性校验

定位准了之后，下一个大问题是“改一半”。比如改了一个函数，但调用它的地方没同步改；或者改了实现，但没更新对应的测试。

我们的解法是，在 Harness 里加一个影响面分析步骤。Agent 完成修改后，Harness 会自动做两件事：

• 找出所有引用了被修改符号的位置，检查是否需要同步修改
• 检查是否有相关的测试文件需要更新

这个步骤不是让 Agent 自己判断，而是 Harness 用静态分析工具跑一遍，把结果作为“待确认项”返回给 Agent。Agent 只需要确认或否认，不需要自己去找。

这里有个坑要提醒：静态分析工具的输出要过滤。我们一开始把所有的引用都返回，结果 Agent 被大量无关引用淹没。后来加了过滤规则，只返回“可能受影响”的，效果才好起来。

这一轮之后，通过率到了 55% 左右。

4.4 第三轮调优：测试反馈的闭环

测试失败占 20%，这个比例不算最高，但解决起来最麻烦。因为测试失败的原因千奇百怪，有的是逻辑错，有的是环境问题，有的是测试本身写得有问题。

我们的做法是，把测试反馈做成一个闭环，而不是一次性返回。具体来说：

1. Agent 修改完成后，Harness 自动跑相关测试
2. 如果失败，Harness 解析失败原因，提取关键信息（哪个用例、什么断言、期望值 vs 实际值）
3. 把这些信息连同原始代码，一起返回给 Agent，让它做针对性修复
4. 最多重试 3 轮，3 轮还不过就标记为失败，交给人工

这个闭环的关键在于失败信息的提取质量。我们试过直接返回原始测试输出，Agent 经常抓不住重点。后来写了一套解析规则，把测试输出结构化，Agent 的修复成功率明显提升。

还有一个细节：重试次数不是越多越好。我们试过 5 轮，发现第 4、5 轮基本是在瞎改，反而把之前对的改错了。3 轮是个比较平衡的点。

这一轮之后，通过率到了 65% 左右。

4.5 第四轮调优：规范约束与格式统一

最后一轮提升来自规范约束。前面提到，10% 的失败是格式问题。这类问题逻辑上不难，但很烦人，因为每个仓库的规范不一样。

我们的解法是，在 Harness 里内置一个格式化钩子。Agent 修改完代码后，Harness 自动调用仓库对应的格式化工具（比如 Python 的 black、JS 的 prettier），把代码格式化一遍。这样 Agent 就不需要操心格式，专注逻辑就行。

同时，对于命名规范这类格式化工具管不了的，我们在约束清单里写清楚，并且在 Agent 提交前做一次检查，不符合就返回让它改。

这一轮之后，通过率稳定在了 70% 左右。从 30% 到 70%，花了大概三周时间，中间踩了无数坑。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

调优过程中遇到的问题很多，我挑几个最有代表性的，整理成表，方便你对照排查。

5.2 几个独家避坑技巧

技巧一：给 Agent 一个“退出机制”。很多 Agent 卡住是因为它不知道该什么时候停。我们在 Harness 里加了一个规则：如果连续两轮没有产生实质性的文件修改，就强制结束，返回当前状态。这个规则救了很多次“无限循环”。

技巧二：日志要记全，但看的时候要过滤。调优期间，我们把每一轮的输入输出都记了日志。但日志量太大，后来写了个脚本，只提取“决策点”相关的信息，比如“这一轮选了什么工具、参数是什么、结果如何”。这样排查效率高很多。

技巧三：不要迷信“最新模型”。我们试过换更强的模型，通过率确实有提升，但提升幅度远不如 Harness 调优。而且强模型的成本高、延迟大，在生产环境里不一定划算。我的建议是，先把 Harness 调到极限，再考虑换模型。

技巧四：人工兜底不是失败。70% 的通过率意味着 30% 需要人工介入。这不是丢人的事，生产环境里人工兜底是常态。关键是要让这 30% 的介入成本足够低，比如 Harness 把失败原因和已尝试的方案整理好，人工只需要做最后判断。

5.3 关于 DeepSeek Harness 等工具的使用心得

热词里提到很多 DeepSeek Harness 相关的问题，比如插件安装、离线使用、权限报错。我自己的经验是，这类工具的核心价值在于可配置性。如果它允许你改上下文组装逻辑、改工具定义、改重试策略，那它就值得投入时间。如果它是个黑盒，只能调几个参数，那效果上限就很有限。

另外，离线局域网使用是个常见需求。我们的做法是，把 Harness 依赖的模型和工具都本地化部署，检索索引也本地构建。这样虽然初始化麻烦点，但稳定性和数据安全性都好很多。

6. 效果调优的长期维护思路

调优不是一锤子买卖。仓库在变、依赖在变、需求在变，Harness 也得跟着变。我们现在维持着一个月度回归的节奏：每个月拿最新的 Multi-SWE-bench 子集跑一遍，看看通过率有没有退化。如果退化超过 5 个百分点，就启动排查。

另外，我们会把每次人工兜底的案例收集起来，分析是不是有共性。如果有，就把它转化成 Harness 的一条新规则。这样 Harness 会随着使用越来越“懂”我们的仓库。

我个人在实际操作中的体会是，Coding Agent 的调优，七分靠 Harness，三分靠模型。把信息流理顺、把约束写清、把反馈闭环做好，效果自然就上来了。那些看起来“玄学”的效果波动，拆开看基本都是工程问题，不是模型问题。

最后再分享一个小技巧：如果你刚开始做，别一上来就追求高通过率。先把一个任务跑通，把日志看明白，搞清楚 Agent 每一步在干什么。这个过程比任何调参都值钱。