Postman Agent Mode 落地：工具、上下文与 Bedrock 的交付经验

先说结论

• 把 Agent 放进成熟产品，最大的坑不是模型质量或提示词，而是把“界面思维”翻译成“数据思维”的架构改造。
• 工具数量超过约 40 个后选择错误明显上升，Postman 的做法是按任务动态裁剪到约 15 个，并把工具与界面状态解耦。
• 真实瓶颈是上下文：渲染用的数据模型不能直接喂给模型，需要按实体类型做专用上下文处理器，并把上下文窗口当作可管理的稀缺预算。

背景

Postman 在 11 年演进中形成了大量界面驱动的假设：开发者通过展开侧边栏、切换标签页、打开请求来定位信息。Agent Mode 的目标是让用户以 AI 原生方式完成 API 测试、文档、发现与实现，而 Agent 是“对数据推理”，不是“在界面上导航”。Postman 与 AWS 在 AWS AI 博客 中披露，团队原本以为模型质量和提示设计最难，真正更深的挑战来自把 Agent 集成到一个成熟产品里。

架构上，Agent Mode 由客户端工具、Agent 编排、专用上下文与 Amazon Bedrock 推理组成，工具按任务限定范围，修改应用状态的操作仍需用户批准。Postman 最初假设缺失工具是最大阻碍，实践中缺失或不完整的上下文导致了更多失败。

为什么对 FDE 重要

对 FDE 而言，这不只是产品案例，更是从原型到生产交付的对照样本。Postman 的经验直接对应 AI Agent 企业部署 中常见的三个交付阶段：工具治理、上下文工程与推理成本。

编辑建议：不要只关注模型选型，先把“工具目录”和“上下文预算”当成交付计划里的硬约束。这两项在 Context Engineering 中有更系统的框架，可与 Postman 的做法对照。

Postman 在测试中发现，可见工具超过约 40 个后，模型会调用不存在的工具、传错参数，或选到语义合理但上下文错误的工具；更大更新的模型能减少但不能消除。这提醒我们在交付评审时，要把工具数量与调用成功率一起纳入验收指标，而不是默认“工具越多越好”。

现场落地建议

Postman 的三条可复用做法值得直接迁移到交付流程：

• 工具目录就是上下文预算的一部分。 按任务动态裁剪暴露给模型的工具，把“Agent 能做什么”与“界面恰好打开了什么”解耦。Postman 的根 Agent 会先查询工具嵌入向量库，把 170 多个工具缩小到约 15 个相关工具，再交给上下文隔离的子 Agent。
• 结构化数据优先给 schema 感知查询，而不是堆单目的读工具。 Postman 把 API Catalog 的多视图合并为一个查询工具，让 Agent 基于 ClickHouse schema 生成带 JOIN 和 WHERE 的复杂查询。工程重心从“为每个问题建一个工具”变成“把数据模型建好一次”，可扩展性更好。
• 上下文要按实体类型做专用处理器，而不是序列化界面数据模型。 界面对象是为渲染和传输设计的，直接序列化往往噪声大。Postman 为每个实体类型建 handler，把实体蒸馏成 Agent 需要的信息；同时把上下文窗口当稀缺预算，主动管理截断。

在推理层，Postman 把 Bedrock 当作路由与缓存问题来处理：按工作负载选择 Claude 模型、用跨 Region 推理应对尖峰流量、用地理推理配置满足数据驻留，并用两级提示缓存（稳定核心 1 小时、可变上下文 5 分钟）降低重复重算的成本。这些都属于交付阶段需要逐项确认的工程项。

风险与检查清单

• 工具幻觉与上下文错误： 验收时记录不同工具数量下的调用成功率与参数错误率，观察模型升级是否真的改善。
• 状态耦合风险： 修改请求的工具依赖标签页打开状态时，Agent 会退化成“模拟界面操作”。交付前检查工具是否已与界面解耦。
• 上下文噪声： 请求描述、OpenAPI 规范、请求体等开放式用户数据容易挤占窗口。确认每个 handler 都有明确的截断与扩展策略。
• 数据驻留与保留： 地理推理配置不等于数据留在客户自己的环境；需逐项核对当前 Bedrock 数据保护与保留文档，确认 zero data retention 是否对所用模型生效。
• 成本不可控： 生产 Agent 每轮都会重发大量稳定上下文。通过 cacheReadInputTokens 与 cacheWriteInputTokens 统计，并测量首 token 时间，验证缓存是否真正生效。

编辑建议：把上述风险点写进交付检查清单，并在上线前做一次“上下文预算审计”——统计每个请求实际喂给模型的 token 来源，找出噪声最大的 handler。这也是 FDE 职业路线 中从交付执行走向架构设计的关键能力。

常见问题

Postman 认为 Agent 落地的最大瓶颈是什么？

是上下文，不是工具。Postman 在博客中明确说，缺失或不完整的上下文导致的失败比缺失能力更多；界面数据模型不能直接序列化使用，需要按实体类型做专用处理器。

工具数量多少比较合适？

Postman 的测试显示，可见工具超过约 40 个后选择错误明显上升。他们的做法是把 170 多个工具动态裁剪到约 15 个相关工具，再交给子 Agent 执行。

如何控制生产 Agent 的推理成本？

通过两级提示缓存：稳定核心用 1 小时缓存，可变上下文用 5 分钟缓存，并通过 cacheReadInputTokens 与 cacheWriteInputTokens 统计用量、测量首 token 时间来验证效果。

---

来源：AWS AI — How Postman runs Agent Mode for 40 million developers on Amazon Bedrock