做出一个能调用API的AI智能体并不难，难的是让它在成熟产品、复杂权限和突发流量中稳定运行。Postman与AWS 10月9日分享Agent Mode的生产经验，其中一个反直觉发现是：工具超过约40个，错误反而增加。

Postman服务的开发者社区规模约为4000万。其Agent Mode希望让用户通过自然语言完成API测试、文档、发现与实现等工作。团队最初以为模型能力和提示词会是最大难题，真正进入生产后，产品内部长期积累的界面假设、庞大功能面和分散知识才成为主要障碍。

智能体不能只学会“点击界面”

传统用户通过展开侧栏、切换标签页和打开请求找到信息，但智能体更适合直接对结构化数据进行推理。如果一个工具必须依赖当前打开的标签页，智能体实际上仍在模拟界面导航，容易受到界面状态变化影响。

Postman因此把智能体动作与界面状态解耦，通过面向模式的数据读取，让智能体先理解工作区、集合、请求和变量之间的关系，再选择动作。系统还能打开拉取请求并提出下一步建议，而不要求用户手动走完全部界面路径。

工具越细，不一定越可靠

早期架构倾向于提供大量原子工具：每个工具只负责打开一个请求、更新一个字段或获取一小块元数据。这种设计便于控制，但真实工作流需要连续调用许多工具，每一步都要返回模型再决定下一步，累计延迟明显。

更重要的是，Postman测试发现，当模型可见的工具集超过大约40个后，工具选择错误增加。模型可能调用不存在的工具、给出不正确参数，或选择语义相近却不适合当前上下文的工具。更大的新模型能缓解问题，但没有消除它。

当前设计不再一次暴露全部能力，而是根据任务和上下文动态挑选相关工具，并隔离不同执行线程。这意味着企业设计智能体时，不只要计算令牌预算，也要管理“工具预算”。

上下文比模型能力更容易成为瓶颈

成熟产品的知识散落在界面逻辑、API模式、内部文档和团队经验中。简单地把整个渲染模型序列化给AI，会带来噪声、成本和截断风险。Postman为不同任务构建专用上下文处理器，并把文档更新与功能发布绑定，避免检索知识库长期滞后。

系统还采用分层提示缓存：相对稳定的系统提示、智能体规则和核心工具定义使用一小时缓存；更容易变化的会话上下文使用五分钟缓存。团队通过缓存读写令牌和首个令牌时间验证实际收益，而不是默认“开启缓存就一定省钱”。

生产智能体必须把人类确认写进架构

Agent Mode在修改应用状态前要求用户批准，并按任务限制工具范围。企业管理员还可启用Amazon Bedrock Guardrails，在内容进入底层模型前遮蔽个人身份信息。对支持的模型，Postman配置零数据保留；但AWS强调，具体能力与行为依赖所选模型，需要逐一核对当前文档。

面对全球开发者的突发流量，系统使用Bedrock跨区域推理：需要处理地域边界的工作负载选择限定地理范围的配置，其他任务可选择全球路由以获得更高吞吐。地域配置并不代表推理发生在Postman自有环境，数据仍由符合配置范围的AWS区域处理。

编辑观察：少给工具，反而让智能体做得更多

Postman的经验说明，智能体可靠性不是“模型越大、工具越多”就会线性提高。动态暴露少量相关工具、提供清晰数据模式、控制上下文、要求高影响动作确认，往往比堆叠功能更重要。

企业上线智能体前，可以统计每类任务需要的工具数量、连续调用长度、失败重试和人工接管率。当可见工具持续膨胀时，应优先合并语义接近的能力、建立任务路由和结构化读取层，而不是继续增加提示词解释。生产化的关键，是让模型面对更小、更明确、更可审计的行动空间。

配图为AIcent原创AI生成实景风格示意图，非官方新闻现场照片，不使用第三方新闻图片。

参考来源：AWS官方技术博客（2026年10月9日）。正文为基于官方消息的中文整理，编辑观察与事实披露分开呈现。