ksxz
AI编程助手Coding Agent百度ComateFeedback LoopBenchmark工程实践

Coding Agent 在百度的落地实践：从反馈闭环到工程范式重构

牛万鹏··原文链接
收录于 2026/5/27 09:38:46

一、背景与挑战

在 AI 编程助手赛道持续升温的当下,模型层的能力迭代几乎以周为单位。从 Claude Opus 到 GLM、Kimi、MiniMax 再到 GPT 系列,新模型密集发布已成为常态。然而对于构建上层 Agent 应用的团队而言,模型能力的剧烈变化恰恰构成了最大的架构挑战。

Comate 作为上层应用团队并不训练模型,但如果应用层不能有效适配模型的快速变化,同样会"感冒"。因此,如何有效适配模型变化,如何让 Agent 框架和产品在模型能力跃迁时保持弹性,成为核心命题。

二、Coding Agent 在百度的落地效果

2.1 用户使用数据

以百度全员中适合使用 Agent 的非开发者和开发者的每周 Query 次数作为衡量指标,数据显示 Query 数量的增长曲线在某个时间点出现了极为陡峭的爬升。截至三月底,百度员工在使用 Agent 时,每周人均 Query 次数已达到九十多次,意味着一周之内发出了将近一百次任务请求。

选择人均 Query 数而非 Token 消耗量作为衡量指标的原因在于:Query 本身能更准确地映射出 Agent 实际完成的任务数量,而 Token 数量则很难直接反映完成了多少任务以及提效的具体幅度。

2.2 用户群体变化

Comate 拥有自己的 IDE(类似 Cursor 体验),也提供 JetBrains 插件和 VS Code 插件。越来越多的用户选择直接使用 Comate IDE,放弃 JetBrains 和 VS Code。他们不仅仅在里面写代码,编译和调试等工作也一并迁移了过来。

同时,使用者的角色边界也在被打破。产品经理尚属研发圈子,但令人始料未及的是,售前工程师和销售人员竟然也开始使用 Agent,用来分析数据、做项目管理,这一现象完全超出了最初的预期。

2.3 两类应用场景

这些用户在用 Agent 做什么?本质上都可以归入 Vibe Coding 的范畴,但具体可以划分为两个截然不同的类型:

第一类场景:非开发者解决那些"大量可以用研发能力解决,但永远不会被纳入研发排期"的工作。典型例子是产品经理的数据统计诉求。过去需要找研发同事写 SQL 查询数据,现在产品经理拿着 Agent 连接数据库,配一个只读账号即可自行完成查询。这类需求优先级不高,但始终存在,产品经理通过 Agent 立刻就能满足。

第二类场景:真正的严肃开发,即日常的软件迭代。三个月前认为 Vibe Coding 在这类场景上不靠谱,但现在情况已经完全不同。包括 Comate 研发团队自身,也在大量使用 Agent 来生成 Agent。一个根本性的变化在于,开发者个人从执行者变成了问题的提出者。约束效率的瓶颈已不再是 Token 价格是否昂贵,而在于一个人能不能提出一个好问题。

2.4 Query 类别分析

进一步细化 Query 的类别,整体可以归入几个大类,其中有三类体量最大:

  • Code Exploration(代码探索):占比接近 20%,包括代码检索和代码解释
  • Debug(排错):每天把日志提供给 Agent,请它帮助定位问题
  • 实现新 Feature:占比相对较低

这一分布完全符合工程师的直觉:每天真正在做的事情并不是实现新功能,而是研究和排查问题。

三、Agent Loop 的基本框架和问题

基于线上数据,Comate 正在搭建的 Agent 框架采用了两层 Loop 的设计:

  • 中间层 Loop:由工具、环境和模型三者构成最基本的 Agent 闭环框架
  • 外围第二层 Loop:赋予 Agent 更多手脚去探索外部环境,包含记忆(Memory)、技能(Skill)、规则(Rules)、MCP 以及 Agents 本身

Claude Code 源码泄露时,发现里面有大量的边界条件处理,充斥着各式各样的 if-else 逻辑。由此重新看待 Harness 这个概念——帮助 Agent 完成各种脏活累活、将各种边界条件限定好的那一层工程设施。

3.1 框架面临的问题

当新模型大量推出的时候,这个框架着实"感冒"了:

问题一:模型能力的变化 以 DeepSeek 刚推出时为例,它对 Function Calling 支持得不好,但对 XML 是 OK 的。因此那时 Agent 框架走了 XML 路线。但到了去年下半年,各个模型对 Function Calling 的支持已经非常成熟,原来的框架就跟不上了。这揭示了一个根本性问题:随着模型解题能力越来越强,我们必须动态调整框架,根本不存在一个可以完全确定的静态框架。

问题二:Spec Driven 的淡化 前几个月关于 Spec Driven 的讨论相当激烈,但如今已经没有多少人再去过多考虑这个问题了,因为模型解析能力实在太强了,Spec 所驱动的那些细节已经不需要人再去关注。

要有效观测这类变化,必须构建有效的评测集。分数本身并不重要,重要的是那些异常值。同样的一个分数,上一次跑评测时做对的题可能是那六十道,下一次跑的时候分数一模一样,但做对的那部分题很可能是另外六十道——对的题换了一组,分数保持不变。因此只关注分数毫无意义,必须去发现那些异常情况。

四、Feedback Loop:让 Agent 的行为可观测

Comate 构建了 Feedback Loop,让 Agent 的行为和观测结果形成反馈闭环。Agent 被推送到线上供用户使用后,会产生大量的线上数据。在确保安全、不泄露用户隐私的前提下,关键在于怎么关注这些数据,让 Loop 更好地运转。

Comate 统计四类数据,从最上层最直观的到最下层最复杂的递次展开:

4.1 第一层:工具层

统计工具的调用次数、失败率、失败后的自愈比例,以及 Query 与 Tool Call 的比例。这个指标至关重要,它衡量的是一个 Agent 在最终解决问题的时候,需要通过多少轮次才能把事情完成。观察所有这些数据时,都必须按照模型来做区分,以 Claude 为标杆,同时跑 Kimi、GLM、文心等模型,进行对比分析。

4.2 第二层:上下文层

关注 Skill 的唤起、Memory 的唤起等。发现 MCP 和 Skill 在 Token 消耗上的对比极为强烈:

  • Skill:渐进式发现思路,无论从效果还是 Token 消耗角度都是更优选择
  • MCP:非渐进式例子,假设有三个 MCP Server,每个各有十个工具,以 Function Calling 方式把全部工具传进去,结果一下子就把上下文给冲爆了

优化方案:让 Comate 自动为每一个 MCP 生成一个类似于 Skill 的描述,在 Agent 内置一个 Skill 工具,把 MCP 的内容渐进式加载进去。这一优化最高可以帮助节省 98% 的 Token 消耗。

4.3 第三层:执行结果

当 Agent 创建任务并创建了文件之后,创建完又反复调用好几次工具去不断修改这个文件——这一行为就能反馈出一个问题:说明 Agent 第一次创建文件时根本没有分析好,在前面做问题澄清的阶段就没想清楚,导致后续需要大量的修补操作。

4.4 第四层:执行轨迹评估

如何有效衡量一个 Query 从发出直到 Agent 最终将整个任务执行完毕,其执行轨迹是否优良。目前只是抽象出了几个类别,仍在建设之中。

4.5 任务复杂度分析

按照用户 Query 的类别,再在各类别内部区分任务复杂度。区分复杂度的目的,在于判断哪些任务适合让什么样的模型来执行。当一个人以全栈的模式去完成一个复杂任务的时候,需要调度多个 Agent。主 Agent 调用 Sub-agent,Sub-agent 之间互相通信,而 Agent 背后仍然靠模型在驱动。希望有效识别 Query 和任务,让最合适的模型来承担相应的任务。假如任务复杂度极高,毫不犹豫上 Claude;如果任务相对简单,就用其他表现稍弱但成本更低的模型。这便是依靠复杂度分析来做模型路由的核心思路。

4.6 GPT 模型的适配实践

近期 Codex 的声量在急剧攀升,其表现确实出色。Comate 同样支持 GPT 模型。对 GPT 做过很多适配:

用暴力的方式去做压测,观察整个工具的调用情况。其中有一个红色线的工具是 Bash,即命令行工具。起初使用 GPT 模型时,提供了写代码的工具——Write、Read、Glob、Grep、Edit 编辑等工具,还有命令执行工具。但发现,越到后面的轮次,命令行工具的使用率就直线攀升——它不再使用定义好的工具去做代码编辑和文件写入了,转而使用命令行,用 Sed 命令,用 Cat 命令。

放在以前,这种情况会让人相当苦恼,可能会在后面的轮次里明确告诉它:不行,你必须使用 Edit 工具,要压制模型的行为。但现在获得了全新的启发:通过这套监控机制,发现再去构建 Agent 工具,尤其是 Coding Agent 这类的工具时,更应该通过数据去观察模型真正喜欢什么。数据显示 GPT 的模型,特别是 5.3-Codex、5.4 这几个版本,特别喜欢用命令行。这证明了 Codex 的 CLI 只有一个工具,就是命令行工具。GPT 在构建 Agent 工具的时候,就是倾向于使用命令,而不是使用定义的结构化编辑工具。

所以当模型出现某些不遵从指令的行为时,可以先不要尝试去压制它、非要它遵从指令,而是去看它的异常。异常发生在这里,说明它可能喜欢这个东西,那就再调一调,说不定能产生更好的效果。

五、Benchmark:挖掘评测集和发现异常值

核心在于如何挖掘评测集以及发现异常值。出发点并不是看分数,而是看那些被分数掩盖的异常情况。

(注:文章后续还有 Benchmark 部分和 Agent Engineers 部分的详细内容,此处因篇幅限制未能完整呈现)

六、核心要点总结

  1. 动态框架思维:不存在静态的 Agent 框架,必须随着模型能力演进动态调整
  2. 数据驱动优化:通过四层数据监控,发现问题并持续优化
  3. 渐进式发现:Skill 的渐进式发现思路可节省高达 98% 的 Token 消耗
  4. 异常值导向:评测不应只关注分数,更要发现被分数掩盖的异常情况
  5. 模型适配:不同模型有不同的偏好,应通过数据观察而非强制压制
  6. 全栈能力:开发者从执行者变为问题提出者,需要角色维度的全栈能力

七、实践启示

  • 不要急于修补:当模型输出出现问题时,不要急于修复,而是等待模型本身完成升级
  • 观察模型偏好:通过数据去观察模型真正喜欢什么,而不是强制改变模型行为
  • 构建反馈闭环:让 Agent 的行为和观测结果形成闭环,持续迭代优化
  • 关注异常值:异常值往往隐藏着重要的优化机会和模型偏好信息

本文根据 InfoQ 整理的演讲实录编写,内容经过编辑整理,保留了原意。

返回首页