组织的第二大脑，首先要学会停下来

读 Meta 这篇文章时，我先想到一个很普通的合规审查。产品输入看起来很像某个已知类别，系统里也有不少相似案例，偏偏关键证据没有补齐。只会检索的 AI 很容易说：“最接近的是 A，所以按 A 处理。”它说得越顺，答案反而越像已经确认过。

负责这次审查的人，第一反应不会是再找十篇相似案例，而是问：这个类别在什么条件下才能套用？眼前缺的证据，会不会让 B 也成为合理解释？我读完后留下的判断是，组织的“第二大脑”不是更大的记忆库，而是把组织判断的适用条件、推理顺序、失败出口和修改回路做成可审阅、可测试、可回滚的知识程序。这样责任在哪里，下一次该怎么改，会清楚一些；代价也很实在：组织得一直维护这套程序。

第二大脑保存的，应该是答案的使用条件

给合规审查接一个更大的 RAG，确实能帮忙回答“有没有找到相关资料”，却不一定能回答“这份资料能不能用于当前判断”。相似文本能把证据送到眼前，却不会自动告诉模型某条立场的门槛、例外和失效出口。资料继续增加，错用规则的机会也可能跟着增加。

第二大脑要保存的，应该是答案周围的条件。position 文件写清组织在什么前提下采取什么立场；taxonomy 和 vocabulary 统一实体、活动与分类，避免同一个词在不同流程里变成不同东西。routing index 根据输入特征决定该调用哪组立场，gateway 则先判断问题是否满足进入某个专业分析的条件。

回到开头的例子。证据齐全、规则明确时，gateway 放行，routing 找到 A 对应的立场，系统再继续分析。证据不足、A 和 B 又都有道理时，系统应该停在 checkpoint，或者通过 escalation 把问题交给专家。它能安全地说“现在不能独立判断”，才算接近专家工作的真实样子。

知道什么和怎样判断，必须拆成两层

Meta 描述的一个重要设计，是把知识文件和分析方法分开。知识文件回答“知道什么”，recipe 回答“怎样分析”：先检查哪个条件，下一阶段加载哪些材料，什么情况下可以继续，什么时候必须结束或升级。顶层 routing recipe 先选下游阶段，再用渐进式披露限制一次查询能触达的知识子集。

上面的审查因此有了明确顺序：gateway 先检查输入是否越过领域门槛，routing index 再选择相关的 position，recipe 按顺序核对术语、适用条件和证据，最后才形成判断。稳定、高密度、频繁使用的立场、框架和边界示例放进精选 wiki；低频规格、历史记录和稀疏证据交给语义或词法检索按需加载。wiki 负责核心判断，RAG 负责临时取证，两者分工不同。

源文说，早期扁平的指令文件会让语义搜索加载大量相关性混杂的内容；改成 recipe 驱动的阶段后，每轮 token 消耗约减少 80%。我更愿意把这个数字理解成路由变细、注意力范围变窄了，不是模型突然变聪明。一次判断只打开必要的知识抽屉，少占上下文，也更容易追问“它为什么看了这些文件”。

这里适合复用源文的四层架构图：Knowledge System、Reasoning Pipeline、Evaluation Framework、Self-Improvement Loop。看这张图时，我最在意的不是层数，而是它把知识、推理、评测和改进放在了同一个系统里。“第二大脑”不是聊天窗口旁边多了一个文件夹。

真正的学习，发生在回答出错以后

专家纠正不能只解决眼前这一问。它被转成下一次能复用的改动，组织才算真的学到了一点东西。Meta 的做法像一次小型工程变更：先做 diagnosis，从对话轨迹和代理加载过的文件中找出问题；再做 compilation，把修复压缩成最小的文件编辑；接着在原场景上 targeted replay，运行 regression testing；最后由领域专家 review、落地，并把这个场景加入回归集。

我觉得这里最有用的是三路错误归因。正确材料已经存在，代理仍然答错，问题多半在 recipe 或分析方法，没必要继续堆文档。材料根本没有覆盖答案，就补 knowledge file、边界示例或 routing。若专家之间也没有收敛到同一个答案，那不是模型知识缺口，而是组织还没有共识，系统应当升级给人讨论。

表面上，它们都叫“AI 答错了”，修复方式却不一样。没有这层归因，团队只能往知识库里继续塞补丁；有了它，反馈才可能变成责任清楚的 diff。源文还提到，改动会经过并行影响分析、独立 fresh context 的对抗审查，以及检查悬空引用、标识符冲突和依赖环的确定性 lint。说到底，检查的是这件事：修正一个判断时，有没有把别的判断弄坏？

这里适合复用源文的自我改进循环图，并在图旁标出三条诊断分支：材料已有但方法错、材料缺失、专家意见不一。前两者可以形成最小文本改动，后一种必须保留升级出口。把所有纠正都说成“模型变好了”，反而会遮住真正发生的变化。

80% token 和零回归，究竟证明了什么

源文报告，这个内部项目用了 3 个 sprint、6 周。改造后，每轮 token 消耗约少 80%，评估时间从数天降到数分钟；领域 SME 认为输出“几乎总是有用”，改进循环中实现了“零回归”。这些是 Meta 对内部系统的自报结果，不是公开产品的性能承诺。文章没有给出模型版本、测试集规模、绝对 token 数、专家人数或独立复现材料。

“零回归”只能在既有测试边界内成立。假如线上新问题一直来自测试集没有覆盖的边界，回归全绿也不能说明现实世界安全，只能说明已知样本没有退步。token 下降同样只说明系统少读了无关上下文，不能单独证明结论更可靠。

面对高风险的组织 AI，我会把几项指标和效率数字放在一起看：该升级时有没有升级，证据不足时能不能把拒绝说清楚，严重错误率是多少，测试集有没有覆盖新边界和分布变化，专家审核后的修复有多少真正落地。这些不是源文已经报告的结果，而是我认为判断“第二大脑”能不能信任时，必须补看的部分。

组织要先学会维护自己的判断

“不重新训练模型”听起来省事，实际只是换了成本落点。模型权重不变，不代表系统没有学习；学习转移到了 taxonomy 的维护、文件依赖的治理、recipe 的设计、回归样本的增长、专家 review 和升级规则上。组织得到一套可 diff、可审查、可回滚的判断程序，也接下了长期维护它的责任。

这套方法更适合规则相对稳定、术语清楚、工作重复，专家意见能逐步收敛，错误也能构造成测试样本的领域。目标持续变化、判断高度依赖未言明情境，或者专家长期无法达成共识时，自动化能做的也许只是整理证据、准备问题，不该替人下结论。

这篇文章也改了我对“企业 AI 学习”的理解。它未必意味着模型参数不断更新，也可能只是组织终于把自己的判断写成了能被调用、质疑和撤回的公共程序。程序写得越清楚，谁负责、哪里不确定、一次修复影响了什么，就越容易查出来。相应地，组织也不能再把错误都推给一个神秘的黑盒：它得对自己写下的规则负责。

如果你的团队只能先维护一种资产，你会优先写“规则是什么”，还是写“什么时候不能套用这条规则”？为什么？

参考资料

• An Organizational Second Brain: Building an AI That Learns From Experts：本文讨论的 Meta Engineering 原文。
• Meta Engineering 官方文章 API：用于核对源文元数据与正文。
• 你的 Agent 不缺记忆，缺的是学习：延伸阅读，区分检索、记忆与可累积学习。
• 可信的评估，先学会拒绝你：延伸阅读，补充拒绝、评测边界与回归测试问题。