豆包和飞书把团队 Agent 拉进了工作群

飞书和豆包工作今天发布了全新的「豆包工作伙伴」。它像人一样拥有独立的组织身份，可以被加入群聊，接收不同成员的任务，在授权范围内使用文档、会议和工具来提高整个团队的工作效率。

这个思路在海外已经有先例。几天前 Claude Code 工程师团队做了一期视频播客分享，成员估计自己 70% 到 80% 的工作都通过 Claude Tag 开展。Claude Tag 是可以加进 Slack 的共享 Agent，既能参与讨论，又能写代码、分析数据。两者都在解决同一个问题，过去的办公 Agent 都在回答「我自己怎么更快地工作」，团队 Agent 在回答「我们怎么一起把事情做完」。

豆包工作伙伴目前还在早期企业共创阶段，没有向所有用户全面开放。

区别在哪

过去两年，大家都在给 AI 补办公能力，读文档、做表格、开浏览器、操作电脑。可一个 Agent 真正进入团队之后，它还得知道项目之前聊过什么、谁负责什么、哪些资料可以看、哪些事情可以做，以及做完之后把结果交给谁。

这些恰好是飞书做了几年的事。豆包工作带来的执行能力，加上飞书已有的组织上下文，Agent 就同时知道了怎么干活和在这个团队里该怎么干活。

最直观的变化是不用每次重新交代背景。进群之后可以直接在群里提问，也可以让它跟踪任务、处理飞书文档、做数据分析，还有定时监控、提醒、记录待办、追踪负责人这些。任何时候 @ 一下它都在线。即使没专门 @，只要告诉它「以后碰到类似的求助主动帮忙」，它也会把这个协作方式记下来。

更关键的是上下文不只来自一个群。在主群里可以直接让它查看另一个工具分享群之前讨论过什么，再把结论带回来。群里的文档也可以授权给它处理，飞书原本的权限规则依然有效。它自己明确表示权限按群聊、资源和应用授权生效，能读取并回复已经加入的群聊，给可触达的人或群发消息，也能搜索公开网页。

这引出一个区别，个人 Agent 借的是用户的权限，团队 Agent 需要有自己的权限。一个项目可能同时散落在产品群、研发群、运营群和营销群，产品在一个群改需求，研发在另一个群讨论实现方案，运营在第三个群补用户反馈。过去这些信息最终靠人来转述同步，再重新解释一遍背景。团队 Agent 作为独立的组织成员被加进不同项目群，在各自授权范围内持续参与，原本分散的讨论就有机会被同一个 Agent 连接起来。

实际用起来

除了问答，它也能真的动手干活。测试者把它当成新同事，一开始给的工作就是找新闻热点，要求它每天早上分享自己找到的 AI 新闻，然后自己评估是否值得跟进、时效性如何，再收集反馈不断优化找选题的能力。

这个场景能说明团队 Agent 的定位。它不只等着被使唤，而是被授予了一个固定的职责，持续在群里履行，接收反馈再调整。

权限是这类产品最需要想清楚的地方。团队 Agent 要拿到独立身份，就意味着它得有一份不依赖某个具体员工的访问权限。这份权限给多大、谁能改、离职员工的临时授权怎么回收，都是落地时必须回答的问题。飞书把已有的权限体系直接复用是个稳妥的做法，但 Agent 的权限边界和个人权限边界不完全一样，这块后面大概率还会调整。

另一个问题是当它出错的时候谁负责。Agent 在群里发了消息、改了文档、给外部人员转了东西，责任落在谁头上，目前没有成熟的做法。企业真正大批量用起来之前，这类规则得先立起来。

你们团队现在有用类似的协作机器人吗，敢把文档权限开给它吗？

作者提示含AI生成内容。