Claude任务拆分：先用单Agent加技能

把任务拆给多个 Claude subagents，不一定更快，也不一定更省。原文转述的 Anthropic 建议是：先用一个主代理配合 skills，只有遇到能测出来的问题，再引入子代理。

对日常 AI 编程来说，关键不是配齐多少个「专家」，而是判断哪些工作需要共享上下文，哪些工作适合独立完成、只交回摘要。这篇指南的价值，就在于给出了拆分边界和一个能直接参考的配置。

为什么先用一个主代理加 skills

据原文转述，Anthropic 的 Applied AI 团队在多个企业部署中发现：单代理配合 skills，在质量上经常优于「一个提示词包办全部」和子代理方案，而且单次任务的成本、延迟往往更低。其中一个客户做了对比，单代理循环的运行速度约为多代理方案的 2 倍。

但这不是「单代理永远赢」的证明。原文没有提供任务集、模型配置和完整评测结果，2 倍也只是一个客户案例。

单代理能承接更多工作，一个原因是渐进式披露（progressive disclosure）。skills 和 tool search 可以先让代理看到简短描述，需要时再加载完整内容，不必开局就塞进所有流程和工具说明。过去为了减少上下文而拆出去的工作，现在可能留在主代理里就能处理。

工具仍然需要整理。原文提到，工具定义超过约 30–50 个后，工具选择往往会变差，因此应按用户意图分组。这里的重点是让代理更容易找到完成当前任务所需的能力。

重复使用的一套操作步骤，优先做成 skill；它并不天然需要一个独立代理。

什么任务值得交给子代理

Claude Code 文档里的子代理有自己的上下文窗口、系统提示词、工具访问范围和权限，完成工作后向主对话返回摘要。它也会独立发起请求，计入同一套用量限制，并不是额外获得一份免费额度。

这套机制适合三类边界明确的任务。

第一类是隔离噪声。长日志、测试输出、文档阅读可能产生大量中间信息，但主代理只需要错误位置和结论。子代理可以处理这些内容，避免把主对话挤满。

第二类是独立并行。几条研究路径互不依赖，各自完成后能交回摘要，就适合使用独立上下文；任务结束后，这些上下文可以丢弃。

第三类是隔离工具和指令。某项工作只允许读取文件，或者主代理已经出现工具选错、系统指令冲突，拆分才有明确目的。

相反，需要频繁追问的任务，以及规划、实现、测试高度共享上下文的工作，更适合留在主对话。快速修改和对延迟敏感的任务也是如此。

拆分依据应当是任务边界，而不是团队组织架构。

给每个团队安排一个子代理，看起来职责分明，却未必符合任务实际需要的信息流。

一个只读日志助手就够开始

原文给出的配置专门处理长日志和测试输出。项目级子代理放在 .claude/agents/，跨项目使用则放在 ~/.claude/agents/。配置采用带 YAML frontmatter 的 Markdown 文件，只有 name 和 description 是必填项。

下面这段配置解决的是「读取大量输出，只返回错误及可能原因」：

---
name: log-researcher
description: "Reads long log files and test output, then reports only the errors and likely causes. Use when output is large."
tools: Read, Grep, Glob
model: haiku
---

You are a log analyst. Find errors, group them by cause,
and return a short summary with file paths and line numbers.
Do not edit any files.

最该看的是 tools: Read, Grep, Glob：配置给它的是读取和查找能力。末尾还要求不修改文件，并让结果包含文件路径和行号，方便主代理继续定位。

model: haiku 是原文示例的选择，但原文没有提供它与其他模型的效果或成本对比，不能据此认定日志分析统一选它最划算。

我的判断

我赞同「先集中，再按问题拆分」。前端和全栈开发里的不少修改，需要连续理解需求、实现和测试结果。过早分配给多个代理，会增加摘要传递和上下文交接的环节。

但原文的证据还不足以支持普遍的性能结论。它引用了企业部署观察和一个约 2 倍提速的案例，没有给出完整对照数据。工具超过约 30–50 个后选择变差，也更适合作为排查线索，不能当成固定上限。

比起凭感觉选择架构，原文更有用的建议是：先准备一组小评测，哪怕只有 10 个好样例，再逐个尝试把子代理职责合回主代理。只有合回后评分变差，才有理由继续保留独立子代理。具体怎么评分，原文没说清，需要团队自己定义。

能拿来做什么

• 处理前端或 Node 的小改动时，先让同一个主代理完成理解、修改和验证；反复使用的项目流程整理成 skill。
• 测试日志很长时，可以参考 log-researcher 配置，让只读助手返回错误分组、可能原因、文件路径和行号，再由主代理处理修改。
• 只有研究任务彼此独立、能分别交回摘要时，才尝试并行子代理；需要频繁同步的信息应继续放在主对话。
• 用至少 10 个有代表性的任务比较拆分前后的质量、耗时和成本，每次只调整一个子代理的职责，保留有实际收益的拆分。