Skill 还是 SubAgent？解锁 AI Agent 架构的终极困惑

RunningData
1 阅读13分钟

最近在研究 Harness Agent、LLM Wiki 等框架时，发现了一个深层困惑：Skill 看起来这么强大（可嵌套、有脚本能力、高可复用性），那 SubAgent 存在的意义是什么？什么时候才该用 SubAgent，什么时候该用 Skill？

这篇文章通过分析 8 个主流 AI Agent 框架的实现、对标业界最新的架构设计，从 问题结构、自主决策能力、复用性需求 等 5 个核心维度出发，给出了清晰的决策矩阵。

一、问题的根源：为何会陷入困惑

我的困惑来自一个真实的现象：Skill 正在变得越来越强大。

1.1 Skill 的进化轨迹

从 2023-2026 年 AI Agent 框架的演变来看：

时期Skill 的定位特点典型框架
2023年早期简单工具封装无状态、单一职责LangChain Tool
2023年中期任务流程编排可组合、流程化Dify Node、n8n
2024年能力单元 + 脚本编排可嵌套、高并发、强大的组织能力LangGraph Subgraph、MetaGPT Action
2026年通用计算单元提供接近 SubAgent 的灵活性，但保持高可靠性你的系统设计、Harness Agent

关键转折点：函数调用（Function Calling）技术的成熟。当 Tool 的成功率从 50% 突破到 95%+，它就从"辅助工具"演变成了"一等公民"。

1.2 业界的困惑不只是你的

看看这些框架的进化过程：

  • LangChain：2023 年推出 Agents（SubAgent 模式）→ 2024 年被 Tool and ReAct 主导 → 2025 年推出 Deep Agents（重新引入递归 SubAgent）
  • MetaGPT：一开始采用 Role-based SubAgent（PM/Architect/Engineer/QA 分工）→ 后来发现 Action（Skill）的可靠性更高
  • Dify：同时支持 Workflow（Skill 组合）和 Agent Mode（自主决策模式）

这说明什么？ 没有一个框架认为 Skill 或 SubAgent 哪个绝对优越，它们的选择都是情景驱动的。

二、核心对比：从 5 个维度理解差异

2.1 维度 1：问题结构的确定性 ⭐⭐⭐⭐⭐

定义：你进入系统时，是否已经明确知道"要做什么"和"怎么做"。

Skill 的世界观

问题 → 分解为已知步骤 → 按流程执行 → 结果

示例：ETL 流程
  提取(Extract) 
    ⬇️
  转换(Transform)
    ⬇️
  加载(Load)

适用场景：

  • ✅ 工作流程在设计时就完全确定（数据管道、报表生成、批量处理）
  • ✅ 流程图是直线或简单分支（if-else）
  • ✅ 每一步做什么、如何做都有明确的算法或规则

SubAgent 的世界观

问题 → 动态分解 → 根据结果调整策略 → 再次分解 → 结果

示例：复杂的软件开发任务
  理解需求 → 分析反馈 → 决定是否需要系统设计 
    → 基于架构决定实施策略 → 根据实施效果调整

适用场景：

  • ✅ 流程需要根据运行时的结果动态调整（多步推理、决策树）
  • ✅ 中间结果会影响后续的决策（如 AutoGPT 的探索式搜索）
  • ✅ "做什么"需要在运行时动态决定

2.2 维度 2：自主决策能力 ⭐⭐⭐⭐

定义：系统是否需要根据上下文进行自主决策（而不是按预设规则判断）。

Skill 的设计

  • 决策是预定义的：所有分支在设计时就已列举
  • 选择是确定性的：基于明确的条件和规则
  • 优势：高可靠性、易于测试、容易追踪
  • 劣势：无法处理"设计时未预见的情况"

真实案例 - Dify 的 Workflow 模式：

IF 用户输入长度 > 100 字
  THEN 调用总结模型
  ELSE 直接返回

决策标准是明确的 → 用 Skill 就够了

SubAgent 的设计

  • 决策是自主的：Agent 根据当前状态和目标自己决定下一步
  • 选择是灵活的：可以处理未预见的情况
  • 优势：面对复杂、不确定的环境时灵活变通
  • 劣势：难以预测、容易出错、难以追踪推理过程

真实案例 - MetaGPT 的 Role 设计：

PM(产品经理) 的工作是：
  1. 理解用户需求
  2. 分析技术可行性反馈
  3. 根据反馈给出产品建议

PM 的具体行动（写什么文档、问哪些问题）是 Agent 自主决定的

2.3 维度 3：复用性期望 ⭐⭐⭐⭐

定义：这个能力是否需要跨项目、跨系统、跨场景复用。

Skill 的复用哲学

  • 设计目标：原子化、通用化、最小化依赖
  • 典型例子：
    • LangChain 的 Tool 库：同一个"Google Search"工具可以被数百个应用调用
    • 你系统中的 Extractor Skill：清洗数据的逻辑对任何研究主题都适用
    • n8n 的整个 Node 库：每个 Node 都是独立复用的单元

复用性的代价：必须做出设计妥协，不能过度优化某一个特定场景

SubAgent 的复用哲学

  • 设计目标：特定场景优化、协作关系锁定
  • 典型例子：
    • MetaGPT 的 PM Agent：只在"软件开发团队"这个场景中高效协作
    • Harness Agent：在自己的 workflow 中表现最佳，但跨系统迁移需要大量改造
    • AutoGPT 的 Agent 设计：为了解决"自主编程"这个特定问题优化过

跨系统迁移的难度：Medium-High（需要理解 SubAgent 的"个性"和环境假设）

2.4 维度 4：状态管理复杂度 ⭐⭐⭐

定义：需要维持多少状态、维持多久。

Skill 的状态策略

  • 单次请求 → 无状态处理 ✅
  • 跨请求 → 通过外部存储（数据库、消息队列）
  • 设计原则：每个 Skill 执行完就释放资源
# Skill 范例：无状态抽取
def extract_data(raw_json):
    # 无内部状态
    result = json.parse(raw_json)
    return clean_result(result)

# 如果需要跨请求状态，存到外部
db.save_extracted_data(result)

优势：高并发友好、易于水平扩展、容器部署简单

SubAgent 的状态策略

  • 长期维持：Agent 需要记住过去的决策、推理过程
  • 设计原则：Agent 是"有记忆的"，每个实例都是独立的
# SubAgent 范例：有状态探索
class ResearchAgent:
    def __init__(self):
        self.explored = set()  # 已探索的路径
        self.findings = []     # 发现的信息
    
    def plan_next_search(self, progress):
        # 基于历史决策动态规划下一步
        next_keyword = self.choose_unexplored_path(progress)
        return next_keyword

代价：难以并发、需要精细的会话管理、分布式部署复杂

2.5 维度 5：部署和扩展能力 ⭐⭐⭐

Skill 的部署模型

单个 Skill ≈ 微服务

特点：

  • 轻量级（可以容器化）
  • 无状态（可以快速扩展）
  • 可独立部署、更新
  • 成本低

典型部署：

  • ✅ Kubernetes + 水平自动扩展
  • ✅ Serverless (AWS Lambda)
  • ✅ 边缘计算（部署到端设备）

SubAgent 的部署模型

SubAgent ≈ 完整应用

特点：

  • 需要持久化存储
  • 可能需要人工干预（Human-in-the-loop）
  • 分布式协调复杂
  • 成本高

典型部署：

  • ✅ 专用服务器或 VM
  • ✅ 需要会话管理中间件
  • ⚠️ 分布式部署需要额外的框架支持（如 LangGraph 的 persistence）

三、决策矩阵：什么时候用 Skill，什么时候用 SubAgent

3.1 快速判断流程（3 道题）

问题1️⃣：你的流程确定性如何？
├─ 是（设计时完全确定）
│  └─ 问题2️⃣：需要跨项目复用？
│     ├─ 是 → ✅ 用 Skill（构建可复用框架）
│     └─ 否 → 问题3️⃣
│
└─ 否（需要动态调整）
   └─ 问题3️⃣：需要多角色/多Agent 协作？
      ├─ 是 → ✅ 用 SubAgent（团队协作）
      └─ 否 → ✅ 用 Agent + Skills 混合模式

3.2 场景对照表

场景推荐方案理由例子
数据 ETLSkill流程确定、高并发、跨项目复用你的 Extractor Skill
定向问题回答Skill + LLM流程固定、可预测搜索 Query 改写、内容总结
开放式探索研究Skill 编排流程是流程，但中间步骤严格质控你的 Agent-Pipeline
代码生成SubAgent需要多步推理、实时调整策略MetaGPT 的 Engineer Agent
团队协作Multi-SubAgent不同角色、不同决策逻辑MetaGPT 的 PM/Architect/QA
自主掌控客户端SubAgent长期交互、维持对话状态ChatBot 场景
批量任务处理Skill 组合预定义流程、高吞吐量批量文档处理、报表生成
创意生成SubAgent需要多次迭代、反复思考广告文案、创意设计

四、架构对标：业界框架是如何选择的

4.1 LangChain 的进化：Tool → Agent → Deep Agent

2023 年：Agent 中心

Agent(职责：决策)
  ├─ 调用 Tool A
  ├─ 调用 Tool B
  └─ 基于结果再次决策
  • ❌ 问题：Tool 的成功率低（50-70%），单 Agent 处理复杂问题困难

2024 年：Tool 中心

Tool(职责：执行)
  ├─ Google Search Tool
  ├─ Code Executor Tool
  └─ (多个 Tool 的标准库)
Agent(职责：简化成"选择哪个 Tool")
  • ✅ 优势：Tool 库复用性强、成功率高（95%+）
  • ⚠️ 问题：Tool 堆砌无法处理 recursive reasoning

2025 年：引入 Deep Agents（重新支持 SubAgent）

Deep Agent = Agent + SubAgents + FileSystem
  用于处理需要多层推理的任务
  • 💡 洞察：Skill（Tool）适合单一职责，SubAgent 适合递归问题

4.2 MetaGPT 的坚持：Role-based Team（多 SubAgent）

MetaGPT 的设计逻辑：
  Software Company = Team of Roles

PM(需求分析) → Architect(架构设计) → Engineer(代码实现) → QA(测试)
  
每个 Role 是一个 SubAgent，有独立的：
  - 思考过程（Agent 的自主决策）
  - 行动方式（Action/Skill）
  - 协作协议（接收前一个 Agent 的输出）

关键数据：

  • 单 Agent 生成代码的成功率：~50%
  • Team of Agents 的成功率：~85%+

启示：当需要多角色分工时，SubAgent 是必要的。不能简单地用 Skill 组合来替代。

4.3 Dify 的平衡：Workflow 和 Agent Mode 并存

固定流程 ──(用 Workflow/Skill)──→ 高可靠、易维护
开放问题 ──(用 Agent Mode)────→ 灵活、自主

用户可以在两种模式间切换

现实意义：

  • 80% 的应用场景用 Skill 就够了
  • 20% 的复杂场景需要 SubAgent

五、系统设计启示

我的当前系统正是"Skill 优先"的典范： image.png

5.1 为什么选择 Skill 而不是 SubAgent

我的系统：Agent-Pipeline + 7 个 Skill

为什么没有 SubAgent？

  1. 流程确定性高：5 个步骤在设计时就固定了
  2. 每个 Skill 单一职责：Crawler、Extractor、Analyst 各司其职
  3. 高复用性需求：任何研究主题都可以复用这套流程
  4. 质量门槛明确：每一步都有量化的质量标准
  5. 并发友好：多个研究可以同时进行（因为 Skill 无状态）

5.2 Skill 架构的优势在我项目的体现

设计点你的系统实现收益
松耦合通过 JSON/Markdown 传递数据各 Skill 独立演化、更新
单一职责Crawler 只采集、Extractor 只清洗易于理解、易于测试
文件隔离每个任务创建独立文件夹支持并行处理、易于追踪
质量门槛每步都有明确的通过标准防止垃圾数据传递
顺序编排Agent 严格控制 5 个步骤的顺序防止流程跳跃、保证逻辑完整

六、关键决策因素速查表

6.1 选择 Skill 的信号

✅ 如果以下大多数为真，选择 Skill：

  • 流程在设计时 ≥80% 确定
  • 需要高并发处理
  • 期望复用到其他项目
  • 每一步的输入输出是明确的
  • 不需要维持长期对话状态
  • 成本敏感（需要低延迟、低资源占用）

6.2 选择 SubAgent 的信号

✅ 如果以下大多数为真，选择 SubAgent：

  • 流程需要动态调整（< 50% 在设计时确定）
  • 涉及多角色分工和复杂协作
  • 需要多步推理和策略调整
  • 单个 Agent 无法高效完成
  • 需要长期维持对话状态和历史记忆
  • 容许更高的延迟和资源占用

6.3 混合方案的信号

✅ 如果需要以下特性，考虑 Skill + SubAgent 混合：

  • 核心流程确定（用 Skill），但某些环节需要自主决策（用 SubAgent）
  • 例如：爬虫 Skill + research SubAgent + 撰写 Skill
  • 例如：数据清洗 Skill + 异常处理 SubAgent + 报表生成 Skill

七、从 Harness Agent 学到的启示

Harness Agent 的核心理念是："以 Skill 为中心，通过 Skill 的递归嵌套和脚本编排，模拟 SubAgent 的灵活性"

这启发了一个新的思路：

传统：SubAgent ≡ 递归调用 Agent
新思路：Skill ≡ 递归调用 Skill + 脚本编排

优势：
  - 保持 Skill 的高复用性和无状态特性
  - 获得接近 SubAgent 的编排灵活性
  - 避免 SubAgent 的状态管理复杂性

这就是为什么我会上瘾：Skill 在演变，正在变成一个更强大的原语。

八、实用指南：如何在你的系统中应用这些洞察

8.1 如果你想扩展现有系统

方向1： 添加新的 Skill

  • 当流程固定、需要复用、输入输出明确时

例如：翻译 Skill、可视化 Skill、多语言支持

方向2：引入 SubAgent（谨慎）

  • 当某个环节需要自主决策时
  • 但要定义清晰的接口和输入输出

例如：异常处理 SubAgent（当数据质量很差时）

方向3：嵌套 Skill（推荐）

  • 让复杂的 Skill 调用简单的 Skill
  • 保持无状态、高复用性

例如：高级 Analyst Skill 调用基础的对比 Skill

8.2 对于新项目的建议

第一步：用 Skill 优先的架构开始

  • 映射出所有流程步骤
  • 每个步骤设计成一个 Skill
  • 定义清晰的输入输出

第二步：等到 80% 场景都能用 Skill 处理时

  • 考虑是否需要 SubAgent
  • 通常答案是"不需要"或"只需要很少"

第三步：如果确实需要 SubAgent

  • 只在决策密集的环节使用
  • 给每个 SubAgent 明确的"职责范围"
  • 设计清晰的 SubAgent 间协议

九、总结：Skill 和 SubAgent 的本质区别

最终的对比

维度SkillSubAgent
适用流程确定性 + 流程化不确定性 + 探索性
核心能力执行（执行器）决策（决策者）
状态管理无状态有状态
扩展性⭐⭐⭐⭐⭐⭐⭐
复用性⭐⭐⭐⭐⭐⭐⭐
灵活性⭐⭐⭐⭐⭐⭐⭐⭐
可靠性⭐⭐⭐⭐⭐⭐⭐⭐
学习成本低高
部署复杂度简单（微服务）复杂（分布式）

核心结论

  • 🎯 Skill = 确定性流程中的高可靠、高复用执行单元
  • 🎯 SubAgent = 不确定性环境中的自主决策单元

它们不是竞争关系，而是互补关系。

选择哪个，取决于你的问题是"已知(Skill)"还是"未知(SubAgent)"。

在当下的 AI 时代：

  • 2024 年的洞察：Skill（Tool）的崛起;
  • 2025 年的认识：SubAgent 不会消失，因为有些问题确实需要递归决策

未来的趋势：混合架构 = Skill 的主流 + 必要时的 SubAgent

参考资源

开源框架官方文档

学术论文

核心设计理念

  • Function Calling 的进展：成功率从 50% → 95%（2023-2024）
  • Agent vs Tool 的权衡：从 2024 年中开始重新优化

讨论：你的想法是什么？

在评论区分享：

  • 你在实际项目中遇到过 Skill vs SubAgent 的选择困惑吗？
  • 你的决策最后是怎么做的？
  • 有没有遇到过"用 Skill 做不了，一定要用 SubAgent"的场景？

期待你的反馈！🚀

avatar
文章
阅读
粉丝