Vibe Coding 最后一公里：华为生产级 Coding Agent 效果调优实录

Vibe Coding 的规模化增长已经发生：用户更多、请求更频繁、代码生成量更大，采纳代码行也同步攀升。但生产级落地不能只看规模，真正困难的是最后一公里：Agent 是否稳定、可控、可评测、可回滚，并且能在真实使用中越用越好。

这篇文章围绕华为生产级 Coding Agent 的实践，把问题拆成三层：先看规模化现状，再看卡住生产级效果的六个工程问题，最后讨论如何用 Harness、记忆、工具、可观测性和评测体系把 Agent 调到可生产使用。

Vibe Coding 从尝鲜走向规模化日常

从 2025-09 到 2026-08，华为内部 Vibe Coding 的四条关键曲线同向增长，数据均为内部脱敏口径：

指标	增长幅度	说明
AI 用户数	超二十倍	从少数人尝鲜扩展到全员日常
人均请求次数	超三十倍	工程师对 Agent 的使用频率显著提高
生成代码行	超百倍	代码产出形成规模
采纳代码行	超百倍	生成结果不只是被尝试，而是真的进入研发流程

四条曲线的形态相似：2025 年缓慢爬坡，2026 年明显起飞。它们分别代表规模、强度、产出和落地：用的人越来越多，每个人越用越勤，模型产出开始爆发，最终被采纳的代码也在增长。图中的曲线经过脱敏和归一化，适合比较趋势，不能据此读出绝对人数、代码行数或采纳率。

但这并不意味着问题已经解决。规模增长证明 Vibe Coding 已进入日常研发流程，却不能自动证明生产级效果已经稳定。采纳是最后一环，也是最难一环。用户、请求、生成量上涨之后，真正要追问的是：这些代码能不能稳定通过验证，能不能被团队放心接入生产流程。

华为 Coding Agent 的演化也体现了这种转变。以下是演讲中列出的五个阶段性里程碑：

时间	里程碑	说明
2025-05	CodeMate 内置开源工具 Cline	早期通过集成开源工具补齐 Coding Agent 能力
2025-08	CodeMate 上线第一版自研 CodeAgent	从修补开源项目转向自研 Agent
2025-12	CodeMate 内置 Claude Code	引入成熟 Coding Agent 能力
2026-01	华为云码道 CodeArts 代码智能体公测	自研能力产品化外溢
2026-04	CodeArts Agent 列为 Multi-SWE-bench Java 榜单 Top1	演讲中展示的阶段性榜单结果

这条演化路径展示了从集成工具转向自研、产品化和评测的过程。榜单名次说明某套题目上的表现，不能直接替代真实业务场景的验收。

卡住生产级 Agent 的六个工程问题

规模上去了，效果不一定跟上。生产级 Coding Agent 的瓶颈不是单点模型能力，而是六个工程问题同时存在短板。

问题	关键词	核心矛盾
引导的两难	失控与窒息	零引导会迷路，全编排会僵死
反馈与试错	盲飞且不敢错	优化无反馈，验证靠上线
没有记忆	每次都是新手	经验不沉淀，同类问题重复踩坑
特性打架	合起来不好用	上下文、工具、指令、时机互相冲突
可观测性差	黑盒里调优	埋点难、数据散、分析难
现网数据闭环	数据飞轮转不起来	真实反馈没有回流到调优流程

引导的两难：零引导会失控，全编排会窒息

生产级 Coding Agent 的第一个坑，是引导的度。

零引导的问题是失控。只给目标和工具，Agent 的探索空间很大，但长任务很容易中途漂移，在同一区域反复兜圈，错误也可能到很晚才暴露。很多本来可以通过确认解决的需求，会变成一连串问题单。

全编排的问题是窒息。把步骤、分支和规则都写死，Agent 会退化为高级执行器。任务一变，流程就要推倒重写；遇到未覆盖情况，链路容易中断；为了堵问题不断往 Prompt 里堆规则，最后规则之间还会互相冲突。

更合理的方向是：给地图，不锁路线。Agent 需要目标、边界和关键状态提示，但不应该被固定成机械流程。

反馈与试错：优化在盲飞，验证靠上线

很多 Agent 优化手段本质上只是"可能有用"：改 Prompt、加规则、调工具。这次有效，下次可能无效，甚至可能拉低效果。如果缺少及时反馈，有效、无效、负向三种结果很难区分。

更麻烦的是，真实效果往往要上线后才知道。上线、用户使用、数据回收，一轮通常需要数周。评测集与真实场景存在差异，错误代价又高，错一次就可能变成线上事故，回滚和用户信任都要付成本。

所以调优不能只靠感觉，也不能只依赖上线验证。关键是缩短反馈链路，降低试错成本。

没有记忆：第 100 次任务仍像第 1 次

人类工程师会越用越熟，但没有记忆机制的 Agent 不会。每次任务都从零开始，上次踩过的坑这次照样踩，修过的编译错误下周还会再来一遍。

记忆缺失会带来三类成本：

表现	问题	结果
零记忆	每次从零开始	只记住当前会话
重复踩坑	修过的 bug 原样回归	踩坑成本按次全额支付
无老手加成	用得再多也不变快	第 1 次和第 N 次没有差别

没有沉淀，就没有加速。换更强模型也不等于有经验，记忆必须长在 Harness 里。

特性打架：单个最优不等于组合最优

团队规模变大后，不同目标会互相打架。Codebase 团队希望工具调用率高，成本团队希望推理成本低，精确度团队希望总解决率提升。每个目标单看都合理，合起来可能变成 1 + 1 < 1。

类型	典型表现	后果
上下文打架	memory、skills、规则、系统提示都想进上下文	注意力被摊薄，关键指令被淹没
工具打架	MCP 越挂越多，工具名字相近、职责重叠	模型经常选错工具
指令打架	一条要求快速自主，另一条要求逐步确认	模型行为忽左忽右
时机打架	权限弹窗、Hook 在子代理执行中途打断	刚建立的思路被截断

真正的解法不是继续堆特性，而是为特性组合做整体设计。

黑盒调优：看不见，就调不动

想回答"效果好不好"，至少要过三关：埋点、数据、分析。

难点	具体问题	结果
埋点难	一轮任务几十次工具调用，模型、Prompt、工具同时在变	不知道埋什么、埋在哪
数据散	Trace 散在各 Harness、各环境，日志格式不统一	轨迹、代码、评测对不上
分析难	海量轨迹里变量太多，一次失败要翻几千行日志	归因全靠猜

不埋点就没有数据；有数据但读不懂，也无法指导调优。缺少可观测性时，调优只能停留在"感觉变好了"。

数据飞轮：真实反馈没有进入闭环

最真实的反馈来自用户现网使用，但这些数据往往只被归档，没有进入调优闭环。

现网数据的阻塞点主要有三个：真实交互只当日志存，用户代码与隐私带来合规红线，拒绝、回滚、采纳等反馈没有结构化采集。于是从用户行为到版本改进之间，每一环都缺机制。

用户的每次使用都是反馈。如果不用起来，Agent 就永远停在第一版；如果没有回流调优闭环，Agent 越用也不会自然越好用。

把 Agent 当玩家：Harness 负责地图与边界

理解生产级 Agent，可以借用银河恶魔城（Metroidvania）的设计思路。银河恶魔城类游戏通常有连通的大地图、非线性探索、能力解锁新区域、回溯探索等特征。玩家不是一直直线推进，而是在卡住后探索其他区域，获得新能力，再回头解决障碍。

LLM Agent 使用 Harness 的过程与此类似：

玩家玩 Metroid	LLM Agent 使用 Harness
接到任务	接到任务
沿主线推进	沿主线推进
遇到障碍	卡住
探索未知区域	探索其他方向
获得新技能	获得关键信息
回头解决障碍	解决卡点并继续推进

Harness 的作用类似关卡结构与能力门槛：它不直接替玩家完成任务，而是通过环境和约束组织探索路径。图中的回环尤其重要：卡住后探索、获得信息、解除阻塞，再回到主线，而不是从头重跑。

Agent 设计有两个极端。严格引导模式会预先编排一切，步骤、分支、校验点全部写死，优点是可控、可复现、易评估，缺点是上限被编排者锁死，意外即断链，维护昂贵。完全不引导模式只给目标和工具，剩下全靠模型自己，优点是上限高、编排成本低，缺点是不可复现、方差大，长任务容易跑飞。

生产级要的是中间路线：给地图，给引导，但不锁死路线。目标不是把 Agent 变成固定流程机器，也不是把一切完全交给模型自由发挥，而是提供足够环境结构，让模型在边界内自主推进。

可落地的手段包括：

手段	作用
system reminder	周期性提醒目标、边界和当前状态
/goal	明确任务目标、期望输出和约束
注意力机制	帮助模型维持在当前关键任务上

《Metroid Dread》的玩家引导很有启发。它有九大互联区域，没有目标箭头，玩家却几乎不迷路。对应到 Agent / Harness，可以转化为一组工程机制：

游戏机制	Agent / Harness 落地
锁与钥匙	阻塞点登记：卡住时记录缺什么、在哪；获得关键信息后重扫阻塞表
临时锁区、单向通道	只暴露当前里程碑的子任务与文件，已完成内容归档收走
奇景伏笔	提前展示目标终态，例如期望输出、接口签名、/goal
新能力教学	首次使用工具时提供受控场景、沙箱、示范和恢复手段
NPC 对话拿任务	周期性重申目标与边界，通过 system reminder 注入当前任务

这组机制把目标、阻塞点和恢复手段放在环境里。模型仍可选择路线，但不会因忘记目标或一次失败而反复兜圈。

核心原则是引导环境：提供足够的目标和边界，让模型在设计好的决策空间里自主规划。

让试错变便宜，让探索变可控

复杂任务一定会出错，关键不是消灭错误，而是降低错误成本。

在游戏里，死亡并不意味着全局重来。玩家通常只回到几步前的存档，进度和道具不丢，可以反复挑战 Boss 或 EMMI 难题。失败本身也会积累经验：哪条路走不通，心里有数。

Agent 也应该这样设计：出错不等于全局重来。Harness 可以把阶段快照落盘，例如 git commit 和环境状态保存；失败时回退到最近现场，只重做局部；环境和代码都可恢复；教训不能只依赖模型上下文，而要由 Harness 记下。

把「一步错、全局重来」变成局部回退，完成率自然会上来
试错成本 ↓ ⇒ 探索意愿 ↑

这也解释了为什么不能把所有任务都设计成线性 Workflow。线性 Workflow 像 Mario，一条路走到底，跳过即失败；非线性 Agent 更像 Metroid，只圈范围，不锁路线。偏离路径不一定是幻觉，破序可能是更优解。判断标准应该看终态，而不是看是否按既定路径执行。

一个典型反例是：需求是 lint 零报错，两小时后 lint 通过了，但代码一塌糊涂，因为 Agent 把 .lintrc 改了。这里的问题不是 Agent 没按路径走，而是 Harness 没锁住边界。

破序 ≠ 错误
判定看终态，不看路径
自主交给模型，边界交给 Harness

Pi 和 Claude Code 展示了两种值得借鉴的克制设计。

Pi 的思路是做减法，只保留 Read、Write、Edit、Bash 等基础能力；不会的技能自己写代码扩展并支持热加载；会话可以树状分支，难题分出去修，修好再合并。它在 Terminal Bench 2.0 进入前五，并获得 GitHub 24k stars，体现的是"不预设你需要什么，让你自己决定"。

Claude Code 的思路是锁边界而不是锁路径。它维持 plan → act → test → review 的循环，提供 default → bypassPermissions 的权限分级，子代理有独立上下文和工具白名单，auto 模式下由 Haiku 分类器逐动作审查。关键不是工具越少越好，而是每个任务暴露的工具面要窄。

记忆长在 Harness，而不是模型里

速通游戏的启发在于：首通可能需要 10 多小时，熟练玩家可以把时间压到 2 小时以内，最快纪录甚至到 40 分钟。游戏本身没有变，变强的是玩家和社区。哪里能跳、哪里有近路、哪里容易卡，全都被记住并共享。

Agent 如果没有长期记忆，每次任务都是首通。对话结束即归零，同一个任务每次从零开始，上次踩过的坑这次照样踩。换更强模型，仍然可能是新手。

长期记忆应该沉淀在 Harness 中，至少包括三类：

记忆类型	作用
项目记忆	用 CLAUDE.md 等文件保存项目约定、常用命令和工程规则
教训记忆	记录踩过的坑，后续自动规避同类错误
路径记忆	把跑通的流程沉淀下来，供同类任务复用

第 N 次任务 = 前 N−1 次的总和
速通的秘密不是手速，是积累的记忆 + 社区共享
模型无记忆，记忆只能长在 Harness

当前的限制是记忆仍然容易成为孤岛。各团队、各 Harness 各攒各的，一人踩过的坑，别的团队还会再踩一遍。下一步需要解决的是 Agent 之间如何共享记忆。

工具层是 Harness 引导的主战场

角色能力可以类比 Agent 工具。工具不是越多越好，关键是每个都好用。《Metroid Dread》有 18 项能力，但物理按键只有 7 类，复杂能力被压缩到少量可靠操作上。

Agent 工具层也应贵精不贵多。工具设计要满足三个标准：

维度	标准	要求
易用性	一眼就会用	参数少且自解释，命名直白，描述写清何时用、怎么用，输出和错误信息能直接指导下一步
可用性	随时都能用	依赖、权限、凭据提前就绪，超时与重试策略内建，失败有降级路径，用不了就从工具列表移除
鲁棒性	怎么用都不坏	宽容输入，幂等设计，重复调用不出事，副作用可回滚，失败不致命

三项标准缺一不可：工具名称清楚但调用时不可用，或能调用却无法回滚副作用，都会让 Agent 的下一步决策变差。

设计工具，就是设计 Agent 的决策空间。工具层优化的方向是：数量做减法，质量做加法。

这也要求改变归因方式。效果不好时，第一反应不应该总是"模型不行"。这类似游戏设计不好却怪玩家。好的 Harness 可以降低模型的不确定性：怕迷路，就设计地图分区和重点图标；怕卡关，就给新能力首用教学；怕劝退，就降低死亡成本；怕错过，就提前埋目标终态；太复杂，就用锁区控制开放节奏。

设计不好就赖玩家，效果不好就赖模型，本质上是同一种偷懒。生产级 Agent 要先看 Harness 是否兜住了模型。

可观测性：看得见每一步，才知道调哪里

Agent 系统需要端到端可观测性。重点不是只看最终结果，而是看完整过程：每一次决策依据、每一次工具调用、每一次错误和恢复，都要能被追踪。

可观测性至少有三个方向：

方向	说明
E2E 全流程透明	每次决策依据、工具调用对错、错误恢复过程都可见
海量轨迹分析	从历史轨迹里挖问题，发现集成测试覆盖不到的缺陷
开放 OpenAPI	让 Agent 可调用观测平台，自动做分析

一次轨迹记录应能关联会话、轮次、工具调用、输入输出 Token、耗时、错误和最终结果。观察单次调用时，还需要知道它发生在什么上下文、修改了什么，以及失败后是否恢复；聚合多次任务时，才能把慢、错和高成本的模式找出来。

轨迹内容还应按系统、用户、助手、工具、压缩等角色分段展示，每次调用的耗时、Token、成功或错误状态都应可见。只有这样，问题定位才不再只靠猜。

评测：既要看结果，也要看过程

CodeAgent 很适合确定性评分器（deterministic-grader），因为代码是否能编译、测试用例是否通过，通常可以直接判断。这类评分本质上是在对最终结果 Outcome 打分。

但只看 Outcome 不够。它无法判断代码生成质量、代码仓理解是否正确、工具调用是否合理、Token 消耗是否必要。因此还需要非确定性评分器，对执行过程 Trajectory 打分。

典型评分器包括：

评分器	评分对象	作用
deterministic_tests	Outcome	判断最终环境状态是否正确
llm_rubric	Trajectory	判断推理路径和过程质量
state_check	状态变化	判断关键状态是否符合预期
tool_calls	工具调用	判断工具选择、顺序和参数是否合理
static_analysis	代码质量	判断静态质量和潜在风险

一个评测任务可以抽象为：

概念	含义
Task	inputs + success criteria + graders + metrics
Trial	一次执行，即 one execution
Trajectory	完整执行记录，即 full record
Graders	对性能的不同方面打分

评测体系把任务、运行记录、结果和评分器连起来：同一任务多次执行产生多个 Trial，每次都有完整 Trajectory 与 Outcome，评分器据此检查不同方面。

结果分与过程分可以概括为：

deterministic(outcome) + non-deterministic(trajectory)

Agent 是概率性系统，单次测试不可信。一个 Task 需要多次运行来计算 pass@1：

pass@1 = 成功次数 / N

如果一个任务只测一次且失败，无法区分偶发失败和高频失败。10 次采样中只失败 1 次，pass@1 = 0.9；10 次采样中失败 9 次，pass@1 = 0.1。两者的失败频率和排查优先级不同，具体是否可接受还要看任务风险。

还要区分 pass@k 和 pass^k：

指标	定义	k 增大时趋势	3 次试验示例
pass@k	k 次里至少一次成功	趋近 100%	pass@3 = 97%
pass^k	k 次全部成功	趋近 0%	pass^3 = 39%

图中的 97% 与 39% 是说明指标差异的示例值，并非这套 Agent 的实测通过率。在单次成功率介于 0 和 1、各次试验相互独立的假设下，尝试次数增加会提高"至少成功一次"的概率，却降低"每次都成功"的概率。演讲建议重要用例每个跑 10 次、一般用例每个跑 5 次，以免把单次运气当成质量。

从 SDD 到 TDD：终态优于路径

规格驱动开发（SDD）和测试驱动开发（TDD）在 Agent 时代承担不同角色。

SDD 的核心是意图契约：在概率生成与工程确定性之间，插入可版本化、可验证的 spec，让系统从"猜你想要"转向"照着实现"。它的优点是意图传递更确定，可版本化、可验证；局限是没有消灭不确定性，只是把不确定性挪到了自然语言 spec，而且 spec 往往只能向下传播，代码改了以后很难同步回 spec，也很少有人认真看 Agent 自动生成的 spec。

TDD 的核心是测试先行，用测试定义"做没做成"，流程是红、绿、重构。它适合 Vibe Coding 时代，因为失败很便宜，重跑测试即可。过去 TDD 推行困难，一个原因是人不喜欢补测试；但模型不会拒绝。存量项目可以先写测试，让测试一开始跑不过，然后把实现路径交给 Agent。

维度	SDD：规格驱动	TDD：测试驱动
核心定位	意图契约	测试先行
目标	从"猜你想要"到"照着实现"	把终态写死
定义方式	用 spec 承接意图	用测试描述是否完成
典型流程	先写规格，再让实现对齐规格	红 → 绿 → 重构
局限	契约锁得住意图，锁不住不确定性	好测试难写，盲区会带来虚假安全感

更可取的工作方式是：Spec 当地图，Test 当存档，路径交给 Agent。模型越强，越不需要人锁路径；测试越清晰，越能定义可验收终态。

**验收循环：**定义终态 → 路径交给 Agent → 运行与反馈 → 测试；未通过则继续修正，通过后交付。

"绿了，才算交付"强调终态要能验证；实际验收还要确认测试覆盖了需求、验证配置没有被 Agent 绕过。

结语：Vibe 起步，工程到达

生产级 Agent 的一年实践可以收束为四句话：规模不等于效果，卡点在工程，把 Agent 当玩家，终态优于路径。

规模增长只是起点。用户、请求、生成量一路上涨，但采纳才是最后一环。真正要调的是 Harness，而不是只盯模型。引导、反馈、记忆、组合、观测、数据闭环这六关，换再强的模型也绕不开。

更好的方式是给 Agent 地图，而不是锁死路线；用测试定义终态，而不是固定执行路径；用 Harness 保存记忆、降低试错成本、控制边界、提供可观测性和评测闭环。

最后一公里不是一次性跨过去的，而是一条条调出来的。Vibe 可以让研发起步更快，但生产级交付必须靠工程系统到达。

---

资料来源：张琦在 QECon 上海站分享的《Vibe Coding 最后一公里：华为生产级 Agent 效果调优实录》（脱敏版演讲材料）。本文为学习整理与解读，演讲中的内部数据、榜单和案例按原材料转述，未作独立核验。