Postman 揭秘 Agent Mode 架构：在 Amazon Bedrock 上为 4000 万开发者构建生产级 AI 代理的工程挑战与模式

为演示构建一个 AI Agent 与为 4000 万开发者运营一个 AI Agent，是两个截然不同的工程问题。Postman 着手打造 Agent Mode，这是一种在 API 测试、文档编写、发现及实现过程中进行协作的 AI 原生方式。团队原本预期模型质量和提示词设计（prompt design）将是最具挑战性的难题。然而，更深层的挑战来自于如何将 Agent 集成到一个成熟的产品中——该产品历经多年发展，形成了基于界面的固有假设、庞大的功能覆盖面以及高度专业化的概念体系。

在本文中，Postman 和 AWS 共同阐述了在使成熟产品对 AI Agent “可读”的过程中涌现出的架构模式。这些模式包括控制工具蔓延（tool sprawl）、暴露基于 Schema 的读取接口，以及将上下文（context）而非能力（capability）视为主要瓶颈。

我们还将解释 Agent Mode 如何利用 Amazon Bedrock 来实现模型灵活性、地理范围限定的跨 Region 推理、依赖模型的零数据保留（zero data retention），以及多层级提示缓存（multi-tier prompt caching）。综合来看，这些经验可以帮助团队将生产环境中的 Agent 从原型阶段推向成熟落地。

Postman 为何构建 Agent Mode

Agent Mode 是 Postman 提供的入口，旨在以 AI 原生的方式贯穿测试、文档、发现和实现全流程。Postman 已演进 11 年，开发者和用户习惯了通过展开侧边栏、查看标签页和打开请求等界面操作来定位信息。为 Agent 重新构建这种感知能力，揭示了产品在 API、用户体验以及产品知识分布方面的结构性假设。Agent 是基于数据进行推理，而非在屏幕上导航。图 1 展示了 Agent Mode 如何直接针对应用程序进行操作。

图 1：Agent Mode 直接针对 Postman 应用程序运行。在此示例中，它打开了一个拉取请求（pull request）并提出了后续步骤建议，而无需用户在界面中进行导航

Agent Mode 运行在 Amazon Bedrock 之上，后者为智能体背后的基础模型提供了托管访问服务。支持 Postman 的全球开发者社区会产生多变且对延迟敏感的需求，并伴随剧烈的流量突发。借助 Amazon Bedrock，Postman 可以在无需自行运营模型推理基础设施的情况下扩展这一生产工作负载，同时在模型选择以及对吞吐量、地理处理区域和成本的控制方面保持灵活性。图 2 展示了生产架构的高层视图，随后的章节将详细剖析其各个组件。

图 2：Postman Agent Mode 结合了客户端工具、智能体编排、专用上下文以及 Amazon Bedrock 模型推理。工具会根据具体任务进行范围限定，而对于那些会修改应用状态的操作，用户审批仍是其中的一部分

人工监督是生产设计的重要组成部分。在执行任何会修改应用状态的操作之前，Agent Mode 都需要获得用户的批准。Postman 还会根据任务限定可用工具的范围，选择专用的上下文信息，并应用依赖于模型的数据保留设置。这些控制措施减少了意外操作和不必要的数据暴露，但生产环境的测试与监控依然必不可少。作为一项负责任的 AI 控制措施，Postman 使用 Amazon Bedrock Guardrails 在数据到达底层大语言模型（LLM）之前对个人身份信息（PII）进行脱敏处理。企业管理员可以在 Agent Mode 的护栏（guardrail）设置中启用此功能。

应对工具蔓延

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

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

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

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

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

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

构建者启示： 将你的工具目录视为上下文预算的一部分。根据任务动态限定暴露给模型的工具范围，并将“代理能做什么”与“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;

采用这种方法后，工程工作从为每个问题构建一个工具转变为一次性做好数据建模。随后，代理能够生成比团队曾作为独立工具枚举出的种类多得多的查询。

构建者启示： 当你拥有结构良好的数据时，赋予代理对查询引擎的 schema 感知读取权限，而不是创建大量单一用途的读取工具。你用工具数量的减少换取了数据建模的投入，从而获得更好的扩展曲线。

上下文才是真正的瓶颈

Postman 最初认为缺失工具会是最大的障碍。但在实践中，缺失或不完整的上下文导致的失败远多于能力缺失带来的问题。

上下文是指 Agent 对用户当前在 Postman 中所处位置、哪些实体处于活动状态以及已建立何种状态的认知。当上下文错误或缺失时，即使工具本身正确，也会变得无效。图 4 区分了提供给 Agent 的两种形式的上下文。

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

这一挑战具有结构性。在过去 11 年中，开发者和用户已经习惯于通过界面查找信息。为了将这些认知重新工程化以供 Agent 使用，团队进行了多次迭代，以确定对于每个工作流而言什么是关键信息，什么是噪音。直接序列化现有的界面数据模型无法产生有用的上下文，因为这些对象是为渲染和数据传输而设计的，而非用于推理。因此，Postman 构建了专用的上下文处理器，将每个实体提炼为 Agent 需要知道的内容。

随着越来越多的对象拥有了处理器，截断（truncation）成为了下一个难题。许多字段包含开放式的用户生成数据，包括请求描述、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 模型之间切换主要是一项配置变更，而非需要重新集成。这种灵活性直接解决了前文提到的工具泛滥（tool-sprawl）和上下文挑战。在 Postman 的测试中，更新且更大的模型减少了工具幻觉（tool hallucinations），并且 Postman 可以在无需重建集成的情况下采用受支持的模型。请参阅 Amazon Bedrock 按 AWS 区域划分的受支持模型。

跨区域推理以实现高吞吐量

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

1. 地理推理配置文件 仅在定义的地理范围内（如美国或欧盟）的受支持区域之间路由请求。此选项结合了更高的吞吐量与已配置的地理处理边界。
2. 全球推理配置文件可在全球范围内的受支持目标区域之间路由请求，以在流量突发期间提供额外的吞吐量。仅当工作负载不需要地理受限的处理边界时，才适合使用此选项。

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

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

数据驻留与企业级控制

对于企业客户而言，允许的处理地理区域可能与吞吐量同等重要。地理推理配置文件（Geographic inference profiles）将 Bedrock 的路由限制在所选地理区域内该配置文件支持的目的地 Region。这并不意味着推理运行在 Postman 自己的 AWS 环境中。Amazon Bedrock 在该配置文件对应的合格 AWS Region 中处理请求，数据在传输和静止状态下均经过加密。AWS 声明 Bedrock 不会使用提示词（prompts）和补全内容（completions）来训练 AWS 模型，也不会将其分发给第三方。Postman 已为受支持的 Agent Mode 模型配置了零数据保留策略，将 data_retention_mode 设置为 none。可用性和行为取决于具体模型，因此每个生产环境中的模型都必须对照当前的 Amazon Bedrock 数据保护和保留文档 进行检查。

通过 Prompt Caching 控制成本

生产环境中的 Agent 会在每一轮对话中重新发送大量稳定的上下文，包括系统指令、通用 Agent 行为、核心工具集、选定的知识以及对话历史。每次请求都重新处理未变化的前缀会增加不必要的延迟和成本。

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

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

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

在生产环境中扩展 Agent 的最佳实践

源自 Postman 的经验总结，供在 Amazon Bedrock 上工作的构建者参考：

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

结论

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

无论你是正在构建第一个 Agent，还是对现有 Agent 进行规模化扩展，这些模式都能帮助团队规避常见的 Agent 集成与扩展挑战。

如需了解更多详情，请参阅 Amazon Bedrock 文档，其中包含关于跨区域推理、提示词缓存以及数据保护与保留的指导。有关相关实施指南，请阅读 AWS Machine Learning Blog 上的文章：在 Amazon Bedrock 上高效使用提示词缓存 和 Amazon Bedrock 宣布推出全球跨区域推理以提升吞吐量。若要探索该产品，请参阅 Postman Agent Mode 文档。

Postman 的生产环境实现属于专有技术，并未作为公开示例代码库提供。