--- order: 20 --- # 如何与智能体协作 很多团队真正的挑战不是“怎么把智能体建出来”，而是“怎么让智能体在团队协作里表现得像一个清晰、可靠的执行角色”。 ## 把 `@智能体` 当成派工动作 在 AgentTeam 里，`@智能体` 应该被理解为一条明确的协作动作：你希望某个智能体真正开始处理某件事。 推荐在这些场景中使用 `@智能体`： - 你需要某个智能体给出分析、建议或执行结果 - 你已经知道这件事更适合哪个角色处理 - 你希望智能体在某个话题的局部上下文中继续跟进 不推荐在这些场景中滥用： - 只是发一条普通同步消息 - 还没有明确到底需不需要智能体参与 - 一个问题并不需要同时叫起多个智能体 ## 为什么普通消息默认不唤醒智能体 这是 AgentTeam 很重要的产品原则。 如果普通消息会默认唤醒所有智能体，团队很快就会遇到三个问题： - 噪音太大 - 成本太高 - 没有人知道一次真正的派工到底发生在什么时候 所以更推荐的习惯是：普通消息用于成员之间同步；需要智能体真正处理时，再明确 `@智能体`。 ## 在当前频道或话题统一控制自动唤醒 打开频道或话题的 **成员** 侧栏，在 **你的智能体** 分组中使用 **全部唤醒**，可以把当前协作面中你有权控制的智能体统一设为自动唤醒；使用 **全部静音**，则统一设为不唤醒。 这个操作只修改当前频道或话题中属于你的智能体。消息里的明确 `@智能体` 仍然只针对当前消息点名对应智能体。 ## 优先级变化时打断正在运行的智能体 如果智能体已经在处理旧任务，而你希望某条可见消息直接替代当前运行，请在这条消息的更多菜单里使用 **加急**。 - **发送** 会保持当前运行继续执行；新消息会进入普通刷新路径，等待智能体后续读取。 - **加急** 会把一条已经发出的可见消息标记为加急，显式打断对应智能体的当前运行，并把同一条消息作为下一条指令重新递交。 只在你确实希望智能体停下当前工作时使用它。它不会撤销已经发生的副作用，例如已写入的文件、已发送的消息，或打断前已经执行的外部命令。 ## 私有智能体通过协作者和任务协作 任务型工作应该落到任务上；非任务型的私有智能体协作，则通过智能体共享管理。 关键规则是： - 当工作已经需要持续执行时，先创建或复用一个任务，再把智能体的工作上下文沉淀到这个任务上 - 当私有智能体需要和来源频道、来源话题或任务里的具体成员协作时，把这些人加入协作者列表 - 用分享/转发生成具体 owner quote 消息，让智能体读取的消息保留来源归因 - 智能体的常规进展应该写入任务讨论、子任务与活动记录 - 当里程碑、阻塞、评审请求、产物或完成总结需要回到来源话题时，用 `任务公告` - 在任务策略中调整通知、智能体唤醒状态，以及私有智能体输出策略 - 后续跟进使用任务引用和任务详情；来源话题保持聚焦，只承载面向人的讨论和显式公告 协作者不等同于频道或话题成员。它们是 owner 明确允许和自己私有智能体协作的具体成员。协作者的消息可以成为可用上下文，但普通消息仍然不会自动唤醒私有智能体；只有明确提及、显式唤醒或任务讨论流程才会触发。 共享智能体仍然是频道协作者。私有智能体仍然保留 owner 控制的上下文输入与输出，日常协作应该明确协作者和任务。 ## 一个智能体一个清晰角色 比起创建很多“全能型智能体”，更推荐为每个智能体设计清晰的角色边界。 常见角色包括： - 代码实现型 - 代码 review 型 - 运维排障型 - 文档整理型 - 项目协调型 职责越清晰，团队越容易知道该叫谁，智能体之间也越不容易长期重叠和抢答。 ## 话题是与智能体协作的最佳场所之一 如果某个问题需要持续迭代，话题往往比主频道更适合与智能体协作。 因为话题可以： - 保留一个更紧的局部上下文 - 避免把主线刷满技术细节 - 让同一个智能体在同一个问题上持续跟进 推荐做法是：在主频道发起，在话题深挖，在需要时再把结果回写主线。 ## 什么时候应该转成任务 当一件事情已经不只是一次问答，而是需要负责人、状态和后续跟进时，就应该考虑建任务。 一个很实用的判断标准是： - 如果你希望下次能明确知道谁在跟、做到哪里、下一步是什么，它就更像任务，而不只是聊天 如果这项工作是从回复话题开始的，AgentTeam 会把来源话题 metadata 和 source refs 保存在任务上。后续执行放在任务详情和任务讨论中，由任务状态、子任务、讨论与 Activity 共同保存持久执行记录。如果同一个话题讨论了多个任务，可以在消息里明确指定目标，例如 `@agent 继续 #t42`。 ## 用任务做 lightweight 派工 当讨论开始变成正式执行工作时，使用任务创建流程创建可持续跟进的工作对象。 适合的场景包括： - 在相关频道看板上创建任务 - 当负责人已经明确时，把任务指派或启动给某个智能体 - 既把任务放到共享频道看板上，又让智能体收到结构化任务信息 它的目标不是替代聊天，而是在工作已经需要可持续执行对象时，不再只靠聊天硬撑。 如果一个大请求最终还是同一个交付物，默认形态应该先落成 1 个根任务，再把拆解继续沉淀到子任务、检查点与任务讨论里，而不是在看板上平铺出多个同级根任务。 ## 在当前浏览器中协调 review 当前 Browser 任务详情还没有暴露 first-class Review Request 与 review decision 控件。仅使用 Browser 协作时： - 把任务移到 `In Review` - 在任务讨论中附上 evidence 或链接 - 在同一条任务 Activity 中记录批准、修改意见与后续处理 - 决策明确后，把任务退回 `In Progress` 或推进到 `Done` - 只有当决策需要更大范围可见性时，才回到频道或来源话题 这样 Browser 协作仍然锚定在任务上，但不会创建 canonical Review Request 记录及其 decision history。 ## 团队早期最值得建立的习惯 - 只在真正需要时 `@agent` - 用职责命名 agent，而不是用模糊的人设命名 - 在话题中持续跟进复杂问题 - 对需要交付和追踪的事情建立任务 - 定期复盘：哪些 agent 真的创造价值，哪些只是制造噪音 ## 常见问题 ### 为什么智能体没有回应 优先检查： - 你是否真的 `@agent` - 这台机器是否在线 - 该智能体绑定的运行环境是否可用 - 当前问题是否已经在另一个更合适的话题中继续 ### 什么时候应该新建智能体，而不是继续复用已有智能体 当一类工作长期存在、上下文稳定、职责清晰，而且继续塞给现有智能体会让角色边界变得混乱时，就值得拆出新的智能体。 ## 下一步 - [设计智能体阵容](../agents/design-your-agent-team.md) - [频道、私聊、话题与任务](./channels-dms-threads-and-tasks.md)