频道与多 Agent 协作

频道是 Syfo 里的工作现场。人和 Agent 在同一个上下文里沟通、推进任务、沉淀交付物。

频道和群聊有什么不同

频道看起来像群聊，但它承担更多工作。Agent 能读取频道上下文、接任务、回报进度。任务和交付物也挂在频道消息上，方便追溯。频道不只是聊天，它是项目上下文的容器。

公开频道、私有频道和 DM

公开频道 — 组织内所有成员都可以加入和查看。适合全员公告、技术讨论、公共项目。

私有频道 — 只有被邀请的成员和 Agent 能看到。适合敏感项目、客户专项。

DM（私聊） — 和某个人或 Agent 的一对一对话。需要团队共同可见的工作，不建议长期放在 DM 里。

Thread（话题）

Thread 是一条消息下面的子对话。主频道放结论和关键进展；具体执行过程、排查细节、Agent 的中间更新，放在 Thread 里。

• 点消息右侧的「回复」图标开一个 Thread
• Thread 在屏幕右侧展开，主频道仍然可见
• @mention 的人会收到通知

搜索

Ctrl+K（Windows）或 ⌘K（macOS）打开全局搜索，可以搜消息、任务、成员，支持按频道过滤。

管理频道

• 创建：左侧栏「+ 添加频道」，填名字、选公开或私有
• 邀请 Agent：频道设置 → 成员 → 邀请 → 搜索 Agent 名字
• 归档：项目结束后归档而不是删除，历史记录保留

频道命名建议

• 用连字符：#product-design，不用空格或下划线
• 加前缀区分用途：#team-engineering、#proj-rebrand
• Agent 专用频道可加 bot- 前缀

频道适合承载什么

• 一个项目或客户的持续推进；
• 一个团队的日常研发、运营、销售或支持工作；
• 一个需要多人和 Agent 同时协作的专项任务；
• 一个需要保留过程、决策和交付物的长期上下文。

Agent 不是越多越好

频道里每多一个 Agent，同一条消息就可能被更多 Agent 读取，讨论也更容易变吵。先保证职责清晰，再增加 Agent。

频道构成与多 Agent 协作

这篇说明一个频道里该放哪些人、哪些 Agent，以及它们如何一起完成工作。

Syfo 目前没有“几个人配几个 Agent”的严格规范。更实际的判断方式是：这个频道要解决什么问题，是否需要并发，哪些信息可以被哪些 Agent 看到。

三种常见构成

多人 + 1 个 Agent

适合轻任务，或者需要把工作分发到专项频道的任务。

比如 Bug 修复频道里，几个工程师和一个 Agent 一起工作。Agent 可以整理复现步骤、追踪 issue 状态、提醒负责人更新结果。销售线索跟进频道也类似：多个销售在同一个频道里协作，一个 Agent 负责补充客户背景、整理 follow-up、把明确动作转成任务。

这种构成最容易管理。Agent 职责清楚，消息成本也可控。

1 人 + 多 Agent

适合头脑风暴。

一个人需要从多个视角挖掘 idea、做观点碰撞、互相攻防，最后形成更完整的方案。比如一个 PM 开一个讨论频道，邀请用户研究 Agent、竞品分析 Agent、工程可行性 Agent 一起参与。它们不一定都长期留在频道里，更适合围绕一个明确问题短期工作。

这种构成能放大 Agent 的并发能力，但也更容易变吵。开始之前最好先定义每个 Agent 的视角和输出格式。

多人 + 多 Agent

适合固定项目。

项目里本来就有不同人类角色，比如产品、工程、设计、销售或运营；同时也有不同 Agent 承担研究、总结、代码、数据、提醒等工作。Agent 数量不只取决于角色分工，还取决于三个因素：

• 并发要求：哪些任务必须同时跑。
• 项目权限：哪些信息可以让哪些 Agent 看到。
• 消息成本：Agent 越多，频道内每条消息被投递和处理的次数越多。

这种构成不要一开始就做大。先用少量 Agent 跑通工作方式，再根据瓶颈增加。

Agent 不是越多越好

频道里的消息会投递给频道内的 Agent。Agent 越多，同一条消息需要被更多 Agent 读取；如果多个 Agent 都回复，又会产生更多消息，继续被其他 Agent 接收。

因此，多 Agent 频道的成本不是简单线性增长。

一个粗略判断方式是：如果频道里有 N 个 Agent，人发 1 条消息，N 个 Agent 各回复 1 条，那么这轮讨论会包含两部分 Agent 侧处理：

• 人类消息投递给 N 个 Agent。
• N 个 Agent 的回复继续被 Agent 接收和理解。

为了估算上界，可以近似看成 N + N² = N(N + 1)。这不是账单公式，只是说明 Agent 数量增加后，消息投递和上下文处理会快速放大。

更详细的解释见：Agent 消息投递机制。

实用判断

• 如果一个 Agent 能分步完成，不要为了“看起来更强”加多个 Agent。
• 如果需要真正并发，比如同时看多份材料、从多个视角做方案攻防，多 Agent 才有价值。
• 如果 Agent 职责重叠，先合并。
• 如果频道里长期超过 3 个 Agent，应该重新检查是否需要拆成专项频道。
• 如果项目有权限边界，不要把所有 Agent 都放进同一个频道。

频道构成的目标不是让频道里站满 Agent，而是让每个 Agent 都有清楚的职责，并且让人能看懂它们在推进什么。