公司在引入 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 跑起来了，管控却跟不上 2025 年以来，AI Agent 在企业端的落地速度持续加快。Claude Code、OpenClaw、Helios 等工具正在改变软件开发的工作方式，尤其是 AI Coding 的提效能力已经从“概念验证”进入“规模化应用”阶段。 然而，企业配套的安全管控体系，却明显滞后于业务发展的速度。 行业调研数据显示，超过 60% 的金融机构已在生产环境中部署了 AI Agent 应用，但其中真正建立起完整终端安全管控机制的，不足 15%。 二、问题本质：分布式与集中式，企业陷入两难 企业在部署 AI Agent 时，通常面临两种选择。 01 分布式部署 AI 直接跑在员工本地 Mac/

一、到底应不应该引入规模化引入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

年初的 OpenClaw 热潮，几乎国内所有的大厂都跟进了，推出了自己的小龙虾。 其实小龙虾的技术并不是非常的神秘，甚至是开源的，主要是它把一件原本只存在于产品演示里的事，直接拉到了普通开发者和技术团队面前：原来一个 Agent 真的可以接消息、调工具、跑多步任务，还能长时间挂在设备上持续工作。 现在回头看，个人用户侧的声量已经没有当时那么高了。这个变化很正常。个人助手类产品从爆红走向常态，往往只需要几周。新鲜感过去之后，留下来的问题就比较现实了：本地环境怎么维护，模型费用怎么算，消息渠道要不要长期接入，技能能不能放心装，电脑上的权限该开到什么程度。很多用户会继续尝试，也会有很多用户停在围观和体验阶段。 如果只看这一层，很容易得出一个误判：OpenClaw 好像已经从舞台中央退下来了。可换个角度看，它的价值判断才刚刚开始。它在个人用户侧完成的那轮传播，更接近给行业做了一次公开演示，让大家第一次把“会执行任务的 Agent”看得足够具体。接下来接棒的，不再只是个人玩家，而是企业。 问题的关键不在于 OpenClaw 还热不热，而在于它把哪种能力带进了企业讨论里。 企业看重的不

APP开发有一个很现实的问题：业务模块越加越多，主工程越来越臃肿，每次发布都要等研发排期、测试、还可能被应用市场打回。项目上了规模之后，光是一个功能改动的上线周期就得好几周。 这个问题怎么破？越来越多的团队开始用"原生+小程序"的混合架构来回答——把业务模块从主包里解耦出来，变成独立运行的小程序包。业务团队可以自己写、自己发，不需要动APP主包。 分享一下基于小程序容器的解决方案～ 传统APP开发模式的核心瓶颈 很多团队的APP开发模式是这样的：所有业务模块都堆在主工程里，任何一个新功能的增删改，都需要改动主包，走完整个发布流程。 堆到一定程度，会遇到几个卡点。 发版周期长，业务跟不上节奏。 一个营销活动从提出到用户真正用上，在很多团队里走的是这样一条路：研发排期评估两周，开发完成后转测试，测试发现问题修复三天，测试通过打包提交应用市场，审核三天后被驳回要求修改，修改后再提交，再等三天审核。整个过程走完，差不多三周。错过了最佳窗口。 多团队协作成本高。 大公司里，APP主工程通常由一个核心团队维护，其他业务团队的功能想要接入，要么等排期，要么把代码合并进去，代码规范、测

2026年4月17日，XChat 正式登陆苹果 App Store。 马斯克一直想做一个美国版的微信的目标已经实现：端对端加密、无广告、无追踪，注册只需要一个 X 账号，不需要手机号。马斯克给它的目标也很直接——X 要从社交平台，变成「美国版微信」。 X 目前的战略版图基本清晰了：X 本体负责流量，X Money 负责支付，Grok AI 提供智能。接下来的问题是：第三方服务用什么形态接入？ XChat 之后，X 最缺的是什么 超级 APP 的竞争，表面上比的是功能，实际上比的是生态。 微信真正的护城河，不是某个具体功能，而是开发者生态——700万小程序开发者在里面提供了完整的服务供给。用户遇到事情不需要离开微信，开发者早就把服务准备好了。 X 有用户基础，有支付工具，有 AI

一、AI 编程能力如何应用到APP开发团队 每天打开新闻都是各种： AI可以取代程序猿、AI可以独立写页面、AI可以独立完成APP，程序员马上要失业了，一个产品经理半天时间就能生成一个带完整页面的活动模块原型；一个运营人员一个小时就能写出一个内部查询工具的小程序的案例....... 但.......如果真的想把AI能力引入到已有APP的开发中，会发现还是很难实现规模化、稳定的交付～ 仿佛现在整个编程世界是割裂的，一方面AI可以极大提高工作效率，但另一方面在真实的生产环境中，很多技术团队还在被效率困扰：业务部门提过来二十多个需求，产品经理排期排到下个季度，开发人力就是不够。产品迭代速度被开发效率卡死，一线开发团队疲于应付。 因为团队真正关心的，不是某个人用 AI 提效了多少，而是整个 APP 的长期运营维护成本能不能降下来。 AI Coding 的短期提效很直观，但只有把 AI 生成的代码真正用容器管起来，后续的迭代、维护、问题修复才能真正减轻负担。 二、AI Coding 落地APP开发的三条路径 2.1 路径一：AI 辅助开发（Claude Code

一、背景：让第三方代码跑进来，但要管得住 企业APP开放能力给第三方，已经不是什么新鲜事。银行把消费分期、生活缴费、影音娱乐引入自己的APP；券商把投教内容、交易工具嵌入合作渠道的流量入口；航空公司把值机、选座等出行服务开放给外部小程序。 特别是在流量收紧的情况下，企业的APP是一个流量分发渠道，第三方服务商有内容和服务，双方各取所需。 但紧接着另一个问题就出现了——第三方代码跑在自己的APP里，企业能管住它吗？ 特别是金融类APP，第三方小程序在运行时会调用摄像头、读取位置、上传数据、对接支付。如果不加以管控，某个小程序出现安全漏洞或恶意行为，受损的是宿主APP的声誉和数据安全。更麻烦的是，这些小程序不是自己开发的，无法要求对方"按规范写代码"，只能在运行时加以限制。 解决这个问题的方式，就是给APP加一层安全沙箱，让第三方代码在可控的边界内运行。 二、先介绍下小程序沙箱 小程序沙箱是一种安全机制，基本逻辑是"限制代码能做什么"。 它的实现依赖四个层面： 安全隔离。 沙箱为每个小程序创建一个独立的运行环境，不同小程序之间互不干扰。一个小程序崩溃或出现内存泄漏，不会

许多企业折腾了大半年AI转型，模型跑得挺溜，但一到“让AI连一下系统”这一步，合规部门的态度就更谨慎。 不是模型不行，而是没人敢给它开权限。 OA里的审批流、ERP的订单数据、CRM的客户资料……这些才是企业真正想让 AI 帮忙干的活。但让一个黑盒模型直接改数据库、发邮件、调接口，出了错谁背锅？数据被带出去了又该怎么办？ 企业要的不是“能跑 AI”，而是“能安全地让 AI 干活”。 凡泰极客自研的企业级Agent平台FinCla个，不做花里胡哨的包装，核心就三件事。 第一、私有化部署，五层隔离机制。 FinClaw不依赖容器守护进程，不借助虚拟化扩展，直接组合Linux内核原生的五种安全原语。让AI在企业内网里跑起来，数据不出域，操作可管控。 第二、让AI安全地调用内部系统。 它底层有个叫FinSafe的沙箱。这个沙箱不靠容器，而是用Linux内核原生的五层隔离机制：文件视图隔离、系统调用过滤、资源限制、身份隔离、路径级权限控制。 举个例子：你让AI去读

一、如何尽可能的复用已有代码资源～ 为原生鸿蒙系统开发一个鸿蒙APP，其实不止是开发团队的工作，有大量的代码适配、测试工作去做，其实在真实的落地业务中，业务部门的第一反应就是：能不能直接复用安卓端的代码，业务部门也没有这么多精力来配合。 一个业务用iOS写过一遍，也上线了安卓，还有微信小程序，能不能把这些代码直接搬过去，不需要重新去写代码？ 今天分享一个最近使用的技术路径，核心思路是：不去做颠覆性的开发，只需要开发一个宿主APP，然后集成一个小程序容器的SDK，让现有的小程序包体就可以直接跑在鸿蒙APP里，看看有没有帮助～ 二、整体思路复盘 第一种是全部用鸿蒙原生代码重写，每个小程序对应一套 ArkUI 代码。好处是性能最优，坏处是工期长，几十个小程序全部重写，加上测试，上线周期拖得很长，而且每次功能迭代都要同步改两套代码，维护成本翻倍。 第二个就是混合开发架构。鸿蒙只做一个壳，集成小程序容器 SDK，底座用原生实现，上面所有的业务功能全部用小程序承载。不需要重写已有的小程序代码，直接把现有包体复用进来就行。 整个混合开发的核心，是把 APP 分成两层： Native 层

从去年开始，软件开发正在经历一次很明显的范式变化。 前几年，AI 辅助写代码，主要场景是补全函数、生成页面、解释报错、写测试用例。但现在，AI Coding 已经不只是辅助写代码，开始进入独立写代码了。GitHub Copilot coding agent 可以在 GitHub Actions 环境里自主研究代码仓库、制定实现计划、修改代码分支，必要时创建 Pull Request。GitHub 在 2025 年宣布 Copilot 引入异步 coding agent，形成 Agentic DevOps Loop。 换句话说，今天的 AI 已经不只是"帮开发者写一段代码"，而是可以独立完成一个开发任务。 于是出现了另一个问题：既然 AI 能写代码了，我们为什么还需要小程序容器？

金融、政务、央国企的AI落地难题 大模型浪潮来了，所有的企业都在谈AI转型。供应商来了一个又一个：方案听起来都很美好，但一问部署方式，要么数据要上公有云，要么得配套上一套Kubernetes集群。要么安全合规不满足，要么运维成本扛不住，这是当前各大金融机构、政务单位、央国企等普遍面临的AI安全落地的难题。 AI要落地，得让它真正"干活"，不是聊天问答，而是调用工具、写代码、执行流程操作。但让AI直接操作你的内部系统，企业能放心吗？满足合规监管吗？一次误操作，可能删掉核心数据；一次"越狱"，可能泄露业务敏感信息；一次失控调用，足以让你的服务器宕机。要上AI，先把"围栏"搭好。 沙箱隔离，给AI划一道安全的边界 "沙箱隔离"并不是新概念。 它的核心逻辑很朴素：在AI与真实系统之间，划定一片"只能在此活动"的区域。无论AI产生什么行为，都被限制在这道围栏之内，出了圈，内核或运行时直接拒绝。 市面上的沙箱方案有很多种。

一、背景 25年AI Coding 的能力可以满足大部分个人开发者的需求；到了26年，大部分APP开发团队应该都在考虑如何引进AI来提高APP开发效率了，今天分享一下团队如何借助AI来实现开发的效率提升 虽然Cursor、Claude Code 在个人开发者的使用过程中已经相当稳定，写脚本、出原型，没有任何问题。但是到了企业研发生成中，还是会遇到很多问题，例如：代码规范要统一、私有组件库要复用、UI/UX 标准要对齐——生成的代码风格发散，还得靠人工 review 才敢正式的发版。 特别是内部实践下来看，直接写APP确实很困难，但借助AI写小程序还是非常稳定且高效的，因此想到是否可以通过引入小程序容器技术，让APP拥有运行小程序的能力，然后借助AI Coding来写小程序而不是动原生APP。 例如，引入AI Coding 来生成小程序，通过小程序容器分发到所有 APP，每个包独立运行在沙箱里，即使出了问题不影响主 APP，发现问题直接回滚。不需要去动宿主APP，也能提升APP的发版效率。 二、核心逻辑 整个框架的逻辑还是：人来负责整个流程的监控、

一、背景 对于一个教育公司来说，目前最大的获客引流渠道还是微信小程序，很多公司陆陆续续做了考研、英语四六级、考公等不同类别林林总总十几个小程序，然后通过各种公域、私域引流传播，也获得了一大批用户，但实际上只有昵称和头像，没有手机号，想给用户发个消息推送根本做不到。 存在服务器上的只有一串底层数据，而且微信对用户数据的限制越来越严，商户能拿到的信息越来越少，靠微信小程序做精细化运营变得越来越困难。 如何做一个统一的教育APP，把考研、英语、考公等不同类别的小程序全部集成为一个自有APP，同时把微信里的用户数据迁移到自有账号体系里。用户迁移过来之后，成为能触达、能分析、能做转化，用户真正变成公司的资产。 这篇文章分享整个迁移过程中的技术实践～ 二、技术可行性 迁移的第一步是要确认一件事：已有的微信小程序能不能不改代码直接迁移到自有APP？ 初步调研了一圈，计划采用兼容微信语法的FinClip小程序容器技术架构，这样已有的微信小程序包体可以直接在小程序runtime 运行时环境中编译运行，不需要二次开发。考研小程序、英语小程序、考公小程序，各自提交到管理后台审核后即可上线，整

麦肯锡预测，生成式AI将为全球保险业带来500亿至700亿美元的额外收入。过去五年，AI领先的保险公司总股东回报（TSR）是落后者的6.1倍，这一差距在所有行业中几乎最大。 一、保险行业AI落地面临的真实挑战 保险的业务链条长且碎片化，产品设计、核保、销售、客服、质检、理赔，每个环节都涉及大量非结构化数据：病历、产品条款、客服录音、理赔材料。这些数据此前高度依赖人工判读，效率瓶颈明显。 挑战一：核保理赔效率待提升 产品条款与医疗记录复杂，人工处理周期长，录入核对易出错。 挑战二：效率与信任难两全 AI提升效率但削弱人情联结，保险依赖信任，需避免完全替代。 挑战三：合规落地三难 数据不能出内网、操作需留痕可查、关键决策必须零幻觉。 核保判断失误，保司承担风险敞口；理赔审核出错，欺诈漏洞难以弥补。大模型在关键业务环节的"幻觉"问题，是保险行业迟迟不敢将AI深度嵌入核心流程的核心顾虑。 二、FinClaw保险行业解决方案，AI深入业务场景

4月22日，第五届国有企业数智化转型创新发展交流会在北京成功召开。大会以“AI赋能 数智领航”为主题，聚焦人工智能赋能、数据要素驱动、产业数字化升级，共探国企数智化转型新趋势。国家部委相关领导、大中型央国企数字化负责人、高校科研院所专家等300余名代表参会。 作为本届峰会重要参与企业之一，凡泰极客携FinClip与FinClaw两大核心产品亮相，与来自全国300余家央企、国企的CIO及数字化负责人展开深度交流。 央国企AI落地，面临三重现实挑战 "十五五"规划明确提出，要推动人工智能与实体经济深度融合，加快推进AI在工业、金融、教育、医疗等领域的规模化应用。国资委近年来也多次强调，央企国企要将数字化转型作为"一把手工程"，积极拥抱AI能力，提升运营效率与创新能力。 政策加速落地，央国企AI应用正加速从"探索试点"走向"规模落地"。然而在实际推进中，安全合规、组织管控、投入产出等挑战正成为央国企普遍关注的焦点。 1、合规安全要求高：央国企承载大量敏感数据，等保三级、密评要求、数据不出域等硬性约束，决定了开放的AI产品不能"拿来即用"，安全是必须迈过的第一道门槛。 2、

当一座城市的政务服务、民生应用、本地商业全部汇聚在一个App里，会是怎样一种体验？ 某市融媒体中心（以下简称"A市融媒"）用一年时间给出了答案：通过FinClip小程序容器技术，他们将原本散落在30多个委办局、数十家本地企业的服务应用全部整合到一个平台，构建了一个真正意义上的"政务+融媒超级App"。 这不仅是一次技术升级，也是一次城市服务模式的进化。 一、为什么需要"超级入口"？ 在项目启动之前，A市融媒面临着一个几乎所有政务平台都会遇到的困境："信息碎片化"。 痛点一：30多个入口，老百姓找服务如同"大海捞针" "我们有新闻客户端、有政务网站、有各部门的公众号、有物业的APP、有本地商家的服务平台……加起来几十个入口，但老百姓真正需要的时候，根本不知道该去哪找。" 据统计，A市涉及民生服务的委办局超过30家，每家都有自己的一套应用系统。物业、社保、医疗、教育、旅游、文化……每一条线都是一个独立的"信息孤岛"。百姓办事需要在不同平台之间反复切换，体验割裂，满意度可想而知。 痛点二：本地科技企业"

01 行业趋势：从"内容平台"到"新型基础设施" 2026年的融媒体已不再是传统媒体与新兴平台的简单叠加，而是演变为一种深度嵌入社会运行肌理的新型基础设施。它既是主流舆论的传播主阵地，也是公共文化服务的数字接口；既是文化创新的孵化温床，也是社会治理的智慧节点。 三大趋势重塑融媒行业格局 趋势一：从"渠道融合"到"生态重构" 融媒体的发展已超越"多端发布、一次采集"的初级阶段，进入以"智能驱动、服务嵌入、价值共生"为特征的深度融合期。 趋势二：从"新闻平台"到"综合服务平台" 全国众多县级融媒体中心已接入"一网通办"系统，市级以上融媒体通过打造本地生活服务平台，真正实现"新闻+政务+服务"的一体化运营。 趋势三：从"内容驱动"到"数据驱动" 内容生产以"数据驱动、人机协同、场景适配"