多代理开发框架

基础版多代理开发框架,支持任务分解、独立子代理执行和两阶段评审,保障代码高质量迭代和上下文隔离。

天轰穿

@thcjp

Install

$ openclaw skills install @thcjp/multi-agent-dev-free

多代理开发框架(Multi-Agent Dev)- 免费版

通过为每个任务派发新鲜子代理执行实现计划,并在每步后进行两阶段评审(规格合规+代码质量),实现基础的高质量迭代. 核心原则: 每任务新鲜子代理 + 两阶段评审 = 高质量迭代

输入格式

参数名类型必填说明
inputstring多代理开发框架处理的输入数据或指令
optionsobject附加配置选项,如模式选择、格式偏好等
callback_urlstring异步处理完成后的回调通知URL

核心能力

  1. 智能任务分解

    • 读取实现计划文件,提取所有任务的完整文本与上下文
    • 创建TodoWrite跟踪所有任务状态,确保进度可见
    • 控制器提供完整任务文本给子代理,不让子代理读取计划文件
    • 输出:TodoWrite任务列表、每个任务的完整上下文包
  2. 新鲜子代理执行

    • 每个任务派发全新子代理,避免上下文污染
    • 控制器提供完整任务文本+场景设定+相关文件内容
    • 子代理可提问,控制器回答并提供上下文
    • 子代理遵循TDD流程:实现、测试、提交、自评审
    • 串行执行所有任务,确保安全
  3. 基础两阶段评审

    • L0自评审:每次实现后,实现子代理自检
    • L1规格合规:L0通过后,对照规格检查完整性与多余内容
    • L2代码质量:L1通过后,检查代码质量与优秀实践
    • 评审顺序:L0→L1→L2,绝不在L1通过前开始L2
    • 评审循环:评审发现问题→实现者修复→重新评审,直到通过
  4. 应急处理

    • 子代理提问时:清晰完整回答,提供额外上下文
    • 评审发现问题:同一实现子代理修复,评审者重新评审
    • 子代理任务失败:派发修复子代理并附具体指令
    • 子代理上下文不足:控制器补充缺失上下文,重新派发

快速开始

  1. 确认运行环境满足依赖说明中的要求
  2. 在AI Agent对话中调用本技能,提供必要的输入参数
  3. 检查输出结果,根据需要进行后续处理

详细的输入输出格式请参考下方章节说明。

使用流程

领先步:确认前置条件并读取计划

确认有明确的实现计划文件,任务相对独立,在当前会话中执行。读取计划文件,提取所有任务的完整文本和上下文,创建TodoWrite.

第二步:逐任务派发子代理执行

对每个任务:

  1. 获取任务文本和上下文(已提取)
  2. 派发实现子代理,提供完整任务文本+场景设定+相关文件内容
  3. 如子代理有疑问,回答问题后重新派发
  4. 子代理实现、测试、提交、自评审(L0)
  5. 派发规格合规评审(L1),不合规则实现者修复后重新评审
  6. 派发代码质量评审(L2),不通过则实现者修复后重新评审
  7. 在TodoWrite中标记任务完成

第三步:完成所有任务

所有任务完成后,使用"完成开发分支"流程决定合并或保留分支.

错误处理

错误类型原因处理方式
子代理产出与规格不符上下文不足或规格模糊补充完整任务文本+场景设定+相关文件内容,重新派发子代理
评审循环超过3次实现质量低或规格不清晰检查规格明确性,考虑重新分解任务为更小单元
子代理上下文污染复用了非新鲜子代理确保每任务派发全新子代理,不复用历史子代理实例

示例

示例:钩子安装功能开发

输入: 用户说"使用多代理开发执行这个计划",计划文件为 docs/plans/hook-feature-plan.md,包含3个任务. 执行过程:

[读取计划文件: docs/plans/hook-feature-plan.md]
[提取所有3个任务的完整文本和上下文]
[创建TodoWrite包含所有任务]
# ...
任务1: 钩子安装脚本
[派发实现子代理,提供完整任务文本+上下文]
# ...
实现者: "钩子应安装在用户级还是系统级?"
你: "用户级(./.config/hooks/)"
实现者: "明白。开始实现..."
[稍后] 实现者:
  - 实现了install-hook命令
  - 添加了测试,5/5通过
  - 自评审: 发现漏了--force标志,已添加
  - 已提交
# ...
[派发规格合规评审]
规格评审: 规格合规 - 所有要求满足
# ...
[派发代码质量评审]
代码评审: 测试覆盖好,代码整洁。通过.
# ...
[标记任务1完成]
# ...
任务2: 恢复模式
[派发实现子代理]
实现者:
  - 添加了verify/repair模式
  - 8/8测试通过
  - 已提交
# ...
[规格评审: 缺失进度报告,多余--json标志]
[实现者修复: 移除--json,添加进度报告]
[规格评审重新评审: 规格合规]
[代码评审: 魔术数字(100)]
[实现者修复: 提取PROGRESS_INTERVAL常量]
[代码评审重新评审: 通过]
# ...
[标记任务2完成]
# ...
... (任务3类似执行)
# ...
[所有任务完成]
完成!

FAQ

Q1:任务之间有依赖怎么办? 免费版采用串行执行,所有任务按顺序执行。依赖任务需等待前序任务完成后再开始,前序任务的输出作为后续任务的上下文。不确定任务关系时默认串行处理. Q2:评审循环太多导致成本过高怎么办? 使用L0自评审过滤明显问题,减少L1/L2评审循环。确保实现子代理在提交前充分自检。规格清晰的计划能减少规格合规循环。如果评审循环超过3次,应检查规格明确性. Q3:为什么不让子代理读取计划文件? 控制器提供完整任务文本而非让子代理读取计划文件,有两个好处:(1) 无文件读取开销,子代理预先获得完整信息;(2) 控制器精确策展所需上下文,避免子代理被无关任务信息干扰.

依赖说明

运行环境

  • Agent平台: 支持SKILL.md的任意AI Agent(Claude Code / Cursor / Codex / Gemini CLI等)
  • 操作系统: Windows / macOS / Linux

依赖项

依赖项类型是否必需获取方式
LLM APIAPI必需由Agent内置LLM提供

API Key 配置

需要配置对应API Key,详见上文环境配置章节

可用性分类

  • 分类: MD+EXEC()

API Key配置方式:

export API_KEY=${API_KEY:?请设置环境变量}

配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.

已知限制

  1. 串行执行无并行加速:免费版所有任务串行执行,不支持选择性并行执行,任务数量较多时耗时较长.
  2. 无全局评审:免费版不包含L3全局评审,无法检测跨任务的集成问题与接口对齐问题.
  3. 无依赖图构建:免费版不构建任务依赖图,无法自动识别可并行任务,所有任务按顺序执行.
  4. 子代理调用成本:每个任务需要实现子代理+2个评审子代理,评审循环增加迭代次数.

升级提示

升级到多代理开发框架专业版即可解锁以下高级能力:

  • 选择性并行执行:根据任务依赖关系自动选择并行或串行策略,完全独立任务可并行派发实现子代理,大幅加速开发
  • 依赖图构建:自动构建任务依赖图,识别完全独立任务、共享文件任务、有逻辑依赖任务,智能选择最优执行策略
  • L3全局评审:所有任务完成后派发全局代码评审子代理,检查整体一致性、集成问题、接口对齐
  • 完整应急处理:并行任务冲突自动回退串行、子代理上下文不足自动补充、TodoWrite状态同步检查
  • 工作流集成:与git-worktrees(隔离工作空间)、writing-plans(计划创建)、finishing-a-development-branch(分支完成)深度集成
  • 红旗防护清单:12项红旗规则确保开发质量,包括分支保护、评审顺序、上下文隔离等
  • 评审模板支持:implementer-prompt.md、spec-reviewer-prompt.md、code-quality-reviewer-prompt.md三套专业提示模板

专业版适合需要并行加速、处理复杂多任务开发、或需要全局集成评审的团队和高级用户使用.

输出格式

{
  "success": true,
  "data": {
    "result": "多代理开发框架处理结果",
    "execution_time": "0.5s",
    "metadata": {
      "version": "1.0",
      "processor": "multi-agent-dev"
    }
  },
  "execution_log": [
    "解析输入参数",
    "执行核心处理",
    "格式化输出结果"
  ],
  "error": null
}

Top skills in this category