Postman 如何在 Amazon Bedrock 上为 4000 万开发者运行 Agent Mode

为演示构建一个 AI 智能体，与为 4000 万开发者运营一个智能体，是完全不同的工程问题。Postman 着手构建 Agent Mode，这是一种 AI 原生的工作方式，覆盖 API 测试、文档、发现和实现。团队原本预期模型质量和提示词设计会是最难的问题。而更深层挑战来自将智能体集成到一个成熟产品中——这个产品带有多年界面驱动的假设、广泛的功能面和专有概念。

在这篇文章中，Postman 和 AWS 描述了在让成熟产品对 AI 智能体可读的过程中形成的架构模式。这些模式包括控制工具泛滥、暴露基于 schema 的读取，以及将上下文而非能力视为首要瓶颈。

我们还将解释 Agent Mode 如何使用 Amazon Bedrock 来实现模型灵活性、按地理范围划分的跨区域推理、依赖模型的零数据保留以及多层级提示词缓存。这些经验可以帮助团队将生产级智能体从原型推进到实际应用。

Postman 为何构建 Agent Mode

Agent Mode 是 Postman 的入口，让用户以 AI 原生的方式跨测试、文档、发现和实现来使用该产品。Postman 已经演化了 11 年，开发者和用户习惯于通过界面来定位信息：展开侧边栏、查看标签页、打开请求。为智能体重新构建这种认知能力，暴露了产品 API、用户体验和产品知识分布中的结构性假设。智能体是对数据进行推理，而不是在屏幕上导航。图 1 展示了 Agent Mode 如何直接作用于应用程序。

图 1：Agent Mode 直接作用于 Postman 应用程序。在此示例中，它打开了一个拉取请求并提出后续步骤，而无需用户在界面中导航

Agent Mode 运行在 Amazon Bedrock 上，它为智能体背后使用的基础模型提供托管访问。支持 Postman 的全球开发者社区带来了多变且对延迟敏感的需求，以及剧烈的流量突发。借助 Amazon Bedrock，Postman 可以扩展这一生产工作负载，而无需自行运营模型服务基础设施，同时保留了模型选择的灵活性以及对吞吐量、地理处理和成本的控制。图 2 给出了生产架构的高级视图，后续章节将逐一考察其组成部分。

图 2：Postman Agent Mode 结合了客户端工具、智能体编排、专门构建的上下文和 Amazon Bedrock 模型推理。工具按任务划分作用域，修改应用状态的操作仍需用户批准

人工监督是生产设计的一部分。Agent Mode 在执行修改应用状态的操作前需要用户批准。Postman 还将可用工具限定在当前任务范围内，选择专门构建的上下文，并应用依赖模型的数据保留设置。这些控制措施减少了意外操作和不必要的数据暴露，同时生产测试和监控仍然必不可少。作为一项负责任的 AI 控制措施，Postman 使用 Amazon Bedrock Guardrails 在个人可识别信息（PII）到达底层大语言模型（LLM）之前对其进行脱敏。企业管理员可以在 Agent Mode 的护栏设置中开启此功能。

应对工具泛滥

在智能体模式（Agent Mode）中，工具定义了智能体在 Postman 内部的行为方式。早期，团队倾向于高度原子化的工具：小而精确的操作，例如打开一个请求、更新某个字段，或获取特定的元数据。这种方式在早期迭代中支持了正确性和可控性，但也暴露出几个问题。

许多真实世界的工作流需要一长串工具调用。即使每一步都很快，整体体验仍显得缓慢，因为每个操作都必须先返回给模型，才能开始下一个操作。用户只能看着智能体一步步执行他们心中早已归为一组单次操作的动作。

在 Postman 的测试中，一旦可见工具集超过约 40 个工具，工具选择错误就会增加。智能体可能会调用不存在的工具、在架构（schema）有效的情况下传入错误的参数，或选择看似语义合理但在上下文中错误的工具。更大或更新的模型减少了这种行为，但并未消除它。

超过一定的工具集规模后，暴露更多工具反而会降低智能体的有效性。当前架构会根据需求和上下文选择工具，并隔离各个执行线程。模型只能看到与当前任务相关的工具。图 3 展示了这一动态选择过程。

图 3：根智能体查询一个工具嵌入向量数据库，将 170 多个工具缩减到约 15 个与请求相关的工具。随后它把这些工具交给一个上下文隔离的子智能体，因此模型只看到该任务所需的工具

一个更微妙的问题是，许多客户端 API 与界面状态隐性耦合。修改请求的工具需要某些元素处于打开状态，而另一些工具则会作为副作用打开新标签页。智能体必须打开一个请求标签页才能读取它，模仿界面交互而不是对数据进行推理。Postman 正在积极地将工具与标签页解耦，其 Native Git 功能大量采用了这种方式。例如，智能体模式现在可以在后台发送请求而无需打开标签页，尽管仍需要用户批准。

开发者要点：把你的工具目录视为上下文预算的一部分。为每个任务动态限定暴露给模型的工具范围，并将“智能体能做什么”与“UI 恰好打开了什么”解耦。

暴露基于架构（schema）的读取

对于 API Catalog 这类产品，Postman 将多个狭窄的视图整合为一个查询工具。这些产品暴露结构化数据，例如众多服务的运行时间、测试结果和端点响应时间。

借助底层 ClickHouse 表的架构（schema），智能体可以生成带有 JOIN 和 WHERE 子句的复杂查询。这大幅减少了回答一个分析问题所需的独立工具数量：

SELECT toString(service_id) AS service_id,
    countMerge(total_events_state) AS total_requests,
    countMerge(error_events_state) AS total_errors,
    round(countMerge(error_events_state) * 100.0
        / countMerge(total_events_state), 4) AS error_rate_pct,
    avgMerge(avg_latency_state) AS avg_latency_ms,
    quantileMerge(0.95)(p95_latency_state) AS p95_latency_ms
FROM http_events_summary_1d
WHERE service_id IN ('...list of service IDs')
    AND bucket_1d >= today() - 7
GROUP BY service_id
HAVING p95_latency_ms < 100
    AND total_requests > 0
ORDER BY error_rate_pct DESC;

通过这种方式，工程工作从为每个问题构建一个工具转变为一次性把数据建模好。这样，智能体能够生成的查询种类之丰富，远非团队当初能逐一枚举为独立工具的规模可比。

开发者要点：在拥有良好结构化数据的地方，给智能体提供对查询引擎的架构感知读取权限，而不是提供大量单一用途的读取工具。你以工具数量换取数据建模，从而获得更好的扩展曲线。

上下文才是真正的瓶颈

Postman 最初以为缺失的工具会是最大的障碍。而实践中，缺失或不完整的上下文造成的失败比缺失能力更多。

上下文是智能体对用户在 Postman 中所处位置、哪些实体处于活动状态以及已经建立了什么状态的理解。当上下文错误或缺失时，即使是正确的工具也会失效。图 4 区分了提供给智能体的两种上下文形式。

图 4：两种上下文共同供给智能体。宽泛而浅层的背景上下文是自动收集并为提示词进行精简的。深入而聚焦的选中上下文由用户选择，并通过针对每种实体类型的专用处理器路由。每个处理器将实体提炼为智能体所需的信息。

这一挑战是结构性的。11 年来，开发者和用户学会了通过界面查找信息。为智能体重构这种感知需要多次迭代，才能确定每个工作流中哪些内容重要、哪些是噪音。直接序列化现有的界面数据模型无法产生有用的上下文，因为这些对象是为渲染和数据传输而设计的，而不是为推理设计的。因此，Postman 构建了专用的上下文处理器，将每个实体提炼为智能体需要了解的信息。

随着越来越多的对象配备了处理器，截断成为下一个问题。许多字段包含开放式的用户生成数据，包括请求描述、OpenAPI 规范和请求载荷。这些数据可能挤占上下文窗口。在大规模场景下，谨慎管理上下文预算至关重要，这也支持了团队正在探索的基于文件系统的方法，即每个处理器无需自定义的截断和扩展逻辑。

开发者要点：不要把渲染数据模型喂给模型。构建有特定用途的上下文处理器，并将上下文窗口视为一种稀缺的、需要主动管理的预算。早在模型达到上限之前，噪音就已经挤占了信号。

整合起来

随着 Agent Mode 的演进，系统显然需要聚合三个不同的组件，每个组件解决不同的问题。

客户端工具位于 Postman 应用程序中，代表智能体可以执行的最终操作，例如打开请求、修改设置、运行集合和检查身份验证。Agent Mode 也使用服务端工具来执行网页搜索和智能体循环管理等功能，但大多数工具作用于 Postman 应用程序。
通用智能体指令定义系统级行为，包括 Agent Mode 应该有多主动、它如何传达不确定性，以及它具备哪些基础产品知识。
知识库采用检索增强生成（RAG）方法。Postman 拥有庞大的产品面，涵盖多种请求协议、Mock 服务器、监控器、文档、API Network、工作区治理、变量、辅助工具、代码生成、请求设置和集合运行。

将所有这些信息编码到静态提示词中并不可行，而且其中大部分内容与特定的查询无关。在初始填充阶段，团队使用 Postman 的 Learning Center 生成了针对各项功能的精简文章。在运行时，Agent Mode 会根据传入的查询和可用的上下文来选择知识文章。例如，当用户选择一个 mock 服务器时，Agent Mode 会自动注入相关文章。这使得智能体在默认情况下保持轻量，同时在需要时提供深度支持。知识库会随应用程序一起演进，因此团队可以在发布新功能时同步发布 Agent Mode 文档。

在 Amazon Bedrock 上运行 Agent Mode

前文所述的三个组件最终都归结为同一个运行时操作：调用基础模型（FM）进行推理。以 Postman 的规模来看，其流量呈突发性且由开发者驱动。路由、缓存和地理处理控制可帮助 Postman 应对流量突发、管理推理成本并满足特定工作负载的处理需求。Amazon Bedrock 提供了在这里最为重要的四项能力。

跨 Claude 系列的模型灵活性

Agent Mode 并不绑定于某一个模型。通过 Amazon Bedrock 模型推理 API，Postman 可以访问受支持的 Anthropic Claude 模型，并将每个工作负载路由到合适的模型。较快的模型可以服务于高吞吐量、对延迟敏感的交互，而更大的模型可以处理复杂推理，此时质量比成本更重要。在受支持的 Claude 模型之间切换主要是配置上的更改，而不是新的集成。这种灵活性直接应对了前面所述的工具蔓延和上下文难题。在 Postman 的测试中，更新、更大的模型减少了工具幻觉，而且 Postman 无需重建集成即可采用受支持的模型。参见 Amazon Bedrock 中按 AWS 区域列出的受支持模型。

用于高吞吐量的跨区域推理

开发者流量波动很大，而在单个 AWS 区域内按峰值需求预配容量可能成本高昂。Agent Mode 使用 Amazon Bedrock 跨区域推理，在推理配置文件定义的目标区域之间自动路由请求。在运行时，应用程序将选定的推理配置文件 ID 或 Amazon 资源名称（ARN）作为 modelId 传入 Converse 或 InvokeModel。配置文件、适用的 AWS Identity and Access Management（IAM）和服务控制策略以及配额必须允许 Bedrock 可能选择的每个目标区域。

地理推理配置文件仅在特定地理区域（如美国或欧盟）内受支持的区域之间路由请求。此选项将更高的吞吐量与已配置的地理处理边界相结合。
全球推理配置文件可以在全球受支持的目标区域之间路由请求，以便在流量突发期间提供额外的吞吐量。它们仅适用于工作负载不需要地理受限处理边界的情况。

Postman 可以为每个工作负载选择推理配置文件：使用全球配置文件以获得最大的可用吞吐量，或者当处理必须保留在配置文件所定义的地理范围内时使用地理配置文件。这一选择明确体现在每个 Bedrock 推理请求所使用的 modelId 中。

# Schematic Converse request
response = bedrock_runtime.converse(
    modelId="<geographic-inference-profile-id-or-arn>",
    messages=messages,
    system=system_blocks,
)

数据驻留与企业级控制

对于企业客户而言，允许的处理地理位置可能与吞吐量同等重要。地理推理配置文件会将 Bedrock 的路由限制在该配置文件在所选地理区域内支持的目标区域。这并不意味着推理在 Postman 自己的 AWS 环境中运行。Amazon Bedrock 会在该配置文件符合条件的 AWS 区域中处理请求，数据在传输和静态状态下均经过加密。AWS 表示，Bedrock 不会使用提示词和补全结果来训练 AWS 模型，也不会将其分发给第三方。Postman 为受支持的 Agent Mode 模型配置了零数据保留，将 data_retention_mode 设置为 none。可用性和行为因模型而异，因此必须对照当前的 Amazon Bedrock 数据保护与保留文档逐一核对每个生产模型。

利用提示词缓存控制成本

生产环境中的智能体每一轮都会重新发送大量稳定上下文，包括系统指令、通用智能体行为、核心工具集、选定的知识以及对话上下文。每次请求都重新处理未变化的前缀会带来可避免的延迟和成本。

Agent Mode 使用 Amazon Bedrock 提示词缓存来复用稳定的提示词前缀。近乎不可变的核心部分（包括系统提示词、智能体指令和核心工具定义）使用一小时的缓存检查点。变化较多的上下文则使用五分钟的检查点，该检查点在缓存命中时刷新。Bedrock 要求生命周期较长的检查点出现在生命周期较短的检查点之前。较短的层级适合交互式会话，因为闲置的上下文会过期，而一小时层级可以通过多次读取来摊销其较高的缓存写入价格。缓存收益和受支持的 TTL 取决于所选模型。团队可以通过 cacheReadInputTokens 和 cacheWriteInputTokens 用量字段验证行为，并针对自己的工作负载测量首个 token 的生成时间。

# Schematic cache checkpoints in Converse content blocks
{"cachePoint": {"type": "default", "ttl": "1h"}}  # stable core
{"cachePoint": {"type": "default", "ttl": "5m"}}  # variable layer

开发者要点：将推理视为路由与缓存问题，而不仅仅是模型选型决策。按工作负载选择 Claude 模型，选择合适的跨区域推理配置文件，并根据各层内容的变更频率用相应的 TTL 缓存稳定的提示词前缀。

在生产环境中扩展智能体的最佳实践

以下经验提炼自 Postman 的实践历程，供在 Amazon Bedrock 上构建的开发者参考：

像管理 token 一样精细地管理工具。按任务动态选择暴露的工具。在 Postman 的测试中，可见工具集变大后，工具选择错误随之增加。
优先使用感知模式的读取，而非盲目增加工具。好好为数据建模，让智能体直接查询它。
将智能体操作与界面状态解耦。如果某个工具需要打开的标签页，智能体就是在操作界面，而不是直接对数据进行推理。
有意识地设计上下文。专门构建的上下文处理器总是胜过序列化你的渲染模型。
把上下文窗口当作稀缺资源来管理。截断与扩展策略是一等设计问题，不能事后补救。
随功能一同发布文档。RAG 知识库只有与产品同步演进，才能持续发挥作用。
在 Bedrock 上进行路由与缓存。将每个工作负载匹配到合适的 Claude 模型，根据吞吐量和地理需求选择跨区域推理，并对稳定的提示词前缀应用分层缓存。

结论

构建智能体模式（Agent Mode）要求 Postman 直面大型语言模型能力与成熟产品结构之间的差距：界面假设、耦合的客户端、庞大的工具目录，以及分散在文档和团队中的知识。动态工具选择、基于架构的读取，以及深思熟虑的上下文工程，成为在 Postman 开发者社区规模下可复用的模式。Amazon Bedrock 提供了托管模型访问、跨区域推理、依赖模型的保留控制以及支持生产架构的提示词缓存。

无论您是在构建第一个智能体，还是在扩展现有智能体，这些模式都可以帮助团队避免常见的智能体集成与扩展挑战。

要了解更多信息，请参阅 Amazon Bedrock 文档，其中包括关于跨区域推理、提示词缓存和数据保护与保留的指南。相关实施指南，请阅读 AWS 机器学习博客上的 Effectively use prompt caching on Amazon Bedrock 和 Amazon Bedrock announces global cross-Region inference for increased throughput。要探索该产品，请参阅 Postman Agent Mode 文档。

Postman 的生产环境实现属于专有内容，不作为公开示例存储库提供。