本文由 简悦 SimpRead 转码， 原文地址 blog.csdn.net
作者：来自 Elastic Sri Desikan
上下文工程如何打造可用于生产环境的agent式 AI。
如果你过去一年投入打造的 AI 战略，现在已经开始按照一套完全不同的规则进行衡量，会怎么样？
最近，我与 IDC 高级研究经理 Amy Machado 和 CIO Marketing Services 高级特约编辑 Jim Malone 一起参加了一场网络研讨会，我们探讨了随着企业从搜索驱动的体验转向 agent 式 AI，客户预期、架构要求和评估标准正在如何发生变化。
这次讨论带来了一些非常深刻的洞察和有价值的数据，我也想分享一下我个人在这个领域看到的一些情况。以下是这次转变中最让我关注的几个方面，以及它在实践中意味着什么。
要点 1：语言变了，但真正棘手的问题并没有变
Agent 式 AI 正在快速发展：客户不再根据传统的搜索基准或指标来评估平台。相反，他们会问："这个解决方案能否成为我的 agent 可以信赖的检索和上下文层？"
以低延迟、大规模地检索任何数据为目标的基本挑战并不是什么新问题，但发生变化的是谁在消费这些信息。过去，人类用户会阅读搜索结果。现在，自主 agent 在推理循环中运行，每一步检索都会影响下一步。
这种演进正在快速加速。模型上下文协议（MCP）已经成为将 agent 与企业数据和工具连接起来的事实标准，而诸如 Agent2Agent（A2A）这样的协议，则正在为 agent 之间的协作做同样的事情。对于许多团队而言，通过标准的 agent 接口暴露数据，如今已经成为一项基础性的架构决策，就像十年前构建索引一样。精准度、延迟和数据新鲜度不再是"锦上添花"的优化项，而是关键基础设施。
要点 2：准确性是决定性挑战
在企业能够真正依赖 agent 执行操作之前，他们需要信任这些 agent 产生的答案。而目前，这种信任鸿沟仍然很大。
IDC 的研究对此进行了清晰的量化：只有 12% 的公司表示，他们始终对主要发现工具所提供答案的事实准确性充满信心。正如 Amy 在网络研讨会上指出的那样，这种缺乏信任的情况正在直接拖慢 agent 式 AI 的部署。超过 50% 的公司仍然难以从早期试验阶段迈向全面生产，这主要是因为他们不信任 agent 的输出。
当 agent 在推理循环中运行时，这一信任挑战变得更加关键。一次返回过时、不完整或不相关数据的检索，不只是导致一个错误答案；它还会产生累积效应。agent 会基于这个存在缺陷的基础继续做出决策，而下游影响会迅速扩大。
我在网络研讨会上这样总结：你的检索层需要提供最新的数据。当它无法做到这一点时，agent 的决策质量会迅速下降。这就是为什么实时数据摄取不再是可选项。
从搜索到 agent：客户预期如何在 2026 年重塑 AI 平台 part 1_哔哩哔哩_bilibili
要点 3：搜索仍然是引擎，但它只是在驱动更大的东西
我经常听到的一种误解是，搜索已经被 agent 取代了。事实并非如此。搜索仍然是基础。搜索已经从简单的数据检索发展到更加面向行动的能力。如今，它已经成为 agent 所依赖的上下文发现层。
不同之处在于，传统搜索被设计用于处理独立查询，并返回一个经过排序的结果列表。而 agent 式检索则需要在单个工作流中支持多跳查询。一个问题的答案会影响下一个查询，而这一切都需要实时、大规模地完成。
现代检索能力已经从简单的查找转向主动推理，在这一过程中，agent 会动态检查查询、确定所需的数据，并不断迭代，以确保信息足够充分。由于仅依靠向量相似度不足以满足生产环境中的 agent 式工作负载，因此组织必须实现集成系统，将混合检索、重排序和安全访问控制结合起来。
这种转变要求采用完全不同的基础设施。如今，检索层的质量会直接影响构建在其之上的 agent 的质量。
要点 4：上下文工程是一个被低估的准确性关键
如果准确性是目标，那么上下文工程就是实现这一目标的方法。
人类在搜索信息时，会携带领域知识。他们理解自己正在寻找的信息所处的上下文，但 agent 不具备这种能力。这些上下文必须以合适的粒度，在推理循环中的恰当时机，明确地提供给 agent。
这就是事情变得复杂的地方。正如我在网络研讨会上解释的那样，你需要管理所有事情：文档中正确的文本块、来自各种系统的正确元数据，以及在正确时间提供给 agent 的正确数据。如果上下文不够精准，agent 就会开始产生幻觉，输出也会变得不可靠。
这种现象现在有了一个名字：上下文腐化（context rot）。上下文腐化是指由于无关信息过度饱和，耗尽模型的注意力预算，从而导致 agent 的推理性能下降，并影响其输出准确性的现象。更大的上下文窗口无法解决这个问题；它们只是将失败点向后移动。这就是为什么上下文工程实际上已经取代提示工程，成为决定 agent 质量的核心学科。
上下文工程涵盖检索、相关性、重排序、文本分块策略、元数据管理等多个方面。这并不是一项光鲜亮丽的工作，但它决定了 agent 的质量究竟是成功还是失败。而当团队依赖彼此割裂的单点解决方案时，这也正是他们容易遇到问题的地方。
www.bilibili.com/video/BV1uy...
要点 5：拼接单点解决方案的隐藏成本
AI 单点解决方案一开始可能很有吸引力，因为它们承诺能够快速满足特定需求。但在实际应用中，它们往往会导致系统蔓延，从而拖慢 AI 的部署速度。
Amy 在网络研讨会上指出了这一点：当你将多个向量数据库、重排序模型和索引拼接在一起时，就会产生一种新型的应用蔓延。你本来是想简化 AI 架构，最终却得到一个碎片化的系统，不仅维护成本高，而且耗时。
这是我在客户评估各种方案时亲眼看到的情况。最初，许多团队认为自己可以依赖大型上下文窗口，或者将多个单点解决方案拼接在一起。但他们很快就不得不付出代价：你提供给模型什么，以及你如何将这些信息提供给模型，与模型本身同样重要。
但系统蔓延并不是唯一的成本。还有第二笔更加直接的账单会每个月到来：token 成本。早期，许多团队试图完全跳过检索层，将所有内容都塞进大型上下文窗口中。但当规模达到 agent 所需要的程度时，这种方式的经济性就无法成立。
解决方案不是继续添加更多彼此割裂的工具，并认为模型和工具调用就能让 agent 进入生产环境。而是投资于一个统一的平台，在所有数据源之间统一处理检索、相关性、上下文工程和数据管理。这正是客户现在所要求的，因为这才是真正能够为他们在 agent 上的投资带来投资回报率的方式。
技术领导者在评估 agent 式 AI 平台时应该优先关注什么
那么，在评估 agent 式 AI 平台时，领导者应该关注什么？Amy 和我在网络研讨会上总结了几个关键标准：
-
**大规模场景下的成本效率：**Token 经济性决定了 agent 的投资回报率。平台应该只向模型提供最相关的上下文，而不是由于 skill 和工具的蔓延，导致每次调用都不得不为臃肿的上下文窗口付费，这样才能随着使用量增长保持成本可预测。
-
**面向 AI 的数据：**在大规模场景下管理结构化数据、非结构化数据和元数据，是构建可靠 agent 式系统的基础。
-
**从概念验证到生产环境的速度：**从概念验证扩展到生产环境，是大多数团队面临困难的地方。能够缩短这一差距的平台至关重要。
-
**信任与安全：**审计日志、合规性以及安全的企业数据访问都是不可妥协的要求。
-
**路线图一致性：**选择一家愿景与你未来需求保持一致的合作伙伴进行投资。
-
**开发者赋能：**让开发者能够利用基于搜索和检索的上下文工程平台，降低 token 成本，并提高生产环境用例中的 agent 准确性。
正如我在网络研讨会上所说，我们正在从 agent 式 AI 的愿景阶段迈向生产架构阶段。现在做出的决策，将决定你未来构建用例的速度，以及这些系统能够实现多好的扩展性。如果你想了解 Elastic 如何在统一平台中处理检索、上下文工程和可观测性，可以观看我们的点播网络研讨会。
本文中所描述的任何功能或特性的发布及时间安排均由 Elastic 自行决定。任何目前尚未提供的功能或特性都可能无法按时交付，甚至可能不会交付。
在这篇博客文章中，我们可能使用或引用了由各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具，对于其内容、运行或使用不承担任何责任，也不对因你使用此类工具而可能产生的任何损失或损害承担责任。使用 AI 工具处理个人信息、敏感信息或机密信息时，请务必谨慎。你提交的任何数据都可能被用于 AI 训练或其他用途。我们无法保证你提供的信息会得到安全或保密的处理。在使用任何生成式 AI 工具之前，你应该了解相关工具的隐私政策和使用条款。
Elastic、Elasticsearch 及相关标志是 Elasticsearch B.V. 在美国及其他国家和地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。
原文：From retrieval to agents: 5 takeaways on production architecture for AI agents | Elastic Blog