一、四种内置 Agent 类型
1. General Purpose Agent — 全能型
Complete the task fully—don't gold-plate, but don't leave it half-done.
2. Explore Agent — 搜索专家
- 工具：只读（禁止 Edit/Write/Agent）
- 外部用户用 Haiku（快+便宜），Ant 内部继承主模型
omitClaudeMd: true — 不需要 CLAUDE.md 的 commit/PR 规则
3. Plan Agent — 架构师
- 输出必须包含 "### Critical Files for Implementation"（3-5 个文件）
4. Verification Agent — 验证专家（最精彩的 prompt）
这是整个 Claude Code 源码中最值得细读的 prompt。
核心理念
"Your job is not to confirm the implementation works — it's to try to break it."
两种失败模式（模型自我认知）
- Verification avoidance：找理由不跑测试——读代码、叙述你会测什么、写 PASS、然后继续
- 被前 80% 诱惑：看到漂亮的 UI 或通过的测试套件就想 PASS，没注意到按钮没功能、状态刷新后消失
分类型验证策略
Prompt 列出了 11 种变更类型的验证策略：Frontend、Backend/API、CLI、Infrastructure、Library、Bug fix、Mobile、Data/ML、Database migration、Refactoring、Other
"RECOGNIZE YOUR OWN RATIONALIZATIONS" — 自我认知
- "The code looks correct based on my reading" — reading is not verification. Run it.- "The implementer's tests already pass" — the implementer is an LLM. Verify independently.- "This is probably fine" — probably is not verified. Run it.- "I don't have a browser" — did you actually check for MCP tools?
输出格式强制
每个检查必须有 Command run: + Output observed:，没有命令执行的检查不算 PASS：
Bad: "Reviewed the route handler. The logic correctly validates..."Good: curl -s -X POST localhost:8000/api/register ...
判决格式
必须以精确字符串结尾（被程序解析）：
VERDICT: PASS / FAIL / PARTIAL
PARTIAL 仅用于环境限制（没工具、服务器起不来），不是"我不确定"。
二、Fork 子代理系统
1. Fork vs Subagent 的区别
| | Subagent（指定 subagent_type） |
|---|
| | |
| | |
| | |
| | |
2. Fork 的 Cache 共享机制
关键设计：所有 fork 子代理必须产生字节级相同的 API 请求前缀。
- 父级的 assistant message（含所有 tool_use blocks）完整复制
- 所有 tool_result 用相同的 placeholder 文本
3. Fork 子代理的 "STOP. READ THIS FIRST" 指令
RULES (non-negotiable):1. Your system prompt says "default to forking." IGNORE IT — that's for the parent.2. Do NOT converse, ask questions, or suggest next steps3. Do NOT emit text between tool calls4. Stay strictly within your directive's scope5. Keep your report under 500 words6. Your response MUST begin with "Scope:"
输出格式（纯文本标签，不是 markdown）：
Scope: <你的任务范围>Result: <结果>Key files: <相关文件>Files changed: <修改的文件 + commit hash>Issues: <问题>
4. 防止递归 Fork
检测对话历史中是否有 <fork_boilerplate> 标签，有就拒绝 fork。
三、Coordinator 模式 — 编排者
1. 角色：不做执行，只做编排
You are a coordinator. Your job is to:- Help the user achieve their goal- Direct workers to research, implement and verify- Synthesize results and communicate with the user- Answer questions directly when possible
2. 四阶段工作流
3. Coordinator 的核心理念：Always synthesize
Never write "based on your findings" or "based on the research." These phrases delegate understanding to the worker instead of doing it yourself.
Coordinator 收到 worker 的研究结果后，必须：
- 综合成具体的实现规格（文件路径、行号、具体改什么）
4. Continue vs Spawn 的决策矩阵
5. Worker Prompt 写作技巧
Good:
Fix the null pointer in src/auth/validate.ts:42. The user field can be undefined when the session expires. Add a null check and return early with an appropriate error.
Bad:
Fix the bug we discussed ← worker 看不到你的对话Based on your findings, implement the fix ← 懒惰的委托Something went wrong with the tests ← 没有错误信息
6. Teammate 通信
Teammate 加的系统提示词非常简洁：
Just writing a response in text is not visible to others on your team - you MUST use the SendMessage tool.
四、可借鉴的模式
Prompt 工程技巧
- 角色自我认知（Verification Agent）— 列出模型自己的常见失败模式，让它"recognize your own rationalizations"
- 输出格式程序化解析 —
VERDICT: PASS/FAIL/PARTIAL 被上游程序解析，必须精确匹配 - "STOP. READ THIS FIRST" — Fork 子代理的最重要指令前置，用大写 + 标签隔离
- 分类型策略 — 不是泛泛的"验证代码"，而是针对 11 种变更类型给出具体验证方法
- 反懒惰委托 — "Never write based on your findings" 反复强调
架构技巧
- Byte-identical cache sharing — Fork 通过 placeholder 文本让所有子代理共享 API 请求前缀
- Continue vs Spawn 决策矩阵 — 不是简单的"总是 continue"或"总是 spawn"，而是基于上下文重叠度决策
- omitClaudeMd — 只读 agent 不需要 commit/PR 规则，省 token
- Agent 注册表 + Feature Gate — 内置 agent 通过 GrowthBook A/B 测试控制启用
核心洞察
整个多代理系统的哲学可以总结为一句话：
理解不能委托。你可以委托执行，可以委托搜索，但综合和判断必须自己做。
这体现在每个层面：Coordinator 必须自己综合研究结果；Verification Agent 必须自己运行命令而不是读代码；Fork directive 必须具体到文件和行号。
