这篇文章我按自己的理解重新梳理了整条演进线，并在每处关键决策后补上企业落地视角的解读。如果你正在做领域知识密集型的 Agent，或正被"Prompt 越写越长、效果越来越差"折磨，这篇值得细读。
做 Agent 的团队，几乎都走在同一条路上：先写一个大 Prompt → 出问题就打补丁 → Prompt 越写越长、互相矛盾 → 最后没人敢改。
技术团队最近复盘了一个更"高级"的踩坑版本：做的是一个面向本地生活业务的分析类 Skill，要让 AI 像资深分析师一样做经营诊断、归因拆解和趋势预测，覆盖几十个行业，每个行业有独立的经营框架和指标体系，复杂度远超一个 Prompt 能承载的范围。
他们绕过了"大 Prompt"的坑，却掉进了另一个坑：用软件工程思维做知识架构，结果过度工程化。
一个月，三次架构重构（V1 → V2 → V3），每次都是被真实问题逼出来的。这篇文章我按自己的理解重新梳理了整条演进线，并在每处关键决策后补上企业落地视角的解读。如果你正在做领域知识密集型的 Agent，或正被"Prompt 越写越长、效果越来越差"折磨，这篇值得细读。
一、先记住一句话：Skill 的上限不取决于模型，取决于知识架构
这是整篇文章的题眼，也是三次重构最终回到的原点：
Skill 的能力上限不取决于模型，取决于你喂给它的知识架构。
模型会持续进化，今天的 context 窗口限制，明天可能不再是瓶颈。但知识怎么组织、怎么路由、怎么更新，这些架构决策的价值不会因为模型变强而消失。就像一个资深分析师换了更强的电脑，分析质量不会因此提升，真正决定质量的是他脑子里的框架、方法和行业认知。
Skill 的知识架构，就是这个"脑子"。
二、V1：把微服务那套搬给 LLM，跑了不到两周就暴露三个结构性问题
面对"几十个行业 × 十几种分析方法 × 二十多种输出形式"的复杂度，团队很自然地借用了软件工程的经典范式，分层解耦，把 Skill 拆成三个独立知识池：
- K 池（Knowledge）：管业务知识。行业概览、规则口径、运营抓手、关键事件、外部因素，每个行业一个子目录，20+ 行业 ≈ 100+ 文件；
- A 池（Analysis）：管分析方法。问题定性 → 分析框架 → 归因方法，三层嵌套，20+ 方法 + 10+ 规则；
- E 池（Expression）：管输出。20+ 个模板，从日报、周报到诊断报告、决策备忘全覆盖。
层间用标准化接口契约通信：K 池组装知识包给 A 池，A 池产出分析结论包给 E 池。看起来架构清晰、职责分明，但这恰恰是把微服务范式错误地套在了 LLM 身上。
上线不到两周，三个结构性问题集中爆发：
1）上下文爆炸 + 知识碎片化。一个行业的知识被打散在 K 池的多个子目录，一次分析要跨三层拉十几个文件，context 直接装不下。根因是：LLM 需要在一个视野内看到连贯的行业知识才能准确推理，而 K/A/E 架构把它们分散在了几十个文件里，模型拼不起完整的上下文。
2）过度工程化。接口契约、版本解析器、schema 校验，这些在传统软件工程里都是好实践，但 LLM 不是微服务。它不需要序列化的数据包在层间传递，它需要的是在一个 context 里看到足够的信息做推理。
3）流水线假设不成立。K→A→E 假设信息单向流动，但真实的分析过程是交织的：分析到一半要补知识，输出时发现结论要修正。流水线切断了这种交互。
落地启示一：LLM 的知识组织范式和传统软件架构根本不同。传统软件追求模块化、接口标准化、关注点分离，这些原则在 LLM 场景下不是失效，而是需要重新定义"正确的分离方式"，分层的目的是让模型在需要时能拿到完整上下文，这和微服务"每个服务只看自己的数据"的理念正好相反。这个认知，直接逼出了 V2 的方向：知识收拢、按需加载、做减法。
三、V2：收拢 + 按需加载 + 做减法，路由层是真正的技术活
V2 围绕三条原则重构：
① 知识收拢。一个行业的知识不再分散到多个子目录，而是收拢到一个独立文件：业务模式、核心公式、经营框架、指标体系、诊断起点，一个文件看全貌。LLM 加载一个文件就能获得足够的行业上下文。
② 按需加载。启动时不把知识全量灌进 context，而是根据用户问题动态决定加载什么。简单的口径问题只加载行业文件；复杂的归因分析才追加分析框架和方法文件。简单问题轻装上阵，复杂问题按需扩展。
③ 做减法。砍掉接口契约、版本解析器、schema 校验这些工程设施。V1 的 100+ 个文件被重组为 40+ 个结构清晰的文件，工程复杂度大幅下降。
按需加载的前提是有一个可靠的路由机制，Skill 要先判断"用户在问什么"，再决定"加载什么知识"。入口文件从 V1 的"三层 orchestrator"变成单一路由入口，承担三级路由：
- 域路由：判断用户问的是哪个业务域（交易/商家/GMV → 商业域，搜索/推荐/DAU → 流量域）；
- 行业路由：域内映射到具体行业，靠关键词匹配 + 歧义消解，命中走行业文件，未命中走通用兜底；
- 问题分类："是什么"（知识类）、"为什么"（分析类）、"怎么做"（方法论类），决定加载哪些 reference 文件。
举例：用户问"某行业 XX 指标为什么降了"，三级路由依次命中业务域、具体行业、"分析类"问题，于是加载行业文件 + 分析框架 + 归因方法；而"XX 口径怎么定义的"只需加载行业文件。
路由层真正有技术含量的是歧义处理和兜底。几十个行业的关键词必然重叠，团队的策略是分级的：上下文有明确行业锚点 → 走行业路由；没有锚点但有职能关键词 → 走横向职能路由；仍判断不了 → 主动询问用户；完全没命中 → 加载通用兜底文件作答，保证不哑火。
本质上，路由层是在用路由逻辑换 context 效率，用少量路由 token，换取大幅减少无效知识加载，按需组合替代全量灌入。这是"token 经济性"的第一次体现，这个思想会贯穿全文。
V2 上线后，知识碎片化和 context 占用问题都解决了，分析质量明显提升。但只跑了一周，新问题就来了：重构的保质期比想象中短得多，行业文件越写越胖。
原因很直接：收拢意味着一个行业的所有知识都在一个文件里。经营框架是稳定的，核心公式是稳定的，但季度策略打法在变、竞争格局在变、运营抓手在变、关键事件在持续发生，这些内容不断追加进同一个文件，部分行业文件膨胀到数百行。维护者的痛苦非常具体：改一个运营策略要翻完整个文件；业务规划更新时不知道哪些该改哪些该保留；几十个行业逐个检查，效率极低。
落地启示二：收拢 ≠ 全塞一个文件。需要更精细的组织方式，这就是 V3 要解决的问题。
四、V3：按变更频率分层，写入效率和 token 效率可以兼得
仔细观察就会发现，行业知识不是铁板一块，它天然按变更频率分成两类：
|---------------------|--------------------------|
| 稳定知识（一两年才变） | 时效知识（每季度甚至每月都在变） |
| 经营框架、核心公式、指标定义、业务模式 | 策略打法、竞争格局、运营抓手、关键事件、口径规则 |
V2 把它们塞进同一个文件，带来两个实际代价：
- 更新时效内容时容易误改稳定内容：在几百行的文件里找某条策略，可能不小心改动旁边的经营框架定义；
- 文件膨胀看不过来：策略、竞争、事件、口径全堆在一起，哪些该改、哪些不该动靠人肉判断，几十个行业 × 每次更新，工作量指数级增长。
V3 的核心决策是按变更频率分层存储：
- 瘦行业文件（稳定层）：每个行业一个文件，只保留低频变更内容，精简到百行级，打开就是这个行业的全景概要，默认加载；
- 主题文件（时效层）：按知识主题（而非按行业）组织高频变更内容，所有行业的策略打法在一个主题文件里，所有行业的竞争格局在另一个里，每个主题文件内部按行业分段管理，按需加载对应段落。
三个直接收益：
1）写入效率：更新全部行业的季度策略，只需打开一个主题文件逐段修改，不用再翻几十个行业文件，一个文件改完所有行业；
2）维护清晰度：行业文件瘦身超过 60%，从 10,000+ 行压缩到 3,000+ 行，误改稳定内容的风险大幅下降；
3）生命周期独立：策略刷新只改主题文件，经营框架调整只改行业文件，互不干扰。
存储分了两层，加载策略也配套调整，关键设计在于"跨行业集中管理，按行业分段加载"：一个主题文件可能几千行，但单次请求时路由层只加载目标行业的那一段，token 消耗控制在几百以内。
落地启示三：写入和读取的最优粒度不一样。维护者的视角是"一个文件改完所有行业"（写入效率），LLM 的视角是"只看一个行业的段落"（token 效率），同一个物理文件，通过分段加载策略同时满足两边。这个"读写分离"的思路，值得所有做知识库的人抄作业。
更普适的原则是：变更频率不同的内容混在一起，维护成本会指数级增长。无论分析类、客服类还是运营类 Skill，只要涉及领域知识，就一定存在稳定知识与时效知识之分。分开管理，是控制长期维护成本的关键。
五、方法与表达层：给 LLM 的架构做减法
路由层和知识层解决"知识怎么组织和调度"，接下来是另两个问题：分析方法怎么结构化、输出怎么标准化。
方法层：20+ 个方法砍到 9 个
V1 的 A 池有 20+ 个分析方法和 10+ 个规则，E 池有 20+ 个输出模板。看似完备，实际暴露三个问题：方法之间边界模糊导致路由错误频发（"结构变化"该用分层还是结构迁移？"趋势下滑"该用趋势分析还是异常检测？）；模板之间大量重复内容（置信度声明、caveat 规范几乎个个都写一遍，改一处要改 20 多处）；以及最本质的，选项多不等于能力强，选项多只会增加决策错误的概率。对 LLM 尤其如此：每一次选择都在消耗推理能力，选项越多，留给真正分析的推理资源越少。
这和给用户设计 UI 是同一个道理。
V2 把 20+ 个方法压缩到 9 个，做了三件事：
- 合并同类项：DID、RDD、PSM、合成控制法，对 LLM 来说都是"归因问题"的不同手段，合并为一个大类的子场景。模型先判断大类，再在内部选具体方法，一级决策的选项从 20+ 降到 9 个；
- 建立路由优先级：9 个方法有标准顺序（异常检测 → 归因 → 趋势 → 预测），LLM 顺着优先级走，遇到匹配信号就停，不做全局选择题；
- 后置触发机制：在分析框架的知识文件里预埋触发标记。模型分析到某个维度、发现特定模式时（比如"供给数量上升但单位产出下降"，典型的结构迁移信号），触发标记指示它按需加载对应方法文件。决策点从"分析前选方法"变成"分析中遇到问题再加载"。
从 token 经济性看，20+ 个方法文件全量预加载 vs 9 个方法按信号触发按需加载，token 占用差的是数量级。
减少选项是第一步，消除选项之间的歧义是第二步。压缩到 9 个方法后，关键词仍有重叠，团队为每对易混淆方法设计了消解规则，比如"结构变化"：关注"结构占比变化对总指标的影响" → 结构迁移分析；关注"哪些个体/群组贡献最大" → 分层分析；两个信号同时命中时默认走结构迁移（更聚焦因果归因），分析中按需追加分层。
做过 NLU 意图识别的同学会有共鸣：意图数量越少不一定越好，意图之间的边界越清晰才越好。
表达层：20+ 个模板收敛为 4 类框架
输出层面，V1 的 20+ 个模板被压缩为 4 类输出框架：监控 / 诊断 / 预测 / 汇报。设计思路是"约束结构，释放内容"：
- 只定义一级骨架，二级让模型自由发挥。诊断类输出的一级骨架固定：诊断结论 → 定位路径 → 归因分析 → 建议行动；但每步的具体表述、数据呈现、详略程度由模型按具体问题组织。比 20+ 个刚性模板灵活，比完全不限制可控；
- 通用规则抽取。置信度声明、数据约束说明、受众适配规则，从每个模板的重复段落中抽出来只写一次，全局共享，改一处全生效；
- 受众适配内置。一套框架覆盖所有受众：给高管看结论和数字，给中层看趋势和行动项，给执行者看操作细节。
为什么不用 few-shot 示例？团队试过，效果不好，模型会过拟合到示例的表面形式：用词、句式、段落长度都在模仿示例，而不是学到结构约束。换个行业、换种问题类型，输出又开始跑偏。"约束骨架但不约束填充内容"的框架式设计比 few-shot 稳定得多：它告诉模型"必须有哪些部分"，但不规定"每个部分怎么写"。
方法层和表达层的共同教训，是一组"反直觉"的经验：
Skill 架构设计，是找到"最少的约束产生最稳定的输出"的那个平衡点。给 LLM 的架构要做减法，给 LLM 的知识要做加法。
六、知识会腐烂：把知识管理当代码 CI/CD 来做
搭建完成只是起点。V3 刚稳定下来，团队就碰到了传统软件不存在的问题：知识腐烂（Knowledge Decay）。
代码的逻辑不会自己变，但业务知识会：口径变更、组织调整、策略刷新、竞争格局变化、行业政策出台。没有系统化的更新机制，Skill 的输出质量会随时间持续下降。
这比"功能不够"更致命。功能不够，用户会反馈"能不能支持 XX"；知识过时，用户看到的是"分析结论不对""口径对不上""策略建议和现在的打法矛盾"，但他们不会告诉你原因是知识过时了，他们只会默默离开，不再使用。
机制一：评测驱动的更新闭环（五步）
核心思路是把知识管理当代码管理来做：
- 评测（Eval）：定期用标准化测试题集验证输出质量，覆盖各行业、各问题类型、各分析场景，产出结构化的差距清单；
- 诊断（Diagnose）：不是"哪里错了改哪里"，而是结构化分析，这个错误属于哪个知识模块？影响范围多大？优先级如何？预期修复能提多少分？
- 登记（Register）：最容易被忽略但最关键的一步。改知识之前先登记变更事实：旧值是什么、新值是什么、在哪些文件出现过。因为同一个业务事实可能被多个文件引用，只改一处漏两处，Skill 内部就会版本不一致，这对分析类 Skill 是致命的；
- 修改 + 校验（Review）：执行修改后跑校验脚本，扫描所有知识文件，检查旧值是否清除、新值是否到位、有无禁用表述残留。零错误才允许提交；
- 复测（Re-eval）：跑同一套评测题验证分数提升，没提升或出现回归就回到步骤 2 重新诊断。
一句话：知识更新是一个有登记、有校验、有复测的工程流程，不只是"打开文件改一下"。它和代码的 CI/CD 是同一个思路，只是被管理的对象从代码变成了知识。
机制二：反馈自演进（静默采集 → 候选区晋升 → 固化入库）
评测驱动是"维护者主动巡检"，另一类信号来自用户使用中的隐式反馈：
- 采集：对话中自动识别多种信号，用户纠错（"不对，应该是 XX"）、追问补充（"你漏了 XX"）、重复提问（换说法再问一遍）、放弃对话。全程静默，用户无感知；
- 候选区晋升：反馈不会立即生效，单次反馈可能是个例，用户可能记错，问题可能有特殊上下文。先进候选区观察，同一类反馈被多次确认后才晋升到正式区，开始影响 Skill 行为；
- 固化到知识库：命中次数足够高的反馈，最终从运行时记忆固化到正式知识文件，成为永久知识，而非会话级记忆。
这套机制有一个重要设计约束：弱模型友好。采集时的信号识别、去重判断、晋升决策，全部用关键词匹配和规则判断实现，不依赖 LLM 的语义理解。为什么？因为反馈机制本身运行在 LLM 的 context 里，如果它消耗太多推理能力做语义分析，就是在和主任务抢资源。反馈机制应该是轻量级的后台进程，不是另一个推理任务。
两套机制解决的是同一个问题，让知识保鲜：评测闭环是定期体检，系统化、全面、但有时滞；反馈自演进是日常免疫系统，实时、精准、但覆盖有限。两者互补，缺一不可。
落地启示四：大部分 Skill 的失败不是因为架构不好，而是因为上线三个月后知识过时了，既没人定期评测，也没有机制从用户行为中捕获退化信号。生命周期管理，是 Skill 从"一次性交付"变成"持续运转的系统"的关键一步。这也是企业级 Agent 项目和个人 demo 的分水岭。
七、六条设计原则（建议收藏）
从三次重构中提炼出的六条 Skill 架构设计原则：
原则一：收拢优于碎片化。一个分析场景需要的知识应收拢到尽量少的文件中。LLM 需要连贯的上下文做推理，不是碎片化的数据包拼装。
原则二：按变更频率分层。半年不变的知识和每月都在变的知识不要放在一起。变更频率不同的内容混合存储，维护成本指数级增长。
原则三：选项少、信号强。路由选择、方法选择、输出选择都要做减法。每一步决策都应该是低歧义的，选项越少，模型选对的概率越高。
原则四：约束结构，释放内容。定义骨架让模型填充，比穷举模板更稳定也更灵活。告诉模型"必须有哪些部分"，不告诉它"每个部分怎么写"。
原则五：知识保鲜靠机制不靠人。评测、登记、校验、复测，没有更新机制的知识是有保质期的。
原则六：Token 经济性是架构的硬约束。每一个设计决策都要回答"这会消耗多少 context 窗口"。收拢是为了减少跨文件加载的 token 开销，按需加载是为了只占用必要 token，主题文件按行业分段而非全量加载是为了精确控制 token 粒度。Skill 架构的本质，是在有限的 token 预算内最大化知识密度。
八、写在最后
一个月，三次重构，四次认知升级，这个节奏在传统软件开发中并不常见，但在 Skill 搭建中可能会成为常态。因为你的"需求方"是 LLM 的行为模式，而你对 LLM 行为模式的理解，只有在实际运行中才能快速校准。
截至目前，这套 Skill 覆盖 20+ 个行业，内置 9 种标准分析方法（归因、趋势、预测、异常检测、分层、漏斗、结构迁移、影响模拟、A/B 实验），支持 4 类输出框架，知识更新闭环已经跑通。值得一提的是，搭建过程本身也大量借助了 AI Coding 工具，知识迁移、文件重构、校验脚本、评测执行，一个月内完成三次重构、近万行知识重建，没有 AI 辅助很难做到。
团队也坦承了三个待解问题：评测体系覆盖面还不够（低频场景用例很薄）、反馈自演进的数据积累还在早期、跨 Skill 的知识共享底座还没建好。
回到开头的命题：模型会持续变强，但"知识怎么组织、怎么路由、怎么更新"的架构决策不会因此贬值。一个资深分析师换更强的电脑，分析质量不会提升，真正决定质量的，是他脑子里的框架、方法和行业认知。
Skill 的知识架构就是这个"脑子"。
架构决定上限。这套范式不只适用于分析类 Skill，任何需要领域知识驱动的 Agent，都面临同样的问题。
责任编辑：庞桂玉来源： 玄姐聊AGI