技术层面，“代码”从垂直能力逐渐成为通用能力，模型的编程水平足够高，就能把自然语言编译成可执行的步骤，继而在实际场景中展现惊人的 Agent 能力。

于是乎，腾讯 Workbuddy 大杀四方，阿里千问办公火速上马，字节一如既往大刀阔斧，飞书团队并入豆包，产品体系全面整合，推出全新产品豆包工作。

和同类产品不同，豆包工作和飞书深度打通，可以直接用飞书账号登录，飞书里原来的豆包企业版也变成了豆包工作。

字节给豆包工作一共设置了三个入口：1. 独立的豆包工作应用；2. 豆包应用的工作模式；3. 飞书内的豆包工作入口。

一个已经冲出去了，一个刚翻身上马，还有一个还在磨刀。但磨刀的有时候最可怕——谁知道刀磨好了要砍谁。

脱离群众深入生产力场景，已经成为大公司的共识，AI 能不能赚到钱，取决于老板愿不愿意开发票。但新的问题随之而来：

当下 Agent 办公的护城河，似乎是电梯广告的投放力度，分众传媒的销售成为最大赢家。

目前来看，各家大厂的 Agent 产品不能说完全一样，但区别相当于郭达和杰森·斯坦森、吴京和荒木飞吕彦，高度同质化。

Agent 办公由两层能力构成，一是 模型，决定了理解与推理的上限，二是 ，是 Agent 背后的基础设施。可以简单理解为模型定战略，Harness 主抓具体工作、负责运行管控。

理论上来说，一个 Agent 产品好不好用，取决于 Harness 够不够扎实。但 Harness 归根结底是个工程问题，可以预见，各家的 Harness 早晚会走向同质化。

考虑到 OpenAI 已经开源了 Codex 的 Harness，这个过程不会太长。

模型不是护城河，功能不是护城河。打了半天 AI 办公大战，最后把灵魂交给了分众传媒，问题出在了哪里？

上下文

第一批付费上班的潮流人士，已经意识到了一个问题： Agent 好不好用跟 Agent 产品没太大关系，关键在“上下文”。

何为上下文？即工作中具体的“语境”。

比如“帮我改一下”这句话，在研发群里是改代码，在设计群里是修图，人类员工在公司的经历，就是完整的上下文。如果不给 Agent 注入足够的上下文，Agent 就只能做字面匹配，无法理解真实意图。

之前广泛流传的《文峰纪要》中，梁文峰举过一个例子：老板叫小王过来，前提是老板知道小王是谁、什么职务、人在哪里、怎么去找他、找他的时候注意什么。

这个语境里，老板已经了解了公司完整上下文，Agent 第一天来公司打工，部门的人都没认全，必须依赖人类输入足够多的上下文，变成公司里的老油条，才能准确的执行任务。

因此梁文峰在“AI 超越人类”这件事上，设定了一个重要前提：给 AI 完整的上下文和完整的指令。

对应到 Agent 办公，道理是一样的。如果没有公司的管理制度文档，你问 AI 自己有几天年假，AI 把劳动法研究三天三夜，也没办法给你准确的答案。

大公司的上下文极端复杂，来自文件、数据、历史记录、企业内部的知识和规则，包含的是整个组织的历史和结构。

举例来说，个体服装店老板问 Agent“一件衣服卖了多少”，Agent 能很快回答。但对一家拥有上千家门店的零售公司来说，Agent 会先反问几个问题：同店口径还是门店口径？线上还是线下？退货计不计入？按订单口径还是收货口径？

AI 潮人和一人公司的上下文都存在电脑硬盘里，时时刻刻都能调度，公司的上下文都躺在 ERP、POS、电商后台、会员系统、物流系统里，而且各有各的统计口径和统计时点。

数据是 AI 的核心，企业上下文如果不被很好的调度，会大幅限制 Agent 的发挥。

高盛在报告《Decoding the Agentic Economy》里就提到：在 Agentic 模式下，模型由于需要不断进行“思考 - 检索 - 调用工具 - 重新读取完整上下文”的循环，Token 消耗量暴涨。

换句话说，强大的模型 +Harness 是一个好的执行者，确实指哪打哪。但在企业经营中，必须结合完整的企业上下文，才能成为一个好用的工作 Agent。

甚至夸张点说，Agent 好不好用，跟 Agent 本身关系不大，而取决于上下文的完整。所以个人用户把 Agent 用的飞起，企业级的 Agent 似乎还没有雏形。

投放完电梯广告的大公司，其实已经发现了这个问题： 越是有支付能力的大客户，上下文就越复杂。

碎片化

一个企业的上下文能不能充分调度，首先考验的是企业的数字化水平。

1997 年，华为引进 IBM 的 IPD（集成产品开发）系统，系统横跨研发、市场、采购、制造、财务等多个部门，实施起来十分复杂，IBM 的报价超过 20 亿人民币，华为一口答应。

华为对信息化向来很重视。1993 年华为只有 300 多人，就在内部成立了十几个的专职 MIS（管理信息系统）开发团队。1995 年，华为又耗资花上千万引进了 Oracle 的 ERP 系统。

能在 1997 年就意识到数字化建设的公司，在当时不算多；像华为一样对数字化建设不惜成本的公司，在现在也不算多。由此导致一个问题：

大部分企业的上下文没有系统性的沉淀，唯独员工的打卡数据汗牛充栋，只能蒸馏出一个查考勤 Agent。只有少数企业，有成体系的知识库和标准化的文档系统。

一方面，很多企业的数字化程度，还停留在 Office 离线处理、机房 + 大铁索本地储存、聊天软件异步传递的阶段；

另一方面，一旦业务线上化，就用上一堆办公软件。十几个人的公司，搞不好要给几十家 SaaS 公司写推荐语。

如此一来，企业的上下文分散在各种各样的角落，不成体系。即便文档文化再浓厚的企业，员工也很难把自己所有的思考和理解“文档化”。

同时，一个企业大量的上下文，是高度碎片化的，包括但不限于群聊里即兴的讨论，临时组织的运营复盘会，聊天记录里领导的 PUA 话术等等。老板批评你“对公司文化的实践还不够扎实”，对公司画风不熟悉的 Agent 当场就爆内存了。

但恰恰是人类员工耳濡目染的日常场景，才能真正反映公司运转的真实情况。

网上有一个段子： 我把我们五年的聊天记录全部喂给 AI，AI 表示根据数据分析他从来没爱过我。这其实就是把碎片化的上下文归集起来，完整输入给 AI 的过程。

《楚门的世界》里，楚门前 30 年人生的上下文都被摄像机完整记录了下来，如果当时有 AI，就能直接喂给数字人继续演了，你楚门爱去哪去哪。

但在企业组织里，让每个员工都有意识的归集上下文，既不现实，也不可能实现。这就导致企业内部大量的隐性知识，被碎片化的隐藏起来。

所以，爬完了模型的雪山，走过了 Harness 的草地，怎么把企业组织内隐藏起来的上下文一网打尽，系统性的归集起来提升 Agent 的智能上限，是当下 AI 办公烈度最高的战区。

或者换句话说，对上下文的有效归集，是办公 Agent 实现产品差异化的关键，也是避免员工付费上班，让老板主动开发票的关键。

行动起来

一个企业最完整的上下文在哪里？答案是办公软件，具体来说，就是 Slack 和飞书这类协作办公工具。

过去一段时间，美国市场已经涌现出非常多 AI Coworker 概念的产品，特点是把 Agent 集成进企业具体的写作场景，可以像普通员工一样和人类一起干活，甚至能自己找活干，加班到忘我。

为什么一定要接入办公软件使用？关键就是上下文：

只有在真实的办公环境里不断输入数据，Agent 才能逐渐形成对公司的长期记忆，从实习生变成老油条。

这其实反映了 Agent 落地过程中的要解决的问题：智能化的能力是 Agent 提供的，但企业的上下文都沉淀在 IM/ 协作软件里，两者必须打通。

国内社交媒体上，有一堆 Agent 接入飞书的教程，原因就是沉淀在飞书里的上下文。甚至大厂的 Agent 产品，也会在客户演示现场重点展示连接飞书的流程。

一方面，飞书作为办公软件，天然承载着企业的上下文，对比同类型产品拥有结构性的优势。另一方面，飞书在 CLI 开放能力上投入很多，天然 AI/Agent 友好。

字节当然也意识到了这一点，让豆包工作和飞书做了账号级别的集成，目的就是彻底打通企业的上下文，又避免权限失控带来安全隐患。

国内几家互联网大厂，基本都有从模型 -Agent- 协作工具的完整生态，企业级 Agent 真正的护城河，恐怕还是在这个生态积累了多少企业的上下文，继而形成粘性。

换句话说，决定 AI 办公战局的东西，其实是企业组织在自家生态里积累的上下文质量。如果只积累了大量打卡数据，Agent 只能帮人事部门狠抓考勤。

飞书的强项是上下文积累。飞书推崇的云文档、多维表格、智能纪要，本身就是一种 AI Native 的工作方式：

举例来说，飞书云文档里，所有人在同一个文档里的评论、修改、讨论过程全部在线留痕。多维表格每一列都是有明确定义的字段，表和表之间可以关联。

同类产品只把文档作为工作的“结果”，但飞书在设计云文档时，本身就包含了工作的“过程”，上下文自动沉淀为数据资产，不需要事后搬运给 AI。

加上飞书的产品逻辑是 All in one，如果一个企业不同环节对应不同工具，Agent 还要逐个建立连接。飞书与豆包工作绑定，豆包工作可以完整的获取企业积累的上下文，不必从头学起。

总得来说，飞书本身是主流协作工具中信息标准化程度最高，对 Agent 适配最完整的平台。这种产品上的互补性，促成了组织架构的调整。

产品成型了，上下文打通了，想让老板心甘情愿开发票，还需要最后一步。

商业产品体系

个人和企业对 Agent 的评价，是截然不同的两种尺度。

个人用户的上下文装在脑子和硬盘里，答错了换个问法重来，成本几乎为零，产品权重很大；企业的上下文分散在五个部门三套系统里，答错一个数字就是合规事故，所以企业真正关心的是可靠性。

这种可靠性有两个具体的指标：

一是管理 Token 额度消耗。今年，硅谷大公司都在猛砍 Token 预算，微软要求团队全部迁移回自研 GitHub Copilot CLI，Uber 四个月花完了全年的预算， Salesforce 禁止销售团队用 AI 搞文案润色甚至日常闲聊。

Meta 一度推出排行榜，在内部比一比谁 AI 用得最猛。结果榜一大哥一个月就烧了 50 万美元。

二是数据安全。任何正规的制造业企业，都会严格管理员工使用个人版 AI 工具，原因是数据安全。

关于这一点，干过云计算销售肯定深有体会，在很多公司老板们心目中，最安全的方法就是把机房放在公司楼下，服务器和网线近在咫尺。门上挂一把大铁锁，钥匙放在枕头下面。

很多高科技行业如芯片设计，一些理念往往极端保守，原因依然是数据安全。专利和技术文档是芯片公司的命根子，RTL 代码、芯片网表、工艺设计套件和 IP 一旦泄露，等于研发成果拱手让人。

如果一个负责任的芯片公司的老板听说员工正在让 Agent 了解公司的上下文，他会第一时间拿出专业液压钳剪断公司的网线。让员工付费上班，是件很危险的事。

额度管理和数据安全两项指标，共同指向了一个结果：个人用户可以用 Agent 猛猛写周报，但企业级 Agent 不能靠单个产品解决问题，需要一套成熟的商业产品体系。

在豆包工作的产品逻辑里，它可以完整继承企业在飞书已有的权限设置，员工只能在权限范围内与 Agent 交互。Agent 既能够了解企业的上下文，又不越过权限的边界。

对企业来说，只需要把飞书上积累的用户习惯直接接入豆包工作，切换成本非常低。

这也是牵引字节一系列业务变动的关键因素：行业相继意识到上下文的重要性，飞书已经建立起了最接近 AI Native 的用户习惯、最完整的企业上下文和经过大公司验证的产品体系。

只能说家底够厚，人生容错率就是高。