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%这个比例不算最高但解决起来最麻烦。因为测试失败的原因千奇百怪有的是逻辑错有的是环境问题有的是测试本身写得有问题。我们的做法是把测试反馈做成一个闭环而不是一次性返回。具体来说Agent 修改完成后Harness 自动跑相关测试如果失败Harness 解析失败原因提取关键信息哪个用例、什么断言、期望值 vs 实际值把这些信息连同原始代码一起返回给 Agent让它做针对性修复最多重试 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 常见问题速查表调优过程中遇到的问题很多我挑几个最有代表性的整理成表方便你对照排查。问题现象可能原因排查方向解决思路Agent 反复读同一个文件上下文里缺少“已读”标记检查 Harness 的状态管理在上下文里显式标注已操作过的文件修改后测试全挂改错了位置或引入了语法错误看测试输出的第一行错误让 Agent 先跑语法检查再跑测试通过率波动大检索结果不稳定检查检索是否依赖随机性固定检索策略去掉随机采样Agent 不执行测试工具描述不清晰检查工具定义把测试命令写进约束清单强制执行修改范围过大粒度控制失效检查工具调用参数限制单次修改的代码行数上限中文注释乱码编码问题检查文件读写编码统一用 UTF-8Harness 层做转换依赖安装失败环境不一致检查依赖版本用锁文件固定版本Harness 预装依赖Agent 陷入死循环重试逻辑没有上限检查重试次数配置设置硬性上限超过就中断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 每一步在干什么。这个过程比任何调参都值钱。