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

为演示构建一个 AI 智能体，与为数千万开发者运营一个智能体，是截然不同的工程问题。Postman 着手构建 Agent Mode（智能体模式），这是一种跨 API 测试、文档、发现和实现的 AI 原生工作方式。团队最初认为模型质量和提示词设计是最难解决的问题。更深层的挑战来自于将一个智能体集成到一个拥有多年界面驱动假设、广阔功能面和专业概念的成熟产品中。

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

我们还解释了 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（护栏）在个人信息到达底层大型语言模型 (LLM) 之前对其进行脱敏处理。企业管理员可以在 Agent Mode 的护栏设置中启用此功能。

处理工具蔓延

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

许多现实世界的工作流程需要长序列的工具调用。即使每一步都很快，整体体验却感觉缓慢，因为每次动作都必须返回给模型，才能开始下一步。用户看着智能体逐步执行那些他们在心理上将其归为一个单一操作的动作。

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

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

图 3：根智能体查询工具嵌入的向量数据库，将 170 多个工具缩小到与请求相关的约 15 个。然后，它将这些工具交给上下文隔离的子智能体，以便模型仅看到完成任务所需的工具。

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

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

暴露基于模式的读取

对于 API Catalog 等产品，Postman 将多个狭窄视图整合为一个查询工具。这些产品跨越多项服务公开结构化数据，如服务正常运行时间、测试结果和端点响应时间。

鉴于底层 ClickHouse 表的模式，智能体可以生成包含连接（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 的演进，很明显系统必须聚合三个不同的组件，每个组件解决不同的问题。

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

将所有这些编码到静态提示词中是不可行的，而且其中大部分与特定查询无关。对于初始种子数据，团队使用 Postman 的学习中心生成了简洁的特定功能文章。在运行时，Agent Mode 根据传入的查询和可用上下文选择知识文章。例如，当用户选择模拟服务器时，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 无需重建集成即可采用受支持的模型。有关各 AWS 区域支持的模型，请参阅 Amazon Bedrock。

跨区推理以实现高吞吐量

开发者流量具有突发性特征，为单个 AWS 区域的峰值需求进行资源预配可能成本高昂。Agent Mode 利用 Amazon Bedrock 的跨区推理功能，根据推理配置文件（inference profile）中定义的目标区域自动路由请求。在运行时，应用程序将选定的推理配置文件 ID 或 Amazon 资源名称（ARN）作为 modelId 传递给 Converse 或 InvokeModel 接口。配置文件、适用的 AWS Identity and Access Management (IAM) 和服务控制策略以及配额必须允许 Bedrock 可能选择的每一个目标区域。

1. 地理推理配置文件仅将请求路由到定义地理范围（如美国或欧盟）内受支持的区域。此选项在提高吞吐量的同时，设定了配置的地理处理边界。
2. 全局推理配置文件可在全球范围内受支持的目标区域间路由请求，从而在流量激增期间提供额外的吞吐量。仅当工作负载不需要地理受限的处理边界时，才适用此选项。

Postman 可根据工作负载选择推理配置文件：若追求最大可用吞吐量，则选用全局配置文件；若处理过程必须保留在配置文件定义的地理范围内，则选用地理配置文件。这一选择在每个 Bedrock 推理请求所使用的 modelId 中明确体现。

# Converse 请求示意图
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 生成时间。

# Converse 内容块中的示意性缓存检查点
{"cachePoint": {"type": "default", "ttl": "1h"}}  # 稳定核心
{"cachePoint": {"type": "default", "ttl": "5m"}}  # 可变层

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

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

1. 像管理 token 一样谨慎地管理工具。动态选择每个任务暴露的工具。在 Postman 的测试中，随着可见工具集变大，工具选择错误也随之增加。
2. 优先使用感知模式的读取而非工具泛滥。很好地建模你的数据，让智能体去查询它。
3. 将智能体操作与界面状态解耦。如果某个工具需要打开标签页，说明智能体是在导航界面，而不是直接在数据上进行推理。
4. 刻意设计上下文。专门设计的上下文处理器优于每次序列化渲染模型。
5. 将上下文窗口视为稀缺资源。截断和扩展策略是一个一等的设计问题，而非事后考虑。
6. 随功能发布文档。RAG 知识库只有在与产品同步演进时才能保持有用。
7. 在 Bedrock 上进行路由和缓存。将每个工作负载匹配到合适的 Claude 模型，根据吞吐量和地理需求选择跨区域推理，并对稳定的提示词前缀应用分层缓存。

结论

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

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

欲了解更多信息，请参阅 Amazon Bedrock 文档，包括有关跨区域推理、提示词缓存以及数据保护和保留的指导。如需相关的实施指导，请阅读《在 Amazon Bedrock 上有效使用提示词缓存》以及 AWS Machine Learning Blog 上的《Amazon Bedrock 宣布全球跨区域推理以提高吞吐量》。要探索该产品，请参阅 Postman Agent Mode 文档。

Postman 的生产实现是专有的，并未作为公共示例仓库提供。

关于作者