从整车研发场景出发，重新思考飞书、Agent与IPD的边界与协同。
最近在公司内部讨论 AI Native 办公交互蓝图，讨论了很久，我们发现：
也许大家一直在问一个错误的问题。
未来企业，到底是谁会成为那个“唯一入口”？
是飞书？
是企业微信？
是企业自己做的 Agent？
还是现有业务系统？
真正跑完整车研发的数字化链路后，我越来越觉得：
答案可能不是“谁替代谁”，而是“谁该回归自己的位置”。
今天，我想分享一下自己对 AI Native 时代企业办公交互的一次推演。
企业 AI Native 时代交互全局蓝图
如果用一句话概括，这就是我目前对 AI Native 办公交互的判断：多入口协同，统一智能中枢。
一、那个让研发人精疲力竭的“系统丛林”
如果你在研发岗位，大概率对这样的场景并不陌生。
上午，在飞书群里讨论项目风险；
下午，打开 IPD 系统处理交付物、维护 BOM；
晚上，又要去仿真平台下载分析报告、整理汇报材料。
不同系统、不同界面、不同操作逻辑。
我们早已习惯在各种系统之间来回切换。
过去二十年的企业数字化，本质上是：
人适应系统。
系统告诉你：
先登录哪个平台；
再点击哪个菜单；
最后按什么流程提交。
员工最重要的能力之一，甚至变成了：
“熟练使用各种系统”。
系统丛林：研发人的一天
但大模型出现之后，事情开始发生变化。
以前，我们学习系统的语言；
现在，系统开始学习人的语言。
过去是：
“我要找到对应功能完成任务。”
未来则变成：
“我只需要表达自己的意图。”
比如：
以前：
请登录系统，进入碰撞分析模块，查找对应报告，导出结果。
未来：
“帮我分析 M9 和 P9 的碰撞结果差异。”
以前：
找到对应页面查询交付状态。
未来：
“M9 项目本周交付完成情况怎么样？”
交互方式正在发生根本变化：
从流程驱动，走向意图驱动。
二、我们差点掉进去的三个“坑”
为了回答“AI Native 企业到底该怎么建”这个问题，我们内部讨论了很长时间。
过程中，有三个看起来非常诱人的方案。
但最后，我们发现它们都存在明显问题。
坑一：让 IPD 系统直接长出一个 Agent
这几乎是很多企业最自然的想法。
既然 IPD 已经是研发核心系统，
为什么不直接把 Agent 做进 IPD？
问题在于：
IPD 的基因，本来就不是做交互入口。
IPD 擅长的是：
流程管理；
交付物管理；
权限控制；
数据治理；
工程规则。
而不是：
高频自然语言对话；
多模态交互体验；
快速迭代的 Agent 能力。
一旦把两者强行耦合：
前端体验升级，需要业务系统同步改造；
后端规则调整，会影响交互能力迭代；
整体复杂度持续上升。
对于并非大模型公司、软件巨头的大多数制造企业而言，
这条路太重。
更重要的是：
企业真正需要的，不是一个会聊天的 IPD，而是一个稳定可靠的业务中枢。
因此：
IPD 应回归“业务中枢”，而不是承担统一前端入口。
坑二：把飞书变成万能入口
另一种声音是：
既然员工每天都在飞书里工作，
为什么不把所有事情都放到飞书？
看起来很合理。
但问题同样明显。
飞书擅长的是：
人与人的协作；
审批流程；
文档沉淀；
消息通知；
移动办公。
但研发体系真正复杂的部分在于：
BOM 管理；
数模数据；
仿真结果；
工程规则；
项目隔离权限；
深度业务流程。
这些能力，很难完全沉淀在协作平台中。
同时，核心工程数据长期托管于第三方 SaaS，也会带来数据主权与安全挑战。
因此：
飞书更适合成为“协作底座与轻量入口”，而不是核心工程执行平台。
坑三：做一个无所不能的“超级 Agent”
这是最容易让人兴奋的方案。
一个 Agent。
什么都懂。
什么都会。
什么都能做。
但冷静下来会发现：
如果脱离业务系统和组织上下文，
Agent 很容易变成：
一个会聊天，却不真正理解企业运行逻辑的助手。
它没有：
IPD 的流程引擎；
阀门评审机制；
交付物管理能力；
统一审计与权限体系；
也缺少：
飞书沉淀的组织关系；
协作链路；
决策过程。
对于当前大多数企业而言，
所谓“全知全能 Agent”，更多是一种想象。
尤其对于并非 AI 基础设施提供者的制造企业来说，
与其从零打造一个超级入口，
不如：
充分借力 CodeX、Claude code、Qoder Work 等成熟生态，把有限资源投入真正不可替代的业务能力建设。
三、最终的答案：三层混合架构
讨论到最后，我们不得不承认一个现实：
没有任何一个入口，能够吃掉所有场景。
我的判断是：
大部分日常查询、知识获取与任务发起，将收敛到办公智能体（约 60%）；
复杂业务操作仍然需要专业系统承载（约 30%）；
轻量通知、审批与协作，则留在飞书等 IM 入口（约 10%）。
（这里的比例，并不是精确统计，而是对未来办公流量的一种推演。）
它反映的不是系统重要性，而是：
人与系统交互方式的重新分配。
第一层：企业办公智能体（约 60%）
承担：
自然语言理解；
意图识别；
任务分发；
统一能力调用。
它更像：
一个统一对话入口。
而不是替代业务系统本身。
第二层：IPD 开发中枢（约 30%）
承担：
Web 复杂操作；
AI 侧边栏辅助；
流程引擎；
权限控制；
Agent 编排；
核心研发数据管理。
它决定了：
什么可以做、谁可以做、应该怎么做。
因此：
IPD 是业务中枢，也是数据底座。
第三层：飞书（约 10%）
承担：
轻量查询；
审批确认；
会议协同；
文档沉淀。
因此：
飞书沉淀的是组织关系与决策上下文，而不是工程执行能力。
需要特别强调的是：
这并不是某个超级 Agent 独立完成所有工作。
它的背后，是办公智能体、IPD 与协作平台之间的能力协同。
下面这个例子，更像是一次“能力编排”。
一句话背后的协同过程：从“帮我看看 M9 项目风险，并生成下周例会材料”开始。
从一句自然语言，到最终完成协同，这背后并不是某个超级 Agent 自己在“编”。
而是：
用户提出需求；
办公智能体理解意图并拆解任务；
IPD 提供真实业务数据；
企业 Skill 生成分析结果；
飞书完成协同与通知。
四、为什么是现在？
有人可能会问：
为什么不是五年前？
为什么偏偏是现在？
因为过去缺少三个关键条件。
第一，大模型让自然语言真正具备生产力价值。
第二，CodeX、Claude code、Qoder Work 等 Agent 产品逐渐成熟，企业无需从零构建完整交互能力。
第三，经过多年数字化建设，IPD 等系统已经沉淀了足够丰富的流程、规则与数据资产。
过去十几年，我们花了大量精力建设系统。
而今天第一次出现了一种可能：
企业终于不用再推倒重来，而是在保留既有数字化资产的基础上，重构人与系统之间的关系。
这或许才是 AI Native 最容易被低估的价值。
五、真正的 AI Native，不是替代，而是重组
很多人在讨论 AI 时，总喜欢问：
飞书会不会被替代？
IPD开发系统会不会消失？
Agent 会不会成为唯一入口？
但我越来越觉得：
这些问题本身可能就问错了。
真正值得思考的是：
当自然语言成为新的操作系统之后，企业原有能力应该如何重新分层？
在我看来：
飞书（IM），是感知与协作层；
企业办公智能体，是认知与任务层；
IPD，是执行与数据层。
三者长期共存，各司其职。
最终形成：
轻量协同在飞书（IM），深度执行在智能体，核心能力沉淀于 IPD。
AI Native 企业的三层关系
未来最有竞争力的企业，
未必是拥有最强模型的企业。
而是那些能够完成这件事的企业：
把组织关系沉淀在协作层；
把业务能力沉淀在中枢层；
把交互体验交给智能体层。
过去二十年的数字化，是让人适应系统。
而 AI Native 真正带来的改变，是让系统开始适应人。
未来已来，只不过这一次，它不是让你去学一个新软件，而是让你少学几个软件。
至于最终会不会真的存在一个“超级 Agent”，我并不确定。
但有一点越来越清晰：
在真正的企业场景里，比“谁成为入口”更重要的，是谁理解人、谁理解业务、谁守住数据。
这三件事，或许长期都不会由同一个角色完成。
那么，在你的企业里：
AI 会成为新的入口，还是新的操作系统？
