复杂任务工程化执行框架 — Sprint Contract 协商、三代理角色切换、对抗性评估、任务分解与上下文管理。3+ 文件修改或多模块设计时自动触发,防止复杂任务中的上下文污染和自我评估偏差。
Auto-Agent — 长程任务工程化框架
功能概述
Auto-Agent — 长程任务工程化框架是一项面向实际任务的技能,主要用于Planner-Generator-Evaluator 三代理架构 + Sprint Contract 协商 + 对抗性评估;核心原则: 复杂任务的问题不是 AI 不够聪明,而是上下文污染和自我评估偏差;
核心要点
- 自动触发:;
- 预计修改 3 个以上文件;
- 设计新模块、新系统、新架构;
使用与执行
大型重构或重写;用户说"复杂功能""大任务""长程""重构"。它将相关步骤、工具调用和结果整理方式集中到统一流程中,帮助使用者更快完成目标并减少重复操作。从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;
结果检查与注意事项
若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。该技能适合用于一次性任务,也可以接入自动化工作流,与其他技能或上层代理配合完成更完整的业务链路;在组合使用时,应明确每一步的输入输出关系,并避免不同步骤之间出现参数冲突。
Auto-Agent — 长程任务工程化框架
Planner-Generator-Evaluator 三代理架构 + Sprint Contract 协商 + 对抗性评估。 核心原则:复杂任务的问题不是 AI 不够聪明,而是上下文污染和自我评估偏差。
何时使用
自动触发:
- 预计修改 3 个以上文件
- 设计新模块、新系统、新架构
- 大型重构或重写
- 用户说"复杂功能""大任务""长程""重构"
不触发:
- 单文件修复、小改动、查询类问题
- 简单的 bug 修复(1-2 文件)
- 代码审查、文档更新
快速开始
首次进入框架时,在项目根目录创建:
mkdir -p .auto-agent
需要 5 个核心文件:
项目/.auto-agent/ ├── tasks.json # 任务清单(单一事实来源) ├── progress.md # 进度日志 + 决策记录 ├── handoff.md # 会话间交接工件 ├── sprint-contract.md # 当前任务 Generator-Evaluator 契约 └── review-checklist.md # 项目特定的审查标准
可选辅助目录:
├── scripts/ # 自动化执行脚本(无人值守模式)
│ ├── run-task.ps1 # 执行单个任务
│ └── run-agent.ps1 # 持续执行多个任务
└── templates/ # 项目特定的代码模板
└── system-template.txt # 新模块的起手式骨架
核心机制
1. Sprint Contract(冲刺契约)
每个任务开始前,必须先协商契约并写入 sprint-contract.md。
契约必须包含:
- 目标 — 这个任务要完成什么(一句话)
- 验收标准 — 可验证的通过条件,必须是可测试的("功能正常"不是验收标准)
- 涉及文件 — 预计修改/新建的完整文件路径列表
- 完成定义 — 什么状态下可以标记
passes: true - 测试方式 — 如何验证:
编译检查/运行测试/手动验证/自动化测试
示例:
目标: 实现用户登录 API 调用及 Token 持久化 验收标准: 1. 输入用户名密码后,2 秒内 POST 请求发送到 /api/login 2. 成功后 token 加密存储到本地,UI 切换到主页 3. 失败后弹窗显示服务端返回的错误信息 4. 网络超时 10 秒后显示"网络异常,请重试" 涉及文件: - src/services/ApiClient.ts - src/systems/LoginSystem.ts - src/ui/LoginPanel.tsx 测试方式: 编译检查 + 手动验证登录流程 + 模拟网络超时
2. 三角色分工
| 角色 | 对应阶段 | 职责 | 约束 |
|---|---|---|---|
| Planner | Plan + Explore | 拆解任务、分析架构、识别复用 | 只做规划,不写实现代码 |
| Generator | Implement + Test | 编码实现、自评估、修复 | 不能评估自己的代码 |
| Evaluator | Review | 独立验收、多维度评分 | 禁止看 Generator 实现思路 |
为什么必须分离:
- 同一个模型写代码 + 审代码 = 自我评估偏差(对自己的错误视而不见)
- Evaluator 只读代码文件 + Sprint Contract,不看
progress.md中的实现说明 - Evaluator 必须刻意挑剔——原文:"tuning a standalone evaluator to be skeptical is far more tractable than making a generator critical of its own work"
3. 任务分解规则
- 每个原子任务 1-3 个文件
- 依赖关系在
tasks.json的dependencies字段记录 - 每个任务必填:
acceptance_criteria、steps、critical_files estimated_complexity:low/medium/high,决定 Evaluator 严格程度
4. 评估评分矩阵
| 维度 | Hard Threshold | 权重参考 |
|---|---|---|
| 功能正确性 | ≥ 4 / 5 | 40% |
| 架构合规 | ≥ 3 / 5 | 25% |
| 代码质量 | ≥ 3 / 5 | 20% |
| 复用性 | ≥ 3 / 5 | 15% |
任一维度低于 hard threshold → 退回 Generator 修复 → 进入下一轮迭代。
典型迭代 2-4 轮,超过 3 轮仍未通过 → 升级为 blocked。
5. 复杂度分级策略
| 级别 | Evaluator 模式 | 典型场景 |
|---|---|---|
| low | 简化:编译检查 + 功能点验证 | 单文件修复、配置修改 |
| medium | 完整:四维度评分 + 代码审查 | 新功能、跨 2-3 文件 |
| high | 完整 + 运行测试 + 边界探索 | 新系统、大型重构 |
五阶段开发流程
Plan → Explore → Implement → Test → Review ↑ │ └────────── 未通过,退回重来 ─────────┘
Phase 1: Plan
角色:Planner
- 分析需求 → 拆解为原子任务 → 写入
tasks.json - 起草 Sprint Contract → 写入
sprint-contract.md - 识别任务依赖 → 填入
dependencies - 更新
progress.md记录决策
Phase 2: Explore
角色:Planner
- 读取现有相关代码,理解架构模式
- 识别可复用的模块、接口、工具函数
- 确认不重复造轮子
- 记录发现到
progress.md
Phase 3: Implement
角色:Generator
- 按
tasks.json的steps顺序实现 - 遵循项目现有架构模式,优先复用
- 完成子任务后自评估 — 对照契约检查
- 更新
progress.md - 每个任务单独 git commit
Phase 4: Test
角色:Generator
- 编译检查(必须通过)
- 功能路径测试(主流程 + 边界情况)
- 修复自评估发现的问题
Phase 5: Review
角色:Evaluator
Evaluator 必须首先声明:
"切换为 Evaluator 角色。以下是仅基于代码文件和 Sprint Contract 的独立评估,未受 Generator 实现思路影响。"
- 对照 Sprint Contract 逐条验收
- 四维度评分(功能正确性 / 架构合规 / 代码质量 / 复用性)
- 任一维度低于 hard threshold → 记录详细原因 + 修复建议 → 退回
- 全部通过 →
tasks.json中passes: true,status: completed
上下文管理
新会话恢复协议
按序读取恢复上下文:
tasks.json→ 当前所有任务状态progress.md→ 最新进度和决策记录handoff.md(如存在)→ 上次会话交接状态- 当前任务涉及的代码文件
阻塞处理
连续 3 轮迭代未通过 → status: blocked:
progress.md中记录完整阻塞原因- 输出以下格式的阻塞信息并停止:
🚫 任务阻塞 - 需要人工介入 当前任务: TASK-001 - 任务标题 阻塞原因: [具体原因] 已完成: [已完成内容] 解除后: [具体步骤]
- 禁止谎报通过、禁止将
passes设为 true
tasks.json 格式
{
"id": "TASK-001",
"title": "简短标题",
"description": "详细描述",
"status": "planned | in_progress | completed | blocked",
"phase": "Plan | Explore | Implement | Test | Review",
"passes": false,
"acceptance_criteria": ["可验证标准1", "可验证标准2"],
"steps": ["具体步骤1", "具体步骤2"],
"dependencies": ["TASK-000"],
"critical_files": ["path/to/file1.cs", "path/to/file2.cs"],
"estimated_complexity": "low | medium | high",
"iteration": 0,
"created_at": "YYYY-MM-DD",
"updated_at": "YYYY-MM-DD"
}
安全规则
| 规则 | 说明 |
|---|---|
| 🔴 不无人值守 | 至少 Level 1 有人工验收 |
| 🔴 单独 commit | 每个任务独立 git commit,不合并 |
| 🔴 不放水 | Evaluator 未达标必须退回,不走捷径 |
| 🔴 不谎报 | 阻塞时不上报通过 |
| 🟡 自动化级别 | 默认 Level 1(人工验收),逐步升级 |
自动化级别:
- Level 1(推荐):人工选择任务,AI 执行,人工验收
- Level 2:AI 自动选任务,执行前人工确认
- Level 3:完全自动 + 定期人工检查(需
--dangerously-skip-permissions) - Level 4:完全无人值守(不推荐,仅成熟项目可用)
安装到你的项目
# 通过 SkillHub(推荐,国内加速) # 在 Claude Code 中说:"安装 auto-agent 技能" # 通过 npx skills(国际) npx skills add/auto-agent -g -y # 手动安装 mkdir -p ~/.claude/skills/auto-agent # 复制 SKILL.md 到上述目录
项目专属配置(代码模板、审查清单)放在项目 .auto-agent/ 下。
热门AI工具
相关专题
全面评测 Manus AI 与 ChatGPT、Claude、OpenAI Operator 等 AI Agent 产品,分析自动化能力、工作流与实际生产力差异。
233
2026.05.29
本专题面向已经具备基础使用经验的用户,深入解析 Claude 在复杂场景中的高阶应用方式,重点解决“如何让 AI 真正参与到实际工作流程中”的问题。让 Claude 成为日常工作中可持续复用的效率引擎,在内容创作、开发实践与信息处理等多个领域实现显著提效。
319
2026.03.27
本专题聚焦 Claude 的提示词(Prompt)设计与优化方法,围绕“如何让 AI 更准确理解需求并输出高质量结果”这一核心问题展开。内容从基础结构入手,逐步深入到复杂场景下的提示词构建策略,帮助用户建立清晰、可复用的提示词体系。
314
2026.03.27
Vite项目打包部署专题汇集生产构建、产物预览、输出目录、资源路径、Nginx与GitHub Pages部署及常见白屏和路由404问题的已审核文章,帮助读者完成上线流程。
0
2026.10.28
Vite搭配Vue.js专题汇集创建Vue 3项目、配置开发环境、路径别名、Vue插件、代理、多环境构建与调试的已审核文章,帮助读者完成从初始化到日常开发的配置。
0
2026.10.28
Vite项目目录专题汇集入口文件、src源码、public静态资源、路径别名、项目根目录和构建输出目录相关的已审核文章,帮助读者理解各文件夹的用途与引用方式。
0
2026.10.28
本专题介绍Gradle插件开发的基本流程,涵盖插件类编写、自定义任务注册、扩展参数设计和插件应用方法,帮助你理解插件如何组织构建逻辑,减少多个项目之间的重复配置。
0
2026.10.22
本专题介绍Gradle Wrapper的基本作用,涵盖文件组成、生成方法、版本配置和任务调用,帮助你理解项目如何使用指定的Gradle版本,减少不同开发环境带来的构建差异。
0
2026.10.22
热门下载
相关下载
精品课程
最新文章
