How Postman runs Agent Mode for 40 million developers on Amazon Bedrock

Postman如何在Amazon Bedrock上为4000万开发者运行Agent模式 | 人工智能

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

为演示构建AI代理与为4000万开发者运营AI代理是不同的工程问题。Postman致力于构建Agent模式，这是一种原生AI的工作方式，覆盖API测试、文档编写、发现和实现等场景。团队最初预计模型质量和提示设计将是最大挑战。但更深层的挑战来自将代理集成到一个成熟产品中，该产品历经多年形成了界面驱动的假设、广泛的功能覆盖范围以及专业化的概念体系。

在本文中，Postman与AWS将描述在使成熟产品对AI代理可读的过程中形成的架构模式。这些模式包括控制工具碎片化、暴露基于模式的读取能力，以及将上下文而非能力视为主要瓶颈。

我们还将解释Agent模式如何利用Amazon Bedrock实现模型灵活性、地理范围限定的跨区域推理、模型依赖的零数据保留以及多级提示缓存。这些经验共同帮助团队将生产环境中的代理从原型推进到实际应用。

为什么Postman构建Agent模式

Agent模式是Postman在测试、文档编写、发现和实现场景中以原生AI方式使用产品的门户。Postman历经11年发展，开发者和用户已习惯通过展开侧边栏、切换标签页和打开请求来定位信息。为代理重新设计这种认知方式，暴露出产品API、用户体验和产品知识分布中的结构性假设。代理通过数据推理而非屏幕导航进行操作。图1展示了Agent模式如何直接针对应用程序工作。

图1：Agent模式直接针对Postman应用程序工作。在此示例中，它打开一个拉取请求并提出下一步建议，无需用户通过界面导航

Agent模式基于Amazon Bedrock运行，该服务为代理提供了对基础模型的托管访问。支持Postman全球开发者社区带来了具有尖峰流量的可变延迟敏感需求。通过Amazon Bedrock，Postman可以在不运营自身模型服务基础设施的情况下扩展此生产工作负载，同时保持模型选择的灵活性，并对吞吐量、地理处理和成本进行控制。图2提供了生产架构的高层视图，后续部分将详细分析其组件。

图2：Postman Agent模式结合了客户端工具、代理编排、专用上下文和Amazon Bedrock模型推理。工具针对每个任务进行限定，用户批准仍然是修改应用状态操作的一部分

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

应对工具冗余

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

许多现实工作流需要长时间的工具调用序列。即使每个步骤都很快，整体体验仍显得缓慢，因为每次操作都必须返回模型才能开始下一步。用户会看到代理逐步执行他们心理上视为单一操作的多个动作。

在Postman的测试中，当可见工具集超过约40个工具时，工具选择错误率显著上升。代理可能会调用不存在的工具，即使模式有效也会传递错误参数，或选择看似语义合理但实际不符合上下文的工具。更大或更新的模型减少了这种行为，但未能完全消除。

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

图3：根代理查询工具嵌入的向量数据库，将170多个工具缩小到约15个与请求相关的工具。然后将这些工具传递给上下文隔离的子代理，使模型只能看到任务所需的工具。

更微妙的问题在于许多客户端API隐式耦合到界面状态。修改请求的工具需要某些元素保持打开状态，而其他工具会作为副作用打开新标签页。代理必须打开请求标签页才能读取内容，模仿界面交互而非直接推理数据。Postman正在积极解耦工具与标签页，其原生Git功能大量采用这种方法。例如，Agent Mode现在可以在不打开标签页的情况下在后台发送请求，尽管仍需要用户批准。

构建者要点：将工具目录视为上下文预算的一部分。根据任务动态限定暴露给模型的工具范围，并将"代理能执行的操作"与"UI当前打开的内容"解耦。

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 网络、工作区治理、变量、辅助工具、代码生成、请求设置和集合运行等功能。

将所有这些信息编码到静态提示中并不可行，且其中大部分内容与特定查询无关。在初始数据填充阶段，团队使用 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 可以在不重建集成的情况下采用支持的模型。请参见 Amazon Bedrock 中按 AWS 区域支持的模型列表。

• 地理推理配置文件仅在定义的地理区域内（如美国或欧洲联盟）的受支持区域之间路由请求。此选项将更高的吞吐量与配置的地理处理边界相结合。

• 全球推理配置文件可以将请求路由到全球范围内的受支持目标区域，从而在流量激增期间提供额外的吞吐量。只有在工作负载不需要地理限制处理边界时才适用此选项。

Postman 可按工作负载选择推理配置文件：使用全球配置文件以实现最大可用吞吐量，或在处理必须保留在配置文件定义的地理区域内时使用地理配置文件。此选择在每个 Bedrock 推理请求使用的 modelId 中明确体现。

# 示意性 Converse 请求
response = bedrock_runtime.converse(
    modelId="<地理推理配置文件 ID 或 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 提示缓存来复用稳定的提示前缀。几乎不可变的核心部分（包括系统提示、代理指令和核心工具定义）使用 1 小时缓存检查点。更易变的上下文使用 5 分钟检查点并在缓存命中时刷新。Bedrock 要求生命周期更长的检查点必须出现在生命周期较短的检查点之前。较短的检查点更适合交互会话，因为空闲上下文会过期，而 1 小时检查点可以将其较高的缓存写入成本分摊到多次读取中。缓存优势和支持的 TTL（存活时间）取决于所选模型。团队可通过 cacheReadInputTokens 和 cacheWriteInputTokens 使用字段验证行为，并针对自身工作负载测量首次生成令牌的时间。

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

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

生产环境中扩展代理的最佳实践

结论

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

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

欲了解更多信息，请参阅 Amazon Bedrock 文档，包括跨区域推理、提示缓存、数据保护和保留的指导。有关相关实现指南，请阅读《在 Amazon Bedrock 上有效使用提示缓存》和《Amazon Bedrock 宣布全球跨区域推理以提高吞吐量》（AWS 机器学习博客）。要探索该产品，请参阅 Postman 代理模式文档。

Postman 的生产实现是专有的，不会作为公开的示例代码库提供。

作者简介

'\" /think