Postman如何在Amazon Bedrock上为4000万开发者运行Agent Mode

从Demo到生产：AI Agent规模化的真实挑战

做一个能在演示里跑通的AI Agent，和为4000万开发者稳定运行一个Agent，是两个完全不同量级的工程问题。Postman与AWS联合分享了其Agent Mode背后的架构设计，核心经验围绕三个关键词展开：控制工具泛滥（tool sprawl）、基于Schema的只读访问，以及把上下文（context）当作真正的性能瓶颈来对待。

这篇内容的价值在于，它跳出了常见的「Agent炫技」叙事，直面了大规模生产环境中最棘手的几个工程取舍。对于任何正在构建企业级Agent应用的团队来说，这些模式都具备直接的参考意义。

控制工具泛滥：Agent不是工具越多越好

一个直觉上的误区是，给Agent接入越多的工具（tools），它就越强大。但在真实的大规模场景中，工具数量的膨胀恰恰是Agent可靠性下降的主要来源之一。

当一个Agent面对数十甚至上百个可调用工具时，模型需要在庞大的候选集里做出正确选择，这会显著增加误调用、幻觉调用和决策延迟的概率。Postman的做法是主动控制「工具泛滥」，即通过精心设计工具的边界与粒度，让Agent在任何给定上下文下只需要面对一个经过筛选的小规模工具集。

这背后反映出一个重要的工程哲学：Agent的稳定性往往不取决于它能做多少事，而取决于它在每个决策点上的选择空间有多可控。

工具泛滥（Tool Sprawl）在技术层面的成因值得深入理解。大语言模型在调用工具时，需要将所有可用工具的名称、描述和参数Schema一并放入上下文，由模型在推理时选择最合适的一个。当工具数量从10个增长到100个时，上下文中的工具描述本身就会消耗大量Token预算，同时模型的「工具选择」任务从一个简单的多选题变成了一个复杂的检索问题，出现语义相近工具之间混淆的概率大幅上升。一些团队采用的缓解策略包括：工具分组与动态加载（根据当前任务意图只注入相关子集）、工具聚合（将多个细粒度操作合并为一个语义更高阶的工具），以及基于向量检索的工具召回机制。Postman的选择代表了一种更为根本的设计哲学：在架构阶段就通过边界划定来阻止工具数量膨胀，而不是等泛滥后再治理。

Schema-based读取：用结构化约束换取可预测性

Postman强调的另一个模式是「基于Schema暴露只读访问」。与其让Agent自由地去探索和拼装请求，不如通过明确的Schema定义，把读取操作约束在可预测的结构之内。

这种做法有几重好处。Schema本身为模型提供了清晰的语义线索，让它更准确地理解可以读取什么、以什么格式返回；只读操作天然降低了Agent行为的风险面，避免在探索阶段产生破坏性副作用；结构化的输入输出也让整个链路更容易被监控、调试和回放。

对于一个服务数千万开发者的平台而言，可预测性几乎等同于可运维性。Schema-based的设计把Agent从一个「黑盒探索者」转变为一个在明确契约下工作的组件。

这里的Schema通常指OpenAPI Schema或JSON Schema，它以机器可读的方式描述了一个API端点接受什么输入、返回什么结构的输出。在Agent架构中，将Schema直接注入上下文，模型便能准确知道字段名称、数据类型和可选值范围，而无需通过试错来「猜测」接口行为。只读（Read-Only）的约束则对应HTTP语义中的GET操作，与POST/PUT/DELETE等写操作相比，它在副作用上具有幂等性——即使模型重复调用，也不会产生数据修改或状态变更。这一设计在多轮重试、调试回放等场景下尤为重要。将Agent的数据访问层限制在Schema定义的只读接口上，本质上是在Agent与底层数据系统之间引入了一层「契约」，把模型的自由探索行为转化为可审计、可版本化的接口调用。

上下文才是真正的瓶颈

整篇分享中最具洞见的观点，是把上下文（context）而非模型能力视为真正的瓶颈。

在实际的Agent系统里，模型的推理能力往往不是最大限制，真正拖累表现的是：如何在有限的上下文窗口里，为模型提供恰到好处的信息——既不能缺失关键依据，也不能被海量无关内容淹没。上下文管理直接决定了Agent的准确度、成本和响应速度。

这与前两点形成了一个闭环：控制工具泛滥，减少了需要塞进上下文的工具描述；Schema-based读取，让进入上下文的信息更紧凑、更结构化。三者本质上都是在为「上下文预算」服务。当团队把上下文当作一种稀缺资源来精细管理时，Agent的工程质量才真正进入可控轨道。

上下文窗口（Context Window）是指大语言模型在单次推理中能够处理的最大Token数量。尽管近期的前沿模型已将这一限制从4K扩展到128K乃至百万Token级别，但上下文管理仍是工程瓶颈，原因是多维度的：成本方面，Token数量与推理费用直接线性相关，在高并发场景下冗余上下文会带来显著的额外开销；延迟方面，更长的上下文意味着更高的首Token时延（TTFT）；准确性方面，研究表明模型对「长上下文中间位置」的信息存在注意力衰减（Lost in the Middle问题），海量无关信息反而会稀释关键依据的权重。因此，上下文管理已逐渐演化为一门独立的工程领域，涵盖摘要压缩、滑动窗口、记忆外化（将历史状态存入向量数据库按需检索）等多种技术手段。

运行在Amazon Bedrock上的规模化支撑

要支撑4000万开发者的调用量，底层的模型托管与推理基础设施同样关键。Postman选择在Amazon Bedrock上运行Agent Mode，借助其托管的大模型服务能力来应对规模化部署的挑战。

Bedrock作为AWS的托管生成式AI服务，提供了多模型接入、弹性扩展和企业级安全合规等能力。对于Postman这样需要在高并发下保持稳定的平台，使用托管基础设施可以把精力集中在Agent的架构设计与业务逻辑上，而不必自行承担大模型推理的运维负担。

给Agent开发者的启示

从Postman的实践中可以提炼出几条通用经验。Agent的工程重心正在从「让它跑起来」转向「让它在规模下稳定可控」。工具设计、Schema约束、上下文管理这三件事，看似分散，实则共同指向同一个目标：降低Agent在每个决策点的不确定性。

对于计划将Agent推向生产的团队，与其追求功能的大而全，不如优先建立起对工具集、数据访问和上下文的严格治理。这或许不如酷炫的Demo吸引眼球，但正是这些朴素的工程原则，决定了一个Agent能否服务于真实世界的海量用户。