夜雨聆风8 月 25 日，豆包工作上线。加上8月初整合亮相的千问办公，以及早就跑出千万月活的 WorkBuddy，阿里、腾讯、字节三家在 AI 办公上的主力牌，基本亮齐了。
围观了一圈各个平台的讨论，判断相当一致：Computer Use、云端任务、Skill、MCP、多 Agent 协作......这些能力都在迅速变成标配。既然模型和执行能力迟早会拉近，接下来比拼的，就是谁能拿到更多、更深的企业上下文。沿着这个逻辑，飞书、钉钉、企业微信背后的组织数据，自然成了下一轮竞争的胜负手。
但我认为，这个判断有道理，但只说了一半。
企业不是一套资料齐全、权限统一、事实自动更新的数据库。真实的工作现场，到处都是没有写进系统的决策、只有部分人能看见的消息，以及无人标注「这版已经作废」的旧材料。
所以，评价一款 AI 办公产品，不能只问它能够接入多少数据。还要继续追问：它拿到的上下文有没有用？看不到的部分，它知不知道？现有信息，够不够支撑它接下来的动作？如果它知道信息不全，是否会提示？
01 上下文多，不等于上下文有用
先看一个真实场景：某个关键事项在多个群里讨论了半个月，文档改了八版，三轮评审会议的记录全在飞书里。系统中的最后一条公开消息是：目前倾向方案 A，先按这个方向继续完善。
但最终决策发生在飞书之外。老板在微信里私信负责人：还是按 B 方案走。
如果仅基于飞书之内的信息，某个 Agent 读完群聊、会议纪要和每一版文档，进而根据方案 A 生成了一份完整的推进计划。逻辑清楚，排期合理，每句话都有出处。
它没有编造任何资料，却给出了错误的答案。
更麻烦的是，这份计划被写回系统之后。如果它被当作正式产物存进知识库，又没有标明依据、假设和验证状态，下一位搜索「这件事最后怎么定的」的员工，看到的会直接是一份有日期、有负责人、有任务分工的正式文档。
其他 Agent 再来检索时，也可能把这份计划当成权重更高的证据。经过几轮转述，最初那个未经确认的假设，越来越像组织已经确认的事实。污染就这样开始产生复利效应。
问题不在过程记录多。讨论过程当然有价值，用来复盘分歧、理解背景，它们不可或缺。问题的关键是，系统分不清什么是讨论、什么是草稿、什么已经作废、什么才是最后的定论。
对「整理讨论进展」这样的任务来说，过程记录已经够用；但如果任务是制定排期、分配负责人，未确认的过程记录越丰富，反而越容易制造一种虚假的确定性。
现实里也不可能靠员工自觉，把每次口头决定和每条微信私信都及时同步回办公系统。重要决定发生在系统之外，属于组织运行的常态，偶发漏洞解释不了。
所以，AI 办公真正难建立的优势，跟 能读取多少数据关系不大，得看能不能让关键结果回到系统里：审批状态以这里为准，任务归属以这里为准，终稿版本以这里为准，每次变更也都留下记录。
平台不必承包所有交流，但必须给最终结果一个被确认、被回写、可追责的落点。拿到上下文只是门票。成为权威事实源，才有资格坐上牌桌。
02 权限残片：别把「没看到」当成「不存在」
即使所有决定都回到了系统，还有一个绕不过去的问题：权限。
如果一个 Agent 可以无差别地俯瞰全公司数据，那算不上能力，只会酿成安全事故。没人会允许一个替普通员工写周报的 AI，顺手读完薪酬表、裁员名单和高管私聊。
现实中可以接受的底线是 Agent 不能越过使用者的权限，还要根据具体任务尽量缩小取数范围。你能看什么，它才能看什么；这件事用不到的数据，它也不该读。
安全上必须这么做，但代价是：平台拥有全量数据，不等于任何一个员工手里的 Agent 拥有完整上下文。它接触到的，天然只是一块被授权的切片。
跨部门的讨论、高管层的会议、另一个项目正在进行的调整，都可能影响当前事项，却不会出现在它的检索结果里。这种残缺属于权限机制正常运行后的结果，跟系统异常没关系。
最危险的情况，是Agent把「我在当前权限和检索范围内没有找到」，直接说成「公司里没有」。Agent 不可能知道系统之外究竟发生了什么，但它至少可以判断：眼前的证据，是否足以支撑当前动作。
第一步，是看懂任务需要什么证据。整理一份「目前的讨论进展」，没有最终结论也可以做；但要输出正式排期、分配负责人，最终方案就是前置条件。
第二步，是把缺口说具体。不能只在文末塞一句「内容仅供参考」，得明确告诉用户：
目前检索到的公开讨论截至 8 月 20 日，团队倾向方案 A，但未找到最终审批或决策记录。如需形成正式排期，请先由项目负责人确认最终方案。
第三步，是区分动作的风险。如果用户只要一份内部草稿，Agent 可以基于方案 A 继续写，但必须把假设标清楚。如果下一步是群发邮件、提交审批、对外发布或修改正式数据，缺少关键信息时，它就应该停下来询问操作人。
现在很多 Agent 擅长把检索到的材料拼成一个完成度很高的答案。问题是，答案越完整，越容易让人忽略它的证据其实并不完整。真正的分水岭，跟它能不能把任务做得像模像样关系不大，得看它什么时候愿意承认：材料还不够，我不能替你做这个决定。
这也不是单一模型就能解决的问题。它背后涉及检索、权限、来源状态、风险分级和交互设计，是一整套系统能力，很难靠一张通用 Benchmark 直接证明。
03 别拿做演示的心态做日常工具
现在的 AI 办公演示，有一套大家已经很熟悉的剧本。用户说一句话，AI 自动打开浏览器、查报表、读取文件，再调起五六个 Agent 协作。半小时后，一份几十页的精美 PPT 送到面前。
这种演示没有错。它证明的是产品的能力上限，也确实适合发布会。但别把低频重任务的演示逻辑，做成所有人的日常入口。
真实的办公日常要琐碎得多。多数人打开办公软件，只是想查一个内部代号，找回上周发过的表格，确认会议最后定了什么，或者回一句「收到」。
对这些高频小事来说，多 Agent 编排、虚拟桌面、连接器商城，都应该藏在后面。用户不需要先理解整套技术架构，才能问一句：
上周五那场会，最后到底怎么定的？
AI 办公更合理的形态，是前台尽量轻，后台足够重。平时，一个入口就够了。到了关键节点，再把来源、权限、假设和待确认事项展开给用户。它也不必每次都展示自己调了多少工具、跑了多少步骤。回答完问题，再自然地补一句就够了：
系统里没有找到最终结论。要不要找李四确认一下？
这种看起来不够「炸裂」的提醒，可能比自动生成一套 PPT 更有价值。入口越轻，人们才越愿意把日常小事交给它。但使用量不会自动变成高质量上下文。只有把确认过的结果结构化回写，并且与过程稿、AI 草稿明确分层，日常使用才能逐渐沉淀出可信的组织记忆。否则，规模只会放大污染的复利效应。
上下文当然重要，但它不是免死金牌。一款能用的办公 Agent，不需要每次都证明自己无所不能。它更应该像一个靠谱的同事：知道自己看到了什么，也知道哪些东西自己没看到；起草时可以带着假设继续，真正执行之前，必须把关键问题问清楚。