Postman Agent Mode架构解析：170+工具如何缩至15个

Postman 的 Agent Mode 运行在 Amazon Bedrock 上，但真正值得关注的工程细节并非模型本身，而是围绕模型构建的整套系统。Postman 与 AWS 共同披露了三个相互关联的设计决策：为每个任务收窄可见工具集、通过专用路径准备上下文、以及在执行流程中保留人工审批。这些决策共同构成了一个可复用的 Agent 架构范式。

工具选择：从 170+ 到约 15 个任务工具

Postman 在测试中发现，当可见工具集超过约 40 个时，工具选择错误率开始攀升。这一观察直接催生了基于任务的检索机制。Agent Mode 不再向模型暴露完整的 170+ 工具目录，而是先搜索相关能力，将集合收窄到约 15 个，再交给上下文隔离的子 Agent 执行。

检索步骤因此变得至关重要——它决定了执行 Agent 能获得哪些能力。这种设计将工具选择的认知负担从模型转移到了检索系统，同时降低了误用工具的风险。对于结构化数据，Postman 还引入了 ClickHouse 表的 schema-aware 只读访问，允许直接查询结构化信息，而不是为每个问题单独构建窄口径工具。

任务检索（task-based retrieval） 是一种在运行时动态收窄模型可见工具集的技术。其核心思想是：不将所有可用工具一次性暴露给模型，而是先根据当前任务描述，在工具目录中检索出最相关的子集（Postman 的实践中约为 15 个），再将该子集交给执行 Agent。

这种方式与传统的“全量工具注册”形成对比。全量注册的优点是模型总能看到所有能力，但代价是选择空间过大，容易触发误选或幻觉调用。任务检索将“选哪些工具”的决策从模型推理转移到检索系统，检索系统可以基于语义相似度、工具描述、历史使用模式等信号进行排序。

需要留意的是，检索质量直接决定执行 Agent 的能力边界：如果检索漏掉了真正需要的工具，执行阶段将无法补救。因此，检索系统本身也需要可观测性和评估机制，而不仅仅是模型侧的性能指标。

上下文准备的两条路径

Postman 将上下文缺失或不完整视为主要瓶颈。为此，Agent Mode 设计了两种上下文获取路径：后台上下文从工作区自动收集，并在进入提示词之前进行精简；聚焦上下文则来自用户的选择或提及，并通过针对相关 Postman 对象定制的处理器传递。

这一设计存在明确的权衡：精简上下文限制了到达模型的信息量，因此拥有工作区访问权限并不意味着每个相关细节都能在提示词准备阶段存活下来。Postman 选择接受这一限制，以换取更可控的输入质量。

上下文精简（context pruning） 指在将收集到的信息送入提示词之前，主动过滤、摘要或截断内容，以控制输入 token 数量和信噪比。Postman 的后台上下文路径就采用了这一机制：从工作区自动收集的信息并非全部保留，而是在进入提示词前经过精简。

精简的收益是降低模型被无关信息干扰的概率，并减少 token 成本与延迟；代价则是信息损失——某些在精简阶段被判定为不相关的细节，可能在后续推理中被证明是关键的。这种权衡在长上下文场景中尤为突出：模型窗口越大，理论上可以塞入更多原始信息，但信噪比下降带来的推理质量损失往往超过信息量增加带来的收益。

因此，上下文精简策略需要与任务类型匹配：对结构化查询类任务，精简可以更激进；对需要跨对象关联的复杂任务，则需保留更完整的上下文，或通过多轮检索按需补充。

推理路由、缓存与数据脱敏

Agent Mode 通过 Bedrock 的推理 API 访问 Claude 模型，并利用跨区域推理配置文件路由工作负载。提示词缓存采用双检查点策略：稳定内容使用一小时检查点，可变上下文使用五分钟检查点。需要注意的是，缓存支持受模型限制，并非普遍保证。

在隐私方面，Postman 使用 Bedrock Guardrails 在数据到达模型之前脱敏 PII，企业管理员可以配置相关策略。这一层与人工审批形成互补：脱敏处理的是传递给模型的信息，而审批控制的是通过应用做出的变更。

提示词缓存（prompt caching） 是一种在模型推理层面复用已处理前缀的优化机制。当多个请求共享相同的前缀内容（如系统提示词、工具定义、稳定背景知识）时，缓存可以避免重复计算这些 token 的注意力状态，从而降低延迟和成本。

Postman 采用双检查点策略：对稳定内容使用较长的缓存有效期（一小时），对可变上下文使用较短的有效期（五分钟）。这种分层设计的逻辑是，稳定内容的复用频率高、变化少，长有效期摊薄了缓存建立成本；可变上下文变化频繁，短有效期避免缓存失效带来的额外开销。

需要注意的是，缓存支持因模型和 API 而异，并非所有模型都保证缓存命中。工程上应将缓存视为性能优化而非正确性依赖，并在缓存未命中时保证功能正常降级。

审批机制始终在环

Agent Mode 要求对修改应用状态的操作进行用户审批，后台请求发送也不例外。这意味着即使某些操作在后台异步执行，只要涉及状态变更，人工确认仍是必要环节。这种设计将人类判断嵌入执行流的关键节点，而非仅作为事后审计手段。

人在环（human-in-the-loop）审批 在 Agent 架构中通常指在执行流的关键节点插入人工确认步骤，而非仅在事后审计日志中记录操作。Postman 的设计要求所有修改应用状态的操作都经过用户审批，包括后台异步请求。

这与“事后审计”模式有本质区别：事后审计只能发现问题，无法阻止错误操作生效；人在环审批则在操作生效前进行拦截，将人类判断嵌入执行路径。代价是自动化程度降低——审批等待会引入延迟，且在高频操作场景中可能成为瓶颈。

因此，审批粒度的设计至关重要：过粗的审批（如整个任务一次确认）会削弱控制力，过细的审批（如每个工具调用一次确认）则会压垮用户。Postman 选择以“状态变更”为边界，在控制力和可用性之间取得平衡。

架构启示与待解问题

这份案例研究更适合作为架构走查来阅读——它记录了 Postman 如何界定工具范围、准备上下文、路由推理并保留人类控制。但研究并未提供经过测量的任务成功率数据，也没有独立的安全评估。

一个需要澄清的细节是：广为流传的“4000 万开发者”指的是 Postman 的开发者社区，而非 Agent Mode 的用户数。对于正在构建企业级 Agent 的团队而言，Postman 的实践提供了一个可参考的模板：用检索收窄工具集、用双路径管理上下文、用分层机制平衡自动化与人类控制。

本文基于 Agentic Affairs 的完整分析，更多源引用与架构图可参阅原文。