首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >LLM工具与技能体系架构设计--从混沌到秩序的演进之路

LLM工具与技能体系架构设计--从混沌到秩序的演进之路

原创
作者头像
OneCode
发布2026-08-12 09:30:16
发布2026-08-12 09:30:16
880
举报
文章被收录于专栏:ooderAgentooderAgent

前言

在 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 枚举):

代码语言:javascript
复制
文件类:       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 披露层级策略

代码语言:javascript
复制
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) 控制工具是否在对应增强力度下可用:

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

工作模式(ToolMode) 控制工具在哪种对话模式下可用:

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

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

3.1 对齐方案

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

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

3.2 技能分类枚举

代码语言:javascript
复制
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 流程定义中的技能元数据扩展

代码语言:javascript
复制
{
  "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 未来方向

  1. 工具自动分类:基于向量相似度的自动分类推荐
  2. 技能市场:技能包的可发现、可安装、可卸载
  3. 工具热加载:运行时动态注册/卸载工具
  4. 分类审计:自动校验分类完整性

结语

工具与技能的分类体系是 LLM 驱动平台的基础设施。从"混沌"到"秩序"的演进,不仅是代码层面的重构,更是对"如何让 LLM 高效理解和使用系统能力"这一问题的深入思考。通过五维分类矩阵、统一注册中心和渐进式披露机制,Ooder 为 LLM 提供了更精准、更高效的工具调用体验。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 前言
  • 一、现状:多轨并行的分类体系
  • 1.1 三套工具注册机制
  • 1.2 工具分类的五个维度
  • 1.3 技能分类的缺失
  • 二、设计:五维分类矩阵
  • 2.1 分类维度全景
  • 2.2 业务类型分类标准
  • 2.3 披露层级策略
  • 2.4 设计强度与工作模式
  • 三、对齐:技能与工具的映射
  • 3.1 对齐方案
  • 3.2 技能分类枚举
  • 3.3 流程定义中的技能元数据扩展
  • 四、重构:从三轨到统一
  • 4.1 统一注册中心架构
  • 4.2 渐进式工具披露流程
  • 五、收益与展望
  • 5.1 重构收益
  • 5.2 未来方向
  • 结语
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档