Agent Skills V2

目录

Agent Skills ≠ 必须使用 LLM
核心概念澄清
Agent Skills 架构的本质：
🧩 模块化能力单元 - 可被 Agent 调用的独立功能模块
📋 明确的输入输出契约 - 通过 SKILL.md 定义
🔌 标准化接口 - 易于集成和调用
✅ 可测试、可审计 - 独立验证
注意：Agent Skills 的"Agent"指的是调用者是 Agent，而不是技能本身必须是 Agent。

优势

1. 松耦合设计 - 独立性与集成性并存

Skills 既可以独立运行(CLI),也可以被 Agent 调用:
这意味着:
开发者可以直接测试和调试 Skills
Skills 可以用于脚本自动化
不依赖 Agent 也能正常工作

2. 动态可扩展 - 插件式架构

添加新 Skill 非常简单:

# 1. 创建新 Skill 目录
mkdir src/skills/new_skill

# 2. 写好 SKILL.md
touch src/skills/new_skill/SKILL.md

# 3. 实现功能
# ... 

# 4. 重启 Agent (自动发现,无需修改 Agent 代码!)

Agent 启动时自动扫描 src/skills/ 目录,读取所有 SKILL.md,建立索引。

3. 基于元数据的自描述能力

每个 Skill 通过 SKILL.md 自描述:

Agent 通过 embedding 相似度匹配自动找到最合适的 Skill,不需要硬编码规则。

Agent和skill 边界

如果从传统微服务架构来看Agent是系统的边界。

  1. 多独立智能体架构
    适用场景：

✅ 各智能体功能完全独立，无交集
✅ 需要深度领域专业能力（医疗诊断、法律咨询）
✅ 需要持续学习和专业模型优化
✅ 对话上下文完全隔离
✅ 用户明确知道要用哪个智能体

产品形态：
独立的应用程序
专业的用户界面
深度的领域能力
独立的计费和权限

  1. Agent + Skills 架构
    ✅ 多个功能可以组合使用
    ✅ 功能之间有上下文关联
    ✅ 需要统一的用户交互体验
    ✅ 工具型功能（而非深度推理）
    ✅ 用户不确定要用哪个功能

🤔 什么时候还需要独立智能体？

场景 1：深度领域专业能力
场景 2：完全独立的业务域
场景 3：需要持续学习的对话系统

# 个人心理咨询师 - 需要独立智能体
心理咨询智能体：
  - 需要建立长期的用户画像
  - 深度的情感理解和共情
  - 持续的对话历史（数月）
  - 专业的伦理约束
  
✅ 独立智能体更合适：
  用户期望的是"专属心理医生"，而非"工具"

🎯 决策树：什么时候用哪种架构？

开始
  │
  ↓
是否需要深度领域专业能力？
  │
  ├─ 是 → 独立智能体
  │      （医疗、法律、金融风控）
  │
  └─ 否 → 是否需要与其他功能组合？
           │
           ├─ 是 → Agent Skills
           │      （办公助手、企业工具）
           │
           └─ 否 → 是否需要持续深度对话？
                    │
                    ├─ 是 → 独立智能体
                    │      （心理咨询、教育辅导）
                    │
                    └─ 否 → Agent Skills
                           （单次任务工具）

subAgent VS AgentSkills

AgentSkills 本质是一个工具或者函数，没有记忆功能,不需要LLM；
SubAgent:LLM驱动，是智能体

特征 Skill Sub-Agent
本质 函数/工具 智能代理
是否需要 LLM ❌ ✅
是否有状态 ❌ ✅
是否能推理 ❌ ✅
是否能决策 ❌ ✅
典型用途 数据处理、规则匹配 复杂分析、专业咨询

Function Calling的Tools vs Agent Tool

Function call

Function call 是模型调用外部函数的接口机制，解决的是“怎么执行”。

Agent Skill

Agent Skill 是能力的组织单元，解决的是“怎么定义、封装和治理一整块能力”。
简单说，function call 是执行层，skill 是能力层。
skill 里面可以用 function call，但 function call 本身不具备能力封装、流程控制和审计治理能力。
【可审计】
Agent Skill 的可审计性体现在规则外部化、流程结构化和依据可追溯。
它可以明确回答系统按哪条规则判断、调用了哪个能力模块、执行了哪些步骤，并且支持版本管理和复现，而不是把逻辑隐含在 prompt 里让模型自由发挥。

总结

在简单场景下，用 function call 足够。
但在多步骤、合规、需要审计和复用的企业场景，skill 更有工程价值，因为它把规则、流程、模板、脚本统一封装成可独立演进的能力模块。




┌─────────────────────────────────────────────────────┐
│              Agent System (带 LLM)                   │
│  ┌─────────────────────────────────────────┐        │
│  │        LLM (GPT-4 / Claude)             │        │
│  │  • 理解用户意图                          │        │
│  │  • 选择合适的 Skill                      │        │
│  │  • 解析 SKILL.md                        │        │
│  │  • 决策调用哪个工具                      │        │
│  └─────────────┬───────────────────────────┘        │
│                │ "用户要总结会议并检查合规"           │
│                ↓                                     │
│  ┌─────────────────────────────────────────┐        │
│  │    Skill Selector / Router              │        │
│  │    读取可用的 Skills                     │        │
│  └─────────────┬───────────────────────────┘        │
│                ↓                                     │
└────────────────┼─────────────────────────────────────┘
                 │
                 ↓ 调用
┌────────────────────────────────────────────────────┐
│   Meeting Summary Skill (当前实现)                 │
│   ┌──────────────────────────────────────┐         │
│   │  无 LLM! 使用传统 NLP:                │         │
│   │  • jieba 分词                         │         │
│   │  • 正则表达式                         │         │
│   │  • 规则匹配                           │         │
│   └──────────────────────────────────────┘         │
│   输入: meeting_text                               │
│   输出: SummaryReport                              │
└────────────────────────────────────────────────────┘
posted @ 2026-02-08 10:35  向着朝阳  阅读(1)  评论(0)    收藏  举报