知识库

Eye(FR) → Mill(skill) → Library(/app)

← 返回列表
BestBlogs.dev - 精选文章 · 2026-07-17 · 待补写

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

结合的源文章

主源
面向复杂业务场景的智能分析 Skills 架构设计与演进实践
打开原文 ↗

原文快照

展开 / 收起快照

📌 一句话摘要

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

📝 详细摘要

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

💡 主要观点

  1. V1 用软件工程分层解耦思路设计 Skill 导致上下文碎片化与流水线假设不成立。 将知识分成 K/A/E 三层并通过接口契约传递,使 LLM 无法在一个连贯上下文中看到完整知识,且分析过程本应是交织的,单向流水线不合理。
  2. V2 通过知识收拢和按需加载解决了碎片化与 context 问题,但行业文件越写越胖。 每个行业知识收拢到一个文件,路由层根据问题类型动态加载知识,但稳定知识和时效知识混在一起导致文件膨胀,维护成本指数增长。
  3. V3 按变更频率将知识分为稳定层和时效层,同时配套分段加载策略。 低频变更的经营框架等放入瘦行业文件,高频变更的策略竞争等按主题组织文件;写入时一个主题文件改所有行业,读取时只加载目标行业段落,兼顾维护效率与 token 效率。
  4. 方法层与表达层需要大幅做减法:减少 LLM 的选项以降低决策噪声。 方法从 20+ 压缩到 9 个,并建立优先级路由与后置触发;输出模板从 20+ 压缩到 4 类框架,只约束骨架,释放内容填充灵活性,比 few-shot 更稳定。
  5. 知识保鲜必须靠系统化机制而非人力,评测闭环与反馈自演进互补。 设计评测→诊断→登记→修改→复测的更新流程,将知识管理当作代码管理;同时通过静默反馈采集确认后固化到知识库,实现持续改进。

💬 文章金句

  • 给 LLM 的架构要做减法,给 LLM 的知识要做加法。
  • Token 经济性是架构的硬约束。
  • 知识保鲜靠机制不靠人。
  • 架构决定上限。

📊 文章信息

AI 初评:91
精选文章:
来源:阿里技术
作者:阿里技术
分类:人工智能
语言:中文
阅读时间:34 分钟
字数:8455
标签: AI Agent, LLM, 知识管理, 路由设计, 工程实践