技术架构的最终价值体现在两个数字上：运营人员多快能上手、老板愿意付多少钱。

Skills 系统：两级拆分的真正逻辑

每个工具对应一个 skills/xxx/SKILL.md，YAML frontmatter（名称、触发词、领域）+ Markdown 正文（标准操作流程）。启动时自动扫描加载 → P0 关键词自动抽取 → P1 向量索引自动构建。增加新业务品类的唯一工作量是创建一个新文件。

但 Skill 一旦多起来（50+），每次都把所有标准操作流程塞进 prompt 会爆炸。那要不要拆？

等等——这个问题的前提已经变了。

回顾第二篇的意图识别流水线：P0+P1+P2 将用户意图收敛到 1-2 个。而意图名对应Skill，所以无论注册了 5 个还是 50 个 skill，真正需要全文加载的 L2 详情永远只是那 1-2 个命中的。L2 不会爆炸。

那还拆什么？真正需要拆的是 L1——P0/P1/P2 是如何知道有 50 个 skill 的？

阶段	L1（简介）的用途	需要多少个？
启动时	从每个 SKILL.md 的 frontmatter 抽取 trigger_keywords → 构建 P0 关键词索引	全部
启动时	对每个 Skill 的描述做 Embedding → 构建 P1 向量索引	全部
运行时 P2	小模型对 P0+P1 的候选结果做确认推理	仅候选（1-2 个）
运行时 Executor	执行器 agent（如 GeneralAgent）拿到 tool result 后重新规划时，需要知道其他可用工具	需要全部 L1

关键在最后一行：执行器在拿到 tool result 后可能需要调用另一个工具（比如先查订单再计算退款金额），它需要知道还有什么工具可以选择。如果 L1 不存在或不全，执行器就只能盲操作。

所以两级拆分的真实逻辑是：

• L1（~50 tokens/Skill）：名称 + 关键词 + 一句话功能。必须始终内联——P0/P1 需要它构建索引，执行器 agent 需要它知道全部工具能力。50 个 skill 也只有 ~2500 tokens，在 8K+ 上下文中占比可控
• L2（完整流程）：仅在 P0/P1/P2 命中后才加载——这已经被流水线保证了，不管多少 skill。对常规 skill（几百 token 流程描述），L1+L2 两级就够了。如果单个 skill 流程极长（数千 token），可再加一层 L3：L2 改为该 skill 的流程概要（~200 tokens），L3 为完整详情，仅在执行器判断概要不够用时按需展开

换句话说：不是"L1 小所以省 token"，而是"L1 是 P0/P1 索引构建和执行器工具感知的必需品"。L2 的按需加载是 P0→P1→P2 流水线的自然结果，不需要额外的拆分机制。这套设计下，从 5 个 skill 到 50 个 skill，单次请求的 prompt 膨胀几乎为零——只差在 L1 那 50 tokens/skill 的简介增量。

---

一笔真实的账：GPU 不是免费空气

第六篇的结论是"本系统必须有一个 GPU"——那 GPU 的成本就必须计入总成本，否则账是虚的。

GPU 成本的三种形态：

部署方式	典型配置	年成本（估）
共享 GPU	公司已有 GPU 集群，本地模型蹭推理 slot	~¥2,500（仅增量电费）
自购 GPU	RTX 4090 ÷ 3年摊销 + 450W × 24h × ¥0.8/kWh	~¥7,500
租云 GPU	AutoDL RTX 3090 按量计费	~¥17,000
租公有云	阿里云/腾讯云 GPU 实例包月	¥40,000-60,000

计入 GPU 后，工具选择方案对比（日均 1万次请求）：

回顾第二篇基准数据：纯 LLM function calling 方案中，qwen-turbo 年成本 ~¥2,400（p50=477ms），qwen-max 约 ¥21,000（p50 ~700ms，估）。P0+P1+P2 流水线本身已将延迟砍到 ~25ms p50——本节聚焦不同 GPU 部署方式下 P0+P1+P2 方案的增量成本：

P0+P1+P2 部署方式	年成本	相比 qwen-turbo	相比 qwen-max
共享 GPU（已有集群）	~¥2,500	几乎持平	省 88%
自购 GPU（RTX 4090 ÷3年摊销）	~¥7,500	贵 3×	省 64%
租云 GPU（AutoDL RTX 3090 按量）	~¥17,000+	贵 7×	省 19%
租公有云（GPU 实例包月）	¥40,000-60,000	贵 17-25×	贵 2-3×

*API 成本按 qwen-turbo 实测 ~730 input + ~24 output tokens/次（500 次请求均值），qwen-turbo ¥0.3/¥0.6 每百万 tokens，qwen-max ¥2.4/¥9.6 每百万 tokens。qwen-max 为估算值——完整基准数据见第二篇。

结论：

• 共享 GPU：本地成本与 qwen-turbo 几乎持平（¥2,500 vs ¥2,400），但延迟优势巨大（25ms vs 477ms）→ 值得做
• 自购 GPU：比 qwen-turbo 贵，但比 qwen-max 便宜近 3 倍。如果原本要用 qwen-max 追求精度，自购 GPU 反而更省钱，还附带 25ms 延迟和零 API 依赖的红利
• 租 GPU：比 qwen-turbo 贵 7 倍，但比 qwen-max 便宜 → 仅适合对延迟有极端要求的场景

决策关键不是 DAU，而是"你原本的 LLM 预算基线是谁？"

• 基线是 qwen-turbo → 共享 GPU 才划算，自购/租 GPU 都不划算
• 基线是 qwen-max → 自购 GPU 甚至租 GPU 都更便宜

本地部署的真正卖点从来不是省钱，而是：

1. p99 延迟可控：云端 API 的 p99 延迟抖动（500ms+）是本地 GPU 推理的 10 倍
2. 零 API 依赖：不依赖外部服务，不受限流、涨价、服务中断影响
3. 隐私合规：敏感数据不出本地

真正的省钱在语义缓存。Redis 向量相似度检索 >0.85 直接返回缓存，不走任何 LLM——用 BGE embedding 将用户问题向量化，与历史缓存做匹配，~10ms 返回结果——一个退货政策回答缓存命中一次就省 2000 input + 100 output tokens（qwen-turbo 约 ¥0.0007，qwen-max 约 ¥0.006），叠加推广期的重复咨询，缓存命中率可达 30-40%。

---

未来三个方向

1. 多模态客服：用户拍照上传 → OCR + 图片理解
2. 主动服务：物流异常主动通知、促销推送
3. 知识图谱自动补全：LLM + 商品数据自动抽取关系

---

系列收尾

回到第一篇的核心哲学，完成闭环：

“用工程手段替代 LLM 调用——5ms 的规则能解决的问题，不要花 500ms 去问 LLM。”

客服Agent 不追求最新最热的 AI 技术，而是追求在给定约束下最合理的工程决策。