1. 办公智能体赛道突然挤进一个国家队办公协同这个赛道过去十年基本是互联网大厂的天下。钉钉、飞书、企业微信三家把持着绝大多数企业的日常办公入口后来者想切进去难度不亚于在已经浇好水泥的地面上重新种树。但2024年下半年开始一个明显的变化出现了中国移动带着MobileWork这个产品直接杀进了办公智能体领域。这不是小打小闹的试水而是带着信创这张底牌、带着运营商级别的资源投入进来的。我最早注意到MobileWork是在几个做企业信息化的群里看到有人转发它的内测截图。第一反应是又一个办公IM但仔细看完产品结构之后发现它的定位跟钉钉、飞书完全不在一个维度上。MobileWork的核心不是聊天、不是审批流、不是视频会议而是智能体AI Agent驱动的办公自动化。换句话说它想做的不是另一个办公平台而是办公场景里的智能体调度中枢。这件事为什么值得认真聊因为办公智能体这个方向目前市面上真正跑通的产品并不多。大部分所谓的AI办公本质上还是在传统办公软件上挂了一个对话框你问它答仅此而已。而智能体的核心在于自主规划、工具调用、多步执行——它能自己拆解任务、自己调用API、自己完成一整套流程而不是等你一步步下指令。MobileWork如果真能把这件事在信创环境下跑通那它抢的就不是钉钉飞书的饭碗而是一个全新的生态位。这篇文章适合谁看如果你是企业IT负责人正在评估信创办公方案那MobileWork值得你花时间研究如果你是智能体开发者想知道大厂在办公场景怎么落地Agent架构这里有一手的架构思路如果你只是对办公智能体这个概念感兴趣想搞清楚它跟普通AI助手的区别我也会用最直白的方式讲清楚。下面我从产品定位、技术架构、信创适配、实操落地、竞品对比几个维度把这件事拆开聊透。2. MobileWork到底是个什么东西2.1 从产品定位看它想解决什么问题先说结论MobileWork不是钉钉的替代品至少现阶段不是。它的产品逻辑更接近办公场景的智能体操作系统。传统办公软件解决的是人和人怎么协作MobileWork想解决的是人和智能体、智能体和智能体之间怎么协作。举个具体场景你就明白了。假设你是一个项目经理需要完成一份季度总结报告。在钉钉里你的操作路径是打开文档→手动整理数据→写内容→发给领导审阅→根据反馈修改。在MobileWork的逻辑里你只需要说一句帮我生成本季度项目总结数据从项目管理系统的API拉取格式参照上季度模板完成后发给张总审批。剩下的拆解任务、调用数据接口、套用模板、发起审批流全部由背后的智能体自动完成。这个差异的本质在于传统办公软件是工具MobileWork想做的是执行者。工具需要你操作执行者只需要你下目标。这也是为什么它叫办公智能体而不是智能办公助手——助手还是被动响应智能体是主动执行。2.2 核心功能模块拆解从目前公开的信息和内测反馈来看MobileWork的功能架构大致分为四层层级功能模块核心能力交互层统一入口自然语言对话、多模态输入、任务下发调度层智能体编排引擎任务拆解、智能体路由、多智能体协作执行层工具调用框架API调用、RPA操作、文档处理、数据查询底座层信创适配层国产芯片/OS/数据库适配、安全合规这个架构里最值得关注的是调度层。市面上很多办公AI产品其实只有交互层和执行层缺了中间的调度层。没有调度层智能体就只能做单步任务比如帮我查一下今天的日程但没法做帮我安排下周的出差包括订票、酒店、日程同步和预算审批这种多步复合任务。MobileWork的调度层如果能稳定运行这是它跟普通办公AI最大的区别。2.3 跟钉钉飞书企业微信的本质差异很多人会把MobileWork跟钉钉、飞书放在一起比较但我觉得这个比较本身就不太对。钉钉飞书是协作平台核心价值在于连接人和信息MobileWork是执行平台核心价值在于连接目标和结果。打个比方钉钉飞书像是办公室里的白板和公告栏大家在上面写东西、看信息、互相沟通MobileWork更像是你雇了一个行政助理你告诉它要做什么它自己去跑腿、去协调、去完成。两者不是替代关系至少在短期内MobileWork更需要考虑的是怎么跟现有办公系统对接而不是怎么取代它们。当然中国移动做这件事有它独特的优势。运营商级别的政企客户资源、信创目录里的天然位置、以及遍布全国的交付服务体系这些都是互联网大厂不具备的。但劣势也很明显产品体验的打磨、开发者生态的构建、以及互联网化的迭代速度这些恰恰是运营商体系不太擅长的。所以MobileWork能不能成关键看它能不能在信创优势和产品体验之间找到平衡点。3. 智能体架构的技术底子有多硬3.1 任务规划引擎的工作原理智能体能不能真正智能核心看任务规划引擎。MobileWork在这块采用的是分层规划动态重规划的架构我拆开讲。当你输入一个复杂任务时系统首先会做意图识别和任务分解。比如帮我准备下周的客户拜访引擎会把它拆成查询客户信息→确认拜访时间→安排行程→准备拜访材料→同步给相关人员。这个拆解过程不是简单的关键词匹配而是基于大语言模型的语义理解加上预设的办公领域知识图谱。拆解完成后进入执行规划阶段。每个子任务会被映射到具体的工具或API上比如查询客户信息映射到CRM系统的查询接口安排行程映射到日历系统和差旅平台的接口。这里有个关键设计执行规划不是一次性的而是动态调整的。如果某个子任务执行失败比如CRM接口超时引擎会自动触发重规划尝试备用方案或者调整任务顺序。实操心得很多团队在做智能体规划时容易犯一个错误——把规划做得太死。一旦某个步骤失败整个任务就卡住了。MobileWork的动态重规划机制值得借鉴核心思路是给每个子任务设置失败处理策略而不是假设所有步骤都会成功。3.2 多智能体协作机制单个智能体的能力是有上限的。一个智能体既要懂HR流程又要懂财务报销还要懂项目管理这不现实。MobileWork的解法是多智能体协作系统里预置了多个垂直领域的智能体比如HR智能体、财务智能体、IT运维智能体、行政智能体等由一个调度智能体根据任务类型进行路由和协调。这个机制的技术难点在于智能体之间的通信协议。不同智能体可能由不同团队开发用的框架、接口、数据格式都不一样。MobileWork定义了一套内部的智能体通信标准包括任务描述格式、状态同步机制、结果返回规范等。这套标准目前没有对外开放但从内测反馈来看它的设计思路跟业界主流的Agent通信协议如MCP有相似之处。多智能体协作的另一个难点是冲突解决。比如一个任务同时涉及财务和法务两个智能体给出的方案有冲突怎么办MobileWork的做法是引入仲裁机制当检测到冲突时调度智能体会根据预设的优先级规则比如合规优先于效率进行裁决必要时升级到人工确认。3.3 工具调用与API集成方案智能体再聪明如果调不动实际的系统那也只是个聊天机器人。MobileWork在工具调用这块下了不少功夫核心是三层集成方案第一层是原生API集成。对于主流的办公系统如OA、CRM、ERPMobileWork提供了预置的连接器配置好认证信息就能直接用。这部分覆盖了大多数标准化场景。第二层是RPA模拟操作。对于那些没有开放API的老系统MobileWork集成了RPA能力通过模拟鼠标键盘操作来完成跨系统任务。这部分的稳定性不如API调用但在信创环境下很多老系统的改造周期很长RPA是一个务实的过渡方案。第三层是自定义工具注册。企业如果有自研系统可以通过MobileWork提供的SDK注册自定义工具让智能体能够调用。这部分目前还在完善中文档和示例代码的丰富度有待提升。集成方式适用场景稳定性开发成本原生API主流办公系统高低RPA模拟无API的老系统中中自定义SDK企业自研系统高高4. 信创这张牌到底怎么打4.1 信创适配的完整技术栈信创是MobileWork最核心的差异化优势但信创适配这四个字说起来简单做起来是一整套技术栈的替换。从底层芯片到上层应用每一层都要重新适配和验证。MobileWork目前的信创适配覆盖了以下几个层面芯片层支持鲲鹏、飞腾、龙芯等国产处理器架构操作系统层适配麒麟、统信UOS等国产OS数据库层支持达梦、人大金仓、OceanBase等国产数据库中间件层适配东方通、金蝶天燕等国产中间件应用层与WPS、金山办公等国产办公套件深度集成这个适配清单看起来很长但实际落地时企业通常只需要关注跟自己现有环境匹配的部分。比如一个已经完成信创改造的政府单位它的底层环境是鲲鹏麒麟达梦那MobileWork只需要确保在这套组合上能稳定运行即可。4.2 信创环境下的性能优化实践信创环境跟传统的x86Windows环境相比性能表现确实有差距。我在实际测试中观察到同样的智能体任务在信创环境下的响应时间大约是传统环境的1.5到2倍。这个差距主要来自几个方面国产芯片的单核性能、国产数据库的查询优化、以及国产OS的调度效率。MobileWork在这块做了一些针对性的优化我挑几个有参考价值的讲模型推理的量化压缩。办公智能体需要本地部署大模型但信创服务器的算力有限。MobileWork采用了INT8量化加上层剪枝的方案把模型体积压缩到原来的四分之一左右推理速度提升了约40%。代价是精度有轻微下降但在办公场景下主要是文本理解和生成这个损失基本感知不到。数据库查询的缓存策略。国产数据库在复杂查询上的性能不如成熟的商业数据库MobileWork的做法是在应用层加了一层查询缓存把常用的组织架构、权限、流程定义等数据缓存在内存里减少对数据库的直接查询。这个策略的效果很明显实测下来高频操作的响应时间降低了60%以上。异步任务队列。智能体的很多任务是耗时的比如批量数据处理、文档生成MobileWork把这些任务放到异步队列里执行前端只返回任务ID用户可以通过消息通知获取结果。这样避免了长时间等待导致的超时问题。注意信创适配不是一次性的工作。国产芯片和OS的版本迭代很快每次底层环境升级都可能需要重新验证。建议在项目规划时预留至少20%的时间用于适配和回归测试。4.3 安全合规层面的设计考量信创场景对安全的要求比普通企业办公高得多。MobileWork在安全设计上做了几件事数据不出域。所有智能体的推理和执行都在企业内网完成不依赖外部云服务。这对于政府、金融、能源等敏感行业是硬性要求。权限最小化。每个智能体只能访问它被授权的系统和数据。比如HR智能体只能查人事数据不能碰财务数据。权限的粒度可以细到字段级别。操作全审计。智能体的每一步操作都有日志记录包括调用了什么接口、传了什么参数、返回了什么结果。这些日志不可篡改支持事后追溯。模型安全。本地部署的模型经过了安全对齐训练避免生成不当内容。同时输入输出都有敏感词过滤和内容审核机制。5. 实际落地怎么操作5.1 从零搭建一个办公智能体的完整流程假设你是一家已经完成信创改造的企业想用MobileWork搭建一个报销审批智能体下面是完整的操作流程。第一步环境准备。确认你的服务器满足最低配置要求。根据我的实测跑一个中等规模的办公智能体建议配置不低于16核CPU、64GB内存、500GB SSD、以及一块支持FP16推理的国产加速卡。操作系统需要是麒麟V10 SP3或统信UOS 20以上版本。第二步部署MobileWork服务端。从官方渠道获取安装包后按照部署文档执行安装脚本。这里有个坑要注意安装脚本默认使用PostgreSQL如果你用的是达梦数据库需要先手动创建数据库实例和用户然后在配置文件中修改连接串。达梦的JDBC驱动需要单独下载并放到指定目录。# 以达梦数据库为例的配置修改 # 编辑 config/database.yml database: driver: dm url: jdbc:dm://127.0.0.1:5236/MOBILEWORK username: MOBILEWORK_USER password: your_password pool_size: 20第三步配置智能体。登录管理后台进入智能体管理页面点击新建智能体。你需要填写几个关键信息智能体名称、描述、绑定的模型、可调用的工具列表、以及权限范围。对于报销审批智能体工具列表至少需要包含员工信息查询接口、报销单查询接口、审批流发起接口、以及通知发送接口。权限范围设置为仅限财务系统只读审批流写入。第四步编写提示词和流程定义。这是最考验功力的部分。提示词需要清晰定义智能体的角色、能力边界、以及处理逻辑。比如你是一个报销审批智能体。你的职责是 1. 接收员工提交的报销申请 2. 自动核对报销金额是否超出该员工的权限额度 3. 检查发票信息是否完整发票号、金额、日期 4. 如果一切正常自动发起审批流 5. 如果有异常生成异常报告并通知申请人 注意单笔报销超过5000元必须转人工审批不得自动通过。第五步测试和调优。在正式上线前用测试数据跑一遍完整流程。重点关注几个指标任务完成率、平均响应时间、异常处理是否正确。我建议至少跑50个测试用例覆盖正常流程、边界情况、以及异常场景。5.2 智能体开发中的关键参数配置在MobileWork上开发智能体有几个参数直接决定了运行效果我逐个解释。温度值Temperature。这个参数控制模型输出的随机性。办公场景建议设置在0.1到0.3之间。太高了会导致输出不稳定同样的输入可能得到不同的结果太低了又会让智能体过于死板遇到稍微变化的情况就不知道怎么处理。我的经验值是0.2在稳定性和灵活性之间比较平衡。最大Token数。这个决定了智能体单次输出的长度上限。办公场景下大部分任务的输出不会超过2000个Token。设置太高会浪费算力设置太低又可能导致输出被截断。建议根据具体任务类型调整简单查询类设为500文档生成类设为4000复杂规划类设为2000。超时时间。智能体调用外部工具时的等待时间。信创环境下API响应可能比传统环境慢建议把超时时间设置得宽松一些。我的配置是查询类接口30秒写入类接口60秒批量处理类接口300秒。重试策略。当工具调用失败时智能体应该重试几次建议设置为2到3次每次间隔递增比如第一次等1秒第二次等3秒第三次等9秒。超过3次还失败就应该触发降级方案或者转人工处理。参数建议值说明Temperature0.2平衡稳定性和灵活性最大Token500-4000根据任务类型调整超时时间30-300秒信创环境适当放宽重试次数2-3次递增间隔5.3 跟现有办公系统的对接实操大部分企业不会把MobileWork当作唯一的办公系统而是让它跟现有的OA、ERP、CRM等系统协同工作。对接的质量直接决定了智能体能不能真正干活。对接的第一步是梳理现有系统的接口清单。把每个系统的可用API列出来标注清楚接口地址、认证方式、请求参数、返回格式、调用频率限制。这个清单越详细后续的对接就越顺利。第二步是设计数据映射关系。不同系统的数据格式不一样比如OA系统里员工ID是工号CRM系统里是邮箱前缀需要建立映射表。这个映射表建议放在MobileWork的配置中心统一管理方便维护。第三步是处理认证和授权。MobileWork需要以某种身份访问各个业务系统。推荐的做法是为MobileWork创建一个专用的服务账号给它分配最小必要的权限。不要直接用管理员的账号否则一旦出问题影响面太大。第四步是联调测试。对接完成后需要做端到端的联调。重点测试跨系统任务能否正确执行、异常情况能否正确处理、数据一致性有没有问题。我建议至少做三轮联调第一轮用测试数据第二轮用部分真实数据第三轮全量真实数据但只读不写。实操心得对接过程中最常见的坑是接口文档跟实际行为不一致。文档说返回JSON实际返回的是XML文档说字段名是userName实际是user_name。建议在对接前先用Postman之类的工具把每个接口都手动调一遍确认实际行为跟文档一致。6. 跟竞品比到底有没有优势6.1 跟钉钉AI、飞书智能伙伴的横向对比把MobileWork跟钉钉AI和飞书智能伙伴放在一起比能看出明显的定位差异。维度MobileWork钉钉AI飞书智能伙伴核心定位智能体执行平台协作平台AI助手协作平台AI助手信创适配完整支持部分支持部分支持多智能体协作原生支持有限支持有限支持私有化部署支持有限支持有限支持生态开放度中等高高产品成熟度早期成熟成熟从表格能看出来MobileWork的优势集中在信创适配、多智能体协作、私有化部署这三个点上。这三个点恰好是政府、金融、能源等行业的刚需。而钉钉和飞书的优势在于产品成熟度和生态开放度它们的AI功能虽然也在快速迭代但在信创场景下的适配深度确实不如MobileWork。6.2 在信创办公场景下的独特优势信创办公场景有几个特殊需求是通用办公平台很难满足的全栈国产化。从芯片到应用全部国产这是信创的硬性要求。钉钉和飞书虽然也在做信创适配但它们的底层架构还是基于互联网云服务设计的在纯内网环境下的功能完整性会打折扣。MobileWork从设计之初就是为私有化部署考虑的这方面有天然优势。数据不出域。政府单位的很多数据是敏感数据不能出内网。MobileWork的本地推理和本地执行架构天然满足这个要求。与信创目录产品的预集成。MobileWork已经跟多家信创目录内的产品完成了预集成比如WPS、金山文档、达梦数据库等。企业采购后可以直接用不需要额外做适配开发。符合信创安全标准。MobileWork通过了信创安全相关的认证在等保测评、密码应用安全性评估等方面有现成的合规材料能帮企业省不少事。6.3 目前存在的短板和局限说了这么多优势也得客观讲讲短板。产品体验还有差距。跟钉钉飞书比MobileWork的界面交互、响应速度、功能细节都有提升空间。这跟运营商体系的产品迭代节奏有关不是短期内能追上的。开发者生态薄弱。钉钉和飞书有大量的ISV和开发者能快速丰富应用生态。MobileWork目前的开发者社区还很小自定义智能体的开发门槛偏高文档和示例也不够丰富。智能体的实际能力边界。虽然宣传上说是智能体但实际测试中复杂任务的完成率还有待提升。特别是涉及多个系统、多个步骤的任务偶尔会出现规划错误或者执行中断。这跟底层模型的能力有关也跟工具调用的稳定性有关。价格体系不透明。目前MobileWork的定价策略还不清晰不同规模、不同部署方式的报价差异很大。对于预算敏感的中小企业来说这是个决策障碍。7. 踩过的坑和实战经验7.1 智能体开发中最容易犯的五个错误我在帮几个客户落地MobileWork的过程中总结了一些高频错误列出来供参考。错误一提示词写得太满。很多人写提示词恨不得把所有的规则都塞进去结果模型反而抓不住重点。正确的做法是分层写先定义角色和核心职责再写关键规则最后补充边界情况。规则不要超过10条太多了模型记不住。错误二工具描述太简略。智能体调用工具时是靠工具的描述来决定用哪个工具的。如果描述写得太简单比如查询数据智能体根本不知道这个工具是查什么数据的。工具描述要写清楚这个工具是干什么的、什么时候用、输入什么、输出什么。错误三忽略异常处理。很多开发者在测试时只测正常流程上线后一遇到异常就崩。建议在开发阶段就考虑好接口超时怎么办、返回数据格式不对怎么办、权限不足怎么办。每个异常都要有对应的处理策略。错误四权限给得太大。为了方便直接给智能体开了管理员权限。这是安全隐患。正确的做法是遵循最小权限原则智能体只需要它能完成任务的权限多余的权限一个都不要给。错误五不做版本管理。智能体的提示词、工具配置、流程定义都是会迭代的。如果不做版本管理改出问题了想回滚都回不去。建议用Git管理智能体的配置文件每次修改都提交记录。7.2 信创环境部署的避坑指南信创环境部署跟传统环境有几个明显的不同我踩过的坑列一下。坑一国产OS的默认配置太保守。麒麟和统信UOS的默认文件句柄数、网络连接数都比较小跑智能体服务容易遇到too many open files的错误。部署前记得调整系统参数# 修改 /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535坑二国产数据库的驱动版本要匹配。达梦、人大金仓的JDBC驱动版本跟数据库版本有严格的对应关系版本不匹配会出现各种奇怪的连接问题。部署前务必确认驱动版本跟数据库版本一致。坑三国产芯片的指令集差异。鲲鹏是ARM架构飞腾也是ARM但具体指令集有差异。如果用了预编译的二进制包要确认它是针对哪种架构编译的。最稳妥的方式是在目标环境上从源码编译。坑四信创环境的网络策略更严格。很多信创环境是纯内网没有外网访问。部署时需要提前准备好所有的依赖包不能指望部署脚本自动下载。建议在联网环境先做一次完整的依赖收集把需要的包全部下载到本地。7.3 性能调优的实战技巧智能体跑起来之后性能调优是个持续的工作。分享几个我实测有效的技巧。模型推理的批处理。如果多个智能体同时处理任务可以把推理请求攒批处理提高GPU利用率。实测下来批大小为8的时候吞吐量比单条推理提升了约3倍。工具调用的并行化。如果一个任务需要调用多个互不依赖的工具可以让它们并行执行。比如查询员工信息和查询报销记录可以同时进行不需要串行等待。MobileWork的调度引擎支持这种并行调用但需要在流程定义时显式声明。缓存的合理使用。组织架构、权限配置、流程定义这些变化不频繁的数据可以缓存在内存里。但要注意缓存失效策略数据更新后要及时刷新缓存否则会出现权限不一致的问题。日志的异步写入。智能体的操作日志量很大如果同步写入磁盘会影响性能。建议用异步队列缓冲日志批量写入。同时要注意日志的滚动策略避免磁盘被写满。8. 这个方向后续还能怎么走办公智能体这个赛道目前还处于非常早期的阶段。MobileWork作为中国移动在这个方向的布局有它的独特优势也有明显的短板。从我个人跟进的几个项目来看它在信创场景下的落地效果是能打的特别是在政府、国企这类对信创有硬性要求的客户群里竞争力比较明显。但如果你问我它能不能抢下这座山头我的判断是它抢的不是钉钉飞书的山头而是一个新的山头。办公智能体的市场足够大大到可以容纳多个玩家。MobileWork如果能守住信创这个基本盘同时把产品体验和开发者生态补上来它有机会成为这个新赛道里的重要一极。对于正在评估办公智能体的企业我的建议是如果你的核心诉求是信创合规和私有化部署MobileWork值得认真考虑如果你更看重产品体验和生态丰富度可以再观望一段时间看看它的迭代速度。对于开发者来说现在入场学习智能体开发是个不错的时机这个方向的人才缺口还很大早积累早受益。最后分享一个我在实际项目中验证过的小技巧部署智能体之前先用一个最小化的场景做验证比如会议室预订这种流程简单、涉及系统少的任务。跑通了再逐步扩展到复杂场景。不要一上来就搞大而全的方案那样出问题了很难定位是哪个环节的毛病。
1. 办公智能体赛道突然挤进一个国家队办公协同这个赛道过去十年基本是互联网大厂的天下。钉钉、飞书、企业微信三家把持着绝大多数企业的日常办公入口后来者想切进去难度不亚于在已经浇好水泥的地面上重新种树。但2024年下半年开始一个明显的变化出现了中国移动带着MobileWork这个产品直接杀进了办公智能体领域。这不是小打小闹的试水而是带着信创这张底牌、带着运营商级别的资源投入进来的。我最早注意到MobileWork是在几个做企业信息化的群里看到有人转发它的内测截图。第一反应是又一个办公IM但仔细看完产品结构之后发现它的定位跟钉钉、飞书完全不在一个维度上。MobileWork的核心不是聊天、不是审批流、不是视频会议而是智能体AI Agent驱动的办公自动化。换句话说它想做的不是另一个办公平台而是办公场景里的智能体调度中枢。这件事为什么值得认真聊因为办公智能体这个方向目前市面上真正跑通的产品并不多。大部分所谓的AI办公本质上还是在传统办公软件上挂了一个对话框你问它答仅此而已。而智能体的核心在于自主规划、工具调用、多步执行——它能自己拆解任务、自己调用API、自己完成一整套流程而不是等你一步步下指令。MobileWork如果真能把这件事在信创环境下跑通那它抢的就不是钉钉飞书的饭碗而是一个全新的生态位。这篇文章适合谁看如果你是企业IT负责人正在评估信创办公方案那MobileWork值得你花时间研究如果你是智能体开发者想知道大厂在办公场景怎么落地Agent架构这里有一手的架构思路如果你只是对办公智能体这个概念感兴趣想搞清楚它跟普通AI助手的区别我也会用最直白的方式讲清楚。下面我从产品定位、技术架构、信创适配、实操落地、竞品对比几个维度把这件事拆开聊透。2. MobileWork到底是个什么东西2.1 从产品定位看它想解决什么问题先说结论MobileWork不是钉钉的替代品至少现阶段不是。它的产品逻辑更接近办公场景的智能体操作系统。传统办公软件解决的是人和人怎么协作MobileWork想解决的是人和智能体、智能体和智能体之间怎么协作。举个具体场景你就明白了。假设你是一个项目经理需要完成一份季度总结报告。在钉钉里你的操作路径是打开文档→手动整理数据→写内容→发给领导审阅→根据反馈修改。在MobileWork的逻辑里你只需要说一句帮我生成本季度项目总结数据从项目管理系统的API拉取格式参照上季度模板完成后发给张总审批。剩下的拆解任务、调用数据接口、套用模板、发起审批流全部由背后的智能体自动完成。这个差异的本质在于传统办公软件是工具MobileWork想做的是执行者。工具需要你操作执行者只需要你下目标。这也是为什么它叫办公智能体而不是智能办公助手——助手还是被动响应智能体是主动执行。2.2 核心功能模块拆解从目前公开的信息和内测反馈来看MobileWork的功能架构大致分为四层层级功能模块核心能力交互层统一入口自然语言对话、多模态输入、任务下发调度层智能体编排引擎任务拆解、智能体路由、多智能体协作执行层工具调用框架API调用、RPA操作、文档处理、数据查询底座层信创适配层国产芯片/OS/数据库适配、安全合规这个架构里最值得关注的是调度层。市面上很多办公AI产品其实只有交互层和执行层缺了中间的调度层。没有调度层智能体就只能做单步任务比如帮我查一下今天的日程但没法做帮我安排下周的出差包括订票、酒店、日程同步和预算审批这种多步复合任务。MobileWork的调度层如果能稳定运行这是它跟普通办公AI最大的区别。2.3 跟钉钉飞书企业微信的本质差异很多人会把MobileWork跟钉钉、飞书放在一起比较但我觉得这个比较本身就不太对。钉钉飞书是协作平台核心价值在于连接人和信息MobileWork是执行平台核心价值在于连接目标和结果。打个比方钉钉飞书像是办公室里的白板和公告栏大家在上面写东西、看信息、互相沟通MobileWork更像是你雇了一个行政助理你告诉它要做什么它自己去跑腿、去协调、去完成。两者不是替代关系至少在短期内MobileWork更需要考虑的是怎么跟现有办公系统对接而不是怎么取代它们。当然中国移动做这件事有它独特的优势。运营商级别的政企客户资源、信创目录里的天然位置、以及遍布全国的交付服务体系这些都是互联网大厂不具备的。但劣势也很明显产品体验的打磨、开发者生态的构建、以及互联网化的迭代速度这些恰恰是运营商体系不太擅长的。所以MobileWork能不能成关键看它能不能在信创优势和产品体验之间找到平衡点。3. 智能体架构的技术底子有多硬3.1 任务规划引擎的工作原理智能体能不能真正智能核心看任务规划引擎。MobileWork在这块采用的是分层规划动态重规划的架构我拆开讲。当你输入一个复杂任务时系统首先会做意图识别和任务分解。比如帮我准备下周的客户拜访引擎会把它拆成查询客户信息→确认拜访时间→安排行程→准备拜访材料→同步给相关人员。这个拆解过程不是简单的关键词匹配而是基于大语言模型的语义理解加上预设的办公领域知识图谱。拆解完成后进入执行规划阶段。每个子任务会被映射到具体的工具或API上比如查询客户信息映射到CRM系统的查询接口安排行程映射到日历系统和差旅平台的接口。这里有个关键设计执行规划不是一次性的而是动态调整的。如果某个子任务执行失败比如CRM接口超时引擎会自动触发重规划尝试备用方案或者调整任务顺序。实操心得很多团队在做智能体规划时容易犯一个错误——把规划做得太死。一旦某个步骤失败整个任务就卡住了。MobileWork的动态重规划机制值得借鉴核心思路是给每个子任务设置失败处理策略而不是假设所有步骤都会成功。3.2 多智能体协作机制单个智能体的能力是有上限的。一个智能体既要懂HR流程又要懂财务报销还要懂项目管理这不现实。MobileWork的解法是多智能体协作系统里预置了多个垂直领域的智能体比如HR智能体、财务智能体、IT运维智能体、行政智能体等由一个调度智能体根据任务类型进行路由和协调。这个机制的技术难点在于智能体之间的通信协议。不同智能体可能由不同团队开发用的框架、接口、数据格式都不一样。MobileWork定义了一套内部的智能体通信标准包括任务描述格式、状态同步机制、结果返回规范等。这套标准目前没有对外开放但从内测反馈来看它的设计思路跟业界主流的Agent通信协议如MCP有相似之处。多智能体协作的另一个难点是冲突解决。比如一个任务同时涉及财务和法务两个智能体给出的方案有冲突怎么办MobileWork的做法是引入仲裁机制当检测到冲突时调度智能体会根据预设的优先级规则比如合规优先于效率进行裁决必要时升级到人工确认。3.3 工具调用与API集成方案智能体再聪明如果调不动实际的系统那也只是个聊天机器人。MobileWork在工具调用这块下了不少功夫核心是三层集成方案第一层是原生API集成。对于主流的办公系统如OA、CRM、ERPMobileWork提供了预置的连接器配置好认证信息就能直接用。这部分覆盖了大多数标准化场景。第二层是RPA模拟操作。对于那些没有开放API的老系统MobileWork集成了RPA能力通过模拟鼠标键盘操作来完成跨系统任务。这部分的稳定性不如API调用但在信创环境下很多老系统的改造周期很长RPA是一个务实的过渡方案。第三层是自定义工具注册。企业如果有自研系统可以通过MobileWork提供的SDK注册自定义工具让智能体能够调用。这部分目前还在完善中文档和示例代码的丰富度有待提升。集成方式适用场景稳定性开发成本原生API主流办公系统高低RPA模拟无API的老系统中中自定义SDK企业自研系统高高4. 信创这张牌到底怎么打4.1 信创适配的完整技术栈信创是MobileWork最核心的差异化优势但信创适配这四个字说起来简单做起来是一整套技术栈的替换。从底层芯片到上层应用每一层都要重新适配和验证。MobileWork目前的信创适配覆盖了以下几个层面芯片层支持鲲鹏、飞腾、龙芯等国产处理器架构操作系统层适配麒麟、统信UOS等国产OS数据库层支持达梦、人大金仓、OceanBase等国产数据库中间件层适配东方通、金蝶天燕等国产中间件应用层与WPS、金山办公等国产办公套件深度集成这个适配清单看起来很长但实际落地时企业通常只需要关注跟自己现有环境匹配的部分。比如一个已经完成信创改造的政府单位它的底层环境是鲲鹏麒麟达梦那MobileWork只需要确保在这套组合上能稳定运行即可。4.2 信创环境下的性能优化实践信创环境跟传统的x86Windows环境相比性能表现确实有差距。我在实际测试中观察到同样的智能体任务在信创环境下的响应时间大约是传统环境的1.5到2倍。这个差距主要来自几个方面国产芯片的单核性能、国产数据库的查询优化、以及国产OS的调度效率。MobileWork在这块做了一些针对性的优化我挑几个有参考价值的讲模型推理的量化压缩。办公智能体需要本地部署大模型但信创服务器的算力有限。MobileWork采用了INT8量化加上层剪枝的方案把模型体积压缩到原来的四分之一左右推理速度提升了约40%。代价是精度有轻微下降但在办公场景下主要是文本理解和生成这个损失基本感知不到。数据库查询的缓存策略。国产数据库在复杂查询上的性能不如成熟的商业数据库MobileWork的做法是在应用层加了一层查询缓存把常用的组织架构、权限、流程定义等数据缓存在内存里减少对数据库的直接查询。这个策略的效果很明显实测下来高频操作的响应时间降低了60%以上。异步任务队列。智能体的很多任务是耗时的比如批量数据处理、文档生成MobileWork把这些任务放到异步队列里执行前端只返回任务ID用户可以通过消息通知获取结果。这样避免了长时间等待导致的超时问题。注意信创适配不是一次性的工作。国产芯片和OS的版本迭代很快每次底层环境升级都可能需要重新验证。建议在项目规划时预留至少20%的时间用于适配和回归测试。4.3 安全合规层面的设计考量信创场景对安全的要求比普通企业办公高得多。MobileWork在安全设计上做了几件事数据不出域。所有智能体的推理和执行都在企业内网完成不依赖外部云服务。这对于政府、金融、能源等敏感行业是硬性要求。权限最小化。每个智能体只能访问它被授权的系统和数据。比如HR智能体只能查人事数据不能碰财务数据。权限的粒度可以细到字段级别。操作全审计。智能体的每一步操作都有日志记录包括调用了什么接口、传了什么参数、返回了什么结果。这些日志不可篡改支持事后追溯。模型安全。本地部署的模型经过了安全对齐训练避免生成不当内容。同时输入输出都有敏感词过滤和内容审核机制。5. 实际落地怎么操作5.1 从零搭建一个办公智能体的完整流程假设你是一家已经完成信创改造的企业想用MobileWork搭建一个报销审批智能体下面是完整的操作流程。第一步环境准备。确认你的服务器满足最低配置要求。根据我的实测跑一个中等规模的办公智能体建议配置不低于16核CPU、64GB内存、500GB SSD、以及一块支持FP16推理的国产加速卡。操作系统需要是麒麟V10 SP3或统信UOS 20以上版本。第二步部署MobileWork服务端。从官方渠道获取安装包后按照部署文档执行安装脚本。这里有个坑要注意安装脚本默认使用PostgreSQL如果你用的是达梦数据库需要先手动创建数据库实例和用户然后在配置文件中修改连接串。达梦的JDBC驱动需要单独下载并放到指定目录。# 以达梦数据库为例的配置修改 # 编辑 config/database.yml database: driver: dm url: jdbc:dm://127.0.0.1:5236/MOBILEWORK username: MOBILEWORK_USER password: your_password pool_size: 20第三步配置智能体。登录管理后台进入智能体管理页面点击新建智能体。你需要填写几个关键信息智能体名称、描述、绑定的模型、可调用的工具列表、以及权限范围。对于报销审批智能体工具列表至少需要包含员工信息查询接口、报销单查询接口、审批流发起接口、以及通知发送接口。权限范围设置为仅限财务系统只读审批流写入。第四步编写提示词和流程定义。这是最考验功力的部分。提示词需要清晰定义智能体的角色、能力边界、以及处理逻辑。比如你是一个报销审批智能体。你的职责是 1. 接收员工提交的报销申请 2. 自动核对报销金额是否超出该员工的权限额度 3. 检查发票信息是否完整发票号、金额、日期 4. 如果一切正常自动发起审批流 5. 如果有异常生成异常报告并通知申请人 注意单笔报销超过5000元必须转人工审批不得自动通过。第五步测试和调优。在正式上线前用测试数据跑一遍完整流程。重点关注几个指标任务完成率、平均响应时间、异常处理是否正确。我建议至少跑50个测试用例覆盖正常流程、边界情况、以及异常场景。5.2 智能体开发中的关键参数配置在MobileWork上开发智能体有几个参数直接决定了运行效果我逐个解释。温度值Temperature。这个参数控制模型输出的随机性。办公场景建议设置在0.1到0.3之间。太高了会导致输出不稳定同样的输入可能得到不同的结果太低了又会让智能体过于死板遇到稍微变化的情况就不知道怎么处理。我的经验值是0.2在稳定性和灵活性之间比较平衡。最大Token数。这个决定了智能体单次输出的长度上限。办公场景下大部分任务的输出不会超过2000个Token。设置太高会浪费算力设置太低又可能导致输出被截断。建议根据具体任务类型调整简单查询类设为500文档生成类设为4000复杂规划类设为2000。超时时间。智能体调用外部工具时的等待时间。信创环境下API响应可能比传统环境慢建议把超时时间设置得宽松一些。我的配置是查询类接口30秒写入类接口60秒批量处理类接口300秒。重试策略。当工具调用失败时智能体应该重试几次建议设置为2到3次每次间隔递增比如第一次等1秒第二次等3秒第三次等9秒。超过3次还失败就应该触发降级方案或者转人工处理。参数建议值说明Temperature0.2平衡稳定性和灵活性最大Token500-4000根据任务类型调整超时时间30-300秒信创环境适当放宽重试次数2-3次递增间隔5.3 跟现有办公系统的对接实操大部分企业不会把MobileWork当作唯一的办公系统而是让它跟现有的OA、ERP、CRM等系统协同工作。对接的质量直接决定了智能体能不能真正干活。对接的第一步是梳理现有系统的接口清单。把每个系统的可用API列出来标注清楚接口地址、认证方式、请求参数、返回格式、调用频率限制。这个清单越详细后续的对接就越顺利。第二步是设计数据映射关系。不同系统的数据格式不一样比如OA系统里员工ID是工号CRM系统里是邮箱前缀需要建立映射表。这个映射表建议放在MobileWork的配置中心统一管理方便维护。第三步是处理认证和授权。MobileWork需要以某种身份访问各个业务系统。推荐的做法是为MobileWork创建一个专用的服务账号给它分配最小必要的权限。不要直接用管理员的账号否则一旦出问题影响面太大。第四步是联调测试。对接完成后需要做端到端的联调。重点测试跨系统任务能否正确执行、异常情况能否正确处理、数据一致性有没有问题。我建议至少做三轮联调第一轮用测试数据第二轮用部分真实数据第三轮全量真实数据但只读不写。实操心得对接过程中最常见的坑是接口文档跟实际行为不一致。文档说返回JSON实际返回的是XML文档说字段名是userName实际是user_name。建议在对接前先用Postman之类的工具把每个接口都手动调一遍确认实际行为跟文档一致。6. 跟竞品比到底有没有优势6.1 跟钉钉AI、飞书智能伙伴的横向对比把MobileWork跟钉钉AI和飞书智能伙伴放在一起比能看出明显的定位差异。维度MobileWork钉钉AI飞书智能伙伴核心定位智能体执行平台协作平台AI助手协作平台AI助手信创适配完整支持部分支持部分支持多智能体协作原生支持有限支持有限支持私有化部署支持有限支持有限支持生态开放度中等高高产品成熟度早期成熟成熟从表格能看出来MobileWork的优势集中在信创适配、多智能体协作、私有化部署这三个点上。这三个点恰好是政府、金融、能源等行业的刚需。而钉钉和飞书的优势在于产品成熟度和生态开放度它们的AI功能虽然也在快速迭代但在信创场景下的适配深度确实不如MobileWork。6.2 在信创办公场景下的独特优势信创办公场景有几个特殊需求是通用办公平台很难满足的全栈国产化。从芯片到应用全部国产这是信创的硬性要求。钉钉和飞书虽然也在做信创适配但它们的底层架构还是基于互联网云服务设计的在纯内网环境下的功能完整性会打折扣。MobileWork从设计之初就是为私有化部署考虑的这方面有天然优势。数据不出域。政府单位的很多数据是敏感数据不能出内网。MobileWork的本地推理和本地执行架构天然满足这个要求。与信创目录产品的预集成。MobileWork已经跟多家信创目录内的产品完成了预集成比如WPS、金山文档、达梦数据库等。企业采购后可以直接用不需要额外做适配开发。符合信创安全标准。MobileWork通过了信创安全相关的认证在等保测评、密码应用安全性评估等方面有现成的合规材料能帮企业省不少事。6.3 目前存在的短板和局限说了这么多优势也得客观讲讲短板。产品体验还有差距。跟钉钉飞书比MobileWork的界面交互、响应速度、功能细节都有提升空间。这跟运营商体系的产品迭代节奏有关不是短期内能追上的。开发者生态薄弱。钉钉和飞书有大量的ISV和开发者能快速丰富应用生态。MobileWork目前的开发者社区还很小自定义智能体的开发门槛偏高文档和示例也不够丰富。智能体的实际能力边界。虽然宣传上说是智能体但实际测试中复杂任务的完成率还有待提升。特别是涉及多个系统、多个步骤的任务偶尔会出现规划错误或者执行中断。这跟底层模型的能力有关也跟工具调用的稳定性有关。价格体系不透明。目前MobileWork的定价策略还不清晰不同规模、不同部署方式的报价差异很大。对于预算敏感的中小企业来说这是个决策障碍。7. 踩过的坑和实战经验7.1 智能体开发中最容易犯的五个错误我在帮几个客户落地MobileWork的过程中总结了一些高频错误列出来供参考。错误一提示词写得太满。很多人写提示词恨不得把所有的规则都塞进去结果模型反而抓不住重点。正确的做法是分层写先定义角色和核心职责再写关键规则最后补充边界情况。规则不要超过10条太多了模型记不住。错误二工具描述太简略。智能体调用工具时是靠工具的描述来决定用哪个工具的。如果描述写得太简单比如查询数据智能体根本不知道这个工具是查什么数据的。工具描述要写清楚这个工具是干什么的、什么时候用、输入什么、输出什么。错误三忽略异常处理。很多开发者在测试时只测正常流程上线后一遇到异常就崩。建议在开发阶段就考虑好接口超时怎么办、返回数据格式不对怎么办、权限不足怎么办。每个异常都要有对应的处理策略。错误四权限给得太大。为了方便直接给智能体开了管理员权限。这是安全隐患。正确的做法是遵循最小权限原则智能体只需要它能完成任务的权限多余的权限一个都不要给。错误五不做版本管理。智能体的提示词、工具配置、流程定义都是会迭代的。如果不做版本管理改出问题了想回滚都回不去。建议用Git管理智能体的配置文件每次修改都提交记录。7.2 信创环境部署的避坑指南信创环境部署跟传统环境有几个明显的不同我踩过的坑列一下。坑一国产OS的默认配置太保守。麒麟和统信UOS的默认文件句柄数、网络连接数都比较小跑智能体服务容易遇到too many open files的错误。部署前记得调整系统参数# 修改 /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535坑二国产数据库的驱动版本要匹配。达梦、人大金仓的JDBC驱动版本跟数据库版本有严格的对应关系版本不匹配会出现各种奇怪的连接问题。部署前务必确认驱动版本跟数据库版本一致。坑三国产芯片的指令集差异。鲲鹏是ARM架构飞腾也是ARM但具体指令集有差异。如果用了预编译的二进制包要确认它是针对哪种架构编译的。最稳妥的方式是在目标环境上从源码编译。坑四信创环境的网络策略更严格。很多信创环境是纯内网没有外网访问。部署时需要提前准备好所有的依赖包不能指望部署脚本自动下载。建议在联网环境先做一次完整的依赖收集把需要的包全部下载到本地。7.3 性能调优的实战技巧智能体跑起来之后性能调优是个持续的工作。分享几个我实测有效的技巧。模型推理的批处理。如果多个智能体同时处理任务可以把推理请求攒批处理提高GPU利用率。实测下来批大小为8的时候吞吐量比单条推理提升了约3倍。工具调用的并行化。如果一个任务需要调用多个互不依赖的工具可以让它们并行执行。比如查询员工信息和查询报销记录可以同时进行不需要串行等待。MobileWork的调度引擎支持这种并行调用但需要在流程定义时显式声明。缓存的合理使用。组织架构、权限配置、流程定义这些变化不频繁的数据可以缓存在内存里。但要注意缓存失效策略数据更新后要及时刷新缓存否则会出现权限不一致的问题。日志的异步写入。智能体的操作日志量很大如果同步写入磁盘会影响性能。建议用异步队列缓冲日志批量写入。同时要注意日志的滚动策略避免磁盘被写满。8. 这个方向后续还能怎么走办公智能体这个赛道目前还处于非常早期的阶段。MobileWork作为中国移动在这个方向的布局有它的独特优势也有明显的短板。从我个人跟进的几个项目来看它在信创场景下的落地效果是能打的特别是在政府、国企这类对信创有硬性要求的客户群里竞争力比较明显。但如果你问我它能不能抢下这座山头我的判断是它抢的不是钉钉飞书的山头而是一个新的山头。办公智能体的市场足够大大到可以容纳多个玩家。MobileWork如果能守住信创这个基本盘同时把产品体验和开发者生态补上来它有机会成为这个新赛道里的重要一极。对于正在评估办公智能体的企业我的建议是如果你的核心诉求是信创合规和私有化部署MobileWork值得认真考虑如果你更看重产品体验和生态丰富度可以再观望一段时间看看它的迭代速度。对于开发者来说现在入场学习智能体开发是个不错的时机这个方向的人才缺口还很大早积累早受益。最后分享一个我在实际项目中验证过的小技巧部署智能体之前先用一个最小化的场景做验证比如会议室预订这种流程简单、涉及系统少的任务。跑通了再逐步扩展到复杂场景。不要一上来就搞大而全的方案那样出问题了很难定位是哪个环节的毛病。
