员工电脑上的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

AI 时代,企业是否需要构建新的协同办公工具,实现组织级 AI 提效?

AI 时代,企业是否需要构建新的协同办公工具,实现组织级 AI 提效?

员工用 AI 起草了一份采购申请,材料整理得更快了,接下来却仍要打开采购系统填表,到预算系统查额度,再把附件发给负责人确认。如果字段不一致、材料不齐,还得在群里来回补充。个人处理文档的时间缩短了,一项工作从发起到办完,依然可能卡在系统切换和部门交接上。 企业推进 AI 应用时,很容易先从写作、检索、总结等个人工具入手。这些能力有直接的使用价值,但一项工作通常需要多个人、多个系统共同完成。员工各自拥有 AI 助手以后,谁把整理好的信息送进业务系统,谁接收下一步任务,处理结果又回到哪里,仍然需要协同办公平台承接。 企业需要升级的,是能够让 AI 参与业务办理的协同能力。已有办公 APP 可以继续使用,OA、ERP、财务和人力系统也可以保留,在原有入口中增加 AI 交互、业务调用和结果反馈。判断是否需要建设新的工具,应该看现有平台能否接住这些能力,以及能否让各部门持续提供可复用的服务。 从个人效率延伸到业务流程效率 个人使用 AI 时,

By Ricky
iOS、安卓、鸿蒙APP如何运行同一个小程序

iOS、安卓、鸿蒙APP如何运行同一个小程序

公司已经做好的会员服务小程序,能不能同时放进 iOS、安卓和鸿蒙 APP?对业务团队来说,页面、接口和办理流程已经有了,新增一个客户端,当然希望继续使用原来的成果。按三个平台分别重写页面,后续每次修改活动规则、增加表单字段,还要再跟着维护三遍。 借助小程序容器,可以把业务页面和逻辑保留在同一套小程序代码中,由三个 APP 分别嵌入对应的小程序 SDK,提供加载和运行环境。客户端团队完成宿主接入,业务团队继续开发小程序,管理平台负责版本上传和发布。同一项业务就能进入不同系统的 APP,后续更新也有了统一的管理入口。 以 FinClip 为例,可以让三个 APP 打开同一个测试小程序,再逐步接入登录、支付等业务能力。接入示例使用官方 SDK 接口,并补充项目侧状态判断和错误处理;尖括号中的版本、凭据和服务地址需要替换成项目配置。代码放入已有宿主工程,省略工程结构及部分导入声明。 小程序与三个客户端的运行关系 小程序代码包含页面结构、样式、业务脚本和资源文件。容器在 APP 内加载代码包,

By Ricky
从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