人工智能上下文工程是指设计围绕智能体的所有信息、边界和指令，使其知道自己可以看到什么、应该做什么，以及在遇到新情况或数据缺失时如何行动。根据 Stack Overflow 工程总监 Doug Whitley 和产品总监 Ash Zade 的解释，其目标不是用所有可用数据淹没智能体，而是为其提供完成一项结果可预测的任务所需的特定上下文。
相关内容来自 Stack Overflow Blog “No Dumb Questions”系列中的一篇对话，讨论了上下文工程、上下文基础设施和上下文工程实践之间的区别，以及这些概念与 RAG 和 MCP 两项技术的关系，还讨论了企业选择购买现成解决方案而不是全部自行构建的原因。
从基础设施到工程
Whitley 区分了上下文基础设施和上下文工程：前者涉及如何存储、呈现上下文并将其提供给智能体，后者则侧重于系统设计，以及促使人们以特定方式组织其组件的原因。至于执行层面的上下文工程，则涉及实际构建系统，例如选择所使用的算法、编程语言和工具。
他认为，RAG 位于涵盖这三个层面的交汇处。索引、上下文存储和搜索方式体现了基础设施方面，而使用 .NET、Python 或 Rust 等语言构建系统则体现了工程方面。另一方面，架构决定系统的整体形态以及约束其运行方式的规则。至于 MCP，Whitley 将其视为一个具有特定要求的协议，但决定如何将其集成到系统中、使用哪些语言以及支持哪些功能，都是设计决策。
减少智能体需要作出决策的空间
Zade 以搜索汽车轮胎为例解释这一理念。如果让一个智能体前往某个资料库搜索“轮胎”，它可能会找到有关飞机、自行车和手推车的轮胎信息，因为这些信息都匹配所要求的词语。但设计良好的系统会从一开始就明确任务涉及汽车轮胎，或具体涉及跑车轮胎，并将可用信息限制在这一范围内。
Zade 认为，仅仅把这些指令放在文本提示中，并不能保证智能体遵守它们。因此，上下文工程需要控制智能体可以访问的数据，同时明确其在遇到不完整或不正确的信息时应采取的行动。这样可以从智能体的决策中移除一些变量，而不是让它自行判断信息是否可靠，或是否应该扩大搜索范围。
这套体系还包括智能体的记忆，使其保留迄今完成的工作、学到的内容、交流过的事项以及构建的内容。当多个智能体协同工作，或任务暂停后在之后恢复时，这种记忆的重要性会进一步增加。
信任、权限与人工介入
根据两位发言人的说法，Stack Internal 展示了如何将上下文与信任系统及专家验证流程连接起来。知识会被划分为高、中或低等级；如果等级为中或低，可以将用户引导至相关领域的专家，以验证信息或补充缺失内容，而不是让智能体基于未经确认的知识作出决定。
数据保护并不只是判断智能体能否看到某条信息。某条信息可能对用户可用，但并不适合智能体正在执行的任务。因此，两位发言人描述了两个控制层级：
- 来源权限：智能体继承用户在其搜索系统中的权限，例如 Slack、MS Teams、Google Drive 或 SharePoint。
- 范围：用户可以缩小智能体可用数据的范围，即使用户本身拥有访问更大数据集合的权限。
- 新数据：可以限制智能体创建或写回系统的内容，使其先发送给用户，而不是自动添加到公共知识库或与团队共享。
这一划分表明，上下文管理不仅涉及检索，还包括对智能体创建的记忆和知识进行控制。
为什么企业可能会购买解决方案，而不是自行构建？
Whitley 表示，构建上下文工程是可行的，但挑战并不局限于编写代码。当企业从 Slack、MS Teams、Google Drive、SharePoint、Confluence、GitHub 和 Jira 收集数据时，还必须确定如何进行索引、筛选和重新排序，以及如何处理相互冲突、缺失或不正确的信息。
Zade 认为，其中很大一部分工作在于定义信任本身。当人工智能的输出符合专家用户的预期和以往经验时，专家用户可能会信任这些输出；但对于缺乏相关领域经验的人来说，这种方式并不具有同等程度的可用性。因此，这套体系需要讨论什么样的信息值得信任，而不仅仅是解决收集信息的技术问题。
Whitley 补充说，购买现成解决方案可能让企业获得其他客户遇到的问题所积累的经验，包括边缘情况和日常问题；他表示，其团队大约将这些问题归为 20 类。不过，两位发言人并不排除内部构建的可能性；当使用场景是全新的，或企业需要作出自身特有的设计决策时，内部构建可能更合适。
对于 Whitley 和 Zade 来说，上下文工程的质量取决于系统的灵活性，以及提供一致且可预测输出的能力，而不只是将其范围缩小到单一任务。尽早筛选信息还可能减少智能体需要处理的令牌数量：搜索汽车书籍的成本低于搜索整个图书馆，而搜索轮胎页面的成本低于浏览全部书籍。最终目标仍然是让智能体完成预期任务，并在达到不应越过的边界时停止或请求人工帮助。