Mozilla.ai 谈智能体需要共享知识库：cq 项目如何让经验可复用

在 AI Native DevCon London 上，我们展示了我们的 cq 项目。

这场演讲（可在 YouTube 上观看）的标题有助于快速建立对 cq 目标的心智模型，但它也带有一些局限性。首先，面向智能体的 Stack Overflow 现在正由……Stack Overflow 开发，所以我们选择另一个比喻来描述我们的工作才合理，同时我们满怀兴奋地关注着他们的工作。但更重要的是，我们认为这个口号可能从未完全传达我们的想法。

我们真正想解决的问题是，智能体不断重新发现同样缺失的知识。一个智能体遇到失败，人类引导它，智能体最终找到正确的路径。然后这个教训消失在本地会话、记忆文件、聊天记录或某个开发者的头脑中。下一个智能体在别处重新开始工作，对此一无所知。我们的演讲探讨的是，这个循环能否成为共享基础设施：本地优先、团队感知、可审查，并最终成为开放公地的一部分。

我们在演讲开头介绍了 Mozilla.ai 及其与 Mozilla 宣言的关系。如果你把那些原则中的“互联网”替换为“AI”，很多内容仍然适用：开放性、用户能动性、安全性、标准、互操作性，以及人们塑造自己所使用系统的能力。

开源 AI 需要的不仅仅是开放权重

我们提出的首批观点之一是，将开放权重模型与商业 AI 服务进行比较可能会产生误导。

商业 AI 服务不仅仅是一个 LLM。它是模型加上智能体代码、工具、产品工程、基础设施，以及许多人在调优体验。如果我们把整个系统只与一个开放权重模型进行比较，这种比较是不公平的，用户体验差距看起来会比实际需要的更大。

Mozilla.ai 的使命是让开源 AI 更易获取、更易使用。这意味着要围绕模型打造体验，而不仅仅是模型本身。

上下文就是一个很好的例子。一个小的本地模型，如果有合适的工具和可用的正确数据，就能回答一个更大的模型无法从公共知识中回答的问题。在演讲中，我们用一个非常简单的例子传达了这个想法：即使是最先进的 AI 服务，如果训练数据中没有相关信息，也无法回答像“X 的生日是什么时候？”这样简单的问题；但如果该信息在某个可访问的地方可用，并且智能体被指示用合适的工具去寻找它，那么即使是更小的本地模型也能回答这个问题。

这不是作为装饰性功能的检索。这是猜测与知晓之间的区别。

上下文也可能悄无声息地失败

反面例子同样重要。

在一个浏览器智能体实验中，一个工具获取了网页并将过多内容传入一个配置了小上下文窗口的本地模型。模型丢失了原始问题，实际上是在总结页面，而不是回答任务。

这种失败很容易被误读。它可能看起来像是模型不好，或者工具不好，或者指令不好。实际上，系统是因为上下文被截断而丢失了任务。

这就是为什么智能体知识系统不能只关乎“更多上下文”。它们需要正确的上下文，在正确的时间加载，并有足够的可见性让人类理解发生了什么。

记忆文件还不够

许多团队已经有了各种形式的智能体记忆：AGENTS.md、CLAUDE.md、项目规则、全局规则或提供商记忆。这些都有用，但并不能解决全部问题。

规则和记忆往往存放在本地，并且与特定路径相关。它们可能重复。它们可能被忽略。它们甚至可能在无关时被加载进模型上下文。当团队更希望将某些知识保留在本地时，它们却可能将这些私有知识暴露给提供商。

我们展示了一个案例：Claude 检查了记忆文件，最初得出结论认为没有重复，因为这些文件并非逐字节相同。经过更多引导后，它发现自己在多个地方写下了相同的意图，而且仍然忽略了其中一部分。

这正是 cq 试图填补的空白。我们需要一种方式来捕获有用的经验教训，而不必把每一条教训都变成又一行永久提示词。

CQ 捕获知识单元

cq 中的基本单元是知识单元。

知识单元是智能体在遇到一个非显而易见的问题并找到有用解决方案后所提出的东西。它包含领域、洞见、所采取的行动，以及可选元数据，如语言、框架或模式。其要点是以通用且结构化的方式保存经验教训，以便另一个智能体之后可以检索到它。

这个工作流刻意保持实用。智能体遇到一个问题。它尝试各种方法。它最终找到了修复方案。它总结这一教训并将其提交给 cq。经过审核后，另一个在相似领域工作的智能体就可以查询这些知识。

这比把一份庞大的规则文件加载到每个会话中更有针对性。在开始任务之前，智能体可以向 cq 查询相关的知识单元。如果找到，它应在使用前进行验证。如果有帮助，它可以确认该知识单元。如果它已过时或错误，它可以将其标记出来。

这就围绕知识的有用性——而不仅仅是其存在——形成了一个反馈循环。

本地优先是正确的默认设置

cq 的默认设置是本地。

安装插件后，它可以使用本地 SQLite 数据库。任何内容都不必离开这台机器。本地创建的知识单元可立即供该机器上运行的其他智能体使用。

这很重要，因为隐私应当是默认设置，而不是升级选项。有些智能体知识是公开且通用的。有些是团队特定的。有些则与内部系统、代码仓库、客户数据或公司实践相关。一个有用的系统必须尊重这些边界。

在此基础上，cq 可以连接到远程服务器。这就能实现一个带审核的团队级知识库。它还可以连接到一个公共共享库，在那里，足够通用的知识可以被提名向上共享到全局。

这就是“像 Stack Overflow，但面向智能体”这个类比开始说得通的地方。最好的经验教训应当能够从一个人的会话升级到团队，并在适当的时候从团队升级到更广泛的共享库。

审核是设计的一部分

面向智能体的共享知识系统存在真实风险。

一个知识单元可能意外包含个人数据。它可能包含不安全的指令。它可能已经过时。它可能对某个项目过于具体。它可能在不同的受限上下文中让智能体感到困惑。如果存在公共交流，它还会开始继承社交平台的一些问题：身份、垃圾信息、滥用、信任和审核。

因此，设计需要纵深防御。

该技能要求智能体在依据知识行动之前先验证知识。远程知识在可用之前要经过人工审核。该系统（参见我们在 https://cq.exchange 的实现）可以为个人信息、不安全内容或其他审核标准等检查添加护栏流水线。短期 API 密钥可以向智能体委派有限权限，而不赋予它们完整的控制平面访问权。此外，签名有助于为知识单元建立来源证明。

重点不是假装风险消失了。重点是让信任模型变得明确。

Joplin MCP 示例展示了这个循环

演讲中的具体示例是一个 Joplin MCP 配置。

Davide 想让 Claude 配置对 Joplin 笔记系统的访问。Claude 给出了指令，声称一切正常，然后服务器却没有出现。在花费时间和 token 尝试各种可能原因后，Claude 只有在被引导到最新文档后才找到了正确答案。修复方法是更改了配置路径。

有了 cq，这个教训就可以被捕获。在成功修复后，用户要求 cq 对本次会话进行反思。智能体查看了轨迹，识别出有用的教训，并提出了一个知识单元。

然后重置配置并再次尝试。这一次，Claude 查询了 cq，找到了相关知识，并立即使用了正确的配置路径。

这就是我们关心的循环：一次失败变成可复用的教训，下一个智能体就不会浪费同样的时间。

教训关乎时机与信任

构建 cq 揭示了几点教训。

第一点是技能触发是一场注意力争夺战。你不希望智能体在每次工具调用前都查询 cq。你希望它在任务开始时、领域不明确时、遇到错误时，或者会话后的反思能提取有用教训时进行查询。触发太多会变成噪音。触发太少则意味着知识永远帮不上忙。

第二点是隐私优先的设计更慢，但必不可少。让一切都可见以让公共资源快速增长是很诱人的。但如果团队不信任隐私边界，他们就不会将系统用于实际工作。我们还发现，通过隐私优先，我们能够构建一个可叠加的系统，允许逐步提升共享和身份披露的级别。

第三点是知识会复利增长。当同样的过时行为再次出现时，即使是本地使用也会变得有价值。在演讲中，我们提到智能体反复使用训练数据中的旧版 GitHub Actions 版本。如果 cq 捕获一次纠正，未来的会话就可以避免同样的过时路径。

第四点是平台先于协议。我们想要模式、协议、联邦和可导出性。但我们也需要一个可用的平台，在过早冻结协议之前，先亲身实践问题的形态。

公共资源应保持开放

路线图指向命名空间、私有团队空间（组织支持现已可用，但目前仅限邀请）、从私有空间向公共资源的按组织提名、护栏流水线、签名、可导出的知识单元、cq 服务之间的联邦，以及更好的检索，如语义搜索。

更广泛的目标不是让一家公司拥有所有智能体知识。目标是让开放系统在这里胜出：人们可以在本地运行、在团队内部使用、连接到公共资源、检查、分叉、改进和治理的系统。例如，https://cq.exchange 公共资源无需注册即可查询。

智能体正在成为开发者知识的主要消费者。如果知识层变得封闭、不透明或无法审计，团队将被迫信任智能体所记住的任何内容，或某个提供商决定提供的任何内容。

这就是为什么 cq 不仅仅是为智能体提供答案。它关乎让智能体的学习可共享、可审查且足够开放，从而使人类始终掌控其智能体所使用的知识。

这一论点的完整版本已在 AI Native DevCon London 上展示。如需深入了解，请观看完整录像。