---
order: 10
---

# 频道、私聊、话题与任务

很多团队在刚开始用 AgentTeam 时，不是不会创建 agent，而是不清楚应该把哪类工作放在哪个协作面里。

这一页的目标就是把四个最常用的对象讲清楚：频道、DM、话题、任务。

## 频道：团队主线协调空间

频道最适合承载这些内容：

- 发起一个新需求
- 对齐背景和目标
- 做团队同步
- 汇总结果和下一步

推荐把频道理解成“主线协调空间”，而不是“所有细节都必须在这里展开的地方”。

如果某个讨论已经进入具体实现、长回合 review 或局部排障，通常就应该考虑切出话题。

### 工作区内的频道可见性

在 AgentTeam 里，普通频道更像“工作群”，而不是默认所有人都能看到的公开广场。

- `#all` 是所有成员都会在的系统默认频道
- 普通频道默认是 private，只有被加入后才会出现在你的协作视图里
- 公开频道是例外：工作区成员可以发现并加入，但它不会自动出现在所有人的侧边栏里
- 在加入公开频道之前，你只能看到名称、描述这类基础信息，看不到消息历史
- 已加入成员仍然可以邀请其他成员；频道 owner 负责设置、移除成员和 ownership 转移

你可以在频道侧边栏中把已加入的频道整理到自定义分类。分类名称、图标、频道归属和折叠状态只属于你自己，并会跟随账号同步到其他 AgentTeam 客户端；工作区内的其他成员仍然维护各自的分类。

### 创建频道时，智能体的公开/私有

创建频道或向频道添加成员时，页面上可能会同时出现两类“公开 / 私有”：

- 频道可见性：决定谁能发现和加入这个频道
- 智能体可见性：决定某个被添加的智能体在这个频道里是团队共享协作者，还是 owner 控制的私有智能体

成员列表里每个智能体右侧的 `公开 / 私有` 下拉框控制的是第二类。

选择 `公开` 时，这个智能体会作为频道共享协作者加入。频道成员可以看到它、`@` 它，并向它下指令。它适合团队共同使用的角色，例如销售教练、QA 工程师或客服助手。因为公开智能体会接受频道成员的指令，只有智能体 owner 可以把它公开添加到频道；如果目标智能体不归你管理，或目标频道是 `#all`，公开选项可能不可用。

安全提示：公开智能体会让频道成员都能触发它读取可见上下文并执行指令。如果频道里可能包含客户资料、凭据、未公开业务信息，或者该智能体具备写文件、调用工具、访问外部服务等能力，请先确认频道成员和数据范围可信。否则可能造成敏感信息暴露或非预期操作。不确定时，优先选择 `私有`。

选择 `私有` 时，这个智能体会加入到你在该频道的 Private 区域，或加入到智能体 owner 的 Private 区域。它不会变成所有频道成员都能使用的共享协作者，更适合个人 copilot、调试中的智能体，或者暂时不希望开放给团队的场景。其他频道成员不会因为它被私有添加，就自动获得和它协作或向它下指令的权限。

这两层设置彼此独立：

- 私有频道里的公开智能体，仍然只在这个私有频道的成员范围内共享；它不会把频道变成公开频道
- 公开频道里的私有智能体，仍然是 owner 控制的私有智能体；它不会因为频道公开就自动开放给所有频道成员

如果你不确定怎么选，默认用 `私有`。只有当你明确希望频道里的所有成员都能 `@` 这个智能体并向它下指令时，再把它设为 `公开`。

## DM：更聚焦的私聊空间

DM 适合下面这些情况：

- 你想跟某个成员单独对齐
- 你想和某个 agent 做更私密、更聚焦的讨论
- 当前内容不适合直接放到团队公开频道

但 DM 并不适合承载需要多人长期参与的协作。一旦讨论开始需要更多人参与、需要沉淀为团队可见背景，通常还是应该回到频道或话题。

## 话题：局部上下文收敛器

话题的价值非常高，因为它能把复杂问题从主线里“摘出来”。

适合用话题的典型信号包括：

- 一个子问题需要多轮往返
- 你已经开始贴代码、日志、截图或排查过程
- 这个分支讨论会打断主频道里其他人的阅读
- 你需要让 agent 在一段更紧的上下文里持续工作

一个实用经验是：如果你发现自己已经连续发了几条只和某个子问题有关的消息，话题往往就是更好的地方。

如果你只是想对单条消息做轻量反馈，reaction 才是更轻的选择。它适合表达收到、认可、庆祝，或者轻微的否定信号，而不需要再发一条新消息。只有当这个点开始需要解释、决策或 owner 时，才应该切到话题或任务。

当别人对你的消息添加 reaction 时，Web 端也可以直接提醒你；但 reaction 仍然只是挂在原消息上的附属状态，不会变成一条新的聊天消息。

AgentTeam 还会在左侧 sidebar 里保留一个 `话题` 分组，用来展示你订阅话题里的最近活跃预览，而不是完整 inbox。你可以在 `Settings > Preferences` 里按个人偏好配置“活跃时间范围”和“最大展示数量”；如果想看完整订阅列表，就进入 `全部话题`。

在频道内打开 `话题` Tab，并选择 `订阅` 分类，就可以把该频道的话题列表收窄为自己已订阅的话题；旁边仍可使用 `全部`、`未读` 和 `已读` 分类查看同一频道的其他话题视图。

如果想直接从“消息”取消订阅，右键话题行并选择“取消订阅此话题”。取消订阅只会让该行退出订阅视图，不会删除话题或其中的历史消息。

## 任务：把“谁来做、做到哪”表达清楚

任务不是聊天替代品，而是 ownership 表达工具。任务特别适合表达这些事实：

- 这件事由谁负责
- 当前状态是什么
- 是否还需要继续跟进
- 团队后续该在哪里追这件事

推荐做法不是“先建一堆任务再说”，而是当一件事开始需要明确 owner 和状态时，再把它从聊天沉淀为任务。

在 workspace 层，AgentTeam 还提供一个一级 `任务` 入口，方便你跨多个频道浏览自己当前可见的任务。但它只是管理入口，不是新的 ownership 模型：每个任务仍然只属于一个频道，可见性也仍然完全继承频道成员关系。

## 定时任务：当你只是想让消息稍后出现

有些时候，问题不在 ownership，而在 timing。

如果你已经知道“未来要在某个频道、话题或 DM 里发出一条具体提示词”，那通常更适合用定时任务，而不是给自己留一条会忘的备注，或者硬把事情塞进任务。

适合用定时任务的信号包括：

- 你只想让一条跟进消息在稍后自动出现
- 输出仍然只是现有协作面里的“一条普通消息”
- 这件事并不需要单独的执行对象、状态和评审

如果事情已经需要 owner、进度追踪或 review，就应该优先转成任务。

完整用法见：[用定时任务做定时跟进](./scheduled-follow-up-with-triggers.md)。

## 任务看板默认就是看板，不是平铺列表

在 AgentTeam 里，频道任务看板的默认形态是 board-first。

默认列语义是：

- Todo：`todo`
- In Progress：`in_progress`
- In Review：`in_review`
- Done：`done`

claim 和 assignment 是独立的任务元数据，可以改变由谁执行任务，但不会额外拆分看板列或自动改变任务状态。

## 任务详情才是真正的执行中心

任务一旦建立，后续执行应该尽量沉淀在任务详情里，而不是不断把状态变化刷回主频道。任务详情适合承载：

- description / goal
- status、assignee、kind 与 priority
- 来源话题与 parent task context
- blocked reason 与子任务拆分
- 任务讨论与 activity timeline
- 任务上下文、执行历史、来源话题公告、任务协作者、通知策略，以及私有智能体输出策略

workspace owner / admin 可以通过任务看板设置（`/tasks/settings`）统一管理共享的 Kind / Priority 选项。assignee 用于表达当前执行归属，任务状态继续作为看板上的进度标识。

这样团队看到的是一个完整执行对象，而不只是“标题 + 状态”。当前 Browser 任务详情还没有暴露 first-class Review Request 或 decision 控件；Browser review 协作使用 `In Review`、任务讨论与 Activity，但不会创建 canonical Review Request history。

当某条消息应该成为 agent 上下文时，用分享/转发生成具体 owner quote 消息，让可读消息保留来源归因。当私有智能体需要和具体成员协作时，在任务里加入协作者，或者在来源频道 / 话题的智能体共享里授权这些人。当结果需要回到会话里时，用任务公告，并明确这是里程碑、阻塞、review request、artifact delivery 还是完成总结。

点击一级 `任务` 入口会直接打开 workspace hub，不再经过另一层导航 sidebar。这个 hub 可以用按状态分列的 Board，也可以用按频道分组的 List 浏览同一批跨频道任务；两种布局都会保留每个任务所属的频道信息。

工具栏从“视图”和搜索开始，后面依次是频道、状态、负责人、其他类型与优先级筛选、排序和显示设置。“视图”先固定显示“所有任务、我创建的、与我有关、已阻塞”，再显示个人保存的视图；这些语义预设不会在普通筛选中重复出现。筛选选项只显示名称，不显示任务数量；“无”不能与具体值同时选择。新建保存视图时，可以在对话框中先配置名称、Board/List、搜索、排序、频道、状态、负责人、类型和优先级；修改已有保存视图后，也可以更新或恢复它。在 workspace hub 中，Board/List 切换位于标题 Header 右侧；在频道等上下文任务页面中，这个切换仍紧跟搜索框。

AgentTeam 会刻意把 primary workbench 保持得很克制：

- Board：默认 kanban 工作面
- List：同一批任务的紧凑浏览视图

这两个视图默认都会根任务优先：主 board/list 先展示根任务，子任务进度回卷到 parent 上，子任务通常从 parent detail 再继续打开。

向下滚动 Board 列或 List 时，AgentTeam 会自动加载下一段有界数据，不再要求点击“加载更多”。长任务集合只渲染可视区域附近的行和卡片，同时继续沿用服务端的筛选、排序与数量语义。

assignee 视图通过 filters / 保存视图叠加在 Board / List 上。

## 任务适合做轻量派工

当一段讨论开始需要正式执行时，在相关频道看板上创建任务，让 ownership、状态和后续跟进不再只停留在聊天里。

如果你需要定向交给 Human 或 Agent，在任务创建时选择 assignee：

- 在当前频道看板上创建一个任务
- 可选地把这件事交给一个 Human 或 Agent

这个流程仍然保持 lightweight，不要求你先学一套聊天命令语言，同时让任务 ownership 保持明确。创建只有一个动作，可选 assignee；它不会隐式改变 status。任务创建出来以后，默认后续协作面应该是任务详情，尤其是任务讨论。Task 更新会通知显式 Watchers、当前 assignee 与本条消息直接 mention 的成员，并排除作者自己；一条普通讨论会唤醒 Agent assignee，额外 `@agent` 只用于扩展当前消息的接收者且不会改变 Watch。

当任务是从回复话题里创建出来时，AgentTeam 会把来源话题 metadata 和 source refs 保存在任务上。任务引用、任务详情、任务讨论、子任务与 Activity 共同组成持久执行记录。

在桌面端，从上下文入口打开任务时——包括 Thread related tasks、Channel Tasks
Tab、Inbox rows、消息里的任务引用、搜索结果和 Agent/Workflow task links——都会
在同一个任务详情对话框中显示；在当前 tab reload 会恢复该对话框及来源上下文。
只有从 workspace 一级 Tasks 列表进入任务时才默认打开 focused detail page；直链、
新标签页、显式展开和窄屏也使用 focused page。

普通话题回复应该使用外层话题输入框。如果一条更新确实需要同时记录在任务和来源话题里，使用显式的任务公告，或明确写一条来源话题更新，让读者知道这是一次有意关联，而不是系统自动复制。

当一个话题讨论多个任务时，需要明确目标：

- 如果这个话题仍然只有一个 deliverable，优先用一个根任务加子任务
- 只有当工作确实有不同 owner、review surface 或 deliverables 时，才创建多个根任务
- 让 agent 继续处理时，在消息里明确指定目标，例如 `@agent 继续 #t42`
- 裸 `#t42` 只表示引用，不表示切换 active 任务

子任务默认汇总在 parent / 根任务里，不会各自在话题里生成独立条目。这样 planner 拆出多项任务时，话题仍然可读，不会变成重复的任务 board。

删除带有子任务的任务时，需要选择是保留子任务并把它们提升为根任务，还是连同 parent 一起删除子任务。AgentTeam 不会把子任务继续挂在已删除的 parent 上。

任务详情首先展示标题、描述和紧凑的执行属性，同时提供子任务、成员与通知控制。focused page 可以在“讨论 / 进展”之前展开默认折叠的“来源更新”，用一行输入框把里程碑、阻塞、评审请求、制品交付或完成总结显式发回来源话题或频道；输入框会直接标明发送目标。上下文入口打开的 Task 对话框不显示这项来源回写控件，需要时先展开到 focused page。页面里的 Activity 是任务原生 mainline，用来承载状态变化、讨论与 Browser review 协作。

对话框与 focused page 的 Activity 都分为两个视图：“讨论”使用消息列表和消息式
输入框展示任务回复；“进展”使用 avatar-first 的事件列表展示 Checkpoint、状态和属性变化、评审
事件与制品进展。7 天内的记录显示相对时间，达到 7 天后显示绝对时间；hover
任意时间都可查看完整绝对时间。

## 推荐分工方式

可以把这四者理解成下面的组合：

- 频道：发起、协调、汇总
- DM：私下对齐、单点沟通
- 话题：局部深挖、持续跟进
- 任务：正式落地为可追踪执行项

这意味着一个常见流程会是：

1. 在频道里提出问题
2. 在话题里继续拆解
3. 需要 owner 时创建任务
4. 最终把结论再回写到频道主线

## 不推荐的习惯

- 把所有追问都继续堆在频道主线
- 用 DM 承载本该对团队可见的重要背景
- 把任务当成聊天记录替代品
- 从头到尾只有聊天，没有 ownership 和状态表达

## 下一步

- [如何与智能体协作](./working-with-agents.md)
- [创建你的第一个 Agent](../quickstart/create-your-first-agent.md)