给老系统装一层 “能办事的 AI”：企业 Agent 卡住的最后一步，SkillsUI 想补上

让我们从一个所有做企业 Agent 的人都遇到过的具体场景说起。

某券商风控员要给客户开通融资融券账户，传统流程是这样的：登录 OA 提风控审批 → 跳到 CRM 拉客户资料 → 跳到风控系统填评估表 → 跳到电子签平台发签约链接 → 回 OA 关单。十几个字段反复填，跨四个系统切换，单子办下来 30 分钟。

如果你试过把这个流程交给一个 GPT-4 + function calling 的 Agent 来跑，结果大概率是这样：模型能聊得很顺，但真到调用环节就开始扑街——参数对不上、字段命名乱、调用失败没有兜底、人在哪个节点该介入说不清、跨系统的状态不知道往哪存。

这不是模型能力的问题。是模型能力和企业系统现实之间，存在一段没人写过的工程层。

这段工程层是兔展智能 SkillsUI 想填的坑。

SkillsUI 当前已开放免费模拟体验，注册还送积分：https://skillsui.rabbitpre.com.cn/?c=csdn

下面我们试着把它的设计取舍说清楚——尤其是给同样在做企业 Agent、被这些问题反复磨过的工程师看。

问题的本质：function calling 和 MCP 解决不了的那段路

过去两年，企业 AI 工程化的工具链已经卷出了几层：

• 底层：function calling（OpenAI、Anthropic）、MCP（Model Context Protocol，Anthropic 推出的工具协议）；
  

• 编排层：LangChain / LangGraph、AutoGen、CrewAI、OpenAI Assistants API；
  

• 应用层：各家自研的 Agent 平台、Copilot 类产品。

但真到企业内部落地，开发者会遇到几个共同的问题：

问题 1：企业 API 是给人写的，不是给 AI 写的。
参数命名混乱，文档残缺，字段含义靠口口相传。直接喂给 LLM 做 function calling，调用成功率经常不到 50%。

问题 2：复杂业务流程里，“人”必须被留下来。
金额确认、合同签字、对外发送指令——这些节点不能让 Agent 自己拍板。但社区里大部分 Agent 框架对“人在环”（Human-in-the-Loop）的处理都很潦草，要么是 input() 阻塞，要么是把整个流程序列化暂停，工程上不优雅。

问题 3：纯文本对话承载不了企业级交互。
让员工在聊天框里“敲十行字描述一个表单字段”，体验比直接打开旧系统还差。但社区里大部分 Agent 框架的输出形态还是文本流。

问题 4：跨端续办的状态一致性没人管。
手机上发起、PC 上接续、大屏上确认——这是企业一线作业的常态，但 session 状态怎么序列化、上下文怎么续传、节点状态怎么同步，社区里几乎没有标准答案。

SkillsUI 的设计逻辑，就是把这四个问题逐个工程化解决。

三层架构：Agent 调度 / Skill 工作流 / AIUI 卡片

SkillsUI 把企业 Agent 拆成了三层，每一层职责单一、互相解耦：

下面分别讲每一层的工程取舍。

2.1 Agent 调度层：把 Planning 和 Skill 编排彻底分开

很多 Agent 框架的常见反模式是——把任务规划、参数解析、API 调用、错误处理全都塞进 Agent 的 prompt 里，靠 ReAct 循环硬扛。这种做法在 demo 里看着很聪明，到生产环境立刻被否掉：

• 一旦业务规则变了，要回去改 prompt；
  

• 错误处理逻辑分散在 LLM 的"思考"里，不可控；
  

• 复杂流程的步数一多，token 成本和延迟都失控；
  

• 没有稳定的 schema，幻觉问题很难收敛。

SkillsUI 的做法是把 Agent 调度层的职责严格收窄——它只做三件事：

（1）意图识别：把用户的自然语言映射到一个或多个 Skill；

（2）任务规划：决定 Skill 的执行顺序，处理依赖关系；

（3）多轮 slot filling：缺参数主动问询，不盲目猜测。

具体的业务规则、异常处理、人机协同节点——全部下沉到 Skill 层内部。Agent 调度层不感知 Skill 的实现细节，只感知它的输入输出 schema。

这个分层和 LangGraph 的“显式状态机 + 节点化”思路同向，但 SkillsUI 把“状态机的节点定义”做成了一个有完整工程规范的 Skill 资产，而不是写死在代码里的 graph。

2.2 Skill 层：原子能力的“可执行规范”

这是 SkillsUI 最值得讲的一层，也是和 MCP、LangChain Tools 拉开差距的地方。

社区主流的工具调用，本质上就是一个 JSON Schema + 一个执行函数。但企业级业务里，一个“能让 Agent 真正办事”的能力单元，至少要包含五样东西：

• 输入参数规范
  

• 业务规则
  

• 多系统调度链路
  

• 异常处理
  

• 人机协同节点

为什么要这么“重”？

因为企业级 Agent 的可靠性，不是靠 LLM 的“思考”挣来的，是靠把不确定性收敛在 Skill 内部挣来的。

LLM 只负责选用哪个 Skill 和填什么参数，剩下的全部由 Skill 自己保证。

这套 Skill 抽象和 MCP 的关系是：MCP 解决的是“模型怎么连工具”，Skill 解决的是“工具长什么样才适合 AI 调用”。

Skill 可以无缝以 MCP 协议对外暴露，但它本身的设计规范比 MCP 更丰富。

2.3 AIUI 层：把“输出形态”从文本流升级到可交互卡片

这层是 SkillsUI 在产品形态上最有辨识度的判断——企业级 AI 入口不该是聊天框。

办企业级业务，员工要做的动作是：填表、对比、确认、签字、上传附件。这些动作在文字对话里都很别扭。SkillsUI 把交互单元拆成了一组卡片：

• 输入采集卡：替代纯文本提问，让用户在卡片上选参数、填字段、上传文件；
  

• 进度卡：跨系统调用过程中的实时阶段提示（流式 + step 级别）；
  

• 结果回显卡：把业务数据以表格、指标、决策矩阵的形式可视化呈现；
  

• 关键节点确认卡：金额、合同、签字等节点的“一键确认”。

这个判断和 Anthropic Artifacts、ChatGPT Canvas 同向——AI 的输出形态正在从“一段文本”进化为“一个可交互工作单元”。SkillsUI 把它推得更远，直接定义为企业入口的标准形态。

▲卡片化办事前后对比

工程上更值得讲的是跨端续办。

一张卡片在手机上发起、PC上接续、大屏上确认，要解决三个问题：

（1）Session 状态序列化：业务上下文 + 当前节点 + 已填字段，必须能跨端恢复；

（2）节点幂等性：同一个节点被两端同时操作时，必须有版本号 / 乐观锁防止脏写；

（3）实时同步：用 WebSocket / SSE 推送状态变更，避免一端操作后另一端看到旧状态。

这些是任何做过分布式协作系统的人都熟悉的工程问题，但放到 Agent 的 session 上下文里，社区里现在还没有成熟方案。

接入工程：从存量 API 到可调度 Skill

技术人员最关心的工程问题之一：那这套东西怎么接到我已有的几百个 API 上？

SkillsUI 给出了两条路径：

路径一：基于 OpenAPI/Swagger 的半自动化生成

如果你的系统有规范的接口文档，工具会做这几件事：

（1）解析 OpenAPI 文档，提取接口语义、入参出参、错误码；

（2）用 LLM 做语义增强——把 flag1: int 这种字段名翻译成“是否需要风控审批”这种 AI 可读的描述；

（3）生成 Skill 骨架，自带基础的参数校验、重试、错误处理；

（4）在可视化面板上人工微调——补充业务规则、定义 HITL 节点、配置异常分支。

这一步不是 5 分钟。真实工程里，一个中等复杂度的业务 Skill，从 API 文档到生产可用，通常需要 0.5–2 个工作日。但相比从零写一套 LangChain Tool + 编排逻辑，已经是数量级的提速。

路径二：业务嗅探（针对没有标准接口的老旧系统）

很多政务、金融、医疗的老系统没有 OpenAPI 文档，甚至接口本身就是非标 SOAP 或自定义协议。SkillsUI 的做法是：

（1）在企业授权下，挂在系统的网关层做流量观测；

（2）用模型反推接口语义和数据结构；

（3）半自动生成 Skill，工程师再做一次复核。

这套思路接近“AI 时代的 API 文档逆向工程”，对老旧系统的 AI 化是一个相对务实的入口。

几个工程层面的关键设计决策

讲到这里，有几个 SkillsUI 在设计上的关键决策值得拉出来说说。它们不是产品功能，是真正的工程取舍。

决策 1：80/20 原则——AI 不替人做关键决策

所有涉及金额、合同、对外发送、设备指令的节点，AI 只完成“准备工作”，最终一键由人确认。这件事在 Skill schema 里是一等公民，不是后加的功能。

这是企业级 Agent 能跑生产的最低门槛。

决策 2：复用原系统的权限边界，不另建一套

SkillsUI 调用任何系统时，使用的是当前用户在原系统里的权限——不会越权、不会绕过审批。

这避免了一个非常危险的反模式：Agent 拿一个超级账号去办所有人的事。

决策 3：全链路 tracing 和审计日志

每一次 Skill 调用——谁、什么时候、调用了什么、传了什么参数、收到什么结果——全部进审计日志。这一条不只是合规要求，对工程团队而言是 debug 一个出错 Agent 的唯一抓手。

设计上和 Langfuse、LangSmith 这类 LLM 可观测平台类似，但更下沉到了业务节点。

决策 4：Skill 的版本控制和灰度发布

业务系统会变，Skill 也得变。SkillsUI 把 Skill 当作有版本的 artifact 管理——支持灰度发布、回滚、多版本并存。这件事在大部分 Agent 框架里现在还是缺失的。

在行业生态里的位置

一句话讲清楚 SkillsUI 在生态里的位置：

SkillsUI 不和模型层、协议层、编排层竞争——相反，它依赖这些底层的能力。

它要解决的是上层的应用 / 中间层问题：把企业的存量系统能力，重新组织成 AI 可以稳定调用、用户可以一句话办成的 Skill 资产。

这一层目前在中国市场还很空。SkillsUI 的核心赌注是——这一层会变成下一阶段企业 AI 落地的标准形态。

留给同行的一个问题

最后，留给所有正在做企业 Agent 的工程师一个问题：

你公司未来三年的 IT 入口长什么样？

如果答案还是“打开 ERP、找菜单、点按钮”，那你团队接下来三年的工作大概率会越来越没人愿意用。

如果答案是“说一句话，事情就办了”，那从今天开始你需要回答几个工程问题：你的 API 是不是 AI 可读的？你的业务流程有没有显式的 HITL 节点？你的 session 状态能不能跨端续办？你的 Agent 调用有没有完整 tracing？

这一层早晚要有人做。不一定是 SkillsUI，但一定是一层中间层。

欢迎点击【阅读原文】，跳转至 SkillsUI 官网链接！SkillsUI 当前已开放免费模拟体验，注册还送积分：https://skillsui.rabbitpre.com.cn/?c=csdn