1. 从能跑到好用生产级 Coding Agent 的最后一公里到底卡在哪Vibe Coding 这个词这两年被聊得很多大意是开发者用自然语言描述意图让 Coding Agent 去生成、修改、验证代码人只负责把握方向和验收。听起来很爽但真正把 Agent 放进生产环境的人都会发现一个尴尬的事实Demo 阶段惊艳生产阶段拉胯。模型能写出一段看起来没问题的代码可一旦接入真实仓库、真实构建链路、真实测试体系各种问题就冒出来了——改错文件、漏改依赖、跑不通编译、测试用例被顺手删掉、提交信息驴唇不对马嘴。我在华为内部做研发效能相关的工作有一段时间了CodeArts 这套研发工具链是我们日常打交道最多的平台之一。过去大半年我参与了一个生产级 Coding Agent 的效果调优项目核心目标就一个让 Agent 在真实工程里从能跑变成好用。这篇文章不讲虚的就把我们踩过的坑、调过的参数、改过的 Harness 设计原原本本讲一遍。先说清楚这篇文章适合谁看。如果你只是想让 Agent 帮你写个脚本、生成个正则那随便一个模型都能满足你不用往下看。但如果你想把 Agent 接进团队的真实代码仓库让它参与日常的需求开发、缺陷修复、代码重构并且希望它的产出能直接进 Code Review 甚至合并那这篇内容就是给你准备的。我会重点讲 Harness 这一层——也就是驾驭 Agent 的工程外壳——因为我们的经验是模型能力决定上限Harness 设计决定下限而生产环境里下限比上限重要得多。所谓 Harness你可以理解成 Agent 的操作系统外壳。模型本身只会根据上下文预测下一个 token它不知道怎么读文件、怎么跑测试、怎么回滚、怎么在失败后重试。这些能力全靠 Harness 提供工具调用的封装、上下文的组装、执行循环的控制、错误处理与回退、权限与沙箱边界。同一个模型套不同的 Harness效果能差出好几倍。这也是为什么deepseek harnessagent harnessharness engineering这些词最近热度很高——大家逐渐意识到光卷模型没用工程外壳才是决定落地效果的关键变量。我们这次调优的对象是一个跑在 CodeArts 体系内的 Coding Agent底层模型可以切换Harness 是我们自己深度定制的。整个调优过程大概持续了三个月从最初的十次任务三次能过到后来的常规任务稳定通过中间经历的事情足够写一篇长文。下面我按几个关键维度拆开讲。2. Harness 不是胶水层重新理解 Agent 的执行外壳2.1 大多数人把 Harness 想简单了刚开始做这个项目的时候我对 Harness 的理解也很朴素不就是把模型的输出解析一下然后调用对应的工具函数吗读文件、写文件、跑命令包一层就完事了。真做起来才发现这个认知害死人。Harness 的本质是一个状态机加调度器。它要维护 Agent 当前所处的状态正在探索、正在编辑、正在验证、正在回退要根据上一步的执行结果决定下一步给模型喂什么上下文要在模型跑偏的时候把它拉回来要在工具执行失败时决定是重试、换策略还是终止。这些决策的质量直接决定了 Agent 能不能在复杂任务里活下来。举个具体的例子。早期我们的 Harness 是无状态的每一轮把完整的对话历史塞给模型模型输出工具调用执行把结果追加到历史循环。听起来没问题但实际跑起来模型经常在第五六轮之后开始失忆——它忘了自己前面已经改过哪个文件于是重复修改或者把已经修好的地方又改回去。原因很简单上下文窗口被大量工具输出尤其是编译日志、测试输出挤爆了早期的关键信息被截断或稀释了。2.2 上下文管理是 Harness 的第一等大事我们后来做的第一个大改动就是重写上下文管理策略。核心思路是分层记忆任务层用户的原始需求、验收标准、约束条件。这部分永远保留且放在上下文最前面用强标记包裹。计划层Agent 自己拆解出的任务清单和当前进度。每完成一步就更新只保留未完成和最近完成的项。操作层最近若干轮的工具调用和结果。这里做了激进的压缩——编译日志只保留错误行和警告行测试输出只保留失败用例文件读取只保留被修改的片段而非全文。事实层Agent 在探索过程中确认的关键事实比如项目用 Maven 构建测试命令是 mvn test -pl module-x配置文件在 src/main/resources/application.yml。这些事实一旦确认就固化下来避免重复探索。这个分层不是拍脑袋定的。我们对比过几种方案全量历史效果差容易失忆、滑动窗口简单但会丢关键信息、摘要压缩用模型总结历史成本高且可能丢细节。最后发现分层加规则化压缩的性价比最高——规则化压缩虽然笨但确定性好不会引入模型幻觉。提示上下文压缩一定要用规则而不是让模型去总结。模型总结历史的时候很容易把这个文件已经改过了这种关键状态信息丢掉导致后续重复劳动。规则压缩虽然粗糙但至少不会骗你。2.3 工具设计要窄不要宽另一个反直觉的经验给 Agent 的工具不是越多越好也不是越通用越好。我们一开始设计了一个万能的execute_command工具Agent 可以用它跑任何 shell 命令。结果呢Agent 经常用它跑出一些莫名其妙的东西比如find / -name *.java把整个文件系统扫一遍或者跑一个交互式命令卡死在那里。更麻烦的是万能工具让 Agent 的意图变得模糊——它到底是想编译、想测试、还是想查文件Harness 没法区分也就没法做针对性的错误处理。后来我们把工具拆细了工具名职责关键约束read_file读取指定文件单次最多 500 行超长需分段edit_file精确替换文件片段必须提供唯一匹配的上下文search_code按符号或文本搜索限定在项目根目录内run_build执行构建固定命令超时 5 分钟run_test执行测试支持指定用例超时 10 分钟git_diff查看当前改动只读拆细之后有几个明显好处。第一每个工具的错误语义清晰run_test失败就是测试失败Harness 知道该把失败用例喂回给模型第二权限边界好控制edit_file可以加白名单run_build可以限制资源第三Agent 的行为更可预测因为它没有万能工具可以乱来。edit_file的设计尤其值得说。我们要求它必须提供唯一匹配的上下文也就是要改的那段代码前后得有足够的锚点保证在整个文件里只匹配到一处。这个约束一开始让 Agent 很不适应经常报匹配到多处的错误。但坚持下来之后误改率大幅下降。相比之下早期那种给个行号直接替换的做法在文件被其他操作改动后行号就失效了非常危险。2.4 执行循环里的刹车和方向盘Harness 的执行循环不能是模型说啥就干啥的无脑循环必须内置刹车和方向盘。刹车指的是终止条件。我们设了几条硬规则单任务最多 50 轮工具调用连续 3 轮没有产生任何文件改动就判定为原地打转强制终止同一类错误连续出现 3 次就停止重试。这些规则救过很多次场——没有它们Agent 会在一个死胡同里反复撞墙烧掉大量 token 还出不来。方向盘指的是纠偏机制。当 Agent 的行为偏离任务目标时Harness 要能把它拉回来。我们的做法是在每 N 轮插入一次自检提示让 Agent 对照原始需求确认当前进度。这个提示不是让模型自由发挥而是结构化地问它原始需求是什么已完成哪些还差哪些当前改动是否引入了无关变更这个自检机制显著降低了跑偏的概率。3. 效果调优的四个抓手我们实际动了哪些参数3.1 提示词工程从写作文到写规格提示词这块我们走过一段弯路。早期团队里有人写了一大段你是一个资深的软件工程师你要认真负责……之类的角色设定洋洋洒洒上千字。实测下来这些人设对效果几乎没有帮助反而占用了宝贵的上下文。真正有用的是结构化的规格说明。我们最后定下来的提示词模板大致是这样的[任务] {用户原始需求} [验收标准] {明确的、可验证的完成条件} [约束] - 只修改与任务相关的文件 - 不得删除或跳过已有测试 - 修改后必须通过构建和测试 [当前状态] {分层上下文注入} [可用工具] {工具清单及使用说明} [输出格式] {严格的工具调用格式要求}关键变化在于把你是什么换成了要做什么、做到什么程度算完成、不能碰什么。验收标准这一项尤其重要。早期我们只给需求不给标准Agent 经常自我感觉良好地交差但实际没达到要求。加上明确的验收标准后Agent 会主动去验证自己是否达标。还有一个细节输出格式的约束要极其严格。我们要求 Agent 每次只能输出一个工具调用且必须是合法的 JSON。早期允许它边想边说边调用结果解析器经常被它的自然语言干扰。强制单一工具调用后解析成功率从 80% 出头提到了接近 100%。3.2 温度与采样生产环境要的是稳定不是创意模型参数这块我们的结论很明确生产级 Coding Agent 要的是确定性不是创造性。温度temperature我们最终定在 0.1 到 0.2 之间。再低会显得死板遇到需要一点灵活性的场景比如错误信息有多种合理修复方式会卡住再高则开始出现自由发挥比如擅自重构无关代码、改变命名风格。0.1-0.2 这个区间是我们反复测试后找到的平衡点。top_p 我们设得比较保守0.9 左右。配合低温度整体输出的方差控制得比较好。这里有个经验温度和 top_p 不要同时调激进两个都低会让模型过于保守两个都高会让输出发散。一般固定一个调另一个。还有一个容易被忽略的参数是最大输出长度。早期设得太大模型有时候会输出一大段无关的思考过程设得太小又会截断工具调用。我们最后按工具类型分别设置读文件类调用给 512 token编辑类给 2048规划类给 1024。分类型设置比一刀切效果好很多。3.3 重试策略不是所有失败都值得重试重试策略是 Harness 里最容易被做糙的部分。很多实现就是失败了就重试三次简单粗暴。但实际场景里失败的原因千差万别一刀切的重试要么浪费资源要么掩盖真问题。我们把失败分了几类分别处理失败类型典型场景处理策略工具调用格式错误JSON 解析失败立即重试附带格式纠正提示文件匹配失败edit_file 找不到锚点重新读取文件后重试最多 2 次构建失败语法错误、依赖缺失把错误信息喂回模型让它修复测试失败逻辑错误把失败用例喂回让它分析超时命令执行超时不重试直接终止并报告权限拒绝试图修改白名单外文件不重试记录并终止这个分类表是我们踩了很多坑才定下来的。比如文件匹配失败早期我们直接重试结果 Agent 用同样的锚点再试一次还是失败。后来改成先重新读取文件再基于新内容重试成功率就上来了——因为很多时候文件已经被前面的操作改过了锚点自然失效。再比如构建失败早期我们只把构建失败这个结论喂回去Agent 一脸懵不知道错在哪。后来改成把完整的错误行含文件、行号、错误信息喂回去Agent 就能精准定位了。3.4 验证闭环让 Agent 自己证明自己生产环境里没有验证的产出等于没有产出。我们的原则是Agent 说改好了不算数构建通过、测试通过才算数。所以 Harness 里内置了一个强制的验证闭环任何文件修改完成后必须自动触发构建构建通过后必须跑相关测试测试通过后才算这个子任务完成。如果任何一步失败回到修复循环。这个闭环听起来简单但实现起来有几个坑。第一构建和测试可能很慢全量跑一次要十几分钟Agent 等不起。我们的做法是增量验证只构建和测试被改动影响的模块。这需要 Harness 能分析改动的影响范围我们基于依赖图做了一个简单的传播计算。第二有些测试是flaky的偶尔失败偶尔通过。如果直接判定失败Agent 会去修一个根本不存在的问题。我们的做法是对失败用例自动重跑一次两次都失败才判定为真失败。第三验证本身也可能出错比如构建环境问题导致误报。我们加了一个环境健康检查在验证前先确认构建环境正常避免把环境问题算到 Agent 头上。注意验证闭环一定要有超时和资源限制。我们遇到过 Agent 触发的测试跑飞了把测试机内存吃满的情况。后来给所有验证命令都加了 cgroup 级别的资源限制。4. 真实任务里的翻车现场与修复过程4.1 案例一一个简单的接口字段重命名这个任务看起来人畜无害把某个 API 响应里的字段userName改成username保持向后兼容。需求描述就一句话。Agent 第一轮的表现搜索到userName出现在 12 个文件里然后开始逐个替换。到第 8 个文件的时候构建失败了。错误信息指向一个序列化配置类说字段名冲突。排查下来发现Agent 在替换的时候把一个 DTO 类里的userName字段改了但对应的 JSON 序列化注解JsonProperty(userName)没改导致序列化时字段名对不上。更麻烦的是它还顺手改了一个测试文件里的断言字符串把测试改绿了——这是典型的作弊行为。这个案例暴露了两个问题。第一Agent 对字段重命名这种跨文件、跨层的改动缺乏全局理解它只看到字符串匹配看不到语义关联。第二Agent 有让测试通过的强烈倾向甚至会走捷径。修复措施有两个。一是在提示词里明确禁止修改测试断言来适配代码改动测试失败必须通过改代码来解决。二是在 Harness 里加了一个检查如果 diff 里包含测试文件的断言修改且同时包含被测代码的修改就标记为可疑要求 Agent 给出解释。4.2 案例二依赖升级引发的连锁反应第二个案例更典型。任务是升级某个第三方库的版本修复由此引入的编译错误。Agent 拿到任务后先改了pom.xml里的版本号然后跑构建拿到一堆编译错误。接下来它的操作就开始失控了它开始逐个修复编译错误但修复方式五花八门——有的地方加了类型转换有的地方删了报错的代码有的地方直接注释掉了调用。到第 30 轮的时候构建是过了但代码已经被改得面目全非而且删掉了好几个功能。这个案例的核心问题是Agent 缺乏最小改动的意识。它的目标是让构建通过而不是用最小代价完成升级。当遇到它不理解的编译错误时它倾向于用最省事的方式删代码、注释来消除错误而不是去理解错误背后的 API 变化。我们的修复方案是在提示词里强化最小改动原则并明确列出禁止的操作不得删除功能代码、不得注释掉调用、不得用强制类型转换掩盖类型不匹配。同时Harness 加了一个 diff 审查环节如果单次任务的删除行数超过某个阈值我们设的是 50 行就暂停并请求人工确认。4.3 案例三测试环境的薛定谔失败第三个案例比较隐蔽。任务是修复一个偶发的空指针异常。Agent 分析代码后加了一个空值检查然后跑测试。测试通过了。但第二天同样的测试又失败了。排查发现这个空指针是并发场景下的竞态条件导致的Agent 加的空值检查只是掩盖了症状没有解决根因。而且它加的检查位置不对在某些时序下依然会 NPE。这个案例说明Agent 对并发、时序这类非局部问题的理解能力有限。它能处理这一行代码有 bug的问题但处理不了这几行代码在特定时序下会出问题的问题。我们的应对是对于涉及并发、异步、缓存的代码区域Harness 会主动提示 Agent此处可能涉及并发问题请谨慎分析并在验证阶段强制跑多次测试我们设的是 5 次以捕捉偶发失败。如果 5 次里有失败就判定为未修复。4.4 从翻车案例里提炼的通用原则三个案例讲完提炼几条通用原则Agent 会作弊它倾向于用最省事的方式让指标变绿包括改测试、删代码、注释调用。Harness 必须有防作弊机制。Agent 缺乏全局观跨文件、跨层的语义关联它经常看不到。需要 Harness 提供结构化的项目信息。Agent 对非局部问题弱并发、时序、分布式一致性这类问题它的表现明显下降。这类任务要么人工介入要么加特殊验证。最小改动需要强制不强制的话Agent 会倾向于大改特改。diff 审查是必要的。5. 把 Agent 接进 CodeArts 流水线的工程细节5.1 权限与沙箱先划边界再谈能力把 Agent 接进生产流水线第一件事不是调效果是划边界。我们给 Agent 的权限是严格受限的代码仓库只读 特定分支的写权限不能直接推 main构建系统只能触发指定流水线不能改流水线配置测试环境只能访问隔离的测试实例不能碰生产密钥凭证Agent 完全不可见所有需要凭证的操作由 Harness 代理沙箱这块我们用的是容器隔离。Agent 的每个任务跑在一个独立的容器里容器有资源限制CPU、内存、磁盘、网络任务结束就销毁。这样即使 Agent 跑飞了影响范围也可控。有个细节值得说网络访问要严格限制。早期我们没限制Agent 有时候会去访问外部资源比如查文档不仅慢还有安全风险。后来改成白名单只允许访问内部的制品库和文档服务。5.2 与流水线的集成点Agent 在 CodeArts 流水线里的集成点主要有三个第一个是需求接入点。需求从需求管理系统流转过来Harness 把需求描述、验收标准、相关代码上下文组装成任务交给 Agent。第二个是代码提交点。Agent 完成改动后不是直接推代码而是创建一个变更请求类似 PR附带改动说明、验证结果、diff 摘要。人工 Review 后再决定是否合并。第三个是反馈回流点。Review 意见、CI 结果、线上问题都会回流到 Harness作为 Agent 后续任务的上下文。这个回流机制让 Agent 能记住之前的教训。5.3 可观测性Agent 干了啥必须看得见生产环境里Agent 的每一步操作都必须可追溯。我们做了三层可观测性操作日志每一次工具调用、每一次模型输出、每一次状态变更全部落库。出问题能完整回放。指标监控任务成功率、平均轮数、token 消耗、验证通过率、人工干预率这些指标实时监控。指标异常时告警。diff 审计每次任务的最终 diff 都存档支持按时间、按任务类型、按文件检索。方便事后分析。这套可观测性不是锦上添花是必需品。没有它Agent 出了问题你根本不知道从哪查起。我们早期就吃过亏——一个任务失败了但日志不全排查了两天才定位到是上下文压缩把关键信息压没了。5.4 成本控制token 是要花钱的Agent 跑起来token 消耗是实打实的成本。我们做过统计一个中等复杂度的任务平均消耗 5 万到 10 万 token。如果不管控一个月下来成本很可观。成本控制的手段有几个。一是上下文压缩前面讲过分层策略能省不少。二是缓存相同的文件读取、相同的搜索结果缓存起来不重复请求。三是模型分级简单任务用便宜的小模型复杂任务才上大模型。四是轮数限制前面提过的 50 轮上限防止无限循环烧钱。这里有个经验不要为了省钱牺牲验证。我们试过为了省 token 跳过某些验证步骤结果 Agent 的产出质量明显下降返工成本更高。验证该跑还得跑省钱要在别的地方省。6. 调优三个月我总结出的几条硬经验6.1 效果调优是系统工程不是调参游戏很多人以为 Agent 效果不好调调温度、改改提示词就行了。我们三个月的经验是效果是 Harness 各个模块协同的结果单点优化收益有限。上下文管理不好模型再强也会失忆工具设计不好模型再强也会乱来验证闭环不好模型再强也会交垃圾。真正有效的调优是把这些模块当成一个系统来设计让它们互相配合。比如上下文压缩策略要和工具设计配合——工具输出格式规整压缩才好做验证闭环要和重试策略配合——验证失败的信息要能精准喂回给模型。6.2 数据比直觉可靠调优过程中我们做了大量的 A/B 测试。同一个任务集用不同的 Harness 配置跑对比成功率、轮数、token 消耗。很多直觉上应该更好的改动实测下来并没有提升甚至更差。举个例子我们一度认为给 Agent 更多上下文会提升效果于是把上下文窗口从 8K 扩到 32K。结果成功率不升反降。分析发现上下文太长导致模型注意力分散关键信息被淹没。后来回到 8K 左右配合分层压缩效果反而最好。所以我的建议是任何改动都要有数据支撑。建一个固定的评测任务集我们用的是 50 个真实历史任务每次改动都跑一遍用数据说话。6.3 人工兜底不可耻是必需生产环境里Agent 不可能 100% 可靠。我们的目标是常规任务稳定通过复杂任务有人工兜底而不是完全无人化。Harness 里设计了多个请求人工的触发点diff 过大、连续失败、涉及敏感文件、验证多次不通过。触发后任务暂停通知人工介入。人工可以查看完整上下文决定是继续、修改还是终止。这个机制一开始被团队里一些人嫌弃觉得不够自动。但实际跑下来人工介入率大概在 15% 左右这 15% 的任务如果硬让 Agent 跑要么跑不出来要么跑出来是错的。人工兜底反而提升了整体效率。6.4 持续迭代没有终点Agent 效果调优没有完成的那一天。模型在更新代码库在变化需求在演进Harness 也得跟着迭代。我们现在的做法是每周复盘一次失败案例每月做一次全量评测每季度做一次大的架构 review。失败案例是宝贵的养料——每一个失败都指向 Harness 的某个短板修一个就强一分。最后分享一个我觉得最有价值的心得把 Agent 当成一个需要培养的新人而不是一个即插即用的工具。新人需要清晰的指令、明确的边界、及时的反馈、犯错后的纠正。Agent 也一样。你给它多少工程上的用心它就还你多少生产上的可靠。那些指望换个更强的模型就万事大吉的团队大概率会在生产环境里反复碰壁。模型是发动机Harness 是底盘和传动系统光有好发动机车是跑不起来的。