想象一个团队同时开着四十个对话。在一个对话里，有人让智能体准备客户方案。在另一个对话里，同事正在问交付时间。第三个人则在确认，同一个功能能不能在这个月上线。
每段对话都从交代背景开始。这是客户。这是我们作出的承诺。这是昨天定下来的事。智能体各自开工，却只看到不同的片段。直到有人发现，方案里承诺的日期，早已在工程讨论中被排除了。
然后，一个 Task 结束了。它的对话安静下来。一周后，另一个人开始做相关工作，又把背景讲了一遍。
在构建智能体时，我们反复想到这个场景。我们希望下一项工作能从团队已经学到的东西出发。于是，我们走向了单一会话的设计：一个持续存在的主对话，配合独立执行各项 Task 的 Worker。
子智能体帮助分工。单一会话回答另一个问题：随着工作推进，对这些工作的理解放在哪里？我们同时使用这两种做法。主对话让团队的工作接续下去，Worker 给每项工作独立展开的空间。
从个人到频道，再到团队
Poke 给个人智能体安排了一个简单的归处：一个人，一个对话（2025 年 9 月）。它把一个人的邮件、日历和文件接到文字对话里。起草回复或调整会议时间，都可以从上一次请求所在的地方开始。随着一天的事情不断推进，这个对话成了可以持续回来的地方。整个体验围绕个人与智能体的关系展开，也让我们看到了不同工作之间如何保持连续。
Claude Tag 把一个 Claude 带进了频道（2026 年 6 月 23 日）。频道里的任何人都能提及同一个智能体、看到它在做什么，并接着同事的讨论往下走。Claude 会逐渐记住相关信息，使用管理员开放的工具。发布介绍也提到，在获得许可时，它能从其他频道和信息源中学习。我们关注的是这种共享对话：人们可以在原本讨论工作的地方，把工作交出去。我们的设计则把团队的主对话作为归处，接住不同讨论和 Task 带回来的信息。
我们选择探索一个团队、一个对话。上下文跟着团队的工作跨越不同讨论。关于交付的决定，可以影响客户方案，即使这两项工作最初发生在不同地方。
2026 年 4 月 28 日，我们发布了前一个产品 Bridge 的第一篇相关文章。这段探索晚于 Poke，早于 Claude Tag。随后，我们在当前产品 Comma（2026 年 10 月 1 日）中继续这项工作，这套设计今天就运行在 Comma 上。
2026 年 10 月 31 日，DeepSeek Harness 也介绍了 Super-agent 的探索。它会在群聊中主动跟进代码工作，呼应了同一个方向：把协调工作从人手里接回系统。这是沿着自身设计展开的研究原型。
DeepSeek 的设计文章第 8.4 节把两个问题列为待探索：云端入侵或提示词注入可能危及连接的设备，凭据进入模型上下文也可能在正常执行时泄露。我们已经在运行的内容流向关卡是 IFC：每次发送声明来源，按目的地读者范围检查，过不了就拒绝，必要时申请特定范围的人工授权。
凭据走另一层。模型只指定凭据引用，执行层解析并注入凭据值，不把值交给模型。
团队留下了什么
设想一位新同事加入了客户方案的工作。他进入的是团队一直使用的同一个主对话。他可以看到其中的决定，问清楚日期为什么变了，然后接着做，而不用找三个人要三份总结。工作区成员身份让他能进入这个共享对话；某项决定背后的资料，仍按资料本身的权限开放。
Task 完成后，结果和历史仍然保留。比如，团队发现某位客户需要一种特别的导出格式。报告回到 Router，后续方案就能引用这个发现及其来源。Task 结束了，团队仍有地方可以回头找到这次工作的收获。
并行工作让这条返回路径更重要。一个 Worker 可能在读客户需求，另一个则在调查技术限制。如果发现经过层层转述才到达团队，重要的前提可能会丢失。每个 Task 都把发现连同来源一起报告回来。Router 在同一个主上下文里接收这些信息。
这让我们有理由把智能体框架拆成两种角色。一个持续跟进团队的对话，其他角色执行具体的工作。
Router 和 Worker 怎样配合
我们给一个工作区配置一个常驻 Router。它持有团队的主上下文，随着新请求进入、决定变化和结果返回，持续跟进对话。关于客户方案的请求，与已经展开的交付讨论，进入同一个上下文。每条输入消息都带着来源对话和消息的身份。Router 跨讨论共享上下文，同时保留每条输入来自哪里的线索。
Router 把明确的工作交给 Worker。每个 Task 都开启一个新的 Worker 会话，带上这项工作的指令与交接内容。其他 Worker 的历史留在各自的会话里。多个 Worker 可以同时调查不同问题。
我们为每个 Task 定义目标、完成目标所需的上下文，以及预期交付物。“调查这个客户”留下了太多空白。“检查客户的导出要求，给出格式建议，并附上来源和待确认问题”，就让 Worker 有明确可完成的工作，也让 Router 拿到可用的结果。
假设客户方案既需要检查导出要求，也需要估算交付时间。我们可以把它们交给不同 Worker。一个返回客户需求，另一个返回估算及其前提。Router 把结果带回主对话，让团队作出决定。完成的工作有路可回。
每一条可见回复都是一次显式发送，主对话里的回复也一样。Router 指定目的地，并通过该目的地的检查。模型输出和结束一轮执行，都不会自动发布回复。Worker 汇报结果或向其他参与者发言时，也遵循同一条规则。读取 Task 资料为 Worker 提供工作的上下文，发送则是单独的动作。
信息流控制
并行的 Task 会把读者范围不同的资料带到一起。每次发送都要声明所用的来源。信息流控制，也就是 IFC，会检查目的地的读者是否有权阅读这些来源。
开启强制执行后，发送被拒会返回原因。智能体可以去掉受限内容后重试，或者申请所需范围的人类授权。重试时，正文和来源声明都要随之调整。
IFC 在准备回复与分享出去之间，给团队加了一道可检查的步骤。
回到客户方案，Router 可以把估算呈给团队，问清仍待决定的事，再通过合适的渠道发出商定的答复。Worker 的工作有明确范围，团队的对话则穿过这次交接继续下去。
新的 Task 会打开新的 Worker 会话。切换会话时，我们把未完成的事和相关引用交接过去。团队仍然需要能回头找到以前的决定。
团队怎样一起学习
可以复用的做法会成为组内共享的 skill，里面有可编辑的指令和资源。智能体侧的修改由创建者负责。其他智能体可以使用它，不用重写原件；只读的内置 skill 则可以复制后定制。会话拿到自己范围内的目录，再打开相关指令。
Router 维护持久记忆，分别记录人、环境、一般事实，以及按日期记下的经历。它按需读取或搜索这些记忆。普通 Worker 从 Task 交接内容出发，不写 memory。产品分配的 Triage Worker 只有与来源绑定的只读访问权。记忆写入由 Router 负责。
启用精简工作区（Condensed Workspace）后，组内每个内部 Router 和 Worker 会话都会看到同一份简短的当前事实清单。工作区所有者可以直接编辑它。
智能体更新清单时，会得到一次建议性检查：这些内容是不是其他智能体需要知道的当前事实。系统记录修订号和最后写入者。所有者可以更正或删除条目，让共同依赖的认识能被看见、能被修改。更新被拒后，可以带上这次拒绝的标识重试，显式覆盖检查。
维持一个对话的代价
这种安排给主会话带来压力。Worker 可以并行运行，Router 仍要把结果汇总起来。前一个请求还没处理完，新请求就可能到了。不管背后有多少 Worker，人们感受到的仍是一条队列。
串行排队仍是我们在解决的问题。把耗时调查交出去，能让 Router 腾出更多空间回应，但团队仍需要为互相影响的决定排好顺序。在客户方案里，总得有人先定下交付日期，再对外作出最后承诺。共享对话让这层依赖更容易看清，也让 Router 承担更多推动工作前进的责任。
历史也有自己的成本。每个完成的 Task 都会留下值得以后参考的内容，也会留下很多再用不上的东西。随着历史增长，找到所需的决定和背后的理由，也需要花更多功夫。
我们希望旧决定容易找，不用请同事把整段讨论重新讲一遍。决定背后的理由，能帮助团队识别什么时候该调整决定。
我们的探索就走到这里。我们选择共享主对话，是因为团队会通过不同的人、不同的 Task，一次次回到同一项工作。下一次有人打开相关讨论时，我们希望团队先前的努力仍在那里，接得上。
