文档(金鹏): 2026-08-28 章节 9 篇文章摘要归档
按主题分三组归档：Agent 工程纵深（经验治理/循环工程/ Token 成本治理/溯源生成）、最弱环节定律（推理链窃取/ GLM-5.3-Flash 开源）、人机共进（意志稀缺/数字员工化/ 大学之问）；每组配 4K 题图与 160x90 缩略图共 3 组， 昇腾 WAIC 纯图片一文无法文本化按先例未收录
This commit is contained in:
@@ -0,0 +1,285 @@
|
||||
# AI Coding的下一站，不是更会写代码，而是更懂团队
|
||||
|
||||
> **来源**：微信公众平台（腾讯技术工程）
|
||||
> **作者**：腾讯程序员
|
||||
> **发布日期**：2026-08-27
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/kz_7d66dhmPhOUlcMh4MzA
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
作者：linjangyang、lypeerluo、kehawang、yansycao
|
||||
|
||||
> 个人 AI Coding 的效率提升已无悬念，但团队规模铺开后，一个更深的短板暴露了：每次 session 踩坑、纠偏产出的有效经验，session 结束即归零。业界在 Agent 经验管理上的探索多聚焦"个人记忆"，而要打破AI每次进项目都"从零开始"的循环，需要的是一套能持续捕获、提纯、沉淀团队经验，让AI带着项目语境进场的系统。本文分享从 0 到 1 建设这套系统的完整过程——从初版 90% 候选经验为废料的起点，到打磨出 Review/Dedup/Merge 三层治理链路，每一步踩在真实问题上的演化路径，以及驱动策略设计的实验数据和可复用方法论。
|
||||
|
||||
### 一、"别那么干，这个 hook 不能同步上报"
|
||||
|
||||
这是半年前的一次 CodeBuddy session。当时我们在开发一个 stop hook 的上报功能，AI 很自然地给出了同步上报的实现——合理，绝大多数上报场景同步就够了。我们 review 代码时改了：必须异步，否则 stop hook 会阻塞进程，后续操作直接超时。AI 根据反馈修正了代码，session 正常结束。
|
||||
|
||||
问题出在结束之后。
|
||||
|
||||
一周后，另一个同事的 session 触发了同样的场景。AI 没有那次 session 的上下文，给出的仍然是同步上报。同事不是那块代码的原始开发者，review 时没有发现这个陷阱。代码合入了，直到测试环境才暴露——stop hook 场景下进程阻塞，一连串超时错误。 这就是经验断层。不是 AI 不行——它在自己的 session 里被纠正过一次，做得很好。但那次纠正只在发起那轮 session 的开发者脑子里，AI 完全不记得发生过什么。
|
||||
|
||||
更普遍地看，我们团队在持续深入使用 AI Coding 一段时间后，陆续碰到四类这类问题：
|
||||
|
||||
- __经验即抛__：一次 session 反复纠偏踩出来的路径，session 结束就清零。下一个同事碰同样问题，AI 又是零基础起步。
|
||||
- __重复踩坑__：项目的隐性约束——"这个目录下的代码访问第三方服务需要走特殊代理""模块间开关引用不能直接用字符串参数，因为开关使用时机问题会导致永远默认关"——这些规则写在 git blame 里，但从来不进文档。换个人、换个 session，很大概率照踩不误。
|
||||
- __知识碎片化__：老同事脑子里有一套"这么做才对"的 pattern，但没人有动力写下来。文档永远跟不上代码变更的速度。到了 AI 时代，靠的不是知识管理，是靠运气——这次 session 的上下文恰好覆盖了上次的历史，就对了；没覆盖，就错了。
|
||||
- AI 永远是"新同事"：AI 不分项目。进新模块不知道架构边界在哪，不知道历史包袱是什么，也不知道团队踩过什么坑。它不缺编码能力，缺的是"这个团队的语境"。
|
||||
|
||||
所以整个事情的起点，不是"怎么让 AI 写代码更快"，而要打破AI每次进项目都"从零开始"的循环，这需要的是一套能持续捕获、提纯、沉淀团队经验，让AI带着项目语境进场的系统。
|
||||
|
||||
### 二、初版翻车：90% 的产出不可用
|
||||
|
||||
我们最初的方案非常直白。利用 CodeBuddy 的 Plugin Hook，上报所有的研发对话。然后让 AI 读这些对话，自动提取经验。Prompt 核心就一句话：__"提取你认为有价值的内容"__——边界的判断、排除规则，全交给模型。
|
||||
|
||||
逻辑上说得通：对话里反正有信息，模型也足够聪明。整条链路只有两步：
|
||||
|
||||
```
|
||||
对话上报 → 经验抽取 → 入库
|
||||
```
|
||||
|
||||
上线后我们很快发现，产出的经验里，大约 90% 是废经验，无法让后续工作更顺畅。这个"废"不是主观评价，是拿"被召回后 Agent 的行为是否发生正向改变"当标准来衡量的。而且废不是一种废，是四层结构性问题叠加在一起：
|
||||
|
||||
__第一层：噪声极高__。 原始对话包含大量调试过程——"继续""重试一下""不行，换个方式"——以及遍地的失败路径。这些不是经验，是过程录像。模型不加区分地全抽出来了。比如系统某次抽出一条"多试几次就好了"——这是在碰运气，不是在沉淀判断。
|
||||
|
||||
__第二层：上下文脱离__。 抽出来的经验脱离原始语境就失真了。比如有一次系统抽出"stop hook 需要异步处理"——听起来对，但实际上这条规则只适用于特定环节、特定场景。不加限定条件，会误导后续 Agent 在所有 hook 场景下无差别异步，反而搞出新的 bug。
|
||||
|
||||
__第三层：错误引导__。 比没经验更糟的，是错的经验。一条"超时就调大超时参数"的经验被抽出来进入库——根因不在这，这只是堆补丁。Agent 下次遇到类似问题，会优先调参数而不是排查根因，系统性走错路。
|
||||
|
||||
__第四层：价值难定义__。 LLM 的总结能力在开放域很强，但放在经验提取里，大量产出流于表面。"遇到复杂问题多收集上下文"——这句话永远对，但在具体工程场景下基本没有指导意义。AI 看完它不知道下一步该干嘛。
|
||||
|
||||
这四层问题暴露出一个核心事实：__过程录像不等于经验。自动提取放大候选集的同时，也在同步放大噪声。不加过滤的自动提取，就是一个垃圾放大器__。 让 AI 自己判断自己产出经验的价值，等于让裁判同时当运动员——在工程上无效。
|
||||
|
||||
### 三、为什么现成方案行不通
|
||||
|
||||
翻车之后，我们系统性地看了业界在"Agent 经验管理"方向上的方案。
|
||||
|
||||
__ClaudeCode AutoDream__ 做的是单会话内自动记忆整理——ExtractMemories 抽取实体/偏好/状态，Auto Dream 异步合并。定位是"延续单 Agent 上下文"，把过程记忆当永久记忆存下来。它没有团队边界的意识，也不会区分什么值得长期留、什么只是临时状态。
|
||||
|
||||
__Hermes Agent__ 是 Prompt 驱动的 memory 策略系统。它在特定条件（任务成功、踩坑解决）触发回顾——解决的是"何时记"，但解决不了"记的东西有没有价值"。缺乏系统级去重与来源追溯。
|
||||
|
||||
__Mem0__ 是一套 Agent 长期记忆基础设施。ADD/UPDATE/DELETE/NONE 四类判定、混合检索，生命周期管理完整。但整个设计的假设是"记忆大体有价值"——这个假设在编程场景的高噪声对话里完全站不住。
|
||||
|
||||
把它们放在一起看，共同的局限是：聚焦"个人记忆"，追求"记住更多"。我们需要的是反向的：聚焦"团队经验质量"，追求"留下更少但更可信"——带适用场景、约束边界、来源证据的工程经验。 既然业界没有现成方案，我们只能自己摸索。
|
||||
|
||||
|
||||
|
||||
### 四、什么是"团队经验"——从 Agent 的视角重新定义
|
||||
|
||||
经验系统的最终服务对象不是人，是 Agent。Agent 的工作方式很明确：接收输入（包含召回的经验）→ 做出决策/产生输出。由此推导，判定一条信息是不是经验的标准只有一个：
|
||||
|
||||
__被召回后，Agent 能否产生正向的行为变更__。
|
||||
|
||||
它把"经验"从"一段有价值的文本"锚定到了"能否改变 Agent 行为"上，是一条可实际验证的工程标准。
|
||||
|
||||
基于这个标准，一条合格的团队经验必须同时满足几个条件：来自真实对话、有证据支撑、项目特有、不是通用常识、后续相似场景可复用。其中最关键的是 __"不容易直接发现"__——如果 Agent 自己就能推出来，召回它没有任何额外价值。但什么才算"不容易直接发现"？我们按 Agent 理解需求的路径拆成三类：
|
||||
|
||||
__黑话镜头（语义不可发现）__： 项目内部的黑话、缩写、代称，字面上完全无法推导。比如"D 站"在项目里指盗版站点、"A 站"指成人站点——AI 只看到字母，不知道背后语义。这类名称在对话里反复出现，但 AI 永远猜不对。
|
||||
|
||||
__索引镜头（位置不可发现）__： 某个工具、目录、能力入口不在直觉路径上。比如"直达页面功能在 xhome 模块，关键类是 FastCutXXX"——读代码找不到，需要知道"去哪找"。
|
||||
|
||||
__逻辑镜头（行为不可发现）__： 反直觉的工程约束、隐式机制。开头提到的"stop hook 不能同步上报"就是典型——AI 常规推理认为"上报是轻量操作，同步没问题"，但实际场景有并发阻塞风险。再比如"模块间开关引用不能直接用字符串参数"——开关确实有 String 参数，但用了之后由于开关使用时机的问题导致效果永远为默认关。这种坑，常规推断推不出来。
|
||||
|
||||
这三个镜头不是按主题（前端/后端）或重要性（高/中/低）分的——那些维度要么无穷无尽列不完，要么依赖主观判断不稳定。认知障碍是客观的：一条信息"Agent 能不能自己发现"，可以判定。
|
||||
|
||||
| 镜头类型 | 障碍本质 | 典型场景 | 信息缺口 |
|
||||
| --- | --- | --- | --- |
|
||||
| 黑话镜头 | 语义不可发现 | "D 站"字面只是字母 D | 需要显式映射为"盗版站点" |
|
||||
| 索引镜头 | 位置不可发现 | "直达页面功能在哪" | 需显式指向 xhome 模块 FastCutXXX |
|
||||
| 逻辑镜头 | 行为不可发现 | stop hook 同步上报 | AI 常规推理推不出并发阻塞风险 |
|
||||
|
||||
### 五、系统链路：被问题逼出来的演化
|
||||
|
||||
回到实际工程。初版的两步链路能跑通，但跑起来后问题一个一个暴露——每个都不是设计时预见的：
|
||||
|
||||
__问题 1__： 原始对话一股脑塞给模型，主题混杂、噪声大、上下文溢出。经验不是什么单轮对答就能判断的——需要看"失败 → 纠正 → 修复 → 采纳"的完整过程。
|
||||
|
||||
→ 新增 __主题分组__ 环节：让模型结合 session 大纲按主题切分片段，分组后再逐个提取。 __问题 2__： 仅提取就直接入库，约 90% 是垃圾。
|
||||
|
||||
→ 新增 __Review 质量审核__ 环节：入库前设一道质量闸口。 __问题 3__： 不同分组、不同 session 产生重复候选经验。
|
||||
|
||||
→ 新增 __Dedup 候选去重__ 环节：在入库前识别并合并重复。 __问题 4__： 入库后无法长期维护，新经验与历史经验的关系是糊涂账。
|
||||
|
||||
→ 新增 __Merge 历史合并__ 环节：判断新经验是新建、更新、跳过还是与历史冲突。
|
||||
|
||||
整条链路最终收敛为：
|
||||
|
||||
```
|
||||
对话上报 → 主题分组 → 经验抽取 → Review → Dedup → Merge → 入库 → 召回统计
|
||||
```
|
||||
|
||||
一个容易被忽视的关键是主题分组。我们试过两组对照：一组给分组后的片段额外附上 session 上下文大纲，一组不给。带大纲的那组产出了更多垃圾——因为大纲引导模型做泛化推断，反而偏离了分组片段里实际发生的具体经验。分组本身的粒度就够了。
|
||||
|
||||
|
||||
|
||||
### 六、三层治理：从"能跑"到"能用"
|
||||
|
||||
链路搭起来只是第一步。真正让系统可靠的是 Review / Dedup / Merge 三层治理。这三层目标不同、策略不同、默认方向也不同，但底层驱动方式一致——__错例分析 → 规则抽象 → 评测验证__。
|
||||
|
||||
#### 6.1 抽取：从识别垃圾到评测驱动
|
||||
|
||||
在讲三层之前，得先说清楚源头——经验抽取这一步本身怎么持续变好。
|
||||
|
||||
初版证明了"能抽出经验"，但质量参差不齐。"好经验"很难一次定义到位，但"垃圾经验"的特征更容易归纳。所以我们的做法是 __先研究垃圾，再反推好经验__。经过大量标注，归纳出九类典型垃圾特征：
|
||||
|
||||
1. __事实性错误__——编造不存在的约束，把对话里的临时说法当规则
|
||||
2. __通用常识__——任何项目都适用，不体现团队特异性
|
||||
3. __对话摘要__——只复述过程，没有沉淀成可复用判断
|
||||
4. __一次性 case__——只对当前任务有效，不能迁移
|
||||
5. __用户主观偏好__——个人选择，不代表团队规范
|
||||
6. __缺少上下文__——不知道对应哪个模块/组件/接口
|
||||
7. __粒度混用__——一条经验里兼顾通用规则和 case 特定信息
|
||||
8. __不可执行__——只有抽象建议，Agent 看完不知道怎么做
|
||||
9. __证据不足__——对话里没有足够依据，模型自己推断过多
|
||||
|
||||
有了九类特征，走两条路径工程化：
|
||||
|
||||
__标注路径__： 对候选经验做价值标注（高价值/低价值/垃圾）→ 对垃圾做归因 → 归纳垃圾模式 → 转成标注规则和 Reviewer 标准。这条路径的意义是让"经验质量"从主观感觉变成可讨论、可对齐的对象。形成的评测集会持续用于后续所有 prompt 修改的效果测量。
|
||||
|
||||
__可审计路径__： 要求模型为每条经验输出三个维度的解释——为什么这是经验（解决了什么可复用问题、是否是项目特有）、命中了 prompt 中的哪些排除规则（通过了哪些垃圾检查）、对话证据是什么（哪几轮对话支撑）。这让模型的判断过程脱离黑盒，也为后续 prompt 迭代提供了错例定位的依据。
|
||||
|
||||
有了这两条路径，Prompt 的迭代不再是"感觉不太好改一下试试"，而是有明确的结构化流程：
|
||||
|
||||
```
|
||||
固定对话样本 → 当前 prompt 提取 → 与人工标注对齐 → 分析错例 → 修改 prompt → 重新评测 → 对比指标变化
|
||||
```
|
||||
|
||||
三个核心指标一起看：Recall 看该提取的提了多少、Precision 看提取的有多少不是垃圾、Garbage Rate 看不该提取的提了多少。__不能只看一个__——只看 Precision 模型会过度保守，只看 Recall 垃圾会变多。目标是同时保持垃圾率下降和整体提取质量不退化。
|
||||
|
||||
#### 6.2 Review：源码探索做事实性校验
|
||||
|
||||
Review 的定位是在入库前拦住明确垃圾。策略是__默认保留、定向过滤__——不追求全面收紧，只对明确的三类垃圾维度做精准拦截：事实性错误/偏好、缺上下文、粒度混用，外加一层无经验类别兜底。这一定位背后是风险判断：经验系统的首要风险是"漏掉好经验"大于"多放几条边缘经验"，默认保留能避免 Review 因过于严格误杀高价值内容。
|
||||
|
||||
Prompt 的裁决框架收敛为四步：事实性错误/偏好检查 → 缺上下文检查 → 粒度混用检查 → 无经验类别兜底。经过三轮迭代从"整体重构"到"边界强化"到"偏好规则硬化"，垃圾穿透不断改善。
|
||||
|
||||
但纯文本判断有一个天然局限：模型无法验证经验中提到的技术事实是否真实存在。
|
||||
|
||||
一条真实案例：系统抽出一条经验，声称 Android 列表开发中对接 FastScrollBar 应使用 attachToQBListView() 方法。从文字上看逻辑自洽——有具体场景、有方法名、有操作指引。纯文本 Review 大概率会放行。但我们引入了__源码探索__——在代码库中检索 FastScrollBar 的类定义，发现该类只有 attachToRecyclerView() 和 attach() 两个方法，根本不存在 attachToQBListView()。正确的方法是 FastScrollBarCompat.attachToQBRecyclerView()。经验被标记为事实性错误，直接拦截。
|
||||
|
||||
```
|
||||
[Reviewer 候选实体] ──▶ 提取代码线索: "FastScrollBar", "attachToQBListView"
|
||||
│
|
||||
▼ Code Explorer 源码定向搜索
|
||||
[QQBrowser 源码库] ──▶ 匹配 Class "FastScrollBar" (收敛成功)
|
||||
│
|
||||
▼ 成员函数级事实验证
|
||||
发现: 该类只有 attachToRecyclerView() 和 attach() 两个方法
|
||||
不存在 attachToQBListView()
|
||||
(正确方法属于 FastScrollBarCompat.attachToQBRecyclerView())
|
||||
│
|
||||
▼
|
||||
[ 触发 S1_FACTUAL_ERROR 拦截 ]
|
||||
```
|
||||
|
||||
如果这条经验入库，Agent 在涉及列表的场景中会按指示调用一个不存在的方法，编译失败。更麻烦的是 Agent 会怀疑自己理解有误，而不是怀疑经验有问题——陷入反复重试的恶性循环。
|
||||
|
||||
#### 6.3 Dedup：宁严勿宽，禁止桥接合并
|
||||
|
||||
Dedup 的定位是在候选经验集内部识别重复，减少后续流程中的冗余判断。这层的核心风险不是"漏去重"，而是误去重——把两条本应独立保留的经验错误合并，造成的边界污染是永久性的。
|
||||
|
||||
因此策略明确为__宁严勿宽__。几条严格否决规则：
|
||||
|
||||
- When 不同不能合——即使结论看起来相似，场景不同就是两条不同的经验
|
||||
- 主结论类型不同不能合——操作建议、风险规避、排查方法之间不能混为一谈
|
||||
- 局部子机制和完整系统经验不能合——粒度不一致，不能互相替代
|
||||
- 同一技术事实但用途不同不能合——比如同一条 API 既用于性能优化又用于兼容处理，不能因为"都涉及这个 API"就合并
|
||||
|
||||
最关键的一条是__禁止桥接式合并__：A 和 B 在处理结果上有重叠、B 和 C 也相关，不能因此推断 A 和 C 是重复。经验的边界在于适用场景的约束条件，语义相似不等于经验等价——一旦桥接式合并把边界不同的经验串联归并，边界信息就永久丢失了。
|
||||
|
||||
在 260 条经验、4 个分组的评测中，整体 F1 为 71.79%。但更值得关注的指标是严格重复场景下的表现——What 和 When 均相同的经验，Recall 达到了 91.67%。这说明在最核心的去重目标上，策略是有效的。漏判主要集中在 What 为包含/相交、When 为不同/相交的边界模糊组合上——这类场景下策略更倾向于保护差异，避免贸然合并。
|
||||
|
||||
值得注意的是，这 260 条经验是分 4 批独立进行的，batch 之间表现差异明显。最极端的是 batch_004，仅识别出 6 个人工正例中的 1 个——该 batch 的正例全部落在非"双强一致"的组合上。这说明去重 prompt 对边界的敏感度在输入特征分布变化时仍有波动。
|
||||
|
||||
#### 6.4 Merge：唯一目标先行，保护历史边界
|
||||
|
||||
Merge 是入库前的最后一关。它判断一条新经验和历史经验库之间的关系，执行四种动作之一：
|
||||
|
||||
- __create__：库中不存在同类目标经验，新建入库
|
||||
- __update__：与历史经验同向，但带有实质新信息，合并更新
|
||||
- __skip__：与新经验在核心结论上可互相替代，跳过
|
||||
- __contradict__：核心结论直接冲突，标记为冲突并提人工裁决
|
||||
|
||||
策略上有三条主线：
|
||||
|
||||
__唯一目标判定前置__。 先从历史库中召回与新经验相关的子集，判断是否存在"唯一最合适的经验目标"。如果没有——比如新经验和几条历史经验都沾边，但都不属于同一条可维护经验——__默认回退到 create__。这条规则从根本上避免了"强行匹配"——一条不够匹配的历史经验被硬推成 update 目标，污染边界。
|
||||
|
||||
__Update 必须自检__。 对每一笔 update 增加内部 quality_check：合并后的 When 是否过度泛化（丢失了原经验的场景约束）、What 是否保留了最具体、最安全、最可执行的操作建议、Why 是否保留了核心机制、是否引入了不受原始经验支持的新结论。Update 过判是当前最突出的问题—— Recall 高达 96.30% 但 Precision 只有 78.79%。也就是说大部分该 update 的都被识别了，但模型存在明显的"积极合并"倾向，把一些本该 create 的内容也判成了 update。
|
||||
|
||||
__Contradict 不自动放过，不自动决断__。 冲突意味着团队的新认知和旧认知出现了不一致——这本身就是有价值的信号，不应该被自动压制。系统只负责标记，具体的决策走人工裁决通道。
|
||||
|
||||
六轮实验、157 个统计样本中，整体 F1 达到 94.27%。Create 是最稳定的主类别（F1 96.46%），模型在"没有唯一目标就创建"上的判法已经比较可靠。Skip 的 Precision 达到 100%——一旦模型判成了 skip，基本都判对；但 Recall 只有 85.71%，仍有一部分真实 skip 被分流到了 update 或 create。Update 是改进空间最大的类别。
|
||||
|
||||
|
||||
|
||||
### 七、跑起来之后
|
||||
|
||||
经过完整的三层治理漏斗，我们最终实现了从初版 90% 的抽取垃圾率到治理后 95% 的有效率，再到平均 80% 的最终入库率——大量的对话摘要、通用建议、一次性 case、缺乏上下文的碎片内容被扼杀在提取阶段、候选经验再被逐层拦截和合并。
|
||||
|
||||
截至目前，团队经验系统已在 QQ 浏览器团队 __6__ 个仓库中常态化运行，覆盖 __50__+ 名研发人员的日常开发 session，累计采集 __1,236__ 次独立对话。从这些对话中累计提取出 __1,022__ 条候选经验，经三层治理最终入库 __789__ 条高置信经验，Pipeline 已稳定运行 __30__+ 次。
|
||||
|
||||
#### 7.1 完整的系统运行生命周期
|
||||
|
||||
以 2026/05/27 日这条 Pipeline 的真实运行案例来看系统如何运作。
|
||||
|
||||
本次处理原始对话记录数 39 条，初步提取候选经验 34 条，Review 后被拦截 3 条，与历史经验库合并 1条，最终入口 30 条：
|
||||
|
||||
|
||||
|
||||
其中一条 "_ForbiddenController 新增禁用能力须同步改三处_" 的候选经验被拦截，被识别的原因就是"在罗列修改清单，告诉读者去哪里找、改什么，而不是在说明隐藏技术事实。"，印证了 Review 门禁在精确区分"技术事实"这条红线上，动作准确。
|
||||
|
||||
而另一条 "_Chromium源代码层只能通过hooks层访问UBA功能_" 的候选经验则由于表达的是不易察觉的技术事实后果，因此被允许通过并入库。
|
||||
|
||||
|
||||
|
||||
在后续与 Agent 协作的开发场景里，我们通过 TDev 驱动需求实现的流程时，对话内部在特定阶段（探索）自动触发对历史经验的召回尝试：
|
||||
|
||||
|
||||
|
||||
#### 7.2 召回消费：复用已有基建
|
||||
|
||||
在召回这里，我们没有重新造轮子，而是深度复用了公司已有的知识库平台：
|
||||
|
||||
1. __存储落库__：三层治理通过后的经验，自动写入 __IWIKI 经验空间__。
|
||||
2. __自动索引__：__Knot 知识库系统__实时监听并自动索引 IWIKI 经验内容，生成向量与关键词索引。
|
||||
3. __MCP 检索桥接__：Knot 提供标准 MCP 协议服务。Agent 在 session 期间自动调用 Knot MCP 接口检索相关经验并注入上下文。
|
||||
4. __监控旁路__：在检索流程中增加了上报旁路，实时记录召回成功率和条数。
|
||||
|
||||
在最新 125 次真实开发检索的召回表现：请求级召回率68.8%，no_hit（未命中）仅 4.8%，平均每次注入 __2.4__ 条经验，平均检索耗时 __1,299 ms__。
|
||||
|
||||
这种架构让团队将全部精力集中在最核心的"经验提纯与治理"上。
|
||||
|
||||
### 八、四条可复用的方法论
|
||||
|
||||
回看整个过程，有价值的不是某一个 prompt 怎么写、某一个参数怎么调，而是四条从反复踩坑中收敛出来的工程原则。
|
||||
|
||||
__第一条：先定义资产边界，再做自动化沉淀__。 初版 90% 废经验教会我们最核心的一课：不定义"什么算经验"就直接启动自动提取，系统会把对话摘要、通用建议、一次性 case 全塞进库。经验系统的关键不是"多提取"，而是"高置信地沉淀"。在工程化之前必须回答：什么算经验、什么不算、判断标准是什么。
|
||||
|
||||
__第二条：分层治理，别用一个 prompt 解决所有问题__。 Review 负责拦垃圾、Dedup 负责候选集内去重、Merge 负责历史库治理——每一层的目标不同、指标不同、prompt 设计也不同。把它们揉在一起，各层目标就会互相牵制。用多个针对性模型各自完成一件事，比一个通用大模型一次性全搞定更可靠。
|
||||
|
||||
__第三条：默认策略要按业务风险分别设计，没有统一答案__。 Review 默认保留（误杀一条高价值经验的代价大于放行两条垃圾）、Dedup 宁严勿宽（误合并的边界污染不可逆）、Merge 保护历史边界（已有的经验是已验证的资产，新经验要跨过更高门槛才能修改它）。"宁可错杀"和"宁可放过"的方向在各层完全不同。
|
||||
|
||||
__第四条：Prompt 优化要从错例中抽象规则，不是凭感觉改__。 我们做 prompt 迭代不是"这个效果不好改一下试试"，而是固定的流程：收集错例 → 识别误判类型 → 抽象成可操作规则 → 多轮实验验证效果 → 判断规则是否有正向收益。同时用固定评测集防止数据泄露和过拟合。整个链路是工程化的，不是手艺活的。
|
||||
|
||||
### 结语
|
||||
|
||||
经验系统从 0 到 1 的建设已经跑通了——链路运转着，三层治理上线了，召回也在工作。但这只是起点。真正让经验系统从"能用"走到"可靠"，还有三个环环相扣的方向：
|
||||
|
||||
__经验质量（生产阶段）__： 当前三层治理生效之后，垃圾率降至约 5%。但事实性错误仍难以纯文本识别，源码探索只覆盖了部分场景；三个镜头之外的边界经验类型还没充分识别；评测集规模有限，长尾和冷门主题覆盖不全，prompt 迭代的边际收益在收窄。
|
||||
|
||||
__使用效率（召回阶段）__： 经验已能被召回并注入上下文，但命中不等于采纳——目前缺乏观测 Agent 是否真的依据经验改变行为的手段；召回侧的唯一目标判定偏粗，相似主题下容易出现"召回了但用不上"。
|
||||
|
||||
__管理维护（生命周期）__： 长期未命中、未采纳的经验没有自动淘汰机制，库会随时间静默膨胀；项目演进时（模块重构、能力下线）历史经验可能集体失效，目前没有自动识别"需要复核"的能力。
|
||||
|
||||
三者构成闭环：__生产决定基线 → 使用暴露问题 → 维护反哺生产__。任一环不闭合，经验系统就会从资产退回为噪声。
|
||||
|
||||
最后想说一句：经验系统的本质不是技术系统，是__团队认知能力的工程化管道__。过去经验在人脑里、产出在文档里；现在经验产生于人与 AI 的对话过程，需要一套管道来捕获、提纯、分发。管道一旦建成，团队就不再依赖"谁在那个时间段在做什么"来传承知识——AI 每次进入项目，都能带着"这个团队积累了什么、在什么场景下该怎么做"的语境。
|
||||
|
||||
#### QQ 浏览器平台技术团队
|
||||
|
||||
我们是腾讯 CSIG 旗下负责 QQ 浏览器平台研发的核心技术团队。致力于为超 4 亿用户打造极速、智能、全平台的浏览体验，产品覆盖 Android、iOS、鸿蒙、Windows、macOS 全终端。
|
||||
|
||||
团队深耕浏览器底层技术十余年，当前正深度参与 AI 在浏览器的能力落地，持续探索大模型时代技术的新边界。期待与更多同行切磋交流，共同成长。
|
||||
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
# 📊 文章摘要：AI Coding的下一站，不是更会写代码，而是更懂团队
|
||||
|
||||
> **原文**：[2026-08-27_AI_Coding的下一站_不是更会写代码_而是更懂团队](./2026-08-27_AI_Coding的下一站_不是更会写代码_而是更懂团队.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/kz_7d66dhmPhOUlcMh4MzA
|
||||
> **来源**：微信公众平台（腾讯技术工程）
|
||||
> **作者**：腾讯程序员
|
||||
> **发布日期**：2026-08-27
|
||||
> **摘要日期**：2026-08-27
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **经验治理** — AI Coding 的短板已从"写得快不快"转移到"团队经验能否跨 session 存活"；把经验定义为"被召回后能改变 Agent 行为的信息"，再用 Review/Dedup/Merge 三层治理追求"留下更少但更可信"，是从个人记忆走向团队认知资产的关键工程。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是腾讯 QQ 浏览器团队从 0 到 1 建设"团队经验系统"的完整复盘。起点是一个真实痛点：session 内的纠偏经验（如 stop hook 必须异步上报）在人脑里蒸发，AI 每次进项目都从零开始。初版"对话上报→自动提取→入库"产出 90% 废料，迫使团队重新定义什么是经验（唯一标准：被召回后 Agent 行为是否正向改变），并演化出 Review（源码探索做事实校验）/Dedup（宁严勿宽、禁止桥接合并）/Merge（唯一目标先行、保护历史边界）三层治理。系统已在 6 个仓库、50+ 研发、1236 次对话中沉淀 789 条高置信经验，请求级召回率 68.8%。价值在于提供了罕见的完整失败-演化-量化数据链，局限是召回采纳观测与经验生命周期管理尚未闭环。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **经验的唯一定义是"能否改变 Agent 行为"** — 把经验从"有价值的文本"锚定到"被召回后 Agent 能否产生正向行为变更"，使主观的质量判断变成可工程验证的标准。 `[分类: 范式突破]`
|
||||
2. **"不容易直接发现"三镜头分类** — 黑话镜头（语义不可发现）、索引镜头（位置不可发现）、逻辑镜头（行为不可发现）按 Agent 认知障碍划分经验类型，比按主题/重要性分类更客观可判定。 `[分类: 共识]`
|
||||
3. **不加过滤的自动提取是垃圾放大器** — 初版 90% 废经验的四层结构性问题（噪声、脱离上下文、错误引导、价值难定义）证明"过程录像不等于经验"，让 AI 自评价值等于裁判兼运动员。 `[分类: 共识]`
|
||||
4. **Review 层的源码探索事实校验** — 纯文本无法验证技术事实，引入 Code Explorer 检索类定义拦截"attachToQBListView()"这类幻觉方法名，事实性错误直接拦截。 `[分类: 共识]`
|
||||
5. **Dedup 宁严勿宽、禁止桥接式合并** — 误合并造成的边界污染是永久性的；严格重复场景 Recall 91.67%，但边界模糊场景倾向保护差异。 `[分类: 共识]`
|
||||
6. **Merge 唯一目标判定前置** — 无唯一匹配目标时默认回退 create，避免强行匹配污染历史边界；冲突（contradict）不自动裁决而走人工通道，因为冲突本身是有价值的认知信号。 `[分类: 共识]`
|
||||
7. **四条可复用方法论** — 先定义资产边界再做自动化；分层治理别用一个 prompt 解决所有问题；默认策略按业务风险分别设计（Review 默认保留、Dedup 宁严勿宽、Merge 保护历史）；Prompt 优化从错例抽象规则而非凭感觉改。 `[分类: 共识]`
|
||||
8. **经验系统的本质是团队认知能力的工程化管道** — 生产（质量）→ 使用（采纳）→ 维护（淘汰）构成闭环，任一环不闭合，经验系统就会从资产退回为噪声。 `[分类: 未探索]`（召回采纳观测、经验自动淘汰、项目演进后的批量失效识别均为待解方向）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者默认：(1) session 对话是团队经验的主要产生场所，且上报对话在组织与隐私上可行；(2) "改变 Agent 行为"这一标准可以通过召回统计近似衡量；(3) 团队经验的颗粒度可以脱离原始对话语境存活（三镜头限定条件是否足以防失真，作者自己承认上下文脱离仍是问题）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据链罕见地扎实：90%→5% 垃圾率的治理效果、260 条 Dedup 评测（F1 71.79%）、157 样本 Merge 评测（F1 94.27%）、125 次真实检索召回数据，全部有量化支撑。方法论部分是作者的总结性推断（四条原则），通用性有待其他团队复现验证。薄弱点：Update 过判（Precision 78.79%）被如实披露但未给出解法；"有效率 95%"的判定手段（Recall 后行为是否正向改变）在结语中承认缺乏观测手段，即核心标准本身尚未完全可测。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论适用于有稳定代码库与规模化 AI Coding 使用的工程团队；对小型团队，三层治理的建设成本可能高于收益。经验类型局限于"三镜头"覆盖的工程事实，架构品味、产品判断类知识不在其列。跨仓库/跨团队的经验共享、经验的时效衰减均未展开。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "被召回后，Agent 能否产生正向的行为变更。"
|
||||
|
||||
> "过程录像不等于经验。自动提取放大候选集的同时，也在同步放大噪声。不加过滤的自动提取，就是一个垃圾放大器。"
|
||||
|
||||
> "经验的边界在于适用场景的约束条件，语义相似不等于经验等价。"
|
||||
|
||||
> "经验系统的本质不是技术系统，是团队认知能力的工程化管道。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：从翻车起点讲起的诚实复盘，每一步演化都被真实问题驱动而非设计先行；量化数据贯穿全链（垃圾率、F1、召回率、入库量）；三镜头分类与"改变 Agent 行为"的经验定义具有范式价值；四条方法论可直接迁移到本院 L1 词典/记忆治理实践。
|
||||
|
||||
**不足**：核心标准"行为正向改变"缺乏观测闭环（作者自认）；评测集规模有限，长尾主题覆盖不全；对个人经验与团队经验的冲突消解未讨论。
|
||||
|
||||
**适用场景**：建设团队级 Agent 记忆/经验系统的架构参考；LLM 输出质量治理（多层 prompt 流水线）的方法论模板；评估 ClaudeCode AutoDream、Mem0 等方案时的对照框架。
|
||||
|
||||
**关联建议**：与本院 L1 实体词典（arno-anl-transcript 的变体沉淀）和跨项目记忆（arno-util-memstat）互证——本文的 Dedup 禁止桥接合并、Merge 冲突人工裁决规则可直接借鉴；与同批《对Loop Engineering的思考》对照：一个解决"经验从哪来"，一个解决"循环怎么跑"；与 2026-08-20《Skill 工程方法论》中"gotchas 是最高价值内容"观点高度呼应——本文就是 gotchas 沉淀的工程化实现。
|
||||
@@ -0,0 +1,398 @@
|
||||
# 靠这10个优化点，我们把Multi-Agent工作流成本降了50%以上
|
||||
|
||||
> **来源**：微信公众平台（腾讯技术工程）
|
||||
> **作者**：腾讯程序员（lemonye）
|
||||
> **发布日期**：2026-08-27
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/TIdXNlrcAOUZWVW1oWnnKQ
|
||||
|
||||
---
|
||||
|
||||
作者：lemonye
|
||||
|
||||
> 我们用 AI Agent 驱动前后端全流程开发——从需求分析到自动化测试，整个 harness 工作流由 1 个 TL + 6 个子 Agent 组成。跑起来之后第一个问题就是：钱烧得很快，但完全不知道烧在哪。我们先用 AgentLens 把成本拆开看，发现系统提示词、工具返回信息、历史消息是大头。围绕"让 AI 只看到当前需要的上下文、减少无关的上下文、减少重复的上下文"这三个原则，我们逐一改造了架构拆分、稳定前缀、渐进式披露、代码图谱、CLI 替代 MCP、长期记忆按需索引、工具调用并行化等 10 个方向。整体全流程预估降本 50%~65%。
|
||||
|
||||
### __一、背景与挑战__
|
||||
|
||||
#### 1.1 业务背景
|
||||
|
||||
过去半年，我们团队一直在探索用 AI Agent 驱动前后端协同开发——从需求分析、技术方案设计，到前后端并行编码、自动化测试、视觉还原验证，全流程由一个叫 tech-leader 的 harness Skill 统一调度：
|
||||
|
||||
```
|
||||
TL（调度层）
|
||||
├── Wave 1（并行）：后端 Agent + 前端 Agent
|
||||
├── Wave 2：质量审查 Agent
|
||||
├── Wave 3：测试 Agent（用例生成 + 执行）
|
||||
├── Wave 4：视觉验证 Agent
|
||||
└── Wave 5：Agent 评测
|
||||
```
|
||||
|
||||
跑一次完整的中等需求，往往需要经历 5-6 个 Wave、20+ 次子 Agent 调用、数百轮工具调用。规模一上来，token 成本就成了绕不开的问题。
|
||||
|
||||
#### 1.2 痛点分析：六类消耗来源
|
||||
|
||||
一次任务的 token 消耗可以归为六类来源：
|
||||
|
||||
| 来源 | 说明 | 成本特点 |
|
||||
| --- | --- | --- |
|
||||
| ① 系统提示词 | 系统固定提示词、Skill 描述、MCP 工具 Schema | 每轮必带，随 Agent/MCP 数量倍增。一个 40 工具的 MCP Server 每轮增加约 10-15KB Schema 开销 |
|
||||
| ② 工具返回的信息 | MCP 调用返回的工具列表、返回的具体内容（需求 JSON、设计稿节点树、截图 base64） | 体积不可控，塞进 context 后后续几十轮都要跟着重复计费 |
|
||||
| ③ 读取的文件信息 | AI 读取的代码文件、知识库文档内容 | 盲搜式探索往往要 3-5 轮才能定位，每轮匹配行、整段文件都会累积 |
|
||||
| ④ 长期记忆 | AI 加载的历史经验、技术方案沉淀文档 | 一旦加载往往常驻会话，即使后续用不上大部分内容 |
|
||||
| ⑤ 历史消息 | 多轮会话后累积的历史 | 真正的大头，append-only 且滚雪球式增长，越往后轮次越贵 |
|
||||
| ⑥ 用户提示词 | 用户输入的一句话/一段需求描述 | 每轮增量，只出现一次、体量小，六类中最便宜的一项 |
|
||||
|
||||
这六类来源叠加，导致一个中等需求的 token 消耗远超预期。而且在没有按 Wave 粒度拆分消耗之前，完全不知道钱主要烧在哪里——这是我们做这次优化专项的直接动因。
|
||||
|
||||
#### 1.3 先建度量：看清成本在哪里
|
||||
|
||||
本人使用的IDE是codebuddy内网版，内网版是把每轮对话的工具链调用和token用量上报到内网的AgentLens平台，如果您使用的是其他IDE，需要查阅下官方文档看看每轮对话的token用量怎么获取。
|
||||
|
||||
没有度量就没有优化。CodeBuddy 已将每轮对话的 token 消耗上报至 AgentLens，通过 agentlens-mcp 可以按 TraceId 追踪单次调用链路，也可以按 SessionId 聚合一个完整需求的消耗分布：
|
||||
|
||||
看清成本分布之后，目标就明确了：系统性压缩六类来源里能压缩的部分，把中型需求的全流程 token 成本降下来。
|
||||
|
||||
### 二、整体方案
|
||||
|
||||
#### 2.1 思路与路径
|
||||
|
||||
我们把可以下手的动作归纳为三个原则：
|
||||
|
||||
```
|
||||
① 让 AI 只看到当前需要的上下文 —— 该加载的东西，按需加载，不要一次性全带
|
||||
② 减少无关的上下文 —— 不该看到的东西，一开始就别带进来
|
||||
③ 减少重复的上下文 —— 同一份内容，不要在多轮里反复计费
|
||||
```
|
||||
|
||||
动手之前还有一个更前置的架构判断：是否需要拆多 Agent。拆分本身有成本（多份系统提示词并行计费），只有需求规模足够大，拆分撬动的后续收益才能覆盖这笔开销。所以我们先做规模预判（S/M/L 模式）：小需求走单 Agent 直接处理；只有中大型需求，才进入多 Agent 并行调度。
|
||||
|
||||
#### 2.2 关键技术选型
|
||||
|
||||
| 原则 | 优化手段 | 解决的问题 |
|
||||
| --- | --- | --- |
|
||||
| 只看到当前需要的上下文 | 渐进式披露（L2/L3 分层） | SKILL.md 里条件性内容常驻，用不上也要计费 |
|
||||
| 确定性的操作由脚本执行 | 大模型擅长推理，不擅长精确执行。反复试错是隐藏成本 | |
|
||||
| MCP 数据获取子 Agent 化 | TAPD/Figma 原始 payload 直接进最长生命周期 Agent 的 context | |
|
||||
| 长期记忆按需索引加载 | 历史经验/技术方案全量加载，用不上的文档也占位计费 | |
|
||||
| 减少无关上下文 | 单 Agent 拆分为多 Agent | 全能型 Agent 背负所有领域的知识和历史 |
|
||||
| Agent 专属配置（工具白名单+模型分层） | 每个 Agent 都能看到所有 MCP 工具 Schema | |
|
||||
| 代码图谱替代盲搜 | 关键词盲搜带入大量无关文件内容 | |
|
||||
| 减少重复上下文 | 稳定前缀设计（状态外化） | 进度状态/执行状态混在会话里，破坏缓存前缀 |
|
||||
| 避免重复加载 Skill | 同一份长期记忆被下游 Agent 各自重新加载 | |
|
||||
| rtk 压缩 CLI 输出 | 命令行原始输出噪音在多轮循环中反复出现 | |
|
||||
| 工具调用并行化 | 无依赖的多次调用串行等待，历史被重复打包的轮次翻倍 | |
|
||||
|
||||
### 三、实践详解
|
||||
|
||||
#### 3.1 让 AI 只看到当前需要的上下文
|
||||
|
||||
##### 3.1.1 渐进式披露
|
||||
|
||||
Anthropic 在 Agent Skill 规范中提出了一个"渐进式披露"架构，核心思想是：不是所有内容都需要常驻 context，只有真正需要时才加载。
|
||||
|
||||
三层结构：
|
||||
|
||||
这种机制的好处是，即使安装了 20 个 Skill，初始加载也仅 1000-2000 token。相比单体式提示词，上下文使用量减少约 90%。
|
||||
|
||||
本次优化主要是把正文部分内容迁移到资源层。
|
||||
|
||||
- 条件性内容外移到资源层
|
||||
|
||||
__我们之前的问题是：__大量只在特定场景才需要的内容，混在 SKILL.md 正文里常驻 context。
|
||||
|
||||
以 自动化测试Skill 为例，改造前有几块内容其实是条件性的：
|
||||
|
||||
① spec 模板代码（约 40 行 TypeScript）
|
||||
|
||||
这段代码只在 Phase A 生成 spec 文件时用到一次，之后完全是冗余占位。所以我们把模版代码外置到references中，按需提取。
|
||||
|
||||
② DB 前置操作规则（约 38 行）
|
||||
|
||||
只有检测到 DB 依赖用例时才需要。一样把DB操作规则外置到references中，按需读取。
|
||||
|
||||
改造后自动化测试Skill正文从 198 行降到 128 行（-35%）。
|
||||
|
||||
- 步骤详情外移到资源层
|
||||
|
||||
比条件性内容更彻底的做法，是把"所有步骤的详细内容"都从 SKILL 正文移到资源层，正文只留骨架。
|
||||
|
||||
以 `tech-leader`Skill （主调度Skill）为例：
|
||||
|
||||
优化前，S/M 两种模式（小需求/中等需求）的完整工作流、Wave 1~5 各阶段的派发 prompt、审查规则、测试调度逻辑等执行细节全写在 SKILL.md 正文里，Skill 一旦激活就全量常驻 context。
|
||||
|
||||
但 TL 每次实际只走一条路径——判完规模后要么进 S 模式、要么进 M 模式，进 M 模式后又按阶段逐步推进，任一时刻真正用到的只是其中一小段，其余步骤的详细内容全程占位计费却用不上。
|
||||
|
||||
改法是把各步骤的详细执行内容拆到 `references/` 资源层，SKILL.md 只保留__骨架__——核心职责、规模预判维度表、分流规则、进度追踪机制、容错机制。
|
||||
|
||||
骨架负责"决定下一步走哪"，具体"怎么走"则按需 `read_file` 对应的资源文件。
|
||||
|
||||
##### 3.1.2 确定性的操作由脚本执行
|
||||
|
||||
这里有两处优化：
|
||||
|
||||
- CLI 驱动一切环境操作和校验操作
|
||||
|
||||
一开始我的工作流里面，没有任何操作脚本和验证脚本。后来发现后端Agent写代码时，频繁出现拼错数据库连接参数、找错启动服务命令、绕过编译等等；因为反复查找各种参数、命令，为此消耗了大量token。
|
||||
|
||||
后来写了一个脚本，里面包含数据库迁移、编译、服务启动、健康检查等确定性的命令，全部让AI通过 dev-env.sh 脚本执行。AI 不拼接 mysql -u root -p 这种命令，只提供参数给脚本。
|
||||
|
||||
- 能用CLI就不用MCP
|
||||
|
||||
MCP 工具调用的隐藏成本：
|
||||
|
||||
MCP 工具给了 Agent 强大的能力，但每次 MCP 工具调用，实际上是一次完整的 LLM 推理轮次：
|
||||
|
||||
```
|
||||
每次 MCP 工具调用的真实成本：
|
||||
1. LLM 决策：判断调用哪个工具、构造参数 ← 一次 API 请求
|
||||
2. 工具 JSON Schema 常驻 context ← 每轮 10-15KB 额外 input
|
||||
3. 工具返回结果进入 context ← 可能几千行
|
||||
4. LLM 处理结果：分析输出、决定下一步 ← 又一次 API 请求
|
||||
```
|
||||
|
||||
自动化测试Skill中，我们最初用的是 Playwright MCP——通过 MCP 协议让 Agent 实时控制浏览器（打开页面、点击、截图）。但实践中发现几个问题：
|
||||
|
||||
- 每个操作都要消耗一次 AI 推理：点击一个按钮就是一次 MCP 调用 + 一次模型推理，10 步操作就是 10 轮对话，token 消耗大、速度慢
|
||||
- 不可重跑：MCP 模式下操作是实时的"一次性"行为，测试失败后想重跑一遍，Agent 需要重新推理一遍所有步骤
|
||||
- 无法并行：MCP 控制的是单个浏览器实例，多个用例只能串行执行
|
||||
|
||||
后面把Playwright MCP换成了Playwright CLI，CLI的核心思路是把自然语言用例翻译为 Playwright spec 文件，再调 Playwright CLI 批量执行。大模型做推理（生成 spec），脚本做执行（跑 CLI）。把"理解用例并翻译为代码"和"实际跑测试"拆成两步，前者需要 AI，后者完全不需要。
|
||||
|
||||
这次改造不仅节省了token，耗时也大大缩短。
|
||||
|
||||
##### 3.1.3 MCP 数据获取子 Agent 化
|
||||
|
||||
问题：主agent自己调 MCP，原始数据永久卡在最长生命周期的 context 里
|
||||
|
||||
tech-leader 工作流里，需求分析阶段要读 TAPD 需求、要读 Figma 设计稿，这两步 MCP 调用最早是主Agent自己直接发起的：
|
||||
|
||||
```
|
||||
● TAPD -> 返回mcp所有工具描述、返回完整需求描述、关联缺陷、任务列表
|
||||
|
||||
● Figma -> 返回mcp所有工具描述、返回设计稿完整节点树 JSON + 截图
|
||||
```
|
||||
|
||||
问题在于 TL 是整个工作流生命周期最长的 Agent。这两次 MCP 调用如果发生在 TL 自己的会话里，原始 payload——动辄几千字的需求描述、上万行的设计稿节点树 JSON——会一直留在 TL 的 context 里，后续几十轮工具调用都要重新计费一遍。
|
||||
|
||||
__改法：__给 TAPD/Figma 各建一个专属子 Agent，只返回结构化摘要
|
||||
|
||||
实测同一工作流改造前后，单轮会话 input token 从 1,030,000 降到 634,905，-38.4%。首次调用两种方式消耗基本一样，真正的收益在后续多轮会话不会带着原始 payload 越滚越大。
|
||||
|
||||
##### 3.1.4 长期记忆按需索引加载
|
||||
|
||||
context-keeper（知识沉淀Skill）负责在方案设计前加载历史经验/技术方案沉淀文档，最早的做法是把匹配到的候选文档全量读入，即使一份文档里只有一两条经验跟当前任务相关，剩下几十行也会一起进 context 常驻到会话结束。
|
||||
|
||||
改法是引入一层轻量的 INDEX.md 目录索引，把"查目录"和"读正文"拆成两步：
|
||||
|
||||
```
|
||||
❌ 改前：直接扫描 team/project 下所有历史文档，命中关键词就整篇 read_file
|
||||
✅ 改后：
|
||||
1. 先 read_file INDEX.md（几十行的标题+标签+摘要表格）
|
||||
2. 按关键词匹配标题/标签/摘要，结合类别权重计算相关度
|
||||
3. 取 Top 3 命中条目，才对这几篇 read_file 正文
|
||||
4. INDEX 不存在时才回退到全文 search_content（兜底，非常态路径）
|
||||
```
|
||||
|
||||
INDEX.md 本身是所有历史文档的目录，体量通常只有几十到一两百行——用几十行的索引筛选出真正相关的 2-3 篇，比一次性全量加载几十篇文档的正文便宜得多。相关度评分低于阈值的文档从一开始就不会进入 read_file 候选列表，从源头减少了"加载了但用不上"的常驻 token。
|
||||
|
||||
#### 3.2 减少无关的上下文
|
||||
|
||||
##### 3.2.1 单 Agent 拆分为多 Agent
|
||||
|
||||
最早的 tech-leader 是一个从头到尾自己干完所有事的单体 Agent，带来两个问题——前端/后端/测试/视觉规范混在同一段历史里，越跑越臃肿；全程一条会话没有重置时机，历史只会越滚越大。
|
||||
|
||||
改法是引入专职调度的 TL，把编码/测试/视觉校验分发给按角色划分的子 Agent（backend-dev / frontend-dev / test-runner / visual-reviewer / code-reviewer），每个子 Agent 只携带自己领域的提示词和工具，跑完即销毁，Wave 1 的前后端还能并行派发。
|
||||
|
||||
需要注意的是：拆分本身不是靠"减少历史堆叠"直接省钱的——6 个 Agent 并行跑，等于同时有 6 份系统提示词在计费。真正的收益是分散滚雪球效应（短生命周期子 Agent 跑完销毁，滚雪球被切段）和为后续优化打开空间（稳定前缀、工具裁剪、模型分层、子 Agent 化都建立在"已经拆分"的前提上）。这也是为什么要先做规模预判——小需求不做无谓拆分。
|
||||
|
||||
##### 3.2.2 Agent 专属配置
|
||||
|
||||
以前每个子 Agent 默认带上所有已注册 MCP Server 的工具 Schema（即使用不到），是一个隐藏的成本漏洞。
|
||||
|
||||
以前我们用的是CodeBuddy自带的TeamCreate工具，自动派生子 Agent来完成任务。但是这种模式就没办法给子 Agent设置mcp白名单、模型。后来我的改法是：给每个角色创建单独的自定义Agent，在创建团队时调用相应的自定义子 Agent执行任务。
|
||||
|
||||
这种做法可以在 Agent 定义文件的 frontmatter 中通过 tools 字段指定工具白名单，未列出的工具对该 Agent 完全不可见，比如后端开发Agent，就不需要任何mcp工具，只需要读文件、写文件等工具；
|
||||
|
||||
```
|
||||
---
|
||||
name: backend-dev
|
||||
tools: list_dir, search_file, search_content, read_file, replace_in_file, write_to_file, execute_command
|
||||
# 没有 mcpServers 字段 → Figma/TAPD/iWiki 等 MCP 全部不暴露
|
||||
---
|
||||
```
|
||||
|
||||
顺带的收益是把原来 主Agent派发子 Agent提示词里的大段稳定指令迁移到子 Agent 系统提示词里（更容易命中缓存），TL 的 派发提示词 从 10-15 行精简到 2 行动态内容。
|
||||
|
||||
同时可以按角色做模型分层路由：自动化测试、视觉还原对比 这类规则性强、推理要求低但轮次最多（修复循环）的角色换成 GLM-5v（智谱 GLM-5V 多模态模型，成本约 Sonnet 的 36%），成本节省随修复轮次倍增，测试/视觉 Agent 成本 -64%。
|
||||
|
||||
##### 3.2.3 代码图谱替代盲搜
|
||||
|
||||
Agent 在编码阶段做的第一件事，往往是"理解项目结构"。传统方式是 search_content 关键词搜索：
|
||||
|
||||
```
|
||||
搜索 "UserService" → 返回 20 个文件的匹配行
|
||||
搜索 "getUserById" → 返回 8 个文件的匹配行
|
||||
read_file UserService.java → 300 行进 context
|
||||
read_file UserController.java → 200 行进 context
|
||||
...
|
||||
```
|
||||
|
||||
每一次搜索返回的结果都会进入 context，大量无关匹配行随之带入。更糟的是，agent 往往需要多轮搜索才能逐渐定位——探索过程本身就是 token 消耗。
|
||||
|
||||
__代码图谱：一次查询直接定位__
|
||||
|
||||
后面我们的工作流中使用了 graphify 代码图谱，代码图谱使用AST和语义来给项目创建文件索引和依赖关系，在搜代码文件前先搜这个目录，锁定文件范围，再去read_file文件，能节省几十倍的token（官方预估数据）。
|
||||
|
||||
代码图谱的 token 节省不只体现在单次查询上，更重要的是减少了 Agent 的探索轮次。少一轮工具调用，就少一次 API 请求，就少一整个 context window 的 input token 计费。在修复循环场景下，这个收益会被轮次数放大。
|
||||
|
||||
__实测数据对比：__
|
||||
|
||||
我们在相同任务下分别测试了使用代码图谱和未使用代码图谱两种模式的 token 消耗：
|
||||
|
||||
| 指标 | 使用代码图谱 | 未使用代码图谱 | 差异 |
|
||||
| --- | --- | --- | --- |
|
||||
| 总计 | 676,987 | 875,352 | -22.7% |
|
||||
| 输入 token | 670,281 | 868,544 | -22.8% |
|
||||
| 缓存命中 | 609,903 | 820,175 | -25.6% |
|
||||
| 缓存未命中 | 60,378 | 48,369 | +24.8% |
|
||||
| 输出 token | 6,706 | 6,808 | -1.5% |
|
||||
| 缓存命中率 | 91.0% | 94.4% | -3.4pp |
|
||||
|
||||
关键发现：
|
||||
|
||||
1. 总 token 节省 22.7%——从 87.5 万降到 67.7 万，节省约 19.8 万 token
|
||||
2. 输入 token 是主要节省来源（-22.8%）——代码图谱减少了探索过程中带入 context 的冗余文件内容
|
||||
|
||||
__代码图谱使用小tips：__
|
||||
|
||||
1. 首先需要安装`graphify`
|
||||
|
||||
```
|
||||
uv tool install graphifyy
|
||||
```
|
||||
|
||||
2. 执行初始化
|
||||
|
||||
让graphify给你的代码仓库建立索引，大概需要几分钟的时间。初始化成功后，会生成一个graphify目录，
|
||||
|
||||
这个目录下面你只要提交4个文件就可以了，其他可以不用提交。
|
||||
|
||||
3. 增量更新
|
||||
|
||||
细心的同学可能会问了，那如果我的代码更新了怎么办？
|
||||
|
||||
你可以绑定Git Hook，graphify hook install一键绑定 post-commit + post-checkout，commit 后自动增量更新图谱、checkout 后自动切换分支图谱。
|
||||
|
||||
省时间技巧：直接丢github链接给AI，让AI帮你完成安装，git hook绑定等等。（ https://github.com/Graphify-Labs/graphify ）
|
||||
|
||||
4. 怎么用
|
||||
|
||||
直接告诉AI代码搜索请使用代码图谱graphify，就会自动触发
|
||||
|
||||
#### 3.3 减少重复的上下文
|
||||
|
||||
##### 3.3.1 稳定前缀设计
|
||||
|
||||
__KV Cache：为什么前缀稳定等于省钱？__
|
||||
|
||||
理解这个优化，需要先了解一点 Transformer 的底层机制。
|
||||
|
||||
LLM 处理每个 token 时，需要对它之前所有 token 做注意力计算（Attention），这个过程会产生两个中间矩阵：K（Key）和 V（Value），合称 KV Cache。KV 矩阵的计算量是 O(n²)——这是推理成本的主要来源。
|
||||
|
||||
Prompt Cache 的本质是：如果你本次请求的前缀和上次完全一致，服务商直接复用上次的 KV 矩阵，跳过重复计算，只收缓存读取的低价（约正常价格的 10%）。
|
||||
|
||||
我们发现 「派发子 Agent的提示词」里稳定指令和动态内容（技术方案文档）交错排列，导致前缀无法命中缓存，改法是把动态内容统一后置。
|
||||
|
||||
__主Agent自身还有个隐藏的前缀破坏者：__进度状态不断在会话里输出累积。原来每个阶段切换都要在对话里输出完整进度看板，堆积在历史里导致历史不能被压缩。改法是把进度状态外化到文件中：
|
||||
|
||||
主Agent每次被唤醒先 read_file 进度文件，而不是回放历史。阶段切换也改成单行输出（✅ Wave 1 完成 → Wave 2 🔄 已启动），额外收益是会话中断后可直接读文件恢复现场。
|
||||
|
||||
##### 3.3.2 避免重复加载 Skill
|
||||
|
||||
排查 「前端Agent」 的 context 膨胀时发现，"调用 知识沉淀Skill 加载项目上下文"这一步其实没必要——主Agent 做方案设计时已经加载过历史经验并写入了技术方案文档，
|
||||
|
||||
前端Agent 直接读文档就能拿到结论，不需要重新触发 use_skill 把 200 行 SKILL.md 再次加载进 context。信息应该在最上游收集一次，通过文档传递给下游，而不是让每个 Agent 各自重复获取。
|
||||
|
||||
##### 3.3.3 rtk 压缩 CLI 输出
|
||||
|
||||
git status、npm test、docker ps 这类命令的原始输出夹带大量噪音，在自动化测试的修复循环中反复出现。我们接入了 rtk——一个在命令执行前拦截、重写为压缩版本的开源 CLI 代理，官方实测降幅 60%-90%。
|
||||
|
||||
__接入时踩了两个坑：__
|
||||
|
||||
① 官方 --agent 不支持 CodeBuddy，改为用 CodeBuddy 的 PreToolUse Hook 机制自己实现等价拦截；
|
||||
|
||||
② rtk 输出字段是 updatedInput，CodeBuddy 要求的是 modifiedInput，字段名不一致会导致静默失效（不报错但不生效），需要写一个几行的转换脚本做字段名转换。
|
||||
|
||||
评估 rtk 效果时也踩了方法论的坑：最初想用"同一需求跑两遍完整工作流，rtk 开/关各一次"对比，但大模型的执行路径本身不确定（探索轮次、有没有踩坑重试都会波动），噪声比 rtk 本身的效果还大。
|
||||
|
||||
更可靠的方式是用 rtk gain 统计或直接命令行对比——因为 rtk 的压缩是纯文本过滤，跟大模型决策无关，100% 可复现：
|
||||
|
||||
幅度因命令而异（ps aux -98.9%，纯 git status 仅 -31%），不能拿"60%-90%"当固定值。全局配置一次（~/.codebuddy/settings.json），所有子 Agent 自动获得压缩效果。
|
||||
|
||||
##### 3.3.4 工具调用并行化
|
||||
|
||||
无依赖关系的多次工具调用如果串行执行，每一次调用都是一轮独立的 LLM 推理，前面所有轮次的历史都要跟着重新打包计费一遍——调用次数越多，滚雪球轮次越多。我们排查了两类典型的"本可并行却串行"场景：
|
||||
|
||||
```
|
||||
❌ 改前：TAPD 摘要获取 → 等结果 → 再发起 Figma 摘要获取 → 等结果
|
||||
两次子 Agent 调用互不依赖，却占用了 2 轮历史累积
|
||||
|
||||
✅ 改后：TAPD/Figma 若同时存在，同一轮消息内并行发起
|
||||
Task 工具同时传入两个 subagent_name 调用，一轮内拿到两份摘要
|
||||
```
|
||||
|
||||
TAPD 需求摘要和 Figma 设计稿摘要本身没有先后依赖，我们把 tapd-req-analyzer、figma-design-analyzer 的派发方式从"依次调用、等结果"改成"同一轮消息内并行发起"，两个子 Agent 各自跑完即销毁，主Agent 一轮就拿到两份摘要，比串行少一轮历史打包。
|
||||
|
||||
测试用例执行也是同理：自动化测试阶段原来是一条 spec 执行完再执行下一条，改法是让 Playwright CLI 一次接收多个 spec 文件、内置多 worker 并行跑（详见"CLI 替代 MCP"一节的批量执行方式），LLM 侧只需 1 次调用 + 1 次读汇总结果，不随用例数线性增加推理轮次。
|
||||
|
||||
__判断是否可并行的原则很简单：__两次调用之间没有数据依赖（后一次不需要前一次的输出作为输入）就应该并行，这类"沉默的串行"往往藏在最初写 prompt 时"想清楚一步再写下一步"的顺序思维里，需要专门排查才能发现。
|
||||
|
||||
### 四、效果与数据
|
||||
|
||||
#### 4.1 核心指标
|
||||
|
||||
| 维度 | 优化前 | 优化后 | 降幅 |
|
||||
| --- | --- | --- | --- |
|
||||
| 主Agent端到端 token | 708,783（17 轮） | 315,266（9 轮） | -55.5%，轮次 -47% |
|
||||
| 子 Agent 单轮固定开销 | 常见上几十万 token | 减少约 20,000 token | 视配置 |
|
||||
| 子 Agent 命令行输出 | 原始 CLI 输出 | rtk 压缩后 | -60%~90% |
|
||||
| 测试/视觉子 Agent 模型成本 | claude Sonnet 计价 | GLM-5v 计价 | -64% |
|
||||
|
||||
#### 4.2 分项收益汇总
|
||||
|
||||
| 优化项 | 所属原则 | 主要收益 |
|
||||
| --- | --- | --- |
|
||||
| 渐进式披露 | 看到需要的 | SKILL.md 体积 -35% |
|
||||
| 确定性操作由脚本执行 | 看到需要的 | 消除 Schema 开销，减少 LLM 推理轮次 |
|
||||
| MCP 数据获取子 Agent 化 | 看到需要的 | 单轮 input token -38.4% |
|
||||
| 长期记忆按需索引加载 | 看到需要的 | INDEX 先行筛选，避免全量文档常驻 |
|
||||
| 单 Agent 拆分为多 Agent | 减少无关 | 打开后续优化空间，分散滚雪球效应 |
|
||||
| Agent 专属配置 | 减少无关 | 测试/视觉 Agent 成本 -64% |
|
||||
| 代码图谱 | 减少无关 | 总 token -22.7% |
|
||||
| 稳定前缀设计 | 减少重复 | 提升缓存命中率 |
|
||||
| 避免重复加载 Skill | 减少重复 | 消除重复常驻的 SKILL.md 开销 |
|
||||
| rtk 压缩 CLI 输出 | 减少重复 | 命令行输出 -60%~90% |
|
||||
| 工具调用并行化 | 减少重复 | 无依赖调用合并为 1 轮，减少历史重复打包次数 |
|
||||
|
||||
全流程反推：以实测的 Wave 消耗分布为基准，代入各分项已验证的降幅区间反推，一个中型需求跑完全流程，token 成本大致能降低 50%~65%。
|
||||
|
||||
### 五、总结与展望
|
||||
|
||||
回顾整个实践过程，我们沉淀了以下几点核心经验：
|
||||
|
||||
1. 省 token 不等于功能降级——只是调整"何时加载""怎么表达"，没删任何功能，反而让工作流更清晰。
|
||||
2. 上游收集一次，通过文档传递——最贵的冗余是"每个 Agent 各自重新发现同一份信息"。
|
||||
3. 最省钱的调用是不调用——确定性操作用 CLI/数据预取解决，把 LLM 留给真正需要语义理解的地方。
|
||||
4. 能并行就不要串行——没有数据依赖的多次调用，合并到同一轮消息内发起，能省下的是历史被重复打包的那几轮，而不只是等待时间。
|
||||
|
||||
落地优先级：先做规模预判和 Agent 拆分（架构前提）→ 度量 + SKILL.md 重排 + 全局接入 rtk（一个下午见效）→ 条件内容移出 SKILL.md、状态外化、排查无依赖调用改并行（逐步推进）→ 代码图谱、CLI 替代 MCP、工具裁剪、子 Agent 化、长期记忆索引化（中长期系统性梳理）。
|
||||
|
||||
目前这套"三原则、十方向"的优化方法已在 tech-leader 工作流全面落地，后续我们将补齐严格的端到端 A/B 复核，并把方法论沉淀为可复用的 checklist，应用到团队内其他 Multi-Agent 工作流的成本治理中。
|
||||
|
||||
如果你的团队也在做类似的 token 成本优化，欢迎在评论区交流讨论 💬
|
||||
|
||||
__参考资料__
|
||||
|
||||
- How we built our multi-agent research system | Anthropic Engineering Blog
|
||||
- Improving token efficiency in GitHub Agentic Workflows | GitHub Blog
|
||||
- Agent Skill 规范、构建与设计模式 | 阿里技术
|
||||
- rtk-ai/rtk：CLI proxy that reduces LLM token consumption by 60-90% | GitHub
|
||||
@@ -0,0 +1,74 @@
|
||||
# 📊 文章摘要：靠这10个优化点，我们把Multi-Agent工作流成本降了50%以上
|
||||
|
||||
> **原文**：[2026-08-27_靠这10个优化点_我们把Multi-Agent工作流成本降了50_以上](./2026-08-27_靠这10个优化点_我们把Multi-Agent工作流成本降了50_以上.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/TIdXNlrcAOUZWVW1oWnnKQ
|
||||
> **来源**：微信公众平台（腾讯技术工程）
|
||||
> **作者**：腾讯程序员（lemonye）
|
||||
> **发布日期**：2026-08-27
|
||||
> **摘要日期**：2026-08-27
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **Token 成本治理** — Multi-Agent 工作流烧钱不可怕，可怕的是不知道烧在哪；先建度量拆解六类消耗来源，再按"只看需要的、减少无关的、减少重复的"三原则系统性压缩，降本 50%~65% 而不牺牲任何功能。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是腾讯团队对 tech-leader Harness 工作流（1 个 TL + 6 个子 Agent 驱动前后端全流程开发）的 token 成本优化实录。先以 AgentLens 度量平台把消耗拆解为六类来源（系统提示词、工具返回、文件信息、长期记忆、历史消息、用户提示词），发现大头在滚雪球式增长的历史消息与常驻的 Schema/payload。围绕三原则落地十个优化方向：渐进式披露、CLI 替代 MCP、MCP 数据获取子 Agent 化、长期记忆索引化、多 Agent 拆分、工具白名单+模型分层、代码图谱、稳定前缀、rtk 压缩、并行化。主 Agent 端到端 token 从 70.8 万降至 31.5 万（-55.5%）。价值在于全部优化项有实测数据、踩坑细节（rtk 字段名静默失效、评估方法论陷阱）如实披露；局限是"50%~65% 全流程降幅"是分项反推而非端到端 A/B 实测（作者自认待补）。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **没有度量就没有优化** — 先用 AgentLens 按 TraceId/SessionId 拆解消耗分布，再动手；六类来源中历史消息（append-only 滚雪球）与工具 Schema（40 工具 MCP 每轮 10-15KB）是被忽视的大头。 `[分类: 共识]`
|
||||
2. **渐进式披露：SKILL.md 只留骨架** — 条件性内容与步骤详情外移到 references/ 资源层按需读取；自动化测试 Skill 正文 -35%，即使装 20 个 Skill 初始加载也仅 1000-2000 token。 `[分类: 共识]`
|
||||
3. **能用 CLI 就不用 MCP** — 每次 MCP 调用是一次完整 LLM 推理轮次（决策+Schema+结果+处理四重开销）；Playwright MCP 换成 CLI 后，大模型只做"用例翻译为 spec"，执行交给脚本，可重跑可并行。 `[分类: 共识]`
|
||||
4. **MCP 原始 payload 子 Agent 化隔离** — TAPD/Figma 的几千字需求、上万行设计树 JSON 不能进入生命周期最长的 TL context；专属子 Agent 只返回结构化摘要，单轮 input token -38.4%。 `[分类: 共识]`
|
||||
5. **Agent 专属配置：工具白名单+模型分层** — frontmatter tools 字段裁剪不可见工具；规则性强、轮次最多的测试/视觉 Agent 换 GLM-5v（成本约 Sonnet 36%），成本 -64%。 `[分类: 共识]`
|
||||
6. **代码图谱替代盲搜** — graphify 用 AST+语义建索引，先锁文件范围再读文件；同任务实测总 token -22.7%，探索轮次减少使收益在修复循环中被放大。 `[分类: 共识]`
|
||||
7. **稳定前缀=缓存命中=省钱** — KV Cache 复用要求前缀完全一致，动态内容后置；进度状态外化到文件（唤醒先 read_file 而非回放历史），顺带获得断点恢复能力。 `[分类: 共识]`
|
||||
8. **最省钱的调用是不调用 + 能并行不串行** — 确定性操作交脚本；无数据依赖的调用合并到同一轮发起，省下的是历史被重复打包的轮次。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者默认：(1) token 成本是 Multi-Agent 工作流的主要矛盾（人力时间成本未纳入 ROI 对比）；(2) 分项实测降幅可以线性叠加反推全流程（各优化项之间可能存在收益重叠，如并行化与子 Agent 化均减少历史打包）；(3) 单次对比的数值（如 -22.7%、-38.4%）在任务分布变化后仍稳定。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
单项优化均有改造前后实测数据，可信度高；rtk 评估的方法论反思（大模型执行路径不确定导致 A/B 噪声大于效果，改用 100% 可复现的纯文本对比）体现严谨。但"全流程 50%~65%"确为反推值，端到端 A/B 复核作者自己承认待补齐，引用该数字时应标注。多 Agent 拆分"本身不省钱、收益在打开后续空间"的澄清诚实且重要。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论基于 CodeBuddy + AgentLens 内网生态，SGLang/Claude Code 等环境的度量工具不同需适配；S/M/L 规模预判的阈值依赖团队任务画像；模型分层引用的 GLM-5v 便宜 64% 的结论绑定了特定任务类型（规则性强的测试/视觉），不可外推到推理密集型角色。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "没有度量就没有优化。"
|
||||
|
||||
> "最省钱的调用是不调用——确定性操作用 CLI/数据预取解决，把 LLM 留给真正需要语义理解的地方。"
|
||||
|
||||
> "省 token 不等于功能降级——只是调整'何时加载''怎么表达'，没删任何功能，反而让工作流更清晰。"
|
||||
|
||||
> "上游收集一次，通过文档传递——最贵的冗余是'每个 Agent 各自重新发现同一份信息'。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：三原则十方向全部带实测数据与代码级细节（frontmatter 配置、rtk 字段名踩坑），可复现性强；六类消耗来源的拆解框架本身即是分析工具；落地优先级排序（一个下午见效项→逐步推进项→中长期项）极具操作性。
|
||||
|
||||
**不足**：全流程 50%~65% 降幅是反推而非端到端实测；部分数据为单次对比样本；强绑定 CodeBuddy/AgentLens 生态。
|
||||
|
||||
**适用场景**：任何 Multi-Agent/Harness 工作流上量后的成本治理；Skill 设计规范审查（渐进式披露检查）；Agent 架构评审（拆分时机、工具暴露面、模型路由）。
|
||||
|
||||
**关联建议**：与本院 tech 项目 Harness 工作流直接互证——渐进式披露与 skill 正文精简可立即用于 arno 系 skill 体检；与同批《对Loop Engineering的思考》的"预算思维"章节合并阅读（本文是其实测版）；与 2026-08-20《Skill 工程方法论》"Thin Harness, Fat Skills"互为表里：Skill 变厚的同时必须靠资源层分层控制常驻成本。
|
||||
Reference in New Issue
Block a user