单 Agent 任务委派 — 把重复劳动交给 AI
适用角色与上手难度
🎯 学习产出: 掌握 agent() 基础调用,能独立将重复任务拆分成子 Agent 委派
🚀 AI 能力提升: 单 Agent、任务委派
场景概述
预计阅读时间: 18 分钟假设你在维护一个中型 Express API 项目(TypeScript),产品迭代到 2.0,技术债清单上有三件事一直没空做:
- 给所有路由加请求日志中间件 — 现在出问题时只能靠直觉排查,缺乏可追溯的请求日志
- 重构错误处理 — 每个路由各自
try-catch,错误信息格式不统一,HTTP 状态码满天飞 - 给 User 模块写单元测试 — 覆盖率不到 30%,每次改 User 逻辑都提心吊胆
三个任务彼此独立,按传统方式,你会排个优先级——今天写日志中间件、明天重构错误处理、后天补测试——至少花掉三个半天。
但如果把每个任务委派给一个 Claude Code Agent,让它们在各自的上下文中独立工作呢?你只需要写好委派指令,然后去喝杯咖啡,回来逐个 review 产出即可。这篇文章就带你走一遍这个流程——三个任务,三个 Agent,一个下午搞定。
为什么用 Agent 委派
在聊具体操作之前,先厘清 Agent 委派相比"在同一个对话里挨个让 CC 做"的核心区别:
核心价值就三点:上下文隔离(每个 Agent 只看自己那摊事)、并行推进(省掉串行等待时间)、输出边界清晰(Agent 的交付物不会和其他对话混淆)。
Agent 不是比你聪明的搭档,它只是比你快 10 倍的工具。关键在于你把任务拆得多清楚——输入是什么、期望产出是什么、不要做什么,越具体效果越好。
前置准备
项目已经运行起来,npm run dev 能正常启动。接下来就是分三步委派。
完整交互过程
Step 1:委派"给所有路由添加请求日志中间件"
先让 Agent 分析当前项目结构,再输出完整的 logger middleware。
用户输入:
在对话中直接描述任务,CC 会自动使用 Agent 工具来执行:
CC 输出(Agent 完成后的交付内容):
修改文件:src/index.ts
在 const app = express() 之后、所有路由之前插入:
设计决策
- 挂载时机:放在所有路由之前、body parser 之后,确保请求进来第一时间记录,又不影响 body 解析
- 为什么用
res.on('finish')而非覆写res.end:finish事件是 Node.js http 模块的标准事件, 兼容性好,不侵入底层实现。覆写res.end可能和 compression 等其他中间件冲突 - 为什么用
console.log而非 winston/pino:按你的要求保持简单,后续如果接入日志系统, 只需替换console.log一行即可,中间件结构不变
CC 输出:
新建 src/middleware/errorHandler.ts
在 src/index.ts 中注册(放在所有路由之后)
旧写法 vs 新写法(以 userController.ts 为例)
旧写法:
新写法:
新写法中 controller 不再直接 res.status().json() 错误响应,而是 next(e) 交给全局 error handler。
这使得错误格式 100% 一致,且 controller 代码更简洁。
CC 输出:
Mock 策略说明
jest.mock('../src/models/User')在 import 之前执行,jest 会自动提升,确保所有测试用 mock 版本- 每个 test case 前
jest.clearAllMocks()重置 mock 状态,避免用例间互相污染 - supertest 直接对 Express app 实例发请求,不需要启动真正的 HTTP server
Agent 2 按要求"只输出设计方案和代码,不要实际修改文件",所以它只给了设计。实际迁移所有 controller 时,你还需要自己改一遍——或者再起一个 Agent 专门做迁移。
接下来把三个 Agent 的产出手动应用到代码库(或用 CC 在当前对话里帮你写入),然后验证:
全部通过。三个任务,三个 Agent 并行推进,你只需要 review 和合并——这就是 Agent 委派的节奏。
要点总结
- Agent 任务要明确输入/输出边界。每个委派指令都包含"先读什么、做什么文件、产出什么、不要做什么",边界越清晰,Agent 交付质量越高。
- 一个 Agent 只做一个关注点。别把 logger + errorHandler + tests 打包成一个任务扔给 Agent——拆开之后每个 Agent 的上下文更干净,产出也更聚焦。
- Agent 不比你聪明,但比你快 10 倍。它不会替你把所有 controller 改好(除非你明确要求),但它能在几分钟内产出你手写要一小时的东西——剩余工作量是你的 review 和微调。
- 委派完去喝杯咖啡,回来 review。三个 Agent 并行跑的时间大概是你串行做的 1/3,多出来的时间不用盯着屏幕——等通知即可。
- Agent 交付的是"初稿",不是"终稿"。你仍然需要审查、合并、验证(
npm test),但这个流程比从零手写快得多。
变体与延伸
变体:同一个任务,三种思路并行探索
有时候你不确定"哪种方案最好"。与其自己纠结,不如让三个 Agent 各自用一种策略实现同一个需求,然后对比选出最优。
以"错误处理重构"为例:
三个 Agent 同时跑,产出三套方案后放在一张表里对比:
这种"并行探索、对比优选"的模式特别适合架构决策或技术选型类任务——AI 替你写 POA(Proof of Architecture),你只做决策。
延伸:Agent 链 — 当 Agent 的产出是下一个 Agent 的输入
在某些场景下,Agent 之间可以串联。比如:
- Agent 1:分析现有错误处理模式,输出一份"问题清单 + 重构方案"
- Agent 2(拿到 Agent 1 的方案后):按方案执行代码迁移,实际修改所有 controller
- Agent 3(拿到 Agent 2 的改动后):写回归测试,确保重构没有引入 bug
每一步的输出成为下一步的输入,形成一条 Agent 流水线——不过要注意,链越长,出错概率越高,建议每步审查后再启动下一环。
相关场景
- Agent 代码审查 — Schema 驱动的结构化审查
- 流水线开发流程 — pipeline() 接力开发

