Postman 如何借助 Amazon Bedrock 为 4000 万开发者运行 Agent Mode
为一个演示构建 AI 智能体，和为 4000 万开发者运营一个智能体，是两个截然不同的工程问题。Postman 着手打造 Agent Mode，一种以 AI 原生方式横跨 API 测试、文档、发现和实现的开发体验。团队原本以为最棘手的问题在于模型质量和提示词设计。然而更深的挑战来自如何将智能体集成进一个成熟产品，这个产品积累了多年的界面驱动假设、庞大的功能面以及专业化的概念体系。本文中，Postman 和 AWS 介绍了在让一个成熟产品对 AI 智能体可读的过程中形成的架构模式。这些模式包括：控制工具泛滥、暴露基于 schema 的读取接口，以及将上下文——而非能力——视为主要瓶颈。我们还解释了 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 上，后者为智能体背后的基础模型（即大语言模型等底层 AI 模型）提供托管访问。支撑 Postman 全球开发者社区意味着需求多变且对延迟敏感，流量还会出现急剧峰值。
借助 Amazon Bedrock，Postman 无需自建模型服务基础设施，就能扩展这套生产工作负载，同时在模型选择、吞吐量控制、地理处理和成本方面保持灵活。图 2 展示了生产架构的整体视图，后续章节会逐一拆解各组件。
图 2：Postman Agent Mode 整合了客户端工具、agent 编排、专用上下文和 Amazon Bedrock 模型推理。每个任务的工具都经过范围限定，修改应用状态的操作仍需用户批准。
人工监督是这套生产设计的一部分。凡是会修改应用状态的操作，Agent Mode 都要求用户先批准。Postman 还会按任务限定可用工具的范围，挑选专用上下文，并根据模型应用不同的数据保留设置。这些控制手段能减少误操作和不必要的数据暴露，但生产环境中的测试和监控仍然必不可少。
为落实负责任的 AI 控制，Postman 使用 Amazon Bedrock Guardrails，在个人信息（PII）送达底层大语言模型（LLM）之前先做脱敏处理。企业管理员可以在 Agent Mode 的护栏设置中开启这一功能。
应对工具泛滥
在 Agent Mode 中，工具决定了 agent 在 Postman 内部如何行动。早期团队倾向于高度原子化的工具：只做一件小事的精确操作，比如打开一个请求、更新某个字段、或获取某一项元数据。这种做法在早期迭代中保证了正确性和可控性，但也暴露出几个问题。
很多实际工作流需要一长串工具调用。即便每一步都很快，整体体验依然很慢，因为每个操作都必须先返回模型，才能开始下一步。用户看到 agent 一步步执行那些在他们心里本该是一步到位的操作。
Postman 的测试显示，一旦可见工具集超过约 40 个，工具选择出错的情况就会增多。agent 可能会调用不存在的工具、在 schema 有效的情况下依然传错参数，或者选中语义上说得通但在当前上下文里并不对的工具。
更大或更新的模型能减轻这种行为，但没法根除。工具集超过一定规模后，暴露更多工具反而会拉低 agent 的效率。当前的架构按需按上下文挑选工具，并隔离各条执行线程。模型只能看到与当前任务相关的工具。图 3 展示了这个动态筛选过程。图 3：根 agent 会去查询一个存有工具嵌入向量的数据库，从 170 多个工具里筛出大约 15 个与请求相关的工具，再把它们交给一个上下文隔离的子 agent，于是模型只看到完成任务所需的那几个工具。
更隐蔽的一个问题是，很多客户端 API 暗中依赖界面状态。修改请求的工具需要某些元素处于打开状态，而另一些工具又会顺手打开新标签页。Agent 为了读取某个请求，得先打开对应的请求标签，是在模仿界面操作，而不是直接对数据做推理。Postman 正在把工具和标签页解耦，它的 Native Git 功能就大量用到了这个思路。比如 Agent Mode 现在能在后台发送请求，无需打开标签页，当然用户授权仍然需要。
给开发者的启示：把工具目录纳入上下文预算来考虑。按任务动态圈定暴露给模型的工具范围，并把“agent 能做什么”与“界面上恰好开着什么”解耦。
用 schema 化的读取来暴露数据
对于 API Catalog 这类产品，Postman 把多个零散的视图合并成一个查询工具。这类产品暴露的是结构化数据，比如多项服务的在线率、测试结果和端点响应时间。给定底层 ClickHouse 表的 schema，agent 就能生成带 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;
用这种办法，工程团队的工作就从「每个问题配一个工具」转向「一次性把数据模型做好」。这样，Agent 能生成的查询种类，远比团队把每种查询都做成单独工具要丰富得多。
给构建者的启示： 如果数据本身结构清晰，就让 Agent 在理解 schema（数据结构）的前提下，拥有对查询引擎的读取权限，直接去查，而不是堆一大堆只干一件事的读取工具。你拿工具数量换数据建模，扩展曲线会更好。
Context 才是真正的瓶颈。Postman 一开始以为，最大的障碍是缺工具。实际跑下来，缺上下文或上下文不完整造成的失败，比缺能力更多。所谓上下文，就是 Agent 对「用户当前在 Postman 的哪个位置、哪些实体处于活跃状态、已经建立了什么状态」的理解。上下文一旦不对或缺失，就算工具本身没问题，也发挥不了作用。图 4 展示了提供给 Agent 的两种上下文。
图 4：两类上下文会送给 Agent。宽泛、浅层的背景上下文由系统自动收集，并压缩后放进提示词。深入、聚焦的选中上下文由用户选择，再按实体类型交给专门的处理器处理。
每个处理器都会把实体提炼成 Agent 需要的信息。难点在于结构。过去 11 年里，开发者和用户已经习惯了通过界面找信息。要替 Agent 重新建立这种「知道去哪找」的能力，需要反复迭代：搞清楚每个工作流里什么信息重要、什么是噪音。直接把现有界面的数据模型序列化，并不能得到有用的上下文，因为这些对象是为渲染和数据传输设计的，不是为推理设计的。
所以 Postman 专门做了上下文处理器，把每个实体提炼成 Agent 需要知道的内容。随着越来越多对象有了处理器，截断又成了下一个问题。不少字段里装着用户生成的开放内容，比如请求描述、OpenAPI 规范、请求负载。这些数据很容易把上下文窗口塞满。
在大规模场景下，仔细管理上下文预算至关重要，这也支撑了团队正在探索的文件系统方案——每个处理器不再需要自己实现截断和扩展逻辑。
给开发者的启示：别把渲染用的数据模型直接丢给模型。要构建贴合具体用途的上下文处理器，把上下文窗口当作稀缺资源来主动管理。在模型达到上限之前很久，噪声就已经把有用信号挤走了。
整合在一起
随着 Agent Mode 的演进，系统需要整合三个不同的部分，各自解决不同的问题。
客户端工具位于 Postman 应用中，代表智能体能执行的最终动作，比如打开请求、修改设置、运行集合、检查认证信息。Agent Mode 也会用到服务端工具来实现网页搜索和智能体循环管理等功能，但大多数工具还是在 Postman 应用上运行。
通用智能体指令定义系统级行为，包括 Agent Mode 该有多主动、如何表达不确定性、以及它掌握哪些基础产品知识。
知识库采用检索增强生成（RAG）方案。Postman 的产品面很广，涵盖多种请求协议、Mock 服务器、监控器、文档、API Network、工作区治理、变量、辅助函数、代码生成、请求设置和集合运行。把这些全写进静态提示词并不可行，而且大部分内容跟具体查询无关。初始填充时，团队用 Postman 学习中心生成了简洁的功能专题文章。运行时，Agent Mode 根据用户查询和当前上下文来挑选知识文章。比如用户选中一个 Mock 服务器时，Agent Mode 会自动注入相关文章。这样默认情况下智能体保持轻量，需要时又能提供足够的深度。知识库随应用一起演进，团队可以在发布新功能时同步更新 Agent Mode 的文档。
在 Amazon Bedrock 上运行 Agent Mode
前面说的三个部分最终都归结为同一个运行时动作：对基础模型（FM）发起一次推理调用。
在 Postman 这个量级上，流量波动大，而且由开发者行为驱动。路由、缓存和地理处理控制能帮助 Postman 应对流量高峰、控制推理成本，并满足特定工作负载的处理要求。Amazon Bedrock 在这方面提供了四项最关键的能力。
Claude 系列内的模型灵活切换
Agent Mode 并不绑定某一个模型。通过 Amazon Bedrock 的模型推理 API，Postman 可以访问受支持的 Anthropic Claude 模型，并把不同任务路由到合适的模型上。响应速度快的模型可以承接高并发、对延迟敏感的交互；更大的模型则处理复杂推理，因为这类场景里质量比成本更重要。在受支持的 Claude 模型之间切换，基本上只需改改配置，而不是重新做一次集成。这种灵活性正好能应对前面提到的工具泛滥和上下文压力问题。在 Postman 的测试中，更新、更大的模型能减少工具幻觉，同时无需重建集成就能采纳新模型。各 AWS 区域支持哪些模型，可查阅 Amazon Bedrock 的相关文档。
跨区域推理应对高吞吐
开发者流量呈尖峰式波动，如果只为单个 AWS 区域的峰值需求预留资源，成本会很高。Agent Mode 使用 Amazon Bedrock 的跨区域推理，按推理配置文件（inference profile）指定的目标区域自动分发请求。运行时，应用把选定的推理配置文件 ID 或 Amazon 资源名称（ARN）作为 modelId 传给 Converse 或 InvokeModel。该配置文件、对应的 AWS Identity and Access Management（IAM）策略和服务控制策略，以及配额，都必须允许 Bedrock 可能选择的所有目标区域。
地理推理配置文件只在某个地理位置（比如美国或欧盟）内的受支持区域之间路由请求。这种方案既提升了吞吐量，又设定了明确的地理处理边界。全局推理配置文件则可以在全球范围内的受支持目标区域之间路由请求，在流量高峰时提供额外吞吐能力。它只适用于不需要地理处理边界约束的工作负载。