ARTICLE · 1268485
个人 AI 助手之后,下一个风口轮到 Team Agent
2026 年 5 月 28 日，Shopify 摊开了一组数据。它自家的 AI 助手 River，30 天里参与了 59,918 次工作会话，覆盖 5,170 个 Slack 频道，服务 7,000 多名员工，参与合并 3,536 个代码提交。
按 30 天摊平，一天差不多 2,000 次会话。摊到 7,000 多人头上，每人每天不到 0.3 次。
这个数字不大。多数人一天也用不上一次，真有事了才在群里喊它一声。工具装上了，用法还是老的。
它只能在群里干活
River 有条挺特别的规定：只在公开频道工作，不收私信。
员工在群里 @ 它，它可以查故障、翻代码、跑测试、提修改。旁人随时能插进来纠正它，或者补一句自己的经验。整个过程留在群里，整理过的办法进共享技能库。
这条规矩看着像管理洁癖，落到产品上是有意为之。一个工程师教会它的东西，成了下一个工程师的起点。
它只能在群里干活
一个人的助手，一个团队的助手
个人 AI 助手攒下的本事，都攒在个人身上。会用的人，等于多带了一个能干的实习生。换个人不会用，那点效率带不走。
Team Agent 攒的是组织的。它长在团队的工作环境里，目标、任务、卡点在哪儿都看得见。没人主动叫它，工作本身也会触发它。
Shopify 为此搭了个叫 Aquifer 的平台，把会话、执行环境、事件记录分开存。程序重启，上下文还在。一次协作结束，记录不跟着聊天窗口一起消失。
这就是两代产品的分界线。个人助手靠使用习惯活着，团队助手有机会变成工作习惯本身。
它记得住，可不知道今天卡在哪
这套做法里最容易被跳过的一层，是把团队记忆和团队工作状态拆成两件事。
记忆回答过去发生了什么。状态回答现在什么还没做完：哪个功能做完了、哪个问题卡着、哪件事等着另一个部门、谁要在什么时候拍板。
一个智能体能把三个月前那次会的结论复述得一字不差，却不知道今天哪个项目延期了，那它还是个知识助手。
要让它干活，得有人持续维护一份工作记录：目标、负责人、进度、依赖、验收标准。做完的留结果，做不完的记下卡在哪，要人决定的进待批队列。
还有一条更细。群里有人说“这个方案可以考虑”，不能自动当成批了。讨论、建议、正式决定、执行授权，四者得分得清。分不清，它记得越多，错得越深。
国外这几家走到了哪一步
Grok Bot 的 Team Bots 让管理者配好工具、技能和文件，再发给整个团队用。成员各自跟它聊，也能读团队记忆。2026 年 9 月 28 日的官方案例里，它已经在真实客户团队上班：每天翻通话记录、Notion 文档和 Slack 讨论，第二天早上主动发一条客户有什么变化、下一步做什么。
Dust 的 Pods 更进一步，人和智能体共用同一个项目空间，任务谁都能建、能接、能推。
Notion 的 Custom Agents 能按文档、数据库、Slack 事件触发任务，还能转交给别的 Agent。Slack 的 Code Channels 让人和 Agent 进同一个临时空间改代码。
都只解决了一部分。Grok 那边的定时任务还挂在创建它的个人名下，团队级的统一运行、统一管理，还没做出来。
国外这几家走到了哪一步
国内的路子不一样
飞书的“豆包工作伙伴”已经有记忆、主动干活、团队协作这套能力。飞书自己攒的消息、文档、日历、多维表格和企业权限，是现成的工作环境。
钉钉悟空走执行路线，从钉钉消息接任务，再用技能和工具去操作电脑和业务系统。
企业微信开放了智能机器人接入，长连接这类机制也有了。
国内企业的真实情况比任何一套架构都乱：信息在微信群，业务靠 Excel，审批在另一套系统，关键决定靠电话。谁能在不逼企业换掉全部软件的前提下，把这些散着的东西变成一份可信的工作状态，谁就拿到了下一代协作的入口。
麻烦在后头
真正难的，不是模型不够强。
一个团队同时推几十条线，后台要是全开着，会养出一群 24 小时互相汇报的数字公务员，算力和 token 一路烧，产出没多少。任务得能长期存在，执行它的智能体不必一直醒着。
另一头是授权。遇重大风险能暂停，发现任务冲突能请求仲裁，错操作查得到、撤得回。权限给到哪一步，得写在明面上。
小编的判断是，这一层比模型本身难得多。通用大模型解决不了组织问题，不同公司的文化不一样，同一家公司不同团队的打法也不一样，一套架构顶不住所有场面。
先拿一件事试
挑团队 Agent，先问三件事。人走了，它手里那份背景还在不在。没人叫它的时候，它知不知道哪件事该往前推。两个人或者两个智能体同时动手，它会不会重复干、拿着旧版本去提交。
三个都答得上来，才算团队助手。答不上来，那还是个拉进群里的聊天机器人。
先挑一件真卡住的事，比如一个已经拖了三天的任务，让它盯住，看第二天它说不说得清卡在谁那儿。
先拿一件事试
