
在 LLM 驱动的开发平台中,工具(Tool) 和 技能(Skill) 是连接自然语言与系统能力的桥梁。工具是 LLM 可调用的 Function Calling 单元,技能是封装了领域知识和流程上下文的执行单元。随着业务场景的不断扩展,Ooder 平台从最初的几十个工具发展为涵盖 150+ 工具、26 个能力、23 个流程定义的庞大体系。如何让这些工具和技能有序运作,成为架构设计的核心挑战。
本文将深入剖析 Ooder 工具与技能体系的架构设计,分享我们从"混沌"走向"秩序"的演进思路。

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

图 1:三套并行的工具注册机制
问题:三套机制各自独立注册,工具重复注册、分类标准不统一、无法通过统一入口查询全部工具。
每个工具(ChatTool 接口)通过五个维度进行分类:
维度 | 说明 | 现状问题 |
|---|---|---|
业务类型(Category) | 工具的业务归属 | 混合动作分类和领域分类,命名不统一 |
披露层级(DisclosureLevel) | 何时注入到 LLM 上下文 | 130+ 工具中仅 3 个设置了 ALWAYS |
设计强度(DesignIntensity) | FLASH / NORMAL / HEIGHT | 全部工具未赋值 |
工作模式(ToolMode) | CHAT / DESIGNER / BUSINESS | 全部工具未赋值 |
流程绑定(FlowDefId) | 所属流程定义 | 独立工具返回 null,能力工具缺失 |
技能(Skill)通过 skillflow-vfs 的 definition.json 定义,但:
我们将工具和技能统一到同一个五维分类矩阵中:

图 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)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设计强度(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:工具与技能的双向映射关系
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{
"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:统一注册中心架构

图 5:渐进式工具披露流程
维度 | 改造前 | 改造后 |
|---|---|---|
工具分类维度 | 1 个 (Category) | 5 个 (Category + Disclosure + Intensity + Mode + Flow) |
技能分类维度 | 0 个 | 5 个 |
注册中心 | 3 套独立 | 1 套统一 |
分类准确性 | 60% | 100% |
工具-技能映射 | 无 | 双向 |
LLM 上下文效率 | 全部注入 | 渐进式注入 |
工具与技能的分类体系是 LLM 驱动平台的基础设施。从"混沌"到"秩序"的演进,不仅是代码层面的重构,更是对"如何让 LLM 高效理解和使用系统能力"这一问题的深入思考。通过五维分类矩阵、统一注册中心和渐进式披露机制,Ooder 为 LLM 提供了更精准、更高效的工具调用体验。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。