让我们从一个所有做企业 Agent 的人都遇到过的具体场景说起。某券商风控员要给客户开通融资融券账户传统流程是这样的登录 OA 提风控审批 → 跳到 CRM 拉客户资料 → 跳到风控系统填评估表 → 跳到电子签平台发签约链接 → 回 OA 关单。十几个字段反复填跨四个系统切换单子办下来 30 分钟。如果你试过把这个流程交给一个 GPT-4 function calling 的 Agent 来跑结果大概率是这样模型能聊得很顺但真到调用环节就开始扑街——参数对不上、字段命名乱、调用失败没有兜底、人在哪个节点该介入说不清、跨系统的状态不知道往哪存。这不是模型能力的问题。是模型能力和企业系统现实之间存在一段没人写过的工程层。这段工程层是兔展智能 SkillsUI想填的坑。SkillsUI 当前已开放免费模拟体验注册还送积分https://skillsui.rabbitpre.com.cn/?ccsdn下面我们试着把它的设计取舍说清楚——尤其是给同样在做企业 Agent、被这些问题反复磨过的工程师看。问题的本质function calling 和 MCP 解决不了的那段路过去两年企业 AI 工程化的工具链已经卷出了几层底层function callingOpenAI、Anthropic、MCPModel Context ProtocolAnthropic 推出的工具协议编排层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意图识别把用户的自然语言映射到一个或多个 Skill2任务规划决定 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上接续、大屏上确认要解决三个问题1Session 状态序列化业务上下文 当前节点 已填字段必须能跨端恢复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 在设计上的关键决策值得拉出来说说。它们不是产品功能是真正的工程取舍。决策 180/20 原则——AI 不替人做关键决策所有涉及金额、合同、对外发送、设备指令的节点AI 只完成“准备工作”最终一键由人确认。这件事在 Skill schema 里是一等公民不是后加的功能。这是企业级 Agent 能跑生产的最低门槛。决策 2复用原系统的权限边界不另建一套SkillsUI 调用任何系统时使用的是当前用户在原系统里的权限——不会越权、不会绕过审批。这避免了一个非常危险的反模式Agent 拿一个超级账号去办所有人的事。决策 3全链路 tracing 和审计日志每一次 Skill 调用——谁、什么时候、调用了什么、传了什么参数、收到什么结果——全部进审计日志。这一条不只是合规要求对工程团队而言是 debug 一个出错 Agent 的唯一抓手。设计上和 Langfuse、LangSmith 这类 LLM 可观测平台类似但更下沉到了业务节点。决策 4Skill 的版本控制和灰度发布业务系统会变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/?ccsdn
给老系统装一层 “能办事的 AI”：企业 Agent 卡住的最后一步，SkillsUI 想补上
发布时间：2026/5/23 0:15:29
让我们从一个所有做企业 Agent 的人都遇到过的具体场景说起。某券商风控员要给客户开通融资融券账户传统流程是这样的登录 OA 提风控审批 → 跳到 CRM 拉客户资料 → 跳到风控系统填评估表 → 跳到电子签平台发签约链接 → 回 OA 关单。十几个字段反复填跨四个系统切换单子办下来 30 分钟。如果你试过把这个流程交给一个 GPT-4 function calling 的 Agent 来跑结果大概率是这样模型能聊得很顺但真到调用环节就开始扑街——参数对不上、字段命名乱、调用失败没有兜底、人在哪个节点该介入说不清、跨系统的状态不知道往哪存。这不是模型能力的问题。是模型能力和企业系统现实之间存在一段没人写过的工程层。这段工程层是兔展智能 SkillsUI想填的坑。SkillsUI 当前已开放免费模拟体验注册还送积分https://skillsui.rabbitpre.com.cn/?ccsdn下面我们试着把它的设计取舍说清楚——尤其是给同样在做企业 Agent、被这些问题反复磨过的工程师看。问题的本质function calling 和 MCP 解决不了的那段路过去两年企业 AI 工程化的工具链已经卷出了几层底层function callingOpenAI、Anthropic、MCPModel Context ProtocolAnthropic 推出的工具协议编排层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意图识别把用户的自然语言映射到一个或多个 Skill2任务规划决定 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上接续、大屏上确认要解决三个问题1Session 状态序列化业务上下文 当前节点 已填字段必须能跨端恢复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 在设计上的关键决策值得拉出来说说。它们不是产品功能是真正的工程取舍。决策 180/20 原则——AI 不替人做关键决策所有涉及金额、合同、对外发送、设备指令的节点AI 只完成“准备工作”最终一键由人确认。这件事在 Skill schema 里是一等公民不是后加的功能。这是企业级 Agent 能跑生产的最低门槛。决策 2复用原系统的权限边界不另建一套SkillsUI 调用任何系统时使用的是当前用户在原系统里的权限——不会越权、不会绕过审批。这避免了一个非常危险的反模式Agent 拿一个超级账号去办所有人的事。决策 3全链路 tracing 和审计日志每一次 Skill 调用——谁、什么时候、调用了什么、传了什么参数、收到什么结果——全部进审计日志。这一条不只是合规要求对工程团队而言是 debug 一个出错 Agent 的唯一抓手。设计上和 Langfuse、LangSmith 这类 LLM 可观测平台类似但更下沉到了业务节点。决策 4Skill 的版本控制和灰度发布业务系统会变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/?ccsdn
