LLM工具与技能体系架构设计--从混沌到秩序的演进之路需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

前言

在 LLM 驱动的开发平台中，工具（Tool） 和 技能（Skill） 是连接自然语言与系统能力的桥梁。工具是 LLM 可调用的 Function Calling 单元，技能是封装了领域知识和流程上下文的执行单元。随着业务场景的不断扩展，Ooder 平台从最初的几十个工具发展为涵盖 150 工具、26 个能力、23 个流程定义的庞大体系。如何让这些工具和技能有序运作，成为架构设计的核心挑战。

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

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

1.1 三套工具注册机制

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

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

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

1.2 工具分类的五个维度

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

1.3 技能分类的缺失

技能（Skill）通过 skillflow-vfs 的 definition.json 定义，但：

二、设计：五维分类矩阵

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 披露层级策略

复制

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

2.4 设计强度与工作模式

设计强度（DesignIntensity） 控制工具是否在对应增强力度下可用：

复制

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

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

复制

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

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

3.1 对齐方案

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

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

3.2 技能分类枚举

复制

SkillCategory 枚举:PLATFORM_CORE── 平台核心: intent-dispatchARCHITECT── 设计: architect-pipeline, designerfirst-buildBUSINESS ── 业务: business-pipeline, bpm-sceneCHAT ── 对话: chat-pipelineSUBFLOW── 子流程: understand-subflow, component-generate-subflowSCENE── 场景: deep-design-scene, patent-review-sceneKNOWLEDGE── 知识: knowledge-init-pipeline, docview-knowledge-initBUILD── 构建: 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 重构收益

5.2 未来方向

结语