员工电脑上的Agent越来越多,企业该怎么管?企业是否可以开发一个自己的Agent桌面端

员工电脑上的Agent越来越多,企业该怎么管?企业是否可以开发一个自己的Agent桌面端

今年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 纳管起来、安全策略跑起来、审计链路验证通,再去谈私有插件和专属发行。底座的价值要等规模上来才看得出来,第一天就追求全套没必要。

Read more

从APP团队内部业务解耦优化到第三方小程序入驻,企业APP如何搭建超级APP技术架构

从APP团队内部业务解耦优化到第三方小程序入驻,企业APP如何搭建超级APP技术架构

今年,很多APP运营团队都有降本增效的需求:希望把企业自己的部分业务转成独立小程序,放进自有 APP 里运行。内部服务运营起来以后,再引入外部小程序,让合作方入驻并持续维护自己的服务。 对企业来说,内部业务拆分与外部生态接入可以采用同一套技术架构。活动、会员、商城等业务先从主工程中独立出来,拥有各自的开发和发布节奏;合作方加入后,也按相同规范提供小程序。APP 团队维护公共能力,业务团队维护功能,运营人员通过后台管理上线与分发,服务增加时不必反复调整整套客户端工程。 FinClip 通过小程序容器 SDK、开发者工具和小程序管理平台,把开发、运行与运营管理连接起来,支持企业从自有业务的小程序化,逐步扩展到多团队、多来源服务共同运营的超级 APP。 业务小程序化与主工程解耦 企业可以把活动专区、会员权益、在线商城、预约报名等业务封装成独立小程序。每个小程序有自己的页面、交互逻辑和代码包,原有业务系统继续提供数据和接口。客户端集成 FinClip 小程序容器后,就具备了加载和运行这些业务模块的能力。 以活动专区为例,活动列表、详情、报名表单和结果页面可以由一个小程序承接。活动团

By Ricky
如何将多个部门的小程序集中运行在一个 APP 中,建设统一的移动政务门户

如何将多个部门的小程序集中运行在一个 APP 中,建设统一的移动政务门户

每个省市都有自己政务APP门户化建设的需求,核心还是希望让市民需要一个入口,就能办完各个部门的事情。 但现实情况是,市民希望入口集中,不用在小程序、公众号和H5页面之间来回切换、反复登录;而各个业务部门那边却各有各的现实,服务由不同供应商开发,迭代节奏也不一样,有的事项一年只改几次,有的专区每周都在调整。如果把几十项服务全部收进 APP 主工程,所有部门的页面变更都得排队等客户端版本,改一个表单字段也要等发版窗口。 难的不只是APP开发,更需要关注如何资源整合 如果只是客户端开发,做一个政务 APP 并不难。难的是建成以后,怎么长期容纳多个部门的服务而不失控。 通过原生方式集成,各部门的业务代码会持续汇入主工程。一方面APP包会越来越大,但更麻烦的在协作上:任何部门改一个页面,都要经过主工程的合并、构建和回归测试,再走应用市场上架;一个部门的服务延期,可能拖累整个版本;某次更新出了问题,受影响的也不止那一家。 同时供应商关系也会遇到管理问题,统一身份是一家单位建的,事项系统来自另一家厂商,部门小程序还有各自的服务商在维护。谁能提交代码,谁负责审核,线上跑的是哪一版,出故障怎

By Ricky
如何借助Skill,把行业经验、Know-How沉淀为企业可治理的软件资产

如何借助Skill,把行业经验、Know-How沉淀为企业可治理的软件资产

现在很多公司都希望通过引入AI提高企业效率。模型账号开通了,知识库和Agent也开始试点,业务部门很快就能感受到内容生成、材料整理和信息检索速度的变化。与此同时,AI技术本身还在快速更迭:模型效果和价格不断调整,Agent框架持续变化,客户端与运行方式也未完全定型。 这会带来一个比选型更长远的问题。假如企业一年后更换模型,或者从一种Agent运行时迁移到另一种实现,今天投入的人力和业务经验还能留下多少?如果项目沉淀的只有一组绑定特定模型的提示词、若干临时脚本和供应商掌握的配置,技术升级很可能意味着重新开始。 企业AI建设真正值得积累的内容,应当能够穿越这类变化。业务对象的定义需要留下,例如什么是有效客户、合格供应商或高风险合同;岗位方法和判断规则需要留下;连接OA、ERP、CRM等系统的工具契约需要保持稳定;真实案例形成的评估样本,以及维护人、权限和审批责任,也应进入企业自己的资产体系。 基于目前的技术来看,Skill可以取代SOP,成为这些内容的任务级载体。它把一类工作所需的方法、规则、工具和交付标准组织在一起,让Agent知道怎样完成任务,也让企业知道这项能力由谁维护、能够在

By Ricky
模块化Agent客户端+FDE服务,是否会成为未来金融行业AI落地的主流路径?

模块化Agent客户端+FDE服务,是否会成为未来金融行业AI落地的主流路径?

2026年AI焦虑,不仅仅是软件服务商在持续迭代产品,企业端其实也在陷入选型焦虑中,特别是强调科技赋能的金融行业,也在面临着AI选型焦虑。 采购部门拿着产品清单,关心客户端功能、授权方式和交付价格;业务团队讲的是日常工作,希望AI能够理解内部材料和岗位习惯;信息技术与合规人员则会追问运行位置、系统权限以及出了问题如何追溯。几类要求都合理,放到一个标准产品招标表里,却很难得到同一套答案。 这也解释了为什么不少AI项目在演示阶段进展很快,临近真实使用时开始卡顿。标准产品已经具备对话、知识检索和Agent能力,但金融机构真正想用的那部分,往往藏在自己的业务系统、岗位方法和管理规则里。产品厂商无法预先知道每家机构的全部细节,内部团队也很难仅凭一份需求文档,把这些细节完整交给外部团队。 模块化Agent客户端与FDE服务的组合,开始受到关注,并不是因为行业需要发明一种新的项目名词。 它尝试重新分配两类工作:共性的客户端、运行和管理能力由产品承担;机构特有的岗位流程,由FDE在真实环境中完成梳理和交付。 如何让AI真正的在企业里产生价值 金融AI项目最初的验收目标,常常写成“建设投研

By Ricky