关键观点
先证明单 Agent，再扩展多 Agent多 Agent 系统不是起点，而是单 Agent 能力成熟后的扩展。演讲者用微服务演进作类比：无法构建结构良好的单体，通常也无法驾驭微服务。同样，如果单个 Agent 循环尚不可靠，增加协调者、子 Agent 和通信协议只会扩大故障面。Navan 因此采用单一主 Agent，并通过子技能和有限的子 Agent 扩展能力。
多 Agent 系统不是起点，而是单 Agent 能力成熟后的扩展。演讲者用微服务演进作类比：无法构建结构良好的单体，通常也无法驾驭微服务。同样，如果单个 Agent 循环尚不可靠，增加协调者、子 Agent 和通信协议只会扩大故障面。Navan 因此采用单一主 Agent，并通过子技能和有限的子 Agent 扩展能力。
为什么重要: 这能降低编排复杂度，使团队先解决真实的可靠性、测试和上下文问题。
支撑证据
if you can't build a single agentic loop, why go in and try to build a multi-agent orchestrated system?
Agent 运行时必须围绕状态重新设计传统 API 服务通常以无状态扩缩容为目标，但 Agent 需要持久会话、隔离和不同的生命周期。AWS、GCP 和 Azure 都在提供 Agent 运行时，但平台能力仍可能留下业务相关缺口。Navan 使用 AWS AgentCore Runtime，同时自行补充会话持久化与恢复能力。云运行时通常宣称框架无关，但往往更偏好自家的原生框架。