第十一篇：Skills 系统与成本分析 —— 从 Demo 到产品的最后一公里

技术架构的最终价值体现在两个数字上运营人员多快能上手、老板愿意付多少钱。Skills 系统两级拆分的真正逻辑每个工具对应一个skills/xxx/SKILL.mdYAML frontmatter名称、触发词、领域 Markdown 正文标准操作流程。启动时自动扫描加载 → P0 关键词自动抽取 → P1 向量索引自动构建。增加新业务品类的唯一工作量是创建一个新文件。但 Skill 一旦多起来50每次都把所有标准操作流程塞进 prompt 会爆炸。那要不要拆等等——这个问题的前提已经变了。回顾第二篇的意图识别流水线P0P1P2 将用户意图收敛到 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小模型对 P0P1 的候选结果做确认推理仅候选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 流程描述L1L2 两级就够了。如果单个 skill 流程极长数千 token可再加一层 L3L2 改为该 skill 的流程概要~200 tokensL3 为完整详情仅在执行器判断概要不够用时按需展开换句话说不是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仅增量电费自购 GPURTX 4090 ÷ 3年摊销 450W × 24h × ¥0.8/kWh~¥7,500租云 GPUAutoDL RTX 3090 按量计费~¥17,000租公有云阿里云/腾讯云 GPU 实例包月¥40,000-60,000计入 GPU 后工具选择方案对比日均 1万次请求回顾第二篇基准数据纯 LLM function calling 方案中qwen-turbo 年成本 ~¥2,400p50477msqwen-max 约 ¥21,000p50 ~700ms估。P0P1P2 流水线本身已将延迟砍到 ~25ms p50——本节聚焦不同 GPU 部署方式下 P0P1P2 方案的增量成本P0P1P2 部署方式年成本相比 qwen-turbo相比 qwen-max共享 GPU已有集群~¥2,500几乎持平省 88%自购 GPURTX 4090 ÷3年摊销~¥7,500贵 3×省 64%租云 GPUAutoDL 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 每百万 tokensqwen-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 都更便宜本地部署的真正卖点从来不是省钱而是p99 延迟可控云端 API 的 p99 延迟抖动500ms是本地 GPU 推理的 10 倍零 API 依赖不依赖外部服务不受限流、涨价、服务中断影响隐私合规敏感数据不出本地真正的省钱在语义缓存。Redis 向量相似度检索 0.85 直接返回缓存不走任何 LLM——用 BGE embedding 将用户问题向量化与历史缓存做匹配~10ms 返回结果——一个退货政策回答缓存命中一次就省 2000 input 100 output tokensqwen-turbo 约 ¥0.0007qwen-max 约 ¥0.006叠加推广期的重复咨询缓存命中率可达 30-40%。但语义缓存不是免费的午餐需要注意一致性风险——这些风险可能抵消节省的 Token甚至造成业务损失风险类型电商场景示例影响解决方案数据过期用户查订单后商家发货缓存返回旧状态用户看到过期信息动态数据订单、余额不缓存仅缓存静态知识政策变更退货政策更新但缓存返回旧政策引导用户执行失效流程政策更新时主动清除相关缓存设置短 TTL缓存污染恶意用户构造相似问题存入错误答案其他用户获取错误信息缓存键加入用户 ID设置内容校验机制/不缓存隐私泄露不同用户的相似问题命中同一缓存泄露他人订单信息缓存键必须包含用户标识禁止跨用户共享语义漂移苹果可能指水果或手机缓存返回错误领域答案回答质量下降结合意图识别结果作为缓存键的一部分一句话缓存适合静态知识退货政策、常见问题不适合动态数据订单状态、余额。未来三个方向多模态客服用户拍照上传 → OCR 图片理解主动服务物流异常主动通知、促销推送知识图谱自动补全LLM 商品数据自动抽取关系系列收尾回到第一篇的核心哲学完成闭环“用工程手段替代 LLM 调用——5ms 的规则能解决的问题不要花 500ms 去问 LLM。”客服Agent 不追求最新最热的 AI 技术而是追求在给定约束下最合理的工程决策。