Postman 如何在 Amazon Bedrock 上为 4000 万开发者运行 Agent Mode
How Postman runs Agent Mode for 40 million developers on Amazon Bedrock
Postman 在 Amazon Bedrock 上运行 Agent Mode，为 4000 万开发者提供覆盖 API 测试、文档、发现和实现的 AI 原生工作方式。文章介绍了动态筛选工具、基于 schema 的数据读取和专用上下文处理器，并说明如何按工作负载选择 Claude 模型、使用跨区域推理及分层提示词缓存。
文章梳理了 Postman 将 Agent Mode 用于大规模生产时遇到的工具膨胀与上下文管理问题，并给出动态筛选工具、按需构造上下文等架构做法。
为演示而构建一个 AI 智能体，与让它服务于4000 万名开发者，是两种不同的工程问题。Postman 着手构建Agent Mode，这是一种 AI 原生的工作方式，涵盖API 测试、文档、发现和实现。团队原以为模型质量和提示词设计会是最棘手的问题。更深层的挑战来自将智能体集成到一款成熟产品中：这款产品历经多年发展，存在许多由界面驱动的假设，功能覆盖面广，并且包含专门的概念。
在本文中，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 现在可以在后台发送请求，无需打开标签页，但仍需获得用户批准。
构建者须知： 将工具目录视为上下文预算的一部分。针对每项任务动态限定向模型开放的工具范围，并将“智能体能做什么”与“界面当前打开了什么”解耦。
开放基于架构的读取能力
对于 API Catalog 等产品，Postman 将多个狭窄的视图整合为一个查询工具。这些产品会公开结构化数据，例如各项服务的运行时间、测试结果和端点响应时间。
给定底层 ClickHouse 表的架构后，智能体可以生成包含联接和 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 的产品涵盖广泛，包括多种请求协议、模拟服务器、监控器、文档、API Network、工作区治理、变量、辅助工具、代码生成、请求设置和集合运行。
将所有这些内容编码到静态提示中并不可行，而且其中大部分与特定查询无关。为了进行初始信息填充，团队使用 Postman 的 Learning Center 生成简明、针对特定功能的文章。运行时，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 无需重建集成即可采用受支持的模型。请参阅 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 模型，也不会将其分发给第三方。对于受支持的 Agent Mode 模型，Postman 已将 data_retention_mode 设为 none，以配置零数据保留。具体可用性和行为因模型而异，因此必须根据最新的 Amazon Bedrock 数据保护与保留文档检查每个生产模型。
通过提示词缓存控制成本
生产环境中的智能体会在每轮对话中重新发送大量稳定上下文，包括系统指令、通用智能体行为、核心工具集、选定的知识以及对话上下文。每次请求都重新处理未变化的前缀，会带来本可避免的延迟和成本。
Agent Mode 使用 Amazon Bedrock 提示词缓存来复用稳定的提示词前缀。近乎不变的核心内容，包括系统提示词、智能体指令和核心工具定义，使用一小时缓存检查点。变化较多的上下文使用五分钟检查点，并在缓存命中时刷新。Bedrock 要求较长生命周期的检查点位于较短生命周期的检查点之前。较短的缓存层适合交互式会话，因为闲置上下文会过期；而一小时缓存层则可将较高的缓存写入价格分摊到多次读取中。缓存收益和支持的 TTL 取决于所选模型。团队可以通过 cacheReadInputTokens 和 cacheWriteInputTokens 使用量字段验证缓存行为，并针对自己的工作负载测量首个令牌生成时间。
# 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 上开展构建的开发者参考：
- 像管理令牌一样谨慎地规划工具。根据任务动态选择要开放的工具。Postman 的测试显示，可见工具集规模较大时，工具选择错误会增加。
- 优先采用支持架构的读取方式，而不是不断增加工具。妥善设计数据模型，让智能体查询数据。
- 将智能体操作与界面状态解耦。如果某个工具要求打开标签页，那么智能体是在操作界面，而不是直接基于数据进行推理。
- 有意识地设计上下文。专门构建的上下文处理程序，优于每次都将渲染模型序列化。
- 将上下文窗口视为稀缺资源来管理。截断和扩展策略是首要设计问题，而不是事后才考虑的问题。
- 随功能一同发布文档。只有与产品同步更新，RAG 知识库才能持续发挥作用。
- 在 Bedrock 上进行路由和缓存。为每种工作负载匹配合适的 Claude 模型，根据吞吐量和地理要求选择跨区域推理，并对稳定的提示词前缀应用分层缓存。
结论
构建 Agent Mode 要求 Postman 正视大型语言模型能力与成熟产品结构之间的差距：界面假设、耦合的客户端、庞大的工具目录，以及分散在文档和团队中的知识。在Postman 开发者社区的规模下，动态工具选择、基于架构的读取和有目的的上下文工程逐渐成为可重复应用的模式。Amazon Bedrock提供托管模型访问、跨区域推理、因模型而异的数据保留控制以及提示缓存，为生产架构提供支持。
无论你是在构建第一个智能体，还是在扩展现有智能体，这些模式都能帮助团队避免常见的智能体集成和扩展挑战。
如需了解更多信息，请参阅Amazon Bedrock 文档，其中包含有关跨区域推理、提示缓存以及数据保护和保留的指南。如需了解相关实施指南，请阅读 AWS Machine Learning Blog 上的文章在 Amazon Bedrock 上有效使用提示缓存和Amazon Bedrock 宣布推出全局跨区域推理，以提高吞吐量。如需了解该产品，请参阅Postman Agent Mode 文档。
Postman 的生产环境实现属于专有内容，未作为公开示例代码库提供。
作者简介
Srinivas Kini
Srinivas 是 Postman AI 团队的高级工程师，致力于构建处于分布式系统与 AI 基础设施交汇处的企业级智能体。他专注于核心智能体架构，确保智能体在大规模运行时保持可靠和准确。
Shubham Gupta
Shubham 是 AWS 的解决方案架构师，常驻印度班加罗尔，为独立软件供应商（ISV）提供支持。他与工程和领导团队合作，帮助他们在 AWS 上设计、构建和运行产品，涵盖从初始架构设计到投入生产的全过程，尤其专注于生成式 AI 和大规模弹性。工作之余，Shubham 热爱徒步，并将徒步中的同等准备和毅力运用到构建经久耐用的系统中。
来源：AWS Machine Learning Blog · aws.amazon.com