Agent 之间的通信正在从"互相聊天"转向结构化信号。这不是语法偏好问题，而是可扩展性问题——当 3 个 Agent 用自然语言互相 @mention 时还能凑合，但 30 个 Agent 需要协调任务、传递状态变更、触发告警时，靠 LLM 读聊天记录来做决策就开始出错了。

Mastra 在 6 月 3-4 日的 release 里同时推出了两种信号模式：Notification Signals 和 State Signals。前者解决 Agent 到 Agent（或 Agent 到人）的异步通知——agent.sendNotificationSignal() 支持 priority（高优先级即时送达，低优先级批量汇总）、due-date dispatch（到时间自动投递），以及一个持久化的 notification_inbox 工具让 Agent 像读邮件一样 list/read/dismiss/archive。后者解决 Agent 内部各组件之间的状态同步——Processor 通过 computeStateSignal() 发布带 cacheKey 的 snapshot/delta，外部 Producer 通过 sendStateSignal() 写入同一 lane，运行时会自动去重。

这里的关键工程取舍是"信号"和"消息"的区别。消息（message）是对话流的一部分，序列化在 LLM 上下文里，一旦压缩或截断就消失。信号（signal）是独立持久化的记录，有自己的生命周期——创建、投递、已读、归档——不依赖 LLM 上下文窗口。这意味着一个 Agent 可以在不占用 context budget 的前提下感知到"CI 挂了""审批通过了""上游数据就绪了"这些事件。

一个容易被忽视的设计点：Mastra 的 working memory 也开始支持通过 State Signals 投递（useStateSignals: true），而不是像往常一样注入 system prompt。这解决了一个实际痛点——working memory 经常被塞进 system message，导致 prompt 缓存频繁失效。改成 signal 后，working memory 的变更不再影响主 prompt 稳定性。

作为 Agent 工程师，在架构设计时需要明确划分：哪些信息应该进入对话上下文（影响模型推理），哪些应该作为信号旁路投递（触发行为但不占 context budget）。把一切都当聊天消息处理，是 Agent 系统在规模上最容易犯的错误。