组织级第二大脑：构建一个向专家学习的 AI

组织级第二大脑：构建一个向专家学习的 AI

原文：Engineering at Meta，作者 Shaurya Sengar、Jason Nawrocki、Jay Shah、Prashant Kommireddi，2026 年 9 月 2 日

• 我们做了一个 AI 智能体，让它在某个专业领域充当「第二专家」：组织里任何人都能取用、分享并继续扩展那些深度的专家知识，而这些知识同时被持久保存下来。
• 它不是常见的垂直领域智能体。新意来自两层结构的结合：
  • 结构化、可审计的知识架构把「智能体知道什么」和「智能体怎么推理」分开。
  • 自我改进闭环再把专家反馈编译成经过验证、跑过回归测试的更新，全程不重训模型。
• 这两层合在一起，把一次性的专家纠错变成永久且可复利的机构记忆；这套模式的设计目标是能推广到任何「由可检索文本而非模型权重承载」的领域。
• 这套系统正在为 Meta 的领域专家（SME）省下大量时间，让他们把精力放到真正需要其判断力的工作上。

大型组织在专业知识上普遍遇到同一个问题。一部分知识确实被写成了模型、playbook、检查清单和方法框架，但最有价值的那部分专业知识活在人的脑子里，很少被完整沉淀到任何耐用的载体中。以合规领域为例：同一类问题会在数百次产品评审中反复出现，专家做一次评估要花好几天的人工调研，而不同评估之间的口径不一致还会带来实实在在的组织风险。

专家花在回答例行问题上的时间，常常比花在真正新颖、真正模糊的工作上更多，而后者才是他们判断力最有价值的地方。我们需要的系统能够把组织里专家的推理方式捕获下来，并让所有需要的人都能用上，从而让专业知识更容易被分享、被叠加、被保存。

我们的做法是把机构智能编码进一个面向特定合规领域的 AI 智能体。它由三部分组成：充当组织「第二大脑」的知识系统、复刻领域专家真实思考方式的推理层，以及让专家投入可以永久复利的自动化改进流水线。这套模式可以推广到任何拥有深度专业知识的企业领域，无论是金融、安全还是工程。

架构总览

开箱即用的大模型提供了很好的底座，但要真正在专业领域发挥作用，往往还需要更深的机构上下文。缺了这层支撑，通用模型的价值很有限：它分不清一个组织「可以做什么」（对通用信息的总结）和「应该考虑做什么」（取决于历史立场、公司方向、业务背景等）。在高风险领域，要补上这道鸿沟，必须把组织自己的知识与优先级喂给模型，让它的分析反映这个组织真实的推理方式。

我们设计的系统有四层，每层解决一个各自独立的问题：

层	解决的问题	关键洞察
知识系统	机构知识散落各处，AI 取不到。	管理知识这件事，LLM 比人更擅长。把知识组织成可导航的文件系统，并针对 LLM 的消费方式做优化。
推理流水线	专家的分析遵循结构化方法论，一个巨石式 prompt 装不下。	把「智能体知道什么」与「它怎么推理」分开，用可组合的过程（我们称之为 recipe）来表达。由此获得渐进式披露：智能体不必一次性记住全部指令。
评估框架	量不出来的东西，就改不动。	建设随每个改进周期一起长大的自动化基准，才能自信地迭代。
自我改进闭环	人工反馈周期以周计，扩不动。	把知识维护当成一个带自动化验证的编译问题来做。

这四层互相依赖。知识系统的文件结构让自动化编辑成为可能；推理层显式化的过程让失败归因变得可操作；评估框架为每一次变更把关；改进闭环则反哺知识与推理两层。抽掉任何一层，其余几层都会退化。

构建组织级第二大脑

大型组织在专家工作的副产品里可以积累出成千上万份文档。人们很容易把这些文档当成组织知识，但真正的知识是隐性的：专家怎么推理、他们优先看什么、他们如何消解歧义。一个在推理时才去检索文档片段的智能体，每一次运行都得从原始材料里重新推导这套推理过程——慢、易错、还不一致。

我们的做法是提前把这些隐性知识显式化。一个长期运行的离线流程会通读源文档，把它们蒸馏成结构化的知识文件：对「组织如何解读自己这个领域」的精炼陈述，并把约束、边界条件和路由含义写成机器可读的形式。

最关键的是，这些知识随后构成了一个反馈闭环的基础，让智能体能够吸收并落实人类专家的反馈，而底层模型完全不需要重训。

业界正在收敛到相似的思路上。Andrej Karpathy 的 LLM Wiki 把智能体知识组织成可导航的文件图，Google 的 Open Knowledge Format 则为跨智能体互操作把它标准化。共同的洞察是：知识应当被预先抽取、显式结构化、渐进披露，而不是每次查询都重新推导一遍。我们把这几条原则扩展成一个「引用保真度和机构口径一致性都是硬性要求」的系统，把 200 多个文件组织进一套严格的分类体系：

• 立场文件（Position files）记录组织的权威立场：针对某个领域问题，组织决定如何解读，附带它的约束条件、边界条件，以及机器可执行的路由含义——后者告诉推理层什么时候该套用这条立场。
• 分类与术语文件（Taxonomy and vocabulary files）是组织描述自身领域所用术语的权威词典，比如实体类型、活动类别、分级层级。每一份都按单一事实来源维护，保证智能体和组织用同一套语言。
• 路由索引（Routing indexes）把输入特征映射到相关的立场与过程，决定哪些文件适用，而不只依赖向量相似度。这让检索变得确定且可审计。
• 网关文件（Gateway files）定义智能体进入某个分析领域之前必须通过的门槛测试，防止它把专业知识套用到不该套用的地方。

每个文件都在 YAML frontmatter 里声明自己的依赖（depends_on）与消费方（referenced_by），从而形成一张双向依赖图。某个文件一变，你能精确追踪还有哪些地方可能受影响——当自我改进闭环提出自动编辑时，这一点至关重要。

按信息密度与使用频率切分知识

一个关键的架构决策是：知识该如何在「精选 wiki」与「补充检索（RAG）」之间划分。我们的切分依据是信息密度和预期使用频率。

高密度、被频繁引用的来源进 wiki：也就是那些蒸馏出来的、记录组织如何推理的文件，比如立场、决策框架、边界案例和战略性解读。智能体几乎每一轮都要查它们。因为它们编码的是组织持续演进的思考，所以必须保持最新，而 wiki 的结构让它们容易更新、容易版本化、容易校验。

稀疏、只在特定情境下相关的来源走语义或词法检索（RAG）：这些文档一旦适用就极其重要，但大多数运行里并不需要细节，比如详细的参考资料、单个产品规格、历史决策记录、小众的外部知识。把它们全塞进 wiki 会让系统臃肿，也会稀释注意力。

结果是：智能体的核心推理始终建立在最精炼、最新的组织知识之上，同时在一个场景确实需要时仍能去取佐证材料。这种组合产出的组织级第二大脑，编码的是组织如何解读并运用信息，而不只是信息在哪里能找到。

用可组合 recipe 复刻专家推理

光有知识还不够。领域专家不是简单地回忆事实，他们遵循结构化的方法论：财务分析师一步步走完估值模型，安全工程师按威胁建模流程推进。难点在于把这些方法论捕获成一种 LLM 能可靠执行的形式。

我们的解法是可组合的过程，我们称之为 recipe。知识文件是声明式的，recipe 是命令式的。每个 recipe 规定一套多步分析工作流：先看什么、每一步加载哪些知识、遵循什么决策过程、怎样才算一次完整的分析。

这里最关键的设计选择是把「智能体知道什么」与「它怎么推理」分开。recipe 引用知识文件，但自身不含任何领域事实；知识文件陈述立场，但不规定任何过程。这带来三个好处：

• 要新增一条组织立场，就加一个知识文件、更新一个路由索引，recipe 一行都不用改。
• 要修智能体方法论里的缺陷，就改 recipe，知识文件一个都不动。
• 失败可以干净地归因到某一层：到底是知识错了，还是过程错了？

recipe 可以组合成流水线，就像主厨为一次晚宴服务写的主 recipe 会把各个组成部分（酱汁、蛋白质、装饰）委派给子 recipe，而自身并不包含这些细节。我们的顶层路由 recipe 检查输入，选出要调用哪些下游 recipe，每个下游 recipe 负责一个分析阶段。

这也是渐进式披露得以成立的原因。与其把覆盖所有可能场景的巨石指令集一次性前置加载，不如让 recipe 的每一步只携带与该阶段相关的指令和知识。早期版本用的是单个扁平指令文件，并通过语义搜索加载全部来源，每次运行都会把大量相关度参差不齐的文件拉进上下文窗口。重构成 recipe 驱动的分阶段之后，每次查询只触及一小撮有针对性的子集，每轮消耗的 token 下降了约 80%。上下文窗口是有限的，而注意力会随着体量增加而退化，所以在正确的时刻交付正确的指令，会直接提升推理质量。

让人始终握着控制权

在这套系统里，人类专家自始至终握着控制权。智能体加速并结构化他们的工作；它不替代他们的判断，也不替代他们对结果的裁量权。

我们通过两种机制来保证这一点：

• 检查点（Checkpoints）是分析中定义好的节点：智能体在继续之前把中间推理摆出来给专家审，专家可以确认、纠正或改道。
• 升级（Escalations）在智能体遇到真正的歧义时触发——可能来自输入定义不足，也可能来自证据本身支持不止一种站得住脚的解读。它不会强行给出一个结论，而是把问题交给专家，由专家的选择决定分析走哪条路。

检查点和升级同时服务三个目的：

• 质量与方向控制：专家在错误向下游累积之前拦住它，并把分析保持在他们认为最相关的路径上。
• 训练信号：每一次纠正、每一次升级，都成为自我改进闭环的输入。
• 信任校准：专家通过观察智能体的推理过程（而不只是最终输出）逐步建立信心，也通过看到它主动标记不确定性、而不是掩盖不确定性来建立信心。

决策的后果越重，这一点越重要。这也是为什么我们建议在合规、金融风险评估、安全评审、工程安全这类领域默认保持人在环中。

自我改进飞轮

我们认为自我改进飞轮是这套系统最有辨识度的部分。结构化的知识系统加上可组合的 recipe，产出的是一个人与智能体都读得懂、可测试、模块化的系统；但相互依赖的文件数量一旦上来，人工维护就不可能规模化。领域专家给智能体的反馈，必须被翻译成精确的文件编辑，而这个过程可能耗时数周：要理解完整的依赖图、要确认没有别的东西被改坏、还要验证这个修复确实有效。

围绕「智能体如何存储、检索、更新知识」已经有大量工作，从 RAG 记忆系统到模型权重的知识编辑。但相比之下，如何让一个基于文档的机构知识库在规模增长、专家立场演进的过程中保持正确，受到的关注要少得多。自动起草自身修复的智能体正变得越来越常见，但我们还没有见过把这种验证严格度用在一个结构化知识库上、且不重训模型的做法。

我们把这类维护当成一个编译问题并把它自动化。每一次专家纠错都要走过四个阶段：

1. 把专家反馈诊断成带根因的可执行问题。
2. 把问题编译成最小化的、经过验证的编辑。
3. 验证修复有效且没有引入回归。
4. 交给领域专家评审。

闭环跑完之后，回归测试套件会被刚刚修掉的这个问题丰富一次，从而让后续的更新保持住这一行为。

诊断：把每一次纠正归因到根因

原始的专家反馈来自对话记录：领域 SME 与智能体交互并给出纠正。诊断阶段从这些对话里抽取结构化信号。

我们最初的做法是按对话形式给反馈分类：专家提供了信息，那一定是知识缺口；专家给智能体改了道，那一定是过程问题。这个启发式失败了，因为对话形式是根因的一个很差的代理指标。一个纠正结论的专家，可能暴露的是知识缺口、recipe 缺陷，也可能是一处真正的歧义。

真正有效的做法是把「抽取」与「分类」分开。第一步，把专家给出的每一个实质性信号抽出来，同时附上智能体完整的知识清单（加载了哪些文件、什么时候加载、怎么被使用）。第二步，去读实际的知识文件，并套用单一的归因判据：智能体凭它手上的源材料，本来能不能得出正确结论？

• 材料里有正确答案，智能体却还是错了：过程（recipe）问题。
• 材料里没有正确答案：知识缺口。
• 专家自己对正确答案都意见不一：歧义，标记出来交给人讨论。

编译：外科手术式的多智能体编辑

编译器把每一个诊断出来的问题翻译成最小化的文件编辑。子智能体并行分析影响面：交叉引用、与既有立场的冲突、token 预算影响、测试覆盖、重复风险。

两个设计选择让它可信：

• 独立的对抗式评审。另有一个智能体在全新上下文里运行，完全不知道这次改进的来龙去脉，它只拿到对知识库提出的 diff。它的任务是找问题：是否引入了矛盾、是否弄坏了边界情况、是否削弱了某条立场。因为它与提案的智能体不共享任何上下文，也就无法继承它们的盲点。
• 确定性的结构校验。一个 linter 以程序化方式抓出问题：悬空的交叉引用、文件大小预算超标、标识符冲突、依赖环。这一层不是概率性的，它要么通过要么失败。

评估：证明这个修复确实有效

每一个提出的变更都要过两阶段验证：

定向回放把智能体放回当初触发反馈的那个场景里跑一遍。智能体并不知道自己在被测。另一个裁判拿着原始的专家反馈去评估新输出，并且不知道改了什么。这种刻意的双盲设计防止确认偏差。定向回放失败，就回去重跑编译。

回归测试跑该领域的多个基准，通常是结构化的问答对测试套件。对于分析型领域——那里可能存在多个正确答案——由一个独立的 LLM 裁判按既定标准给每个测试用例打通过/失败。智能体在并行、互相独立的会话里对着基准问题运行，性能上的回归由此被检测出来。回归测试失败，编译会被重试，并附上一份更新过的 prompt，说明智能体在哪里退化了，同时带上原始问题和上一次的尝试修复。

合入与增厚：收益开始复利

这条流水线的产出是一个带完整审计轨迹的 pull request（diff）。人类专家评审的是一个已经被证明有效的修复，而不是去调试一次原始失败。一旦通过评审并合入（知识文件或 recipe 被更新），当初失败的场景和它已验证的正确答案会被自动加进回归测试套件。这意味着每一次修复都永久抬高了门槛，后续对知识系统的任何改动都必须保住刚刚被纠正的那个行为。

结果

经过三个开发冲刺、合计六周之后，这套系统取得了：

• 领域 SME 评价智能体的输出几乎总是有用，相比早期版本（输出经常需要大幅返工）是显著提升。
• 单次评估耗时从数天降到数分钟。
• 自动化自我改进产出经过验证的知识编辑，速率相当于过去需要一整个工程冲刺才能做到的水平。
• 各改进周期之间零回归，且每次修复都会自动强化回归套件。
• 领域专家一致反馈，智能体承担了绝大部分分析工作，让他们能专注于真正模糊、真正需要人类判断的案例。

把这套架构用起来

我们构建这套系统所针对的那个具体领域，需要把几十个来源（既有内部立场也有外部材料）综合成带风险权重的评估。但这套架构是与领域无关的。只要满足以下条件，它就适用：

• 专业知识以部落知识的形式活在专家脑子里。
• 各次评估之间的一致性很重要。
• 工作量超出可用的专家产能。
• 开箱即用的大模型给出的分析不够用。

这套模式契合的具体领域包括监管合规、协议遵从、金融风险评估、安全评审、工程标准合规、采购评估。共同点在于：组织需要的是具备真正机构专业能力的 AI 系统，而不只是通用知识。

采用这套架构需要具备：

• 一个结构化知识系统，带明确的文件边界、交叉引用和依赖图（也就是该领域的组织级第二大脑）。
• 一个过程层，把领域知识与分析方法论分开（recipe）。
• 一套自动化评估体系，随每个改进周期一起成长。
• 按该领域风险容忍度校准过的人在环检查点。

更深层的原则很直白：把复杂度放在人类与智能体都读得懂的文本文件里，而不是微调进模型权重里。每一次改进都是一次文本编辑，领域专家 30 秒就能看完。每一次变更都受版本控制、可 diff、可回滚。编译流水线本身很复杂，但它的输出永远是透明的。

目标是这样一个系统：专家的投入可以永久复利。每一次专家交互都让系统变得更好，每一次纠正都作为已验证的改进留存下来。组织的集体知识不再被困在个体身上，而是开始以一致且可规模化的方式，提供给所有需要它的人。

致谢

作者要感谢以下各位的贡献，他们在这套系统的研发中起到了关键作用。特别致谢（按姓氏字母序）：Cecilia Baek、Philipp Kaufold、Cat Hughes、Suzanne Leijten、Michael Marcusa、Jordi Mola、Timothy Neo、Elliott Prentiss、Laia Reyes、John Ross、Julio Santil、Taylor Wilson Thomas、Mansi Tripathi、Nikhil Shanbhag、Madeleine Vos、Jackie Zajac。

---

原文：An Organizational Second Brain: Building an AI That Learns From Experts，Engineering at Meta，2026 年 9 月 2 日。