一件事，交到下一个人手里以后

团队已经有很多 AI

产品可以让 AI 整理访谈，工程师拿它写代码，设计师用它找参考，项目经理也能很快得到一份会议纪要。每个人手里的那一步都快了。

事情一旦交出去，老问题还在。客户为什么坚持某个要求，到了技术手里可能只剩一行需求。工程师改了实现边界，设计师还在按上一版继续。等项目经理追进度时，又得从几段聊天和几份文档里把来龙去脉重新拼起来。

团队往往需要知道这件事从哪里来，谁改过判断，眼下该由谁接着做。再多一份总结也未必能回答这些问题。

我们在设计 Nexus 时，先把 Agent 当成一个有长期身份的工作成员。它有名字、联系人和自己的工作区，也能进入 Room，与真人和其他 Agent 一起工作。

这个选择看着有点慢。做一个按钮，点下去调用某个模型，演示起来容易得多。可按钮接不到别人交来的工作，也不知道结果该送给谁。项目里的 Agent 需要被找到、被提及，也需要在做完以后把结论带回原来的地方。

Nexus 里的 DM 适合一个人与单个 Agent 持续沟通。Room 留给多个人和多个 Agent。大家在这里确认共同目标，分开处理各自负责的部分，再把会影响其他人的结果放回公区。

所有消息都公开，会把 Room 变成一条很快没人愿意看的长河。什么都留在私聊里，其他成员又会拿着旧事实继续工作。

我们更在意消息有没有合适的落点。已经确认的目标、决策、进展和阻塞放在公区。只需要某个成员处理的问题可以定向发送。私下讨论出了会改变项目的结论，负责的人再把它带回 Room。

提及一个成员，只代表这条消息该由谁醒来接住。需要长期保存负责人、依赖和验收关系时，Nexus 还有工作图。这样，聊天负责交流，工作图负责把责任留下来。两件事不用挤在一句 @Amy 里。

设想一个常见的开发项目。产品负责人把客户的原始需求带进 Room，产品 Agent 整理已经确认的事实和待问的问题。工程师看到原始背景以后判断成本，技术 Agent 补可行性分析。设计调整方案时，也能看到技术边界刚刚发生了什么变化。

这里没有哪个 Agent 替谁作最终决定。人仍然负责取舍。Agent 接住资料多、查找重、需要反复核对的工作，结果连同依据一起回到 Room。成员忙碌或暂时离线，任务也应当留在明确的位置，等对方回来继续。

我们希望减少的就是那次重新解释。项目走到下一位成员手里，他不必先猜前面的人为什么这样做。

多人和多 Agent 共处以后，问题会变得具体。公共事实与个人记忆怎样分开，Agent 能联系谁，谁可以暂停它，模型换掉以后它还是不是原来的成员，这些都需要产品给出清楚的边界。

Nexus 目前先把身份、Room、消息、工作区和运行记录放在一起，并把代码开源，让这些边界可以被检查。协作这道题，我们还没有做完。

先让一件事在交出去以后还能接得上。下一步才有意义。