飞书2.0猜想：员工实时生成自己的企业协作软件

今天的企业协作软件，无论是飞书、Slack，还是更多面向组织的办公平台，基本遵循同一种范式：公司采购或开发一套统一应用，产品经理设计页面和流程，研发把功能实现出来，然后所有员工学习怎样使用它。

这种范式曾经大幅降低了协作成本。但系统越做越大，问题也越来越明显：入口越来越多，菜单越来越深，功能越来越全，每个人真正需要的部分却只占其中很小一块。

教师、销售、产品经理、财务人员和 CEO，本来面对完全不同的目标、信息和工作节奏，却被要求进入同一套界面，理解同一套产品逻辑。所谓个性化，通常只是换一组快捷入口，软件的生产权仍然掌握在平台和研发团队手里。

我的猜想是，AI 会改变这条延续了几十年的基本规则。

飞书 2.0 不一定是一个功能更多的超级 App。它更可能是一套 Headless Enterprise OS：企业提供身份、规则、数据、能力和运行环境，每个员工则与自己的 Agent 一起，实时生成最适合当前目标的协作软件。

入职第一天，先和 Agent 一起造自己的软件

设想一个员工刚刚入职。激活员工 ID 的同时，他自动获得一个属于自己的 Agent。

这个 Agent 已经知道他的岗位、部门、汇报关系、职责和项目，也获得了与岗位匹配的知识、数据和工具权限。它了解公司的制度、业务背景和团队分工，但不会把这些初始信息当成对员工的最终定义。

它的第一句话可能不是“您好，我能为您做什么”，而是：

“我目前对你的理解是：你负责学习机数学内容产品，未来 90 天的核心任务是完成七年级内容上线。我已经读过相关项目历史、决策和团队分工。我们先校正我对你的理解，再一起设计你的工作台和第一个月的工作方式。”

接下来的几十分钟里，员工和 Agent 会共同校正个人 Profile，明确阶段目标，识别关键协作者，选择需要的 Skills，生成入职计划，并在电脑和手机上创建第一版个人工作台。

这个首页不再是公司统一规定的八宫格，而是围绕员工当下的责任生成：我的目标、今日最重要事项、所负责项目、待我决策、需要补充的 Context、用户和业务信号、Agent 正在执行的任务，以及常用工具和自动化。

员工不再从学习软件开始工作，而是从定义目标和共同创造工作方式开始工作。

生成的不只是页面，而是整个工作系统

如果 AI 只是帮员工画一个 Dashboard，这件事的意义有限。真正的变化，是软件从预先制造的固定产品，变成可以围绕任务持续生成和修改的工作系统。

员工可以生成界面。教研人员可以直接说：“帮我做一个七年级数学教材版本差异工作台。左边按知识点组织，右边展示各版本内容差异，再把最近两周的一线教师反馈放进来。”Agent 调用经过授权的数据和组件，很快生成可用页面。

员工也可以生成工作流。他可以说：“每周五汇总学生错题变化，发现异常知识点后通知对应教研负责人，形成原因假设并建立验证任务。”Agent 把这句话编译成触发条件、数据查询、判断规则、责任人、人工确认节点和反馈闭环。

员工还会把自己的方法生成 Skills。竞品课程拆解、用户访谈分析、教研内容审校、经营数据诊断、项目复盘，都可以从个人经验变成可调用、可评测、可授权、可复用的能力。最佳实践不再只是一份供人阅读的文件，而是一个能够直接运行的对象。

一个员工拥有的也不再只是一个总助理。他可以针对任务组织调研 Agent、数据分析 Agent、项目管理 Agent、内容 Agent、质量评测 Agent和蓝军 Agent。人与人之间的能力差距，将越来越取决于谁能提出更好的问题、建立更好的 Context，并组织一支更有效的 Agent 团队。

在权限允许的情况下，个人工作台里的某个功能还可以继续长成微应用，发布为团队工具、教师工作台、合作伙伴门户、活动页面或轻量产品原型。

一个员工为解决自己问题而创造的工具，经过真实使用、评测和治理，可以升级为团队能力，甚至成为面向客户的产品。

企业从交付应用，转向交付底座

过去，企业 IT 的主要交付物是一套套系统。未来，平台团队更重要的任务，可能是提供一组稳定、清晰、可组合的基础能力。

第一层是 Identity 与 Policy。员工 ID 不只是登录账号，而是人、Agent、数据与工具之间的身份根节点。系统必须知道一个人是谁、承担什么责任、可以访问什么、能调用什么工具、可以让 Agent 自动执行到什么程度，以及哪些动作必须由人确认。

第二层是 Context 与 Data。公司的知识、项目历史、决策记录、会议内容、用户反馈、业务数据、制度和外部情报，不能只是散落在文档库里。它们需要可读取、可调用、可追溯、可更新，并进入真实工作的反馈循环。

第三层是 Capability。API、CLI、MCP、Skills、消息、日历、文档、数据查询、代码执行、内部系统连接器和对外发布 Site 的能力，都应成为 Agent 可以在权限内组合的原子能力。

第四层是 Agent Runtime。Agent 不能只活在聊天窗口里。它需要长期运行，管理长短期记忆，完成模型路由和多 Agent 协作，响应定时与事件触发，并具备人工确认、沙箱执行、成本控制、失败恢复和运行日志。

第五层是 App Runtime。员工与 Agent 应当能够快速生成 Web、移动端页面、表格、Workflow、Bot、Site 和微型业务系统。但这些应用不应每次从零编程，而应建立在企业统一的设计系统、组件库、安全框架和数据标准之上。

第六层是 Evaluation 与 Audit。系统必须回答：Agent 调用了哪些数据，依据什么做出判断，执行了什么动作，使用了哪个模型和 Skill，谁授权、谁确认，结果是否正确，对业务产生了什么影响。Agent 越自主，评测、审计和责任追踪就越重要。

这六层合在一起，才是 Headless Enterprise OS。前台应用只是这些能力针对某个员工、某个项目和某个时刻的一次动态编译。

三种新的组织单元

如果这种形态成立，未来组织可能出现三个基本单元。

第一个单元是“一个员工 + 一个 Agent + 一个个人 App”。个人 App 围绕员工的目标、责任、Context、权限和工作方式动态生成，是员工与 Agent 共同维护的个人工作系统。

第二个单元是“一个项目 + 一个 Workspace + 一组人机 Agent”。项目 Workspace 不只是群聊，而是一个持续存在的业务对象：它包含目标、文档、代码、数据、决策历史、任务、用户反馈、Agent 运行记录、评测结果和最终业务结果。人在其中协作，Agent 也在其中工作。

第三个单元是“一个企业 + 统一的 Context 与 Policy”。个人界面可以不同，但企业的身份、权限、数据定义、业务规则、风险边界、组织目标、责任归属和评测标准必须统一。

这件事最重要的原则可以概括为一句话：前台高度个性化，后台高度标准化；体验高度生成化，规则高度确定化。

个性化不等于取消统一系统

飞书 2.0 的猜想，不意味着财务、HR、合同、交易和标准审批系统都应该被生成式应用取代。

企业仍然需要共同事实和统一规则。报销制度、财务科目和审批要求必须保持一致，但不同角色看到的入口和操作过程可以完全不同。

财务人员需要完整专业的经营和核算界面。普通员工只需要告诉 Agent：“把这几张发票处理掉。”Agent 在背后识别票据、补全信息、调用同一套财务系统，并在关键节点要求员工确认。

稳定的系统继续承担确定性和可审计性，生成式前台负责理解人的目标、降低操作复杂度和编排跨系统任务。企业协作平台不是吞掉一切，而是成为人与全部系统、数据和 Agent 之间的智能交互层。

最大的风险，不在模型能力

第一个风险是口径分裂。界面可以千人千面，核心指标、业务定义和制度规则不能千人千套。企业必须明确哪些内容可以生成，哪些事实只能引用权威来源。

第二个风险是 Profile 固化。Agent 对员工的理解不能变成永久标签。系统应清晰区分客观事实、员工自述、他人反馈和 Agent 推断，并允许员工查看、校正和删除。否则，“理解员工”很容易变成“定义员工”。

第三个风险是局部最优。个人 Agent 天然会帮助员工完成个人目标，但个人、项目、部门、公司和用户的目标并不总是一致。Agent 必须理解多层目标，同时受到企业 Policy 约束。

第四个风险是应用爆炸。如果每个人都可以无限生成应用，公司很快会拥有大量重复、低质、无人维护的工具。私人应用、团队应用和公司级应用必须有不同的发布等级、评测标准、安全要求和维护责任。

第五个风险是责任模糊。不能出现“这是 Agent 做的，所以没有人负责”。系统必须始终记录谁提出目标、谁授权执行、谁确认关键动作、谁承担最终业务责任。

这些风险决定了企业不能只建设一个生成器。生成能力必须与统一身份、权限、评测、审计和生命周期治理同时出现。

从一个很小的入口开始

这种未来不需要通过一次庞大的平台重建实现。更现实的路径，是从一个边界清楚、价值完整的场景开始。

第一步是入职 Agent。员工激活 ID 后，Agent 帮助他校正 Profile，学习公司与岗位 Context，形成 90 天计划，识别关键联系人，理解权限和系统，并生成第一版个人工作台。

第二步是可生成的个人首页。员工通过对话调整目标、项目、待办、数据指标、知识订阅、Agent 工作记录和常用 Skill，但界面仍由公司批准的组件构成。

第三步是受控的个人微应用。先从信息整理、数据查询、内容生成、项目跟踪、会议复盘和用户反馈分析等低风险场景开放，让生成的软件在沙箱中运行。

第四步是项目级 Agent Workspace。个人工具可以升级为团队工具，优秀团队工具可以进入公司组件和 Skill 市场，工作结果和评测继续反哺平台。

第五步才是完整的 Headless 平台。企业逐步把 Identity、Policy、Context、API、CLI、MCP、Skills、Agent Runtime、App Runtime、Evaluation 和 Audit 建成公共基础设施，不再追求用一个无所不包的前台满足所有人。

从知音楼到飞书 2.0

“知音楼”是好未来内部协作平台的名字。它并不是公众熟悉的通用产品，但可以把它视为这个猜想的实践背景，也是我们内部讨论这种未来形态时使用的一个代号。

过去的企业协作平台，像一栋由公司统一设计和装修的办公楼。所有人使用相似的门、走廊和房间。

未来的企业协作平台更像一座城市。公司建设身份系统、水、电、道路、公共设施、规则和安全边界；每个员工与自己的 Agent 一起，建造并持续改造最适合自己的工作空间。

因此，飞书 2.0 真正的升级，不是再增加多少功能，也不是在每个页面放进一个聊天框。

它改变的是软件生产权的归属。

未来企业不是给员工提供软件，而是赋予员工生成软件、改造流程和组织 Agent 的能力。企业协作软件也将从一个统一应用，变成组织中每个人都可以参与编程、持续进化的基础设施。