Elastic Agent Builder：我们如何让 AI 代理学会管理自己的上下文-开发者社区

作者：来自 Elastic Anish Mathur, Deepti Dheer 及 Evan Castle

Elasticsearch 9.4 中的 Agent Builder 提供动态加载的技能（skills）、对话上下文存储、选择性压缩（selective compaction）以及外部连接器（external connectors），从而将 token 成本降低 40%，并让代理能够自行处理上下文管理。

Agent Builder 现已正式发布。可以开始 Elastic Cloud 试用，并查看 Agent Builder 的相关文档。

每个构建 agent 的开发者都必须回答一个问题：agent 应该知道什么，以及什么时候知道？通常的起点很简单：写一个 system prompt，连接几个工具，agent 就可以工作了。但随着范围扩大，你会加入更多指令、数据源和工具，运行时间也会变长。最终上下文窗口被填满，输出质量下降，token 成本上升。上下文管理变成一个核心问题。本文分享我们如何将上下文处理内建到 agent 中，使其能够自行决定要获取什么、要总结什么、要丢弃什么，以及 memory 如何在步骤之间传递。

9.4 中的 Agent Builder 将上下文变成 agent 自己要解决的问题，而不是开发者的负担。skills 提供可复用的指令，并按需加载，因此只有当前任务所需内容会进入上下文。大规模结果会被放入 conversation context store，而不是直接堆在 prompt 中。对于长任务，上下文会被选择性压缩，从而避免 agent 偏移（drift）。同时系统会持续监控 token 和 turn 数。connectors 则负责访问企业数据所在的位置。

所有这些设计的目标都是一致的：只在需要的时候加载需要的上下文。我们在内部观察到，这可以将 token 成本降低最高 40%，并在原本会退化的数据场景中保持 agent 上下文的稳定性。

让 agent 知道你所知道的东西

有三个上下文问题反复出现：管理臃肿的 prompt、执行复杂操作，以及控制企业数据源。

首先，prompt 变得臃肿，是因为每条指令都必须放在其中。skills通过按需加载并减少输入 token 来解决这个问题。skills 提供结构化描述，说明 agent 在特定任务中应该如何运作和行动。Agent Builder 内置了一些用于常见数据分析模式的 skills，但真正的价值在于用户也可以创建自定义 skills。安全团队可以把他们的分诊（triage）流程编码为一个 skill，SRE 团队可以描述他们希望根因分析如何进行，开发者可以编码他们的 API 设计规范和错误处理约定。skills 可以在多个 agent 之间复用和共享，这意味着一个团队有效的模式不需要被下一个团队重复实现。

在实践中，这看起来是这样的：团队负责人定义一个 “总结此事件” skill，其中包含他们关心的流程、组织使用的严重等级分类，以及 runbook 期望的输出格式。团队中的任何人都可以在聊天输入中调用它，并通过自动补全选择该 skill。skills 遵循 Agent Skills 开放格式，因此你可以从共享库中获取它们、自己编写，或者用你选择的 agent 来创建 skills。

在内部测试中，我们发现，将指令从 agent prompt 中移除并放入动态加载的 skills 中，在测试数据集上可使输入 token 使用量减少 21% 到 39%。关键的架构改进在于：skills 及其关联工具只在 agent 需要时才加载。所有其他 skills 都以轻量级 “占位符（stubs）”形式存在，仅保留名称和描述，几乎不消耗上下文。

与你的数据聊天并对其执行操作（仪表板、工作流、查询等）：Agentic 任务不会长期保持简单。Agent Builder 现在具备对 Kibana 对象的上下文感知能力。通过 agentic 仪表板创建，用户可以用自然语言描述他们想看到的内容，agent 会生成包含面板、可视化、查询等完整内容的仪表板。用户还可以通过对话进行调整：“按地区拆分”、“添加最近 7 天的过滤器”、“把柱状图换成折线图”。

仪表板、告警和规则也可以作为输入。一旦仪表板创建完成，它就可以从 agent 的上下文中被检索出来。这开启了 agent 的“执行”能力。一旦仪表板或告警进入上下文，agent 就可以对其进行修改、扩展或创建新的对象。agent 可以推理数据展示的含义，提出后续分析建议，或根据所看到的内容调整仪表板。这形成了一个反馈循环：用户表达意图，agent 生成可视化对象，而用户和 agent 都可以基于该对象进行共同推理。

对于业务分析师和运营团队来说，这极大地缩短了 “我有一个关于数据的问题” 和 “我有一个可以分享给团队的仪表板” 之间的距离，把原本需要数小时的手工工作压缩为几分钟的对话。

最后，将企业数据用于上下文本身就会带来一种“无需额外声明的治理机制”。Connectors负责打通 Elastic 之外的数据来源。我们为 Google Drive、Salesforce 和 Slack 等系统提供了预构建的基于 OAuth 的连接器。这里的设计原则非常关键：数据仍然留在原始位置。agent 通过 connector 在用户自身权限范围内检索数据。agent 不会为了回答问题而在新的位置复制和积累企业数据副本。

这一点比表面看起来更重要。企业数据治理不仅仅是合规清单上的一个勾选项，它更像是一种承重基础设施，只有在失效时团队才会意识到它的存在。当 agent 开始绕过这些治理机制，在向量存储和上下文窗口中不断积累数据副本时，你实际上已经悄悄创建了一种新的数据扩散形式 —— 安全团队未曾批准，审计日志也无法捕捉。使用 connector 的方式通过约束来消除这种风险：如果数据不发生迁移，就不会出现在不该出现的地方。用户权限会随着每一次查询一起生效，因为查询始终发往数据源本身，而不是缓存副本。这样你就得到了一个真正能够在企业数据上工作的 agent。

确保 agent 不会超出上下文窗口

给 agent 提供过多上下文会引入一个新问题。一名安全分析师在调查复杂威胁时，可能会拉取数十条告警，在多个索引之间进行关联，并与 agent 反复交互二三十轮。在某个时刻，你会超过上下文窗口的承载能力，从而降低模型响应质量。问题在于，每一次检索调用都会增加用户请求延迟并推高基础设施成本，而单次用户交互可能会触发数十次这样的调用。

我们构建了一个用于检索结果的上下文存储。当 agent 从索引中检索数据时，结果可能非常大并挤占上下文窗口。我们引入了一个临时存储，将查询结果保存在内存的 “文件存储”中，仅在需要时才将其加载到活跃上下文中。这样可以让对话持续进行并处理多个相关数据集，而不会撑爆上下文。同时，我们还在优化检索结果本身，引入 top snippets 检索，在测试中实现了 27% 到 34% 的 token 使用量下降。

我们还为更长的交互引入了智能上下文压缩机制：随着对话的进行，agent 会管理哪些内容保留在活跃上下文中，哪些内容被压缩为摘要，并在需要时可以重新检索。这不是简单的截断，而是选择性压缩，能够保留最可能在下一轮对话中重要的信息。

这使得 agent 能够处理更大的结果集、更复杂的查询以及更长的对话，而不会让 token 成本随着每一轮线性增长。借助上下文压缩机制，即使是 30 轮以上的对话，context window 也能保持在可控范围内，而不会迅速膨胀到最大限制。

对于执行多步骤调查或摘要任务的团队来说，这之间的差别在于：一个 agent 可以在第 30 轮对话中仍然保持一致性，而另一个在第 12 轮就开始出现自相矛盾。

监控能力：在 9.4 中，我们还为 agent 发布了监控功能，用于跟踪 token 使用情况，并提供 API 来监控对话轮次和工具调用。这一点非常重要，因为 agent 并不是静态的。它们的行为会随着接收到的上下文以及调用的工具而变化，如果没有这些行为模式的可视化，成本和性能优化就只能依赖猜测。

Agent 消费模型

为了支持这些新能力，我们引入了一种 agent 定价模型，使其与用户从 agent 获得的价值以及扩展方式直接对齐。Agent Builder 的使用将按 Executions（执行次数）计量。在 Elasticsearch 中，每月前 1,000 次 executions 免费；在 Elastic Security 和 Observability 项目中，每月前 10,000 次免费。

一次 Agent Builder execution 表示 agent 完成的一轮交互。在大多数情况下，发送一条聊天消息并获得成功响应会计为一次 execution。对于需要大量处理的消息，将根据输入 token 总量按多个 executions 计算，并以每 50,000 input tokens 为一个单位分组。例如，一个需要 130,000 input tokens 的深度调查任务将计费为 3 次 executions。该模型确保你的使用成本与 agent 交付的价值保持一致，并且随着 agent 上下文效率的提升而变得更具成本效益。