自如自建企业 AI 工作台 Ziroombuddy 落地实践

• 这是一篇关于企业级 AI 工作台的长文问答。起点是一个越来越清楚的判断：模型正在成为公共品，企业真正稀缺的，是自己的数据、语义和工作流。我们从数仓 ChatBI 和知识平台出发，一路走到数字工位和轻应用，把买与建的取舍、架构上的关键决定和踩过的坑，按问答的方式讲清楚。整套平台跑在开源 Agent 运行时 Deepseek harness 上。

智能正在成为公共品。最强的模型对所有企业明码标价，竞争对手明天就能买到同一个。当智能本身不再是壁垒，竞争的变量就从「买什么智能」迁移到「智能接什么」。员工最早提给我们的需求都很普通：查一下昨天的入住率，拉一份这个月的业绩明细，把周报发到群里。真正难的从来不是让模型回答问题，而是让它以正确的身份进入正确的系统，并把结果交付出来。两个月前，第一个员工 Agent 实例上线；今天，数百个数字工位在运行。这篇文章不复述功能清单，只回答一个问题：模型平权之后，一家有较为完善的数据平台的公司，应该把能力建设放在哪里。

1. 语义先于智能：本体、元数据与知识库，是企业给智能的第一张地图。模型买得到，语义资产买不到。
2. 轻应用改变的是组织的软件代谢速度：软件的修改权回到业务手中。
3. 数据出不了内网，买与建就没得选：核心数据资产能不能搬出公司，是一道判断题——能搬，可以买成品解决方案；不能搬，厂商方案在第一步「数据接入」就走不通。
4. 模型平权之后，稀缺点变成了真正的Ai-native企业组织能力的提升：工作台是模型和组织能力两者之间的转换器。
5. 这是企业 IT 的第四个「人人级动作」：发 PC、开邮箱、装 IM 之后，给每个员工一个数字工位。一句话：模型会换，工位不换。模型是买得到的，组织能力才是建出来的。

01

起点：从问数到工位

• 让智能懂数、懂知识，是企业 GenAI 的第一步。两个平台，一个本质：把企业的隐性语义变成机器可读的资产。模型买得到，语义资产买不到。

Q1：「在做工作台之前，你们从哪里开始？」

企业 GenAI 落地，第一步往往不是选模型，而是整理企业自己的语义。我们先做了两个平台：

• 数仓 ChatBI：从本体和元数据建设开始，把业务概念、概念之间的关系、表和字段、指标口径写清楚，然后在此基础上做自然语言转 SQL。员工说「看一下本月入住率」，系统要生成正确的sql，前提是要知道「入住率」在公司内部到底怎么定义。这件事的瓶颈从来不在模型：模型翻译得了自然语言，翻译不了没写下来的业务口径。没有口径地图，模型可以生成一条语法完全正确的 SQL，却可能把错误的字段和错误的时间范围拼在一起，答案越流畅，错误越难被发现；
• 企业知识平台：制度、流程、排障经验和业务问答，通过 RAG 变成可以检索的知识库。很多组织经验没有写在任何系统里，却决定了一个问题应该怎么处理。知识平台做的，就是把这些经验从个人记忆里沉淀出来。

两个平台，一个管数据，一个管知识，本质上做的是同一件事：把企业的隐性语义变成机器可以理解和调用的资产。模型人人买得到，语义资产买不到，这是「智能平权」之后企业真正的家底。

02

价值：模型平权之后，稀缺项改变了

• 模型人人买得到，稀缺的是把模型能力变成组织能力的自有载体；工位就是这个载体——员工身份、自带工具、动作留痕、产出归公司，连核心数仓都敢交给它，因为 AI 用谁的身份，就走谁的权限。

Q2：「先说结论：企业级 AI 工作台的价值，到底是什么？」

工作台是把「买得到的模型能力」转化为「买不到的组织能力」的转换器。具体是三重价值：

• 第一重，转化：模型能力只有接上数仓、懂业务口径、能替员工跑完整流程，才进入组织的工作流；否则永远停留在员工各自的聊天框里；
• 第二重，资产化：没有工作台，AI 投入是费用，席位费按年流出，能力长在个人聊天记录里，人走能力走；有了工作台，提示词沉淀成技能、分析固化成轻应用，每一项可复用、都归公司；
• 第三重，解锁：安全边界不是刹车，是门票。没有「实例零凭据」这样的硬边界，核心数据不敢给 AI 碰；安全做得越硬，AI 能碰的场景价值越高。

Q3：「给每个员工买一份 AI 会员，不就 AI 化了吗？」

会员能解决「每个人有没有模型可用」，解决不了「组织如何持续使用 AI」。它便宜、零运维、当天见效，但边界也很清楚：模型进不了企业内网数据，员工第一批真实需求，查入住率、拉业绩明细，全部撞在这堵墙上；员工摸索出的提示词和取数方法留在个人对话里，无法复用，人走了经验也跟着走；它也缺少企业身份、审计和权限控制，数据进了哪个对话框，公司很难完整追踪。所以这两件事之间，差一个载体，而且这个载体必须是自有的。

Q4：「为什么叫『工位』？」

因为「工具」「助手」都叫小了，只有「工位」叫得准。工具是拿来用一下的东西：不带身份，用完不留痕迹，换一个产品照样用。工位是公司分给个人的一席之地：挂在你的名下，配齐干活的装备，干活的过程受治理，产出的东西沉淀下来。这个平台给的正是这样一件东西：有身份，以员工本人身份进出企业系统；有工具，数仓、BI、浏览器、知识库；有审计，每一步动作留痕；有产出，分析变报告、报告变应用，可沉淀可分享。工具用完就走，工位天天开工。

Q5：「核心数仓，真的敢交给 AI 碰吗？你们是怎么解决安全问题的？」

安全是这套设计能存在的前提。数仓本有一套跑了多年的权限体系：LDAP 统一认证，Ranger 集中授权，消费端按人执行。我们的原则只有一条：Agent 不另建权限体系，只做身份翻译。代理按LDAP登陆账号认出这是谁的实例，交回原有链路裁决；审计仍在数仓那一侧，AI 平台不留第二份权限账。身份翻译靠「实例零凭据」实现。

03

买与建：不是性价比问题，是可行性问题

• 厂商的路是把企业搬上平台，我们的路是把 Agent 搬进企业。上下文的搬运成本，是数据密集企业不可接受的成本。

Q6：「业界都给出了什么答案？为什么对你们不成立？」

市场上已经有不少企业 AI 工作台，形态高度趋同：托管运行时、企业知识接入、IM 生态绑定、安全中心。三家代表：

• 腾讯 WorkBuddy：与企业微信深度打通，以独立桌面客户端为载体；
• 阿里千问办公：主打「企业上下文」，用连接器把企业知识与业务数据拉上平台，绑钉钉；
• 字节豆包工作：做账号级上下文继承，深度整合飞书。

差异主要在绑哪家 IM，以及上下文工程的路线。

最有代表性的是千问办公的判断，Context is All You Need。我们认同一半：Agent 不接数据就是玩具，这被我们数百个实例上的真实需求反复验证。但实践者要补上后半句：上下文进得来的前提，是有一个企业自有的载体。

同一个判断引出两条路。阿里的路是把企业搬上平台：用连接器把数据拉上去，压缩成 Agent 可调用的上下文，由托管运行时来跑。我们的路恰好相反，把 Agent 搬进企业：实例直接运行在内网里，以员工本人的身份和权限去碰数仓、BI、知识库。上下文不需要被搬运，因为它从来没有离开过公司。

厂商的路对没有内网数据平台的公司是成立的；但对数据资产密度高的公司，上下文的搬运本身就是最大的安全与工程负担。

Q7：「怎么评估这些方案？载体形态本身有没有优劣？」

我们评估过这些路线，也并不认为自建天然优于采购。真正的分界线是三个问题：企业核心数据能不能离开自己的网络；Agent 是否必须以员工本人的身份访问内部系统；企业是否需要长期掌握运行时和能力扩展的主导权。具体可以用五个问题衡量：

1. 上下文和密钥由谁掌握？
2. Agent 以谁的身份行动？
3. 能不能接入内部系统并编程新的能力？
4. 模型和平台能不能独立演进？
5. 成本是按席位线性增长，还是随规模扩大逐步下降？

三家在数据主权、身份、能力开放三行高度同构。这不是工程差距，是产品定位使然：它们必须服务所有企业，所以必须把数据收拢到自己的平台。我们要的东西，恰好只能出现在这张表的最后一列。

载体形态还有一个被普遍低估的维度：harness 住在哪一侧。WorkBuddy 和豆包工作的 harness 跑在员工本地电脑上，运行时在端上，意味着三件避免不了的事：

• 数据落端：会话、取数、产物写在员工本地磁盘，企业数据从机房的一份变成每台终端的一份，审计链在落盘那刻就断了；
• 过程黑箱：Agent 在员工电脑里运行，资源占用、循环失控平台全看不见，出问题靠用户截图报障；
• 配置碎片：每人一份模型和技能配置，漂移随人数线性增长。

这三条不取决于厂商的工程水平，取决于 harness 住在哪一侧。服务端形态则天然获得三条红利：

• 工位不绑设备：任何终端登录都是同一工位、同一会话；
• 升级对称：平台一次动作全舰队生效；
• 长任务与值守：用户关掉浏览器，任务继续跑。

Agent 运行时住在哪一侧，是安全与治理问题，不是体验问题。

Q8：「既然大厂都有成品，为什么不直接买？」

先把决策凝成一道判断题：你的核心数据资产，能不能搬出公司？

• 能搬（轻数据行业、无强合规约束）：买，别犹豫。厂商在上下文工程上的专业化打磨，短期内不是自建团队追得上的；
• 不能搬（数据在内网数仓、有合规义务、内部系统深度耦合）：厂商方案在第一步「数据接入」就走不通，后面的功能对比、价格谈判都不存在。对这类公司，买的障碍不是价格，是可行性。

归纳起来，自建的理由是三句话：

• 买得到的是人人可得的：成品对所有人明码标价，竞争对手不但买得起，而且买得比你更快；用买的方式永远追平不了对手；
• 租的是费用，建的是资产：席位订阅按人头线性增长，停止续费一切归零；平台是一次性投入，技能、应用、站点在它上面持续复利，平台建成后，每新增一个工位的成本只是一个容器加推理费；
• 通用产品进不了非通用场景：厂商必须服务「最大公约数」需求，而数仓按人控权、统一认证、内部 BI，恰好全是非通用的部分。

判断是否自建，可以先看一个简单的乘积：数据资产密度乘以内部系统耦合度。这个乘积越高，越需要把 Agent 放回企业自己的网络和身份体系里；这样的公司买成品工作台，买到的是一间进不来的门面。

Q9：「自建是不是什么都自己造？代价是什么？」

恰恰不是。栈分三层，各用各的策略：

• 模型层，默认租用：所有模型供给走公司统一网关，网关后面接哪家、按什么倍率计费，与工作台完全解耦；唯一的例外是敏感度最高的那部分内部数据——它们不出网，走我们自己私有化部署的模型，而这条通道同样挂在统一网关后面，按数据分级路由，上层应用无感；
• 内核层，用开源：Agent 的会话、工具调用、审批流、技能机制，用开源 Agent 运行时 Deepseek harness，我们不写 Agent 框架，就像二十年前的企业不自己写操作系统；
• 平台层，自建：身份、网络、数据腿、技能市场、监控治理、轻应用，这一层没有现成品，也恰好是主权所在。

模型是最应该保持可替换的部分，平台才是需要长期拥有的部分。

代价也要诚实说：

• 稳定性工程全是自己的事：我们处理过无上限的浏览器进程一夜泄漏数十 G 内存拖垮节点，也处理过上游内核缺陷把磁盘 IO 打满，采购 SaaS 时这些由厂商承担；
• 上游跟随有成本：版本升级带着连带修复，跟不上就漂移，跟得太紧就要有大量自测成本；
• 安全要自证：厂商拿资质说话，自建要拿设计说话，凭据怎么放、审计怎么做、脱敏在哪层，每一样要证明给安全团队看。

我们的结论是，这些代价不是「自建的成本」，而是「拥有」的价格。SaaS 并没有消灭复杂性，只是把它们连同主权一起，转移给了厂商。

Q10：「为什么是一人一个实例，而不是一个服务多个账号？」

选 harness 而不是编排框架，背后是两条匹配律：

• 部署单元对齐信任单元：传统 web 服务是一个进程服务所有账号，权限靠代码层层校验、故障与升级全员共担——它为高并发而生，前提是请求无状态；
• 资源形态决定架构形态：工位不是轻量的请求处理器，而是一组重资源——长驻的专属浏览器带着持久的 profile 和登录态、一人一个容器的轻应用、个人的安卓虚拟机、工作区文件与记忆，动辄以 GB 计，且需要常年在线。

把这样一组资源塞进多账号统一服务只有两条路：做成共享池按账号调度，于是串会话、串凭据、排队、吵闹邻居全都会来；或者服务自己长成一个小型云，在 web 框架里重新发明容器调度。

一人一实例把问题倒过来解。这组重资源天然属于个人，就让它们住进本人的容器里，跟着人走：

• 隔离交给内核，而不是业务代码；
• 一个人的失控循环，只烧自己的容器；
• 升级逐人灰度；
• 审计就是容器生命周期本身。

具体到运行时，选 Deepseek harness，看中两样：一是「一切皆插件」，引擎、技能、外部连接、界面组件全是插件，连自研的引擎接入、技能市场、网络代理也以插件挂载，零改内核；二是活跃的开源社区，开源仅两个月，社区索引已收录数千个插件与技能条目，上游每进一步，全部工位免费受益。

04

轻应用：组织的软件代谢速度

• 企业软件永远滞后于业务，根源是软件的修改权集中在少数人手里。轻应用把修改权还给业务，让组织的软件代谢速度，第一次跟得上业务的变化速度。

Q11：「轻应用到底是什么？」

一句话：员工用自己的 Agent，把一句需求变成一个自己会跑的小系统。员工可以直接说：「每天早上从数仓取昨天的入住数据，按区域校验异常，生成一页看板。」平台负责把它生成并运行起来，同时提供网址、权限、定时任务、告警和版本管理。一个传统上要立项、排期、开发、上线的「小 IT 项目」，在这里的形态是：员工对 Agent 说一句话，当天上线。

以企业做 BI 页面为例，这条路已经走过了三个阶段：

• 第一阶段，前后端研发：业务提需求，工程师排期写代码，出一张页面以周计，会做的人只有研发；
• 第二阶段，拖拽式 BI：Tableau、有数、FineBI 这类工具让做页面不再需要写代码，但拖拽本身仍是一门要学的手艺——要懂数据集、维度和指标口径；企业里真正用得起来的，通常是每个部门里少数愿意钻研平台的人，大多数业务员工仍然只能提需求、等排期；
• 第三阶段，vibe BI：不写代码、不拖拽，在对话框里把想要的页面描述出来，直接得到一个能跑的系统，公网产品已经用海量用户验证了这个需求。

三个阶段的规律是：每走一步，「谁可以做」的圈子扩大一个数量级，门槛从「会代码」到「会拖拽」再到「会说话」。到轻应用这一步，做系统的门槛第一次降到「会把需求说清楚」，而这恰好是每个业务同学的本职。

Q12：「一句话做应用，价值到底在哪？一句话变成系统，又要靠什么架构？」

「一句话做应用」的价值不在省了程序员，在消灭翻译，需求方第一次就是建设方；而这句话要变成企业敢用的系统，靠四层架构。先看价值。百度秒哒上线八个月生成五十万个应用（公开报道口径），这个数字验证的不只是「AI 会写代码」：软件三十年来昂贵的部分不单单是代码，还有想法和系统之间的翻译链。传统流程里，一句话需求要经过产品文档、交互设计、技术方案、研发排期和测试上线等多轮转换，每一轮都可能产生偏差，周期以周或月计算。秒哒这类产品把这条链压缩成自然语言直达，需求方第一次有机会直接参与建设。对企业，这是长尾需求的解放：那些值得做、但不值得立项的需求，第一次有了出口。而同一份价值搬到企业内部会放大，根因是它连得上内部的数据和系统：公网的一句话，做出一个面向公众的页面，页面本身就是全部；企业里的一句话，做出的是接着数仓、按人分权、每天自跑的内部系统——连着真实数据和真实流程，能干的活自然多得多。要让一句话生成的系统可以在企业里运行，至少需要四层保障：

• 生成层：Agent 写码，平台保底。员工在自己的工位里描述需求，Agent 在统一脚手架上生成应用。脚手架、依赖和管理能力由平台统一提供，平台的工程下限就是每个应用的质量下限。
• 运行层：一个应用一个容器。容器负责把应用彼此隔开，用量有上限，越不过权限边界，一个应用失控，影响范围只停留在自己的容器里。
• 数据层：四条腿，零凭据。所有取数通过数据代理完成，代理以负责人身份访问数仓、数据库、BI 和浏览器，应用本身看不到任何密码和密钥。
• 权限层：统一认证，按人分权。入口接入公司统一认证，负责人可以配置「只有我、指定名单或全员可见」，权限细到单个页面。

这四层决定了轻应用和普通原型的区别：它不是生成一个看起来能用的页面，而是生成一个有人负责、有权限边界、能持续运行、出了问题可以恢复的企业系统。软件的修改权回到业务手里之后，组织的代谢速度，肉眼可见地跟了上来。

05

终章：第四个「人人级动作」

Q13：「下一步要投入什么，换回什么？」

投入侧清单很短：一支精干的平台团队、按增长节奏的节点扩容、持续的商业大模型推理费，没有许可证，没有席位费。

换回什么？正是Ai-Native组织能力——让模型在公司里真正干活的那套东西。它分三层兑现：

• 短期，效率：查数、拉报表、写分析的工时节省，已经在兑现；
• 中期，资产：技能库、轻应用持续积累，新员工入职第一天就继承前人的经验——组织能力越攒越厚，招聘和培训的隐性成本随之下降；
• 长期，新形态：面向具体业务场景的任务型常驻实例（「数字员工」值守岗位）、面向产品、研发、测试、设计的通用垂直工作台，以及跨实例协作——这是组织能力的完整形态。

• 模型是租来的，组织能力是建出来的。建到最后，就是更高的组织效率和更强的市场竞争力。

06

结语：发 PC、开邮箱、装 IM、给工位

上世纪九十年代以来，企业 IT 做过三个人人级动作：给员工发一台 PC，让信息进入每个人的工作；开一个邮箱，让正式沟通进入每个人的工作；再后来，企业微信、飞书、钉钉这样的 IM 工具，让实时协作进入每个人的工作。这一代企业 IT 的第四个人人级动作，可能是给每个员工一个数字工位，让行动进入每个人的工作：组织的执行单元，从「人+流程」变成「人+Agent」。模型在云上，数据在内网，企业需要自己建设的，正是让两者安全相遇的那套工位。

这一步的分量，要放进办公室的装备换代史里看。PC 让每个人拥有了信息处理能力，邮箱和 IM 让沟通即时抵达——但它们改写的都是效率：同样的事，一个人做得更快。AI 工位改写的是产能：以前要一群人分头做的事，现在一个人接得住。因为它给个人的，是调动整个组织资源去行动的能力。当「一个人加一组 Agent 就是一支队伍」成为日常，组织与个体的边界开始重画。这不是又一次办公工具的升级，是历史浪潮的变更，是超级智能个体时代的前奏。

嘉宾简介：14 年大数据平台经验，主导建设湖仓一体、AI Ready 的数据平台，覆盖离线、实时数仓、GPU 算力与数据治理；最近专注 Data Agent 与 GenAI 落地，打造“对话即达”的全员AI工作台