这篇文章我按自己的理解重新梳理了整条演进线并在每处关键决策后补上企业落地视角的解读。如果你正在做领域知识密集型的 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