什么是AI上下文架构？为什么不建议自建？

Phoebe Sajor：Doug、Ash，感谢你们参加这期「没有愚蠢的问题」节目。首先——AI 中的上下文架构到底是什么？为什么我们要关注它？

Doug Whitley：它其实和常规的上下文架构是一样的概念，当我们谈论建筑的实际架构时。AI 上下文架构就是围绕 AI 融入系统的一切进行适配——你在查看、操作和看到的东西。在 AI 方面很容易陷入细节泥潭。你可能希望在你的系统中保持一个非常聚焦的上下文。例如，对于 AI，我不一定需要了解成千上万条日志，这些日志是我正在做的工作的输入，但当我试图解决与它们相关的问题时，我确实需要在非常特定的某几条日志中获取信息。

Ash Zade：作为产品经理，我认为 AI 上下文架构是我们可以为 AI 智能体提供的护栏和约束。你要做的是消除 AI 智能体中模糊的决策和变量，让用户能够获得更可预测的结果。它可能看起来像是搭建这样一套系统：告诉你的 AI 智能体「只查看这些数据，并且只基于这些数据做这三件事。如果你卡住了，做这两件事。」因此，智能体不仅拥有它需要工作的有限上下文，还拥有在遇到新情况时该怎么做的上下文。

Phoebe Sajor：我最近在节目中采访了 Michael Foree，他教了我一些关于上下文工程的知识。上下文架构和上下文基础设施有什么不同？上下文架构和上下文工程有什么不同？它们是如何协同工作的？

Doug Whitley：理解它的最好方式是从上下文基础设施开始，这涉及到你实际提供服务上下文的方式。基础设施是你如何传递某些东西——比如上下文——或者你如何组织你要传递的内容。所以对于上下文基础设施，你会看到诸如上下文库和 RAG 特定的上下文基础设施之类的东西。它是一种存储、呈现和向 AI 智能体提供上下文的方式，让它能够为你解决问题。

当我们谈论架构与工程——不管前面有没有「上下文」这个词——界限就变得有些模糊了。它们确实是齐头并进的，但架构更偏哲学性。架构要问的是：为什么我们可能尝试以某些方式做事，为什么我们可能尝试将某些东西组合在一起来实现某些目标。架构就是设计。例如，工程师使用的标准设计模式就是架构。工程才是真正落地的地方——你实际在构建东西。你可能决定使用某种特定算法，因为它非常有效，或者你可能使用某些编程语言，因为你正在用 RAG 构建某些东西。

Phoebe Sajor：那么 RAG 和 MCP 在 AI 基础设施 vs. 架构 vs. 工程这个话题中处于什么位置？

Doug Whitley：当你谈论 MCP 时，那是架构。MCP 是一个有明确要求的定义协议，但如何实现它——如何将它设计到系统中——完全取决于你。你可以用任何语言实现 MCP，或者你可能只选择实现某些 MCP 服务器功能，或只支持某些 MCP 客户端。你在做的是关于 AI 系统设计的决策。RAG 这三个层面都有一些，是三者协同工作的结果。你的 RAG 后端会有某种基础设施——可能是你的索引，可能是你已经做了高性能查询设置的上下文存储，或者其他提供上下文并使其可搜索的东西。也许是你为编码智能体保存的规则和流程列表，以 Markdown 文件形式存储。你如何存储和向 ML 或 LLM 模型提供该上下文，那就是基础设施。但 RAG 也是工程。对于 RAG，我们可能用 .NET 构建它，可能用 Python 构建它，如果我们感觉很有极客精神的话，我们用 Rust 构建它。我们可以用许多不同的方式构建它，但当我们这样做时，我们必须遵循一种架构。

可以这样想：如果我们正在造一辆车，我们首先要造一辆车这件事就是一个架构决策。我们决定我们想要一辆车，而不是船、不是滑板车、不是自行车。品牌和型号是工程层面。我们在哪里购买零件是基础设施。

Phoebe Sajor：Ash，从 PM 的产品角度来看，上下文架构究竟是如何让 AI 智能体工作得更好的？

Ash Zade：我借用 Doug 的汽车比喻。我们可以要求一个智能体出去学习它能了解到的关于不同轮胎选项的一切，然后回来提供建议。如果那个智能体走进一个图书馆寻找轮胎，它会找到飞机轮胎、自行车轮胎和手推车轮胎的信息。它会在任何地方找到轮胎的匹配项，因为它们都是轮胎。这些信息都是有效的。但如果我们正在造一辆车，我们只关心汽车轮胎。但无论你多么努力地设置护栏来让智能体只查找汽车轮胎，如果你是在 prompt 中做的，你就无法保证它只会带回汽车轮胎。你想要做的是限制你赋予智能体访问权限的信息。当你能控制它能访问什么时，它就不会跑偏，不会带回关于自行车轮胎的信息。这是我想让你关注和在你给我的任务中使用的知识。

构建上下文的另一个部分是智能体记忆——确保智能体记住它已经做过的工作。它已经查过了跑车轮胎、面包车轮胎和卡车轮胎。你可以细化它并指示智能体只专注于跑车。但你不可能在一天内造出一辆跑车，所以你会希望智能体保持那段历史，记住它正在造一辆跑车。然后你可以离开一天，再回来继续做跑车的开发，即使你的智能体同时在处理多件事情。AI 上下文的一部分是保存智能体正在做什么、它学到了什么、它沟通了什么、以及它迄今为止构建了什么。如果你把这乘以 10 个智能体或 100 个智能体，维护所有这些信息就变得尤为重要，这样你才能在已有基础上继续构建。所以你有检索和上下文的维护。

但你也想定义智能体在遇到这种情况或那种情况时应该做什么。这就是护栏。一个例子是人在环机制，我们在我们的产品 Stack Internal 中有。所以想象你派出你的智能体去执行一个动作，但我们不知道在我们的知识库中是否有智能体完成它所需的所有答案。我们不希望智能体依据不完整或不正确的信息采取行动。在 Stack Internal 中，我们做的是将知识标记为不完整或不正确。然后我们告诉智能体：「如果你遇到不完整或不正确的东西，你应该这样做。不要直接使用它。不要假设它是正确的。如果你不确定它是否正确，不要自己做判断。」

我们这样做的方式是通过一个信任系统。它会给知识打分——高、中、低。如果分数是中或低，我们就告诉智能体使用一个叫做主题专家验证流程的工具。智能体会自动将用户路由到该主题的专家那里，让他们来验证或填补空白。

通过上下文架构，我们所做的实际上只是消除变量。我们消除那个会让智能体把自行车轮胎和汽车轮胎搞混的变量，并给它划定边界——只考虑跑车轮胎。我们消除高质量与低质量知识之间的变量，这样它就不需要对不完整或不正确的信息做判断。然后我们给它一个机制，让它在遇到困难时，不会自己摸索，而是引入人在环。

整个目的是安全且有信心地为智能体创建任务，让它们能够访问知识，并且知道它们会做你期望它们做的事。如果它们遇到了困难，它们也会做你期望它们做的事。

Phoebe Sajor：当你们给智能体这么多信息访问权限时，你们如何保证数据安全？给智能体访问知识的权限是否存在隐私和安全问题？

Ash Zade：所以，在很多场景下，你会用 Codex 这样的工具连接 Slack、MS Teams、Google Drive、SharePoint 等平台。然后你让它去做某件事。智能体会选择它认为最适合你任务的信息来源平台。但它可能会进入你不想让它获取数据的 Slack 频道——比如创新频道，那里的人在讨论一些潜在的可能做的东西，智能体就会回来告诉你一些还没做出来的事实。所以隐私不仅仅是智能体应该或不应该看到什么的问题。完全可以是，我们根本不想让某些信息被融入它的工作中。这就是为什么给智能体访问数据的权限时，上下文工程如此重要。在安全方面，真正相关的是权限。在 Stack Internal，我们让智能体继承其来源的相同权限来处理这个问题。用户访问权限会被带入 Stack Internal。因此，如果它代表我这个产品经理工作，它拥有的上下文和我一样，而且只有那些上下文。如果我想进一步限制它，比如说，"好吧，我可以访问很多东西，但我只想让你关注我的产品领域"，我们有一种叫 Scopes 的机制，允许用户进一步定义智能体可以访问的内容。

所以这里有两层。一层是来源的权限。如果是一个私有 Slack 频道，而我不是其成员，我的智能体也不会是成员。但即使我是那个私有 Slack 频道的成员，我仍然可能不想让那些知识融入智能体的工作。这时，我可以在我所访问的所有知识上设置一个 Scope，只给智能体其中的一个子集。所以我可以筛选我所访问的内容，但代表我工作的智能体永远不会访问超出我权限范围的内容。

这只是检索部分。但正如我所说，你希望你的智能体存储记忆，并围绕它所做的事情创建新的知识上下文。它可能正在向系统推送知识。这也是你需要设置一些限制的地方。你也可以用 Scopes 来做到这一点。好的，我的智能体可以访问这些数据，我希望它记录它正在做什么。但这些信息是特定于我个人的。我可以告诉智能体不要把它放到通用知识池中，也不要与我的团队共享。先发给我。你也可以控制这一点。

Phoebe Sajor：关于 AI 最有趣的事情之一，就是一切都在不断变化。这既令人兴奋又令人恐惧。但这对上下文工程意味着什么？当底层模型或系统发生变化时，上下文会怎样？

Doug Whitley：上下文工程最酷的地方在于，它不必与如何与特定的 AI 模型交互有关。我们实际上在日常生活中也在做上下文工程——你可能只在桌上放某些东西，因为你想让那个上下文非常特定于你的工作流程。上下文工程是我们每天自然参与的事情。当我们控制周围的上下文时，即使在物理层面，我们也会找到成功。所以，上下文工程最酷的地方在于，无论另一端是谁，它都能让事物变得有用。无论是 MCP 客户端还是服务器在为你做事情，无论是你直接与从搜索端点获得的上下文交互，或者只是你自己在做一些工作，保持干净的上下文都非常有价值。对于 AI 上下文工程也是如此，无论你接入了什么 AI 模型。我们只是在明确地说明，为什么把它编纂成法并围绕它构建一个专门的工具可能更有用。

Phoebe Sajor：在 AI 系统中使用上下文工程的实际过程是什么样的？AI 智能体如何通过架构获得上下文的喂养？

Doug Whitley：和其他事情一样，这取决于具体情况。在 Stack Internal，我们使用许多不同的算法来给用户最好的结果。有索引、有会发生的特定标记、还有你可能会做的向量搜索，这些都取决于输入的问题。所以我们流程的一部分是看被问了什么、工作流中发生了什么，然后找出搜索数据的最佳方式。还有上下文映射，你可以把它想象成一块钉满图钉和连接线的疯狂白板。还有经典的算法概念中的桌子，你在桌上放东西，可以轻松地拿起或放下。而你可以把 Scopes 想象成你写的一叠便签纸，每张便签对应特定的上下文。

我们还使用 Ash 之前提到的信任分数，来弄清楚你的智能体可以安全地在什么信息上操作。Stack Internal 还会重新排序信息，并确定什么上下文对你和你的智能体最重要。好的 AI 上下文工程需要多个步骤。我喜欢把它想象成撒下一张非常宽的网，然后收网，说："好吧，我们在找鱼，不是蚝。我们要丢掉蚝。而且实际上，我们只要这种鱼，所以我们要扔掉其他种类的鱼。我们也只要这个大小的鱼，所以我们会去掉太小或太大的。" 我们通过多个步骤来过滤掉你不需要的信息。

Phoebe Sajor：我喜欢那个织网的比喻。那为什么一家公司不自己去织网，而是去超市买鱼呢？购买上下文工程而不是自己构建有什么好处？

Ash Zade：构建自己的上下文工程有两个重要的部分。有技术层面，然后是它实际上应该如何工作。我回到汽车的比喻。我让智能体返回关于跑车轮胎的信息，所以它去了图书馆。但当它拿出两本书时，它们关于最好的跑车轮胎给出了矛盾的信息。当出现冲突时，我的智能体应该怎么做？我们如何解决？我们如何识别冲突？上下文工程看起来可能是一个简单的问题——把所有这些数据引入、排序、索引、重新排序，然后提供服务。但现在我们的数据无处不在——在 Slack 和 MS Teams、Google Drive、SharePoint、Confluence、GitHub、Jira 中。你想访问所有这些。这些都有价值。但一旦引入，就产生了一个巨大的问题。而且这不仅仅是技术问题，技术问题已经很大了。你必须弄清楚当遇到冲突、不完整或错误的信息时会发生什么。我们如何选择这些东西？我们如何给它们排名？

Doug 和我紧密合作，有很多哲学层面的对话——说实话，技术层面的对话反而更多。因为我认为在涉及信任或冲突等细节和决策时，确实存在一个可能被忽视或低估的巨大成本。你知道，信任融入了 Stack Overflow 的基因。我们做了很多研究，我们问过人们如何知道可以信任 AI 输出。绝大多数情况下，这取决于他们对输出应该是什么样的期望。他们正在做一份已经做过 20 次的客户报告。现在他们让 AI 帮助他们。如果 AI 输出的东西不符合他们作为报告专家的期望，他们就不信任它。

但这只有在你有经验的情况下才有效。对于在 AI 所做之事上没有经验的人来说，这是一个巨大的问题，比如凭感觉编程。那么你如何构建一个人们真正可以信任的上下文工程？有经验的人不是在输出中寻找特定的词或特定的图像。为了信任他们的 AI，他们有一个需要被满足的总体期望。一旦我们分解了这一点，实际上在弄清楚我们需要构建什么的过程中，就涉及了大量的努力和哲学层面的对话。然后我们必须构建它，这本身就很复杂。创建一个能够满足信任所需期望的系统或产品是非常困难的。要做好这件事，需要很多环节。我认为这是"构建还是购买"讨论中被忽视的部分。是的，为你的架构进行技术层面的编码是可能的——这完全有效。但你如何对待所有这些数据呢？你将如何以系统化的方式排序、过滤并确定最佳上下文是什么？

Phoebe Sajor：从产品和技术的角度来看，什么构成一个好的上下文工程？人们在他们的上下文工程中应该注意什么？

Doug Whitley：说实话，好的上下文架构意味着你每次都能得到完美的答案。难的地方在于如何做到这一点。你需要的是一套能灵活适配各种使用场景的方案。它不能过度特定化，否则就会陷入隧道视野，只对运动汽车轮胎有用。你永远找不到能装在独轮车上的轮胎。或者即便找到了，它也总会建议你买汽车轮胎然后硬装到独轮车上——这种事我以前碰到过 AI 干过。我认为好的上下文架构之所以好，是因为它在不同用户之间都能良好运作，无论用户是一个模型还是一个真实的人。它提供强上下文，帮助你捕捉到原本捕捉不到的东西。也许它还会给你提供你未必知道的额外上下文。也许它意识到你需要特定的 PSI 胎压，因为它知道汽车的型号和品牌，然后基于这些额外上下文给出输出。所以，好的上下文架构还能填补你不知道存在的空白。

Ash Zade：我认为真正好的上下文架构，其基础在于输出的可预测性和一致性。如果我搜索某个 PSI 的轮胎，每次都会得到相同的答案吗？Doug 会得到相同的答案吗？你会得到相同的答案吗？这正是我们努力要实现的目标。所以当我们说"完美的答案"，它是以一致性和可预测性为前提交付的。这是 AI 多年来一直缺失的两个要素。它做了很多很棒的事，但我们没有信心把一个任务交给智能体然后放手让它去跑，因为我们无法预测它会做什么。我们需要可预测性，这样我们才能对这些工具有信心。

如果你把上下文工程和架构做对了，不仅你每次都能可预测地得到正确答案，还能优化 token 成本。如果你要 AI 代理遍历整个图书馆来找书，那得花好几个小时。这是大量的 token 和投入。如果你要它只遍历汽车相关的书籍，那就少多了。如果你要它只遍历关于轮胎的书页，那就更少了。如果你要它只遍历运动汽车轮胎和 PSI 相关的段落，那就更更少了。这一点我认为在买与建（buy vs. build）的讨论中并不是显而易见的。

Doug Whitley：说到买与建，我认为自建总是有合理理由的。但购买带来的最大好处之一，是你能够受益于所有在你们之前走过这条路的人。你在自建时将要面对的所有问题，我们已经为其他客户解决过了。我们有经验也有泛化知识。我们可以说："说实话，上下文架构中我们日常处理的问题大致可以分为 20 类左右。"所以这些对我们来说都不是新问题。也许你有一个真正全新的使用场景，但你仍然会受益于这样一个事实：我们已经训练过数据、研究过数据，并且考虑了所有人的所有边缘情况。这些知识你只能通过自己去磕去才能获得。而这些我们已经通过与他人合作的工作积累下来了。

Phoebe Sajor：我的意思是，既然可以让 Doug 和 Ash 帮你做，为什么还要自己来呢？