小度为什么越来越懂你？一套 Agent 研发闭环的诞生

百度Geek说 2026-08-18 12 阅读1分钟

导读

每天，成千上万句的“小度小度”涌向 AI 助手。小度 AI 智能助手产研团队以信息类 Bot（Aries）为试点，打通了从 bad case 发现、问题定位到上线解决的完整闭环，并将这套方法推广至音乐、短视频和长视频业务，推动研发从被动接需求转向主动发现问题、端到端解决问题。

实践效果明显：在不增加人力的情况下，Aries 每周解决需求数从 2 个提升至 12.5 个，增长约 6 倍；端到端满足度从 76.1% 提升至 81.5%。截至今年7月，团队已累计发现 160 个需求并上线解决 121 个，短视频 UP 主召回专项满足度也从 47% 提升至 67%。

01 方案阐述

1.1 项目背景简介

这个项目要解决的不是某一个 Bot 的问题，而是一个更底层的问题：

AI 已经能写代码了，为什么研发效率没有真正翻倍？

现在很多团队都在用 AI Coding，但大多数时候，AI 只是让“写代码”这个动作快了一点。真正的研发链路仍然靠人一步步串起来：发现问题、分析原因、建卡、出方案、改代码、编译、部署、看日志、验证、提交、回归、上线。

只要这条链路还靠人手工串行推进，一个 RD 一次就只能深度盯住一个问题。单步效率即使提升 30% 到 50%，整体组织效率仍然很难产生量级变化。

所以这个项目的出发点是：

真正的瓶颈不是 AI 会不会写代码，而是研发链路仍然围绕“人手工串行执行”组织。

我们沉淀出的核心思想是：

把研发链路里可标准化、可重复、可验证的动作交给 Agent 和代码，把人留在判断密度最高、风险最高、最不可逆的节点。

这套思想可以概括成一句话：

不确定的交给 Agent，确定的交给代码，不可逆的交给人。

这不是做一个单点工具，而是把研发链路重新设计成一个自动化系统。原始提报材料中也明确提出：研发效果不是模型给的，而是设计出来的；上限不只取决于模型能力，更取决于怎样为 Agent 设计环境、约束和验证机制。

这套思想的精华可以再压缩成五句话：

输入可采集：问题从真实流量、日志、热词、评估样本中来。判断可拆解：再主观的问题，也要拆成可判断的类型。过程可自动：重复执行动作交给 Agent、Skill、脚本和平台接口。结果可验证：每一步都有沙盒、回放、diff、抽检或监控集兜底。经验可沉淀：解决过的问题进入 Skill、案例库和监控集，后续持续复用。

所以，这套方法不限制业务场景。只要一个业务能定义输入、问题标准、归因类型和验证卡点，就可以接入这套自动化范式。

Aries 是第一条完整跑通的样板线；音乐、长视频、短视频进一步证明：这套思想不只是信息类 Bot 能用，内容类、主观类、热点类、资源类 Bot 同样可以用。

1.2 团队的模式变化

这套范式带来的变化，不是“用了 AI 工具”，而是团队研发模式发生了变化：

从人手工串行执行，变成机器自动执行、人关键判断。

过去，RD 是亲自下场执行每一步。 现在，RD 变成自动化系统的设计者、Agent 编队的调度者、结果质量的把关者。

具体变化体现在四个方面。

1.2.1 研发分工变了：从“人做所有事”到“人、Agent、代码各司其职”

过去的研发链路是：

人发现问题→ 人分析问题→ 人建卡→ 人出方案→ 人改代码→ 人编译部署→ 人看日志→ 人验证→ 人提交上线

现在变成：

机器发现问题→ Agent 分析归因→ Agent / Skill 生成方案→ 脚本执行确定动作→ 自动验证结果→ 人在关键节点判断→ 结果沉淀进系统

人的位置不是被替代，而是被前移和上移：

• 不再盯每一步执行细节；
• 只在“做不做、方案对不对、能不能上线”这些关键点判断；
• 把更多精力放在机制设计、质量把关和多任务调度上。

这意味着 RD 的价值从“我亲手做了多少需求”，变成“我能同时治理多少条自动化流水线，并保证质量不失控”。

1.2.2 研发链路变了：从单点提效，变成端到端闭环

这套自动化思想不是只优化某一步，而是把完整链路串起来：

真实数据输入  ↓自动发现问题  ↓Agent 归因分类  ↓自动建卡 / 生成方案  ↓Agent 或脚本执行修改  ↓自动验证 / 人工放行  ↓结果沉淀  ↓进入下一轮监控

这条链路最大的价值是：它不是一次性解决问题，而是形成持续飞轮。

发现问题→ 解决问题→ 回归验证→ 沉淀监控→ 继续发现下一批问题

这就是模式变化的本质：

不是让一个人把一件事做得更快，而是让一个人可以同时调度多件事。

1.2.3 业务接入方式变了：不同 Bot 复用同一套自动化思想

这套方法不是 Aries 专属，也不是信息类 Bot 专属。

我们把业务接入抽象成一个通用模板：

不同 Bot 的业务特性不同，但底层都是这五件事。

总体范式：不确定交给 Agent，确定交给代码，不可逆交给人。（如下图）

1. Aries：信息类 Bot，先跑通完整研发闭环

Aries 是第一条样板线。

它的特点是问题相对客观：用户问了什么，系统有没有答到点上，可以通过线上 query、沙盒回放、LLM 评估器、diff 回归来判断。

以线上真实 query「5 月 10 号是什么节日」为例，系统先从热词榜里自动拉取 query，在沙盒中重跑真实回答，发现系统回答成“一年中的第几天”，没有回答用户真正关心的节日问题。随后 LLM 评估器判断这个 case 不满足，把它记入 fail 文件；同类的“后天是什么节日”“星期五是什么节”等问题被自动聚类，形成一组需求，并自动创建 iCafe 卡片。

后续链路继续自动推进：Agent 领卡、建分支、分析代码、生成方案；AI 先做方案审查，人再判断方案边界；方案通过后，Agent 修改 C++ 代码，自动编译部署，跑目标 case、监控集和随机 case；最后由人做真机确认，确认无误后上线，并把修复后的 case 沉淀进监控集。

Aries 的完整链路可以概括为：

线上 query 自动发现→ 沙盒回放真实回答→ LLM 评估是否满足→ 同类问题自动聚类→ 自动建 iCafe 卡→ Agent 领卡、建分支、分析代码→ AI 先审方案，人再审边界→ Agent 改码、编译、部署→ 目标 case / 监控集 / 随机 case 回归→ 人工真机确认→ 结果并入监控集

这条线证明了第一件事：信息类 Bot 的问题发现、归因、修复、验证、上线，可以被串成一个端到端自动化闭环。人不再盯完整流程，只在三个判断点介入：这事做不做、方案对不对、能不能上线。

2. 音乐：把“想听什么、实际播了什么、为什么不满足”结构化

音乐和 Aries 最大的不同是：它不是简单判断“有没有回答”，而是要判断“有没有播到用户真正想听的内容”。

用户说一句“播放某首歌”，背后可能有很多原因导致不满足：可能不是音乐需求，可能歌曲无版权，可能歌名对但歌手不对，可能播放了非主流版本，也可能 NLU 槽位解析错。音乐材料里把问题拆成七类：需求不明、歌曲无版权、歌曲错误、非最优版本、满足、版本待确认、意图槽位错误。

音乐的自动化链路分成两条并行分支。

第一条分支判断用户真实想听什么：系统读取线上用户 query 样本，对“播放”“我想听”等引导词做预处理，提取核心关键词，再调用 TME 知识图谱检索，拿到候选歌曲、歌手、版权等信息。

第二条分支复现Bot 实际播放了什么：通过 dumi v3 仿真环境调用 audio_music 服务，回放用户 query，提取 TTS 播报文本、实际播放歌名、歌手、song_id，同时解析 NLU 的 domain、intent、slots，并保留 log_id、cuid、请求时间戳等链路字段。

两条分支合并后，系统把 TME 知识图谱结果和真实流量回放结果输入大模型；子 Agent 再结合 WebSearch，对百度、网易云、维基等结果做交叉验证，最终输出七类问题之一，并给出 reason 和 source。对于 c/d 类问题，也就是“歌曲错误”和“非最优版本”，系统会继续结合日志下钻排查。最后生成报告，由人工根据页面详情做处理决策，可以选择负责人并自动创建卡片；如果判断是业务代码问题，建卡时会同步推送给对应问题解决者机器。

音乐的链路可以概括为：

线上 query 输入→ 提取核心音乐关键词→ TME 知识图谱检索，判断歌曲、歌手、版权→ dumi v3 流量回放，确认 Bot 实际播了什么→ 解析 TTS / 歌名 / 歌手 / song_id / NLU / slots / log_id→ 合并 TME 结果和实播结果→ Agent + WebSearch 交叉验证→ 归类为七类问题之一→ 生成问题报告→ 人工确认处理决策→ 自动建卡，进入解决流程

音乐的解决链路也不是停在报告层。问题卡片创建后，Skill 会检索同类历史问题，生成技术方案；代码审核 Skill 做自动初审；人工确认方案后进入编码；编码后再做二次自动化代码校验和批量 case 验证，全部通过后再提交入库。

音乐目前累计发现问题 14 个，解决 5 个。它证明的是：即使是版权、歌手、版本、真实听歌意图这种主观且动态变化的内容问题，也可以先被拆成结构化分类，再进入自动化发现和解决闭环。

3. 长视频：把热点 Query、短切 Query 和跨 Bot 路由自动审计起来

长视频和 Aries 的差异更明显。Aries 主要看“答没答对”，长视频要判断的是：这个 query 到底是不是影视需求、有没有被错误分发到音乐或短视频、资源是否存在、NLU 是否解析正确、ASR / DA 改写是否影响路由、召回和排序是否正确。

所以长视频的第一步不是改代码，而是先把热点 Query 和短切 Query 做自动审计。

长视频链路分三段，最适合直接使用「vod-agent 驱动开发」第 3 页的泳道图。

第一段是问题发现：开发者提供 query 列表，可以是 CSV，也可以手动输入；/video-query-audit 调用沙盒执行 queryUi.py --sandbox，拿到每条 query 的 bot_id、NLU、response；系统对比预期，识别异常 query，包括错误路由、NLU 解析错误、资源缺失等，然后输出审计报告，必要时一键创建 iCafe 卡片。

第二段是开发环境定位：对于已经创建的卡片，/vod-dev-cycle 拉取 iCafe 卡片详情，解析修改点；人工只确认修改点是否正确；确认后再进入 C++ 代码修改、推送代码、编译和重启。

第三段是验证与归因：系统用 queryUi.py --dev --query "<query>" 在开发环境重新验证，拿到 bot_id、NLU、response，再拉取 video-on-demand.log，分析 slots、directive_type、slot_search_type、err_code 等字段，最后把排查结论自动评论到卡片，并修改状态。

长视频链路可以概括为：

热点 query / 短切 query 输入→ /video-query-audit 沙盒回放→ 返回 bot_id / NLU / response→ 对比预期，识别异常 query→ 输出审计报告→ 一键创建 iCafe 卡片→ /vod-dev-cycle 拉取卡片详情→ 解析修改点→ 人工确认修改边界→ 修改 C++ 代码，编译重启→ 开发环境 query 回放→ 拉取 VOD 日志→ 分析 slots / directive_type / slot_search_type / err_code→ 评论归因结果，推进卡片闭环

长视频已经有阶段性结果：回溯 0429-0511 影视新热词天级飙升榜，共 243 个 query，其中 33 个 query 切换到其他 Bot，包括 audio_music、us.check 等；通过“播放 xxx”“影视剧 xxx”等切换 query 辅助人工判断，一共创建 6 个卡片。

后续监控里，2026-05-19 热点 Query 影视 Tab 共 104 条，VOD 命中率 93⁄104 = 89.4%；2026-05-20 短切 Query 审计共 133 条，VOD 命中率 121⁄133 = 91.0%；5.19-5.28 期间累计发现 case 10 个，已解决 8 个。

长视频证明的是：热点、资源、跨 Bot 路由、召回排序这种复杂链路问题，也可以从“靠人经验发现”，变成“系统定期审计、自动建卡、日志归因、持续闭环”。

4. 短视频：把主观内容评估拆成 Skill，形成质量飞轮

短视频是四类 Bot 里最主观的一类。

它的问题不是“有没有返回结果”这么简单，而是返回的视频和用户搜索意图是否相关、标题和内容是否匹配、结果是否真正满足用户需求。难点在于用户表达很不规范，有大量口语化、方言化表达，例如“咋整”“整活儿”；网络新词变化快，例如 “yyds”“绝绝子”“i 人 e 人”；视频标题还经常包含 emoji、特殊符号和夸张修辞，导致标题和实际内容相关性很难人工稳定判断。

过去短视频主要靠人工 review，问题是成本高、效率低、标准不统一、覆盖量小。现在的做法不是让 AI 直接拍脑袋判断，而是把评估过程拆成几个 Skill：相关性评估 Skill、意图匹配 Skill、满足度汇聚 Skill，再配合离线脚本、日志解析、报告生成和人工抽检，形成一条可持续评估的流水线。

短视频链路可以概括为：

离线脚本批量采集短视频评估日志→ 日志解析，提取 query、标题、播放、召回等关键字段→ 数据清洗，过滤无效样本，补全缺失字段→ 相关性评估 Skill 判断内容是否相关→ 意图匹配 Skill 判断结果是否符合用户意图→ 满足度汇聚 Skill 形成综合评分→ 自动生成评估报告→ 标记问题视频，推送优化建议→ 业务方修改→ 评估效果确认→ Skill 参数调优→ 进入下一轮持续迭代

短视频证明的是：即使是最主观的内容满足度评估，也可以通过 Skill 拆解、自动化采集、自动报告和人工抽检校准，变成工程化质量体系。

5.四条线共同说明什么

这四个 Bot 的业务形态不一样，但底层动作是一样的：

Aries 证明它能跑通完整研发闭环。 音乐证明主观内容匹配可以结构化。 长视频证明热点、资源和跨 Bot 路由可以自动审计。 短视频证明主观满足度可以 Skill 化评估。

这四类都能跑，才说明这套思想不是理论，也不限制场景。

6. 团队协作模式变了：从带碳基人，到带硅基人

这套范式最后改变的是团队组织方式。

过去，团队扩产能主要靠加人：

更多 RD→ 更多需求并行→ 更多测试和管理成本

现在，产能扩张开始变成：

人 + Agent + Skill + 脚本 + 监控集→ 多条自动化流水线并行→ 人在关键点把关

也就是说，管理对象变了。

过去负责人主要带“碳基人”：RD、测试、产品、运营。 现在负责人还要带“硅基人”：Agent、Skill、脚本、自动化流水线、监控集。

这里的“硅基人”不是口号，而是新的生产力单元：

• 一个 Agent 可以领卡；
• 一个 Agent 可以分析方案；
• 一个 Agent 可以改代码；
• 一个 Skill 可以持续发现问题；
• 一个脚本可以持续跑验证；
• 一个监控集可以持续防止退化。

所以 RD 的身份也发生了变化：

从写代码的人，变成自动化系统的运营者；从单线程执行者，变成多线程 Agent 编队的调度者。

这才是这套范式最核心的团队模式变化。

1.3 团队取得的成效

1. 单条线吞吐提升：Aries 跑通 6 倍效率样板

Aries 是第一条完整接入的业务线，也是这套范式的样板线。

接入后，同等人力下，每周解决需求从 2 个提升到 12.5 个，达到 6 倍吞吐；端到端满足度提升 5.4 个百分点。该指标是在语音识别正确的前提下，由小度人工评估团队在智能屏上独立实测。

更重要的是，它不是一次性专项优化，而是形成了持续飞轮：每天自动跑日飙升榜、快切榜、线上随机 query，不满足的 case 自动进入研发范式被消化。

这说明：

提效不是因为某个步骤快了 6 倍，而是因为工作结构变了：从一个 RD 一次盯一个问题，变成一个 RD 同时调度多条自动化流水线。

2. 范式复制效果：已扩展到多条业务线

这套范式已经从 Aries 扩展到音乐、短视频、长视频等业务线，形成跨 Bot 的自动化能力。

截至 2026 年 7 月 24 日，跨业务线累计发现 160 个需求、上线解决 121 个。最新访谈确认的代表性结果包括：Aries 同等人力下每周解决需求从 2 个提升到 12.5 个；短视频 UP 主召回专项满足度相对提升约 43%；音乐业务也已沿同一套闭环落地。

这里不再沿用早期按业务线拆分的阶段性统计，避免不同时间点的口径混用。

这张表最重要的不是数字本身，而是证明了：

这套自动化思想不限制场景。

Aries 是信息类 Bot，判断相对客观。 音乐涉及版权、版本、歌手、真实听歌意图。 长视频涉及热点、资源、路由、召回、排序。 短视频涉及主观内容相关性和满足度评估。

这些场景差异很大，但都能接入同一套范式，说明我们复制的不是一个 Skill，而是一套底层方法。

3. 内容类业务收益：主观问题也能工程化

音乐、长视频、短视频的意义在于：它们不是标准的信息问答，而是更复杂的内容类业务。

这类业务过去普遍认为更难自动化，因为它们有很多主观判断：

• 音乐要判断版本、歌手、版权和真实听歌意图；
• 长视频要判断影视热点、资源、路由和召回；
• 短视频要判断内容相关性、意图匹配和满足度。

但这套范式把主观问题拆成了工程问题：

主观判断→ 拆成明确分类→ 设计 Skill→ 自动化采集和评估→ 人工抽检校准→ 形成持续迭代

短视频自动化评估后，评估覆盖从每月 50～100 条提升到 10000+ 条，约提升 50 倍；UP 主召回专项满足度相对提升约 43%。

这说明：

自动化不等于消灭主观判断，而是把主观判断前面的重复劳动系统化，把最终判断权留给人。

4. 组织收益：个人经验变成团队资产

过去很多能力存在熟手脑子里：怎么发现问题、怎么判断归因、怎么建卡、怎么查日志、怎么跑验证、怎么决定是否放行。

这套范式把这些经验沉淀成了 Skill、自动化脚本、评估报告、监控集、问题案例库和端到端研发流水线。

这意味着：

能力不再只属于某个熟手，而是沉淀进系统里，后续业务可以复用。

1.4 补充说明

1.4.1 行业先进性

这套范式对标的是软件工程里的“黑灯工厂”和 Prompt to Harness 思路，但它往前推进了一步：

不是只把 AI 用在写代码，而是把 AI 放进完整研发链路。

它的先进性不在于用了某个最强模型，而在于形成了一套可落地的人机分工方法：

Agent 负责探索；代码负责确定性执行；人负责不可逆判断；验证机制负责质量兜底。

同一个模型，如果没有边界、约束和验证，只会变成不可控黑盒；如果有清晰的人机边界、平台接口、回归机制和人工判断点，就能成为研发执行引擎。

更重要的是，它已经从 Aries 复制到音乐、长视频、短视频。内容类业务比信息类业务更主观、更依赖热点、更难自动化，但仍然可以跑通，这说明能力护城河不是某一个 Bot 的经验，而是这套方法本身。

1.4.2 团队经验沉淀

这套范式已经沉淀出三类组织资产。

1. 标准 Skill 库

把原来分散在个人手里的动作封装成 Skill：

• 问题发现；
• 自动建卡；
• 方案生成；
• 方案审查；
• 代码修改；
• 编译部署；
• diff 回归；
• CR 报告；
• 结果归档；
• 监控集沉淀。

这些 Skill 可以被不同业务线复用。

2. 业务接入模板

新业务线接入时，不需要从零设计，只需要回答五个问题：

这让新业务线可以复用同一套范式骨架，只替换自己的业务判断逻辑。

3. 人机协作机制

这套范式沉淀了一套清晰的人机协作方式：

机器先跑；Agent 先判断；脚本先验证；人最后拍板。

人不再盯流程，而是在流程需要判断时被系统主动召回。

这才是真正的 AI Native 研发：不是把 AI 当工具，而是把 AI 作为研发组织的一部分来设计。

1.4.3 后续规划

1. 继续扩大业务场景

当前已覆盖：

• 信息类 Bot：Aries；
• 音乐类 Bot：版权、版本、歌手、真实需求判断；
• 长视频 Bot：热点、资源、路由、召回；
• 短视频 Bot：主观满足度评估。

后续可以继续扩展到更多垂类 Bot、端到端联调业务、全栈开发场景，验证这套自动化思想在更大范围内的适用边界。

2. 沉淀通用接入平台

下一步不是继续堆单点工具，而是把当前经验平台化：

新业务接入→ 配置输入源→ 配置问题分类→ 配置验证卡点→ 自动生成评估 / 建卡 / 处理链路→ 接入组织级看板

目标是让更多业务线可以低成本接入，而不是依赖少数人手工搭链路。

3. 推进免测能力复制

Aries 单线已经验证了从问题发现到自动验证、自动回归的闭环能力。后续可以把免测能力逐步复制到音乐、长视频、短视频等业务线。

不同业务的免测标准不同，但底层逻辑一致：

目标 case 验证→ 监控集防退化→ 随机 case 兜底→ 人工关键确认→ 结果沉淀

4. 建设组织级 AI 研发看板

当前已经有跨业务线的统计：发现数、解决数、上线数、待解决数。

后续可以进一步沉淀组织级看板，从三个角度持续衡量 AI 研发能力：

这样 AI 价值就不再是“个人感觉提效”，而是可以被持续度量的组织能力。

02 总结

这个项目的核心不是 Aries，也不是某几个 Bot 的专项优化，而是一套闭环智能研发思想。

它的本质是重新划分人、Agent、代码的边界：不确定的交给 Agent，确定的交给代码，不可逆的交给人。Agent 负责分析和探索，代码负责稳定执行，人负责关键判断，验证机制负责质量兜底。

Aries 是第一条完整跑通的样板线，证明这套思想能把信息类 Bot 的问题发现、归因、修复、验证、上线串成自动闭环；音乐、长视频、短视频进一步证明，这套思想不限制业务场景。音乐可以把版权、版本、歌手、真实听歌意图拆成结构化问题；长视频可以把热点 Query、资源、召回、跨 Bot 路由纳入自动审计；短视频可以把主观满足度评估拆成相关性、意图匹配、满足度等 Skill。

截至 2026 年 7 月 24 日，这套范式已在多条业务线累计发现 160 个需求、上线解决 121 个；Aries 同等人力下每周解决需求从 2 个提升到 12.5 个，达到 6 倍吞吐；端到端满足度提升 5.4 个百分点；短视频 UP 主召回专项满足度相对提升约 43%。

所以我们沉淀的不是一个 Bot 的经验，而是一套可迁移的闭环范式。只要一个业务能定义输入、判断标准、归因类型和验证卡点，就可以接入这套范式。它改变了 RD 的工作方式：从被动执行者，变成主动发现问题、端到端跑通闭环的 Agent 工程师；团队扩产能也不再只靠增加人力，而是通过 Skill、Agent、代码和监控集，管理一支可持续运转的智能生产力队伍。