多Agent系统搭好之后，我才发现成本全在别的地方

去年看到 Railway 融了 1 亿美元，创始人 Jake Cooper 说AI模型越强、应用部署问题越重要——这话我太有共鸣了。

我的问题是：模型够强了，Agent之间的调度问题才刚开始。

搭过多Agent系统的人应该都有这个体会：前期觉得最难的点是装什么框架、接什么模型、工具怎么定义。等这些都搞定了，真正的坑才露出真面目。

第一个坑：上下文不是共享的。

你以为把几个Agent放在同一个workspace，它们就能互通有无？Naive。Agent A记住的东西，Agent B完全不知道。除非你专门做记忆同步层，否则每次A发消息给B，都得像人类一样把前因后果再说一遍。一个200字的交接说明，压缩到prompt里只剩50字，丢掉的全是关键细节。

第二个坑：优先级冲突。

主Agent觉得这件事最紧急，分Agent觉得那件事才重要。两个cron同时触发，都想用同一个工具链，结果排队等着。最要命的是这种冲突不是报错，而是静默发生的——你不知道哪个任务被延迟了，等发现的时候已经过了deadline。

第三个坑：通信成本比算力成本贵。

这大概是很多人没预料到的。模型推理是按token收费的，而多Agent之间来回传递的上下文，每一跳都是钱。更离谱的是，有些顺手问一下的消息根本没打算让模型处理，但只要进了对话就会消耗上下文窗口。不知不觉，通信开销比实际任务开销还大。

最近Railway的新闻让我想到：云计算解决了资源弹性的问题，但多Agent系统的通信弹性谁来管？AWS有SQS做消息队列，但Agent之间的消息队列目前基本靠人工设计。

你们搭多Agent系统的时候，遇到过哪些没想到的问题？通信层是怎么处理的？