讓我們從一個所有做企業 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