前言

在 LLM 驱动的开发平台中，工具（Tool） 和 技能（Skill） 是连接自然语言与系统能力的桥梁。

工具是 LLM 可调用的 Function Calling 单元。技能是封装了领域知识和流程上下文的执行单元。

随着业务场景的不断扩展，Ooder 平台从最初的几十个工具发展为涵盖 150 工具、26 个能力、23 个流程定义的庞大体系。

如何让这些工具和技能有序运作，成为架构设计的核心挑战。

本文将深入剖析 Ooder 工具与技能体系的架构设计，分享我们从"混沌"走向"秩序"的演进思路。

---

一、现状：多轨并行的分类体系

1.1 三套工具注册机制

Ooder 目前存在三套并行的工具注册机制：

图 1：三套并行的工具注册机制

问题：三套机制各自独立注册，工具重复注册、分类标准不统一、无法通过统一入口查询全部工具。

1.2 工具分类的五个维度

每个工具（ChatTool 接口）通过五个维度进行分类：

维度	说明	现状问题
业务类型(Category)	工具的业务归属	混合动作分类和领域分类，命名不统一
披露层级(DisclosureLevel)	何时注入到 LLM 上下文	130 工具中仅 3 个设置了 ALWAYS
设计强度(DesignIntensity)	FLASH / NORMAL / HEIGHT	全部工具未赋值
工作模式(ToolMode)	CHAT / DESIGNER / BUSINESS	全部工具未赋值
流程绑定(FlowDefId)	所属流程定义	独立工具返回 null，能力工具缺失

1.3 技能分类的缺失

技能（Skill）通过 skillflow-vfs 的 definition.json 定义，但目前仍存在明显缺失。

• 缺少 disclosureLevel、designIntensity、toolMode 等分类维度

• RichSkill 只有 skillId、name、version、category 四个字段

• 技能与工具之间没有双向映射关系

---

二、设计：五维分类矩阵

2.1 分类维度全景

我们将工具和技能统一到同一个五维分类矩阵中：

图 2：工具/技能五维分类矩阵

2.2 业务类型分类标准

统一后的业务类型分类（ToolCategory 枚举）：

文件类: file_operation (vfs_file_read, vfs_file_write) 代码类: code_operation (code_search, sandbox_read_logs) 系统类: system_operation (shell_execute) 流程类: flow_dispatch(switch_scene_flow) 查询类: flow_query (list_flow_definitions, get_flow_detail) 设计类: component_design (nlp_build_component, insert_component) SVG类:svg_design (svg_free_generate, svg_ooder_convert) 知识类: knowledge_retrieval(lucene_search, search_knowledge) 知识库管理类:knowledge_base (import_document, batch_parse_documents) 配置类: config_management(get_system_config, update_llm_config) 工作管理类: work_management(todo_create, snapshot_list) 技能管理类: skill_management (skill.list, skill.install) 专利审查类: patent_review(patent_parse_text, patent_form_review) 上下文管理类:context_management (context_inspect, context_compress) 表单审核类: form_review(form_review) 人机交互类: human_interaction(human_confirm, human_operation) 工作流管理类:workflow_management(create_activity, deploy_process) 表单管理类: form_management(list_forms, generate_form_schema) 组织管理类: organization_management (get_organization_tree, search_users) 场景管理类: scene_management (list_scene_templates, match_scene_by_activity) 能力发现类: capability_discovery (list_capabilities, search_capabilities) 文档渲染类: document_rendering (render_document, render_chart) 文档交互类: document_interaction (doc_operate, doc_operate_check) 设计器渲染类:designer_rendering (render_database_diagram, render_uml_diagram) 持久层类: persistence_layer(persistence.generate, persistence.compile) 沙箱DevOps类: sandbox_devops (sandbox_read_logs, sandbox_compile)

2.3 披露层级策略

披露层级的目标，是控制工具在什么时机进入 LLM 上下文。

ALWAYS (核心) ──── 系统基础设施工具3个: vfs_file_read, vfs_file_write, switch_scene_flow 注入时机: 始终注入到 LLM 上下文 Token预算: 300 ON_FLOW_SELECTED (场景) ──── 领域业务工具18个独立工具 全部能力工具 注入时机: 流程匹配后注入 Token预算: 500 ON_ACTIVITY_START (活动) ──── 交互确认工具1个: human_confirm 注入时机: 活动启动时注入 Token预算: 400 ON_DEMAND (动态) ──── 按需加载工具深度知识检索、高级设计工具 注入时机: LLM 执行时按需加载 Token预算: 1000

2.4 设计强度与工作模式

设计强度（DesignIntensity）本质上是在控制：某个工具，是否会在对应的增强力度下被开放使用。

FLASH── MVP 快速生成: get_component_template, get_layout_template NORMAL ── 轻量分析: list_page_components, get_component_info HEIGHT ── 深度质量: four_separation_audit, compliance_refine 空数组 ── 通用: 所有模式下可用

工作模式（ToolMode）控制工具在哪种对话模式下可用：

CHAT ── 知识检索、文档渲染、文件操作 DESIGNER ── 组件设计、页面操作、SVG设计 BUSINESS ── 工作流管理、表单管理、组织管理 空数组 ── 通用: 所有模式下可用

---

三、对齐：技能与工具的映射

3.1 对齐方案

将技能分类体系与工具分类体系对齐的核心思路：

图 3：工具与技能的双向映射关系

3.2 技能分类枚举

SkillCategory 枚举： PLATFORM_CORE── 平台核心：intent-dispatch ARCHITECT── 设计：architect-pipeline、designerfirst-build BUSINESS ── 业务：business-pipeline、bpm-scene CHAT ── 对话：chat-pipeline SUBFLOW── 子流程：understand-subflow、component-generate-subflow SCENE── 场景：deep-design-scene、patent-review-scene KNOWLEDGE── 知识：knowledge-init-pipeline、docview-knowledge-init BUILD── 构建：dbfirst-build、viewfirst-build、svg-paper-build

3.3 流程定义中的技能元数据扩展

{"definitionId": "bpm-scene","workMode": "work","classification": "bpm_orchestration","skillCategory": "BUSINESS","disclosureLevel": "ON_FLOW_SELECTED","designIntensity": ["NORMAL", "HEIGHT"],"toolMode": ["BUSINESS"],"activities": [{"activityId": "ae_analyze_process","skillId": "ae_analyze_process","activityToolIds": ["process_knowledge"],"disclosureLevel": "ON_ACTIVITY_START"}]}

---

四、重构：从三轨到统一

4.1 统一注册中心架构

图 4：统一注册中心架构

4.2 渐进式工具披露流程

图 5：渐进式工具披露流程

---

五、收益与展望

5.1 重构收益

维度	改造前	改造后
工具分类维度	1 个 (Category)	5 个 (Category Disclosure Intensity Mode Flow)
技能分类维度	0 个	5 个
注册中心	3 套独立	1 套统一
分类准确性	60%	100%
工具-技能映射	无	双向
LLM 上下文效率	全部注入	渐进式注入

5.2 未来方向

• 工具自动分类：基于向量相似度的自动分类推荐

• 技能市场：技能包的可发现、可安装、可卸载

• 工具热加载：运行时动态注册/卸载

• 工具分类审计：自动校验分类完整性

---

结语

Ooder 工具与技能体系的演进，本质上是从分散治理走向统一治理。

通过五维分类矩阵、技能与工具的双向映射，以及统一注册中心架构，平台逐步建立起清晰、可扩展、可管理的能力体系。

这不仅提升了分类准确性和上下文效率，也为后续的自动分类、技能市场、工具热加载与分类审计打下了基础。