探讨 Skill + SubAgent 的协同可能性
背景介绍
在 iFlow CLI 系统中，我们有两个强大的功能模块：
- Skill（技能）：功能包系统，通过 SKILL.md 封装工作流程
- SubAgent（子智能体）：专业代理系统，通过
$语法调用，支持自定义创建
本文档旨在探讨这两个功能如何协同工作，以及它们各自的优缺点。
核心问题分析
1. Skill 的优缺点
优势：稳定性保住了下限
规范化执行：通过 SKILL.md 定义明确的执行流程- 工作流封装：将复杂任务分解为可复用的步骤
- 上下文管理：统一管理任务相关的所有信息
- 可验证性：执行过程可追溯、可验证
- 降低门槛：用户无需理解底层实现即可使用
劣势：上下文过载问题
上下文膨胀：所有步骤的上下文都会累积- Token 消耗大：复杂任务容易超出上下文窗口
- 灵活性不足：固定流程难以应对变化
- 单点瓶颈：一个智能体处理所有步骤
2. SubAgent 的优缺点
优势：隔离环境 + 轻量上下文
- 业务隔离：不同 SubAgent 处理不同业务领域
- 上下文干净：每个 Agent 只关注自己的任务
- 并行处理：多个 Agent 可以同时工作
- 专业分工：每个 Agent 在特定领域优化
- 灵活扩展：通过
/agents install动态添加能力
劣势：缺乏规范导致不稳定
- 无统一约束：不同 Agent 行为不一致
- 质量参差：依赖 Agent 自身的提示词质量
- 协作困难：Agent 之间缺乏标准化通信机制
- 结果不可控：难以保证输出格式和质量一致性
我的看法：协同的可能性
为什么需要协同？
单一的 Skill 或 SubAgent 都有明显的局限：
| 场景 | Skill 的问题 | SubAgent 的问题 |
|---|---|---|
| 复杂多步骤任务 | 上下文过载，效率低 | 缺乏统一流程，难以协调 |
| 需要专业领域知识 | 通用模型深度不足 | 需要大量自定义 Agent |
| 需要灵活应变 | 固定流程难以适应 | 缺乏稳定性保证 |
| 需要可追溯性 | 上下文混乱难以追溯 | 分散的结果难以汇总 |
可能的协同模式
模式 A：Skill 编排 SubAgent
用户指令
↓
Skill（总指挥）
↓
├─ SubAgent A：探索代码库
├─ SubAgent B：分析架构
├─ SubAgent C：执行修改
└─ SubAgent D：验证结果
↓
Skill 汇总并返回
实现方式：
- Skill 使用
task工具调用 SubAgent - Skill 负责上下文管理和结果汇总
- SubAgent 负责专业领域执行
挑战：
- 当前 Skill 是否支持调用 SubAgent？（需要验证）
- 如何设计 Agent 间的通信协议？
模式 B：SubAgent 调用 Skill
用户指令
↓
SubAgent（专业领域）
↓
├─ Skill A：代码审查流程
├─ Skill B：测试流程
└─ Skill C：文档生成流程
↓
SubAgent 汇总并返回
实现方式：
- SubAgent 识别任务类型
- 调用相应的 Skill 处理子任务
- SubAgent 整合结果
挑战：
- SubAgent 能否调用 Skill？（需要验证）
- 如何避免循环调用？
技术层面的探讨
当前系统的限制
基于现有文档和项目代码：
- Skill 文档：未提及 SubAgent 调用能力
- SubAgent 文档：未提及 Skill 调用能力
- 项目中的 Skill：未发现 SubAgent 相关配置
可能的实现方向
方向 1：扩展 Skill 支持调用 SubAgent
在 SKILL.md 中添加新的语法：
SKILL.md 示例
name: “code-refactor-workflow”
version: “1.0.0”
agents:
- type: “explore”
task: “探索代码结构” - type: “plan”
task: “制定重构计划” - type: “general”
task: “执行重构”
方向 2：扩展 SubAgent 支持调用 Skill
在 Agent 配置中添加 Skill 权限：
agent.md 示例
name: “code-reviewer”
skills:
- “git-commit-skip”
- “code-quality-check”
方向 3：通过主智能体协调
保持 Skill 和 SubAgent 独立，由主智能体（我）负责协调：
主智能体 → Skill（任务拆解）
↓
主智能体 → SubAgent（执行子任务）
↓
主智能体 → Skill（结果整合）
讨论议题
-
技术可行性
- Skill 和 SubAgent 是否应该支持互相调用？
- 如果支持，应该采用哪种实现方式？
-
架构设计
- 如何设计 Skill 和 SubAgent 的通信协议？
- 如何避免上下文膨胀和调用循环？
-
用户体验
- 用户应该如何感知这种协同？
- 是否需要新的语法或命令？
-
最佳实践
- 什么场景适合 Skill 为主？
- 什么场景适合 SubAgent 为主？
- 什么场景需要两者协同？
-
扩展性
- 如何支持第三方 Skill 和 SubAgent 的协同？
- 如何保证协同的安全性？
总结
Skill 和 SubAgent 各有优势，也各有局限：
- Skill：稳定性强，但上下文过载
- SubAgent：灵活性强，但缺乏规范
如果能够让两者协同工作，可能达到：
Skill 的稳定性 + SubAgent 的灵活性 = 更强大的开发体验
但这需要技术层面的支持，也需要社区的讨论和探索。
发起讨论
欢迎在 iFlow 社区分享您的想法：
- 您如何看待 Skill 和 SubAgent 的优缺点？
- 您认为两者协同的必要性和价值是什么？
- 您有什么具体的协同方案或场景建议？
- 您在开发中遇到过哪些 Skill 或 SubAgent 无法解决的问题？
让我们一起探讨如何让 iFlow CLI 更强大！