造到第 30 个 agent，我开始怀疑该不该造

我的 Claude agent 定义库里现在有 30 份。reviewer 配对给了每种编程语言；流程 agent 分了规划、设计、测试、审查五个阶段；还有 5 个领域特化（数据库、医疗、性能等）。问题是：多少才够？什么时候不该造新的？

答案不是"能不能造"，而是约束密度。

三类成立条件

1. 语言成对的 reviewer 和 build-resolver——最明显成立

TypeScript、Rust、Go、Java、Python、C++、Kotlin……每种语言都配一对。typescript-reviewer 关注类型安全、异步正确、XSS 防护；rust-build-resolver 关注借用检查器、生命周期、cargo 依赖。

为什么分离？因为 error pattern 真的不一样。

typescript-reviewer 的 HIGH 检查点包括：

非空断言滥用（value! 后没有前置守卫）
as 类型转换绕过检查
forEach 里用 async（不会等待）
宽松的 TypeScript 编译器设置

这些对 Rust 没有意义。Rust 则需要：

借用冲突（immutable 活跃时不能 mutable）
生命周期边界太短
从引用后移出所有权
trait 实现不匹配

混在一个通用 reviewer 里会产生两个后果：要么给出泛泛而谈的"检查类型"之类的意见，要么为了照顾所有语言而膨胀到无用。所以这类成立。

2. 流程 agent——思考方式必须隔离

planner、architect、tdd-guide、code-reviewer、security-reviewer 分别对应的是不同的思维模式。

planner 的工作是规模化。它把一个模糊的需求分解成有依赖关系的、分阶段的步骤。格式包括：

Requirements 列表
Architecture Changes 清单
多个 Phase，每个 Phase 有多个步骤
每步都标注 Action、Why、Dependencies、Risk
Testing Strategy
Success Criteria

code-reviewer 的工作是细节校验。它逐行读代码，按优先级分类问题（CRITICAL / HIGH / MEDIUM / LOW），给出代码片段和修复建议。

如果混在一个 agent 里，它们会互相干扰：规划时陷入代码细节，审查时又开始重新规划。分离后，planner 可以大局思考而不被小语法问题打断，reviewer 可以专注代码质量而不被"这个步骤设计对吗"的大问题分神。

3. 领域 agent——条件性成立，必须约束足够密

database-reviewer 是这类的好例子。它不只是"你是 PostgreSQL 专家"，而是定义了：

核心职责：

Query Performance
Schema Design
Security & RLS
Connection Management
Concurrency
Monitoring

诊断命令：

psql -c "SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"
psql -c "SELECT relname, pg_size_pretty(...) FROM pg_stat_user_tables ORDER BY ...;"

关键原则（不只是建议，是规则）：

索引外键——没有例外
部分索引用于软删除
覆盖索引避免表查
队列用 SKIP LOCKED
游标分页替代 OFFSET
批量插入，禁止循环内逐行插入
事务保持短
锁顺序一致

反模式检查清单（10+ 条）：

SELECT * 在生产代码
ID 用 int（应该 bigint）
timestamp 无时区
随机 UUID 做主键
未参数化查询
GRANT ALL 给应用用户
RLS 策略每行调函数

这些不是建议，而是具体的、可验证的、在 PostgreSQL 世界里遵循的法则。database-reviewer 存在是因为它编码了这个领域的专有知识。

对比一个不该独立存在的例子：假设有个 "api-design-reviewer" agent，系统提示只有"检查 API 设计"加几条通用的"RESTful 最佳实践"。没有针对这个项目的路由规范、没有特定的错误响应格式检查、没有该业务领域的约束……那个 agent 其实不该独立——它只是拿 Claude 通用能力换了个称呼，增加了调度成本却没有添加任何专有约束。

过度设计的信号

一个 agent 定义如果满足以下条件，很可能不该独立存在：

系统提示是"你是 X 专家"加 2-3 条泛泛要求。真正有价值的 agent 定义会包含诊断步骤、命令、检查清单。
没有输出格式或流程。强 agent 会规定"输出必须包含这些节，用这个表格格式"之类的约束。没有就说明它没有对问题空间的深入理解。
check list 是通用的，不是该领域特有的。code-reviewer 的"检查大函数"对所有语言都有意义，但 typescript-reviewer 还会检查特定的 async 陷阱。如果一个 agent 的检查清单完全是通用的，它不该独立。
没有诊断命令。database-reviewer 给出了 pg_stat_statements 查询、EXPLAIN ANALYZE 步骤。如果 agent 定义里全是文字建议没有可执行的步骤，它没有足够的专有约束。

调度的代价

多 agent 不是免费的。每调用一个 agent 意味着：

上下文切换
一次新的 LLM 推理（可能是更贵的模型）
并行时的并发管理

所以不值得的 agent 必须合并。比如"README-updater"和"changelog-updater"如果约束差不多，就应该合并成单一的 doc-updater。实际上 doc-updater 确实存在，而且它的约束包括：输出结构（docs/CODEMAPS/ 的特定文件组织）、代码地图格式、验证步骤。这足以支撑独立存在。

实际计数

30 份 agent 的分布：

语言 reviewer/build-resolver 对：8 对（TypeScript/Rust/Go/Java/Python/C++/Kotlin/PyTorch），共 16 份
流程 agent：planner、architect、tdd-guide、code-reviewer、security-reviewer，共 5 份
领域特化：database-reviewer、healthcare-reviewer、performance-optimizer，共 3 份
功能专用：doc-updater、e2e-runner、refactor-cleaner、chief-of-staff、loop-operator、harness-optimizer、docs-lookup，共 7 份

前三类的成立都有明确的约束理由。第四类是工具性的，每个都解决具体问题（文档更新、E2E 测试、死代码清理）。

反过来想，如果要造第 31 个 agent，需要问：

它处理的问题空间有专有模式吗？
能列出 5 条以上该领域特有的规则或检查点吗？
有具体的诊断或验证步骤吗？
还是只是"我是 X 专家"加通用建议？

只要有一条答"不"，那就应该把这个职责并入现有 agent，而不是新造。

■