No Dumb Questions: What is AI context architecture? Why not just build your own?

没有愚蠢的问题：什么是AI上下文架构？为什么不能自己构建？ - Stack Overflow

2026年8月14日

没有愚蠢的问题：什么是AI上下文架构？为什么不能自己构建？

在本期《没有愚蠢的问题》中，Phoebe向Stack的工程经理Doug Whitley和产品经理Ash Zade提出了关于AI上下文架构的所有疑问。它到底是什么？为什么如此重要？什么样的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基础设施、架构与工程的讨论中处于什么位置？

Doug Whitley: 当谈到MCP时，这属于架构层面的讨论。MCP是一种定义明确的协议，它有具体的要求，但如何实现它——如何将它设计到系统中——完全取决于你自己。你可以在任何语言中实现MCP，或者选择只实现某些MCP服务器功能，或只支持特定的MCP客户端。你在决定AI系统的架构设计。RAG则需要三者协同工作。RAG背后会有一些基础设施，可能是你的索引系统，可能是你通过高性能查询设置构建的上下文存储库，或者其他能提供上下文并使其可搜索的组件。比如可能是将编码代理的规则和流程保存在Markdown文件中的列表。你如何存储并提供这些上下文给机器学习或大语言模型，这构成了基础设施部分。但RAG也是工程实现。对于RAG，我们可能会用.NET开发，也可能用Python开发，如果想挑战极限，甚至会用Rust开发。我们可以用多种方式构建它，但一旦开始构建，就必须遵循某种架构。

举个例子：如果我们正在制造一辆车，决定制造汽车本身就是一个架构决策。我们选择制造汽车而非船只、滑板车或自行车。品牌和型号则属于工程层面。我们在哪里采购零部件属于基础设施层面。

Phoebe Sajor: Ash，从产品经理的角度来看，上下文架构具体是如何让AI代理表现得更好的？

Ash Zade: 我借用Doug的汽车类比。我们可以让代理去学习不同轮胎选项的所有信息，然后回来提供建议。如果这个代理走进图书馆查找轮胎，它会找到飞机轮胎、自行车轮胎和手推车轮胎的信息。它会找到所有类型的轮胎信息，因为它们本质上都是轮胎。这是合理的。但如果我们正在制造汽车，我们只关心汽车轮胎。但无论你如何设置限制，让代理只查找汽车轮胎，如果通过提示语实现，你无法保证它只返回汽车轮胎。你真正需要做的是限制代理能访问的信息范围。当你控制代理的访问权限时，它就不会偏离主题，返回自行车相关的信息。我只希望你关注并使用这些知识来完成我交给你的任务。

构建上下文的另一个关键部分是代理记忆——确保代理能记住它已经完成的工作。它会检查跑车轮胎、厢式车轮胎和卡车轮胎。你可以进一步细化要求，指示代理只关注跑车。但你不可能一天内造出跑车，所以你需要代理保持历史记录，记住它正在处理的是跑车。这样即使你离开一天再回来继续工作，即使代理同时处理多项任务，它仍能继续推进跑车项目。AI上下文的一部分就是保存代理正在做的事情、它学到的内容、它传递的信息以及它到目前为止构建的内容。如果你将这种机制扩展到10个或100个代理，保持所有这些信息就尤为重要，这样才能在此基础上继续构建。因此你需要检索功能和上下文的持续维护。

但你还需要定义代理在遇到特定情况时应采取的行动。这就是所谓的“防护措施”。一个例子是“人工介入机制”，我们在产品 Stack Internal 中就实现了这一功能。设想一下，你让代理执行某个任务，但你不确定知识库中是否包含代理完成该任务所需的所有信息。我们不希望代理基于不完整或错误的信息采取行动。在 Stack Internal 中，我们会将知识标记为“不完整”或“错误”，然后告诉代理：“如果你遇到不完整或错误的信息，应该采取以下措施：不要直接使用这些信息，不要假设它们是正确的，也不要自行判断其正确性。”

我们通过“信任系统”实现这一点。该系统会将知识评为“高”、“中”或“低”等级。如果评分是“中”或“低”，我们会让代理使用一种称为“领域专家验证流程”的工具。代理会自动将用户路由到该领域的专家，由专家验证或补充信息。

通过“上下文架构”，我们实际上只是在移除变量。我们移除了让代理混淆自行车轮胎和汽车轮胎的变量，只为其设定运动车轮胎的边界。我们还去除了“高质量”与“低质量”知识的变量，使其无需对不完整或错误的信息进行判断。然后，我们为其提供一种机制，当遇到障碍时，代理不会自行尝试解决，而是引入人工介入。

整个设计的目的是在确保安全的前提下，为拥有知识访问权限的代理创建任务，并确信它们会按照预期执行任务。如果遇到障碍，它们也会按照预期采取行动。

Phoebe Sajor：当给予代理如此多的信息访问权限时，如何确保数据安全？赋予代理访问知识的权限是否存在隐私和安全方面的担忧？

Ash Zade：在很多情况下，你会使用像 Codex 这样的工具，并将其连接到 Slack、MS Teams、Google Drive、SharePoint 等平台。然后你要求它执行某个任务。代理会根据它认为最适合的平台来查找信息。但可能它会进入你不希望它获取数据的 Slack 频道。例如，它可能进入一个讨论潜在开发项目的“创新”Slack 频道，然后返回关于尚未构建的项目的信息。隐私问题不仅涉及代理应该和不应该看到的内容，还可能涉及我们根本不想让某些信息被代理使用。这就是为什么在赋予代理数据访问权限时，上下文架构至关重要。谈到安全性，核心问题在于权限管理。在 Stack Internal 中，我们通过赋予代理与原始来源相同的权限来处理这一问题。用户的访问权限会直接继承到 Stack Internal 中。因此，如果代理以产品经理的身份代表我工作，它将拥有与我相同的上下文权限，且仅限于这一上下文。如果我希望进一步限制权限，比如“我虽然可以访问很多内容，但只希望你关注我的产品领域”，我们有一个称为“作用域（Scopes）”的机制，允许用户进一步定义代理的访问范围。

所以这里存在两个层次。首先是源数据的权限。如果这是一个私有Slack频道，而我不是其成员，我的代理也不会成为成员。但即使我是该私有Slack频道的成员，我可能仍然不希望将这些知识纳入代理的工作范围。当出现这种情况时，我可以围绕所有可访问的知识设置一个作用域，只向代理提供其中的一部分。这样我可以筛选自己能够访问的内容，但代表我工作的代理永远无法访问超出我权限范围的信息。

这只是检索部分。但正如我所说，你希望你的代理能够存储记忆并围绕其执行的操作创建新的知识上下文。这可能涉及将知识重新推回系统。这时你也需要设置一些限制，同样可以通过作用域实现。例如，我的代理可以访问这些数据，并且我希望它记录自己的操作。但这些信息是特定于我的。我可以告诉代理不要将这些信息放入通用知识库或与我的团队共享。先发送给我自己。你也可以对这种情况进行控制。

Phoebe Sajor：人工智能最有趣的地方之一是，一切事物都在不断变化。这既令人兴奋又令人害怕。但这种变化如何与上下文架构结合？当底层模型或系统发生变化时，上下文会受到什么影响？

Doug Whitley：上下文架构的巧妙之处在于，它并不需要依赖与特定AI模型的交互方式。实际上，我们在日常生活中就经常使用上下文架构——你可能只在书桌上保留某些物品，因为你想让这个上下文非常贴合你的工作流程。上下文架构是我们日常自然参与的事情。我们发现，即使在物理空间中控制周围的上下文也能取得成功。因此，上下文架构的巧妙之处在于，它能让事物在任何使用端都变得有用。无论是MCP客户端或服务器在为你执行操作，还是你直接与从搜索端点提供的上下文进行交互，又或者只是你在尝试完成某项工作，保持一个清晰的上下文都非常有价值。对于AI上下文架构来说，无论你连接的是什么AI模型，情况都是一样的。我们只是明确地说明如何通过编码化和围绕它构建工具来增强其实用性。

Phoebe Sajor：在AI系统中，实际使用上下文架构的过程是怎样的？AI代理是如何通过架构获取上下文的？

Doug Whitley：和任何事情一样，这取决于具体情况。在Stack Internal中，我们使用了许多不同的算法来为用户提供最佳结果。有索引、特定的标签处理，以及可能进行的向量搜索，所有这些都取决于输入的问题。因此，我们处理过程的一部分是分析被提出的问题、工作流程中正在发生的事情，并确定搜索数据的最佳方式。存在上下文映射，你可以将其想象成一个布满图钉和连接线的复杂板。还有经典的算法概念中的表格，你可以在桌子上放置物品，并轻松地从中取出或排除。你可以将作用域想象成一叠你写有特定上下文的便利贴。

我们还利用 Ash 之前提到的信任评分来判断代理可以安全处理哪些信息。Stack Internal 会对信息进行重新排序，确定对你和你的代理来说最重要的上下文。优秀的 AI 上下文架构需要经过多个步骤。我喜欢将其比作撒开一张大网，然后将其收拢，说：“我们寻找的是鱼，而不是牡蛎。我们会把牡蛎扔掉。实际上，我们只想获取这种特定的鱼，所以会把其他种类的鱼扔回去。我们还只想要这种尺寸的鱼，因此会把太小或太大的鱼都去掉。”我们通过多个步骤来过滤掉你不需要的信息。

Phoebe Sajor：我喜欢这个网的比喻。那么，为什么公司不直接自己制作一张网，而不是去超市买鱼呢？购买上下文架构相比自己构建有什么优势？

Ash Zade：构建自己的上下文架构涉及两个重要方面：技术层面和实际运作方式。我再回到汽车的类比。我曾让代理返回有关跑车轮胎的信息，于是它去图书馆查找。但当它拿出两本书时，这两本书对最佳跑车轮胎的描述出现了矛盾。当出现矛盾时，我的代理该怎么办？我们如何解决这种矛盾？我们甚至如何识别矛盾？上下文架构可能看起来像是一个简单的数据整合问题，包括收集数据、排序、索引、重新排序并提供数据。但现在数据无处不在——它们存在于 Slack 和 MS Teams、Google Drive、SharePoint、Confluence、GitHub、Jira 等平台。你希望可以访问所有这些数据，它们都具有价值。但一旦你将这些数据整合进来，就会产生一个巨大的问题。这不仅是一个技术问题，而且问题本身已经非常庞大。你必须弄清楚当遇到冲突、不完整或错误的信息时该怎么办。我们如何选择这些信息？我们甚至如何对它们进行排序？

我和 Doug 合作非常密切，我们经常进行大量哲学层面的讨论，实际上比技术层面的讨论更多。因为我认为在信任或冲突等细节和决策方面，可能存在一些未被注意到或被低估的重大成本。你知道，在 Stack Overflow，信任已经融入我们的 DNA。我们做过大量研究，询问人们如何判断他们是否可以信任 AI 的输出。大多数情况下，答案取决于他们对输出内容的预期。例如，他们正在撰写一份他们之前做过 20 次的客户报告。现在，他们让 AI 帮助完成这份报告。如果 AI 输出的内容与作为报告专家的他们预期不符，他们就不会信任这个结果。

但这种方法只有在你具备相关经验时才有效。对于那些在请求AI完成任务（如氛围编程）时缺乏相关经验的人来说，这会成为一个巨大的问题。那么，如何构建一个人们真正可以信任的上下文架构呢？有经验的人并不在输出中寻找特定的词语或特定的图像。为了信任他们的AI，他们需要满足一个总体的期望。当我们拆解这个期望时，实际上需要投入大量精力和进行哲学层面的讨论，才能明确需要构建的内容。然后我们还必须构建它，而这本身就是一个复杂的过程。创建一个能够满足信任所需期望的系统或产品非常困难。要实现这一点，需要涉及许多组件。我认为这正是在“自建还是购买”讨论中经常被忽视的地方。是的，为你的架构编写技术代码是完全可行的。但你如何处理所有数据呢？你将如何对数据进行分类、过滤，并以系统化的方式确定最佳上下文？

Phoebe Sajor：从产品和技术角度来看，什么构成了一个良好的上下文架构？人们在选择上下文架构时应该注意哪些方面？

Doug Whitley：老实说，良好的上下文架构意味着你每次都能得到完美的答案。达到这一点是关键难点。你需要一个能够灵活适应各种使用场景的架构。它不能过于具体，否则你将得到一个只适用于跑车轮胎的隧道视野架构。你将永远无法查找手推车轮胎的相关信息。或者即使你能查到，系统也总是会建议你使用汽车轮胎并将其安装在手推车上，这正是我之前在AI中遇到过的问题。我认为一个好的上下文架构应该能跨用户群体良好运行，无论是模型还是实际的个人用户。它能提供强大的上下文信息，帮助你发现原本可能忽略的问题。也许它还会提供一些你原本不知道的额外信息。例如，它可能意识到你需要特定的轮胎气压值，因为它知道你的汽车品牌和型号，并基于这些额外上下文信息给出输出。因此，良好的上下文架构还可以填补你未曾意识到的空白。

Ash Zade：我认为真正优秀的上下文架构取决于输出的可预测性和一致性。如果我搜索特定气压值的轮胎，每次得到的答案是否相同？Doug会得到同样的答案吗？你也会得到同样的答案吗？这就是我们试图实现的目标。当我们说“完美答案”时，意味着它能够以一致性和可预测性的方式呈现。这些正是多年来AI所缺乏的两个关键要素。AI确实能完成许多出色的工作，但我们无法对代理任务充满信心，因为无法预测它会做什么。我们希望获得可预测性，这样才能对这些工具建立信心。

如果你能做好上下文工程和架构设计，不仅每次都能稳定得到正确答案，还能优化令牌成本。如果让代理去遍历整个图书馆寻找所有书籍，可能需要数小时，这会消耗大量令牌并投入大量资源。如果只让它查找汽车相关的书籍，消耗就会减少。如果只让它查看轮胎相关的页面，消耗更少。如果只让它处理运动型车轮胎和PSI相关的段落，消耗会更少。这种优化在购买与自建的讨论中往往不那么明显，但确实存在。

Doug Whitley：说到购买与自建的选择，我认为自建始终有其合理之处。但购买的一大优势在于，你可以继承前人积累的经验。当你自行构建时会遇到的诸多问题，我们早已为其他客户解决过。我们拥有丰富的经验与通用知识，可以明确指出："实际上，我们日常处理的上下文架构问题大致可分为20个类别左右。"对我们而言，这些都不是新问题。也许你确实有非常新颖的应用场景，但你仍能受益于我们通过数据训练、数据分析以及对所有边缘案例的考量所积累的经验。你必须通过反复实践才能掌握这些知识，而我们早已通过与他人的合作工作获得了这些能力。

Phoebe Sajor：我意思是，当你可以让Doug和Ash来完成时，为什么还要自己动手呢？