客户拜访结束后，AI生成了纪要，列出客户需求、双方承诺和下次联系时间。销售仍要核对客户名称，把需求录入CRM，创建跟进任务，通知售前同事，再逐个系统查看进度。

纪要写完了，后续业务还靠员工手工衔接。缺的是一条能把纪要转成系统动作、并追踪结果的任务链。

纪要是信息，更新CRM是业务动作

AI能从录音中提取“客户希望周五前收到方案”，但这句话还不是CRM活动，也不是有负责人和截止时间的任务。

要让业务继续推进，系统需要匹配客户记录，把承诺转成任务字段，以授权身份执行写入，再把结果交还给发起人。任何一步依赖复制粘贴，员工就仍在充当系统连接器。

纪要数量和助手调用次数无法反映客户跟进进度。应检查CRM是否新增准确记录、任务是否有负责人和截止时间、协作人是否接收，以及后续状态能否从业务系统查到。

从一次拜访定义一条可执行任务链

任务链从销售提交拜访记录开始，记录带上拜访ID、客户或商机ID、发起人、时间和原始材料引用。拜访ID关联后续动作，客户ID定位CRM记录，避免同名客户写错对象。

AI先提取“客户需要报价”“售前下周演示”等行动项，再映射为关联商机、任务类型、负责人、截止时间和任务描述，并保留纪要中的依据片段。负责人不明确的任务留待确认；报价金额、承诺日期可回到原文或录音核对，不能直接用模型补出的字段派单。

待执行清单列明目标系统、写入内容、确认人和预期回执。销售看到的是CRM将新增什么、会创建哪些任务；确认后，系统再执行写入，不用重新翻阅整篇纪要寻找待办。

执行时，先确认客户记录，再写入CRM活动、创建跟进任务、发送任务链接，并保存每一步返回的记录ID和状态。CRM写入失败，通知不得称已更新；任务已创建而通知失败，则只重试通知。

接口接通之后，还要处理重复、失败与责任

接口接通，只代表动作可以发起。重复提交、部分成功和失败恢复，决定它能否稳定处理真实业务。

销售重复点击提交，或客户端因超时重试，都可能生成重复任务。为拜访及行动项分配稳定标识，执行服务先查已有记录，再创建或返回原结果。旧系统没有幂等接口时，连接层保存“业务动作—目标记录ID”的映射。

若CRM活动已保存，任务系统却因字段缺失拒绝创建，任务链应显示“部分完成”，保留已写入的活动，并记录失败动作、原因、重试次数与目标记录。销售看到“CRM已更新；售前任务待补负责人”，运营人员则处理异常队列。整条任务不能被误标为完成，也不必撤销正确写入的活动。

读取客户资料、写入拜访活动、给他人派单，权限各不相同。连接服务记录调用者、业务对象、动作、授权结果及确认人，才能追溯一条CRM记录由谁发起、依据什么写入、哪个系统返回成功。所有动作共用一个账号，会让责任难以还原。

通知也不能代替业务结果。先取得任务系统的记录ID，再发送包含任务链接的消息；查询进度时回到任务系统读取状态。

[[RYAN_FINCLIP_GHOST_IMAGE_02]]

平台要连接任务，不要求重买所有软件

在凡泰极客的产品体系里，FinClaw承接任务组织与执行，FinFlow连接现有系统、封装业务动作并回写结果，Fin AI OS串起任务、连接和回执。CRM和任务系统仍保存正式业务记录。

CIO可以先选“客户拜访记录—CRM活动—跟进任务”这条业务链，梳理字段映射和例外情况，再接入所需系统。无需一开始接通所有工具，也不必迁走CRM数据。评价连接能力时，看它能否处理既有系统的身份、字段、回执与失败恢复。

验证的终点在业务系统里

试点前后按相同口径记录：从拜访结束到CRM更新、任务创建、负责人接收各用了多久，人工复制了几次，漏建和重复任务有多少。纪要生成时间与业务链完成时间要分别统计。

验收时沿拜访ID检查CRM活动ID与任务ID是否存在、客户与负责人是否正确、异常是否进入待处理队列、状态能否回查。只生成纪要和待办草稿，员工仍需录入；记录经授权写入并取得回执，员工才能转向处理判断与例外。

CIO盘点现有AI工具时，就沿一次客户跟进检查：哪些步骤仍靠员工复制信息、切换身份、确认写入、追问结果。把这些交接点连成有业务标识、授权动作和系统回执的任务链，客户跟进才能在系统中继续执行。

设想一场数字化例会：安全把前四层都勾过了——请求进得了认证、运行时按租户落盘、主机上套了隔离、核心写接口前面有闸门。

IT 经理补了一句：“员工周一打开的，是别人家的桌面。”台下有人点头。

若各部门各自安装未经 IT 统一管理的桌面 Agent，网关日志仍可能干干净净，但员工每天点开的图标，写的往往是供应商的名字。下文说的“现场”，都是这类可对照的检查场景，不是某一家客户的内部工单。

前四篇分别讲了连接面、常驻运行时、主机沙箱、行动面。四层都成立，仍回答不了：员工每天打开的那扇 AI 办公门，品牌、插件和安装包归谁。

入口替不了沙箱，也替不了写接口治理。入口缺位，企业还需要确认：员工从不同桌面发起的操作，是否都经过了既定的控制。

入口主权说的不是“员工能不能用 AI”。它说的是：默认入口由谁分发、窗口长什么样、里面能装哪些插件、安装包按谁的策略打出来。

买到桌面产品的使用权，并不自动意味着企业掌握了这些决定权。

别人家的桌面，正在变成默认入口

桌面 Agent 会读授权目录、改文件、接企业邮箱和网盘，关了浏览器也还能继续工作。员工把它当成办公壳，不是当成网页书签。

微软将未经 IT 知悉或批准的消费级 AI 应用和独立 Agent 纳入 Shadow AI（影子 AI）的范畴。其预览文档列出了 ChatGPT Desktop、Claude Desktop、Ollama Desktop 等检测对象，并对 OpenClaw 提供检测与拦截；拦截目前仅覆盖已加入 Intune 的托管 Windows 设备。

能看见、能拦一部分，不等于企业已经有了自己的入口。

Defender 的本地 Agent 发现说明写道，这些程序以用户权限运行，能接触文件、工具和服务；看不见在哪台机器、以谁的身份运行，就难以评估暴露面。发现解决的是盘点问题。

腾讯 WorkBuddy 产品页与 Anthropic 的 Cowork 企业指南，都描述了“桌面里办事”：下任务、读写授权本地文件。Cowork 的本地文件与桌面应用操作需要 Claude Desktop，客户端可通过 MDM 推送，也可由员工自行安装。

这些产品同样可以提供企业管理能力。例如，Claude Desktop 支持用 Jamf、Intune 下发配置，Cowork 提供企业插件管理与分发策略。但在供应商提供的窗口中管理策略，与企业自行定义和发行一套桌面，仍是不同的事情。

盘点清了，还要继续问：品牌、插件接口和发布节奏，企业分别能决定到哪一步？

入口也能像浏览器那样分层

浏览器早就拆过这件事。Chromium 提供共用的技术基础；Chrome、Edge 则是不同的浏览器产品，有各自的界面、扩展管理和发行安排。共用底座，不意味着交付的是同一个产品。

桌面 AI 入口可以按同一组问题切开。

启动层（Host）：谁来启动程序，插件走哪套接口。

它负责程序启动、注册，以及给上层使用的软件接口。换品牌、换插件集，都不该逼着开发团队重写这一层。

窗口壳（Shell）：员工看见哪套导航和品牌。

侧栏、顶栏、导航，构成员工看见的办公外壳。它决定界面如何组织，不负责回答代码在哪组主机隔离机制里运行。

插件（Plugin）：这扇门里允许办哪些事。

插件承载具体办事的界面和能力，应通过启动层公开的接口使用底座能力，避免各自依赖桌面主进程的私有通道。至于对核心系统的写操作该不该发生，仍需由对应的权限和行动治理机制判断。

发行单元（Distribution）：员工真正拿到哪套组合。

哪一套壳、哪些插件、什么品牌、什么策略，需要落实到最终交付的版本中。它回答的是软件交付内容，和席位账单是否已付是两件事。

还可以再叠配置档案（Profile）：按版本、辖区或条线组合，而不必为每个地区重写启动层。

白牌在这里才有具体的工程含义：企业能决定交付给员工的壳、插件和策略如何组合，开始菜单里出现的是自己的办公入口。

Rocket.Chat 的白牌文档举例说明了如何修改图标、托盘图、关于页版权，以及在 electron-builder 中修改 productName，也就是安装程序与系统应用列表里显示的名字。

图标和产品名能改，只证明品牌表面可换；插件谁能上架、共享界面走哪套接口、正式包打进哪一个发行单元，还需要分别核对。

判断入口是否由企业掌握，要看企业能否指出：员工拿到的壳、插件和策略，属于哪一个由自己管理的发行组合。

常见错法与更短的对照

容易混淆的，是把席位、换皮和入口主权当成一件事。

只禁不替。

能在部分托管设备上拦截某类桌面 Agent，不等于员工不再找别的安装包。禁令没有配套可用的替代入口，实际工作就可能转向尚未被盘点的工具。

买了席位就当有了企业入口。

管理控制台可以管账号、额度、账单，也可能管理插件和策略；窗口叫什么、导航如何组织、版本怎么发布，仍取决于产品开放的范围。需要逐项核对，不能仅凭购买了企业版来判断。

只换图标和关于页。

品牌表面换了，插件仍依赖供应商私有通道，壳仍是固定导航，机构自己的能力也没有独立维护的位置。此时换掉的是外观，后续定制仍可能牵动整套客户端。

把入口当成沙箱或行动网关。

入口回答“员工打开谁的门”；主机隔离回答代码在哪跑；行动面回答对存量系统的写该不该发生。把三件事混进同一个安装包叙事，评审时就容易忽略各自的控制边界。

忽略不同岗位的交付差异。

辖区和条线不同，威胁模型和能办的事也不同。可以使用不同发行单元，也可以通过同一安装包的受管配置来区分。关键是避免把不该出现的插件发到不该出现的工位。

更好的做法很短：承认员工会从桌面办事；把启动层保持稳定，让壳、插件和发行组合可以分别管理；插件依赖公开接口；正式交付对应明确的版本与配置；桌面接上已有的运行时和主机隔离。

四层分开画，评审才问得清楚：买的是使用权，改的是外观，还是已经具备了自主发行和维护的能力。

一条可核对的入口层

分层讲到这里，已经不依赖任何一家供应商。需要核对的是：入口能不能写成可组合、可维护、可发行的软件结构。

例如，凡泰 FinDesk 的公开材料描述了桌面 SDK 与独立发行仓的分工，由壳、插件、配置档案和发行单元组成不同的桌面版本。这个例子说明，入口定制可以落实为工程组合，而不只是在界面上换一个图标。

入口层能核对的，是这些部分有没有被拆开、由谁维护。它本身不证明代码已经进入隔离环境，也不证明对核心系统的写操作已被批准。

读者可以带走四个问题：员工打开的窗口叫谁的名字；插件走谁的接口；安装包对应哪一个发行单元；这扇门有没有被误当成沙箱或写入治理。

下周就能做的五件事

不必先换桌面产品。先对着员工已经在用的那几个 AI 桌面，拉上 IT、安全和一条业务线，回答同一组问题。

1. 点名默认入口。

员工周一最常打开的是哪一个安装包，从哪里安装，由谁管理。写不出名字，就先补盘点。

2. 分开席位和发行单元。

管理控制台里的席位、额度、账单，与安装包里的品牌、插件、策略，列成两列。分别写清企业能控制哪些内容。

3. 画出四层。

启动层、窗口壳、插件、发行单元，各写一句它回答什么。如果把桌面入口直接当作沙箱或写入治理，需要重新划清职责。

4. 核对接线。

插件是否通过启动层公开的接口使用底座能力。如果共享界面直连桌面主进程的私有通道，换壳就可能牵动插件，后续维护也会更困难。

5. 按条线看交付。

顾问、柜台、境外团队，是否应该拿到相同的插件与配置。若只能全部禁止或全部开放，就先补齐按岗位组合和管理的能力，再谈推广。

这些问题答不清时，可以先把入口的决定权和维护责任理清，再评估是否需要新增一款桌面 Agent。

讨论

你们线上那扇“员工已经用得很顺”的 AI 桌面，安装包里的壳、插件和策略，是由企业自主组合、维护和发布，还是在供应商提供的范围内配置？

参考资料

1. Microsoft Learn：《Understand Shadow AI in Microsoft 365 admin center》。
2. Microsoft Learn：《Local AI agent discovery with Microsoft Defender for Endpoint》。
3. 腾讯云：《WorkBuddy》产品说明。
4. Anthropic：《Claude Cowork Enterprise Admin Guide》。
5. Anthropic Help Center：《Enterprise configuration for Claude Desktop》。
6. Rocket.Chat：《White-label Your Desktop App》。
7. electron-builder：《Configuration》中的 productName 配置说明。
8. 凡泰极客：《FinDesk 端云一体方案，让企业掌控自己的 AI 终端》。

员工用 AI 起草了一份采购申请，材料整理得更快了，接下来却仍要打开采购系统填表，到预算系统查额度，再把附件发给负责人确认。如果字段不一致、材料不齐，还得在群里来回补充。个人处理文档的时间缩短了，一项工作从发起到办完，依然可能卡在系统切换和部门交接上。

企业推进 AI 应用时，很容易先从写作、检索、总结等个人工具入手。这些能力有直接的使用价值，但一项工作通常需要多个人、多个系统共同完成。员工各自拥有 AI 助手以后，谁把整理好的信息送进业务系统，谁接收下一步任务，处理结果又回到哪里，仍然需要协同办公平台承接。

企业需要升级的，是能够让 AI 参与业务办理的协同能力。已有办公 APP 可以继续使用，OA、ERP、财务和人力系统也可以保留，在原有入口中增加 AI 交互、业务调用和结果反馈。判断是否需要建设新的工具，应该看现有平台能否接住这些能力，以及能否让各部门持续提供可复用的服务。

从个人效率延伸到业务流程效率

个人使用 AI 时，任务范围通常比较明确：整理一份资料、分析一张表、拟一封邮件，结果交给本人使用。进入组织协作后，同一份结果还需要符合业务字段、部门规则和审批要求，才能进入后续环节。生成一段采购理由，与完成一笔采购申请，中间还有预算、品类、供应商、附件和审批路径等具体工作。

如果 AI 只存在于独立聊天窗口里，员工就要承担信息搬运：把系统里的内容复制出来，再把 AI 的结果粘贴回去。每个人都在使用新工具，部门之间的信息传递方式却没有变化。要减少这种重复劳动，需要把 AI 与企业的查询接口、表单和流程连接起来，让整理好的信息能够继续被业务系统使用。

评估 AI 对一项业务的帮助时，可以看申请材料是否更完整、重复录入是否减少、退回补充的次数有没有变化，以及跨部门交接是否更清楚。这些变化比员工发起了多少次 AI 对话更接近实际效果。人工审批和专业判断继续保留，AI 优先承担查询、整理、填充和状态汇总等反复发生的工作。

围绕任务组织协同办公入口

传统办公平台按部门和系统组织入口，人力、行政、财务各有自己的菜单。员工提出的需求则经常跨越这些分类，例如“帮新同事办理入职准备”，涉及人员信息、办公位、设备领用和账号申请。员工关心的是事情有没有准备好，不愿意逐一研究每个后台的操作路径。

以新员工入职准备为例，在接入人事、行政和 IT 服务接口后，经办人可以在办公 APP 中提出办理需求，由 AI 根据入职信息和岗位要求整理待办，补充询问尚未确定的内容，再呈现设备、办公位和账号申请卡片。经办人核对后，申请分别进入已有流程，由对应部门处理。

后续进度通过业务接口查询或事件回传进入门户，经办人能够看到设备是否已分配、账号是否已开通，以及还有哪些事项需要补充。AI 可以帮助汇总当前状态、定位未完成项，跨部门任务的负责人和完成状态由企业流程系统保存。换一个人接手时，也有共同的业务记录可以查，不必从零翻阅前任的聊天内容。

员工使用的入口由此可以围绕任务组织：表达需求、补充信息、确认操作、查看结果。复杂的选择和填写仍然通过表单完成，简短的查询和进度追踪则留在会话里。聊天、页面与待办能够配合使用，员工也可以直接打开熟悉的业务页面办理。

存量系统的业务能力接入

把 AI 引入协同办公，并不要求企业重新建设所有业务后台。多年积累的账号、组织架构、审批规则和业务数据可以继续使用，新增的工作集中在如何把服务接出来，以及如何让员工通过统一入口操作。

每项业务需要提供明确的用途、输入参数、执行接口和返回结果。例如“查询设备库存”和“提交设备领用”是两个不同的动作，前者返回可用设备，后者需要申请人、用途和领用信息。项目可以用 Skill 描述或工具接口组织这些能力，让 AI 根据员工需求匹配调用，同时让业务系统按原有规则处理请求。

人力维护岗位信息和入职要求，行政维护资源与领用规则，IT 维护账号与服务流程，各部门将自己负责的业务知识和接口接入平台。规则变化以后，更新相应的知识、接口或表单，供进入同一流程的员工共同使用。经过确认的业务处理方式由此能沉淀为组织共享的服务，减少每个人重复整理资料、编写提示词和询问办理路径的工作。

跨部门的先后关系也可以沿用企业已有流程。例如必须完成入职信息确认才能开通账号，就由流程系统保留这个条件。AI 帮助员工准备和发起任务，各项工作的状态与依赖有统一记录，后续查询才能得到一致的结果。

FinClip AI+ 与办公应用的结合

在应用层，FinClip AI+ 可以为企业办公 APP 增加会话交互、上下文感知和交互式界面，结合企业模型、知识服务与业务 API，把员工的需求连接到具体服务。查询结果可以直接呈现在会话中，需要补充或核对信息时，则通过卡片、表单和业务页面继续操作。

对于已经开发好的办公模块，可以借助 FinClip 小程序容器接入统一 APP。小程序容器是嵌入宿主 APP 的运行环境，负责加载小程序代码、运行页面和业务逻辑。设备领用、会议预约、报销申请等业务可以分别作为小程序维护，员工从工作台点击进入，AI 助理也可以按配置调起同一项服务。

设备领用小程序中已有的设备列表、附件上传和确认页面，可以继续承接 AI 整理好的申请信息，员工在原有业务界面核对和办理。企业不用为了增加会话入口，再长期维护一套功能相同的办理页面。原有小程序在完成适配后可以复用，H5 和原生模块也能保留在门户中，按统一的账号与导航约定接入。

应用架构可以分工为：AI 理解需求并组织调用，业务接口负责查询和执行，小程序承接需要员工参与的交互，办公 APP 提供统一入口，原有流程系统保存处理状态。FinClip 连接应用运行与交互，企业已有系统继续承担业务处理，协同能力便能建立在存量投入之上。

面向岗位的 AI 助理与统一管理

销售、财务、行政和管理人员需要的服务不同，可以在统一办公入口中，按岗位组织 AI 助理的知识与可调用能力。行政人员常用会议、用车和物资服务，财务人员需要费用制度、预算和报销进度，管理人员更关注待办及业务汇总。员工无需从一长串工具中自行选择，门户结合企业身份和岗位提供相应服务。

岗位助理之间可以共用同一批业务接口和小程序。例如设备领用既可以由员工发起，也可以由行政人员协助准备，但执行时使用相应人员的授权范围。提交申请、变更数据等操作按企业要求保留确认，办理结果进入原有审批流程，个人的会话内容不作为全组织共享的数据源。

FinClip 支持私有化部署，小程序平台可以部署在企业指定环境中，AI 方案对接企业模型与知识服务。小程序在端侧沙箱中运行，业务访问衔接企业身份与权限体系。结合平台操作记录和业务系统日志，企业可以关联应用版本、调用记录与实际办理结果，让 AI 办公进入现有管理体系。

可持续扩展的组织服务平台

组织里的业务一直在变，协同工具也需要能持续增加服务。人力上线新的员工服务，行政调整资源申请，分支机构增加专属业务，都可以按统一规范交付小程序。FinClip 管理平台提供版本管理、审核、灰度发布、上下架和回退，企业统一管理发布过程，各团队继续维护自己负责的模块。

在宿主已提供所需能力的情况下，小程序业务更新可以独立发布，减少对主 APP 整体升级的依赖。AI 侧的工具描述、接口约定和知识内容则随业务变更同步维护，让员工从菜单进入或通过对话办理时，使用的是一致的服务。FinClip 的多端运行能力也能帮助受支持客户端复用同一套小程序资源，降低办公入口扩展时的重复建设。

平台运营可以进一步结合业务数据判断改进方向：入职准备为什么迟迟没有完成，是缺少资料、资源不足，还是任务交接不清楚；员工反复询问同一个问题，是服务入口难找，还是流程状态没有及时反馈。把这些问题持续修正，AI 的价值才能落实到具体办理过程。

企业是否需要新的协同办公工具，取决于现有平台能否支持这种服务方式。能够继续承接的入口可以升级，分散的业务则通过统一门户重新组织。借助 FinClip AI+、小程序容器和管理平台，企业可以把已有系统变成员工可直接使用、AI 可按授权调用、部门可持续维护的办公服务，让个人使用 AI 的便利延伸到跨部门协作之中。

公司已经做好的会员服务小程序，能不能同时放进 iOS、安卓和鸿蒙 APP？对业务团队来说，页面、接口和办理流程已经有了，新增一个客户端，当然希望继续使用原来的成果。按三个平台分别重写页面，后续每次修改活动规则、增加表单字段，还要再跟着维护三遍。

借助小程序容器，可以把业务页面和逻辑保留在同一套小程序代码中，由三个 APP 分别嵌入对应的小程序 SDK，提供加载和运行环境。客户端团队完成宿主接入，业务团队继续开发小程序，管理平台负责版本上传和发布。同一项业务就能进入不同系统的 APP，后续更新也有了统一的管理入口。

以 FinClip 为例，可以让三个 APP 打开同一个测试小程序，再逐步接入登录、支付等业务能力。接入示例使用官方 SDK 接口，并补充项目侧状态判断和错误处理；尖括号中的版本、凭据和服务地址需要替换成项目配置。代码放入已有宿主工程，省略工程结构及部分导入声明。

小程序与三个客户端的运行关系

小程序代码包含页面结构、样式、业务脚本和资源文件。容器在 APP 内加载代码包，提供页面渲染、脚本执行、路由、生命周期以及设备能力调用等运行支持。用户在 APP 首页点击某项服务，打开的就是运行在宿主内部的小程序页面。

iOS APP 使用 iOS 版 SDK，安卓 APP 使用 Android 版 SDK，鸿蒙 APP 使用 HarmonyOS 版 SDK。各端运行时对接自己的系统环境，向小程序提供相应的组件和接口，业务开发者可以复用页面布局、表单校验、查询逻辑和后端请求。三端共用业务代码，各自保留原有客户端工程和原生导航。

例如，会员积分小程序里有积分明细、兑换列表和订单详情。业务团队维护一套页面，三个客户端都从各自的入口打开它。积分怎么计算、订单怎么生成仍由原有业务后台处理，小程序容器负责让页面在不同 APP 中运行。

平台配置与小程序准备

开始集成前，需要在 FinClip 管理平台创建小程序，取得平台分配的小程序 AppID，再配置宿主应用及各端应用标识，获取相应的 SDK Key 和 SDK Secret。小程序还要与允许承载它的宿主应用建立关联，客户端才能按平台配置打开服务。

接入时可以把信息分成两组：SDK 初始化使用宿主凭据和平台服务地址；打开具体业务时使用小程序 AppID、目标页面与业务参数。宿主凭据标识的是哪个 APP 在接入平台，小程序 AppID 标识的是要运行哪一项业务，两者在工程配置中分别维护。

已有微信小程序可以导入 FinClip 开发者工具，检查组件和 API 兼容情况，复用受支持的页面与逻辑。登录、支付、消息以及微信云开发等平台相关能力，需要对接自有 APP 和后端服务。为了验证 SDK 接入，先准备一个只显示入口参数的小程序页面，避免把容器接入与业务接口问题混在一起。

共用测试小程序

在小程序项目中注册 pages/index/index。项目侧测试示例的 app.json 如下；已有工程只需合并页面配置。

{

  "pages": ["pages/index/index"],

  "window": {

    "navigationBarTitleText": "多端运行测试"

  }

}

pages/index/index.js 读取启动参数，pages/index/index.wxml 将参数显示出来：

Page({

  data: { source: '未传入' },

  onLoad(options) {

    this.setData({ source: options.source || '未传入' });

  }

});

<view>

  <text>小程序已打开，入口参数：{{source}}</text>

</view>

用开发者工具编译并上传代码包，完成审核、上架和宿主关联。三端示例统一使用同一个 <MINIAPP_ID>，通过 source=ios、source=android、source=harmony 区分入口。source 只是客户端传入的测试标记，不代表系统检测结果。示例按 AppID 打开正式版；体验版和开发版应使用对应的二维码打开接口，并配置体验成员。

iOS：依赖引入、初始化与打开页面

在现有 Podfile 的 APP target 中加入官方依赖，将 <IOS_SDK_VERSION> 替换为选定版本，执行 pod install，再通过生成的 .xcworkspace 打开工程。

pod 'FinApplet', '<IOS_SDK_VERSION>'

在 AppDelegate 的应用启动方法中加入初始化片段。示例使用 Objective-C；Swift 工程可以按官方集成方式导入同一 SDK，再按 Swift 调用形式接入。

#import <FinApplet/FinApplet.h>



// 放在应用启动方法内，初始化一次。

FATStoreConfig *store = [[FATStoreConfig alloc] init];

store.sdkKey = @"<IOS_SDK_KEY>";

store.sdkSecret = @"<IOS_SDK_SECRET>";

store.apiServer = @"<FINCLIP_API_SERVER>";



FATConfig *config = [FATConfig configWithStoreConfigs:@[store]];

NSError *initError = nil;

BOOL ready = [[FATClient sharedClient] initWithConfig:config

                                               error:&initError];

if (!ready) {

    NSLog(@"小程序 SDK 初始化失败：%@", initError);

}

宿主保存初始化结果，成功后启用业务入口。在当前可见的 UIViewController 中响应按钮点击，使用 FATAppletRequest 指定小程序和目标页面。代码中的 self 是当前页面控制器，打开操作在主线程执行。

FATAppletRequest *request = [[FATAppletRequest alloc] init];

request.appletId = @"<MINIAPP_ID>";

request.apiServer = @"<FINCLIP_API_SERVER>";

request.startParams = @{

    @"path": @"/pages/index/index",

    @"query": @"source=ios"

};



[[FATClient sharedClient] startAppletWithRequest:request

    InParentViewController:self

    completion:^(BOOL result, FATError *error) {

        if (!result) {

            NSLog(@"小程序打开失败：%@", error);

        }

    }

    closeCompletion:^{

        NSLog(@"已返回宿主页面");

    }];

测试页显示 ios，即可确认代码包加载、页面跳转和参数传递已经连通。接入相机、定位等业务时，再补充相应权限描述和扩展模块。

安卓：初始化状态与业务入口

按官方集成指引配置 FinClip Maven 仓库后，在 APP 模块的 build.gradle 中加入 SDK 依赖。仓库地址与访问配置由工程维护，<ANDROID_SDK_VERSION> 替换为项目使用的固定版本。

dependencies {

    implementation 'com.finogeeks.lib:finapplet:<ANDROID_SDK_VERSION>'

}

同时按该版本接入文档配置原生库打包与混淆规则，在使用代码压缩的工程中加入：

-keep class com.finogeeks.** {*;}

初始化放入宿主现有 Application。Kotlin 示例使用 FinStoreConfig、FinAppConfig、FinAppClient 和 FinCallback 的官方接口；类名 HostApplication、状态字段及提示语是项目侧示例，导入声明由 IDE 从已安装 SDK 补齐。若项目已有 Application，将字段和初始化逻辑合入原类，并确认 Manifest 指向该类。

class HostApplication : android.app.Application() {

    @Volatile var finclipReady = false

        private set



    override fun onCreate() {

        super.onCreate()

        if (FinAppClient.isFinAppProcess(this)) return



        val store = FinStoreConfig(

            "<ANDROID_SDK_KEY>",

            "<ANDROID_SDK_SECRET>",

            "<FINCLIP_API_SERVER>",

            "<FINCLIP_APM_SERVER>",

            "/api/v1/mop/",

            "",

            "MD5",

            false,

            true

        )

        val config = FinAppConfig.Builder()

            .setFinStoreConfigs(listOf(store))

            .build()



        FinAppClient.init(this, config, object : FinCallback<Any?> {

            override fun onSuccess(result: Any?) {

                finclipReady = true

            }

            override fun onError(code: Int, error: String?) {

                finclipReady = false

                android.util.Log.e("FinClip", "初始化失败：$code $error")

            }

            override fun onProgress(status: Int, info: String?) {}

        })

    }

}

MD5 是示例中的 SDK 通信配置值，需要与平台配置一致；末尾两个布尔值分别关闭返回数据加密、开启基础库预加载。APM 地址填写平台的数据上报地址。进程判断也应覆盖其他宿主级初始化，避免小程序进程重复启动整套业务组件。

Activity 的按钮点击处理使用真实的 startApplet 接口。只有初始化成功才继续打开，失败结果交回当前页面处理。

val app = application as HostApplication

if (!app.finclipReady) {

    android.widget.Toast.makeText(

        this, "小程序服务尚未就绪", android.widget.Toast.LENGTH_SHORT

    ).show()

} else {

    val request = IFinAppletRequest.fromAppId(

        "<FINCLIP_API_SERVER>", "<MINIAPP_ID>"

    ).setStartParams(mapOf(

        "path" to "/pages/index/index",

        "query" to "source=android"

    ))

    FinAppClient.appletApiManager.startApplet(

        this, request, object : FinCallback<String?> {

            override fun onSuccess(result: String?) {}

            override fun onProgress(status: Int, info: String?) {}

            override fun onError(code: Int, error: String?) {

                android.util.Log.e("FinClip", "打开失败：$code $error")

            }

        }

    )

}

打开接口接收当前 Activity，测试页应显示 android。初始化成功却打不开时，优先核对小程序发布状态、关联关系和请求的服务地址。

[[RYAN_FINCLIP_GHOST_IMAGE_02]]

鸿蒙：HAR 依赖与 Navigation 接入

鸿蒙可以采用线上依赖或本地 HAR 包。以本地包为例，将同一交付版本的 FinClipSDK.har 和 FinClipSDKCore.har 放进工程根目录的 har 文件夹，在 entry/oh-package.json5 中合并：

{

  "dependencies": {

    "@finclip/sdk": "file:../har/FinClipSDK.har"

  }

}

在工程根目录的 oh-package.json5 中合并底层依赖覆盖配置，随后执行 ohpm install：

{

  "overrides": {

    "@finclip/sdk-core": "file:./har/FinClipSDKCore.har"

  }

}

依照接入指引，在根目录 build-profile.json5 的目标 app.products 元素内合并配置；JSON 片段均保留工程已有字段：

{

  "buildOption": {

    "strictMode": {

      "useNormalizedOHMUrl": true

    }

  }

}

entry/src/main/module.json5 的 module.requestPermissions 中至少配置网络权限：

{

  "name": "ohos.permission.INTERNET"

}

启动方式采用官方 Navigation 方案，该方式文档标注最低支持 SDK 1.1.0。小程序使用宿主已挂载的 NavPathStack 打开，因此无需额外注册承载小程序的 Ability。将示例加入工程已登记的入口页面，已有 Navigation 工程则复用自己的页面栈。

import common from '@ohos.app.ability.common';

import {

  EAppletStartMode, FinAppClient,

  IFinAppConfig, IFinAppStartMode

} from '@finclip/sdk';



@Entry

@Component

struct Index {

  @State pageInfos: NavPathStack = new NavPathStack();

  @State status: string = '等待打开';

  client?: FinAppClient;



  async openMiniProgram() {

    try {

      if (!this.client) {

        const config: IFinAppConfig.IFinAppConfig = {

          finStoreConfigs: [{

            apiServer: '<FINCLIP_API_SERVER>',

            sdkKey: '<HARMONY_SDK_KEY>',

            sdkSecret: '<HARMONY_SDK_SECRET>',

            cryptType: 'md5'

          }]

        };

        const mode: IFinAppStartMode = {

          startMode: EAppletStartMode.Navigation,

          routerState: this.pageInfos,

          uiContext: this.getUIContext()

        };

        this.client = FinAppClient.init(

          config,

          getContext(this) as common.UIAbilityContext,

          '',

          mode

        );

      }



      this.status = '正在打开';

      await this.client.startApplet({

        appId: '<MINIAPP_ID>',

        apiServer: '<FINCLIP_API_SERVER>',

        startParams: {

          path: '/pages/index/index',

          query: 'source=harmony'

        }

      });

      this.status = '打开调用已返回，请检查小程序页面';

    } catch {

      this.status = '调用异常，请查看 SDK 日志后重试';

    }

  }



  @Builder

  PageMap(name: string) {

    // 在已有工程中保留宿主原有的页面路由映射。

  }



  build() {

    Navigation(this.pageInfos) {

      Column({ space: 16 }) {

        Text(this.status)

        Button('打开测试小程序')

          .onClick(() => { this.openMiniProgram(); })

      }

    }

    .mode(NavigationMode.Stack)

    .id('root')

    .title('小程序接入测试')

    .navDestination(this.PageMap)

  }

}

openMiniProgram 是页面自定义方法，内部调用的是 SDK 的 FinAppClient.init 和 startApplet。初始化在用户点击后执行，此时页面已经创建，能够提供 UI 上下文；routerState 与页面上的 Navigation 使用同一个实例。示例将通信方式显式设为 md5，实际值按平台配置填写。已有工程统一保存客户端实例，不随页面重建重复初始化 SDK。

点击按钮后，小程序应显示 harmony。startApplet 的调用返回并不单独作为页面成功展示的证据，实际验收以测试页出现、参数正确和 SDK 日志为准。

宿主登录与设备能力对接

小程序页面能够打开后，接下来要让它接上 APP 已有的业务环境。比如用户已经登录 APP，进入会员小程序时，应该能够继续查询自己的积分和订单，无需再走一遍注册流程。

项目可以通过容器提供的扩展机制，把获取业务登录态、发起支付、打开原生页面等操作封装为统一的宿主能力。小程序调用约定接口，各端宿主分别完成原生实现，再按一致的数据结构返回结果。登录过程由企业账号服务衔接，业务后台继续校验用户身份和访问权限。

对于扫码、拍照、定位等能力，三个客户端需要分别配置系统权限、接入相关 SDK 模块。业务侧保持统一的调用约定，平台差异由运行时和宿主适配处理。后续再增加新的小程序时，已经接好的登录、支付和设备能力就能继续复用。

返回行为也要与 APP 原有体验接上：小程序内部返回上一页，退出小程序则回到宿主入口；业务完成后需要刷新原生列表的，由宿主接收办理结果并更新页面。用户感受到的是同一个 APP 内连续的服务流程。

三端联调与发布检查

三台设备使用同一个小程序 AppID，分别从宿主按钮打开测试页。先看页面能否显示，再核对参数和返回行为，比直接接入完整业务更容易定位接入问题。

测试页通过后，将相同的打开方式接到首页宫格、活动位或消息入口，再把目标路径换成真实业务页面。例如订单消息可以携带订单标识，直接进入详情页。随后在三个宿主中完成登录、查询、提交、返回的全流程，检查设备授权、网络中断和前后台切换。错误日志同时记录宿主版本、SDK 版本及小程序版本，方便区分客户端接入问题和业务更新问题。

统一发布与业务独立更新

三端接入完成后，小程序代码包进入同一个管理平台，经过体验验证、审核和发布，再由各端 SDK 获取适用版本。团队可以统一管理小程序资产，也可以通过灰度策略控制新版本的发布范围，结合各端测试结果逐步上线。

日常调整会员页面、增加活动专区、修改表单等业务更新，只要使用的能力已由当前宿主和运行时提供，就可以走小程序发布流程，无需等待三个主 APP 同步发版。容器 SDK 升级、新增原生能力等宿主工程变更，继续走各客户端的构建和发布流程。

业务更新与客户端更新分开后，团队的协作方式也会随之变化：业务开发人员维护共用的小程序，客户端人员维护各端运行环境和公共能力，运营人员在平台查看版本、审核和上线状态。新增业务可以继续接入现有容器，已有微信小程序资源也能在完成适配后加入自有 APP。

FinClip 将三端运行 SDK、开发者工具和管理平台连接起来，让同一套小程序拥有跨客户端运行和持续发布的能力。企业保留各端 APP 已有的原生体验，同时把频繁变化的业务交给共用小程序承载，减少重复开发，让功能上线与日常维护围绕同一份业务成果推进。

今年，很多APP运营团队都有降本增效的需求：希望把企业自己的部分业务转成独立小程序，放进自有 APP 里运行。内部服务运营起来以后，再引入外部小程序，让合作方入驻并持续维护自己的服务。

对企业来说，内部业务拆分与外部生态接入可以采用同一套技术架构。活动、会员、商城等业务先从主工程中独立出来，拥有各自的开发和发布节奏；合作方加入后，也按相同规范提供小程序。APP 团队维护公共能力，业务团队维护功能，运营人员通过后台管理上线与分发，服务增加时不必反复调整整套客户端工程。

FinClip 通过小程序容器 SDK、开发者工具和小程序管理平台，把开发、运行与运营管理连接起来，支持企业从自有业务的小程序化，逐步扩展到多团队、多来源服务共同运营的超级 APP。

业务小程序化与主工程解耦

企业可以把活动专区、会员权益、在线商城、预约报名等业务封装成独立小程序。每个小程序有自己的页面、交互逻辑和代码包，原有业务系统继续提供数据和接口。客户端集成 FinClip 小程序容器后，就具备了加载和运行这些业务模块的能力。

以活动专区为例，活动列表、详情、报名表单和结果页面可以由一个小程序承接。活动团队调整页面和交互时，独立完成开发、测试与版本提交，APP 主工程集中维护账号、导航、消息和设备能力。在宿主已支持的能力范围内，业务更新通过小程序发布完成，减少对 APP 整体发版的依赖。

用户从首页、服务中心或活动入口进入小程序，业务页面直接在企业 APP 内运行。企业可以把登录、扫码、定位等公共能力接入容器的宿主扩展体系，供不同小程序复用，让业务团队按照共同的接口规范开发，减少重复接入工作。

已有小程序资产也可以通过 FinClip 开发者工具进行兼容性扫描、预览和真机调试，复用已支持的页面、组件与业务逻辑。对于原生和 H5 业务，则可以保留既有后端，按小程序形态调整前端页面与交互，把改造工作集中在需要独立运营的模块上。

独立开发与版本发布

FinClip 为小程序提供从代码编译、预览调试到上传发布的工具支持。开发人员可以在开发者工具中维护项目，上传时选择对应的小程序并填写版本信息，代码包随后进入管理平台，供测试、审核和发布使用。

平台区分体验版本、审核版本与线上版本。业务团队可以先将指定代码包配置为体验版，邀请相关人员验证页面和业务流程；确认完成后提交审核，再发布为线上版本。运营与研发围绕同一个版本协作，能够查到准备上线的内容、已经发布的包，以及历史审核记录。

一个 APP 内的多个小程序可以分别维护版本。会员专区更新权益页面，不必等待活动专区同步修改；合作方服务发布新功能，也可以沿用自己的开发节奏。业务包按需加载，页面资源随小程序分发，主工程不必持续装入所有业务模块。

新增原生能力、调整系统权限和升级容器 SDK 继续由 APP 团队统一交付，业务页面则使用独立的小程序发布通道。两条通道配合，让客户端保持稳定，也让日常功能迭代更灵活。

云端管理与运营调整

FinClip 管理平台集中管理小程序名称、图标、分类、简介、代码包和版本信息。运营人员可以查看服务状态，安排审核与上线，并通过历史记录追溯版本变化。原本分散在各业务团队中的交付信息，汇集到同一个管理入口。

针对新功能发布，平台提供灰度管理能力，可以按配置的规则与发布计划控制版本分发范围。企业能够先观察部分用户的使用情况，再扩大新版本覆盖范围；需要调整时，可以下架服务或回退到已验证版本，为日常运营提供明确的操作手段。

小程序版本管理还可以与现有业务后台配合。活动素材、商品和权益内容继续由对应系统维护，页面结构与交互逻辑通过小程序更新。运营人员沿用已有内容管理方式，同时获得独立的应用发布能力，业务后台与小程序平台各自承担清晰的管理工作。

在运行观测上，可以结合容器运行信息、应用日志和业务埋点，按小程序与版本分析加载情况、页面异常和业务转化。出现问题时，运营能够找到对应的服务与维护团队，开发人员也有具体版本和运行记录可供排查。

第三方入驻与自主维护

企业准备引入外部服务时，可以把已有的小程序交付流程开放给合作方。合作方以团队形式参与，维护自己的小程序，企业则集中管理服务准入、宿主关联与发布。内部业务和外部服务使用共同的运行环境，接入数量增加后仍然有统一的管理方式。

FinClip Cloud 将开发者侧与生态运营侧分为开发中心和数字中心。开发中心用于开发者管理小程序及宿主应用，数字中心用于生态运营方开展全局管理。企业可以通过团队、角色与成员配置组织协作，按项目要求分配管理后台和开发者工具的操作权限。

合作方获得授权后，可以自行维护服务信息、上传代码包、安排体验测试并提交审核。企业运营方负责审核与发布管理，合作方修改页面时，无须每次都把代码交给 APP 团队重新集成。通过这套协作方式，服务维护工作留在熟悉业务的团队手中，企业也能持续掌握线上内容和版本状态。

平台中的宿主关联用于管理小程序可以在哪些 APP 中运行。企业可以围绕自己的服务生态组织接入，将适合的会员权益、内容、营销或生活服务引入 APP，并通过共同的开发与审核规范维持服务体验。

服务入口与公共能力复用

第三方服务进入 APP 后，可以与内部业务一起组织到首页专区、服务目录或应用中心。平台维护小程序基本信息与发布状态，宿主 APP 结合服务分类、用户身份和运营配置展示入口，让用户在原有使用路径中发现和打开新服务。

企业既可以让高频服务保持直接入口，也可以把更多小程序集中到分类目录和搜索页面中。新增服务时，通过服务标识和页面路径完成入口关联，已有导航与公共能力可以继续复用，为 APP 持续扩充内容和功能留出空间。

FinClip 的小程序运行环境、域名管理与宿主能力调用机制，可以与企业已有的身份和权限体系结合，组织不同服务的访问范围。合作方按约定使用公共能力，用户在 APP 内完成登录和业务操作，后端系统继续处理订单、报名和履约结果。

当服务需要覆盖多个客户端时，FinClip 的多端运行能力还可以支持业务代码复用。完成对应终端的容器接入与必要适配后，同一小程序业务可以在不同客户端延伸，减少每增加一个终端就重新建设整套业务页面的工作。

从自有业务运营到企业服务生态

对于APP运营方来说，FinClip 提供的是一条能够连续扩展的产品路径：内部业务通过小程序独立开发和更新，管理平台承接版本与发布，外部合作方再沿用共同规范入驻。企业可以先把自己的业务运营方式建立起来，再根据服务需求增加合作方，无须为生态接入重新设计一套运行架构。

APP 团队、业务团队和运营团队也因此有了更清楚的分工。客户端集中建设公共能力，内部与外部团队持续提供业务小程序，运营方统一组织服务和发布。随着小程序逐步丰富，企业 APP 可以从承载自有功能的客户端，发展为汇集多方服务、支持持续运营的超级 APP。

每个省市都有自己政务APP门户化建设的需求，核心还是希望让市民需要一个入口，就能办完各个部门的事情。

但现实情况是，市民希望入口集中，不用在小程序、公众号和H5页面之间来回切换、反复登录；而各个业务部门那边却各有各的现实，服务由不同供应商开发，迭代节奏也不一样，有的事项一年只改几次，有的专区每周都在调整。如果把几十项服务全部收进 APP 主工程，所有部门的页面变更都得排队等客户端版本，改一个表单字段也要等发版窗口。

难的不只是APP开发，更需要关注如何资源整合

如果只是客户端开发，做一个政务 APP 并不难。难的是建成以后，怎么长期容纳多个部门的服务而不失控。

通过原生方式集成，各部门的业务代码会持续汇入主工程。一方面APP包会越来越大，但更麻烦的在协作上：任何部门改一个页面，都要经过主工程的合并、构建和回归测试，再走应用市场上架；一个部门的服务延期，可能拖累整个版本；某次更新出了问题，受影响的也不止那一家。

同时供应商关系也会遇到管理问题，统一身份是一家单位建的，事项系统来自另一家厂商，部门小程序还有各自的服务商在维护。谁能提交代码，谁负责审核，线上跑的是哪一版，出故障怎么快速停掉——这些事如果靠群聊和发文件来对齐，服务一多肯定乱。

所以门户项目要同时解决两个问题：服务以什么形态进 APP，多部门的版本和发布又归什么规则管。前者是技术选型，后者是治理设计，缺一个都转不长。

通过小程序容器来实现APP解耦

门户APP做宿主，承载各部门都要用的公共能力，比如统一实名认证、服务目录和消息中心，外加系统权限和设备能力。这一层求稳，不跟着单个部门的服务调整频繁发版。

小程序容器集成在门户里，负责把各部门的小程序跑起来。小程序运行依赖逻辑层和视图层两套线程，JS 引擎执行业务脚本，WebView 渲染页面，代码包加载、路由和生命周期调度都归容器管。用户从服务目录点开某项服务，宿主把小程序标识和页面参数交给容器，剩下的运行在 APP 内完成。

管理平台在服务端，管小程序资产和版本。一个小程序归哪个部门，线上跑的是哪一版，谁提交过、谁审核过，平台都记着。治理的细节放到下一节说。

各部门原有的业务系统继续管权威数据。预约成没成功、办件流转到哪一步，仍由对应事项系统判断。门户建设不用复制一套业务后台，这一条对控制项目规模很实在。

已有小程序如何进行复用已有资源

现在各个部门都有自己的H5、小程序页面，是门户APP应该利用起来的存量资产，其实这些内容，开发层面并不复杂，主要是数据积累和接口对接需要大量的时间和人力成本。

而FinClip的解决方案比较现实，就是兼容微信小程序的语法，只要微信APP中能够运行的小程序，都可以运行在自有的APP中，能够大幅度减少二次开发的成本。

解决了前期的接入工作后，更需要关注的是如何长期的运维，这部分主要是依靠云端的管理平台。

平台上要为门户 APP 创建宿主应用并绑定 Bundle ID，关联后下发的 SDK Key 和 SDK Secret 会在 SDK 初始化时校验。小程序必须完成与宿主应用的关联才能在 APP 里打开，没授权的应用跑不了这些服务。门户里有哪些服务、来自哪里，因此是受控的。

版本流转走固定流程。部门用开发者工具上传代码包，先设成体验版本，让指定成员扫码验证；再提交审核版本走内部审核；通过后上架为线上版本，也可以设置审核通过后自动上架。每次提交和审核都会留下历史记录，事后查得到。

新版本上线前可以先灰度。平台按“规则配置加发布计划”的方式实现：规则条件可以按机型和网络这类属性圈定范围，也可以按基础库或 SDK 版本区分，先让小范围用户接触新版本，验证符合预期再扩大。有个前提要注意，灰度的小程序得有一个通过审核但暂未上架的版本，而且版本号不能低于当前线上版本。

万一新版本有问题，退路也是现成的。线上版本可以直接下架，用户立刻打不开；也可以回退到最近发布或已回退过的历史版本，目前最多支持回退 5 个，回退本身不需要重新审核。加载速度敏感的高频服务，还能导出离线包随 APP 打包，用户首次打开直接从本地加载。

这几条加起来，效果是这样的：部门保留自己的提交和迭代动作，门户运营方握着审核、发布范围和止损手段。权责分得开，出了问题也收得住。

如何实现上线发布的统一管理

集中运行之后，更新分两条通道。

部门服务的业务更新，比如事项规则调整、专区页面上线，走小程序版本的审核和发布，不占 APP 的发版窗口，部门之间也不用互相等。

门户自身的变更，比如升级容器 SDK、新增系统权限，仍然进客户端版本流程。

通道分开是这套结构能长期运转的前提。业务更新不再挤进主工程排队，客户端团队也不用为页面调整反复集成发版。反过来，部门同样没法借小程序通道绕过宿主侧的变更管理，边界对双方都成立。

更核心的还是实现运营层面的优化提升

市民只装一个 APP，各部门的服务都在里面，实名一次、消息一处，办事不再需要在小程序、公众号和 H5 页面之间来回找入口。

部门保留了原来的开发方式。小程序该怎么写还怎么写，版本该怎么发还怎么发，只是运行位置从微信换到了门户，发布动作从各自为政变成走统一的审核流程。业务更新不再排队等 APP 发版，一个专区页面今天提审，明天就能上线。

门户运营方拿到的是完整的管理手段：哪些服务能进来，每个版本发到什么范围，出了问题怎么退，都有明确的操作和记录。对整个项目来说，更实在的收益是建设账好算了，已有的微信小程序大量复用，新增服务按统一规范接入，重复建设的空间一点点被挤掉。

入口统一了，部门的迭代节奏还在，治理也收得住。这就是小程序容器对移动政务门户的价值。

今年3月开始，陆续听说好几家券商发了内部通知，不让员工在工作电脑上私自安装 OpenClaw、Hermes 这类智能体工具。理由也能理解：这些 Agent 拿着系统级权限在本地直接跑命令，没有隔离，没有审计，被提示词注入带偏一次，动的是整台机器和内网。但说实话，禁令治标不治本，员工想用 Agent 提效这个需求是压不住的。

今天分享一下最近看到的一个支持深度定制的Agent客户端——FinDesk。

整个技术架构可以拆成四层来讲：安全底座、Agent运行时、私有插件、白牌发行。看完会发现，企业级 Agent 终端这件事，工程上已经有比较成熟的打法了。

第一层：给 Agent 进程单独修一个沙箱

浏览器早就有沙箱，网页里的 JS 再嚣张也越不出渲染进程。桌面 Agent 麻烦在它天生就要读文件、跑命令、调接口，权限给小了干不了活，给大了等于把主机交出去。琢磨下来，靠谱的思路就是照抄浏览器的作业：给 Agent 进程单独建一道 OS 级的围栏。

FinDesk 里的 FinSafe 模块就是这么干的，按"一次执行 = 一个沙箱 = 一套策略"来组织。每次执行任务之前，先按策略把能力收窄：文件只能读写哪几个目录、网络只允许访问哪些域名、CPU 和内存上限多少，收窄完了再执行，策略没覆盖的操作默认拒绝。这跟传统安全软件"先放行、再查黑名单"的路子是反的，对 Agent 这种行为没法完全预测的东西，反过来才对。

还有两个细节印象比较深。一个是策略由中央统一签发、带签名，员工本机改不了，不会出现"沙箱还在、策略被人关了"的尴尬。另一个是每次执行都会产出一份审计信封和策略指纹，能直接对接企业的 SIEM，出了事可以举证，平时内审和监管要看也有东西给。另外它是进程级隔离，不用套容器和虚拟机，启动开销低很多，macOS、Windows、Linux 三端都是原生实现。别小看这一点，一个启动要等十秒的工具，推广的时候会被员工用脚投票。

第二层：运行时必须能换

选终端的时候有个坑很多人没注意：Agent 技术还在快速演化，今年选定的引擎，明年可能就不是最优解了。终端要是跟某个 Agent 绑死了，换引擎就等于换终端，安全体系和治理流程全部重来一遍，这买卖太亏。

FinDesk 把运行时做成了可替换的一层，这点很认可。FinClaw 内置在终端里，本地和云端引擎在对话中就能切换；员工 PATH 上已经装好的 Hermes、OpenClaw 或者其他兼容 ACP 协议的 CLI，终端会自动检测接管。说白了一句话：换 Agent 不动安全体系，换模型不动治理体系，之前在工具上投的钱都还在。对 IT 部门来说，这也意味着可以先纳管存量、再慢慢收敛，犯不着一上来就推倒重来。

第三层：把业务能力做成自己的插件

之前跟几个金融行业的朋友聊，他们用通用 AI 助手最大的别扭在于：数据接口、合规审核流程、内部研究工具这些真正值钱的东西，通用产品给不了；而数据终端厂商那边，功能定义权又攥在人家手里，想加个自己的流程都没门。

插件化是目前看到的比较合理的出路。机构把自己的业务做成源码级的私有插件：合规流程里的审核节点、留痕要求、人工确认点，直接做成插件能力，不用再靠贴在流程外面的规章制度去约束人；行情、资讯、内部知识库走 MCP 插件接进来。关键是插件源码归机构自己，随发行仓签名打包、锁定版本，平台方不会把这些代码合并回公共版本。时间一长，这批插件就是机构自己攒下来的能力资产，这跟买数据终端那种"功能由厂商定义"的关系完全两码事。

交易能力也是同样的处理。FinDesk 把股票、债券、基金、衍生品这些交易抽象成了可插拔的底座，机构接自家的柜台接口就行。桌面端还带了 Office、邮件、企业知识库、IM 这些内部系统的连接器，Agent 能在真实的企业环境里干活，不会被困在一个孤立的聊天窗口里。

第四层：白牌发行，属于自己终端

最后一层最容易被低估，就是完全自主可控，企业级终端得有自己的品牌、自己的签名、自己的更新通道，数据和配置还要跟其他客户完全隔离。按传统打法，这得找厂商定制开发，周期长不说，以后升级还得跟着人家的节奏走。

FinDesk 的思路就是：底座统一维护，企业拿一份 Desktop SDK，在自己的发行仓里装配品牌视觉、私有插件和配置，pin 住一个底座版本号，就能打出完全独立的品牌安装包。以后底座升级，改一行版本 pin、重新出包就完事，发布节奏自己说了算。整个流程压到了五步：从 findesk-std 脚手架初始化发行仓，拉官方 CLI 搭开发环境，借助内置 Skill 写业务插件，替换 UI 皮肤和产品命名，打包发布。交付上也照顾了金融行业的实际情况，在线 Releases 和离线介质两条通道都有。

这套模式说白了就是分工：治理、安全、发行这些重复建设没意义的部分，做成基础设施；品牌、插件、业务这些各家最不愿意交出去的东西，留给企业自己。

落地建议

如果团队就几个人各自用用 AI 助手，通用产品开箱即用确实够了。可一旦 Agent 要进正式业务流程，碰到客户数据、交易操作、合规要求，治理碎片化、安全缺位、品牌让渡这三个问题会一起冒出来。到那时候再补，成本远比一开始选一个可治理的底座高得多。

建议就是，可以先拿一个低风险的团队试点，把存量 Agent 纳管起来、安全策略跑起来、审计链路验证通，再去谈私有插件和专属发行。底座的价值要等规模上来才看得出来，第一天就追求全套没必要。

现在很多公司都希望通过引入AI提高企业效率。模型账号开通了，知识库和Agent也开始试点，业务部门很快就能感受到内容生成、材料整理和信息检索速度的变化。与此同时，AI技术本身还在快速更迭：模型效果和价格不断调整，Agent框架持续变化，客户端与运行方式也未完全定型。

这会带来一个比选型更长远的问题。假如企业一年后更换模型，或者从一种Agent运行时迁移到另一种实现，今天投入的人力和业务经验还能留下多少？如果项目沉淀的只有一组绑定特定模型的提示词、若干临时脚本和供应商掌握的配置，技术升级很可能意味着重新开始。

企业AI建设真正值得积累的内容，应当能够穿越这类变化。业务对象的定义需要留下，例如什么是有效客户、合格供应商或高风险合同；岗位方法和判断规则需要留下；连接OA、ERP、CRM等系统的工具契约需要保持稳定；真实案例形成的评估样本，以及维护人、权限和审批责任，也应进入企业自己的资产体系。

基于目前的技术来看，Skill可以取代SOP，成为这些内容的任务级载体。它把一类工作所需的方法、规则、工具和交付标准组织在一起，让Agent知道怎样完成任务，也让企业知道这项能力由谁维护、能够在哪些范围运行。底层模型可以更换，Skill需要重新测试和适配，但企业已经确认的做事方法不必随之丢失。

企业要留下的是能力结构

以供应商准入审查为例。制度文件进入知识库后，Agent通常已经能够回答需要提交哪些材料，真正拿到一份申请时，输出仍可能不稳定。

资深审核人员会先判断供应商类型，再选择审查路径；普通信息缺失可以补交，股权关系异常则需要升级处理；遇到历史风险记录，还要结合解除时间和内部处置意见判断。这些分支散落在系统字段、项目记录和个人经验中，知识库只能帮助Agent找到材料，无法自动补齐做事方法。

长期沉淀也不等于把所有内容都塞进Skill包。业务数据仍由相应系统管理，知识材料留在知识库，工具接口由平台维护。Skill保存的是它们在一类任务中的组合关系：需要什么输入，按什么顺序处理，调用哪些企业能力，结果达到什么标准，以及在哪个节点必须交回给人。这样的能力结构比单份文档更容易复用，也比一套完整应用更轻。

文档保存信息，Skill定义执行合同

SOP面向人，允许读者结合经验理解省略部分；Skill面向Agent，任务边界必须更明确。一个供应商审查Skill需要说明材料从哪里取得，怎样识别供应商类型，哪些信息要交叉核验，什么时候停止自动处理，以及结果交给谁确认。

因此，把文档改写成更长的提示词，并不能完成资产化。企业需要把不同形态的经验转换成可维护对象：

Agent可以选择合适的推理过程，但不能随意改变数据范围、工具权限和业务责任。

经验梳理要从真实任务开始

直接询问专家“你通常怎么做”，得到的多半是原则。更有效的方式，是选择近期完成的任务逐步复盘：当时为什么先看某个字段，在哪一步打开了内部系统，哪些情况没有继续自动判断，最终意见为何被修改。

多次复盘后，项目团队才能区分三类内容。已经形成共识的规则可以直接封装；依赖业务语境的判断可以让Agent生成候选意见；尚未稳定或涉及责任决策的部分继续由人处理。Skill边界可能因此变窄，但验收标准会清楚很多。

这一过程还会暴露流程本身的问题。有些SOP多年没有更新，实际操作已经变化；有些规则在不同部门存在两种解释；还有些步骤依赖某位员工的个人账号。Skill开发并非机械复制现有流程，它迫使企业确认哪套方法可以被正式发行。

一个可发行的Skill包里有什么

企业Skill可以采用yaml的方式描述自身，例如：

name: supplier_review

owner: procurement_risk_team

inputs: [supplier_profile, submitted_documents]

tools: [registry_query, internal_risk_records]

policies: [data_scope, escalation_rules]

human_checkpoints: [final_review]

outputs: [review_summary, missing_items, risk_evidence]

owner回答由谁维护，tools列出外部依赖，policies限定执行范围，human_checkpoints保留人工责任，outputs则保证结果可以被后续流程接收。真正的Skill包还应包含任务说明、规则文件、输出模板和测试样本，复杂场景可以加入脚本或插件，但这些内容仍受同一份清单约束。

工具接口尤其需要收敛。Skill调用的应是“查询供应商风险记录”这样的业务能力，不应直接持有数据库账号或任意API权限。接口需要限定输入、返回字段和凭据使用方式，调用失败时也要给出确定的处理路径。这样即使Skill方法不断调整，底层系统仍然保持自己的安全边界。

模型会变化，业务方法应尽量保持稳定

模型和Agent运行时仍在快速更新。企业今天可能使用OpenClaw，下一阶段接入Hermes，之后还会出现其他实现。如果业务规则、模型调用和工具协议写在一起，更换技术底座就意味着重新整理一遍Know-How。

Skill应保留岗位方法和输出标准，模型选择交给运行平台，系统连接收敛到稳定工具接口，再由Agent适配层处理不同运行时的差异。切换模型或Agent后，兼容性和结果质量仍要重新测试，但已经确认的业务步骤、权限边界和责任关系可以继续使用。

这种解耦决定了Skill能否成为长期资产，企业真正持有的是“一类任务应该怎样完成”，不必把方法绑定在某一代模型或某一种Agent框架上。

通过发行治理进入企业能力库

通过测试的Skill还要进入组织内的发行流程。平台需要记录维护人和版本，控制可见范围，并保留提交、审核和安装记录。业务规则变化后，新版本应先在限定范围验证，再替换正在使用的版本；失去维护或长期异常的Skill需要停用，而不是继续留给员工调用。

FinClaw技能中心提供企业内部的提交、审核和上架入口，技能可按组织或角色控制可见范围，并保留版本历史、审计记录与安装统计。经过审核的Skill可以安装到对应数字员工，使岗位能力与具体使用范围建立关联。

过去的软件资产通常对应应用系统、源代码或许可证。Agent进入企业后，一部分业务需求可以由Skill承接。专项检查、短周期分析和阶段性运营任务未必需要开发完整应用，可以先发行一个受控能力包；任务结束后，Skill可以下线，方法和测试样本仍然保留。

当一个Skill能够说明怎样运行，能够通过测试，也有人持续负责，它才真正完成了从个人经验到企业软件资产的转换。模型可以升级，专家可能换岗，已经验证过的行业方法仍然留在组织内部，并能被下一位员工或下一个Agent继续使用。

2026年AI焦虑，不仅仅是软件服务商在持续迭代产品，企业端其实也在陷入选型焦虑中，特别是强调科技赋能的金融行业，也在面临着AI选型焦虑。

采购部门拿着产品清单，关心客户端功能、授权方式和交付价格；业务团队讲的是日常工作，希望AI能够理解内部材料和岗位习惯；信息技术与合规人员则会追问运行位置、系统权限以及出了问题如何追溯。几类要求都合理，放到一个标准产品招标表里，却很难得到同一套答案。

这也解释了为什么不少AI项目在演示阶段进展很快，临近真实使用时开始卡顿。标准产品已经具备对话、知识检索和Agent能力，但金融机构真正想用的那部分，往往藏在自己的业务系统、岗位方法和管理规则里。产品厂商无法预先知道每家机构的全部细节，内部团队也很难仅凭一份需求文档，把这些细节完整交给外部团队。

模块化Agent客户端与FDE服务的组合，开始受到关注，并不是因为行业需要发明一种新的项目名词。

它尝试重新分配两类工作：共性的客户端、运行和管理能力由产品承担；机构特有的岗位流程，由FDE在真实环境中完成梳理和交付。

如何让AI真正的在企业里产生价值

金融AI项目最初的验收目标，常常写成“建设投研助手”“打造客户经理数字员工”或者“实现运营智能化”。这些目标便于立项，却很难直接指导开发。一个投研助手究竟要在哪个页面工作，读取哪一类材料，引用能否追溯，生成内容要进入什么审核流程，都要继续向下拆。

标准Agent客户端能够提供模型入口、会话管理和基础工具，但它不会自动理解一家机构的岗位分工。若产品预置了过多流程，实际部署时反而要花时间删改；若只提供一个空白对话框，业务人员又要反复描述背景，最终还是停留在个人使用阶段。

模块化设计解决的是这里的“共性底盘”。客户端先把安装升级、Agent运行、插件加载和任务状态这些基础工作处理好，再允许项目团队按照岗位装入页面、Skill与系统连接。机构不必从桌面框架开始开发，也无需接受一套无法调整的固定产品。

FDE 更关注如何模糊的需求如何落地为技术方案，例如把“做一个投研助手”收敛成一条能被真实用户验收的任务。例如，研究人员在产品页面发起内部笔记整理，Agent读取授权范围内的材料，保留引用和风险提示，研究人员确认后再进入现有归档流程。任务范围一旦明确，插件需要提供什么上下文、Skill怎样组织处理步骤、系统接口开放到哪里，就不再依赖各方猜测。

客户端提供稳定起点，FDE缩短产品能力与岗位现场之间的距离。两部分缺少任何一边，项目都容易走向另一个极端：要么产品很好用，却进不了正式流程；要么做出一套高度定制的系统，上线速度和后续成本都难以控制。

第二个场景还要不要重做一遍

许多项目在第一个场景交付后看起来已经成功，等到另一个部门提出相似需求，才发现此前留下的主要是一组脚本、几个接口和大量口头经验。原团队能够继续做，换一批人就要重新理解。这种交付可以解决当时的问题，却没有降低下一次建设的成本。

模块化客户端与普通定制项目的差别，更多体现在第二次扩展。第一次为投研岗位建设的能力，应该被拆成若干可维护的部分：插件保留业务入口和页面上下文，Skill记录任务方法与规则，系统连接按照机构接口规范管理，运行策略约束数据与工具的访问范围。后续建设客户经营场景时，不需要复制完整投研方案，但可以沿用已经验证的身份体系、发布机制和运行环境。

这种复用并不追求把所有金融业务抽象成同一个模板。研究、销售和运营本来就有不同的工作方式，强行统一会损失业务含义。真正值得统一的是软件运行和能力管理的方法，让不同岗位的差异能够以模块形式存在，同时接受同一套版本与权限管理。

FDE的交付方式也要随之变化。如果FDE只是驻场写代码，项目数量增加后，人力会线性增长，机构对外部团队的依赖也会越来越深。更合理的结果，是把现场梳理出来的方法变成插件、Skill、配置和测试用例，再交给机构内部团队维护。下一次遇到相似任务，FDE不必从零解释环境，可以把时间用在新的业务差异上。

在快速变化的时代下，如何保证Agent的可拓展性

Agent技术本身的变化尤其快。今天团队可能选择OpenClaw，下一阶段又希望接入Hermes，之后还会出现新的Agent框架和运行时；底层模型也会随着效果、成本和部署要求不断调整。金融机构很难把长期建设押在某一种技术实现上。客户端需要保留稳定的适配层，让上层插件、Skill、权限策略和业务连接尽量不受底层替换影响。这样切换Agent时，机构验证过的岗位方法仍然能够继续使用，只需重新测试运行兼容、工具调用和安全边界。

客户端的模块化程度，决定了变化能否被局部处理。业务页面调整时，可以更新对应插件；岗位方法发生变化时，可以发布新的Skill版本；模型替换或运行策略修改，则由底层配置处理。机构还可以根据内部发布要求控制升级节奏，让小范围用户先验证，再决定是否扩大使用。这样一来，业务变化不必每次牵动整套客户端。

FDE在项目后期需要把“怎么改”交出去。除了源码和部署包，机构还需要知道模块之间的边界、接口依赖和验证方式。哪些配置可以由业务管理员调整，哪些修改必须经过技术评审，出现异常时如何恢复旧版本，这些内容如果没有进入交付物，项目仍然依赖少数熟悉现场的人。

金融机构采购AI时容易低估这部分成本，因为传统软件通常已经定义好功能边界，客户主要负责配置和使用。Agent会调用工具并参与流程，系统开放的范围更容易随业务变化，维护责任也更难完全固化。谁能发布Skill、谁能修改插件连接、谁来批准高风险动作，需要在长期运营中保持清楚。

FinDesk把标准客户端留给机构，把业务差异交给模块

FinDesk采用模块化、插件化的方式建设金融机构自己的AI工作空间。机构可以保留独立的应用身份、品牌界面和更新通道，再按照岗位配置菜单、页面、插件与Skill。员工进入客户端后，看到的是与职责相关的工作空间，不需要在一个通用对话框中寻找所有能力。

插件在FinDesk中承担的不只是界面展示，它可以连接业务对象和机构已有的服务，并向Agent提供当前页面的上下文。Skill负责沉淀任务方法，让Agent按照经过确认的步骤调用工具、组织结果。业务团队可以逐步调整岗位方法，客户端底层无需随每次变化一起重做。

结合凡泰AI的FDE团队与这套模块机制配合，从一项具体任务开始梳理业务流程，完成系统连接、插件开发和Skill封装，再到机构环境中验证实际使用。项目交付后，经过确认的模块和规则留在机构自己的客户端中，后续可以由内部团队继续维护，也可以用于相近岗位的扩展。

具体的系统集成、安全隔离、终端兼容以及升级回退，仍要根据机构现有环境完成测试。模块化不会消除金融AI项目的复杂度，它改变的是复杂度被处理和保留下来的方式。共性工程不再重复开发，现场差异也不必永久留在项目人员的脑子里。

现在很多银行、基金、证券机构都在纷纷引入AI能力进行提效，从前期的问答助手、智能客服、Agent 智能体，一直在尝试AI的落地应用。

其实给员工开通一个AI对话入口并不难，但运行一段时间后，金融机构往往会发现：AI虽然能够整理材料、修改表达、生成PPT提纲，却很少直接出现在员工原有的工作过程中。

投研人员还是要从研究系统里找到资料，再复制到对话框；客户经理需要重新说明客户情况，拿到建议后回到原系统创建任务；运营人员让AI生成了一份名单，后续分配和跟进仍在另一套系统里完成。审核人员看到的通常只有最终文件，很难确认内容引用了哪些材料，中间又经过了怎样的修改。

员工确实在使用AI，但机构的业务流程并没有因此连起来。资料搬运、权限判断、任务流转和结果回写仍由员工处理，AI更像一个位于工作流程之外的内容工具。

不同岗位面对的AI工作空间并不相同

FinDesk是一套面向金融机构的私有化AI桌面客户端————机构可以在统一桌面底座上，按照组织和岗位配置页面、Agent、Skill与工作流，形成自己的AI工作空间。

投研人员进入的是研究工作区，客户经理看到客户经营页面，运营和审核岗位拥有各自的任务入口。大家使用同一个终端框架，但页面内容、可用数据和操作范围由岗位决定，不需要让所有员工面对一套相同的聊天界面。

这不仅仅是修改一个菜单或者图标能够实现的，一个投研工作区需要承载研报对象、引用来源和分析状态，客户经营页面则要呈现持仓、风险标签、服务记录与待办。岗位页面还要连接机构已有的数据和服务，并告诉Agent当前正在处理什么。

员工打开一份研报时，页面可以提供文档标识、可见范围和当前任务状态；打开某位客户时，Agent获得的是这位员工有权查看且与本次任务有关的字段。页面不会把后台全部数据交给模型，员工原有权限和机构数据策略仍然有效。

通过插件的形式来进行个性化定制

FinDesk采用模块化、插件化的装配方式。插件负责员工在哪里工作，包括页面入口、业务对象、交互流程和系统连接；Skill负责Agent怎样完成任务，把资料检索方法、业务规则、处理步骤、工具调用和输出要求封装起来。

以客户经营为例，客户页面和持仓信息由插件承载，“生成持仓诊断”“准备服务建议”“检查沟通内容”可以分别形成Skill。客户经理发起任务后，Agent读取当前页面允许提供的信息，调用获准的Skill，再把结果返回页面等待确认。

插件和Skill分开管理，机构就不必把每项业务变化都写进桌面主程序。研究模板或审核规则调整时，可以更新对应Skill；业务页面和系统接口发生变化时，则由插件处理。桌面底座继续使用，岗位能力按照业务节奏迭代。

这种方式也改变了机构沉淀经验的方法。过去，效果较好的提示词和操作方法可能保存在个人笔记里，其他员工很难直接复用。FinDesk可以把经过验证的方法制作成Skill，经业务和管理人员审核后再分发到指定岗位。规则变化时，机构维护统一版本，员工无需各自修改。

AI 如何从对话走向执行，真正的降本增效

投研人员在FinDesk中打开待处理材料，发起内部投资笔记任务。Agent在授权范围内整理市场变化、研报观点和风险提示，生成初稿时一并返回引用来源、待确认信息和处理状态。投研人员可以核对原文、修改结论，也可以在依据不足时终止任务。

经过确认的研究内容可以进入后续业务环节。客户经理在客户经营页面中，结合当前客户的持仓和风险标签准备诊断结果与沟通草稿；运营规则命中后，系统创建待跟进任务并分配负责人，处理进度继续保留在看板中。需要制作业务物料时，已经确认的内容可以按照机构模板重新组织。

物料进入审核页面后，审核人员看到引用来源、风险项和修改记录，再依据机构制度决定通过、退回修改或禁止外发。AI完成资料归集、内容准备和重复步骤，投研判断、客户沟通与审核结论仍由对应岗位负责。

这个价值不在于让Agent独立完成全部工作，而在于任务上下文可以随页面和流程传递。员工不必反复搬运材料，生成结果也不会只停留在个人对话记录里。每一步由谁确认、结果进入了哪个环节，都可以继续保留在机构的工作过程中。

如何保证金融机构有最终的掌控权

金融机构所说的专属AI终端，通常不止是更换Logo和界面颜色。如果应用身份、配置目录、插件来源和更新通道仍由公共版本统一管理，机构就很难控制某项能力何时进入生产，也难以在出现问题时锁定或回退版本。

FinDesk采用统一桌面底座与机构独立发行版本的方式。应用名称、品牌界面、应用身份、本地配置目录、岗位菜单和插件组合可以按机构配置，安装包签名、版本锁定与更新节奏也可以纳入内部发布流程。机构自有的插件和Skill保留在自己的版本边界中，由内部团队或获准的交付团队维护。

因此，FinDesk项目交付的不应只是一组可以演示的页面。机构还需要验收终端能否重复安装，插件与Skill是否按照岗位生效，版本能否升级、停用和回滚，内网环境中的更新方式是否符合现有管理要求。具体能力仍要结合目标操作系统和项目版本验证。

Agent能做什么，要在任务开始前确定

FinDesk进入桌面后，Agent可能读取本地文件、访问内部服务或调用工具。模型部署在机构内部，并不会自动解决这些执行风险。文件可以读到哪里、允许连接哪些网络、哪些工具可用以及哪些动作必须由人确认，都需要单独设置。

例如，投研Agent可以读取指定研究目录，但不能访问员工电脑上的其他文件；客户经营Agent可以生成服务建议，涉及客户触达或业务系统写回时，需要客户经理确认；审核任务可以查看引用和修改记录，最终放行仍由审核人员操作。

任务结束后，系统还需要保留发起人、Agent与Skill版本、策略判断、工具调用、处理结果和人员操作。出现异常时，运维和审计人员可以沿着记录定位问题，避免现场最终只留下一份无法解释来源的生成结果。

一项岗位任务跑通后，机构可以复用桌面底座、发行机制和安全策略，再逐步增加新的岗位插件与Skill。长期保留下来的包括机构自己的业务页面、工作方法、系统连接和运行记录。行情、CRM、交易及核心业务系统仍然承担原有职责，投资判断、客户建议与审核责任也继续由对应岗位负责。金融AI工作台连接这些既有能力，让AI进入日常任务，同时保留机构原来的权限和责任边界。

随着通用办公Agent 技术架构的输出，市面上会出现了大量的 AI Agent形态的产品，包括通用类办公Agent以及各类垂直行业的Agent，那什么样的Agent能够满足金融机构的AI选型需求？

如果选择通用桌面，客户数据和内部研报如何处理，行情、客户经营、知识库与审批系统怎样连接，合规要求能否落实？

如果选择自研，网上开源项目很多，真正到了金融机构环境里，品牌发行、内网适配、插件治理、安全策略和后续更新又会变成一项长期工程。

更棘手的是，金融机构今天选定的模型或 Agent运行时，未必就是三年后的答案。如果桌面入口、业务页面、知识资产和安全体系都与某一种技术绑定，底层一变，前面投入的大量工作可能又要重新建设。

所以，金融企业选型时，需要先回答三个问题：

1. 桌面是否真正属于机构。 品牌、应用身份、配置、插件和版本节奏能否由自己的 IT 团队管理。
2. AI 是否进入真实工作路径。 Agent 能否理解当前页面、当前对象和当前任务，而不是让员工反复向聊天框搬运上下文。
3. 能力开放后能否继续治理。 文件、网络、工具和数据访问有没有边界，关键结果能否进入人工确认、审核与审计流程。

今天介绍一下FinDesk 企业级AI桌面工作台。它以统一桌面底座承载不同岗位入口，再通过私有插件、Skill、系统连接和治理策略，让机构把自己的业务能力装进来。模型可以变化，岗位页面可以扩展，但工作台的边界和演进权仍留在机构手中。

一、独立发行：金融机构得到的不是“换皮桌面”

传统桌面产品的定制，往往从换 Logo、改配色、修改安装包名称开始。视觉上有了专属版本，底层仍可能与公共产品共用应用身份、配置目录和升级通道。项目一多，客户差异不断写进主程序，维护成本会慢慢浮出来。

FinDesk 采用“统一桌面底座 + 机构独立发行仓”的方式组织交付。通用能力由统一底座维护，机构自己的品牌、应用身份、私有插件、业务配置、签名材料和发布策略则保留在独立发行仓中。

可以针对以下内容进行独立配置：

• 应用名称、图标和品牌界面；
• 应用标识、本地配置目录和业务参数；
• 面向不同岗位装配的私有插件；
• 安装包签名、版本锁定和制品校验；
• 在线更新、内网分发或离线导入方式。

这样金融机构获得的是不只是一个软件，而是一份可安装、可更新、可治理的 AI 桌面交付物，也为后续跨平台适配和版本演进留下工程基础。

二、私有插件：让“人”重新回到业务路径中心

很多AI桌面的终点，是把一切都交给 Agent。但在投研、客户经营、运营和合规场景中，专业人员需要的不只是一个空白对话框。他们仍要查看行情与图表、填写表单、提交材料、比较版本、审批结果，并对最终动作承担责任。

FinDesk 通过私有插件承载这些专业工作界面。插件可以提供左侧导航、独立页面、业务对象和交互流程，也可以连接本机服务或机构后台。客户经营、研报处理、运营任务和合规审核，都可以沿着自己的业务结构装入桌面，而不必被压缩成一轮轮聊天。

插件页面还可以向“当前页面 Agent”提供受控上下文。当员工打开某位客户、某份研报或某条待审物料时，Agent 能够围绕当前对象调用获准的 Skill 和工具，员工无需重新描述页面里已经存在的信息。

两者通过当前页面上下文形成 Human-in-the-Loop：Agent 负责提出建议和完成重复步骤，人员在业务页面中复核、修改、批准或终止。AI 辅助由此发生在专业工作流内部，而不是把专业人员赶进一个通用聊天窗口。

三、数据闭环：先把数据留在边界内，再谈“越用越懂业务”

没有反馈闭环的 AI 桌面，很容易停留在“会聊天”的阶段。金融机构如果希望 Skill 越用越贴合岗位，就需要知道哪些场景使用频繁、任务卡在哪里、输出为何被退回、哪个版本带来了改进。

但金融机构的数据闭环不能建立在无差别采集之上。至少要区分三类数据：

1. 业务数据：决定 Agent 在当前任务中可以看见什么；
2. 运行数据：用于定位调用、性能、失败和异常；
3. 评估数据：用于判断输出质量、合规情况和用户采纳结果。

它们对应不同的授权、脱敏、保留周期和访问人员。FinDesk 可以把获准的采集与监控能力纳入机构自己的部署和策略体系，让运行记录服务于场景理解、Skill 迭代和合规观察，而不是默认流向外部 SaaS。

那适合金融机构的反馈链路可以是：

桌面使用与协作

        ↓

按策略采集运行记录

        ↓

机构自建的数据与监控服务

        ↓

场景分析 / Skill 调整 / 合规检查

        ↓

审核后重新发布能力版本

数据不出域只是起点。哪些内容允许采集、谁能查看原始记录、评估样本能否复用、记录何时删除，同样需要由机构制定策略。只有数据边界和治理规则同时成立，“数据飞轮”才可能沉淀为金融机构自己的能力资产。

四、运行时中立：更换“大脑”，不重做桌面治理

模型和 Agent 运行时仍在快速变化。金融机构不应该把未来押在单一运行时上，也不适合让每一次底层替换都牵动岗位入口、业务页面、插件生态、会话资产和审核流程。

FinDesk 更适合承担金融机构管理 Agent 的桌面环境：保留目录、页面上下文、插件、Skill、策略、审批和审计等长期资产，同时为不同运行时预留适配空间。底层推理与任务编排可以按场景评估，桌面侧的业务结构和治理框架继续沿用。

运行时中立不等于“任何 Agent 接进来都完全一样”。工具协议、上下文格式、鉴权方式、任务状态和失败恢复仍会存在差异。正式交付时，需要针对选定运行时完成兼容验证，并为关键任务准备降级或人工接管路径。

对 CIO 和架构团队而言，这意味着：底层技术可以迭代，但金融机构不必同时更换自己的桌面治理体系。

五、跨平台安全：约束 Agent 执行，而不只检查回答

当 Agent 只能生成文字时，风险主要集中在内容质量；当它开始读取文件、访问网络、调用工具和创建任务后，安全问题就会进入员工工作区和机构内网。

FinDesk 的安全治理覆盖 Agent 执行的前、中、后：

1. 执行前：限定可读写路径、网络出口、工具范围和资源上限；
2. 执行中：结合 Windows、macOS、Linux 对应的隔离机制约束进程和工具行为；
3. 执行后：记录执行主体、策略版本、调用过程、结果状态和人工处理，为机构审计提供依据。

终端侧策略还可以与中央策略服务、设备管理和审计平台协同。金融机构安全与合规团队负责统一下发和调整策略，终端按策略执行，既有终端管理体系继续负责软件安装与设备纳管。这样既保留个人工作区的隔离，也让机构能够集中治理。

具体操作系统版本的隔离能力、网络治理方式、策略失效处理和审计接口，需要进入真实环境测试。安全不能停留在“产品支持”四个字上，最终要落实为可验证的策略、日志和异常处置流程。

六、Desktop SDK：把既有 UI 应用“插件化”

金融机构已经拥有大量内部 UI 应用。强迫业务团队推倒重做，通常会带来较长的迁移周期，也会让员工放弃熟悉的操作路径。更现实的方法，是保留专业界面，将它逐步迁入 FinDesk，再沿着原有流程接入 Agent。

Desktop SDK 为开发团队提供统一桌面壳层、页面注册、上下文接入和发行约定。金融机构 IT 团队可以：

• 将已有 UI 应用迁移为 FinDesk 私有插件；
• 为页面注册当前客户、研报、任务或审核对象；
• 把重复操作沉淀为 Skill，再交给 Agent 调用；
• 继续通过既有身份、权限和审批系统控制关键动作。

开发团队也可以从一个高频、低风险、结果容易核对的任务开始，先完成插件页面和当前上下文，再逐步增加 Skill、工具调用、监控和审核。专业界面继续存在，责任边界没有消失，AI 能力则生长在员工已经熟悉的工作流之上。

七、最终选型标准

把这些能力放在一起，FinDesk 的产品主线会更加清晰：

FinDesk 不替金融机构决定未来必须使用哪一个模型或 Agent。它帮助机构先建立一套可以长期演进的 AI 桌面工作台：员工与 Agent 在同一业务环境中协作，既有系统继续发挥作用，插件和 Skill 持续积累，数据、安全和更新节奏由自己的 IT 团队管理。

技术会继续变化，金融机构真正值得保留的是岗位页面、业务方法、连接能力、治理策略和责任链路。让变化留给模型，把长期资产留在机构手中——这才是企业级 AI 桌面应有的样子。

感兴趣的话欢迎搜索了解～

企业开AI需求会时，白板很容易被写满：销售助手、合同审查、经营分析、自动报表。每个方向都有业务价值，也都能找到类似的产品演示。会议继续往下开，问题会落到很细的地方。销售助手要读CRM里的哪些数据，合同审查使用法务部哪一版规则，经营分析的数据口径由谁确认，Agent生成结果之后又交给谁处理，参会者给出的答案往往并不一致。

需求卡住，通常不是因为业务人员没有想法。很多企业工作本来就没有一份完整说明，它分散在系统字段、群聊记录和员工习惯里。同一件事换一名熟练员工来做，顺序可能不同，遇到例外时的处理也没有写进SOP。业务部门能够判断结果能不能用，让他们在项目启动时一次讲清所有输入、规则和异常，确实很难。

模型可以把一句模糊指令扩写成完整方案，这种能力反而容易掩盖需求缺口。Demo能够跑通，不代表工程团队已经知道系统应当如何处理下一笔真实任务。这里的FDE（Forward Deployed Engineer）会进入客户现场，把业务诉求还原成可开发、可验收的任务，需求梳理也从会议讨论转到真实工作中。

“做一个Agent”还不能直接进入开发

软件项目过去常用PRD描述页面、字段和接口，这套方法仍然有效，不过AI任务还要多写一层。Agent拿到的材料可能每次都不一样，模型输出存在波动，长任务还会调用多个工具。工程团队需要提前知道哪些变化可以接受，哪类动作越过了边界，以及结果由谁承担责任。

例如，采购部门提出“让AI审核供应商准入材料”。工程团队还不能据此估算工作量。准入材料从邮件进入还是从采购系统进入，会影响接入方式；审核如果只检查缺件，复杂度并不高，一旦包含主体信息核对和风险提示，就要确认数据源及规则版本。发现问题后，Agent可以生成核验清单，直接退回申请则涉及业务权限。这些差异不会在模型演示里自动消失。

右侧这些内容不太像功能，却直接影响项目能否进入客户测试环境。继续补页面原型没有太大帮助，团队需要找到一笔已经发生的工作，查看它从发起到结束究竟经过了什么。

跟着一笔真实任务走下去

访谈能拿到制度规定的流程，实际操作还会多出不少细节。采购专员收到材料后，也许会先翻看历史供应商记录；遇到股权信息不一致，会在群里找同事确认；采购系统缺少某个字段时，又从共享表格里补数据。这些动作已经成为熟练员工的习惯，一次会议很难完整回忆出来。

FDE会选几笔近期任务，跟着使用者走一遍。员工打开过什么材料，在哪一步停下来判断，判断时参考了哪个来源，处理结果后来交给了谁，都会被记录下来。点击次数只是操作痕迹，真正要写进需求的是决策依据。某项判断高度依赖资深员工的上下文经验，第一版就让Agent整理证据并给出候选结论，确认动作继续由员工完成。

顺利完成的样本能跑通主流程，退回记录更容易暴露缺失的规则。材料不完整时，当前流程究竟是暂停还是继续；内网接口超时后，员工是否会改走线下；两个系统的数据冲突时，哪一个来源具有最终效力。工程团队知道这些情况以后，才能设计任务状态、重试方式和接管位置。

原来宽泛的“采购Agent”，到这里会变成一项更窄的工作：

采购专员提交供应商材料后，Agent读取指定工作区内的文件，依据当前版本规则检查缺失项，生成带来源引用的核验清单；采购专员确认后，结果才进入准入流程。

这段话已经能够支撑工程设计。任务从哪里开始，Agent可以读取什么，交付物长什么样，哪个动作由员工完成，都有了边界。后续要不要增加主体信息核对，可以等第一条链路跑通后再决定，不必提前塞进同一个“大助手”。

第一版交付到真实用户手里

需求逐渐清楚以后，项目还要划定第一次交付的范围。FDE常用MVD，也就是Minimum Viable Delivery。MVP通常用于验证市场假设，MVD面对一个已知客户和已经存在的工作，交付结果要能在客户环境中完成一次真实任务。

工程师在自己电脑上读完几份样例文档，只能确认技术路线大致可行。进入客户测试环境后，问题才会具体出现：依赖包可能无法从外网下载，测试账号看不到目标目录，接口返回字段和样例不一致，日志里还可能写入原始敏感内容。早一点遇到这些问题，项目仍有空间调整；功能做完以后才处理，排期通常会被部署和审批拖住。

供应商材料核验的第一版可以只处理一种供应商类型，只接一个材料入口，也暂时不自动写回采购系统。一名采购专员使用自己的账号提交任务，Agent读取授权材料并生成清单，负责人完成确认，这条链路已经足够检验数据、权限和输出是否可用。批量处理和更多系统接入可以稍后安排。

范围缩小以后，业务人员的反馈也会变得具体。他们不再讨论“AI是否足够智能”，而会指出某个数据源已经过期，某条风险提示缺少出处，或者清单的排序不符合日常处理顺序。这些反馈能够直接进入下一次开发。

验收集要比提示词更早确定

有些项目在任务边界尚未稳定时，就开始反复修改提示词。某一轮输出读起来更完整，换一批材料又出现新的遗漏，团队很难判断迭代到底改善了什么。提示词可以继续调，前提是业务方已经准备好一批固定样本和判断口径。

初始验收集可以从近期任务中抽取。常规样本用于检查主流程，曾经被退回的材料保留下来测试边界，业务负责人再为每条样本标出可接受结果和必须拦截的错误。模型或Skill更新后，工程团队用同一批材料回归，避免只挑对当前版本有利的案例。

验收也不能只看回答内容。任务有没有走到结束，接口失败后能否从原位置继续，人工确认是否真正生效，调用内部系统时使用了哪个身份，这些记录都关系到投产。涉及敏感材料时，还要检查数据流向和日志内容。一次回答很漂亮，但执行过程无法复盘，业务负责人很难批准它进入下一阶段。

这样形成的需求比一份长PRD更容易执行。任务规格约束Agent做什么，验收集判断结果能不能用，运行策略限定它可以访问的数据和动作。三部分可以分别更新，又都关联到同一项业务任务。

现场经验怎样留在企业里

FDE如果只交出一份需求文档和一套定制代码，下一个场景仍会从头梳理。现场记录还要转成企业自己的可维护资产：已经稳定的处理方法封装为Skill，内部接口形成工具适配，业务负责人确认的边界进入任务配置，验收样本则作为后续回归的基准。部署过程遇到的异常，也应留在运行手册中。

凡泰AI的FDE团队可以协助客户完成首个任务的梳理和MVD验证，经过确认的方法再进入FinClaw，以Skill和任务配置的形式保存。产品只承接已经明确的业务约定，场景范围和验收标准仍由客户团队确认。

运行记录还会暴露访谈中看不到的问题。某一类输入反复退回，原因可能是业务规则没写清；任务总停在同一个接口，也可能是系统连接不稳定；规则更新后人工修改明显增多，团队就要检查新版Skill。下一轮工作究竟应该补数据、改规则还是缩小Agent的范围，可以根据这些记录决定。

从一笔真实任务开始

FDE能够把业务语言翻译成工程任务，验收结论仍由业务负责人作出。哪些错误可以接受，某项动作是否允许自动执行，结果出现争议时由谁处理，都需要在试运行中确认。

项目启动不必先向所有部门征集几十个AI场景。候选团队准备几笔近期完成的任务，其中包括原始输入、已经确认的结果和一份退回记录，FDE与实际使用者从中选出一条数据能够取得、结果容易验收的链路，先走完一次。需求在第一次会议上说不完整并不妨碍项目开始，开发之前要留下明确约定：Agent接手哪一段工作，依据什么材料，完成到什么状态，以及出错后由谁接管。

到了2026年，越来越多的团队开始利用AI提高工作效率，输出的工作量也成倍的增加。以内容输出为例，现在最大的问题不是AI输出内容不够好，而是压根来不及审核。

最典型的场景是，临近下班，运营团队的Agent已经生成了一批活动复盘，负责人却来不及审核。数据口径还在等数据团队确认，预算偏差需要财务解释，涉及渠道承诺的内容又转给销售核实。初稿越来越快地进入队列，真正能够对外发布的报告并没有同步增加。

其实这批初稿本身没有问题，原来的工作本来就依赖多个岗位，只是过去材料准备耗时较长，后面的等待没有那么显眼。Agent把前半段压缩以后，审核能力不足和交接信息不完整的问题一起露了出来，返工也随之增加。员工完成得更快，企业交付得未必更快，两者之间隔着一整套组织运行方式。

处理时间缩短，等待时间却没变

企业讨论AI效率，通常先看员工完成一次操作用了多久。原来两个小时才能整理好的材料，现在半小时可以拿到初稿，这个变化直观，也便于统计。不过，一项工作从发起到验收，时间还花在等待认领、口径确认、审批排队和退回修改上。

Agent缩短了其中的处理时间，其他环节不会自动跟着变化。如果审核岗位每天能处理的任务有限，上游新增的产出只会排进更长的队列。生成内容的成本越低，团队越容易同时启动更多工作，结果是已经开始、尚未完成的任务越来越多，注意力也被切碎在不同上下文中。

所以，评估这类项目不能只统计每个人生成了多少内容。更接近业务结果的口径，是单位时间内有多少任务通过验收，以及它们在途中等待了多久。某个岗位快了几倍，只要瓶颈仍停在下一环，客户看到的交付周期就不会有同样幅度的变化。

Agent需要一份可执行的任务协议

聊天窗口很适合个人使用，却不是一个完整的任务系统。员工和Agent讨论了什么，可以从历史消息里找到；任务进行到哪一步、现在由谁负责、退回后应该从哪里继续，往往还要靠人重新说明。

跨角色协作需要一个稳定的任务标识，以及与它关联的工作上下文。系统先记录任务由谁发起、谁对结果负责，随后固定本次处理所使用的文件和数据版本。输出也要有明确的接收人和验收条件，否则Agent写得再完整，下一岗位仍会按自己的理解重新整理。

任务状态需要比“运行中”和“已完成”更细。等待模型资源、等待业务数据和等待人工确认，处理方式完全不同。前一种阻塞可以调度到其他资源，后两种要找到具体责任人；如果系统把它们都显示成运行中，项目负责人只能看到任务没有结束，却不知道卡在哪里。

这组信息可以组成一个工作包。它不一定表现为新的文档格式，也可以由任务记录、工作区和状态机共同承载。

{

  "task_id": "campaign-review-2026-08-06",

  "owner": "operations-lead",

  "input_snapshot": "report-data-v3",

  "status": "waiting_review",

  "blocked_by": "finance-confirmation",

  "acceptance": "数据口径确认后允许发布"

}

实际系统会有更完整的字段，这里想说明的是，工作从员工交给Agent，或者在不同Agent之间转移时，输入版本、处理结果和验收要求要跟着同一个task_id移动，接手者不用翻阅整段聊天记录恢复现场。

Skill、Session和交接协议分别解决什么

研究员或合同助手这类名称可以帮助员工理解Agent的分工，但改一段系统提示词、换一个头像，并不会自动形成岗位能力。企业还要把领域方法写进Skill，明确它使用什么数据，允许调用哪些工具，输出达到什么条件才算完成。

“专家”更接近一套经过业务人员确认的方法和质量标准。方法发布后要有版本，规则变化时能够更新，出问题时也能退回已经验证过的版本。否则所谓专家Agent仍依赖最初创建者维护，其他团队安装以后，很难判断结果为什么发生变化。

“助理”的难点在连续工作。很多任务会等待外部系统返回，或者停在人工确认节点几个小时。页面关闭后，已经完成的步骤和当前上下文不能一起丢失；再次运行时，Agent也不能把旧任务和新任务混在同一段记忆里。

到了团队协作，重点落在交接协议。系统需要知道哪个角色处理当前步骤，什么条件下转给人工，失败后是重试、回退还是终止。让多个模型互相发送消息并不复杂，真正影响上线的是其中一个环节出错以后，任务能否停在可处理的位置，而不是继续把错误传给下一个系统。

中断和退回更能检验Harness

演示环境通常展示一条顺利完成的链路，企业运行中的麻烦更多发生在中断、退回和版本变化时。AI Harness需要接住这些情况，让模型之外的任务状态和业务约定保持稳定。

例如法务退回一份材料，系统保存的不应只有一句“请修改”。本次退回针对哪个输入版本、命中了哪条规则、哪些段落已经通过，都要关联到原任务。Agent重新执行时只处理受影响的部分，避免整份材料再次生成后带来新的差异。

长任务还会遇到服务重启和人工等待。Session保存当前任务的连续上下文，Checkpoint记录可恢复的执行位置。确认人暂时不在线时，运行进程可以释放资源，任务留在等待状态；收到确认后，再加载对应的工作区继续处理。状态留在持久化空间里，不必依赖某个进程一直在线。

工具调用也要进入同一条任务链。Action系统把企业接口和Skill转化成Agent可调用的动作，也可以通过MCP接入标准化工具。每次调用使用当前任务的身份与输入，执行结果写回task_id。业务系统返回失败时，运行时才有条件判断应该重试、换用备用工具，还是交给员工处理。

版本管理解决的是另一类问题。Skill升级后，如果新规则造成大量退回，管理人员需要知道哪些任务使用了新版本，正在运行的任务是否继续，后续任务能否先回到旧版。只管理模型版本、不记录任务实际使用的Skill和工具版本，故障发生时很难还原原因。

调度器不能只看模型并发

很多Agent平台把并发能力等同于同时运行更多任务，组织协同还要考虑下一个节点的承载能力。审核队列已经堆积时，继续生成低优先级初稿只会扩大在制任务。此时运行时应该暂停部分任务，或者把资源转给能够完成交付的工作。

计算队列和业务队列需要分别观察。等待模型资源可以通过扩容或切换模型缓解；等待业务负责人确认，增加服务器没有作用。平台要把阻塞原因暴露出来，并为任务设置优先级、超时和接管方式。项目负责人看到的也不应只是Agent是否在线，而是哪些工作正在推进，哪些工作已经停滞。

这种调度方式会影响成本判断。一个任务消耗的Token不高，但如果反复生成、长期占用人工审核，它的实际成本并不低。反过来，某项Skill调用次数不多，却能减少退回和重复确认，对交付周期的影响可能更明显。

把状态从Agent进程里拿出来

Agent数量增加以后，为每名员工维护一个长期驻留进程，并不能解决协作问题。更稳妥的运行方式是把身份、任务记录和工作产物放进持久化空间，计算进程按需加载上下文，执行结束后写回状态并释放资源。

这也是Managed Agents与批量运行聊天机器人的区别。耗时任务通过Session保持连续性，进入人工确认后暂停，系统升级或节点故障时从Checkpoint恢复。不同部门可以使用不同模型和Skill，不必统一Agent框架，但进入生产环境的任务要遵循同一套状态和交接约定。

运行观测也应围绕任务展开。单看某个容器是否存活，只能判断进程状态；把运行记录关联到工作包以后，运维人员才能分清任务是在正常推理、等待业务输入，还是卡在一次失败的工具调用上。

统一管理任务、工作区和Skill

凡泰AI的企业级Agent中台FinClaw提供数字员工模板、独立工作区和Skill中心。员工可以从Web或企业IM发起任务，经过验证的处理方法提交审核后，再按组织或角色开放。任务执行过程中产生的工作文件留在对应工作区，工具调用和人工审批也有记录可查。

这套机制能把个人调试出来的用法变成有维护人、有版本和使用范围的企业能力。业务规则变化时，管理人员更新Skill并控制发布节奏，员工不必分别修改提示词；某个版本产生异常后，也能根据运行记录确认影响范围。

不过，平台不能替企业定义一条原本就含糊的流程。如果两个部门对验收标准没有共识，责任人也不清楚，Agent中台最多把这些分歧记录得更完整。接入系统之前，业务团队仍要确认任务由谁负责，哪些结果允许自动流转，出现异常时由谁接管。

选择试点时，可以找一条结果能够验收的跨岗位流程，任务量也应相对稳定。上线前先记录处理时间和等待时间，再看首次通过率以及同时在途的任务数量。Agent接入后仍按同一口径观察，才看得出它改善了交付，还是只把瓶颈推到了下一岗位。

2026年以来，一些过去被Agent框架内部消化的问题，开始被单独提到运行时层面讨论。行业把AI Runtime Infrastructure定义在模型之上、应用之下，用它观察长任务的状态，并在任务偏离、资源异常或策略变化时介入；A2A协议进入1.0版本后，Agent发现、任务状态和结果交付有了更明确的协议对象，OpenTelemetry也在补充Agent与工作流的可观测语义。多Agent进入企业时，架构讨论已经不能只停留在“哪个Agent效果更好”，还要回答不同Agent怎样被发现、调用和追踪。

这给企业自建Agent平台提供了一个新的思路。运行底座不必要求各部门改用同一种框架，也不必把所有任务搬进同一种计算环境。平台可以先统一Agent参与企业运行时必须遵守的几份契约，再用适配器连接现有Agent。部门保留开发自由，平台团队获得可执行的管理边界。

统一框架很难，统一运行契约更现实

企业里的Agent通常不会来自同一个技术栈。一个团队使用开源框架开发研究Agent，另一个团队采购行业Agent，部分员工还会在桌面端运行本地助手。要求它们共享内部代码和编排方式，迁移成本很高，也容易让平台建设卡在框架选型上。

运行底座更适合统一外部行为。Agent怎样声明自己的能力，接到任务后如何回报状态，以什么身份访问工具，执行过程怎样进入监控，这些内容可以形成稳定接口。当前公开规范已经给出了一些可参考的对象：

把这些边界固定下来，平台才有可能接管运行过程。至于Agent内部使用什么模型、怎样规划任务、是否采用多Agent编排，仍由开发团队决定。企业不需要先消除所有框架差异，只要求接入的Agent在边界处提供可验证的输入和输出。

Agent清单要能被机器读取

A2A 1.0规范使用Agent Card描述一个Agent的身份、能力、Skill、服务端点和认证要求。客户端在调用前先读取这张卡片，确认对方是否支持流式响应、异步通知或扩展能力。需要认证才能查看的详细信息，还可以通过Extended Agent Card按身份返回。

企业内部未必直接采用A2A，但Agent注册表可以借鉴这种方式。每个Agent提交一份机器可读清单，其中写明负责人、版本、可处理的任务、接入地址、认证方式和支持的交互模式。平台根据清单生成调用适配器，并在Agent升级时检查兼容性。

清单里不应保存静态密钥。它只声明认证要求，调用方通过身份系统另行取得凭据。这样，Agent信息可以进入企业目录并被其他Agent发现，凭据仍然按照人员、租户和任务动态发放。某个Agent下线或版本存在问题时，平台停用对应清单即可阻止新的任务分配，不需要逐个修改上游Agent的Prompt。

任务协议要从聊天会话中独立出来

对话系统习惯把一次交互理解成消息请求，Agent更常遇到长时间运行和中途等待。A2A将Task定义为带有唯一标识的有状态工作单元，并区分已提交、执行中、完成、失败、取消、等待输入、等待认证和拒绝等状态。任务还可以持续产生Artifact，用来传递文档、文件引用或结构化结果。

这些状态比“成功或失败”多了一些，但能减少多Agent协作中的误判。资料收集Agent需要访问受限系统时，可以返回AUTH_REQUIRED，上游Agent不必把它当作失败任务重新创建；法务人员需要补充合同附件时，任务进入INPUT_REQUIRED，已有Artifact和历史记录继续保留。补充条件满足后，原任务接着执行。

企业运行底座可以把这套任务语义映射到内部状态机。一次任务在多个Agent之间转交，task_id与context_id继续保持关联；子Agent产生的Artifact回到父任务后，平台记录版本和来源。执行节点重启或用户暂时离线，任务状态仍然保存在运行底座里，不依赖某个进程或聊天窗口。

任务协议还要明确取消的含义。数据库中把状态改成CANCELED并不会自动停止脚本，上游Agent也可能继续等待结果。调度器发出取消命令后，执行节点需要终止相应进程，关闭工作区写权限并回报最终状态。只有完成这些动作，取消才算结束。

Agent身份要分成入站和出站

员工调用Agent时，平台要识别发起人和所属组织，这是入站身份。Agent随后访问代码仓库、内部接口或第三方服务，还需要一份出站身份。两类身份混在同一个固定服务账号里，平台只能查到“某个Agent调用了工具”，很难还原实际授权来源。

Amazon Bedrock AgentCore的安全文档给出了一个值得关注的工程提醒：网关策略只有在全部流量经过网关时才有效，如果调用方可以直接访问Runtime，策略、Guardrail和拦截器都会被绕过。文档同时建议把OAuth凭据和API Key交给身份组件管理，避免凭据进入Agent代码或日志。

企业自建运行底座时也要处理这条旁路。工具网关负责校验调用者和目标工具，Runtime只接受来自网关的请求；Agent根据当次任务取得短期凭据，工具调用结束后凭据失效。业务系统继续做最终鉴权，网关不复制一套业务权限。这样既能保留现有身份体系，也能阻止Agent绕开平台直接连接工具。

多Agent转交任务时，身份不能只传一个用户名。父Agent需要传递委托范围，子Agent获得的权限不得超过原任务。发生再次委托时，平台保留委托链和有效期。某个子Agent即便具备更强的工具能力，也只能在这次任务允许的范围内使用。

可观测数据也需要公共语义

多Agent平台常见的另一类问题是日志无法拼接。Agent A记录“已委托”，Agent B记录“开始处理”，工具网关只留下一个HTTP请求，运维人员很难判断三条记录是否属于同一项任务。

OpenTelemetry的GenAI Agent语义规范正在定义invoke_agent、invoke_workflow和plan等Span，并为Agent ID、Agent版本、会话ID和错误类型提供统一属性。一次多Agent任务可以由Workflow Span统领，下挂Agent调用和工具执行，平台再用Trace ID关联业务日志。

这项规范目前仍标记为Development，字段和命名可能继续变化。企业可以先做内部映射层，不要把尚未稳定的字段直接固化为数据库主键。采集内容也要受数据策略控制：任务标识、耗时、错误类型和工具名称通常可以进入遥测系统，原始Prompt、文件内容和工具返回值则应按敏感级别决定是否记录。

统一观测语义的价值会在故障时体现出来。上游Agent等待超时，平台沿Trace ID可以看到子Agent已经完成规划，但工具调用被身份网关拒绝；修复权限后，只重放失败步骤，无需重新执行整条工作流。

安全执行是运行协议的最后一段

A2A负责Agent之间怎样协作，OpenTelemetry负责怎样记录调用链，它们都不直接限制进程能够读取哪些文件或访问哪些网络。任务进入执行节点后，仍然需要安全执行环境落实策略。

凡泰AI的产品体系把这两部分分开处理。FinClaw承担企业Agent中台的运行管理，将租户、数字员工、Skill、运行实例和工作区纳入同一平台，保存任务进度和执行记录。不同来源的Agent可以通过适配器进入平台，具体采用哪种协议则由项目接入方式决定。

FinSafe处理代码执行与高风险工具调用。中心端可以在企业内网提供Sandbox as a Service接口，本地端用于必须处理终端文件的任务。策略随执行请求进入沙箱，约束可读写目录、网络和资源；执行结果连同策略版本返回管理侧。FinClaw知道任务由谁发起、交给哪个Agent以及运行到了哪一步，FinSafe记录实际动作在哪个边界内完成。

现有IAM继续提供人员身份，业务系统保留最终鉴权，MDM负责终端分发和设备状态。运行底座利用这些系统提供的结果，不需要把企业原来的安全体系再造一遍。

用两个异构Agent测试运行底座

运行底座的第一项测试，可以选择两个技术栈不同的Agent完成一次任务交接。例如合规Agent接收材料检查任务，把证据收集交给文档Agent；文档Agent访问受限文件时返回等待认证，员工完成授权后继续处理，并把结构化Artifact交回合规Agent。最后一步进入沙箱执行，生成结果文件但不直接写回业务系统。

这条任务可以验证四个容易被普通演示忽略的分支：

完成这轮测试，企业才能确认运行底座管理的是Agent之间的运行关系，而不只是若干服务实例。后续接入新Agent时，平台检查能力清单、任务协议、身份方式和遥测映射；高风险执行再进入统一安全边界。Agent框架可以继续变化，企业的调用规则和运行记录不会跟着某个框架一起丢失。

给框架变化留出余地

从这些公开规范可以看到，企业Agent平台正在补齐一套独立于具体框架的运行协议：能力声明用于发现Agent，任务状态支撑长时间协作，入站与出站身份限制委托范围，可观测语义负责串联跨Agent调用，安全执行环境则约束最终落到系统上的动作。

这些标准仍在演进，企业没有必要等它们全部稳定，也不宜把某一份草案直接做成内部数据库结构。运行底座可以保留协议适配层，把外部规范映射到企业自己的Agent目录、任务状态和审计模型。这样做不追求一次选对永久不变的框架，而是让更换Agent框架或升级协议时，已经接入的业务流程和历史运行记录不必重新建设。

企业做 Agent 试点，第一阶段通常推进得很快。接一个大模型，挂几个工具，补一批业务知识，再做一个对话入口，团队很快就能看到效果。

麻烦往往出现在进入生产之后。

一个任务执行到一半中断了，第二天能不能接着跑？不同部门的数据和记忆怎么隔开？智能体调用高风险工具时，谁来审批？出了问题以后，能不能还原当时的上下文、工具输入、执行结果和责任边界？

这些问题靠单个应用临时补配置，很难长期撑住。企业级 Agent 需要一层运行时，把身份、技能、工具、状态、权限、审计和工作区统一管起来。接下来一段时间，Agent 平台的重点会从“能不能调用模型”，转向“能不能稳定、安全、可治理地运行”。

一个正在变得清晰的方向，是以文件系统为导向来组织智能体。

将智能体放到目录树里

很多 Agent 系统早期会把提示词放在代码里，把知识文件放在对象存储里，把工具权限放在数据库里，把运行状态放在缓存或任务表里。开发时看起来灵活，运维和审计时就会变得很散。

一个智能体到底由哪些内容组成、谁改过、当前版本是什么、能调用哪些系统，往往要跨好几处地方查。团队规模一大，这种分散会变成持续负担。

以文件系统为导向的做法更直接。一个智能体就是一棵目录树：

某个智能体/

  ├─ 身份与行为说明

  ├─ 模型与连接配置

  ├─ 工具声明

  ├─ 技能与知识文件

  ├─ 子智能体

  ├─ 运行记忆

  └─ 历史产出

目录结构本身承载智能体的定义。新增能力，就是放入新的工具或技能文件；调整行为，就修改身份说明；迁移环境，可以连同目录一起打包、审阅、复制和回滚。

这类设计的价值不只在开发效率上。对企业来说，智能体从一段临时上下文，变成了一份可读、可查、可版本管理的资产。技术团队能维护，安全团队能审查，合规团队也能知道它到底能做什么。

企业场景不能只做“一个智能体一个目录”

个人工具或小团队场景里，一个智能体对应一个目录已经足够。企业内部的情况要复杂得多。

一个平台可能同时服务多个机构、多个部门、多个岗位。每个用户可能拥有自己的智能体，每个智能体又有不同的技能、记忆、工具权限和历史产出。如果所有内容仍然挤在一层目录里，隔离边界会很快变得模糊。

企业级架构更适合把工作空间组织成多层结构：

企业工作空间

└── 机构 / 租户

    ├── 用户 A

    │   ├── 智能体 1

    │   │   ├── 身份说明

    │   │   ├── 技能与知识

    │   │   ├── 记忆与产出

    │   │   └── 工具权限

    │   └── 智能体 2

    └── 用户 B

        └── 智能体 3

这层结构解决的是企业最关心的隔离问题。机构之间的数据不能互相可见，用户之间的记忆不能被随意共享，不同智能体的工具、知识和产出也要分开管理。对金融、政企、医疗、国央企等场景来说，逻辑隔离还不够，部分机构可能需要独立存储卷、独立密钥，甚至独立部署环境。

多租户不是后期加一列 tenant_id 就能解决的问题。它会影响请求路由、上下文加载、文件读写、工具授权、审计记录和资源配额。架构一开始没有把这层关系放进去，后面补起来会很重。

每一次请求，都要找到正确的工作区

Agent 平台接到一次请求后，不能只看用户输入了什么。它要先确认这次请求属于哪个机构、哪个用户、哪个智能体、哪段会话，以及适用哪套策略。

一个更稳的流程大致是这样：

用户请求

  ↓

治理层校验身份、权限、策略

  ↓

运行时定位机构 / 用户 / 智能体 / 会话

  ↓

加载身份说明、技能文件、历史上下文和工具权限

  ↓

执行智能体主循环

  ↓

写回产出、进度、审计记录

这个流程看起来普通，但它决定了平台能否承载大量用户同时使用。每次运行都按身份信息定位到对应工作区，智能体不需要长期占着某个进程。进程可以随用随起，任务结束后释放资源；状态留在文件系统和持久存储里。

对企业平台来说，这比“每个智能体长期占着一个运行环境”更容易扩展，也更容易恢复。扩容时增加运行进程即可，升级时替换进程即可，故障后也能从持久层恢复上下文和任务进度。

状态要从进程里拿出来

Agent 的很多生产问题都和状态有关。长任务执行到一半，进程重启了怎么办；模型调用失败，是否能重试；平台滚动升级时，会话会不会丢；用户第二天回来，能不能接上昨天的任务。

如果状态绑在进程里，这些问题都会变成运维负担。更合理的方式，是把状态放到客户可控的持久层。

智能体运行进程

  ↕

文件系统：身份、技能、知识、工作区产出

  ↕

持久存储：会话上下文、运行存档、续跑信息

  ↕

审计存储：工具调用、审批记录、结果回放

这样，每一次 Agent 运行都可以被看作一次独立计算：加载上下文，执行任务，写回结果。进程只是计算单元，不承担长期记忆。

这个设计会让很多运维动作变得简单。扩容时可以增加运行进程，升级时可以替换进程，故障后可以从持久层恢复。对合规要求高的企业来说，状态和审计记录留在自己的基础设施里，也更符合数据主权和内控要求。

这里还要注意会话记录的写入方式。生产环境里，审计记录不适合反复覆盖。更稳的方式是按追加方式记录每一次交互、工具调用、审批结果和产出摘要。出现争议时，平台可以按时间顺序回放当时发生了什么，避免只剩一个被更新过的最终状态。

沙箱应该落在工具调用上

Agent 风险较高的时刻，往往发生在动手阶段：执行命令、读取文件、访问内网接口、写入业务系统、触发自动化流程。模型生成一段文本本身风险有限，工具调用才需要严格隔离。

在多租户场景里，为每个智能体长期准备一个独立沙箱，资源开销会很高。智能体数量、用户数量、会话数量一上来，常驻隔离环境会拖慢部署和扩容。

更适合企业平台的方式，是工具调用级沙箱：

多租户运行时

  ├─ 工具调用 A → 临时沙箱 → 销毁

  ├─ 工具调用 B → 临时沙箱 → 销毁

  └─ 工具调用 C → 临时沙箱 → 销毁

运行时负责上下文组装、策略判断和任务调度。只有当智能体要执行高风险动作时，才进入操作系统级隔离环境。调用完成后，沙箱销毁，结果写回。

这种粒度更贴近企业真实风险点。该隔离的时候隔离，该释放的时候释放，既控制资源成本，也方便对每次工具调用做权限校验、输入输出留痕和失败回收。

工具调用级沙箱还可以和授权策略配合。低风险的查询类工具可以直接放行，高风险写操作可以要求审批，涉及文件写入、命令执行、外部系统变更的动作可以进入更严格的隔离策略。这样一来，企业不用把所有能力一刀切地关掉，也不会让智能体在关键系统里裸跑。

治理能力要进入运行时

企业 Agent 进入生产后，平台每天都要处理类似问题：

• 哪些用户可以调用哪些智能体；
• 哪些工具可以直接执行，哪些要人工审批；
• 哪些数据可以进入模型上下文；
• 工具执行失败后是否需要回滚；
• 输出内容是否要经过安全检查；
• 审计时能否回放完整链路。

如果这些能力散落在各个业务系统里，后期会形成很多套规则。一个部门一套审批，一个应用一套审计，一个团队一套工具权限，平台很难统一管理。

更稳的做法，是把权限、审批、审计、隔离、回滚这些能力放进运行时和托管平台。业务团队负责定义智能体和业务流程，平台负责守住执行边界。

这一步容易被低估。很多团队会先把 Agent 做成一个应用，等业务跑起来以后再补治理。到了这个阶段，工具已经接了很多，数据入口也打开了不少，再回头整理权限、审计、沙箱和审批链路，改造成本会明显上升。

FinClaw 会成为企业的AI基础设施

公有云上的 Agent 框架适合云原生团队。托管工作流、连接器、沙箱、观测平台都已经准备好，开发者可以很快把智能体上线。

但很多企业的约束不同。数据不能出域，模型部署在内网，业务系统运行在专有云或信创环境，部分场景还要求离线运行。对这些组织来说，Agent 运行在哪里，数据沉淀在哪里，权限由谁控制，审计记录能否长期持有，往往比功能清单更重要。

FinClaw 的定位就在这里。它面向企业自有基础设施，提供多租户智能体运行时；ChatKit Middleware 负责治理、托管、多通道接入和全平台会话管理。两者配合后，企业可以把 Agent 的运行、状态、工具调用和审计记录放在自己的边界内管理。

可以把两者关系理解为：

ChatKit Middleware

  治理 / 托管 / 多通道 / 会话管理

        ↓

FinClaw

  多租户智能体运行时

        ↓

文件系统 / 持久存储 / 工具调用级沙箱

FinClaw 采用 Rust 构建，可以交付为单个可执行文件，部署依赖少。它可以运行在企业数据中心、专有云、隔离内网，作为独立运行时使用，也可以嵌入到更大的智能体平台里。

这种形态适合那些希望建设 Agent 平台，但又不能把数据和执行环境交给外部公有云的企业。

Agent落地会回到运行时工程

企业级 Agent 下一阶段不会只比模型接入数量，也不会只比工具列表有多长。会拉开差距的，是运行时能不能把智能体稳定地跑起来、隔离起来、治理起来。

以文件系统为导向的架构，把智能体变成可管理的工作空间；多租户目录树解决机构、用户和智能体之间的隔离；状态外置让会话可以恢复、任务可以续跑、进程可以替换；工具调用级沙箱把安全边界放到风险发生的位置。

FinClaw 沿着这条路线，把智能体运行时落在企业自有基础设施里。对监管行业、政企客户、信创环境和离线场景来说，这种架构更贴近真实约束。

Agent 从试点走向生产，要回答的问题会越来越具体：能不能长期运行，能不能审计，能不能隔离，能不能在企业自己的边界里被持续管理。