为演示构建一个AI智能体与为 4000万开发者 运营一个智能体是不同的工程问题。Postman着手构建 Agent Mode,这是一种AI原生的工作方式,涵盖 API测试, 文档、发现和实现。团队原本预期模型质量和提示词设计是最难的问题。更深层的挑战来自将智能体集成到一个成熟的产品中——该产品多年来基于界面的假设、广泛的覆盖面和专业化的概念。
在这篇文章中,Postman和AWS描述了在让成熟产品对AI智能体可理解的过程中涌现的架构模式。这些模式包括控制工具泛滥、暴露基于模式的读取,以及将上下文而非能力视为主要瓶颈。
我们还解释了 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上,后者为智能体背后的基础模型提供托管访问。支持Postman的全球开发者社区带来了多变、延迟敏感且具有剧烈流量突发的需求。借助Amazon Bedrock,Postman可以扩展这一生产工作负载,而无需自行运营模型服务基础设施,同时在模型选择以及吞吐量、地理处理和成本的控制方面保持灵活性。图2提供了生产架构的高级视图,后续章节将考察其各个组件。
图2:Postman Agent Mode结合了客户端工具、智能体编排、专门构建的上下文和Amazon Bedrock模型推理。工具按任务进行限定范围,用户批准仍然是修改应用程序状态的操作的一部分
人工监督是生产设计的一部分。Agent Mode在执行修改应用程序状态的操作之前需要用户批准。Postman还将可用工具限定在任务范围内、选择专门构建的上下文,并应用依赖于模型的数据保留设置。这些控制措施减少了意外操作和不必要的数据暴露,同时生产测试和监控仍然必不可少。作为一项负责任的AI控制措施,Postman使用 Amazon Bedrock Guardrails 在个人身份信息到达底层大语言模型(LLM)之前对其进行脱敏处理。企业管理员可以在Agent Mode的guardrail设置中开启此功能。
处理工具泛滥
在Agent Mode中,工具定义了智能体如何在Postman内部执行操作。早期,团队倾向于高度原子化的工具:小而精确的操作,例如打开一个请求、更新一个字段或获取特定的元数据。这种方式在早期迭代中支持了正确性和控制力,但也暴露出几个问题。
许多真实世界的工作流需要长序列的工具调用。即使每一步都很快,整体体验仍然感觉缓慢,因为每个操作都必须返回到模型之后才能开始下一个操作。用户看着智能体逐步执行他们心理上已归为一组单一操作的动作。
在 Postman 的测试中，当可见工具集超过约 40 个工具后，工具选择错误开始增加。Agent 可能调用不存在的工具、在模式有效的情况下传递错误的参数，或选择在语义上看似合理但在具体情境中却是错误的工具。更大或更新的模型减少了这种行为，但没有完全消除它。
超过一定工具集规模后，暴露更多工具反而会降低智能体的有效性。当前架构根据需要和上下文选择工具，并隔离各个执行线程。模型只会看到与当前任务相关的工具。图 3 展示了这一动态选择过程。
图3：根代理查询一个包含工具嵌入向量的向量数据库，将超过170个工具缩减到大约15个与请求相关的工具。然后它将这些工具交给一个上下文隔离的子代理，因此模型只会看到该任务所需的工具
一个更微妙的问题是，许多客户端 API 隐式地耦合到界面状态上。修改请求的工具需要某些元素处于打开状态，而另一些工具则会作为副作用打开新标签页。代理必须打开一个请求标签页才能读取它，模仿界面交互而不是对数据进行推理。Postman 正在积极地将工具与标签页解耦，并且其 原生 Git 功能广泛使用了这种方法。例如， 代理模式 现在可以在后台发送请求而无需打开标签页，不过仍需用户批准。
给建设者的启示： 把你的工具目录视为上下文预算的一部分。根据任务动态限定暴露给模型的工具范围，并将“代理能做什么”与“UI 恰好打开了什么”解耦。
暴露基于 schema 的读取
对于API Catalog等产品，Postman将多个窄视图整合为一个统一的查询工具。这些产品暴露了跨众多服务的结构化数据，例如服务正常运行时间、测试结果和端点响应时间。
基于底层 ClickHouse 表的 schema,该代理能够生成包含 joins 和 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 最初被认为失踪 工具 将是最大的阻碍。在实践中，缺失或不完整的 context 造成的失败比缺失的能力还要多。
上下文是智能体对用户在 Postman 中所处位置、哪些实体处于活动状态以及已经建立了什么状态的理解。当上下文错误或缺失时，即使工具正确也会变得无效。图 4 区分了提供给智能体的两种上下文形式。
图4：两种上下文供代理使用。宽而浅的背景上下文自动收集并为提示进行压缩。深而聚焦的选定上下文由用户选择，并通过针对每种实体类型的专用处理器进行路由。每个处理器将实体提炼为代理所需的信息
这个挑战是结构性的。在11年里，开发者和用户学会了通过界面来查找信息。为了让智能体重建这种认知，需要经过多次迭代才能确定每个工作流中什么内容是重要的、什么只是噪音。将现有界面的数据模型直接序列化并不能产生有用的上下文，因为这些对象是为渲染和数据传输而设计的，而不是为推理设计的。因此，Postman 构建了专用的上下文处理器，将每个实体提炼为智能体需要了解的信息。
随着越来越多的对象获得了处理器，截断成为了下一个问题。许多字段包含开放式的用户生成数据，包括请求描述、OpenAPI 规范和请求载荷。这些数据可能会挤占上下文窗口。在大规模场景下，谨慎管理上下文预算至关重要，这也支持了团队正在探索的基于文件系统的方法，即每个处理器无需自定义截断和扩展逻辑。
给建设者的要点： 不要把你的渲染数据模型喂给模型。构建有明确用途的上下文处理器，并把上下文窗口当作稀缺的、需要主动管理的预算。在模型达到其上限之前很久，噪声就会挤占信号的空间。
将所有部分整合在一起
随着 Agent Mode 的演进，我们发现系统必须整合三个不同的组件，每个组件解决一个不同的问题。
- 客户端工具位于 Postman 应用程序中，代表智能体可以执行的最终操作，例如打开请求、修改设置、运行集合以及检查身份验证。Agent Mode 还使用服务端工具来实现网络搜索和智能体循环管理等功能，但大多数工具都是在 Postman 应用程序上运行的。
- 通用智能体指令定义了系统级别的行为，包括 Agent Mode 应该有多主动、它如何传达不确定性，以及它具备哪些基础产品知识。
- 知识库采用检索增强生成（RAG）方法。Postman 拥有庞大的产品面，包括多种请求协议、模拟服务器、监控器、文档、API Network、工作区治理、变量、辅助工具、代码生成、请求设置和集合运行。
将所有这些内容编码到静态提示词中是不可行的，而且其中大部分内容对于给定查询来说是无关的。为了初始填充，团队使用 Postman 的 Learning Center 生成简洁的特定功能文章。在运行时，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 区域划分的受支持模型.
用于高吞吐量的跨区域推理
开发者流量是波动的，而在单个 AWS 区域中按峰值需求进行预置可能成本高昂。Agent Mode 使用 Amazon Bedrock 跨区域推理 在推理配置文件定义的目标区域之间自动路由请求。在运行时，应用程序将所选的推理配置文件 ID 或 Amazon Resource Name（ARN）作为 modelId 传递给 Converse 或 InvokeModel。该配置文件、适用的 AWS Identity and Access Management（IAM）和服务控制策略以及配额必须允许 Bedrock 可能选择的每个目标区域。
- 地理推理配置文件 仅在定义的地理区域（如美国或欧盟）内的受支持区域之间路由请求。此选项将提高的吞吐量与配置的地理处理边界相结合。
- 全局推理配置文件可以在全球范围内受支持的目标区域之间路由请求，以便在流量突发期间提供额外的吞吐量。它们仅适用于工作负载不需要地理上受约束的处理边界的情况。
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 数据保护和保留文档.
通过提示词缓存控制成本
生产环境中的智能体在每一轮都会重新发送大量稳定的上下文，包括系统指令、通用智能体行为、核心工具集、所选知识以及对话上下文。在每次请求中重新处理未变化的前缀会增加可避免的延迟和成本。
Agent Mode 使用 Amazon Bedrock 提示词缓存 来复用稳定的提示词前缀。近乎不变的核心部分（包括系统提示词、智能体指令和核心工具定义）使用一小时缓存检查点。变化较多的上下文使用五分钟检查点，该检查点在缓存命中时刷新。Bedrock 要求存活时间较长的检查点出现在存活时间较短的检查点之前。较短的层级适合交互式会话，因为空闲上下文会过期，而一小时层级可以通过多次读取来摊销其较高的缓存写入价格。缓存收益和受支持的 TTL 取决于所选模型。团队可以通过 cacheReadInputTokens 和 cacheWriteInputTokens 用量字段验证行为，并为其自身工作负载测量首个 token 的生成时间。
# Schematic cache checkpoints in Converse content blocks
{"cachePoint": {"type": "default", "ttl": "1h"}} # stable core
{"cachePoint": {"type": "default", "ttl": "5m"}} # variable layer给开发者的要点： 将推理视为一个路由与缓存问题，而不仅仅是模型选择决策。针对每个工作负载选择 Claude 模型，选择合适的跨区域推理配置文件，并根据每一层的变化频率设置相应的 TTL 来缓存稳定的提示词前缀。
在生产环境中扩展代理的最佳实践
提炼自 Postman 的历程，供在 Amazon Bedrock 上构建的开发者参考：
- 像对待 token 一样谨慎地规划预算。 根据任务动态选择所暴露的工具。在 Postman 的测试中，随着可见工具集变大，工具选择错误随之增加。
- 优先使用具备模式感知的读取方式，而非 proliferation 各种工具。 对数据进行良好的建模，并让智能体对其进行查询。
- 将智能体的操作与界面状态解耦。 如果某个工具需要打开标签页，那么智能体是在导航界面，而不是直接对数据进行推理。
- 有意识地设计上下文。 专门构建的上下文处理器总是胜过对渲染模型进行序列化。
- 将上下文窗口作为稀缺资源来管理。 截断与扩展策略是一等设计问题，而不是事后补丁。
- 文档随功能一起发布。 RAG 知识库只有与产品同步演进，才能持续发挥作用。
- 在 Bedrock 上进行路由和缓存。 将每个工作负载匹配到合适的 Claude 模型，根据吞吐量和地理需求选择跨区域推理，并对稳定的提示词前缀应用分层缓存。
结论
构建 Agent Mode 要求 Postman 直面大语言模型能力与成熟产品结构之间的差距：界面假设、耦合的客户端、庞大的工具目录，以及分散在文档和团队中的知识。动态工具选择、基于模式的读取以及有意识的上下文工程，成为在 Postman 的开发者社区. Amazon Bedrock 提供了托管模型访问、 跨区域推理、依赖模型的 保留控制以及 提示词缓存 ，以支持生产架构。
无论你是在构建第一个智能体，还是扩展现有智能体，这些模式都可以帮助团队避免常见的智能体集成和扩展挑战。
欲了解更多信息，请参阅 Amazon Bedrock 文档,包括关于 跨区域推理, 提示词缓存以及 数据保护与保留的指导。相关实施指导请阅读 AWS Machine Learning 博客上的 Effectively use prompt caching on Amazon Bedrock 和 Amazon Bedrock 宣布推出全局跨区域推理，以提高吞吐量 。要探索该产品,请参阅 Postman Agent Mode 文档.
Postman 的生产环境实现是专有的,不作为公开示例仓库提供。