AI 智能体 CLI Skill 企业系统 2026-02-28

从浏览器到命令行：企业系统的 AI 化重构

如何将传统企业系统改造为 AI 智能体友好的接口

引言

受到 Anthropic 关于智能体技能（Agent Skills）分享的启发，我们开始重新思考企业系统的交互范式。

传统系统为人类设计，依赖浏览器和图形界面；但面向 AI 智能体，我们需要另一种思路——将系统能力 CLI 化，再通过 Skill 封装。

问题的本质：人机接口 vs 智能体接口

让我们先看一个典型的企业应用场景：员工需要通过浏览器登录 OA 系统，点击几个菜单，填写一张表单，然后提交审批。

这个过程对人类来说很自然，但对 AI 智能体来说却充满挑战：

  • 需要模拟浏览器行为，处理复杂的 DOM 结构
  • 需要理解视觉布局，识别按钮、输入框的位置
  • 需要处理登录态、Cookie、Session 等状态管理
  • 界面变化可能导致整个自动化流程失效

这就像让一个只会说英语的人去填写一份中文表格——虽然理论上可行，但效率极低，而且容易出错。

Anthropic 的启示：Skill 作为能力单元

Anthropic 的思路给了我们一个重要启发：与其让智能体去"操作"人类界面，不如为智能体提供专用的能力接口。

这就是 Skill（技能）的概念。

“A skill is a self-contained capability that an agent can invoke to accomplish a specific task.” — Anthropic

换句话说，我们应该把系统能力抽象成一个个独立的技能单元，智能体只需要知道"调用哪个技能"和"传递什么参数"，而不需要关心底层实现的细节。

我们的实践：CLI + Skill 封装

基于这个思路，我们在企业系统 AI 化过程中，探索出了一条可行的路径。

第一步：系统能力 CLI 化

我们将原有系统的核心能力，从"浏览器操作"重构为"命令行接口"。

例如，原来需要通过网页表单提交的审批流程，现在可以通过这样的命令完成：

# 提交审批
oa approval create \
  --type "expense" \
  --amount 5000 \
  --description "项目差旅费用" \
  --approver "manager@company.com"

这种方式有几个明显优势：

  • 确定性：命令行参数是结构化的，不会因为界面变化而失效
  • 可组合：多个命令可以通过管道、脚本组合成复杂流程
  • 可测试：每个命令都可以独立测试和验证
  • 低开销：不需要启动浏览器，资源占用更少

第二步：Skill 封装

有了 CLI 接口，下一步就是用 Skill 来封装。我们定义了一套标准的 Skill 结构：

expense-approval/
├── SKILL.md           # 必需：技能描述文档
├── scripts/
│   └── submit.py      # 可选：执行脚本
└── templates/
    └── form.json      # 可选：模板文件

SKILL.md 是 Skill 的核心描述文件，采用 Markdown + YAML Frontmatter 格式：

---
name: 费用审批提交
description: 提交费用审批申请。在需要报销费用、提交审批流程时使用。
---

# 费用审批提交

## 功能

提交费用审批申请到 OA 系统：
- 支持多种费用类型（差旅、招待、办公等）
- 自动关联审批人
- 生成审批单号

## 使用方法

1. 用户描述费用信息（金额、类型、说明）
2. 确认审批人
3. 执行提交

## 脚本说明

`scripts/submit.py` 参数：
- `--type`：费用类型（expense/travel/office）
- `--amount`：金额
- `--description`：费用说明
- `--approver`：审批人邮箱

## 示例

提交差旅费用：
python scripts/submit.py \
  --type travel \
  --amount 5000 \
  --description "项目差旅费用" \
  --approver "manager@company.com"

## 权限要求

需要 OA 系统的"费用提交"权限。

这样，AI 智能体只需要读取 SKILL.md，就能理解这个技能的用途、参数和使用方法，完全不需要知道 OA 系统的界面长什么样。

第三步：权限复用

企业系统的 Skill 改造还有一个关键点：复用现有的授权机制。

我们不需要重新设计一套权限系统，而是直接复用企业已有的 HTTP Cookie 或 JWT 授权机制：

  • 数字员工有账号：在统一用户中心为数字员工创建账号
  • 复用现有 Token：数字员工登录后获取 Cookie/JWT Token
  • CLI 携带认证：命令行工具自动携带认证信息
  • 权限隔离：数字员工只能访问其账号权限范围内的资源

这种方式的优势：

  • 改造最小：不需要修改现有系统的权限逻辑
  • 安全合规：所有操作都有审计记录
  • 权限隔离：不同数字员工有不同的权限边界
# CLI 工具自动使用存储的认证信息
oa approval create --type expense ...
# 实际请求会携带: Authorization: Bearer <数字员工的JWT>

效果：调用效率的质的飞跃

通过这种"CLI + Skill"的架构，我们观察到几个显著的变化：

  • 调用延迟降低 90%：从原来的浏览器自动化（秒级）变成命令行调用（毫秒级）
  • 成功率接近 100%：不再受界面变化、元素定位失败等问题影响
  • 可维护性大幅提升：底层系统升级时，只需要保持 CLI 接口稳定即可
  • 智能体理解更准确：结构化的 Skill 描述比视觉界面更容易被 AI 理解
  • 权限管理清晰：复用现有授权体系，权限边界明确

架构对比

维度浏览器自动化CLI + Skill
延迟秒级毫秒级
稳定性受界面影响接口稳定
资源占用高（浏览器）低
可调试性困难容易
智能体友好度低高
权限管理模糊复用现有体系

写在最后

企业系统的 AI 化，不是简单地"让 AI 学会用人的工具"，而是为 AI 设计专用的工具。

从浏览器到命令行，从图形界面到 Skill 封装，这是一条需要重构思维的道路。但好消息是，我们可以复用现有的授权体系，让改造最小化、风险可控。

我们仍在探索中，但已经看到了这条路的潜力。如果你也在做类似的事情，欢迎交流讨论。

作者：感物技术团队

返回博客列表