技术方案 · 内部提效项目

AI CLI 企业管理面板技术方案
(OpenClaw 版)

关联文档:《AI CLI 企业管理面板项目可行性分析报告》(2026年7月8日)—— 本文档不修改原报告,作为技术路径调整后的独立分析产出 文档版本:V2 ・ 编写人:数智中心-梦蝶 ・ 编写时间:2026年7月8日
目录

01背景与决策脉络

《AI CLI 企业管理面板项目可行性分析报告》完成后,在推进落地过程中,针对产品形态和技术选型出现了新的关键信息,需要重新论证技术路径,因此单独成篇说明,不改动原报告。

调整的关键节点:

02技术选型:为什么是 OpenClaw

企业做 AI CLI,本质上是想做一个"能听懂人话的命令行智能体(Agent)"——员工用自然语言描述需求,CLI 负责理解意图、拆解任务、自动调用企业内部脚本或 API 完成执行。OpenClaw 作为开源 Agent 底层框架,正是为这一场景设计,核心依据:

  1. 强大的工具调用(Tool Call)管理。OpenClaw 的强项在于封装底层架构,可稳定地把企业内部指令、云服务 API、数据库查询封装成 AI 可精准调用的"武器库"(Tools)。这正是"让非工程岗位员工也能驱动 Agent 完成实际任务"所需要的底层能力。
  2. 企业级权限与安全控制的可定制性。作为底层框架,便于在其之上定制企业所需的安全边界——审计日志(记录 AI 实际执行了哪些命令)、敏感操作的人工二次确认(Human-in-the-loop)等,与本方案设计的"高风险操作弹确认框、按角色放行"能力天然契合。
  3. 架构灵活、模型不绑定。OpenClaw 是"底盘",上层对接哪个大模型可自由决定——本地私有化部署的模型或闭源的 GPT/Claude 均可,不受供应商绑定。这使得"模型调用指向公司自建网关、Key 由公司统一管理、员工不接触真实凭证"的设计在本地执行架构下依然成立。
  4. 可承载"技能库"设计。基于框架的 Agent/技能定义机制,可将团队沉淀的常用任务预置为可分发的技能配置,直接承载本方案的"技能库",不需要另行搭建一套技能模板系统。
需要留意的风险 作为开源项目,OpenClaw 的社区活跃度、版本稳定性、组织治理需要持续关注,不代表当前不可用,但在长期依赖评估中应纳入考量。此外,本文档对 OpenClaw 具体接口形态(无头服务模式、官方 SDK、技能定义机制的落地方式)的描述,需在阶段一技术验证 Spike 中以官方文档和实测为准确认,不应在验证前当作既定事实排期。

03整体架构

员工电脑 ┌───────────────────────────────────┐ │ 桌面客户端(Tauri 外壳) │ │ ┌────────────┐ ┌─────────────┐│ │ │ 自研前端UI │───▶│ OpenClaw CLI ││ │ │登录/工作台/ │ │(无头服务 ││ │ │历史/技能库 │◀───│ 模式) ││ │ └────────────┘ └──────┬──────┘│ └───────────────────────────┼───────┘ │ HTTPS ▼ ┌─────────────────────┐ │ 公司内部 AI 网关 │ │ - 持有真实 API Key │ │ - 钉钉 SSO 鉴权 │ │ - 用量计量/审计日志 │ │ - 按角色下发权限 │ └──────────┬──────────┘ ▼ OpenAI / Anthropic 等模型供应商

核心设计逻辑:OpenClaw 运行在员工电脑本地,以具备完整读写文件、执行 shell 命令能力的 Agent 模式运行,真正体现"能执行代码、操作文件"的 Agent 级能力,这是与先马AI工作室(纯聊天)的根本区别所在。但 OpenClaw 的模型调用并不直连官方 API,而是配置指向公司内部网关——真实的模型供应商 API Key 只存放在网关这一层,员工电脑上只会出现一个可控、可随时吊销的短期访问令牌。这个设计让"本地执行"与"Key 不向员工暴露"两个目标同时成立,不互相冲突。

04核心模块

模块说明
客户端外壳采用 Tauri(优先于 Electron,理由:体积更小、基于 Rust,启动快、适合分发);首个版本支持 macOS + Windows;内置自动更新检测机制
登录与身份钉钉扫码/免密登录 → 换取短期 JWT 访问令牌 → 客户端本地安全存储;令牌而非明文 Key,可控可吊销
网关代理层(新建,核心模块)验证客户端令牌;按角色与用量策略决定是否放行调用;转发请求至真实模型供应商;记录调用元数据(人员、时间、消耗)用于审计
技能库基于 OpenClaw 的 Agent/技能定义机制(Markdown + YAML 配置),将团队沉淀的常用任务预置为可分发的技能配置,随客户端分发;客户端 UI 提供技能库页面供选择调用
会话历史本地留存任务记录,并将关键元数据同步至公司后端,支撑跨设备查看、审计与成本核算
UI 层复用此前已产出的原型界面(登录页/工作台/历史记录/技能库),将模拟输出替换为真实调用 OpenClaw 服务接口的结果

05分阶段推进

阶段一 · 3-5 天

技术验证 Spike

  • 本地跑通 OpenClaw 的无头服务模式与调用接口,验证程序化发起任务、获取流式/结构化输出
  • 验证自定义 baseURL / 模型端点配置的连通性(先接一个本地模拟网关)
  • 验证 Agent(技能)定义机制的实际效果
目的:在投入后续开发资源前,把技术路径中不确定的部分先行验证清楚,避免重蹈"未验证技术可行性就排期"的问题。
阶段二 · 2-3 周

内部 Demo

  • 网关层最小实现:钉钉登录换令牌、基础调用转发、简单用量记录
  • Tauri 客户端外壳接入真实 OpenClaw 调用,复用已有 UI 原型
  • 提供 2-3 条预置技能
验证核心假设:非工程岗位能否通过该客户端有效使用 Agent 能力。
阶段三 · 验证通过后排期

企业级完善

  • 权限分级(技能按风险等级、按角色开放)
  • 完整审计日志、异常用量告警
  • 会话历史多端同步、跨人员/跨项目查看

06产品版本规划(1.0 / 2.0 / 3.0)

上一节的"阶段一/二/三"是工程交付节奏(先验证技术、再做内部 Demo、最后企业级完善);本节的"1.0/2.0/3.0"是面向员工的产品能力分期——两者是同一条路线的两个视角。总目标是做到"像 Codex 一样"的完整体验,但分三个版本落地,不追求一次做全。

1.0跑起来,验证核心闭环

  • 登录:钉钉免登 / 钉钉扫码 / 账号密码(复用公司现有账号体系),三种方式都在 1.0 范围内;员工全程不接触真实 API Key
  • Key 与调用统一走公司网关,做鉴权 + 基础用量记录
  • 客户端图形界面(参考 Codex/Typeless 风格,浅色主题),自由对话为主入口,员工不接触命令行
  • 本地执行能力落地:读写文件、跑代码,通过系统原生文件选择器由员工自选本次任务的操作对象
  • 执行过程轻量可见:把工具调用事件翻译成简短状态文案(如"正在读取文件""正在生成内容")滚动展示,不暴露原始命令与日志
  • 高风险操作弹确认框:覆盖删除文件、覆盖已有文件、外发内容(发邮件/发钉钉消息)三类
  • 内置 4 类通用技能卡:日报/周报生成、P 图/图片处理、文案润色改写、会议记录整理(只做全员通用能力,不做绑定部门 SOP 的垂直场景)
  • 管理端复用公司已有后台:数智中心查看用量、管理技能库配置等操作挂进现有管理后台,不单独为本项目做一套;并提供管理员模式解锁完整无限制执行,用于调试与处理技能库外的任务

2.0从"能用"到"好用、可控"

  • 角色权限精细化:技能库按部门/岗位打标签,客户端按角色过滤展示
  • 技能库自主配置:业务侧自己能新增/编辑技能卡,不用每次找数智中心加代码
  • 多步骤任务链:技能卡之间可串联(如"生成报表→自动排版→发到钉钉群")
  • 审计升级:除用量外,增加操作内容级别的留痕(为合规/复盘做准备)
  • 用户反馈机制:员工可给技能卡结果打分,反哺技能库迭代

3.0打通企业系统,变成基础设施

  • 打通企业内部系统数据源(ERP、工单系统、内部文档库),Agent 直接查数据而非员工手动喂
  • 跨部门协作任务:一个任务链可串联多个部门的技能
  • 内容/成本治理:按部门做用量成本核算,支持精细化的模型调用策略(不同任务用不同档次的模型)

07管理后台建设内容

管理后台不单独为本项目新建一套,而是将相关功能挂进公司已有的管理后台,以减少开发量。按产品版本分期落地:1.0 只建"最小必要集",2.0、3.0 再逐步增量。

1.0要做的(最小必要集)

1.0 阶段管理后台只需实现以下五项,其余推至后续版本,避免后台开发挤占核心闭环:

  1. Key 托管 + 令牌签发/吊销——真实供应商 API Key 集中托管、轮换、吊销(员工不可见);客户端短期令牌的签发、有效期与主动吊销(离职/异常一键断)。这是"员工不接触真实 Key"这一安全模型的底线,缺此则整体方案不成立
  2. 员工开通/停用——同步钉钉组织架构、复用公司账号(不新建);角色分配(普通员工/管理员)
  3. 基础用量查看——调用量与 Token 消耗看板,可看到谁用了多少即可
  4. 技能库配置——技能卡增删改、上下架、参数表单配置,由数智中心手动维护(含底层 skill 与"技能卡↔skill"映射)
  5. 基础操作日志——谁、何时、发起什么任务、动了哪些文件;含高风险操作(删除/覆盖/外发)的确认与执行记录
安全提示 第 1 项(Key 与令牌治理)本质是网关层的一部分,集中承载公司真实 API Key,其风险等级与"查看用量、配置技能卡"这类普通后台功能不在一个量级,须纳入第八节所述的安全设计评审,不能作为普通 CRUD 功能顺带实现。

2.0增量

  • 角色权限精细化:技能库按部门/岗位打标签,客户端按角色/部门过滤展示
  • 技能库业务侧自助配置:业务管理员可自行新增/编辑技能卡,不必每次找数智中心
  • 员工反馈查看:员工对技能卡结果的评分/反馈,反哺技能迭代
  • 审计升级:在操作日志基础上增加内容级留痕(输入/输出摘要),为合规复盘准备

3.0增量

  • 用量成本治理:按部门做成本核算报表,支撑内部分摊
  • 模型调用策略:按角色/部门配置配额与模型档次(不同任务用不同档次的模型)
  • 企业数据源接入管理:ERP、工单系统、内部文档库等连接的配置与管理

08风险与明确排除项

OpenClaw 作为开源项目存在组织与版本层面的不确定性

社区活跃度、版本稳定性、组织治理需要持续关注,评估长期依赖的稳定性,不建议将其视为零风险的选择。此外,本文档对 OpenClaw 具体接口能力的描述需在阶段一 Spike 中以官方文档和实测确认,验证前不作为既定事实。

网关代理层是新增的攻击面和单点故障点

它集中持有公司的真实 API Key,一旦设计不严谨,风险等级不亚于此前可行性分析报告中提示的"Key 集中托管"风险,需要单独进行安全设计评审,不能与业务功能一起顺带实现。

桌面客户端的跨平台打包、签名、自动更新是真实工作量

这在此前的可行性分析报告中已提示过,即便采用 Tauri 这类相对轻量的方案,也需要单独排期,不是界面开发的附属工作。

明确排除:浏览器访问、电脑操作(computer use)类工具

这类能力(让 AI 像人一样操作鼠标键盘、控制屏幕、访问已登录的浏览器会话)风险等级与本方案设计的"沙箱化 Agent 执行"完全不在一个量级,一旦开放,员工电脑上的任意应用、任意已登录账号都可能被触及。本方案不包含这部分能力,如后续确有业务需求,应作为独立项目单独立项,进行专项的安全设计评估,不与本方案合并推进。

09与先马AI工作室的关系

先马AI工作室(对话式 LLM 应用)与本方案(Agent 级能力封装)服务的是不同的任务层级,不建议合并为同一套架构:

是否废弃先马AI工作室,应在本方案上线并观察真实使用数据后再判断,不应在方案设计阶段预设结论。

10与原可行性分析报告的关键差异

维度原报告(2026-07-08)本方案
产品形态纯 Web 端桌面客户端(Tauri)
执行位置服务器端沙箱环境员工电脑本地
底层 Agent未指定,以 Codex 为例明确选定 OpenClaw(开源 Agent 底层框架、擅长工具调用管理与权限定制)
Key 管理方式Key 全程留在服务器,不下发到客户端Key 留在公司网关层,客户端仅持有短期可吊销令牌
技能库实现方式需自建技能模板系统复用 OpenClaw 的 Agent/技能定义机制
核心技术风险Codex CLI 能否被程序化包装,未经验证以 OpenClaw 的无头/程序化调用能力为路径,具体接口需阶段一 Spike 实测确认

差异产生的根本原因:原报告基于"目标用户不需要操作本地文件"的假设设计,而后续确认领导需要的是真正的 Agent 级执行能力(读写文件、执行代码),这在纯 Web 端沙箱模式下难以自然实现,因此调整为本地客户端架构。