新上线昨天0 投票
Postman 如何在 Amazon Bedrock 上为 4000 万开发者运行 Agent Mode
从演示到生产：Postman Agent Mode 的规模化挑战
构建一个能在演示中工作的 AI 代理，与为 4000 万开发者 运行一个代理，是完全不同的工程问题。Postman 在推出 Agent Mode 时，原本以为模型质量和提示设计会是最大的难题，但真正的挑战来自于将一个代理集成到拥有 11 年历史、界面驱动假设根深蒂固的成熟产品中。
为什么需要 Agent Mode？
Postman 已演进了 11 年，开发者习惯了通过展开侧边栏、检查标签页、打开请求来定位信息。而代理需要直接对数据进行推理，而不是导航屏幕。Agent Mode 提供了一种 AI 原生的工作方式，覆盖 API 测试、文档、发现和实现。
架构模式：控制工具蔓延与上下文瓶颈
Postman 和 AWS 分享了在让成熟产品对 AI 代理可读的过程中浮现的架构模式：
- 控制工具蔓延：避免代理可用工具数量爆炸，保持工具集精简且聚焦。
- 暴露基于 schema 的读取：让代理通过结构化 schema 直接读取数据，而非模拟界面操作。
- 将上下文视为主要瓶颈：不是能力不足，而是上下文窗口有限，需要精心管理。
这些模式帮助团队将生产级代理推向原型之外。
在 Amazon Bedrock 上运行
Agent Mode 运行在 Amazon Bedrock 上，该服务提供对基础模型的托管访问。Postman 的全球开发者社区产生 可变、延迟敏感且带有突发流量 的需求。借助 Amazon Bedrock，Postman 无需运营自己的模型服务基础设施，同时保留了模型选择的灵活性，并能控制吞吐量、地理处理和成本。
具体而言，Agent Mode 利用了 Amazon Bedrock 的以下能力：
- 模型灵活性：可根据任务选择不同基础模型。
- 地理范围的跨区域推理：满足数据驻留要求。
- 模型相关的零数据保留：确保数据隐私。
- 多级提示缓存：优化延迟和成本。
对生产级 AI 代理的启示
Postman 的经验表明，将代理集成到成熟产品中，需要重新审视产品的 API、用户体验和知识分布。团队应关注上下文管理、工具设计和 schema 暴露，而非仅仅追求模型能力。这些经验可以帮助更多团队将生产代理从原型推向实际应用。
