豆包工作会做 PPT，不代表企业敢让它干活

会写文档、做表格、生成 PPT、操作浏览器，现在已经很难让我对一个办公 Agent 多看两眼了。

不是这些能力没用，而是大家都会了。

8 月 25 日，字节跳动把「豆包工作」推到了台前。产品官网展示的能力很齐，能处理本地文件、操作网页、跑定时任务、做研究、生成图片和视频，人在外面还可以从手机远程派活。好家伙，办公软件里能摆上货架的功能，它几乎都摆上去了。

真正让我在意的不是这张能力表，而是另一件事。

它能带着飞书账号进入组织现场。

按飞书官方的协作说明，团队可以从文档、搜索、群聊和会议这些入口发起任务，Agent 读取相关企业材料，完成连续操作，再把文档、表格和其他成果交还给团队评审。广州日报的公开报道还提到，用户授权后，豆包工作可以继承飞书里的企业权限和上下文。极客公园对这次发布的梳理也把飞书补上的企业协同、权限和组织上下文列为关键差异。

这个变化比「又多会了一种文件格式」大得多。

过去，我们把材料复制给 AI。现在，AI 开始站在材料本来就存在的地方，知道谁说过什么、哪份文档是最新版、会议里定了什么、谁有权看、谁有权改。

办公 Agent 真正进入公司了。

也正因为进来了，问题才刚开始。

入口从单个应用移向 Agent，企业知识与连接器也被放进同一个工作台。

做 PPT 只是入场券

宝玉的公开体验里有个判断很准，模型可以换，工具可以接，Harness 这一层的功能差距正在被迅速抹平。Harness 用人话讲，就是让模型能调用工具、保存状态、处理失败并把任务真的做完的那层脚手架。

一个新办公 Agent 今天多出网页操作，竞争对手下个月就能补。今天支持 PPT，明天大家都支持。今天能跑长任务，过一阵云电脑和定时调度也会变成标配。

这类能力当然重要，但它们更像水电煤。

企业真正难复制的，是每天自然产生的组织上下文。会议里没有写进 PRD 的取舍，群聊里临时改掉的口径，文档的版本关系，客户名字背后的项目历史，还有谁能访问哪一层数据。

于是办公 Agent 的竞争会出现一个挺有意思的转向。模型负责推理，工具负责执行，协作平台负责提供真实工作现场。谁离现场近，谁就少让员工做一遍「把背景重新喂给 AI」的搬运工。

周报就是最直观的例子。

一个看不到工作数据的 Agent，只能等你先把本周做过的事重新讲一遍。你写半份周报，它帮你润色另外半份，棒棒的，自动化完成了，最累的回忆和核对还是你自己干。

如果它能在授权范围内读取会议纪要、项目文档、任务看板和相关讨论，周报才有机会从「帮我改写」变成「帮我收集证据并起草」。

注意，是起草。

项目是否真的完成、数字能不能对外说、延期原因该怎么表达，仍然需要负责人判断。上下文能降低收集成本，不能替你承担组织责任。

这条边界很重要。企业不是为了得到一份更顺滑的文案才接入 Agent，而是为了缩短「事实散落在十个地方」到「形成可验收成果」之间的距离。

功能清单只能证明它会干活，证据链才能证明它干的是对的活。

文档、表格和 PPT 已经是办公 Agent 的入场券，难点在成果如何进入组织验收。

上下文越完整，事故半径越大

上下文经常被当成办公 Agent 的护城河。这个词听起来很舒服，像仓库里堆得越多，价值就越大。

可从工程角度看，组织上下文先是一大片权限面。

群聊里有尚未公布的产品计划，会议记录里有客户承诺，文档里有财务数字，日历能暴露谁在谈什么项目。把它们接给 Agent，不是简单地多挂几个数据源，而是把原来分散在不同应用里的访问能力交给同一个执行主体。

有点子牛逼，也有点子危险。

最常见的误区，是把「继承权限」理解成「拿到一个能访问飞书的 token」。token 只是门卡，真正要回答的是它代表谁、这次任务能开哪些门、能停留多久、能不能把屋里的东西带出去。

假设一个销售同事让 Agent 整理下周客户会议材料。它读取本人有权限查看的文档，没问题。接着它从群聊里找到一份旧报价，把数字写进新方案，又把方案共享给了外部联系人。

这里至少有三种权限混在一起。

读取旧报价是一种权限，判断哪份报价有效是一种业务判断，对外共享则是一次有副作用的动作。前两步成功，不会自动让第三步变得安全。

所以我一直觉得，办公 Agent 不能只继承用户权限，还要在每个任务里把权限继续缩小。安全圈里常说最小权限，放到 Agent 上可以更直白一点，员工能做的事，不等于 Agent 这一次都该做。

一个「帮我整理会议材料」的任务，可以读指定项目空间，可以创建草稿，但不该默认获得发消息、改原文、扩大共享范围和提交外部表单的能力。任务结束后，这些临时能力应该失效。员工转岗或离职，相关授权也要能立即撤销。

这才叫权限继承。

不是复制门卡，是继承组织已有的身份规则，再按任务把门卡剪小。

能操作本地文件和远程派活以后，任务级授权、撤销和审计就不再是可选项。

真正的瓶颈会移到验收

很多公司算 AI 提效，喜欢算某一步快了多少。

写方案从三小时变成二十分钟，做表格从半天变成十分钟，整理会议纪要几乎实时。单看都很漂亮。

然后项目交付周期没怎么动。

原因并不神秘。执行快了，排队的地方换了。以前大家等人写初稿，现在等人确认数据、核对来源、处理权限、决定是否发送。Agent 一口气产出五份材料，审核人桌上就多了五份材料。

这一下给我整不会了。自动化没有消灭工作，只是把工作从生产端推到了验证端。

个人提效和组织提效之间，差的就是这条验收链。

飞书官方说明里有一句挺实在，任务完成不等于成果自动可用。负责人仍要检查事实、格式、字段、操作结果和后续维护方式。对外内容和关键业务动作，仍由相应负责人决定是否使用。

这不是保守，而是组织运行的基本纪律。

办公 Agent 真想提高整条链路的速度，就不能只追求「更快生成」，还要让验收成本下降。每份成果都该带着来源、版本、操作记录和未解决问题一起回来。审核人不该重新翻十个群聊判断一句话从哪儿来的，也不该靠猜测确认 Agent 有没有覆盖原文。

理想的交付物不是一个孤零零的 final_v7_真的最终版.pptx。

它应该同时告诉你，任务由谁发起，读取过哪些材料，哪些材料被排除，调用了什么工具，改了哪些对象，哪里缺证据，哪些动作等待批准，失败后能不能重试，重试会不会重复发送。

看到这里，程序员大概已经闻到熟悉的味道了。

这不就是一次需要 trace 的生产任务吗。

trace 可以理解成任务轨迹。它不只记一条「成功」，而是把每一步输入、工具调用、输出和错误串起来。没有这条轨迹，Agent 做对了是玄学，做错了是悬案。

上线前先写一份权限合同

我不知道所有团队是不是都需要一套很重的平台，但最小合同真的可以先写起来。不要先买产品，再开会讨论该怎么管。顺序反过来，先挑一个高频、低风险、可回滚的任务，把边界写清楚，再让 Agent 进去。

可以从这样一份配置开始。

task: weekly-project-digest
principal: current_user
read_scope:
  - project_docs
  - approved_meetings
write_scope:
  - draft_folder
deny_actions:
  - send_external_message
  - expand_share_scope
  - overwrite_source
approval_required:
  - publish
  - submit_form
  - move_or_delete
evidence:
  source_links: required
  document_version: required
audit:
  tool_calls: retained
  changed_objects: retained
revocation:
  on_task_end: true
  kill_switch: enabled

这不是某个平台的真实配置格式，只是一份能拿去开评审会的最小合同。每一行都在逼团队回答一个原本容易含糊的问题。

principal 决定 Agent 代表谁。read_scope 和 write_scope 把可读与可写分开。deny_actions 明确哪些事再聪明也不能自己做。approval_required 把人留在真正有业务后果的节点。evidence 要求成果能回到来源。audit 让事故有路可查。revocation 保证任务结束或风险出现时能立刻收权。

坦率讲，这些东西没有「一句话生成完整 PPT」好卖。

但企业敢不敢让 Agent 真干活，看的恰恰是这些不性感的部分。

再往前一步，团队还要给任务设计可验证的完成条件。周报不是生成一篇文字就算完，而是每个关键进展能链接到任务或文档，数字有明确口径，未确认事项被标出来，草稿只写进指定目录，对外发送必须由负责人批准。

如果执行失败，也要把失败语义说明白。网络超时不等于任务没执行，重试前要确认是否已经创建文档。共享动作返回失败，不等于对方没收到。浏览器卡住时，Agent 应该停在可恢复的状态，而不是从头再跑一遍，把同一条消息发三次。

厉害了，这些听起来全是后端系统几十年前就学过的老知识。幂等、审计、最小权限、回滚、人工审批。

AI 没有让它们过时，只是把它们重新塞进了一个会说话、会点按钮、还能自己规划步骤的新执行器里。

办公入口换了，责任不能丢

豆包工作这次最值得看的地方，不是它能不能生成一份漂亮表格。类似能力很快会铺满所有办公 Agent。

真正的分水岭，是 Agent 能不能在组织已有的上下文和权限里工作，又不把完整上下文变成完整风险。

它得知道哪些材料能读，哪些结论没证据，哪些动作必须等人，哪些结果应该回到团队继续评审。人也得从「亲手做每一步」转向「定义目标、守住边界、验收结果」。

这不是把人从流程里拿掉。

是把人放回最需要判断的位置。

办公软件的入口也许真的会从一个个 App，慢慢变成 Agent。可入口换了以后，组织仍然需要知道谁让它做了什么、它依据什么做、结果由谁负责。

模型是租来的，工具会追平，责任链才是自己的。