# Postman 如何为 API 工作设计 Agent Mode

- Source: MechNext — https://mechnext.eu/zh/article/36-how-postman-designed-agent-mode-for-api-work
- Published: 2026-10-11
- Updated: 2026-10-11
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> AWS 文章介绍了 Agent Mode 如何结合 API 工作流、工具筛选、上下文处理和变更审批。Postman 表示，该服务运行在 Amazon Bedrock 上。

2026年10月9日，AWS Machine Learning Blog 发布文章，介绍 Postman 如何在 Amazon Bedrock 上运行 Agent Mode。文章称，Postman 将 Agent Mode 构建为一种面向 AI 的工作方式，覆盖 API 测试、文档编写、API 发现和实现。文章关注的是代理如何融入 API 工作，以及当代理需要面对大量工具和不同类型的上下文时，系统设计如何应对这些情况。

Postman 表示，Agent Mode 运行在 Amazon Bedrock 上，并使用该服务管理对基础模型的访问。这些架构信息来自 AWS 文章；文中有关设计和测试的描述应理解为文章转述的 Postman 说法。阅读相关数字时，这一区分很重要：文章介绍了 Postman 所描述的模式，但没有提供对其结果的独立验证。

### 把工具筛选纳入系统设计

文章讨论的一个问题是代理可用工具集的规模。根据 Postman 的测试，当可见工具数量超过约40个时，工具选择错误会增加。文章描述了一种筛选流程：从170多个工具中缩小范围，选出约15个与请求相关的工具，然后再把它们交给一个上下文隔离的子代理。

这一做法的实际含义是，代理不必在每次处理请求时都面对完整目录。系统先缩小选项范围，再向子代理提供较小且与任务相关的工具集。文章将可见工具的数量与 Postman 所报告测试中的选择准确性联系起来。这些数值是近似值，反映的是公司报告的结果，不应被视为适用于所有代理系统的通用阈值。

Postman 还介绍了 API Catalog 的一种调整方式：把多个范围较窄的目录视图合并为一个查询工具。代理可以依据底层 ClickHouse 表的结构生成查询。文章称，这使代理能够通过查询处理目录数据，而工具依据这些表结构提供数据。文章描述的是一种数据访问方式，并没有据此声称所有目录操作都使用相同流程。

### 为代理准备上下文

另一项调整是构建专用的上下文处理器。Postman 表示，原有界面数据模型是为渲染和数据传输设计的，并不是为代理推理设计的。因此，专用处理器会以 Agent Mode 所需的形式准备上下文。这解释了为什么即使产品已有界面和成熟的数据模型，代理仍可能需要独立的上下文处理路径。

界面和代理可以处理产品中的相同领域，但对信息如何组织可能有不同需求。按照 Postman 的描述，上下文处理因此是 Agent Mode 设计的一部分，而不是现有数据传输机制的另一种称呼。文章将这一做法描述为对两类不同用途的回应：界面需要呈现信息，代理则需要利用信息进行推理。

### 审批与后台请求

文章称，在执行会改变应用状态的操作之前，Agent Mode 必须取得用户批准。它也可以在没有打开标签页的情况下于后台发送请求，同时仍然要求用户批准。这里描述的是运行方式的两个方面：请求可以在没有打开标签页时运行，但按照文章所述的规则，改变应用状态的操作仍须经过用户批准。

在请求路由方面，Postman 表示使用 Amazon Bedrock 的跨区域推理。请求会在推理配置文件所定义的目标区域之间进行路由。文章把这种区域路由描述为 Agent Mode 运行方式的一部分。目标区域由配置文件确定；文章没有说每个请求都可以被路由到任意区域。

Postman 还表示，对于受支持的 Agent Mode 模型，已配置零数据保留，并将 `data_retention_mode` 设为 `none`。这一功能是否可用以及具体行为如何，取决于所用模型。因此，这项说法只适用于支持该设置的模型，不能扩展为 Agent Mode 使用的每个模型都具备零数据保留。

### 复用提示词上下文

文章称，Agent Mode 使用 Amazon Bedrock 的提示词缓存：对近乎不变的核心提示词内容设置一小时检查点，对变化较多的上下文设置五分钟检查点。这种描述区分了相对稳定的提示词部分和更常变化的信息。这是文章中归于 Postman 配置的时间间隔，不表示同样的间隔适用于每种应用。

综合来看，文章将 Agent Mode 描述为一个需要处理工具选择、上下文准备、变更审批和模型访问的系统。AWS 文章呈现了 Postman 对其 API 工作设计的解释：代理收到经过筛选的相关工具，上下文会按推理需要进行准备，后台请求仍保留审批要求，而 Bedrock 提供模型访问和区域路由。这些细节都是文章转述的公司说法，应据此理解其范围。

这种架构描述也让读者看到，Agent Mode 的设计涉及的不只是调用模型。工具目录需要依据请求缩小，已有数据模型需要通过专用处理器转换为适合代理使用的上下文，改变应用状态的操作需要用户批准。文章还把后台请求、跨区域推理、模型相关的数据保留设置和提示词缓存纳入同一运行图景。它们共同说明了 Postman 在文章中报告的系统组成，但不能单凭这篇文章推断其架构已得到独立评估，也不能把公司报告的测试结果推广到其他系统。