把Karpathy的wiki带到工作中

如果你接到的挑战是打造一个真正了解你的业务（且绝不犯错）的智能体，那你很可能正深陷于RAG管道的决策之中，忙着在仓库里提交对markdown文件的修改，祈祷GitHub的服务等级协议能一直保持绿灯。

如果你正是如此，那你就把精力放错了层级。我们已有无数种方式向智能体传递上下文，因此关键问题不再是它们如何获取上下文，而是谁首先拥有成为上下文的内容，以及我们如何确保其一致性和正确性？这是一个内容运营问题，而非DevOps问题。

我将为你留下一个心智模型，用于规模化处理智能体上下文，灵感来自Andrej Karpathy关于LLM知识库的帖子。还有六个问题，可以用来检验你的现有配置。

别只盯着锤子和钉子；重要的是木头

过去几年，我们花了很多时间讨论如何进行智能体工程。但感觉我们花在讨论如何让智能体体验惠及那些职位描述中没有工程师字样的人身上的时间却少得多。每当我看到有人在X上宣称“MCP已死，直接用CLI就行”时，我总觉得他们没意识到，那些手边没有CLI可用的人也在使用智能体。

使用智能体与制造智能体并不相同，尽管两者之间有很多重叠的东西。

比如，你如何打造一个智能体，让它知道你刚卖光了某款鞋，或者你的新退货政策是什么？你如何让你的整个组织能够协作、维护、治理并处理智能体上下文，而不必给他们GitHub的钥匙，也不必为了每次小改动而重新部署整个技术栈？

所谓上下文，我指的是智能体解决问题或执行任务所需的信息。在多数情况下，这种上下文就是内容——由某人（或许借助AI）创作、发布，并可能持续维护和治理的内容。

超越个人使用范畴，智能体上下文开始需要所有者、流程、审计、治理、分发和互操作性。尤其是当智能体开始承担关键业务工作，甚至可能自主运行时。当然，这些需求本身并不新鲜。新鲜的是，智能体的高效性和自动化的前景，为攻克这些问题提供了巨大动力。

作为工程师，我们现在有机会思考如何赋能组织中更广泛的团队，去构建并治理内部及面向客户的智能体体验。

将知识结构化为上下文

2026年4月，AI研究员兼教育者@karpathy（OpenAI创始成员，自5月起任职于Anthropic）在X上发布了他关于“LLM知识库”的思考。该帖子浏览量已逼近2200万，引发了大量讨论，回复中也不乏一些投机取巧的GitHub仓库。

查看原推文

在帖子中，他反思了让智能体在研究过程中构建小型维基（即知识库）的做法——通过让它们将原始资料整理成结构化内容。“值得注意的是，维基的所有数据都由LLM编写和维护，我很少直接触碰，”他写道。正如我们似乎都在践行测试驱动开发（或者说，让智能体代劳），我们最终也能让维基保持最新状态（过去十年里接触过团队Notion或Confluence的人，都明白我指的是什么）。

细看之下，这些知识库并非仅仅是文件夹里的一堆文件。Karpathy让他的智能体通过阅读自动维护的索引文件和简要摘要来遍历它们，然后再深入挖掘。智能体在规模达到一定程度之前，都能高效完成这部分工作。由于大型语言模型内置了海量（可以说是“海量中的海量”）的领域知识，它们往往只需那份标题和描述的清单，就能迅速锁定所需了解的内容。

Karpathy的帖子简要概述了当上下文由团队维护时，你需要解决的关键要素：

他还承认，他的设置目前仅在小规模运作，大约一百篇文章和40万词，且这些工具只是权宜之计：“我认为这里存在一个巨大新产品的空间，而不是一堆拼凑的脚本。”

组织内容的主要敌人：熵与漂移

任何在企业内网或内部信息系统工作过的人都深知这一点：内容会衰退。事实往往分散在多个来源中。当一个事实在一处更新而未在另一处同步时，便会产生漂移，事实逐渐沦为谬误。大量机构知识未能抵达其应有的归宿，而是作为传说残留在某个Slack线程中，或安息于某人无人问津的AI生成会议纪要里。有些事实在无人察觉中悄然过期。工程师们倾向于称之为熵，而编辑团队则称之为漂移。

Karpathy精心策划的文章、代码库、论文和数据集来源，较少受组织“事实”那种有损现实的影响。而当我们利用代理从组织中汇编事实时，追踪知识库中最终收录的内容可能变得更加困难，因为大语言模型倾向于综合并撰写听起来合理的内容。

因此，你需要一个系统，能够指定使用哪些来源，设定代理汇编这些来源的规则，将每个事实追溯至其源头，并在冲突被发现后持久化解决这些冲突的决策。

事实上，让代理从组织来源汇编知识库，是揭示内容中矛盾、熵和漂移的绝佳方式。理想情况下，你应利用这一过程在上游修复这些问题。当你将其应用于面向公众的内容时，尤其有价值，比如修复文档、支持材料、产品信息中的矛盾。因为那正是你的客户及其代理已经在阅读的版本。

在将维基带入工作前，先问六个问题

当你从“在我的电脑上能运行”过渡到构建一个基于LLM的组织级代理基础设施时，需要考虑哪些因素？让我们通过Karpathy提出的框架来审视一些问题：

首先，将其视为内容运营问题来思考。这样，你就可以借鉴几十年来积累的成熟模式。

这份清单映射到任何为团队实施过CMS的人都能识别的问题和领域。变化在于，大型语言模型及其构建的代理，改变了我们能外包多少内容运营工作，以及能多快完成。

先思考内容运维，再谈DevOps

你可能会争辩说，对于AI内容操作系统而言，所有问题看起来都像是内容问题。没错。我们正是在这一领域构建和销售产品，所以请将此视为一种免责声明。但话说回来，这也意味着我们在实践中经常遇到这些挑战，无论是与客户合作，还是大大小小的实际部署中。

一个有点令人费解的观点是，我们在将内容运维更视为开发运维（DevOps）方面取得了巨大成功——通过将内容视为数据，我们能够以比传统面向页面的CMS更高效、更可靠的方式自动化和分发内容。但是！我们也会反过来论证：要扩展我们维护和管理智能体上下文的方式，你必须首先将其视为一个内容运维问题，而非DevOps问题。

让我举个例子。如果你把上下文视为DevOps问题，那么直觉上会觉得应该将上下文作为Markdown文件存放在代码仓库中，与代码一起通过GitHub（或任何新的挑战者）发布和维护。这在某种程度上是可行的。

假设你想在公司网站上发布公司政策（同时也有一个适合智能体的Markdown版本），使其可供支持智能体使用，以及自动处理退款的智能体使用。那它如何更新？在哪里更新？

直觉上的DevOps方法是，仓库中的文件是事实来源，其他一切皆由此派生。只要负责的人有访问权限并具备Git知识（即使通过智能体），这就行得通。但一旦没有Git环境的人需要与此交互，他们就必须通过工程师（无论是否智能体化）来操作。法务部门不会审查代码行差异；他们审查的是文档，带有生效日期、审批记录以及签署人记录。

当然，你可以在git之上构建这一切：定时合并、策略发布分支、由提交信息拼接而成的审计追踪。到了某个节点，值得留意你构建出的东西：一个内容管理系统，藏于你的仓库之内，由你维护，受限于git假设其追踪的是代码这一前提。大多数DevOps基础设施也承载着同样的假设：变化的是作为代码的业务逻辑，而非作为代理上下文的知识。

无论怎样，你都会运行的内容操作

浏览Karpathy的gist下的回复和分支，你会看到团队独立得出相同需求。并发摄取导致一个团队的wiki分叉，于是他们发明了草稿状态和锁定。重建不断覆盖人工修正，于是他们发明了带来源的固定覆盖。内部页面泄露到外部助手，于是他们为不同受众分别编译了wiki。帖子中没人说“内容管理系统”，但每个修复都感觉像是如此。

所以问题不在于你是否会为代理运行内容操作——你一定会。问题在于，你是通过事故在仓库内偶然构建它，一次一个事件，还是有意搭建，有负责人、审查，以及能在重建中存续的决策。

我们花了十年时间争论，内容作为数据处理比作为“帖子和页面”更好；这正是我们平台上内容可查询、可搜索、向量化，并通过HTTP和MCP提供的原因。对于代理上下文，这是同样的争论，但风险更高。过时的页面过去偶尔误导找到它的人类；在代理背后，它自信地、以机器速度、在每次对话中误导。

Karpathy的结语是，有空间让一个出色的产品取代他那“拼凑的脚本集合”方法。我们的赌注是，这个产品不是更智能的wiki，而是围绕它的操作。

我们一直在为Sanity Context构建这一功能，并期待在本季度晚些时候向您展示。在此之前，请针对您自己的环境提出问题。如果每个答案都指向一个人（而那个人就是您自己），那么您就处于Karpathy的位置，仓库中的文件或许就足够了。如果不是这样，我很想听听您是如何处理的，以及哪些地方让您感到吃力。

这篇文章最初发布在@sanity_io的博客上。