正在加载，请稍候
9 月 15 日飞书 8.0 与豆包工作合体、支付宝 xUI、京东「东东」同日亮相。办公 Agent 进群的卡点不在模型，而在会话权限、产物责任与通道配额。
2026 年 9 月 15 日这一天，三个国民级移动端产品同时把智能体放进了用户的日常动线，而它们暴露的瓶颈都不在模型。
北京举办的 2026 飞书未来无限大会暨豆包工作开工大会上，飞书发布 8.0，并与豆包工作完成原生融合；同日发布团队智能体「豆包工作伙伴」，支持像邀请同事一样把它拉进群聊，替团队整理周报、做 PPT、审校文档。同一时间，蚂蚁集团支付宝客户端团队在 AICon 深圳站系统讲解了支撑「阿宝」的端侧交互引擎 xUI；京东则在自家 App 里上线了购物助手「东东」（相关报道）。三件事指向同一个判断：移动端办公智能体已经越过「能不能演示」的阶段，进入「能不能进日常流程」的阶段。
而一旦进入流程，问题就从模型能力切换到工程约束。下面把当天三条产品线放在一起对照，再拆开讲三道绕不开的前提。
| 产品线 | 入口形态 | 产出物 | 执行位置 | 当前阶段 |
|---|---|---|---|---|
| 飞书 8.0 + 豆包工作（伙伴） | IM 群会话、文档、会议、多维表格 | 文档、表格、演示文稿、周报、待办 | 云端 + 飞书开放能力 | 飞书 8.0 已发布；豆包工作伙伴处于定向共创 |
| 支付宝 xUI（阿宝） | 端内对话、全双工音视频 | 可交互 UI 卡片，最终落到服务闭环 | 端云协同，端上生成式渲染 | 已落地支付、生活、政务等高频场景 |
| 京东「东东」 | 京东 App 内嵌对话 | 导购与购物任务结果 | App 内闭环 | 2026-09-15 上线 |
共同点有三条，且都不是技术细节，而是产品结构的选择。
差异同样关键。按 发布会实录，飞书侧对智能体的适配被归纳为三点：让人与智能体自然协作、智能体和人一样使用各类产品、企业像管人一样管理智能体。这说明办公场景的第一价值排序是可控，其次才是效率。而京东「东东」所处的消费导购场景，单次失败只是转化损失；办公 Agent 单次越权读写，可能直接触发合规问题。同样是「进群」，容错率完全不同。
智能体进群之后第一个必须回答的问题不是「它能做什么」，而是「它能读到什么，以及读完之后留下什么」。
飞书给出的答案是把智能体的身份挂到人身上：以员工身份使用的智能体沿用该员工的访问权限，员工无权查看的信息，它也不能获取；管理员则可以管理其使用情况、设置用量上限，并限制高消耗模型与使用场景（原文）。这个设计的好处是审计口径唯一——查人的权限，就能推出它的权限。弊端是权限模型本身的短板会被原样继承。
「豆包工作伙伴」把问题又推进了一层。按飞书介绍，它拥有独立身份、权限和记忆，不与任何人共享，只在授权范围内读写；同一团队的成员可以与一个智能体协作，无需每人重复配置。它能结合群聊、文档和会议内容处理信息同步、文档审校、周报整理与代码分析，并根据工作进展主动执行任务（现场介绍）。
「团队共用」意味着一个新的数据资产出现了：团队级记忆。它带来四个必须在立项阶段就定义清楚的问题：
当智能体产出的文档进入流转，它就不再是「对话记录」，而是公司文件。此时「谁署名、谁复核」不是流程问题，是法律与审计问题。
飞书 8.0 的一个细节值得注意：AI 产出的 Markdown / HTML 可以直接在飞书内编辑，不需要下载后切换到其他软件。流转损耗被压到很低，但责任归属不会自动生成。可执行的做法有两条：
支付宝 xUI 在渲染层的思路可以直接借来：在 A2UI 框架下，他们不让模型生成页面本身，而是让模型生成「要做什么事情」，再把这件事翻译成可交互的 UI 卡片，由用户查看、确认、选择后完成服务（演讲整理）。把「确认点前移」这套设计搬到内部产物上，就是让它先交意图、再交结果。
前两道前提解决「能不能」，第三道解决「撑不撑得住」。
能力面扩大，必然带来调用量上升。据飞书在会上公布的数据，通过 CLI 开放的功能点已从 2026 年 3 月的 247 个增至 767 个（会上公布）。功能越多，一次任务能触发的调用越密，配额与限流就必须前置设计，而不是等线上报错再补。三个具体的工程面：
通道选型还会决定体验上限。xUI 的通信层最终以 MoQ 协议为基础、配合 RTC 等方式，原因之一就是传统 RTC 面向人与人交互设计，需要先建房间、建连时间长，多模态扩展不灵活。如果你的智能体要做语音介入和随时打断，这一步在立项时就要定，后期很难改。
把上面三道前提落成一份可以拿去开会的清单（可配合 2026 年的选型决策框架一起看）：
工期区间（基于公开能力的工程估算，不是承诺 SLA）：
区间浮动主要来自两点：一是平台能力是否已全面开放——「豆包工作伙伴」目前仍处于与企业定向共创阶段，尚未全面向客户开放（官方说明），把未开放能力写进里程碑会直接导致延期；二是企业自身的权限模型是否已经结构化。
另外一个绕不开的选型题：平台能力这么强，自研还有没有必要？字节跳动 CEO 梁汝波在会上给了官方答案——需要构建专属智能体的企业，可以使用火山引擎提供的模型、算力和开发工具，构建出的成果同样可以接入飞书，与人及其他智能体协作。换句话说，平台做通用能力，企业做自己的业务上下文与规则，这个分工在 2026 年已经比较清楚。对垂直场景的团队来说，「不造新模型」往往比自造更划算（「不造新模型」的启示）。
Q：移动端办公智能体与 PC 端有什么本质区别？
A：三点。入口在 IM 会话或端内对话，产物要落到文档或卡片，执行贴着端。移动端还额外要求全双工与可打断——xUI 之所以以 MoQ 为基础做通信，正是为了让智能体支持打断与多模态扩展。
Q：豆包工作伙伴现在能直接用吗？
A：不能。官方口径是仍处于与企业定向共创阶段，尚未全面向客户开放，做规划时要把这个不确定性算进时间表。
Q：权限对齐最省事的做法是什么？
A：让它直接继承员工的访问权限，而不是自建一套权限映射表。员工看不到的信息，它也拿不到，这样审计口径就只有一个。
Q：怎么衡量一期是否成功？
A：主指标建议选「产物被人工签发或采纳的比例」和「免确认动作的准确率」，而不是调用量或活跃对话数。前者反映真实价值，后者只反映热闹程度。
Q：为什么不直接从多场景全量铺开？
A：多场景会同时放大权限、责任与配额三个维度的风险。今年行业里反复出现的讨论是「模型再强，Demo 还是进不了生产」（相关分析），原因基本都在工程侧，而不在模型侧。
如果你正在评估把办公智能体接进企业 IM，建议先做权限盘点，再选单场景试点，最后才谈多场景铺开。蓝曜炬辉（www.lanyaoai.com）在企业 AI 应用开发与 IM 集成方向上的实践，可参考站内案例库；需要讨论具体方案的，可以通过联系页面约一次技术评估。