Postman 如何在 Amazon Bedrock 上为 4000 万开发者运行 Agent Mode：工具超过 40 个后选择错误率上升，上下文才是真正瓶颈
来源AWS Machine Learning查看原文
速览
- 把 Agent 接入成熟产品的难点不在模型，而在界面假设、客户端耦合与知识分布
- 工具不是越多越好，超过约 40 个后选择错误率上升，需按任务动态收窄
- 用 schema 感知的读取替代工具堆砌，把成本转移到数据建模上
- 上下文缺失比能力缺失造成更多失败，需为每类实体建专门的上下文处理器
- 不要把渲染用的数据模型直接喂给模型，要建面向推理的上下文
- 上下文窗口是稀缺预算，截断与展开策略是一等设计问题
- RAG 知识库必须与产品功能同步演进，否则很快失效
- Bedrock 侧按工作负载选模型、选跨区域推理配置、做分层提示词缓存
Postman 与 AWS 联合发布技术博客，复盘了 Postman Agent Mode 在生产环境中的架构设计。Agent Mode 是 Postman 面向 API 测试、文档、发现与实现场景推出的 AI 原生入口，运行在 Amazon Bedrock 之上，服务其 4000 万开发者社区。团队原本以为模型质量和提示词设计是最难的部分，实际最深的挑战来自把 Agent 集成进一个已有 11 年历史、界面假设根深蒂固的成熟产品。文章给出的核心结论包括：在 Postman 的测试中，当可见工具集超过约 40 个时，工具选择错误率上升，Agent 会调用不存在的工具、传错参数或选到语义上合理但语境错误的工具；当前架构通过向量数据库检索工具嵌入，把 170 多个工具收窄到约 15 个再交给上下文隔离的子 Agent。此外，Postman 把多个窄视图合并为单一查询工具，让 Agent 基于 ClickHouse 表结构直接生成带 join 和 WHERE 的复杂 SQL，把工程工作从「为每个问题造一个工具」转为「一次性把数据建模做好」。团队还发现，缺失或不完整的上下文导致的失败多于缺失能力，因此构建了专门的上下文处理器，把每个实体蒸馏成 Agent 真正需要的信息。在 Bedrock 侧，Agent Mode 使用跨 Claude 系列的模型灵活性、跨区域推理、模型相关的零数据保留以及多级提示词缓存。
关键事实
- Postman Agent Mode 服务其 4000 万开发者社区，运行在 Amazon Bedrock 上，使用 Anthropic Claude 系列模型
- Postman 已有 11 年历史，Agent Mode 覆盖 API 测试、文档、发现与实现四类场景
- 在 Postman 的测试中，可见工具集超过约 40 个后，工具选择错误率上升；更大或更新的模型能减少但无法消除该行为
- 当前架构中，根 Agent 通过查询工具嵌入向量数据库，把 170 多个工具收窄到约 15 个，再交给上下文隔离的子 Agent
- Postman 把 API Catalog 等多个窄视图合并为单一查询工具，Agent 可基于 ClickHouse 表结构生成带 join 和 WHERE 的 SQL
- Agent Mode 对会修改应用状态的操作要求用户批准，并使用 Amazon Bedrock Guardrails 在数据进入 LLM 前脱敏个人身份信息
本站视角
这篇文章的价值不在「Postman 用了 Bedrock」这个事实，而在于它把生产级 Agent 的失败模式讲得足够具体。首先受影响最直接的是国内做 Agent 平台的团队和把 Agent 嵌入既有 SaaS 的厂商：40 个工具这个经验阈值、170 收窄到 15 的动态选择机制、以及「上下文缺失比能力缺失造成更多失败」的判断，都是可以立刻拿去对照自己架构的检查项。很多团队仍在用「把所有 API 都包成工具丢给模型」的做法，这篇文章等于给出了这条路的天花板。其次，做企业级 Agent 的团队应关注其中关于数据保留、地理边界和 PII 脱敏的部分——这些不是技术选型，而是能否通过企业采购的门槛。我们的判断是，这篇文章的实质信息量高于一般厂商联名博客：它承认了早期原子化工具路线的失败，也承认更大模型只能减少而不能消除工具选择错误，这种「承认踩坑」的表述通常意味着经验来自真实生产环境而非演示。但需要指出几点可疑之处：文章没有给出任何量化指标，比如工具选择错误率的具体数值、延迟改善幅度、缓存带来的成本下降比例，所有结论都是定性描述；「约 40 个工具」这一阈值来自 Postman 内部测试，样本和方法均未披露，不宜当作通用常数；文章由 AWS 与 Postman 联合署名，Bedrock 的四项能力被逐一正面呈现，带有明显的产品推广动机，读者应把架构模式与平台选型建议分开看待。对中文开发者来说，最值得跟进的是上下文工程那一段——把渲染数据模型与推理上下文分离、为每类实体写专门的处理器，这个思路与具体云厂商无关，可以独立落地。
背景与影响
Postman 从 API 调试工具起步，11 年间成长为覆盖测试、文档、Mock 服务器、监控、API Network、工作区治理、变量、代码生成等大量功能的平台，用户习惯通过展开侧边栏、切换标签页、打开请求等界面操作来定位信息。Agent Mode 试图让开发者以 AI 原生方式完成这些工作，但 Agent 是对数据做推理，而不是在屏幕上导航，这暴露出产品 API、用户体验和知识分布中的结构性假设。这意味着把成熟产品「翻译」给 Agent 理解，工作量可能远超模型选型和提示词调优。文章由 Postman 高级工程师 Srinivas Kini 与 AWS 解决方案架构师 Shubham Gupta 联合撰写，属于厂商技术博客，Postman 的生产实现为专有代码，未提供公开示例仓库。对国内做 Agent 的团队而言，文中关于工具数量阈值、上下文处理器、schema 化读取的经验具有直接参考价值，尤其是那些试图在已有 SaaS 或内部系统上叠加 Agent 能力的团队。需要观察的是，40 个工具这一阈值来自 Postman 自身的测试，未必能直接迁移到其他产品形态；工具嵌入检索、上下文处理器等方案也会带来额外的工程与维护成本，是否值得取决于产品表面的复杂度。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
