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

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

做一个演示用的人工智能智能体（AI agent），和为一个 4000 万开发者的社区运营一个智能体（https://www.postman.com/company/about-postman/），是不同的工程问题。Postman 着手构建 Agent Mode（https://learning.postman.com/docs/postman-ai-developer-tools/agent-mode/），一种以人工智能为原生方式、贯穿应用程序接口（API）测试（https://learning.postman.com/docs/sending-requests/response-data/test-responses/）、文档（https://learning.postman.com/docs/publishing-your-api/documenting-your-api/）、发现和实现的工作方式。团队原本以为模型质量和提示设计会是最难的问题。更深的挑战来自把智能体接入一个成熟产品：多年界面驱动的假设、很宽的产品表面，以及专门化的概念。

在本文中，Postman 与 AWS 描述在让成熟产品对人工智能智能体可读的过程中出现的架构模式。这些模式包括控制工具蔓延、暴露基于模式的读取，以及把上下文而不是能力当作主要瓶颈。

我们也说明 Agent Mode（https://learning.postman.com/docs/getting-started/basics/about-agent-mode/）如何使用 Amazon Bedrock（https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html）获得模型灵活性、按地理范围限定的跨区域推理、依模型而定的零数据保留，以及多层提示缓存。这些经验合在一起，可以帮助团队把生产智能体推进到原型之外。

Postman 为何构建 Agent Mode

Agent Mode（https://learning.postman.com/docs/getting-started/basics/about-agent-mode/）是 Postman 用以人工智能原生方式使用产品的入口，覆盖测试、文档、发现和实现。Postman 已经演进了 11 年，开发者和用户学会通过界面找信息：展开侧栏、查看标签页、打开请求。为智能体重新设计这种感知，暴露出产品应用程序接口、用户体验和产品知识分布中的结构性假设。智能体是对数据推理，而不是在屏幕上导航。图 1 说明 Agent Mode 如何直接作用于应用程序。

图注：图 1：Agent Mode 直接作用于 Postman 应用程序。在这个例子中，它打开一个拉取请求并提出下一步，而不要求用户在界面中导航

Agent Mode（https://learning.postman.com/docs/getting-started/basics/about-agent-mode/）运行在 Amazon Bedrock（https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html）上，由它为智能体背后的基础模型提供托管访问。支撑 Postman 的全球开发者社区，会带来变化的、对延迟敏感的需求，以及陡峭的流量突发。借助 Amazon Bedrock，Postman 可以扩展这一生产工作负载，而不必自己运营模型服务基础设施，同时保留模型选择的灵活性，以及对吞吐量、地理处理和成本的控制。图 2 给出生产架构的高层视图，随后各节再检查其组件。

图注：图 2：Postman Agent Mode 组合了客户端工具、智能体编排、专门构建的上下文和 Amazon Bedrock 模型推理。工具按每个任务限定范围，修改应用程序状态的动作仍保留用户批准

人工监督是生产设计的一部分。Agent Mode 在修改应用程序状态的动作之前要求用户批准。Postman 也会把可用工具限定到当前任务，选择专门构建的上下文，并应用依模型而定的数据保留设置。这些控制减少意外动作和不必要的数据暴露，同时生产测试和监控仍然必要。作为负责任人工智能控制，Postman 使用 Amazon Bedrock Guardrails（https://aws.amazon.com/bedrock/guardrails/）在个人可识别信息到达底层大语言模型（large language model，LLM）之前将其涂销。企业管理员可以在 Agent Mode 的护栏设置中打开这一项。

处理工具蔓延

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

许多真实工作流需要很长的工具调用序列。即便每一步都很快，整体体验仍然感觉慢，因为每个动作都必须回到模型，下一个动作才能开始。用户看着智能体逐步执行他们在心里已经归成一次操作的动作。

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

超过某个工具集规模之后，暴露更多工具会降低智能体效果。当前架构按需要和上下文选择工具，并隔离各个执行线程。模型只看到与当前任务相关的工具。图 3 说明这一动态选择过程。

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

一个更隐蔽的问题是，许多客户端应用程序接口隐含地耦合到界面状态。修改请求的工具需要某些元素处于打开状态，而另一些工具会把打开新标签页作为副作用。智能体必须打开请求标签页才能读取它，这是在模仿界面交互，而不是对数据推理。Postman 正在积极把工具与标签页解耦，其 Native Git（https://www.postman.com/product/native-git/）功能大量使用这一做法。例如，Agent Mode（https://learning.postman.com/docs/postman-ai-developer-tools/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 演进，系统必须聚合三个不同组件，各自解决不同问题，这一点变得清楚。

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

把所有这些编进静态提示并不可行，而且其中大部分对某一次查询无关。为了初始播种，团队使用 Postman 的 Learning Center 生成简明的、针对功能的文章。运行时，Agent Mode 根据进入的查询和可用上下文选择知识文章。例如，当用户选择一个模拟服务器时，Agent Mode 会自动注入相关文章。这使智能体默认保持轻量，同时在需要时提供深度。知识库随应用程序演进，因此团队可以随新功能一起交付 Agent Mode 文档。

在 Amazon Bedrock 上运行 Agent Mode

前面描述的三个组件，归结为同一个运行时动作：对基础模型（foundation model，FM）的一次推理调用。在 Postman 的规模上，流量是突发的，并由开发者驱动。路由、缓存和地理处理控制帮助 Postman 容纳流量突发、管理推理成本，并处理特定工作负载的处理要求。Amazon Bedrock 提供了这里最重要的四项能力。

Claude 系列上的模型灵活性

Agent Mode 不绑定单一模型。通过 Amazon Bedrock 模型推理应用程序接口（https://docs.aws.amazon.com/bedrock/latest/APIReference/welcome.html），Postman 可以访问受支持的 Anthropic Claude 模型，并把每个工作负载路由到合适的模型。更快的模型可以服务高流量、对延迟敏感的交互，更大的模型可以处理质量比成本更重要的复杂推理。在受支持的 Claude 模型之间移动，主要是配置变更，而不是新的集成。这种灵活性直接支持前面描述的工具蔓延和上下文挑战。在 Postman 的测试中，更新、更大的模型减少了工具幻觉，Postman 可以采用受支持的模型而不必重建集成。参见 Amazon Bedrock 中按 AWS 区域列出的受支持模型（https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html）。

面向高吞吐量的跨区域推理

开发者流量是尖峰式的，在单个 AWS 区域按峰值需求预置可能很贵。Agent Mode 使用 Amazon Bedrock 跨区域推理（https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html），在推理配置文件定义的目的地区域之间自动路由请求。运行时，应用程序把所选推理配置文件标识或 Amazon 资源名称（Amazon Resource Name，ARN）作为 Converse 或 InvokeModel 中的 modelId 传入。该配置文件、适用的 AWS 身份与访问管理（AWS Identity and Access Management，IAM）及服务控制策略，以及配额，必须允许 Bedrock 可能选择的每一个目的地区域。

1. 地理推理配置文件（https://docs.aws.amazon.com/bedrock/latest/userguide/geographic-cross-region-inference.html）只在已定义地理范围内的受支持区域之间路由请求，例如美国或欧盟。这一选项把提高的吞吐量与已配置的地理处理边界结合在一起。
2. 全球推理配置文件可以在全球受支持的目的地区域之间路由请求，以便在流量突发时提供额外吞吐量。只有当工作负载不要求地理上受限的处理边界时，它们才合适。

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 数据保护与保留文档（https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html）核对。

用提示缓存控制成本

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

Agent Mode 使用 Amazon Bedrock 提示缓存（https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html）复用稳定的提示前缀。近乎不变的核心，包括系统提示、智能体指令和核心工具定义，使用一小时缓存检查点。更多变的上下文使用五分钟检查点，并在缓存命中时刷新。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 模型，选择合适的跨区域推理配置文件，并用与每一层变化频率匹配的生存时间缓存稳定的提示前缀。

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

从 Postman 的历程中提炼，给在 Amazon Bedrock 上工作的构建者：

1. 像预算令牌一样预算工具。按任务动态选择暴露的工具。在 Postman 的测试中，可见工具集变大时，工具选择错误增加。
2. 优先使用感知模式的读取，而不是工具增殖。把数据建模好，让智能体去查询它。
3. 把智能体动作与界面状态解耦。如果一个工具要求打开标签页，智能体就是在导航界面，而不是直接对数据推理。
4. 有意识地工程化上下文。专用上下文处理器每次都胜过序列化你的渲染模型。
5. 把上下文窗口当作稀缺资源来管理。截断和展开策略是一等设计问题，不是事后补救。
6. 随功能一起交付文档。检索增强生成知识库只有与产品同步演进才保持有用。
7. 在 Bedrock 上路由并缓存。把每个工作负载匹配到合适的 Claude 模型，按吞吐量和地理要求选择跨区域推理，并对稳定提示前缀应用分层缓存。

结论

构建 Agent Mode 要求 Postman 面对大语言模型能力与成熟产品结构之间的差距：界面假设、耦合的客户端、蔓延的工具目录，以及分布在文档和团队中的知识。动态工具选择、基于模式的读取和有意的上下文工程，在 Postman 开发者社区的规模上（https://www.postman.com/company/about-postman/）成为可重复的模式。Amazon Bedrock（https://aws.amazon.com/bedrock/）提供支撑该生产架构的托管模型访问、跨区域推理（https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html）、依模型而定的保留控制（https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html）和提示缓存（https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html）。

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

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

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/how-postman-runs-agent-mode-for-40-million-developers-on-amazon-bedrock