赵帅起

不少APP团队原来只维护iOS和安卓两套客户端，协作方式已经比较稳定，现在也需要开发鸿蒙客户端，加入以后，同一项需求开始需要三个团队来实现：三个团队分别做页面、接接口、处理登录和权限，再各自测试、构建和发布。 如果需求是会员查询、活动专区或售后办理，三端背后的业务流程通常没有太大区别。产品改一个字段，三个工程都要跟着修改；接口增加一种状态，三端分别补页面和异常处理；其中一端排期晚几天，功能就很难同时上线。团队表面上在维护三个客户端，很多时间却花在重复实现同一项业务。 小程序容器提供了一种全新的解决方案：iOS、安卓和鸿蒙仍然保留自己的宿主 APP，系统相关能力继续按平台建设；页面、路由、表单、接口调用和业务规则放进一套小程序工程，由三个客户端中的小程序运行时共同承载，大幅度降低二次开发的成本。 重复开发的主要是业务的频繁迭代 iOS、安卓和鸿蒙有各自的应用生命周期、权限模型、导航方式和工程工具。APP 启动、账号安全、消息、支付编排、系统权限以及设备能力，通常都要留在原生宿主中处理。三个客户端分别维护这些底层代码是合理的，因为它们直接连接操作系统，差异无法靠复制一份页面代码消

随着小程序生态的普及，很多团队都希望将H5升级为小程序，来承载APP内的业务和第三方的服务生态，前期很多团队的注意力都会先放在客户端：SDK要改多少代码，包体会增加多少，iOS、Android、鸿蒙能不能接，已有小程序能不能直接打开。 可一旦准备上线，问题就变了。开发人员发来两个代码包，一个叫“正式版”，另一个叫“正式版改”；测试人员手里还有一份上午验证过的版本。运营准备晚上八点发布，却没人能确认哪个包已经审核、哪个版本关联了生产 APP。上线后发现登录页有问题，团队又开始在群文件里找上一个稳定版本。活动临时结束，还要请客户端同事关闭入口，已经打开的小程序该怎么处理也没有约定。 客户端SDK没有出问题，只是它负责的范围到“加载和运行”就结束了。业务长期在线，还要管理小程序身份、代码版本、宿主范围、审核记录和发布状态。小程序只有一两个时，这些工作可以靠群消息和表格勉强维持；接入的团队和版本逐渐增多，管理平台就成了小程序容器架构中的另一半。 端侧运行和云端管理如何定位 小程序容器位于宿主APP内，负责代码包加载、页面渲染、生命周期、缓存、沙箱隔离，以及小程序与原生能力之间的交互。

其实现在很多团队都有自己的小程序，只是大部分还运行在微信上。不过新的项目需求出现时，业务团队往往会问：既然页面和功能已经做好了，能不能在自己的 APP 里继续使用？ 从技术角度来看，自有APP也能运行小程序，整体的思路就是：在APP内集成小程序容器，由容器提供代码加载、页面渲染、路由、生命周期和端能力调用等运行环境。原有微信小程序项目无需二次开发，只要有代码，就可以作为业务小程序运行在企业自己的APP中。 小程序代码、运行时与宿主APP的关系 小程序页面能够正常展示和交互，需要小程序代码、运行时与宿主 APP 共同工作。 小程序项目承载页面结构、样式、JavaScript 业务逻辑、组件和网络请求。业务功能如何展示、用户如何操作，大都由小程序项目中的代码决定。 小程序代码无法脱离运行时单独执行。页面创建、路由跳转、存储、网络、权限和原生端通信，都由运行时承接。微信已经把运行时集成在客户端里，因此用户和小程序开发者很少需要关注它的存在。 宿主 APP 提供小程序的运行入口。微信是一种宿主，企业自有 APP 也可以成为宿主。

随着APP流量进入存量竞争时代，现在的APP很少只承载自己开发的功能，今天分享一下如何在自有APP中如何进入第三方服务业态。现在主流的方式就是SDK嵌入、H5页面和小程序三种方式。 SDK 把第三方代码和依赖直接带进客户端工程； H5 主要把网页入口带进 APP，业务页面仍然运行在远程 Web 环境中； 小程序则把业务交付为独立代码包，由 APP 内的小程序容器加载和运行。 接入一个服务时，三种方式都可能很快。接入数量增加、合作关系持续变化以后，架构差异才会逐渐显现。 三种接入方式改变的是业务边界 评估第三方服务时，只比较页面效果并不够。一项完整服务通常包含前端页面、服务端接口、登录状态、设备能力、版本更新和异常处理。它还会不断变化：页面改版、接口升级、权限调整、活动结束，甚至服务方退出。 因此，选型真正要回答的是几个长期问题：第三方代码是否进入 APP 主工程，功能更新是否依赖客户端发版，服务能够调用哪些宿主能力，线上版本由谁控制，故障发生后能否只影响当前服务。 SDK、H5 和小程序没有固定的优劣顺序。它们分别适合不同的集成深度和运营周期。把边界看清楚，

今天分享一个政务 APP 移动门户建设项目，作为一个软件集成商，面对的往往是大量已经运行的系统和页面。很多东西从零开发其实并不难，但现实是：身份、事项中心、预约系统、办件查询和消息平台已经使用多年，多个委办局或业务单位还各自维护着微信小程序。甲方希望把常用服务收进自有 APP，同时保留原有建设投入。 按原生页面重新开发，技术上当然能够完成。但是每项服务都要重新整理页面、路由、登录、接口和异常流程，原来的小程序团队又要与 APP 主工程重新联调。服务数量上来后，主工程会快速吸收多个部门的业务代码，一次普通页面调整也要进入客户端版本计划。 除了软件开发本身，更麻烦的是还要解决多家供应商怎样同时接入，谁能提交代码包，谁负责审核，哪个版本正在线上运行，出现故障时怎样停止新的访问。 调研了几个方案后，最终采用了“稳定宿主+小程序容器+管理平台+现有业务系统”的组合。宿主 APP 管统一入口和端侧公共能力，已有小程序经过兼容检查和必要调整后进入自有 APP，小程序管理平台统一管理资产、版本和上下架。这样原有政务业务系统仍然处理预约、申报、查询和办件数据，

这两年，在内容层面最火的题材就是短剧了，红果APP借助短剧的优势，不到三年日活就已经过亿，而且吸引了一大批黏性极强的用户，而且培养了一大批短剧重视用户。那我们自己的APP是否可以像红果APP一样，通过短剧来提升APP的活跃度，增加流量变现的机会。 短剧内容并不难找到，市场上有大量制作方、版权方和运营机构，资源非常多，但难点出现在接入环节。每引入一家内容方，客户端都要重新开发频道页、剧集详情、播放器、账号连接和付费流程；合作方调整接口，APP 还要跟着发版。内容合作原本需要快速试验，落到原生工程里却变成了持续数周甚至更久的开发项目。 微信、抖音的小程序体系让第三方短剧服务能够按照统一规则进入平台。开发者按照小程序规范提交业务，平台提供运行环境、账号和支付等公共能力，同时负责准入、审核、分发和违规处置。短剧内容来自不同机构，用户看到的入口和使用体验仍然处在同一个平台中。 自有 APP 也可以采用类似的技术思路。在 APP 内集成小程序容器，为第三方短剧小程序提供统一运行环境，再建设一套小程序管理平台，管理内容方、代码版本、宿主关联、审核、灰度和上下架。宿主 APP 保留账号、

随着越来越多华为手机升级到 HarmonyOS 5 及以上的原生鸿蒙系统，也“纯血鸿蒙”，不少省市的政务APP已经开始推进鸿蒙原生适配。 接下来需要考虑的是如何快速完成业务的对接引入，如果预约、查询、申报、政策服务、便民工具都在鸿蒙端重新开发，团队需要重新排建设周期，页面、流程和接口也要再联调一遍。 等到 APP 上线，日常运营还会增加一条发布线。同一项服务调整办理材料或页面规则，相当于一个团队在同时维护iOS、安卓、鸿蒙、微信小程序多个终端，几个客户端分别修改、测试、审核，时间久了，版本差异很容易积累下来。 而且政务APP的变化又比较频繁。政策专区有明确的上线时间，预约服务会调整规则，阶段性活动到期后需要及时撤下，某个办事入口出现异常时还要快速止损。过去依赖原生 APP 发版的方式，在两个客户端上已经有不小的协调成本，再增加鸿蒙端，业务上线节奏会继续受客户端版本牵制。 今天分享一个技术方案，可以将已有的微信小程序项目，通过小程序容器融入到鸿蒙APP中。鸿蒙 APP 可以仍然采用原生方式建设宿主框架，小程序容器负责承载已有的业务页面，小程序管理平台统一管理各项业务的版本、发布范

很多APP的运营效率，卡住的地方并不在页面设计，也不在需求排期，而是在“功能已经做好，什么时候才能交到用户手里”。 一个新的会员活动准备周二上线，规则、页面和接口都已完成，但 APP 的下一个版本要到月底才能发布。临近上线，活动入口还要改一次；上线当天，合作方又临时调整了服务时间。业务团队只能继续找客户端团队改配置、重新测试，遇到涉及主包的内容，还得等待应用商店审核。 如果是项目早期，整体功能少，靠群消息、表格和人工确认也能维持。但是随着APP 里逐渐出现会员服务、营销活动、内容专区、问卷、内部工具以及第三方服务，情况会复杂很多：每项业务有不同负责人，上线时间不同，版本节奏不同，能开放的人群也不同。客户端发版通道很快就变成一条拥挤的单行道。 这时需要调整的不只是发布流程，还包括 APP 内业务功能的交付方式。把适合动态运营的功能从主工程中拆出来，以小程序承载，再通过小程序管理平台管理版本、审核、发布、灰度、上下架和运行状态，业务上线便可以从 APP 主包发版中相对独立出来。

现在一个业务同时覆盖 iOS、安卓、鸿蒙和 PC，已经不算少见。客户查询、内容专区、工单处理、员工服务这些功能，在四类客户端里做的事情差不多，背后连接的也是同一套业务系统，但开发时经常会落进四个工程：移动端各写一套，鸿蒙再做适配，PC 端重新处理窗口和键鼠交互。 一两个模块这样做还能推进。业务多起来以后，同步成本会慢慢显出来。后端调整一个字段，几个客户端都要修改；产品新增一个状态，每一端都要补页面、埋点和异常处理；其中一端排期稍晚，用户看到的功能就会不一致。看起来是在维护四个客户端，团队花掉的时间却有很大一部分是在重复同一项业务改动。 小程序多端框架解决的是这类重复建设。页面、路由、表单、接口调用和业务规则保留在一套小程序工程中，iOS、安卓、鸿蒙和 PC 客户端分别接入自己的小程序运行时。系统权限、窗口、进程和设备能力仍由各端处理，上层业务则围绕同一份代码继续迭代。 FinClip 的多端方案也沿着这个思路展开：客户端内集成小程序 SDK，后台管理小程序代码包和版本，各端在自己的运行环境中加载同一项业务。它减少的是业务页面和业务逻辑的重复开发，

其实现在很多团队都有自己的小程序，但这些小程序大部分都是运行在微信上的，今天分享一个新的技术解决方案：借助小程序容器的技术将这些小程序运行在自己的APP里。 特别是商城、预约、会员中心、业务查询，这些服务可能已经在微信里跑了几年，页面和接口都比较成熟，业务人员也已经习惯了小程序的开发和发布方式。 但等企业开始运营自己的APP，就需要看看，如何低成本的把这些服务搬迁到自有的APP中。 一种方案是：直接重写成原生页面，Android和iOS都要投入人力，测试、发版和后续维护也会多出两套工作。换成H5能少写一些界面，但原有小程序的组件、路由、分包和生命周期很难原样搬过来。更麻烦的是，微信小程序还要继续维护。一个需求改动，可能要同时照顾微信、APP原生和H5，业务越多，重复建设越明显。 那还有一个技术方案：在自己的APP里接入小程序容器，让APP先具备运行小程序的能力，再把已有微信小程序迁进来。原来的页面和业务逻辑能复用的继续复用，需要调整的地方集中处理，版本则交给小程序管理平台统一发布。 例如FinClip的小程序管理平台，宿主APP集成小程序运行时SDK，已有小程序代码上传到管理

到了2026年，国内各个行业的APP运营已经从增量市场变成了存量市场，很多APP的用户规模已经逐步稳定下来，从前期的野蛮生长到现在的精细化运行，运营团队也开始会希望加入更多内容和服务：资讯、直播、活动报名、会员权益、票务商城、本地生活、在线预约，甚至合作伙伴提供的专业工具。需求清单很快就能列出几十项，但企业很难把这些服务全部重新开发一遍。 其实不少合作方手里已经有现成的H5页面、微信小程序或原生SDK。单独接入一两个服务时，客户端团队可以逐项处理登录、页面跳转和权限申请，工作量还算可控。但随着接入数量增加后，每家合作方不同的技术栈和上线节奏都会影响宿主APP。一个页面调整可能要重新发版，某个服务出现故障时也缺少统一的关闭和回退手段。 今天方向一个基于小程序技术的解决方案：小程序容器技术可以先在APP内建立统一运行环境，再让第三方业务以小程序代码包的形式接入。例如FinClip 可以通过端侧小程序容器承载业务运行，通过云侧小程序管理平台管理开发者、小程序资产、版本、审核和分发。后续服务沿用同一条接入链路，宿主团队不必为每个合作方重复建设运行、连接和发布机制。 第三方服务如何放进自

很多公司原来只维护 iOS 和 Android 两套客户端，团队之间已经形成了比较稳定的协作方式。但随着要开发鸿蒙客户端之后，同一个需求开始出现三份排期：三端分别设计页面、接入接口、处理权限、联调测试，再各自构建和发布。 很多时候一项查询、预约或会员服务，业务流程没有变化，开发工作却被拆成三条线。产品改一个字段，三个工程都要跟进；某一端进度慢几天，功能就很难同步上线。等版本越来越多，团队还要长期处理页面差异、接口差异和历史版本兼容。 现在市面上有很多跨端开发的技术方案，但更偏向于从零开始构建APP的形式，对于存量APP来说：多端 APP 更实用的做法，是先把业务分层，再为每一层选择合适的技术。账号、安全、消息和系统能力保留在原生宿主；变化较慢、与 APP 生命周期绑定较深的页面，可以继续用原生或现有跨端框架；更新频繁、流程相对独立的业务，则可以通过小程序容器运行。混合架构的价值，也来自这些边界分清以后形成的长期分工。 三端开发中的重复成本 三端重复建设并不只发生在页面开发阶段。一个功能进入原生主工程后，通常会同时进入编译、测试和应用市场发布流程。

大部分APP在运行几年后，主包通常都会一点点变重，可能刚开始只是加一个会员中心，后来又陆续接入商城、客服、活动专区、办事工具和合作方服务。每个需求单独看都不算大，但经过几年之后，图片、组件、第三方依赖和初始化任务全都留在主工程里，安装包体积随之上涨。 包体变大还只是表面现象，更麻烦的是更新，可能一次普通的活动改版，业务侧可能只换了几张图片、调整了两处页面逻辑，客户端团队却要重新拉分支、合并代码、构建安装包、跑集成测试，再等待应用市场审核。改动只发生在一个短期活动里，发布流程却把整套 APP 都带了进来。 图片压缩、无用代码清理和原生模块化当然要做，但它们解决不了业务交付仍然绑在主包里的问题。资源压缩完，新业务还会继续加入；工程模块拆开了，发布时依然要打进同一个安装包。要让 APP 长期保持可维护，除了清理资源，还要重新划分业务的运行和发布边界。 接下来分享一个基于小程序容器的技术方案：是把更新频繁、流程相对完整的业务从主工程拆出，改成小程序代码包，通过小程序容器运行在 APP 内。 宿主 APP 留下稳定的客户端底座，业务团队维护各自的小程序，

过去一年，很多企业的AI落地已经从“要不要做”进入了“怎么管”的阶段。 最早跑起来的AI项目，通常不是总部统一规划出来的，而是从业务部门里长出来的。客服团队想缓解咨询压力，销售团队希望整理客户信息，财务团队尝试辅助单据核对，区域公司也会根据自己的业务节奏接入本地工具。站在部门视角，这些动作都合理，场景明确，反馈也快。 项目多起来以后，总部会遇到一个很现实的问题：每个部门都在做AI，企业整体反而更难管了。 这不是简单的“工具太多”。真正麻烦的是，AI开始进入数据访问、工具调用和业务执行链路以后，会把原来隐藏在组织里的权限问题和系统烟囱问题重新放大。部门试点越活跃，总部越需要看清两个风险：不同组织、区域、岗位之间的数据边界，会不会被AI打穿；每个部门独立建设AI，会不会再造一批新的技术债。 企业AI落地走到这个阶段，模型能力只是基础条件。更难的部分，是AI能力能不能在组织内部被统一管理、持续运营和事后追溯。 部门先跑起来，治理压力后出现 业务驱动本身没有问题。AI如果脱离业务场景，很容易变成演示项目。真正知道流程卡在哪里、员工每天重复做什么、哪些动作适合交给AI辅助的，往往就

随着“79号文”和2027年时间节点的临近，国资体系的国产化替代节奏明显加快。 前几年，很多项目先处理硬件、操作系统、数据库、中间件和办公软件替换；到了应用落地阶段，团队会遇到一个更具体的问题：底座换完之后，原有业务应用怎么继续跑，新的应用生态又怎么搭起来。 这一步很容易被低估。办公门户看起来只是一个入口，背后却牵着OA、财务、人事、资产、采购、工单、会议、档案、知识库、报表等一批系统。它们来自不同部门、不同厂商、不同技术栈，也运行在移动端、国产PC、内网浏览器和桌面客户端里。 信创改造如果只停留在“能装、能打开、能登录”，后面会陆续遇到兼容性、体验割裂、重复开发、发版滞后和安全治理问题。部分迁移材料会用“40%业务功能异常”来描述兼容性风险，这个数字在不同项目里会有差异，但足以提醒团队：应用适配的成本，往往比基础软硬件替换更难控制。 到了企业内部办公门户这一层，建设思路需要往前走一步。

企业引入AI工具，最早讨论的通常是账号、费用、模型选择和数据合规。到了桌面Agent开始普及之后，问题会变得更具体：员工在本机运行一个Agent，它可以读取文件、调用命令行、执行脚本、访问内部系统，也可能把这些动作串成一个自动化流程。对个人来说，这是效率工具；对企业来说，它已经带上了一部分执行权。 执行权一旦落到员工终端上，管理方式就不能只停留在“买了哪些AI账号”“谁能访问哪个知识库”“Token用了多少”这些层面。企业更需要知道，Agent运行在哪台设备上，拿到的是哪一套策略，访问过哪些目录，调用过哪些工具，哪些动作被允许，哪些动作被拒绝。否则，AI使用看起来在快速扩散，实际的边界却可能分散在每个人的电脑里。 接下来想分享的是：桌面Agent从个人工具进入企业环境之后，企业到底要管什么，以及FinSafe如何把这些分散的执行行为纳入统一托管。 一、企业AI管理正在从账号管理走向执行管理 过去企业管理AI能力，重点经常放在入口侧。比如谁能登录模型平台，哪些团队可以使用企业知识库，哪些数据不能外发，哪些模型供应商可以接入。这个阶段的AI更多像信息处理工具，它帮助员工生成文本、

26年5月，中国银行宣布旗下"缤纷生活"APP将于6月30日24时起全面停止服务，所有功能迁移至"中国银行"主APP。这是国有大行里第一个被关停的独立信用卡APP。邮储银行、渤海银行、上海农商行在2025年下半年完成了同类整合。这场覆盖国有大行、股份制银行和区域银行的APP"瘦身整合"潮，把过去十年银行数字化的一条主线推到了转折点。 之前的银行APP布局，标准打法是"按业务线拆APP"：手机银行主APP承担综合服务，信用卡APP做获客和权益运营，理财APP服务高净值用户，企业网银做对公业务，普惠金融APP服务小微客户。每个业务线在自己的垂直场景里做获客、转化、留存，封闭运营。移动互联网早期这条路径看上去是合理的——应用市场鼓励垂直化、APP开发成本可控、用户对"一个银行多个APP"也基本接受了。 所以很多时候，一个用户手机里同时装着"XX银行"和"XX信用卡"两个APP，账户体系不互通、积分体系不互通、消息推送不互通，办完业务就关掉。运营资源被多个APP摊薄，迭代节奏被各个业务部门独立规划，版本更新不同步、活动节奏对不齐，数据分散在多个后台无法打通。 "按业务线拆APP"

金融、政府、医疗这类企业引入 AI Agent 时，真正卡住落地的，往往不是模型能力，而是运行环境。 如果只是做内部知识问答，企业可以把制度、文档、FAQ、业务材料接入知识库，让员工通过对话检索信息。但当 Agent 开始从“回答问题”走向“执行任务”，情况会变得复杂。 它可能需要运行脚本、处理文件、调用内部工具、读写临时目录，或者根据业务人员的指令生成报表、整理材料、做数据预处理。到了这一步，企业必须回答一个很具体的问题：这些代码和工具调用在哪里运行，怎么隔离，怎么限制资源，出了问题又怎么审计。 在云原生基础设施成熟的团队里，这类任务可以交给现有平台处理，比如云端函数、容器、Kubernetes 集群或专门的代码执行沙箱。但在很多金融机构、政府单位、医院和大型集团的生产内网里，系统长期运行在受控环境中，网络出入口、数据流向、第三方依赖、系统变更、日志留存都有明确要求。

公司在引入 AI 工具的时候，很多情况下不是从一个正式项目开始的，而是先从员工和部门的日常需求里冒出来。 刚开始是员工自己订阅 AI 工具，用来写材料、查资料、整理会议纪要，效果不错以后申请报销；有团队先拿智能体做客服、运营、投研或研发辅助，跑出一点效率收益，再推动公司统一采购账号。很多新工具进入企业都是这样的路径，但AI Agent的问题在于，它不是一个只提供固定功能的软件。 它会读取上下文、理解员工意图、生成判断、调用工具，有些场景里还会沉淀记忆，甚至参与到业务执行里。 对金融机构来说，这意味着它一旦被真正用起来，就可能接触客户信息、内部制度、投研材料、风控规则、业务系统和员工的业务判断。 如果企业只把管理动作停在采购、账号和费用报销上，后面一定会遇到看不见、说不清、追不回的问题。 AI 管理不能只看模型效果 不少企业在评估 AI 时，第一反应还是看模型：效果好不好，响应快不快，价格贵不贵，能不能接入内部知识库，能不能私有化部署。

做了几年政务APP的外包开发服务，发现大部分客户都有同一个诉求：把现有的各种服务整合在一起，形成一个聚合的服务平台。 早期做这件事的方式是在微信里开发一个小程序，在支付宝里也开发一个小程序，有时候还给做一个H5的移动端页面。每个部门各自找供应商，各自开发，标准不统一，平台越来越多，市民要找服务，得先想清楚去哪个平台，再去那个平台里找到对应的小程序。 但时间长了，积累了很多入口很多的入口，很多不同入口做的都是同一件事。 政务小程序分布在不同的平台上，由不同的供应商开发，登录体系不互通，信息不共享，市民办事要跑多个入口，每个入口都要重新熟悉一遍。平台有平台的规则，小程序有小程序的数据，政务APP有政务APP的逻辑，三者之间是割裂的。 很多情况下都是一步一步积累的资产 差不多12-15年，移动互联网早期，各地政府选择通过微信、支付宝这类大平台发布服务，是合理的。平台有现成的用户基础，有成熟的登录体系，有完善的安全认证，政务小程序借助大平台的流量，能快速触达市民。 各个部门在不同的平台上发布服务，标准不统一。一个城市的公积金查询可能在支付宝里，社保缴纳可能在微信里，预约挂号在另一

从iOS14到iOS18，从安卓12到安卓16，APP版本一直在迭代，随着迭代越来越多，发现团队的技术债越欠越多～ 最开始为了省事，采用了主流的Native加H5混合开发，效率确实快。 页面要迭代，扔一个H5进去；需要调原生能力的，用Native处理。两年下来，H5模块塞了十几个，Native模块也有七八个。每个模块之间耦合得很紧——改A模块，B模块莫名其妙崩了；想更新C模块，必须跟着APP一起发版。 随着手机性能的升级，H5的体验也开始好起来，不过管理起来还是比较麻烦。十几个H5页面运行在各个不同版本的APP中，没有统一的版本控制，没有统一的内容审核，运营人员想改个字得找开发团队排期。 其实不止是我们的APP，估计这个问题很多APP都有。到某个阶段，包体越来越臃肿，维护成本越来越高，产品体验却越来越差。 今年开始测试引入小程序容器的形式，升级一下APP的架构～ 一、现状分析 Native加H5的混合开发模式，在早期是合理的。H5开发效率高、发布快，改完直接上线，不需要跟着发版。Native负责核心能力和高性能模块，H5负责内容展示和轻量交互。这个分工没问题。 但H5模

公司在引入 AI 工具的时候，很多情况下不是从一个正式项目开始的，而是先从员工和部门的日常需求里冒出来。 刚开始是员工自己订阅 AI 工具，用来写材料、查资料、整理会议纪要，效果不错以后申请报销；有团队先拿智能体做客服、运营、投研或研发辅助，跑出一点效率收益，再推动公司统一采购账号。很多新工具进入企业都是这样的路径，但AI Agent的问题在于，它不是一个只提供固定功能的软件。 它会读取上下文、理解员工意图、生成判断、调用工具，有些场景里还会沉淀记忆，甚至参与到业务执行里。 对金融机构来说，这意味着它一旦被真正用起来，就可能接触客户信息、内部制度、投研材料、风控规则、业务系统和员工的业务判断。 如果企业只把管理动作停在采购、账号和费用报销上，后面一定会遇到看不见、说不清、追不回的问题。 AI 管理不能只看模型效果 不少企业在评估 AI 时，第一反应还是看模型：效果好不好，响应快不快，价格贵不贵，能不能接入内部知识库，能不能私有化部署。

一、到底应不应该引入规模化引入AI 这轮 AI Agent 的热度，很大一部分来自个人体验的变化。 过去很多人用 AI，是把它当成一个问答工具。写一段文案、总结一份材料、解释一段代码，或者帮忙把一堆杂乱的信息整理成一页报告。到了 Agent 阶段，AI 开始能接任务、调工具、读文件、跑脚本、调用系统接口。它不再只是站在旁边给建议，而是开始参与工作本身。 企业最先感受到的，通常也是这种个人层面的提效。研发用它读代码、改测试；运营用它写方案、拆活动；投研人员用它整理材料；客服团队用它生成答复草稿。这个阶段很有价值，也很容易被看到，因为每个人都能讲出一个“以前要几个小时，现在几分钟”的例子。 但企业级 AI 改造如果只停在这里，后面会很快遇到天花板。 一个人变快，不等于一个组织变快。很多业务的低效，并不只是因为某个人写得慢、查得慢、整理得慢，而是任务在不同部门、

现在，很多APP都从H5混合开发升级为“Native+小程序”的开发架构，接下来从自身团队的开发经历出发，分享一下，如何当APP引入小程序之后，用户打开一个小程序后，背后的运行机制。 整体包括：打开方式、启动模式、关闭方式、预加载机制～ 打开小程序的几种方式 APP里打开小程序有几种不同方式，分别对应不同的业务场景。 最常用的方式：通过小程序ID直接打开 FATAppletRequest *request = [[FATAppletRequest alloc] init]; request.appletId = @"小程序id"; // 必填 request.apiServer = @"服务器地址"; // 必填 [[FATClient sharedClient] startAppletWithRequest:request InParentViewController:self completion:^(BOOL result