面向复杂业务场景的智能分析 Skills 架构设计与演进实践

📌 一句话摘要

本文复盘了面向本地生活业务的智能分析 Skill 在搭建过程中的三次架构重构，从 V1 的软件工程式分层解耦到 V2 的知识收拢与按需加载，再到 V3 的稳定/时效知识分离与方法/表达层做减法，最终提炼出六条 Skill 架构设计原则。

📝 详细摘要

文章完整记录了阿里技术团队在搭建面向本地生活业务的智能分析 Skill 时经历的 V1→V2→V3 三次架构演进。V1 借用软件工程的分层解耦思路却导致上下文碎片化与过度工程化；V2 转向知识收拢（行业知识合并为一个文件）与按需加载（通过三层路由动态决定加载哪些知识），但行业文件迅速膨胀；V3 按变更频率将行业知识分为稳定层（经营框架等）和时效层（策略、竞争格局等），配合分发加载策略，同时在大幅精简方法（20+→9）和输出模板（20+→4 类框架）后设计信号消解规则与受众适配内置。文章还讨论了知识生命周期管理，包括评测驱动的更新闭环和基于隐式反馈的自演进机制，并总结了「收拢优于碎片化」「按变更频率分层」「选项少、信号强」「约束结构，释放内容」「知识保鲜靠机制不靠人」「Token 经济性是架构的硬约束」六条原则。全文基于真实项目经验，案例翔实、逻辑清晰、可迁移性高。

💡 主要观点

- V1 用软件工程分层解耦思路设计 Skill 导致上下文碎片化与流水线假设不成立。 将知识分成 K/A/E 三层并通过接口契约传递，使 LLM 无法在一个连贯上下文中看到完整知识，且分析过程本应是交织的，单向流水线不合理。

V2 通过知识收拢和按需加载解决了碎片化与 context 问题，但行业文件越写越胖。 每个行业知识收拢到一个文件，路由层根据问题类型动态加载知识，但稳定知识和时效知识混在一起导致文件膨胀，维护成本指数增长。

V3 按变更频率将知识分为稳定层和时效层，同时配套分段加载策略。 低频变更的经营框架等放入瘦行业文件，高频变更的策略竞争等按主题组织文件；写入时一个主题文件改所有行业，读取时只加载目标行业段落，兼顾维护效率与 token 效率。

方法层与表达层需要大幅做减法：减少 LLM 的选项以降低决策噪声。 方法从 20+ 压缩到 9 个，并建立优先级路由与后置触发；输出模板从 20+ 压缩到 4 类框架，只约束骨架，释放内容填充灵活性，比 few-shot 更稳定。

知识保鲜必须靠系统化机制而非人力，评测闭环与反馈自演进互补。 设计评测→诊断→登记→修改→复测的更新流程，将知识管理当作代码管理；同时通过静默反馈采集确认后固化到知识库，实现持续改进。

💬 文章金句

- 给 LLM 的架构要做减法，给 LLM 的知识要做加法。

• Token 经济性是架构的硬约束。
• 知识保鲜靠机制不靠人。
• 架构决定上限。

📊 文章信息

AI 初评：91

精选文章：是

来源：阿里技术

作者：阿里技术

分类：人工智能

语言：中文

阅读时间：34 分钟

字数：8455

标签： AI Agent, LLM, 知识管理, 路由设计, 工程实践

阅读完整文章