Meta 不重训模型，把专家经验变成可回滚的文件

专家最值钱的那部分判断，一直没被写下来

在合规这类领域，同一类问题会在数百次产品评审里反复出现。专家要花数天做人工研究才能给出结论，而两次评估之间还可能不一致——这种不一致本身就是组织风险。

真正的缺口不在文档数量。大型组织在专家日常工作的过程中会积累成千上万份文档，但最有价值的那部分知识是隐性的：专家怎么推理、优先看什么、在模糊地带怎么定夺。如果把这些文档直接当成组织知识，agent 每一次运行都要从原始材料里重新推导一遍这套推理，结果就是慢、易错、前后不一致。

于是问题可以收紧成一句话：一个组织的判断力，能不能被写成机器可以执行的东西，并且在专家纠正之后持续更新，而不是每次都回到模型训练上去？

Meta 工程团队给出的回答，是一个充当特定领域次级专家的 AI agent。它的任务不是替代专家，而是保存和共享组织内的专家知识，让同一类问题不必每次从头推一遍。

如果答案不在模型本身，那到底要动的是哪几样东西？

四层结构：知识与推理分开，评估守住每一次改动

Meta 给出的是一套四层结构，每层解决一个不同的问题：知识系统、推理层、评估框架，以及自我改进循环。四层不是并排的模块，而是彼此咬合。知识系统的文件结构让自动编辑成为可能；推理层把分析步骤显式写出来，失败才有办法归因到具体一层；评估框架守住每一次改动；改进循环再把结果反哺回知识和推理。任何一层拿掉，其余几层都会退化。

按 Meta 自己的说法，这套设计的新颖之处集中在两层的整合上。第一层是把「agent 知道什么」和「它怎么推理」分开的结构化、可审计知识架构；第二层是一条自我改进循环，它把专家反馈编译成经过验证、并且跑过回归测试的知识更新，而底层模型不需要重新训练。

这样设计有它的针对性。通用大模型在专业领域的问题通常不是不够聪明，而是缺少组织自己的上下文，因此分不清「组织可以做什么」和「组织应该考虑做什么」——后者依赖的是历史立场、公司方向和业务背景。在高风险场景里，这个差距只能靠把组织自己的知识和优先级喂给模型来补。

这套系统最初针对一个具体的合规领域构建。具体是哪一种合规子领域、覆盖了多少产品和团队，Meta 没有公开。

类比四层互相依赖像一条生产线上四个工位：前面的工位把零件摆整齐，后面的工位才有办法检查和返修，拆掉任何一个，整条线都跑不顺。

四层各自解决一个问题，也互相依赖

怎么读：层级按依赖关系自上而下排列：上面的层为下面的层提供条件，下层的产出反过来更新上层。

把知识写下来，具体写成什么形式？

200 多个文件：把组织的立场、词汇和路由都写成带依赖的文档

答案是一批结构化文件，而不是一堆原始文档。一个长跑的离线流程先阅读源材料，把它们蒸馏成策展式知识文件：组织如何解读自己领域的明确陈述，连同约束、边界条件，以及告诉推理层「什么时候该用这一条」的路由含义，都写成机器可读的形式。这类文件有 200 多个，按一套严格分类组织，其中包含四类：位置文件、术语与词汇文件、路由索引和网关文件。

位置文件记录组织的权威立场，并带上可被机器执行的路由含义。术语与词汇文件充当权威词表，管住实体类型、活动分类、分级这些说法，让 agent 和组织用同一套语言。路由索引把输入特征映射到相应的立场和程序，决定哪些文件适用，而且不单靠向量相似度，检索因此是确定的、可审计的。网关文件则定义进入某个分析领域之前必须通过的阈值测试，防止 agent 把专门知识用在不相干的地方。

每个文件都在 YAML frontmatter（文件开头的元数据块）里声明自己的依赖（depends_on）和使用者（referenced_by）。这张双向依赖图的作用很直接：改动一个文件，可以精确追出还有谁会受影响。

不是所有材料都进这套文件系统。知识按信息密度和预期使用频率切分。高密度、几乎每轮都要引用的内容进策展 wiki；稀疏、只在特定情境下相关的材料——详细参考资料、单个产品规格、历史决策记录、小众外部知识——走语义或词法检索，也就是 RAG（检索增强生成），先从相关资料里检索出片段，再交给模型作答。理由很实际：全塞进 wiki 会让系统臃肿，还会稀释模型投在关键内容上的注意力。

这套划分的依据只有「信息密度」和「预期使用频率」两个词。Meta 没有公布划分阈值、误分类样例，也没有给出检索的召回率。

Meta 还把 Andrej Karpathy 的 LLM（大语言模型）Wiki 和 Google 的 Open Knowledge Format 举为行业朝同一方向收敛的例证，认为知识应当被预先抽取、显式结构化、逐步披露，而不是每次查询重新推导。Meta 没有公开这两份原始材料，因此无法独立核对它对其内容的转述是否准确。

类比wiki 与 RAG 的分工像厨房里常用的调料放在灶台边、偶尔用到的干货存在仓库：常用的必须顺手且随时新鲜，稀有的按需要去取，不必全堆在台面上。

知识放在哪里：策展 wiki 还是按需检索

为什么要把专家的思路写成 recipe？

知识文件回答的是「组织怎么看」，而专家干活是按步骤走的。分析师按估值模型一步步走，安全工程师按威胁建模流程一步步走，光有一张事实清单复现不了这套动作。系统用可组合的程序来装这套方法论，称之为 recipe。每个 recipe 规定一段多步分析流程：先看什么、每一步加载哪些知识、遵循什么决策程序、什么算一份完整的分析。

关键设计是继续把「知道什么」和「怎么推理」分开。recipe 引用知识文件，但不含领域事实；知识文件陈述立场，但不规定程序。这个分法带来三个具体后果。其一，增加一条组织立场，只要加一个知识文件再更新路由索引，recipe 不用动。其二，修正 agent 的方法论缺陷，只改 recipe，知识文件不用动。其三，失败因此能干净地归到某一层：是知识错了，还是步骤错了。

第二个后果听起来平淡，却正是后面那条自动纠错流水线的前提。也正因为知识只以文本形式存在，专家的纠正不需要动底层模型的权重。

recipe 还能组合成流水线：最顶层的路由 recipe 判断该调用哪些下游 recipe，每个负责一个分析阶段。这样每轮只加载当前阶段需要的指令和知识，而不是一开始就塞进一套覆盖所有场景的巨型说明。早期版本恰好相反：只有一个扁平指令文件，所有材料都走语义检索，每一轮都把一批相关性参差的文件拉进上下文。把知识组织重构为 recipe 驱动的阶段之后，每轮消耗的 token减少约 80%。这个数字只有相对值，改造前的绝对 token 量、样本查询集和统计口径，Meta 都没有公布。

类比recipe 组合成流水线像主厨的整场晚宴方案，只负责决定上菜顺序和调用哪些分项做法，酱汁、主菜、配菜各自有独立配方，不会把细节全写进同一张纸。

推理结构清楚了，最贵的一步还剩在原地：专家的纠正怎么落进文件里。

专家的一句纠正，怎么变成一次经过测试的代码式改动

人工维护会撑不住。文件之间互相依赖，数量一多，把一条专家反馈翻译成精确的文件编辑可能要花数周——要理解完整依赖图、确认别处没被弄坏、再验证这次修复真的有效。

Meta 把这件维护工作当成编译问题来处理。整条流水线分四步：诊断，把专家反馈转成带根因的可执行问题；编译，把问题转成最小化的、经过验证的编辑；验证，确认修复有效且不引入回归；最后交领域专家审阅。合入之后，刚刚被修掉的那个问题会自动进入回归测试套件，也就是说每一次修复都永久抬高了门槛。

编译这一步用了多个子 agent 并行分析影响，检查交叉引用、与既有立场的冲突、token 预算、测试覆盖和重复风险。两个设计让结果更可信。

一个是独立的对抗审查 agent。它在全新上下文里运行，不知道这次改进的理由，只拿到提交上来的 diff，任务是找出被引入的矛盾、被破坏的边界情况、被削弱的立场。因为它和提出改动的 agent 不共享上下文，也就继承不了对方的盲点。

另一个是确定性的结构校验（linter），负责悬空交叉引用、文件大小超预算、标识符冲突和依赖环。这一层没有概率空间，只有通过与失败。

验证分两段。定向回放（targeted replay）在触发反馈的原始场景上重跑 agent，agent 不知道自己正在被测试；另一个独立 judge 在不知道改了什么的前提下，把新输出和原始专家反馈作比对，这种盲设计是为了压住确认偏误。回归测试则在领域的基准集上跑——通常是问答对形式的结构化测试套件，由独立的 LLM judge 逐用例判通过或失败，agent 在并行、独立的会话中运行。

定向回放没过就重试编译；回归没过，就把「在哪里回归了」写进更新后的提示，连同原问题和已尝试的修复一起重试。最终产出是一份带完整审计轨迹的合并请求（pull request），人类专家审阅的是一份已经被证明过的修复，而不是在调试一个原始失败。

类比判断结果用回放和回归测试保护像软件修 bug：不仅要修好用户报的那个问题，还要跑一遍既有测试，确认没把别处弄坏，最后把这次的问题也加进测试集。

一次专家纠正要经过的四步

整条流水线的第一环是诊断，而它恰恰是最容易做错的一环。

第一版归因方法错了：对话形式判断不了根因

归因这一步，第一版方法走错了。它按对话形式给反馈分类：专家补充了信息，就当成知识缺口；专家纠正了方向，就当成程序问题。这个启发式很快失效，因为对话的形式并不能反映根因——专家纠正一个结论，背后可能是知识缺口，可能是 recipe 缺陷，也可能是真实存在的歧义。

现行做法把抽取和分类拆开，核心只剩一个归因测试。先从对话里抽出每一个实质性信号，同时抽出 agent 的完整知识清单：加载了哪些文件、什么时候加载、怎么用的。然后去读实际的知识文件，只问一个问题：agent 本来能不能从它的源材料得出正确答案？

诊断阶段使用单一归因测试：若材料包含正确答案而 agent 仍答错，就是 recipe 问题；若材料不含正确答案，则是知识缺口；若专家自己对正确答案存在分歧，则标记为歧义并交人工讨论，不进自动修复流水线。

这个测试的价值在于把「该改哪一层」变成了一个可以核对的问题。它的局限同样清楚：判断依赖人去读知识文件，或者依赖模型来做这个判断，而 Meta 没有公布归因的准确率，也没有说明是否存在第二道复核。

一次纠错该改知识，还是改步骤

流程跑起来之后，团队公布了一组结果。这些数字的口径需要一条条看。

数天到数分钟、零回归：数字口径要一条条看

三轮开发冲刺、跨六周之后，Meta 给出的结果有五条。

领域 SME（领域主题专家）认为 agent 的输出几乎总是有用，相比早期版本经常需要大量返工是显著改善。单项评估时间从数天缩短到数分钟。自动化自我改进产出已验证知识编辑的速率，此前需要完整工程冲刺才能达到。跨改进周期零回归，且每个修复都会自动加固回归套件。专家反复报告 agent 处理了绝大部分分析工作，他们因此能集中在真正需要人判断的歧义案例上。

这几条都停在定性或约数的层面。「几乎总是有用」没有评分量表、样本量、评价人数，也没有统计显著性。「数天到数分钟」没有原始天数和最终分钟数，没有说明测量方式，也没说是否把此前的人工返工时间算进去。「零回归」没有交代改进周期的数量、回归用例规模、判题模型和判定标准。「绝大部分分析工作」没有具体比例。所有数字都来自系统的构建方，没有独立复现。

另有一层设计值得单独拿出来：人类并没有从流程里退出。检查点让 agent 在分析中途把中间推理摊开给专家确认、纠正或改道；升级上报发生在 agent 撞上真正歧义的时候——输入本身没说清，或者证据支持不止一种站得住的解读。这种时候它不强行给结论，而是把问题交回专家，由专家的选择决定分析走哪条路。

这些机制同时在办三件事：控制质量与方向、为自我改进提供训练信号，以及让专家通过观察推理过程、而不只是看结论来逐步校准信任。

如果这套结构真的有效，它能搬到别的领域吗？

这套结构的适用条件，和它真正的赌注

Meta 把这套架构设计成与领域无关，并给出四个判断条件：专业知识以「部落知识」的形式留在专家脑子里；评估之间的一致性重要；工作量超出专家产能；通用大模型给出的分析不够用。按这个标准，监管合规、协议遵守、金融风险评估、安全审查、工程标准合规和采购评估都被列为适配场景。但系统只在一个合规领域落地过，没有跨领域的实测结果，所谓可泛化目前是设计目标，不是已验证的结论。

要采用这套结构，至少得具备四样东西：一套结构化知识系统，文件边界、交叉引用和依赖图都明确；一个把领域知识和分析方法分开的流程层；一套会随每次改进周期增长的评价套件；以及按领域风险容忍度校准的人类在环检查点。缺哪一样，后面那条自动纠错流水线都很难立起来。

更深的原则其实很朴素：把复杂性留在人和 agent 都能读的知识文件里，而不是微调后的模型权重里。每次改进都是一次文本编辑，专家可以在 30 秒内审阅——这个 30 秒没有说明测量方式，也没有算上理解上下文的时间。每次改动都可以版本控制、可以 diff、可以回滚。编译流水线本身很复杂，但它的产出始终是透明的。

那么，一个组织的判断力到底能不能被写成机器可执行、并且随专家纠正持续更新的东西？能。路径不是让模型学得更多，而是把专家的判断当成一份需要测试和版本管理的文本库来维护：每一次纠正被冻结成一条回归用例之后，纠错就从一次性劳动变成了永久收益。前提是失败可以被干净地归因到具体某一层——归因做不干净，这条流水线就从源头失去方向。

这个判断有边界。如果某个领域的知识主要靠说不清的手感或视觉经验，写不成可检索的文本；或者专家之间对正确答案的分歧大到形成不了稳定的位置文件，这套编译式路径的收益就会明显下降。这两类情况都还没有公开的测试或失败案例可供参照。

对刚进入 AI 的人来说，可迁移的是一个顺序：当知识本身能被写成文本，先想结构和验证流程，再考虑要不要训练模型。