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

一、银行AI应用现状 2026年被视为金融智能体元年。行业数据显示，银行日均词元消耗较两年前增长近100倍，AI已覆盖营销、风控与运营全链条。头部银行正加速规模化落地：工商银行500+AI应用覆盖30余领域，招商银行超800个智能体场景，交通银行已部署2500+轻量化智能体，AI开始深入信贷尽调、反洗钱、财报校验等核心流程。银行AI正在从“工具试点”走向“业务系统化嵌入”，应用规模与复杂度同步提升，在这一进程中，新的挑战也开始集中显现。 二、银行AI落地核心挑战 银行AI应用的矛盾集中在三个层面： AI具备理解能力，但缺乏业务执行边界，难以进入核心流程； 业务流程跨系统运行，但AI能力无法统一编排，形成局部智能； 模型输出具备不确定性，但金融业务要求结果可解释、过程可追溯。 在监管与安全要求下，银行更关注AI是否具备“可管控运行能力”，而不仅是能力本身。 三、FinClaw银行智能体平台全景 FinClaw面向银行构建统一AI Agent中台，连接业务系统、知识体系与安全治理体系，实现AI能力的统一编排与运行。 平台围绕三层结构构建：  1）业务执行层，让AI进入

企业开始做 Agent，通常进展都不慢，常规流程是先接一个大模型，接几套工具，再补一层业务知识，一个对话入口很快就能跑起来。 前期效果往往也不错，但真正的问题一般出现在上线之后。 1、任务执行到一半中断，怎么续跑？ 2、不同部门的数据和记忆如何隔离？ 3、工具调用是否需要审批？ 4、出了问题以后，能不能完整还原当时发生了什么？ 这些问题单靠一个应用层的补丁，很难长期解决。 越往生产环境走，Agent越像一个系统问题，而不是一个功能问题。 很多企业最初会把智能体拆成几个模块：模型、工具、提示词、记忆、接口。 开发阶段看起来很清晰，但进入运维阶段就会发现，这些东西分散在不同地方。 比如，配置是在代码里，知识在文件系统，权限在数据库，状态在缓存，审计在日志系统。 单个Agent看起来简单，但整体变得难以管理，这个智能体到底“长什么样”，很难三言两语就说清。 凡泰极客在探索一个更为清晰的方向：把智能体放回到文件系统里组织。不再把它拆散在不同系统，而是用目录来表达结构。 从“功能型”

在信创体系持续推进的背景下，越来越多央国企与行业单位开始引入AI能力，用于提升办公效率与业务智能化水平。 根据赛迪数据，信创产业整体市场规模已超过万亿级别，并持续快速增长。与此同时，央国企核心系统国产化替代正在进入“深水区”，对系统完整性与安全能力提出更高要求。 从智能办公助手，到知识问答系统，再到基于大模型的智能体应用，AI正在逐步进入信创办公体系的核心场景。但在实际落地过程中，合规问题也正浮现。“有AI能力，但难以在信创环境中真正合规运行。”尤其在项目交付过程中，这一问题便突出了。 一、市场现状：信创项目进入AI融合阶段 当前信创建设已经从“替代阶段”进入“融合阶段”，企业不再只关注系统国产化替换，而是开始关注AI能力如何融入现有信创办公体系。因此，大量项目开始提出明确需求： * 在信创环境中部署AI办公能力 * 支持智能体应用与业务流程结合 * 满足安全与审计要求 * 可通过验收与监管检查 但在实际执行中，很多项目仍停留在“应用层AI”，缺少真正可交付的统一底座能力。AI能做出来，但很难在信创体系里跑稳、管住、查清。 二、核心痛点：能开发智能体，但缺少安

从大模型助手到智能办公工具，从代码生成到数据分析，从知识问答到业务自动化，越来越多员工开始在日常工作中使用各类AI应用。然而，随着AI工具数量快速增长，一个新的管理问题正在浮现：员工在使用AI，企业却看不见AI。员工各自选择不同工具，不同部门接入不同Agent，不同业务场景采用不同模型。AI能力正在快速渗透企业，但企业IT部门对这些能力的管理和控制却相对滞后。在Agent时代，如何实现统一管理、统一控制和统一协同，正在成为企业AI建设的新课题。 从应用管理到Agent管理 企业正在进入新阶段 过去，企业IT管理的对象主要是业务系统。ERP、CRM、OA等系统部署完成后，用户通过标准流程完成业务操作。而Agent的出现改变了这一模式。Agent不再只是一个工具，而是具备理解、规划和执行能力的数字助手。未来，每位员工都可能拥有多个Agent。销售拥有销售Agent，客服拥有服务Agent，研发拥有开发Agent，运营拥有运营Agent。 这些Agent将持续参与企业业务流程，成为新的生产力单元。当Agent数量达到一定规模后，企业面临的挑战已经不再是如何让员工使用AI，而是如何

近日，微信开发者后台上线《开发者接入微信AI生态指引》，其中一项能力引发行业广泛关注： 开发者可开启“小程序被微信AI调用”。 过去几个月，关于微信AI、小程序 Agent、MCP 的讨论一直很多，从行业传闻，到开发者社区里的各种猜测，市场其实已经预热了很久。 这次不太一样，真正的变化开始出现在开发者后台。 微信这次开放了两种模式，一种是自动模式： AI可以像真人一样操作小程序，识别页面、点击按钮、输入内容，直接完成服务流程。 另一种是开发模式。 开发者可以把原本页面里的功能拆成一个个Skill，通过 MCP 协议开放给 AI 调用。小程序正在从“入口”慢慢变成“服务”过去，小程序更像一个轻量入口。用户主动搜索、扫码、点击，然后进入页面完成操作。现在，服务开始变成“可被调用”， 入口逻辑也开始变化。 这种变化，其实和FinClip这些年一直在做的方向很接近。  很多企业过去几年都遇到过类似的问题：业务越来越多、系统越来越多。

近日，第二十届深圳国际金融博览会（以下简称“金博会”）在深圳会展中心（福田）圆满落幕。作为2026深圳科技金融周的重要组成部分，本届金博会以“AI时代：制造业与服务业协同发展”为主题，汇聚300余家金融机构、400余家科创企业及众多产业生态伙伴，共同探讨人工智能技术驱动下的金融创新与产业升级。 作为企业级AI智能体与数字员工平台服务商，凡泰极客携旗下FinClaw企业级Agent平台与FinClip超级应用智能平台亮相金融科技展区，围绕“AI数字员工”“企业级Agent平台”“金融级安全与治理”等核心议题，展示了AI在金融行业从概念验证走向规模化落地的实践路径，吸引了银行、证券、保险及政企领域的IT决策人和业务负责人到场交流。 聚焦金融AI落地，从“能对话”走向“能执行” 随着大模型技术快速发展，金融行业正进入AI应用深化阶段。相比早期“聊天式AI”的探索，越来越多金融机构关注AI如何真正融入业务流程、提升运营效率，并满足金融行业对安全、合规、可控的高标准要求。 在展会期间，凡泰极客重点展示了FinClaw企业级Agent平台在金融场景中的落地能力。 企业级架构：基于100%

最近跟几家券商的朋友聊天，聊到一个有意思的现象： 同一年上的AI Agent，现在差距拉开了。 有的券商，AI数字员工已经从"试点"变成了"主力"，业务部门抢着要用，科技人员的排期都排到下个季度了。 有的券商，AI项目上线半年，热度过去了，现在打开率越来越低，业务部门说"还不如我自己干"，科技人员也不愿意继续投入了。 同样都是AI Agent，差距怎么这么大？ 我跟几家券商的科技负责人聊了聊，发现那些"越用越值钱"的，和那些"成了摆设"的，在选型和运营上有几个关键差异。 今天不聊产品，就聊这个问题。 差异1：选型时问的是"能做什么"，还是"能做好什么" 那些把AI Agent做成摆设的券商，选型时问的问题大概是： * "这个平台支持多少种工具调用？" * "能接哪些大模型？" * "有哪些现成的模板？" 这些问题都没错，但问的都是"功能清单"。 而那些"越用越值钱"的券商，问的问题是：

企业引入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 进入企业之后，很多讨论都会落到一个问题上：到底应该跑在员工电脑上，还是统一收进云端平台？这个问题看起来是架构选型，背后其实是企业对 AI 的理解。如果只是让员工写材料、查资料、生成代码、整理表格，AI 更像一个个人效率工具。它离员工越近，越能理解本地上下文，使用体验也越顺。但一旦企业希望 AI 进入流程、调用工具、连接系统、沉淀经验，它就不再只是某个员工身边的助手，而会逐渐变成组织执行系统的一部分。这时候，真正的问题就不是“分布式还是集中式”这么简单了。企业需要思考的是：AI 能不能在贴近工作现场的同时，被组织看见、约束、审计和复用。 个人提效只是第一步 很多企业最早感受到 AI Agent 的价值，都是从个人提效开始的。 研发用它读代码、写测试；运营用它拆活动、写方案；客服团队用它生成答复草稿；投研和数据团队用它整理材料、做初步分析。

金融、政府、医疗这类企业引入 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 跑起来了，管控却跟不上 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