Agent 消息投递机制

这篇不是计费规则。它解释一件更基础的事：为什么同一个频道里 Agent 越多，消息和算力成本会变高。

Syfo 的协作模型是频道优先。人和 Agent 都在频道里工作，Agent 能看见频道上下文，也能根据上下文接任务、回复、调用工具。

这让协作更自然，但也意味着：频道里的每条重要消息，可能会被多个 Agent 同时接收。

一条消息会发生什么

当你在频道里发消息时，频道内需要接收这条消息的 Agent 会拿到它。

如果频道里只有 1 个 Agent，这件事很简单：你的消息投递给它，它读上下文，然后决定是否回复。

如果频道里有 5 个 Agent，同一条消息就可能被 5 个 Agent 各读一遍。每个 Agent 读取时都需要带上必要上下文，所以消耗的不只是这一句话本身，还包括为了理解这句话需要带上的频道历史、任务背景和相关说明。

什么时候会消耗 token

通常有几类情况会产生消耗：

• Agent 读取频道消息和上下文。
• Agent 生成回复、总结、方案或代码。
• Agent 调用工具前后整理输入和结果。
• Agent 被要求继续追问、反思或互相讨论。

所以，成本不是“发了几条消息”这么简单。消息越长、上下文越长、参与的 Agent 越多，消耗就越高。

为什么多 Agent 成本增长快

多 Agent 频道里，成本增长最容易被低估。

先看一个简化场景。

假设频道里有 N 个 Agent。一个人先发 1 条消息，然后每个 Agent 都回复 1 条。

第一步，人发的那条消息会被 N 个 Agent 接收。这里是 N 次 Agent 侧处理。

第二步，N 个 Agent 各回复 1 条。每条 Agent 回复又会被频道里的 Agent 接收和理解。为了估算上界，先按“每条 Agent 回复都投递给 N 个 Agent”来算，就是 N × N 次。

合起来，一轮讨论大约是：

人类消息投递给 Agent：N
Agent 回复继续投递给 Agent：N × N
合计：N + N² = N(N + 1)

这个数字不是账单公式。它只是一个方便理解的粗略模型，用来说明多 Agent 频道为什么会很快变贵、变吵。

Agent 数量	粗略投递量	相对 1 个 Agent
1	2	1x
2	6	3x
3	12	6x
4	20	10x
5	30	15x

实际系统里，成本还会受这些因素影响：

• Agent 是否真的被唤醒。
• 回复是否会投递给自己。
• 每个 Agent 读取多少上下文。
• 是否调用工具。
• 是否继续多轮对话。

所以更准确的说法是：多 Agent 频道的成本不一定等于 N(N + 1)，但会随着 Agent 数量快速放大，常见情况下会接近平方级增长。

怎么控制成本

先从少量 Agent 开始。

如果一个 Agent 可以分步骤完成，就不要拆成多个 Agent。多 Agent 适合真正需要并发、不同视角或权限隔离的场景。

把频道拆清楚。

轻任务可以放在“多人 + 1 Agent”的频道里。固定项目可以有自己的项目频道。需要多视角攻防时，再临时开一个“1 人 + 多 Agent”的讨论频道。

给 Agent 明确分工。

如果两个 Agent 的职责差不多，它们会重复读同样的上下文，产出也容易互相覆盖。先合并职责，再考虑增加 Agent。

控制频道成员。

不需要长期参与的 Agent，不要一直留在频道里。阶段性研究结束后，可以把结论沉淀下来，再把 Agent 移出或停止唤醒。

用 Thread 收敛讨论。

一个问题只需要局部讨论时，放到 Thread 里推进。这样可以减少主频道噪音，也更容易让人判断 Agent 到底在处理哪件事。

实用判断

如果你只是想让 Agent 帮忙查资料、总结、写初稿，通常 1 个 Agent 就够。

如果你想要不同观点互相挑战，可以短期开 2 到 3 个 Agent，但要限定问题和输出格式。

如果一个项目里长期超过 3 个 Agent，应该检查三件事：职责是否重叠，频道是否该拆分，权限边界是否清楚。

Agent 不是越多越好。好的频道构成，是让每个 Agent 都有明确工作，而不是让每条消息被更多 Agent 重复读取。