组织的第二大脑：打造一个能向专家学习的 AI

我们构建了一个 AI 代理，它可作为某一特定领域的“第二专家”，让深厚的专业知识随手可得，并得以保留，供组织内任何人访问、共享并在此基础上继续构建。
这并不是一个典型的领域专用代理。它的创新之处在于整合了两层能力：
- 结构化、可审计的知识架构，将代理“知道什么”与“如何推理”分离开来。
- 一个自我改进闭环，在无需模型重新训练的情况下，将专家反馈编译为经过验证、通过回归测试的更新。
这两层结合起来，将一次性的专家修正转化为永久累积的组织记忆；而且，这一模式被设计为可推广到其他由可检索文本而非模型权重主导的领域。
该系统已经为 Meta 的领域主题专家（SME）节省了大量时间，使他们能更专注于那些最需要其专业知识的工作。

许多大型组织在专业知识方面都面临同样的问题。虽然其中一部分知识会以模型、操作手册、检查清单和框架的形式被记录下来，但最有价值的专业知识其实存在于人的头脑中，而且很少被以任何持久的方式保存下来。以合规领域为例，同样类型的问题可能会出现在数百次产品审查中，专家评估往往需要数天的人工调研，而评估之间的不一致又会给组织带来真实风险。

专家花在回答日常问题上的时间，往往比花在真正新颖、含糊且最能体现其判断力的工作上还要多，这并不罕见。我们需要能够捕捉组织内专家推理方式的系统，并把这些知识提供给所有需要它的人，从而让专业知识更易于共享、在其基础上继续发展并得以保留。

我们着手通过将组织智能编码进一个面向特定合规领域的 AI 代理来解决这一挑战。该代理结合了一个充当组织“第二大脑”的知识系统、一个模拟领域专家真实思维方式的推理层，以及一个能够永久放大专家投入的自动化改进流水线。这些模式可推广到任何拥有深度专业知识的企业领域，无论是金融、安全还是工程。

架构概览

开箱即用的大语言模型（LLM）提供了坚实基础，但在专业领域中，往往需要更深层的组织语境才能真正发挥作用。若缺少这种 grounding，通用模型的价值就会受限，因为它无法区分组织“可以做什么”（通用信息摘要）与组织“应该考虑做什么”（基于历史立场、公司方向、业务语境等）。在高风险领域，要弥合这一差距，就需要向模型提供组织自身的知识与优先级，使其分析反映组织真实的思考方式。

我们设计的系统有四层，每一层都解决一个不同的问题：

这些层彼此依赖。知识系统的文件结构使自动化编辑成为可能；推理层的显式流程使故障归因可行；评估框架为每一次变更设门；而改进闭环则同时反馈到知识和推理中。去掉其中任何一层，其余层都会退化。

构建组织的第二大脑

大型组织在专家工作的副产品中，往往会积累成千上万份文档。人们很容易把这些文档视为组织知识，但真正的知识其实是隐性的：专家如何推理、优先考虑什么、如何化解歧义。一个在推理时检索文档片段的代理，必须在每次运行中从原始来源重新推导这些推理过程，这样既慢、又容易出错，还不一致。

我们把这种隐性知识提前显式化。一个长期运行的离线流程会对源文档进行推理，并将其提炼为结构化知识文件——这些文件是对组织如何解读其领域的精选陈述，其中的约束、边界与路由含义都被整理成机器可读的形式。

更重要的是，这些知识随后构成了一个反馈闭环的基础，使代理能够在无需对底层模型重新训练的情况下，从人类专家的反馈中学习并落实这些反馈。

业内已经围绕类似思路形成了共识。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），从而形成一个双向依赖图。当某个文件发生变化时，你可以精确追踪还有哪些内容可能受到影响——这在自我改进闭环提出自动化编辑时尤其重要。

知识系统示意图：文件以可导航的文件系统方式组织（左），每个文件的 YAML frontmatter（右）声明其适用条件（触发场景）以及其依赖项和被引用者，从而形成一个代理可以轻松遍历和维护的双向依赖图。

按知识密度与使用频率组织知识

一个关键的架构决策，是如何在精心策划的 wiki 与补充检索（RAG）之间分配知识。我们按照信息密度和预期使用频率进行划分。

高密度、被频繁引用的来源会进入 wiki：**提炼后的文件，用于捕捉组织如何推理，例如立场、决策框架、边界示例和战略性解读。代理几乎在每一轮都会查阅这些内容。由于这些内容编码了组织不断演进的思考方式，因此必须保持最新，而 wiki 结构使其易于更新、版本管理和验证。

稀疏的、仅在特定情境下相关的来源则通过语义或词法搜索（RAG）提供：这些文档在适用时非常重要，但在大多数运行中并不需要详细信息，例如详细参考资料、单个产品规格、历史决策记录以及小众外部知识。若将它们全部塞入 wiki，只会让系统臃肿并稀释注意力。

最终的结果是，代理的核心推理始终建立在最精炼、最新的组织知识之上，同时在场景需要时仍可调取支撑性证据。二者结合，形成了一个组织的第二大脑：它编码的不是“到哪里找信息”，而是“组织如何解读并应用信息”。

通过可组合的配方实现专家推理

只有知识还不够。领域专家并不是只回忆事实，他们遵循的是结构化方法：金融分析师会一步一步地推演估值模型，安全工程师会遵循威胁建模流程。挑战在于，如何把这些方法论捕捉成 LLM 能够可靠执行的形式。

我们通过可组合的流程来解决这一问题，我们称之为 recipes。如果说知识文件是声明式的，那么 recipes 就是命令式的。每一个 recipe 都规定了一个多步骤的分析工作流，明确先看什么、每一步加载哪些知识、遵循哪些决策流程，以及什么才算完成了一次完整分析。

关键设计选择在于将代理知道什么与如何推理分离开来。recipes 会引用知识文件，但不包含任何领域事实；知识文件陈述立场，但不规定流程。这意味着：

添加一项组织立场，只需要新增一个知识文件并更新路由索引，无需修改 recipe。
修复代理方法论中的缺陷，只需要编辑 recipe，无需更改任何知识文件。
故障能够清晰归因到某一层：是知识错了，还是流程错了？

recipes 可以组合成管道，类似主厨为一场晚宴设计的总配方，会把每个组件（酱汁、蛋白质、装饰）分派给子配方处理，而总配方本身并不包含这些细节。我们的顶层路由 recipe 会检查输入，并选择调用哪些下游 recipes，每个 recipe 负责一个分析阶段。

这也是实现**渐进式披露（progressive disclosure）**的关键。与其一开始就塞入一套覆盖所有可能场景的庞大指令集，不如让每个 recipe 步骤只携带该阶段相关的指令与知识。早期版本使用单一平面指令文件，并通过语义搜索加载所有来源，每次运行都会将大量相关性混杂的文件拉入上下文窗口。重构为 recipe 驱动的分阶段流程后，每次查询只会触及一小部分目标明确的子集，使每轮消耗的 token 数量减少了约 80%。上下文窗口是有限的，而且注意力会随着内容量增加而下降，因此在正确的时间提供正确的指令，能直接提升推理质量。

让人类始终掌控系统

在整个系统中，人类专家始终掌握控制权。代理加速并结构化他们的工作，但不会取代他们的判断，也不会取代他们对结果的权威。

我们通过两种机制来实现这一点：

检查点（Checkpoints） 是分析过程中的预设节点，代理会在继续之前向专家展示其中间推理，供专家审阅；专家可以确认、修正或重新定向。

升级（Escalations） 则会在代理遇到真正的歧义时触发，无论是输入信息不充分，还是证据支持多种都说得通的解读。此时代理不会强行给出结论，而是把问题交给专家，由专家的选择决定分析路径。

检查点和升级同时发挥三种作用：

质量与方向控制： 专家可以在错误向下游累积之前将其捕获，并将分析保持在他们认为最相关的路径上。
训练信号： 每一次修正和每一次升级都会成为自我改进闭环的输入。
信任校准： 专家通过观察代理的推理过程，而不仅仅是最终输出，逐步建立信心；同时看到它主动标记不确定性，而不是加以掩饰。

决策越重要，这一点就越关键。这也是为什么我们建议在合规、财务风险评估、安全审查和工程安全等领域，默认保留人类在环。

自我改进飞轮

我们认为，自我改进飞轮是该系统最独特的部分。结构化知识系统和可组合 recipes 使系统在人和代理之间都可读、可测试、模块化，但彼此依赖的文件数量也使人工维护无法规模化。领域专家向代理提供反馈后，这些反馈必须被转化为精确的文件编辑。这个过程可能要花上数周，因为它要求理解完整的依赖图、验证不会破坏其他内容，并确认修复确实有效。

围绕代理如何存储、检索和更新知识，已经有大量工作——从 RAG 记忆系统到模型权重级知识编辑——都在试图解决这一问题。但对于一个基于文档的组织知识库而言，随着其不断增长以及专家立场不断演化，如何保持其正确性，却远未得到同等程度的关注。能够自动起草自身修复的代理越来越常见，但我们尚未见到在无需模型重新训练的情况下，把如此严格的验证流程应用于结构化知识库的做法。

我们把这种维护视为一个编译问题并将其自动化。每一次专家修正都会经过四个阶段：

将专家反馈诊断为带有根因的可执行问题。
将问题编译为最小化、已验证的编辑。
验证修复有效且不会引入回归。
让领域专家审阅。

一旦闭环完成，回归测试套件就会加入刚刚修复的问题，以便未来的更新能够保留这一行为。

自我改进闭环。专家修正先被诊断到根因，再编译为最小化的已验证编辑，并在回放与回归测试中评估通过后才会被审阅并落地。随后，每个修复都会被纳入回归测试套件，因此收益会永久累积。

诊断：将每一次修正归因到根因

原始的专家反馈来自对话轨迹，其中领域 SME 与代理交互并给出修正。诊断阶段会从这些对话中提取结构化信号。

我们的第一个方法是按对话形式对反馈分类。如果专家提供了信息，那一定是知识缺口；如果专家把代理引回正轨，那一定是流程问题。这个经验法则失败了，因为对话形式并不是根因的良好代理。专家修正结论时，可能暴露的是知识缺口、recipe 缺陷，也可能是真正的歧义。

可行的方法是把提取与分类分开。首先，提取专家给出的所有实质性信号，同时附上代理的完整知识清单（加载了哪些文件、何时加载、如何使用）。其次，读取实际的知识文件，并应用一个单一归因测试：代理是否能够仅凭其源材料得出正确结论？

如果材料中包含正确答案，但代理仍然出错：流程问题。
如果材料中不包含正确答案：知识缺口。
如果专家之间对正确答案本身存在分歧：歧义，标记出来供人工讨论。

编译：外科式的多代理编辑

编译器会把每个已诊断的问题转换为最小化的文件编辑。子代理会并行分析影响，检查交叉引用、与既有立场的冲突、token 预算影响、测试覆盖率以及重复风险。

有两个设计选择使其值得信赖：

独立的对抗式审查。 另一个代理在新的上下文中运行，且不知道改进动机，只接收对知识库的拟议 diff。它的任务是找出诸如引入矛盾、破坏边缘情况或削弱既有立场之类的问题。由于它与提出修改的代理不共享上下文，因此不会继承它们的盲点。

确定性的结构验证。 由 lint 工具以程序化方式捕捉问题，包括悬空交叉引用、文件大小预算违规、标识符冲突以及依赖循环。这一层不是概率性的。它要么通过，要么失败。

评估：证明修复有效

每一项拟议修改都要经过两阶段验证：

定向回放（Targeted replay） 会在触发反馈的原始场景上运行代理。代理并不知道自己正在被测试。另一个独立的评审器会在不知道改了什么的情况下，依据原始专家反馈评估新的输出。这种刻意的盲测设计可防止确认偏差。如果定向回放失败，就重新编译。

回归测试（Regression testing） 会运行该领域的多个基准，通常是结构化的问答对测试集。对于可能存在多个正确答案的分析领域，独立的 LLM 评审器会依据特定标准，对每个测试用例给出通过/失败判断。代理会在并行、彼此独立的会话中针对基准问题运行，并检测性能回归。如果回归测试失败，就会用一份更新后的提示词重新编译，说明代理在哪些地方出现了回退，以及原始问题和尝试过的修复是什么。

落地与增量强化：收益持续累积

流水线的输出是一个带完整审计轨迹的 pull request（diff）。人类专家审核的是一个已被证实有效的修复，而不是去调试原始故障。一旦获批并落地（即知识文件或 recipe 被更新），原始失败场景及其经验证正确的答案就会自动加入回归测试套件。这意味着每一次修复都会永久抬高门槛，未来对知识系统的任何改动都必须保留刚刚被修正后的行为。

结果

经过六周、三轮开发冲刺后，系统达成了以下结果：

领域 SME 认为代理输出几乎总是有用，相较于早期版本输出经常需要大幅返工，有了显著改善。
单项评估时间从数天缩短到数分钟。
自动自我改进能够以此前需要完整工程冲刺才能达到的速度，产出经过验证的知识编辑。
在所有改进周期中保持零回归，且每一次修复都会自动增强回归测试套件。
领域专家一致反馈，代理能够处理绝大多数分析工作，使他们能够专注于真正需要人类判断的含糊案例。

应用这一架构

我们为其构建这一系统的具体领域，需要将数十个来源（包括内部立场和外部材料）综合为带风险权重的评估。但这一架构并不依赖于具体领域。它适用于以下场景：

专业知识以“部落知识”的形式存在于专家头脑中。
评估之间的一致性很重要。
工作量超过了现有专家能力。
开箱即用的 LLM 生成的分析不充分。

与这一模式相匹配的具体领域包括监管合规、协议遵循、财务风险评估、安全审查、工程标准合规以及采购评估。其共同点在于，组织需要的不是仅有通用知识的 AI 系统，而是真正具备组织机构知识的 AI 系统。

采用这一架构所需满足的条件是：

一个结构化知识系统，具备明确的文件边界、交叉引用和依赖图（即该领域的组织第二大脑）。
一层流程层，将领域知识与分析方法论分离开来（recipes）。
一个自动化评估套件，并随每一轮改进而增长。
与该领域风险容忍度相匹配的人类在环检查点。

更深层的原则很简单：把复杂性保留在文本文件中，让人和代理都能读懂，而不是塞进微调后的模型权重里。每一次改进都是一项文本编辑，领域专家 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。