霍格沃兹测试开发学社
方式一：Blueprint 的“调研→规划→执行”流水线我最早接触的是 @mathew-cf/opencode-blueprint 这个插件。它把整个工作流拆成五个专职 Agent：Planner（规划者）：主 Agent，负责理解需求、调研代码库、制定计划Investigator（调研员）：子 Agent，深入调研目录结构、代码模式、依赖关系Reviewer（审查者）：子 Agent，审查计划和代码，检查遗漏和范围蔓延Orchestrator（协调者）：主 Agent，执行计划、分配任务、验证结果Worker（执行者）：子 Agent，在隔离的 git worktree 中实现单个原子任务实际用起来是这样的：你告诉 Planner 想做什么，它会同时生成 3 到 5 个 Investigator，并行调研代码库的不同方面。调研完成后，Planner 整合信息，可能还会追问你几个澄清问题，最后产出一份结构化的实施计划。这份计划通过 /execute 命令交给 Orchestrator。Orchestrator 为每个任务创建独立的 git worktree，生成对应的 Worker 子 Agent 去执行。每个 Worker 只负责一个原子任务，互不干扰。这个流程的精髓在于 关注点分离：调研的人只管调研，执行的人只管执行，审查的人只管审查。每个 Agent 的上下文都很干净，不会因为混杂了太多职责而“精神分裂”。方式二：swarm-control 的自动分解如果你的需求没那么复杂，不想搞五六个 Agent 的流水线，swarm-control 提供了更轻量的方案。它的思路更直接：你给一个任务描述，它自动分析涉及哪些文件，然后把任务拆成 1 到 4 个基于文件的子任务，最多生成 4 个 Worker 并行执行。使用方式也非常简单：/swarm_spawn "为 src/api/ 下所有 API 端点增加错误处理"系统会自动识别 src/api/ 目录下的文件，按文件粒度拆解任务，每个 Worker 负责一个或几个文件。子任务之间有依赖关系时，会自动等待。如果多个 Worker 需要访问同一个文件，还有文件锁机制防止冲突。两种方式各有适用场景：Blueprint 适合大型、多阶段的复杂项目；swarm-control 适合中等规模、文件粒度清晰的单一任务。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
