亚马逊工程师警告：AI Agent直接调用等于分布式单体，凌晨三点堵死你
内容提要
亚马逊工程师指出，AI Agent间直接同步调用会形成分布式单体，导致紧耦合、级联故障、扇出风暴及无法回放审计。解决方案是改用事件日志和消息代理，让Agent异步通信，通过持久化事件实现松耦合、可回放和审计。虽然增加延迟，但相比秒级推理可忽略，核心是避免脆弱性，确保系统稳定可维护。
延伸解读
同步调用的五个坑
文章指出，Agent间直接同步调用会同时踩中五个坑：紧耦合、级联故障、扇出风暴、缺乏背压、无法回放审计。紧耦合意味着调用图焊死在代码里，加个Agent就得改代码；级联故障让可用性相乘、尾延迟相加；扇出风暴导致并发失控；背压缺失造成阻塞或丢活；最致命的是没有日志，事故后无法复盘。这些坑在微服务时代就存在，Agent不应重蹈覆辙。
事件日志的三大好处
用事件日志替代直接调用，核心好处有三：持久化让事件先落盘，Agent宕机后可从断点续跑；回放功能支持重置消费者偏移量重跑事件，调试和修复问题更高效；审计记录天然生成，每个意图和结果都有时间戳，满足合规需求。此外，松耦合让增删Agent只需调整订阅，背压问题也转化为可监控的延迟。
延迟与可靠性的权衡
文章承认事件驱动会增加一跳延迟和代理维护成本，但强调Agent工作流瓶颈在秒级推理，毫秒级延迟可忽略。真正要防的是脆弱性和盲目性，而非延迟。对于少数真正同步、低延迟的两方交互，直接调用仍适用，但成网的调用图才是问题。核心是避免分布式单体，确保系统可维护、可回放。
Q&A
为什么亚马逊工程师认为AI Agent之间直接同步调用会形成分布式单体？
因为直接同步调用会导致紧耦合、级联故障、扇出风暴以及无法回放审计等问题，这与微服务架构中分布式单体的弊端相同。
AI Agent直接同步调用会带来哪些具体问题？
具体问题包括：紧耦合（A必须知道B的地址和接口）、级联故障（B挂了A也挂）、扇出风暴（一个事件激活多个Agent导致并发失控）、无法回放和审计（交互无日志）。
如何解决AI Agent之间的同步调用问题？
解决方案是使用事件日志和消息代理，让Agent通过发布和订阅事件进行异步通信，而不是直接调用。
事件驱动架构相比直接调用有哪些优势？
优势包括：持久化（事件先落盘）、可回放（可重放历史事件）、审计（有完整记录）、背压处理（延迟而非故障）、松耦合（增删Agent不影响其他）。
事件驱动架构会增加延迟，为什么仍然值得采用？
因为增加的延迟是毫秒级，而Agent工作流的瓶颈是LLM推理和工具调用，按秒计算，所以增加的延迟可忽略。真正的代价是脆弱性和盲目性，而不是延迟。
在事件驱动架构中，Agent之间的契约是什么？
契约是事件结构（event schema），即带版本号的类型化结构，而不是API。这样耦合面就集中在一个结构上，便于演进。
如何实现事件驱动架构中的请求/响应模式？
将请求和响应建模为关联的请求事件和响应事件，例如发布order.enrichment.requested和order.enrichment.completed，消费者订阅并处理。
在什么情况下仍然可以使用直接调用？
对于真正同步、低延迟、两方之间的交互，直接调用仍然没问题。问题在于形成调用网，而不是单次调用。
