这篇学完你能回答什么
- Agent 每轮都调大模型，太贵太慢，成本和延迟怎么优化？
- Agent Skills 是什么？和把说明全写进 system prompt 有什么区别？渐进式披露解决什么？
- 账单突然涨了 3 倍，你的排查顺序是什么？
从一个真实故障讲起
一个运营助手 Agent，月账单从 ¥1.8 万涨到 ¥5.6 万。业务量（会话数）几乎没变。
财务来问的时候，团队第一反应是"模型涨价了吧"——没有。第二反应是"用户用得更多了"——会话数只涨了 4%。
拉了两周的 trace 做归因，三个因素叠加，每一个单独看都不起眼：
| 变化 | 影响 |
|---|---|
| 上季度陆续加了 3 个新工具（共 11 个），工具定义总长从 1,800 → 4,100 token | 每轮固定开销 +2,300 token，而 Agent 平均跑 7 轮 |
| 有人在 system prompt 顶部加了一行"当前时间：{now}" | prompt 缓存命中率从 78% 掉到 19%——前缀每分钟都在变 |
| 新增了一个"知识库使用说明"文档，全量写进 system prompt（约 6,000 token） | 每轮都付，但实际只有约 12% 的会话真正用到它 |
三项合计，单会话平均输入 token 涨了 2.8 倍。没有任何一次代码改动看起来像是"性能问题"，但它们的乘积就是账单。
修复动作也很朴素：动态时间戳从前缀挪到最后一条用户消息里（缓存命中率回到 74%）；工具按域分组、常驻只留 6 个；那份 6000 token 的使用说明改成按需加载。一个月后账单回到 ¥2.1 万。
这个故障浓缩了 Agent 成本的全部特征：它不是被某一个大动作花掉的，是被每一轮的固定开销乘出来的。
月账单 1.8 万 → 5.6 万
业务量几乎没变，会话数只涨 4%
先怀疑模型涨价
没有涨价，也不是用户用得更多
拉两周 trace 归因
三个改动叠在一起，单看都不起眼
每轮固定开销被乘了 7 遍断点
工具 +2,300、说明 6,000、缓存跌到 19%
单会话输入涨 2.8 倍
没有一次改动像是性能问题
核心概念：先打比方，再给定义
比喻：Agent 的成本像"每天上班都把整个书架背在身上"。
书架里有 90% 的书今天用不到，但你每走一步都在扛着它们的重量。优化的第一原则不是走得少一点，而是别背用不到的书。
成本公式（这是回答 Q3-23 的骨架）：
单任务成本 ≈ Σ (第 i 轮的输入 token × 输入单价 + 输出 token × 输出单价)
↑
第 i 轮输入 ≈ 固定前缀（system + 工具定义 + skills 说明）
+ 前 i-1 轮的全部对话与工具返回
⇒ 成本随轮数 **超线性** 增长；固定前缀被乘以轮数由此得出优化的优先级顺序（顺序本身就是考点）：
① 减少轮数 ← 杠杆最大，一次省的是"所有后续轮的重复开销" ② 稳定前缀提升缓存 ← 见效最快、改动最小 ③ 裁剪每轮输入 ← 渐进式披露 / 工具返回裁剪 / 压缩 ④ 模型分级路由 ← 有效但要谨慎，质量风险最大 ⑤ 换更便宜的模型 ← 最后考虑，且必须先有评测集
很多人上来就答"换小模型"，那是清单上最后一项。 先讲结构再讲手段，是这题最有效的答法。
书架里 90% 的书今天用不到
但你每走一步，都在扛着它们的重量
system + 工具定义 + skills 说明
单任务成本 ≈ Σ(输入 token × 输入单价 + 输出 token × 输出单价)，第 i 轮输入 = 固定前缀 + 前 i-1 轮的全部对话与工具返回
不是走得少一点，是少背一点
那份 6,000 token 的说明，约 88% 的会话是白背的
把加载时机变成架构变量
先只广告 name + description，任务匹配上了才读完整 SKILL.md
原理拆解
- 减少轮数合并高频调用序列、开场一次给足信息
- 稳定前缀吃缓存变的东西一律往后放，见效最快
- 裁剪每轮输入工具返回裁剪分页、压缩、渐进式披露
- 模型分级路由编排、分类、摘要给小模型；关键判断给大模型
- 换更便宜的模型最后才考虑，且必须先有评测集
| 固定前缀里的一项 | 一轮 | × 7 轮 | 读法 |
|---|---|---|---|
| 新加 3 个工具的定义 | +2,300 token | +16,100 token | 工具定义从 1,800 涨到 4,100 |
| 那份知识库使用说明 | 6,000 token | 42,000 token | 约 88% 的会话完全用不上 |
| 顶上那行「当前时间」 | 只多了一行文字 | 缓存 78% → 19% | 前缀每分钟都在变，逐字节对不上 |
「变的东西一律往后放」：[system 指令] → [工具定义] → [skills 说明] → [对话历史] → [当前时间/动态]。缓存的前提是前缀逐字节相同，一个动态时间戳就足以打穿它。
压缩也会打穿缓存（T3-6）：压得太勤，省下的历史 token 未必赔得起丢掉的缓存折扣，所以压缩频率要和缓存收益放在一起算。
四类杠杆
① 减少轮数——省的是复利
一轮 = 一次完整的输入重发。少一轮，省的不只是那一轮，还有它之后每一轮都要重发的那部分内容。
- 工具设计：一个
search_orders(user_id, status, date_range)顶三次"先查用户→再查订单→再过滤"。合并高频调用序列是最直接的减轮手段（T3-2）。 - 一次给足信息：把常用的上下文（当前用户、时区、权限范围）在开场就注入，别让模型花一轮去问或去查。
- 并行工具调用：不减 token，但减墙钟时间（延迟优化，非成本优化）。
- 该用 workflow 就用 workflow：路径固定的部分不要交给模型现场决策（T3-1）——这是最大的一笔省。
② 稳定前缀，吃满缓存
prompt 缓存的前提是前缀逐字节相同。Agent 场景天然适合缓存（每轮都重发前面所有内容），但也天然容易被破坏：
坏结构 好结构
[当前时间 2026-08-19 14:23:07] [system 指令] ← 稳定
[system 指令] [工具定义] ← 稳定
[工具定义] [skills 说明] ← 稳定
[对话历史] [对话历史] ← 增量追加
[当前时间/动态] ← 放最后路由决策（小模型或规则）→ 简单意图 → 小模型
→ 复杂推理 → 大模型
编排器 / 分类 / 摘要 → 小模型
最终综合 / 关键判断 → 大模型真实收益不小，但风险也最高：路由判断本身可能出错，且错误是隐性的（小模型给出一个看起来合理的错答案）。上线前必须有评测集验证"降级后的质量差多少"，并留人工升级通道。
Agent Skills 与渐进式披露
问题：你想让 Agent 会做 30 种专项任务（写周报、处理退款、生成 SQL、审合同……），每种都有几百到几千字的操作规范。全写进 system prompt，等于每一轮都为 30 种任务付费，而单次会话通常只用到其中 1 种。
Agent Skills 的答案：把程序性知识（怎么做）封装成标准化的文件夹，按需分级加载。
skills/
expense-report/
SKILL.md ← 必需：frontmatter（name + description）+ 正文指令
references/ ← 可选：详细参考资料，用到才读
edge-cases.md
scripts/ ← 可选：可执行脚本
validate.py渐进式披露（Progressive Disclosure）的分级加载：
第 1 级 · 广告（Advertise） 每个 skill 只把 name + description 注入 system prompt
← 量级约 100 token / skill。30 个 skill ≈ 3k token 常驻
模型只知道"有什么"，不知道"怎么做"
第 2 级 · 加载（Load） 任务匹配到某个 skill 时，才读取完整 SKILL.md 正文
← 建议控制在 5,000 token 以内；SKILL.md 建议 500 行以内
第 3 级 · 读资源（Resources） 需要细节时，再按需读 references/ 下的文件
第 4 级 · 执行（Scripts） 需要确定性时，直接跑脚本，而不是让模型模拟和"全写进 system prompt"的差别，本质是加载时机：
| 全写进 system prompt | Agent Skills | |
|---|---|---|
| 常驻开销 | 30 × 完整规范 ≈ 数万 token，每轮都付 | 30 × 约 100 token ≈ 3k token |
| 注意力 | 大量无关内容稀释注意力（context rot） | 只有当前任务相关的内容在场 |
| 维护 | 一个巨型 prompt，改一处影响全部 | 每个 skill 独立文件，可分权维护、可版本化 |
| 触发准确性 | 靠模型在长文里自己找 | 靠 description 写得好不好（新的失败点） |
和 MCP 的区别（这是 Q3-24 的高频追问）：
MCP 给的是"手"（能做什么，工具接入），Skills 给的是"操作手册"（怎么做，程序性知识）。 一个是能力接入协议，一个是知识组织格式。它们互补：skill 的正文里完全可以指导模型去调用某个 MCP 工具。
生态现状（截至 2026-08）：Agent Skills 由 Anthropic 于 2025 年 10 月推出，同年 12 月作为开放标准发布；到 2026 年年中，已有数十个兼容产品（含多家主流编码工具），社区目录规模极大——但规模不等于质量：有第三方对四万余个公开 skill 做过质量评估，平均分并不高；而经过筛选的高质量 skill 能把 Agent 任务通过率提升十几个百分点。结论是"用精选的、自己写的少量 skill"，而不是装一堆。
工程实践（截至 2026-08）
账单暴涨的排查顺序（可直接用于 Q6-09 类排障题）
1. 先归因到"量"还是"价"：会话数变了吗？单会话成本变了吗？
2. 单会话成本涨 → 拆成 轮数 × 每轮输入
├─ 轮数涨了？ → 看步数分布 P50/P90，找是不是新增了重试/死循环/工具变难用
└─ 每轮输入涨了？→ 拆固定前缀 vs 历史累积
├─ 固定前缀涨 → 新加的工具/skills/说明文档
└─ 缓存命中率跌 → 前缀里混进了动态内容（时间戳、随机 ID、变动的工具顺序）
3. 检查压缩策略：是不是压得太频繁，反复打穿缓存
4. 最后才看模型档位和单价"先看缓存命中率"是这道题最实用的一条经验——它是唯一一个"改一行代码可能省一半钱"的地方。
参数经验值（起步值，务必自测）
- 常驻工具数：≤ 15～20（T3-2）；超了用分组或 skill 化按需加载。
- skill 的 description：一两句话，写清什么时候该用我（触发全靠它）。
- SKILL.md 正文：控制在数千 token / 500 行以内，细节下沉到 references。
- 缓存命中率：Agent 场景做得好可以到 70%+，低于 50% 一定有前缀被污染。
- 模型路由的降级比例：先从"明确简单"的窄口径开始（比如纯格式转换），别一上来路由 50% 流量。
延迟优化（和成本优化不完全同向）
- 并行工具调用：减墙钟时间，不减 token。
- 流式输出：不减总时长，但大幅改善感知延迟——对话式 Agent 必做。
- 预热/预取：开场就并发取用户画像、权限等必然要用的信息。
- 推理档位调节：需要深思的步骤给高档位，格式化输出给低档位。
- 注意：压缩是同步的，会在中途卡一下；把压缩安排在自然停顿处比在关键路径上好。
进阶技术三段式：渐进式披露
- 解决什么：把"知识必须常驻上下文"变成"知识按需加载"，让 Agent 能挂载远超上下文容量的专项知识，同时降低每轮固定开销并保护注意力。
- 代价是什么：① 多一次或多次加载往返，首次触发的延迟增加；② 触发准确性成为新的失败点——description 写不好，skill 永远不会被加载，且这种失败是静默的；③ 维护成本从"一个 prompt"变成"一个知识库"，需要版本、评审与测试；④ 供应链风险：外部 skill 里的指令会进入上下文，等同于工具描述投毒（T3-4），社区已有针对 skill 的注入攻击研究；⑤ 加载后的内容仍然占上下文，只是延后付费，不是免费。
- 什么时候不该用：只有两三种任务的小 Agent（直接写进 system prompt 更简单可控）；所有会话都会用到的核心指令（那本来就该常驻）；对首字延迟极敏感的交互；以及知识极不稳定、每次都要重新拉取的场景。
避坑清单
- 别把动态内容放前缀。这是最高频、代价最大的低级错误。
- 别为省钱牺牲可观测。省下来的钱不够一次线上事故的排查成本。
- 别在没有评测集时换小模型。你会用质量下降换来账单下降，而且不知道降了多少。
- skill 装得多不等于能力强。低质量 skill 会误触发，比没有更糟。
- skill 的 description 要当 prompt 来写，并纳入回归测试——它决定触发。
- 外部来源的 skill 要审，它的正文会进上下文。
- 优化前先量：没有步数分布、缓存命中率、单会话成本这三个指标，所有优化都是猜。
| 维度 | 全写进 system prompt | Agent Skills |
|---|---|---|
| 常驻开销本质差异 | 30 × 完整规范 ≈ 数万 token，每轮都付 | 30 × 约 100 token ≈ 3k token |
| 注意力 | 大量无关内容稀释注意力（context rot） | 只有当前任务相关的内容在场 |
| 维护 | 一个巨型 prompt，改一处影响全部 | 每个 skill 独立文件，可分权维护、可版本化 |
| 触发准确性 | 靠模型在长文里自己找 | 靠 description 写得好不好（新的失败点） |
- 四级披露
- 广告 ≈100 token/skill（30 个 ≈3k 常驻）→ 加载 SKILL.md → 读
references/→ 跑scripts/ - 写多长
- SKILL.md 控制在 5,000 token / 500 行以内，细节下沉到
references/ - description
- 一两句话写清什么时候该用我；触发全靠它，写不好就永远不被加载，且失败是静默的
- 常驻工具数
- ≤ 15～20 个（T3-2），超了就按域分组，或 skill 化按需加载
- 缓存命中率
- Agent 场景做得好能到 70%+，低于 50% 一定有前缀被污染
- 装一堆不等于强
- 有第三方评过四万余个公开 skill，平均分并不高；精选的能把通过率提十几个百分点
面试视角
- 先给公式和顺序固定前缀 × 轮数，再加反复重发的历史
- 解释减轮数为何最大省的是复利，不只是省掉的那一轮
- 缓存给可操作规则「变的东西一律往后放」，配前后命中率
- Skills 抓加载时机四级披露和各级 token 量级，别答成拆文件
- 用排查顺序收尾先量还是价 → 轮数 × 每轮输入 → 缓存 → 单价
- 一上来就说「换个便宜模型」或「加缓存」，没有结构
- 以为成本和轮数线性相关，不知道固定前缀被乘了 N 遍
- 从没量过缓存命中率
- 认为 Skills 就是「把 prompt 拆成文件」，或说它会取代 MCP
- 谈延迟只会说「用流式」
- 先给优先级顺序，并解释减轮数省的是复利
- 有完整排查顺序：先归因量或价，再拆轮数 × 每轮输入
- 说得出动态内容污染前缀，并报得出前后命中率数字
- Skills 落在加载时机上，也点出 description 决定触发且静默失败
- 区分两本账：并行调用减墙钟时间，不减 token
Q3-24 里主动交代外部 skill 的供应链风险，是很稀缺的一句。面试官怎么问
答题结构建议
- 先给成本公式和优先级顺序，说明为什么"换小模型"排在最后。
- 讲缓存时给"变的往后放"这条可操作规则，并配一个前后对比。
- 讲 Skills 时抓住"加载时机"这个本质差异，给出四级披露和 token 量级。
- 主动交代 Skills 的代价：触发准确性、首次延迟、供应链风险。
- 用排查顺序收尾：账单涨了先看量还是价、再拆轮数与每轮输入、再看缓存。
分水岭信号
只读过资料的回答：
- 一上来就说"换个便宜模型"或"加缓存"，没有结构。
- 不知道 Agent 成本是超线性的，以为和轮数线性相关。
- 从没量过缓存命中率。
- 认为 Skills 就是"把 prompt 拆成文件"。
- 认为 Skills 会取代 MCP，或说不清两者关系。
- 谈延迟只会说"用流式"。
真做过的回答：
- 给出优先级顺序并解释为什么减轮数杠杆最大（省的是复利）。
- 说得出动态内容污染前缀导致缓存失效这个具体坑，并能给出前后命中率数字。
- 区分成本优化与延迟优化不同向（并行调用减延迟不减成本）。
- Skills 的本质抓在加载时机上，能说出各级的 token 量级。
- 主动指出 description 决定触发、且失败是静默的——这是真用过才有的痛点。
- 提到 skill 供应链风险（外部 skill 的正文进上下文）。
- 提到压缩与缓存的相互作用：压得太勤反而更贵。
- 有完整的账单排查顺序，先归因量/价再拆结构。
小结与延伸
- Agent 成本是超线性的：固定前缀被乘以轮数，历史被反复重发。
- 优化优先级：减轮数 > 稳前缀吃缓存 > 裁剪每轮输入 > 分级路由 > 换模型。
- "变的东西往后放"是性价比最高的一条规则。
- Agent Skills 的本质是把加载时机变成架构变量：广告（~100 token）→ 加载（数千 token）→ 读资源 → 跑脚本。
- Skills 给操作手册，MCP 给手，两者互补。
- Skills 的新失败点是 description 写不好导致静默不触发，以及外部 skill 的供应链风险。
延伸：工具返回裁剪与工具数量控制见 T3-2；压缩与缓存的相互作用见 T3-6；成本指标怎么监控见 T3-11；更系统的成本治理（网关、语义缓存、模型路由）见模块 6。
模块 3（Agent 开发）教程部分到此完结：T3-1 边界 → T3-2 工具 → T3-3 循环 → T3-4 MCP → T3-5 A2A → T3-6 记忆 → T3-7 范式 → T3-8 多 Agent → T3-9 框架 → T3-10 护栏与 harness → T3-11 评测与 trace → T3-12 成本与 Skills。 建议的复习路径：先把 T3-1 的"控制权归属"和 T3-10 的"Agent = Model + Harness"两条主线串起来，其余十篇都可以挂在这两条线上。
继续深入
本篇归属第 3 章「Agent 开发」，去做这一章的题。