8 月 21 日,腾讯技术工程公开了用 AI Agent 驱动前后端全流程开发的降本实践:一个 1 个 TL + 6 个子 Agent 的 harness 工作流,跑一次中等需求要经历 5-6 个 Wave、20+ 次子 Agent 调用、数百轮工具调用——「钱烧得很快,但完全不知道烧在哪」。他们先用 AgentLens 拆开成本,发现大头是系统提示词、工具返回信息、历史消息,随后围绕三条原则改造了 10 个方向,整体全流程预估降本 50%~65%。
🧩 本教程适合:正在搭建或维护多 Agent 工作流的开发者与架构师。我们拆解这 10 个方向,并给出一份可直接照抄的降本检查清单。
先搞懂:多 Agent 的钱烧在哪
多 Agent 的 token 消耗可以归为六类来源。搞不清来源,省钱就无从下手:
| 消耗来源 | 特点 | 优化方向 |
|---|---|---|
| 系统提示词 | 每轮必带,随 Agent/MCP 数量倍增 | 稳定前缀 + 压缩瘦身 |
| 工具返回信息 | 大而全的工具输出大量无关内容 | 渐进式披露 + 紧凑输出 |
| 历史消息 | 对话越长携带越多,重复上下文 | 长期记忆按需索引 |
| 工具调用轮次 | 串行调用放大延迟与 token | 工具调用并行化 |
| 重复检索 | 多次翻同一份代码/文档 | 代码图谱 + 缓存 |
| 失败重试 | 任务失败后的重复执行 | 评测反馈闭环 |
先测量再优化:没有 AgentLens 这类成本观测工具,任何降本都是猜。第一步永远是「把成本拆开看」。
Step 1:搭好成本观测——先看见再动手
1 用 AgentLens 拆出六大来源占比
降本前置条件:可观测性。
1. 接入 AgentLens(或等效工具)
· 按子 Agent 统计 token 消耗
· 按来源分类(系统提示词/工具
返回/历史消息/工具调用)
2. 跑一次真实任务,生成成本报告
· 看占比 Top 3
· 对照上表定位「大头」在哪
3. 建立基线
· 记录优化前的中等需求成本
· 每次优化后重跑对比
4. 设阈值告警
· 单任务 token 超限自动告警
· 参考《预算护栏》
的护栏设计思路
典型发现(腾讯实践):
系统提示词、工具返回信息、
历史消息是大头——
都指向「上下文管理」
💡 观测工具不是可选件:没有基线就无法证明降本有效。把它当成工作流的一部分,而不是事后补救。
Step 2:三原则 × 架构拆分
2 让 AI 只看到当前需要的上下文
腾讯的三条原则:
① 只看到当前需要的上下文
② 减少无关的上下文
③ 减少重复的上下文
落地动作 1:架构拆分
· 把大 Agent 拆成职责单一的小 Agent
(TL + 后端/前端/质量/测试/视觉)
· 每个子 Agent 只带自己的
局部上下文,互不污染
· 子 Agent 之间通过
结构化交接物传递,而非全量历史
落地动作 2:稳定前缀
· 系统提示词里的固定部分
(角色、规范)排在最前
· 命中提示词缓存,后续轮次
这部分几乎零成本
· 可变内容(任务描述)放后面
效果:
首轮提示词压得越小,
后续每一轮都跟着省——
「滚雪球」式节约
拆分不是越碎越好:Agent 太多会增加交接开销。腾讯的实践是 1 个 TL + 6 个子 Agent,按 Wave 组织——先按任务天然边界拆,再考虑压缩。
Step 3:渐进式披露——让工具「按需吐料」
3 别把整个仓库塞进工具返回
问题:工具一次返回大段内容,
其中 90% 与当前子任务无关,
但 token 照算。
解法:渐进式披露(Progressive Disclosure)
1. 第一层:只返回「摘要/清单」
· 文件名、行号、关键签名
· 让模型决定下一步看什么
2. 第二层:按需展开
· 模型明确请求时才返回
完整文件/完整段落
3. 紧凑输出
· 工具返回压缩为结构化摘要
· 去掉空行、注释、无关字段
配套:
· 工具 Schema 精简描述
· 返回内容做裁剪与格式化
· CLI 替代 MCP 时同样适用
(CLI 输出可解析、可控、紧凑)
效果:工具返回信息从「大头」
变成「按需小口喂」
💡 渐进式披露的通用思路可对照《上下文工程三板斧》:过滤、压缩、分层是同一套哲学。
Step 4:代码图谱 + CLI 替代 MCP
4 让 Agent 少读文件、多用命令
方向 4:代码图谱
· 预先构建项目结构索引
(文件、依赖、接口关系)
· Agent 先查图谱定位相关文件,
而不是逐个文件翻
· 减少重复检索同一份代码
方向 5:CLI 替代 MCP
· 很多 MCP 工具本质是
「包了一层 API 的命令」
· 直接用 CLI 命令更紧凑:
· 输出可控(grep/awk/jq 裁剪)
· 无 Schema 描述开销
· 可并行、可管道
· 例:查文件用 grep 命令
而非文件搜索 MCP 工具
方向 6:长期记忆按需索引
· 历史消息不全量携带
· 存成结构化记忆,按任务需要
检索相关片段注入
· 减少「重复的上下文」
方向 7:工具调用并行化
· 相互独立的工具调用并发执行
· 串行 → 并行,延迟与
上下文占用同步下降
CLI 替代 MCP 有条件:适合内部工具与自有系统;第三方服务的鉴权、参数校验仍靠 MCP/SDK 更稳。别为了省 token 牺牲可靠性——先小范围验证再推广。
Step 5:把 10 个方向做成检查清单
5 腾讯 10 方向全表逐项过
① 架构拆分:子 Agent 职责单一,
局部上下文隔离
② 稳定前缀:固定提示词前置,
吃满缓存
③ 渐进式披露:工具先给摘要,
按需展开
④ 代码图谱:先查索引再读文件
⑤ CLI 替代 MCP:命令紧凑输出,
减少 Schema 开销
⑥ 长期记忆按需索引:
历史不全量携带
⑦ 工具调用并行化:
独立调用并发执行
⑧ 系统提示词瘦身:
精简角色描述与规则表达
⑨ 重复上下文去重:
交接物用结构化结果而非历史
⑩ 评测反馈闭环:
失败重试前先分析原因
落地节奏建议:
· 第 1 步先做观测(基线)
· 第 2-3 步做架构与披露
(收益最快)
· 第 4-7 步按痛点逐个上
· 每步改造后重跑基线对比
💡 建议用《Agent 评测》的框架衡量每步改造是否引入质量回退——降本不能以完成率下降为代价。
Step 6:从「降本」到「规模化」
6 建立成本×质量的双维决策机制
1. 成本预算化
· 每个子 Agent/任务设 token 预算
· 超预算自动降级或告警
2. 模型分级
· 简单任务低配模型,
复杂任务高配模型
· 参考《分层路由》
《V4 Pro 路由》
的模型×时段双维策略
3. 质量看门
· 完成率、返工率与成本一起看
· 参考《Agent 经济学》
的完成率×成本矩阵
4. 持续复盘
· 每季度重跑基线
· 新 Agent 上线先过降本清单
5. 防跑偏
· 多 Agent 协作的「羊群效应」
会放大无效调用,
参考《防跑偏》
最终目标:
不是「最便宜」,而是
「每块钱换到最高的完成率」
降本有天花板,别抠成残疾:上下文压缩过度会明显掉完成率。用评测数据说话——当完成率下降超过可接受阈值,就该停止压缩,转向更便宜的模型或更好的工具。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| 不知道成本花在哪 | 先接 AgentLens 类观测工具,拆出六大来源占比再优化 |
| 系统提示词每轮都很贵 | 稳定前缀置顶吃缓存 + 精简角色描述 |
| 工具返回一堆没用内容 | 渐进式披露:先摘要后展开,输出裁剪 |
| Agent 反复读同一份代码 | 建代码图谱索引,先查定位再按需读 |
| 压缩上下文后完成率掉了 | 过度压缩:回退部分披露,或改用更便宜模型而非继续压缩 |