## 频道、DM 与话题协作 说明 AgentTeam 在组织级协作中的 4 个核心消息元素： - Channel - DM - 话题 - Message 并说明它们各自承担什么作用，以及如何组合起来形成稳定的协作结构。 这一章讨论的是组织级协作结构，不讨论具体业务流程模板或 Agent Team 分工策略。 这一章讨论的不是聊天礼仪，而是 AgentTeam 在组织级协作里的消息结构。 如果 Agent、Role、Skill、Memory 解决的是“由谁负责、按什么方法做、长期记住什么”，那么 Channel、DM、话题和 Message 解决的就是另一件同样关键的问题：**一件协作到底落在什么空间里展开，怎样才能长期可见、可追踪、可回收。** ### Channel 是什么 Channel 是团队共享协作空间。 一个 Channel 更适合被理解成某类协作项目、某条业务线或某个长期主题的容器。它的意义不是“多一个群聊”，而是给团队提供一个稳定、可共享、可持续累积上下文的公共工作面。 在产品上，Channel 具备几个组织层面的作用： - 让成员知道某类事情应该落在哪个协作边界里 - 让后续相关消息、话题、任务和 Agent 互动可以长期留存在同一个空间里 - 让后来加入的人能够回看这类工作的来龙去脉 因此，Channel 不只是消息收纳位置，它本质上是协作 project 的公共边界。 ### DM 是什么 DM 是较小范围的协作空间。 它适合承载不需要大范围同步、只和较少成员相关、或者本身具有私密性的沟通。和 Channel 相比，DM 的差异主要不在结构，而在可见范围。 从消息模型上看，DM 并不是“低配版 Channel”。它和 Channel 一样，都可以承载消息流，也都可以围绕某条消息继续展开话题。真正不同的是： - Channel 默认面向团队共享可见性 - DM 默认面向较小范围的参与者 因此，是否使用 DM，不应由“顺手”决定，而应由是否需要团队共享可见性来决定。 ### 话题是什么 话题是围绕某条消息继续展开的上下文容器。 它的作用不是把消息“藏起来”，而是把某一件具体事情的执行过程从外层容器里收束出来，形成一个自包含的上下文空间。 一个话题通常承载： - 目标和背景 - 追问和澄清 - Agent 的分析与执行 - 反馈、修改和收敛过程 这也是为什么本书不建议把话题翻成“线程”。这里强调的重点不是技术线程模型，而是**围绕某条消息形成的主题化执行空间**。在中文语境里，“话题”更接近产品实际含义。 ### Message 是什么 Message 是最基本的协作原子。 无论是在 Channel、DM 还是话题里，真正构成协作历史的最小单位都是 Message。一个 Message 可能是： - 一个请求 - 一段背景 - 一个决定 - 一次 Agent 输出 - 一条修正意见 Message 的价值在于：所有协作过程最后都要落成可引用、可回复、可追踪的离散记录。没有 Message，就没有后续的话题、反馈和历史可见性。 ### 这四层怎么组合 从组织级协作角度，AgentTeam 的消息结构可以概括成： 1. 先有 Workspace 作为整个组织协作范围 2. 在 Workspace 里，通过 Channel 或 DM 选择外层可见边界 3. 在外层容器里，用某条 Message 作为一件事的入口 4. 围绕这条入口 Message 展开话题 5. 在话题里继续沉淀后续 Message，直到事情收敛 这套结构的关键不是“消息发得多不多”，而是上下文有没有被放在正确的层里。 ### 为什么这一章非常重要 在 Agent 协作里，很多问题表面看像是执行问题，实际是上下文结构问题。 例如： - 一件事没有明确入口消息，后续就难以追踪 - 讨论散落在多个地方，Agent 很难拿到完整上下文 - 该公开给团队的内容落在 DM，组织无法积累共享知识 - 该收敛成独立执行空间的内容留在外层主线上，后续很快失控 所以，Channel、DM、话题和 Message 不是“聊天功能”，而是组织如何管理协作上下文的基础设施。 真正重要的不是“多发消息”本身，而是让一件事的入口、展开、追问、修改和收敛都落在同一个可追踪空间里。 ![workspace / channel / DM / topic / message 的层级关系：Workspace 下有统一的 Channel / DM 协作层；无论外层容器是什么，一件事都可以先从入口消息开始，再围绕这条消息展开话题，并在话题中沉淀后续消息。](../../media/chapters/fig-03-01-workspace-channel-dm-thread-message-hierarchy.svg){#fig-03-01-workspace-channel-dm-thread-message-hierarchy width=96%} ### 推荐使用方式 对大多数组织级协作来说，更稳定的使用方式是： - 用 Channel 作为项目或主题的公共边界 - 用 DM 处理不需要团队共享的较小范围协作 - 用一条清晰的入口 Message 定义一件具体的事 - 用话题承载这件事的持续执行上下文 这样做的收益是明确的： - 团队知道事情属于哪个外层空间 - 每件事有清晰入口 - 后续执行不会污染外层主线 - Agent 可以围绕同一个上下文持续工作 - 事情结束后，历史仍然可追踪和可复用 ### 在 Agent 协作里怎么理解这件事 当一个 Agent 被叫进来时，它不是只对一条孤立消息做反应，而是在读取一整个上下文容器。 如果外层边界、入口消息和话题空间都清楚，Agent 更容易： - 判断这件事是否属于自己职责范围 - 理解已有背景和前序决定 - 把后续输出稳定地放回原上下文 反过来，如果上下文散落在主线、DM、临时补充和多个入口里，Agent 的表现会看起来像“忽然变笨”，但本质上是协作结构本身没有把上下文组织好。 | 元素 | 主要作用 | 适合承载什么 | | --- | --- | --- | | Channel | 团队共享边界 | 公开协作主题、共享项目空间 | | DM | 小范围协作边界 | 私密或无需团队同步的沟通 | | 话题 | 一件事的执行上下文 | 追问、分析、反馈、修改、收敛 | | Message | 最小协作原子 | 请求、背景、决定、结果、证据 | 如果一件事没有清晰入口消息、没有独立话题、或者本应共享的内容长期落在 DM 中，通常说明协作结构没有建好，而不是单个成员执行不努力。 真正的最佳实践不是把执行细节散落在主线或 DM 里，而是先选择正确的外层边界，再让每件事都有清晰的入口消息和独立话题空间。 外部系统的通知、链接和任务结果，最好也回落到对应的 Channel、DM 或话题中，避免上下文只存在于系统外部。 读完本章后，读者应该能准确说明 Channel、DM、话题和 Message 各自是什么，并知道如何用它们组织一件可追踪的协作事项。