1. 从“单打独斗”到“团队协作”为什么你需要子代理如果你用过 Claude Code 或者类似的 AI 编程助手大概率经历过这种场景你让它写一个完整的 Web 应用从后端 API 到前端页面再到数据库设计。它吭哧吭哧给你生成了一大堆代码乍一看挺全但仔细一瞧API 路由的逻辑有点混乱前端的样式表命名冲突数据库的迁移脚本可能还有语法错误。你不得不打断它“等等我们先专注把用户认证模块做好其他的先放放。” 这就是典型的“全能型单体代理”的困境——它试图用一个大脑、一个进程去处理所有层级的任务结果往往是广度尚可深度不足尤其在复杂项目里细节经不起推敲。“子代理”Subagents这个概念就是为了解决这个问题而生的。它的核心思想非常直白就像它的中文翻译“把活儿外包出去别什么都自己扛”一样是一种任务分解与委派架构。想象一下你是一个项目经理主代理接到一个“开发电商网站”的大项目。你不会自己跑去写 CSS、调数据库连接池、配置 Nginx。你会组建一个团队前端工程师、后端工程师、运维工程师。你主代理负责理解客户需求用户指令拆解成产品需求文档高层任务规划然后分别派给对应的专家子代理去执行。前端工程师只关心组件和交互后端工程师专注业务逻辑和 API他们各司其职最终向你汇报成果由你汇总和呈现给客户。在 AI 智能体的语境下这个模式被具象化为Fan-out Subagents或Hierarchical Agents。主代理比如 Claude充当“大脑”和“协调者”它的核心职责不再是事无巨细地生成每一行代码而是理解与规划深度解析用户的复杂、模糊或宏大的指令将其分解成一系列离散、具体、可执行的任务。调度与委派为每个子任务创建或调用一个专门的子代理。每个子代理被赋予明确的职责、上下文和资源。协调与集成监督子代理的执行处理它们之间的依赖比如后端 API 没写完前端没法联调并最终将各个子代理的产出整合成一个连贯、完整的交付物。这种架构带来的好处是显而易见的。首先是质量与专注度的提升。一个专门处理“优化数据库查询”的子代理可以调用所有关于 SQL 索引、查询计划、ORM 最佳实践的知识而不必被 UI 设计或 API 路由分散注意力。其次是可扩展性。任务越复杂越能通过增加并行执行的子代理来加速。最后是鲁棒性与可调试性。如果前端构建失败了你可以清晰地定位到负责“前端构建”的子代理及其日志而不是在混杂了所有步骤的单体输出中大海捞针。当前围绕 Claude特别是 Claude Code的生态和社区讨论中Subagents 已经从一个理论概念变成了许多高阶工作流和工具链的核心模式。无论是通过 Claude API 自行编排还是利用一些新兴的 Agents 框架开发者们都在实践这种“让专业的人做专业的事”的协作范式以应对日益复杂的软件开发、数据分析乃至创意生成任务。2. 子代理的核心工作模式从串行到并行的思维转变理解了“为什么需要”之后我们来看看子代理具体“怎么工作”。这不仅仅是技术实现更是一种思维模式的转变——从线性的、串行的任务执行转向树状的、并行的任务协作。2.1 任务分解的艺术如何把“大活儿”拆成“小包”主代理的第一项也是最重要的能力就是任务分解。这听起来简单实则非常考验对问题域的理解深度。一个糟糕的分解会导致子代理间职责不清、相互阻塞而一个优雅的分解则能让整个系统流畅运转。以一个常见的开发任务为例“为我的博客系统添加一个文章评论功能需要支持富文本、回复嵌套、以及垃圾评论过滤。”一个初级的、线性的思路可能是1. 设计数据库表2. 写后端 CRUD API3. 实现富文本编辑器前端4. 做嵌套回复的 UI5. 接入反垃圾服务。这个顺序本身没问题但它是串行的且每个步骤内部依然复杂。在子代理模式下主代理的分解会更像一张工作分解结构图WBS子任务 A数据层设计评论相关的数据库表结构包括主评论、回复、用户关联编写 SQL 迁移脚本或 ORM 模型定义。子任务 B后端核心逻辑实现评论的创建、读取按文章分页、按线程嵌套、更新编辑、删除软删除的 API 端点。处理基础的数据验证和权限检查如用户只能删自己的评论。子任务 C富文本处理研究并集成一个前端富文本编辑器库如 Tiptap、Quill定义前端与后端交互的数据格式如 Delta 或 HTML并实现后端接收富文本内容后的安全过滤防 XSS。子任务 D嵌套回复与 UI设计前端组件树来渲染嵌套评论线程实现回复表单的交互逻辑点击回复按钮、引用原文、表单定位。子任务 E反垃圾服务调研并集成第三方反垃圾评论 API如 Akismet 或自建基于规则的过滤器在后端创建评论时调用并根据结果决定是直接发布、放入待审核还是拒绝。关键点在于这些子任务并非完全串行。任务 A数据层是 B、C、E 的前提。但任务 C富文本和 D嵌套 UI的前端部分可以与任务 B后端 API并行开发只要双方约定好 API 接口契约Contract。这就是主代理的另一个核心作用定义接口。它会在分解任务时就清晰地规定好子代理之间需要交换的数据格式比如“子任务 B 输出的 API必须遵循{ id, content, author, createdAt, parentId }这样的 JSON 结构。”2.2 子代理的创建与调度静态分配与动态生成子代理如何被创建和管理主要有两种模式。模式一静态技能池Skill Pool。主代理背后有一个预先定义好的“技能目录”或“工具集”。每个子代理对应一个特定的技能比如PythonCodeWriter、SQLExpert、UIAnalyst。当主代理分解出任务“编写一个 Flask 登录端点”时它就会从池子里唤醒PythonCodeWriter这个子代理并把任务描述、相关上下文如项目结构、已有的用户模型作为输入传递给它。Claude Code 内置的许多“技能”Skills在某种程度上就可以被视为这种预配置的子代理。你通过指令调用一个特定技能就等于启动了一个专精于此的子流程。模式二动态生成Dynamic Generation。这是更灵活、也更“智能”的模式。主代理根据当前任务的特殊需求临时“创造”一个子代理。例如任务分解出一项“将这篇中文技术文档翻译成英文并保持术语准确”。主代理可能会动态生成一个子代理并赋予它这样的指令“你是一个精通计算机科学的中英技术翻译专家。你的知识库特别关注‘云计算’、‘容器化’和‘微服务’领域的术语。请翻译以下内容对于专业术语请参考 Kubernetes 官方文档的译法。” 这个子代理的“人设”和专注领域就是为当前任务即时定制的。在基于 LLM 的系统中这通常通过为每个子任务实例化一个新的对话或提示词上下文来实现。在实际调度中主代理还需要处理依赖关系。它会构建一个任务依赖图无依赖的任务可以并行执行Fan-out有依赖的任务则需顺序执行。这就像 CI/CD 中的流水线单元测试任务依赖于编译任务而集成测试又依赖于单元测试。2.3 通信与集成让孤岛连接起来子代理们各干各的最后怎么拼到一起这就是通信与集成机制要解决的问题。子代理之间通常不直接对话它们都只与主代理通信向主代理汇报进度和提交产出。产出物通常是结构化的数据或代码块。例如数据层子代理提交comments_table.sql文件内容。后端子代理提交app/api/comments.py和app/models/comment.py的代码。富文本子代理提交前端RichTextEditor.vue组件代码以及后端的sanitize_html工具函数。主代理扮演“集成工程师”的角色。它需要验证与合并检查子代理的产出是否符合约定的接口是否有语法错误然后将代码合并到项目文件的正确位置。解决冲突如果两个子代理修改了同一个文件的相邻区域虽然好的分解应尽量避免主代理需要决定如何合并或提出解决冲突的方案。生成最终交付将所有子代理的产出连同必要的集成说明如“需要运行pip install -r requirements.txt以安装新依赖”打包成一个完整的、可运行的成果交付给用户。这个过程可以是全自动的也可以是需要人工审核的半自动。在 Claude Code 的交互中你常常会看到它分步骤、分文件地给出代码并询问“这部分完成了接下来我们实现 X 功能好吗”这其实就是一种简化版的、交互驱动的子代理模式——你是那个最终的主代理负责协调和决策。3. 实战基于现有工具构建你的子代理工作流理论说再多不如动手试。目前虽然还没有一个叫“Subagents”的现成一键工具但我们可以利用现有的 Claude 生态和相关框架搭建出子代理工作流的雏形。这里我分享两种实操路径一种基于 Claude Code 的交互式技巧另一种基于更编程化的 Agents 框架。3.1 路径一在 Claude Code 中手动实践“精神分裂式”开发即使没有高级框架你也可以在普通的 Claude Code 对话中有意识地运用子代理思维。我把这叫做“精神分裂式”开发法——你不是在和一个人工智能对话而是在指挥一个由你扮演项目经理的虚拟团队。第一步明确主代理角色你自己。在对话开始时就给自己定好位。你可以这样开始提示“我将扮演一个软件开发项目经理。我有一个项目需要完成[你的项目描述]。我的职责是将这个项目分解为具体的开发任务并分别委派给不同的专家由你扮演。我会清晰地描述每个专家的职责和任务边界。请你严格按照我委派的任务角色来响应不要越界。”第二步分解并委派第一个子代理。“首先我需要一位系统架构师。请根据项目描述给出高层次的技术选型建议、系统组件图以及主要的模块划分。请专注于架构设计不要深入任何模块的具体代码实现。”等 Claude 以“系统架构师”的身份回复后你得到了架构图。第三步基于产出委派后续子代理。“很好。现在基于架构师的方案我需要一位后端工程师使用 Python Flask。你的任务是1. 根据架构设计创建项目的基础目录结构。2. 实现核心的 [某个具体模块比如用户模型] 的数据库模型使用 SQLAlchemy和基础的 CRUD API 端点。请只完成后端部分不要涉及前端或部署。”在 Claude 生成后端代码后你继续“现在我需要一位前端工程师使用 Vue.js。这是后端提供的 API 接口文档 [粘贴刚才生成的 API 接口说明]。请创建对应的前端组件用于调用这些 API 并展示数据。请专注于前端逻辑和界面。”关键技巧与避坑指南上下文隔离这是手动模式最大的挑战。当你切换到新角色时Claude 可能还记得之前角色的对话细节导致“前端工程师”试图去修改后端代码。为了减少干扰一个有效的方法是开启一个新的对话窗口或会话标签页来扮演每个“子代理”。更优雅的做法是在每次委派时都清晰地重申边界“请注意你现在是前端工程师你只应关心 Vue 组件和调用 API不要修改或评论任何后端 Python 代码。”传递接口契约就像之前说的明确的数据接口是并行工作的基础。在委派前端任务时务必把后端 API 的精确 URL、HTTP 方法、请求体格式、响应体格式作为“合同”提供过去。集成由你负责最后你需要自己扮演“集成工程师”把不同对话中生成的代码手动复制、粘贴到正确的项目文件中并解决可能存在的微小不一致比如变量命名差异。这虽然有些繁琐但能让你深刻理解集成的痛点。这种方法锻炼的是你作为“人类主代理”的任务分解和协调能力非常适合中小型项目或学习阶段。3.2 路径二利用 Agents 框架进行自动化编排对于更复杂、更重复的任务手动切换角色效率太低。这时就需要用到一些自动化 Agents 框架。这些框架提供了创建、管理和协调多个 AI 代理子代理的编程基础。目前社区中比较活跃的框架包括LangChain、AutoGen微软、CrewAI等。它们的设计哲学类似都提供了定义代理角色、工具、以及代理间对话流程的能力。这里以概念相对直观的 CrewAI 为例简述如何搭建一个子代理系统。假设我们要自动化一个“技术博客生成”任务给定一个主题自动完成大纲撰写、内容研究、初稿写作、代码示例生成和最终校对。1. 定义代理子代理角色from crewai import Agent, Task, Crew, Process # 大纲策划师 outline_agent Agent( role技术博客大纲策划师, goal根据给定主题创作出结构清晰、逻辑严谨、吸引技术读者的博客大纲, backstory你是一位资深技术编辑擅长将复杂的主题分解为易于理解的章节。, verboseTrue # 打印详细日志 ) # 技术研究员 research_agent Agent( role技术细节研究员, goal为博客大纲中的每个关键章节搜集准确的技术细节、最新趋势和最佳实践, backstory你是一个不知疲倦的技术文档挖掘者善于从权威来源提取核心信息。, verboseTrue ) # 内容写手 writer_agent Agent( role技术博客写手, goal根据大纲和研究资料撰写生动、准确、易于理解的技术博客正文, backstory你是一位文笔流畅的技术博主善于将枯燥的技术概念转化为有趣的故事。, verboseTrue ) # 代码示例工程师 code_agent Agent( role代码示例工程师, goal为博客中涉及的技术概念生成简洁、正确、可运行的代码示例, backstory你是一名追求代码优雅和实用的开发者痛恨伪代码热爱可运行的片段。, verboseTrue )2. 创建任务链定义工作流# 任务1撰写大纲 task_outline Task( description针对主题“{topic}”撰写一篇技术博客的详细大纲包括引言、至少3个核心章节、以及结论。, agentoutline_agent, expected_output一个包含各级标题的Markdown格式大纲。 ) # 任务2研究技术细节 (依赖于大纲) task_research Task( description基于以下大纲为每个核心章节深入研究具体的技术细节、解决方案和参考案例。大纲{outline}, agentresearch_agent, context[task_outline], # 显式声明依赖关系 expected_output一份详细的研究笔记包含每个章节的关键点、数据和技术引用。 ) # 任务3撰写正文 (依赖于大纲和研究) task_write Task( description结合以下大纲和研究笔记撰写完整的博客正文。大纲{outline} 研究笔记{research}, agentwriter_agent, context[task_outline, task_research], expected_output一篇完整的、格式良好的技术博客文章草稿。 ) # 任务4生成代码示例 (依赖于正文草稿) task_code Task( description审阅以下博客草稿为其中提到的所有可代码化的概念生成对应的代码示例。博客草稿{draft}, agentcode_agent, context[task_write], expected_output一系列与博客内容对应的、可独立运行的代码块附有简短说明。 )3. 组建团队并执行# 组建团队指定执行流程顺序执行 crew Crew( agents[outline_agent, research_agent, writer_agent, code_agent], tasks[task_outline, task_research, task_write, task_code], processProcess.sequential # 也可以是 hierarchical 或 collaborative ) # 启动任务 result crew.kickoff(inputs{topic: 如何使用子代理架构构建AI辅助编程工作流}) print(result)在这个例子中框架自动处理了任务间的依赖传递context参数一个任务的输出会自动成为下一个任务的输入。Process.sequential表示顺序执行对于有依赖的任务链这是合适的。对于可以并行的任务你可以定义更复杂的流程。部署与集成考量成本每个子代理都是一次或多次 LLM API 调用如 Claude API复杂工作流成本不菲需做好预算管理。稳定性任何一个子代理失败如 API 超时、生成质量极差都可能导致整个工作流中断。需要设计重试、降级或人工审核的机制。评估如何自动评估最终产出的质量这本身就是一个难题。通常需要结合规则检查如代码编译通过、简单指标如文章长度和最终的人工审核。4. 深入原理子代理如何与 LLM 协同工作子代理模式之所以可行其根基在于现代大语言模型LLM如 Claude 所具备的两个关键能力角色扮演Role-playing与上下文管理Context Management。理解这些原理能帮助你在设计工作流时做出更明智的决策。4.1 角色扮演与提示词工程为子代理注入“灵魂”当你要求 Claude “扮演一个资深系统架构师”时你实际上是在通过提示词Prompt为模型临时构建一个高度特化的“人格面具”或“思维框架”。这个提示词不仅定义了角色更关键的是限制了模型的响应空间。一个用于创建“安全审计子代理”的提示词可能长这样你是一个专注于网络安全和代码审计的专家。你的知识库涵盖OWASP Top 10、常见注入漏洞、敏感信息泄露、权限绕过等问题。你的性格特点是严谨、多疑对任何潜在风险都持零容忍态度。 你的任务分析下面这段代码找出所有可能的安全漏洞并按风险等级高危、中危、低危分类列出。对于每个漏洞必须提供 1. 漏洞类型如SQL注入、XSS。 2. 代码中的具体位置行号。 3. 简要的原理说明。 4. 具体的修复代码建议。 请只输出审计报告不要对代码功能本身做任何评价或修改建议。如果未发现漏洞请明确声明“未发现可识别的安全漏洞”。 待审计代码 [此处粘贴代码]这个提示词做了以下几件事身份锚定“网络安全和代码审计的专家”设定了基础领域。知识范围限定“涵盖OWASP Top 10...”指明了调用的知识范围避免它用无关的知识来回答。性格与立场塑造“严谨、多疑...零容忍”给了模型一个响应的“态度”这会影响它判断的严格程度。任务与格式约束“找出...按风险等级分类...必须提供4点...”这是最核心的指令给出了明确、结构化、可验证的输出要求。输出边界划定“只输出审计报告不要...”防止它画蛇添足保持输出的纯净。通过精心设计的提示词我们可以让同一个底层 LLM 模型化身为无数个具有不同专业背景、思维模式和输出规范的“子代理”。这就是子代理多样性的来源。4.2 上下文窗口子代理协作的“会议室”与“接力棒”LLM 的上下文窗口Context Window是所有交互发生的地方。你可以把它想象成一个“短期工作记忆区”。子代理之间的协作本质上是信息在这个上下文窗口内或跨窗口的传递。模式A单窗口内的角色切换适用于简单工作流。就像我们在 Claude Code 手动模式里做的所有“对话”都发生在同一个上下文窗口中。主代理用户通过提示词切换话题和角色。优点是简单直接信息传递无损因为上下文全在。缺点是容易造成“角色污染”随着对话轮次增加模型可能会混淆不同角色的指令且上下文长度有限比如 Claude 的 200K token超长任务可能装不下。模式B多窗口间的任务接力框架常用模式。这是 Agents 框架的典型做法。每个子代理任务都在一个独立的、干净的上下文窗口中发起。主代理框架将上一个任务的输出作为下一个任务的输入的一部分注入到新的提示词中。这就像一场接力赛每个子代理只跑自己的一棒接过“任务说明上游产出”这根接力棒跑完后将结果交给下一棒。优点角色隔离彻底每个子代理都从“纯净”的指令开始不易受干扰。易于并行化多个独立窗口可同时运行。缺点信息可能有损传递。上游子代理的完整思考过程那些“内心戏”不会被下游看到下游只能看到最终产出。如果上游产出有细微的歧义或隐含假设下游可能无法理解导致错误累积。这要求任务分解时接口契约必须定义得极其清晰、无歧义。模式C分层上下文与摘要传递高级模式。为了解决信息丢失问题更高级的系统会引入“摘要”或“状态向量”的概念。当一个子代理完成复杂任务后除了产出最终结果如代码文件它还会生成一份简短的执行摘要或关键决策日志说明“我做了什么”、“我做了哪些关键假设”、“遇到了什么问题以及如何解决的”。这份摘要会和核心产出一起传递给下游子代理为其提供更丰富的上下文减少误解。4.3 工具调用Function Calling子代理的“手”和“脚”一个只会“空想”的子代理价值有限。真正的威力在于让子代理能够行动——执行代码、查询数据库、调用 API、操作文件系统。这就是工具调用Tool Calling 或 Function Calling的意义。在子代理架构中不同的子代理可以被赋予不同的工具集代码专家子代理可能被授予在安全沙箱中执行python、npm install、git命令的工具。网络研究员子代理可能被授予使用search_web、fetch_webpage工具的能力。文件操作子代理可能被授予read_file、write_file、list_directory的权限。主代理或编排框架负责管理这些工具的权限和安全边界。例如一个负责代码生成的子代理可以被允许写文件到src/目录但绝不允许删除node_modules或修改系统文件。当子代理需要完成一项任务时它不仅可以“思考”生成文本还可以“行动”选择并调用一个工具。LLM 会输出一个结构化的请求如{action: execute_shell, command: python -m pytest tests/}框架则执行该命令并将结果标准输出、错误码返回给 LLMLLM 再根据结果决定下一步。这使得子代理能够完成闭环的、影响现实世界的任务。安全是这里的重中之重。必须实施严格的沙箱环境、资源限制CPU/内存/网络和操作审计防止子代理执行恶意或破坏性指令。在自动化程度很高的工作流中对于高风险操作如删除文件、向生产环境部署引入“人工审批”环节是必要的安全阀。5. 设计高效子代理系统的关键考量与避坑指南将子代理从概念落地为稳定、高效的系统会面临一系列工程和设计上的挑战。结合我自己的实践和观察到的社区案例这里总结出几个最关键的设计考量和常见陷阱。5.1 任务分解的粒度多细才算“刚刚好”这是子代理设计中最艺术的部分。分解得太粗子代理内部依然复杂失去了分工的意义分解得太细管理开销剧增子代理间通信成本可能超过收益。一个实用的启发式原则是“单一职责与可验证产出”。每个子代理的任务应该满足职责单一能用一句话清晰说明这个代理是干什么的例如“将用户自然语言描述转化为 SQL 查询语句”。输入明确任务所需的所有信息都能从上游或初始指令中获得没有隐藏的、需要它自己猜测的上下文。产出可验证产出物有明确的、可自动或人工快速检验的标准例如生成的 SQL 是否能通过语法检查返回的代码片段是否能编译。以“开发一个登录页面”为例过粗的分解“实现登录页面”。这个任务包含前端 UI、后端 API、数据库交互、密码加密太复杂。过细的分解“编写用户名输入框的 HTML 代码”、“编写密码输入框的 HTML 代码”、“编写提交按钮的 HTML 代码”……管理噩梦且失去了组件化的意义。合适的分解子代理A设计登录 API 端点接收用户名/密码返回 Token/错误。子代理B创建登录表单的 Vue 组件包含数据绑定、表单验证和 API 调用。子代理C实现密码的加盐哈希存储与验证函数。每个子任务都有清晰的边界和可交付的代码文件。5.2 错误处理与鲁棒性当一个子代理“宕机”时在自动化工作流中错误不是例外而是常态。子代理可能因为多种原因失败LLM 生成质量差胡言乱语、偏离主题、生成有害内容。工具调用失败命令执行错误、网络超时、权限不足。依赖不满足上游子代理的产出不符合预期导致下游无法处理。你的系统必须有应对策略重试机制对于暂时的失败如 API 限流、网络抖动可以自动重试 1-2 次并可能伴随一些提示词的微调例如“上次的答案格式不对请严格按照 JSON 格式输出”。降级方案如果一个负责“优化图片”的子代理失败了系统是否可以跳过这一步直接使用原始图片或者调用一个更简单但效果差一点的备用工具人工审核点在关键路径上设置检查点。例如在所有代码生成子代理完成后引入一个“代码审查子代理”或直接触发一次 CI 流水线。如果编译失败或测试不通过则暂停流程通知人类介入。超时与回滚为每个子任务设置合理的超时时间。对于有状态的操作如数据库写入要考虑如何回滚一个失败工作流中已成功步骤的影响这通常非常复杂因此要尽量设计无状态或幂等的子任务。5.3 成本与延迟的权衡子代理模式不是免费的午餐。每个子代理都是一次或多次 LLM API 调用成本随着代理数量线性增长。同时串行执行的子代理会引入累积延迟。优化策略包括并行化仔细分析任务依赖图让没有依赖关系的子代理并行执行。例如“生成文档”和“运行单元测试”这两个任务通常可以同时进行。缓存对于确定性较高的子任务如“根据固定模板生成项目脚手架代码”其输出可以缓存起来。下次遇到相同输入时直接使用缓存结果避免重复调用 LLM。使用轻量级模型并非所有子代理都需要 Claude Opus 这样的“重型大脑”。对于格式转换、简单文本提取、基础代码生成等任务使用更小、更便宜的模型如 Haiku可能完全足够能大幅降低成本。任务合并如果两个子代理总是顺序执行且通信开销很大可以考虑将它们合并为一个稍大但更连贯的任务减少一次 LLM 调用和上下文传递的开销。5.4 评估与迭代如何知道你的子代理系统在变好搭建好系统只是开始。你需要一套机制来评估其表现并持续迭代优化。定性评估人工抽查。定期检查最终产出物看是否符合预期。这是最可靠但最费力的方法。定量指标任务完成率有多少比例的工作流能从头到尾无人工干预地跑通平均处理时间从开始到结束的总耗时是多少分解到每个子任务的时间是多少成本消耗每个工作流平均花费多少 API 费用产出质量评分可以设计一些自动化的评分规则。例如对于代码生成任务可以用“编译通过率”、“单元测试通过率”、“代码风格检查得分”作为代理指标。A/B 测试尝试用不同的方式分解同一个任务或者为同一个子任务设计不同的提示词然后对比最终结果的质量和效率。数据会告诉你哪种设计更优。子代理系统的设计是一个持续迭代的过程。从一个小而精的用例开始比如自动生成项目的 README 文件验证整个流程跑通然后逐步增加复杂度扩展到一个模块、一个功能乃至更复杂的项目。在这个过程中你会积累下最适用于你自身业务场景的任务分解模式、提示词模板和错误处理策略这才是最有价值的资产。 子代理架构：从单体AI到团队协作的智能体设计模式
1. 从“单打独斗”到“团队协作”为什么你需要子代理如果你用过 Claude Code 或者类似的 AI 编程助手大概率经历过这种场景你让它写一个完整的 Web 应用从后端 API 到前端页面再到数据库设计。它吭哧吭哧给你生成了一大堆代码乍一看挺全但仔细一瞧API 路由的逻辑有点混乱前端的样式表命名冲突数据库的迁移脚本可能还有语法错误。你不得不打断它“等等我们先专注把用户认证模块做好其他的先放放。” 这就是典型的“全能型单体代理”的困境——它试图用一个大脑、一个进程去处理所有层级的任务结果往往是广度尚可深度不足尤其在复杂项目里细节经不起推敲。“子代理”Subagents这个概念就是为了解决这个问题而生的。它的核心思想非常直白就像它的中文翻译“把活儿外包出去别什么都自己扛”一样是一种任务分解与委派架构。想象一下你是一个项目经理主代理接到一个“开发电商网站”的大项目。你不会自己跑去写 CSS、调数据库连接池、配置 Nginx。你会组建一个团队前端工程师、后端工程师、运维工程师。你主代理负责理解客户需求用户指令拆解成产品需求文档高层任务规划然后分别派给对应的专家子代理去执行。前端工程师只关心组件和交互后端工程师专注业务逻辑和 API他们各司其职最终向你汇报成果由你汇总和呈现给客户。在 AI 智能体的语境下这个模式被具象化为Fan-out Subagents或Hierarchical Agents。主代理比如 Claude充当“大脑”和“协调者”它的核心职责不再是事无巨细地生成每一行代码而是理解与规划深度解析用户的复杂、模糊或宏大的指令将其分解成一系列离散、具体、可执行的任务。调度与委派为每个子任务创建或调用一个专门的子代理。每个子代理被赋予明确的职责、上下文和资源。协调与集成监督子代理的执行处理它们之间的依赖比如后端 API 没写完前端没法联调并最终将各个子代理的产出整合成一个连贯、完整的交付物。这种架构带来的好处是显而易见的。首先是质量与专注度的提升。一个专门处理“优化数据库查询”的子代理可以调用所有关于 SQL 索引、查询计划、ORM 最佳实践的知识而不必被 UI 设计或 API 路由分散注意力。其次是可扩展性。任务越复杂越能通过增加并行执行的子代理来加速。最后是鲁棒性与可调试性。如果前端构建失败了你可以清晰地定位到负责“前端构建”的子代理及其日志而不是在混杂了所有步骤的单体输出中大海捞针。当前围绕 Claude特别是 Claude Code的生态和社区讨论中Subagents 已经从一个理论概念变成了许多高阶工作流和工具链的核心模式。无论是通过 Claude API 自行编排还是利用一些新兴的 Agents 框架开发者们都在实践这种“让专业的人做专业的事”的协作范式以应对日益复杂的软件开发、数据分析乃至创意生成任务。2. 子代理的核心工作模式从串行到并行的思维转变理解了“为什么需要”之后我们来看看子代理具体“怎么工作”。这不仅仅是技术实现更是一种思维模式的转变——从线性的、串行的任务执行转向树状的、并行的任务协作。2.1 任务分解的艺术如何把“大活儿”拆成“小包”主代理的第一项也是最重要的能力就是任务分解。这听起来简单实则非常考验对问题域的理解深度。一个糟糕的分解会导致子代理间职责不清、相互阻塞而一个优雅的分解则能让整个系统流畅运转。以一个常见的开发任务为例“为我的博客系统添加一个文章评论功能需要支持富文本、回复嵌套、以及垃圾评论过滤。”一个初级的、线性的思路可能是1. 设计数据库表2. 写后端 CRUD API3. 实现富文本编辑器前端4. 做嵌套回复的 UI5. 接入反垃圾服务。这个顺序本身没问题但它是串行的且每个步骤内部依然复杂。在子代理模式下主代理的分解会更像一张工作分解结构图WBS子任务 A数据层设计评论相关的数据库表结构包括主评论、回复、用户关联编写 SQL 迁移脚本或 ORM 模型定义。子任务 B后端核心逻辑实现评论的创建、读取按文章分页、按线程嵌套、更新编辑、删除软删除的 API 端点。处理基础的数据验证和权限检查如用户只能删自己的评论。子任务 C富文本处理研究并集成一个前端富文本编辑器库如 Tiptap、Quill定义前端与后端交互的数据格式如 Delta 或 HTML并实现后端接收富文本内容后的安全过滤防 XSS。子任务 D嵌套回复与 UI设计前端组件树来渲染嵌套评论线程实现回复表单的交互逻辑点击回复按钮、引用原文、表单定位。子任务 E反垃圾服务调研并集成第三方反垃圾评论 API如 Akismet 或自建基于规则的过滤器在后端创建评论时调用并根据结果决定是直接发布、放入待审核还是拒绝。关键点在于这些子任务并非完全串行。任务 A数据层是 B、C、E 的前提。但任务 C富文本和 D嵌套 UI的前端部分可以与任务 B后端 API并行开发只要双方约定好 API 接口契约Contract。这就是主代理的另一个核心作用定义接口。它会在分解任务时就清晰地规定好子代理之间需要交换的数据格式比如“子任务 B 输出的 API必须遵循{ id, content, author, createdAt, parentId }这样的 JSON 结构。”2.2 子代理的创建与调度静态分配与动态生成子代理如何被创建和管理主要有两种模式。模式一静态技能池Skill Pool。主代理背后有一个预先定义好的“技能目录”或“工具集”。每个子代理对应一个特定的技能比如PythonCodeWriter、SQLExpert、UIAnalyst。当主代理分解出任务“编写一个 Flask 登录端点”时它就会从池子里唤醒PythonCodeWriter这个子代理并把任务描述、相关上下文如项目结构、已有的用户模型作为输入传递给它。Claude Code 内置的许多“技能”Skills在某种程度上就可以被视为这种预配置的子代理。你通过指令调用一个特定技能就等于启动了一个专精于此的子流程。模式二动态生成Dynamic Generation。这是更灵活、也更“智能”的模式。主代理根据当前任务的特殊需求临时“创造”一个子代理。例如任务分解出一项“将这篇中文技术文档翻译成英文并保持术语准确”。主代理可能会动态生成一个子代理并赋予它这样的指令“你是一个精通计算机科学的中英技术翻译专家。你的知识库特别关注‘云计算’、‘容器化’和‘微服务’领域的术语。请翻译以下内容对于专业术语请参考 Kubernetes 官方文档的译法。” 这个子代理的“人设”和专注领域就是为当前任务即时定制的。在基于 LLM 的系统中这通常通过为每个子任务实例化一个新的对话或提示词上下文来实现。在实际调度中主代理还需要处理依赖关系。它会构建一个任务依赖图无依赖的任务可以并行执行Fan-out有依赖的任务则需顺序执行。这就像 CI/CD 中的流水线单元测试任务依赖于编译任务而集成测试又依赖于单元测试。2.3 通信与集成让孤岛连接起来子代理们各干各的最后怎么拼到一起这就是通信与集成机制要解决的问题。子代理之间通常不直接对话它们都只与主代理通信向主代理汇报进度和提交产出。产出物通常是结构化的数据或代码块。例如数据层子代理提交comments_table.sql文件内容。后端子代理提交app/api/comments.py和app/models/comment.py的代码。富文本子代理提交前端RichTextEditor.vue组件代码以及后端的sanitize_html工具函数。主代理扮演“集成工程师”的角色。它需要验证与合并检查子代理的产出是否符合约定的接口是否有语法错误然后将代码合并到项目文件的正确位置。解决冲突如果两个子代理修改了同一个文件的相邻区域虽然好的分解应尽量避免主代理需要决定如何合并或提出解决冲突的方案。生成最终交付将所有子代理的产出连同必要的集成说明如“需要运行pip install -r requirements.txt以安装新依赖”打包成一个完整的、可运行的成果交付给用户。这个过程可以是全自动的也可以是需要人工审核的半自动。在 Claude Code 的交互中你常常会看到它分步骤、分文件地给出代码并询问“这部分完成了接下来我们实现 X 功能好吗”这其实就是一种简化版的、交互驱动的子代理模式——你是那个最终的主代理负责协调和决策。3. 实战基于现有工具构建你的子代理工作流理论说再多不如动手试。目前虽然还没有一个叫“Subagents”的现成一键工具但我们可以利用现有的 Claude 生态和相关框架搭建出子代理工作流的雏形。这里我分享两种实操路径一种基于 Claude Code 的交互式技巧另一种基于更编程化的 Agents 框架。3.1 路径一在 Claude Code 中手动实践“精神分裂式”开发即使没有高级框架你也可以在普通的 Claude Code 对话中有意识地运用子代理思维。我把这叫做“精神分裂式”开发法——你不是在和一个人工智能对话而是在指挥一个由你扮演项目经理的虚拟团队。第一步明确主代理角色你自己。在对话开始时就给自己定好位。你可以这样开始提示“我将扮演一个软件开发项目经理。我有一个项目需要完成[你的项目描述]。我的职责是将这个项目分解为具体的开发任务并分别委派给不同的专家由你扮演。我会清晰地描述每个专家的职责和任务边界。请你严格按照我委派的任务角色来响应不要越界。”第二步分解并委派第一个子代理。“首先我需要一位系统架构师。请根据项目描述给出高层次的技术选型建议、系统组件图以及主要的模块划分。请专注于架构设计不要深入任何模块的具体代码实现。”等 Claude 以“系统架构师”的身份回复后你得到了架构图。第三步基于产出委派后续子代理。“很好。现在基于架构师的方案我需要一位后端工程师使用 Python Flask。你的任务是1. 根据架构设计创建项目的基础目录结构。2. 实现核心的 [某个具体模块比如用户模型] 的数据库模型使用 SQLAlchemy和基础的 CRUD API 端点。请只完成后端部分不要涉及前端或部署。”在 Claude 生成后端代码后你继续“现在我需要一位前端工程师使用 Vue.js。这是后端提供的 API 接口文档 [粘贴刚才生成的 API 接口说明]。请创建对应的前端组件用于调用这些 API 并展示数据。请专注于前端逻辑和界面。”关键技巧与避坑指南上下文隔离这是手动模式最大的挑战。当你切换到新角色时Claude 可能还记得之前角色的对话细节导致“前端工程师”试图去修改后端代码。为了减少干扰一个有效的方法是开启一个新的对话窗口或会话标签页来扮演每个“子代理”。更优雅的做法是在每次委派时都清晰地重申边界“请注意你现在是前端工程师你只应关心 Vue 组件和调用 API不要修改或评论任何后端 Python 代码。”传递接口契约就像之前说的明确的数据接口是并行工作的基础。在委派前端任务时务必把后端 API 的精确 URL、HTTP 方法、请求体格式、响应体格式作为“合同”提供过去。集成由你负责最后你需要自己扮演“集成工程师”把不同对话中生成的代码手动复制、粘贴到正确的项目文件中并解决可能存在的微小不一致比如变量命名差异。这虽然有些繁琐但能让你深刻理解集成的痛点。这种方法锻炼的是你作为“人类主代理”的任务分解和协调能力非常适合中小型项目或学习阶段。3.2 路径二利用 Agents 框架进行自动化编排对于更复杂、更重复的任务手动切换角色效率太低。这时就需要用到一些自动化 Agents 框架。这些框架提供了创建、管理和协调多个 AI 代理子代理的编程基础。目前社区中比较活跃的框架包括LangChain、AutoGen微软、CrewAI等。它们的设计哲学类似都提供了定义代理角色、工具、以及代理间对话流程的能力。这里以概念相对直观的 CrewAI 为例简述如何搭建一个子代理系统。假设我们要自动化一个“技术博客生成”任务给定一个主题自动完成大纲撰写、内容研究、初稿写作、代码示例生成和最终校对。1. 定义代理子代理角色from crewai import Agent, Task, Crew, Process # 大纲策划师 outline_agent Agent( role技术博客大纲策划师, goal根据给定主题创作出结构清晰、逻辑严谨、吸引技术读者的博客大纲, backstory你是一位资深技术编辑擅长将复杂的主题分解为易于理解的章节。, verboseTrue # 打印详细日志 ) # 技术研究员 research_agent Agent( role技术细节研究员, goal为博客大纲中的每个关键章节搜集准确的技术细节、最新趋势和最佳实践, backstory你是一个不知疲倦的技术文档挖掘者善于从权威来源提取核心信息。, verboseTrue ) # 内容写手 writer_agent Agent( role技术博客写手, goal根据大纲和研究资料撰写生动、准确、易于理解的技术博客正文, backstory你是一位文笔流畅的技术博主善于将枯燥的技术概念转化为有趣的故事。, verboseTrue ) # 代码示例工程师 code_agent Agent( role代码示例工程师, goal为博客中涉及的技术概念生成简洁、正确、可运行的代码示例, backstory你是一名追求代码优雅和实用的开发者痛恨伪代码热爱可运行的片段。, verboseTrue )2. 创建任务链定义工作流# 任务1撰写大纲 task_outline Task( description针对主题“{topic}”撰写一篇技术博客的详细大纲包括引言、至少3个核心章节、以及结论。, agentoutline_agent, expected_output一个包含各级标题的Markdown格式大纲。 ) # 任务2研究技术细节 (依赖于大纲) task_research Task( description基于以下大纲为每个核心章节深入研究具体的技术细节、解决方案和参考案例。大纲{outline}, agentresearch_agent, context[task_outline], # 显式声明依赖关系 expected_output一份详细的研究笔记包含每个章节的关键点、数据和技术引用。 ) # 任务3撰写正文 (依赖于大纲和研究) task_write Task( description结合以下大纲和研究笔记撰写完整的博客正文。大纲{outline} 研究笔记{research}, agentwriter_agent, context[task_outline, task_research], expected_output一篇完整的、格式良好的技术博客文章草稿。 ) # 任务4生成代码示例 (依赖于正文草稿) task_code Task( description审阅以下博客草稿为其中提到的所有可代码化的概念生成对应的代码示例。博客草稿{draft}, agentcode_agent, context[task_write], expected_output一系列与博客内容对应的、可独立运行的代码块附有简短说明。 )3. 组建团队并执行# 组建团队指定执行流程顺序执行 crew Crew( agents[outline_agent, research_agent, writer_agent, code_agent], tasks[task_outline, task_research, task_write, task_code], processProcess.sequential # 也可以是 hierarchical 或 collaborative ) # 启动任务 result crew.kickoff(inputs{topic: 如何使用子代理架构构建AI辅助编程工作流}) print(result)在这个例子中框架自动处理了任务间的依赖传递context参数一个任务的输出会自动成为下一个任务的输入。Process.sequential表示顺序执行对于有依赖的任务链这是合适的。对于可以并行的任务你可以定义更复杂的流程。部署与集成考量成本每个子代理都是一次或多次 LLM API 调用如 Claude API复杂工作流成本不菲需做好预算管理。稳定性任何一个子代理失败如 API 超时、生成质量极差都可能导致整个工作流中断。需要设计重试、降级或人工审核的机制。评估如何自动评估最终产出的质量这本身就是一个难题。通常需要结合规则检查如代码编译通过、简单指标如文章长度和最终的人工审核。4. 深入原理子代理如何与 LLM 协同工作子代理模式之所以可行其根基在于现代大语言模型LLM如 Claude 所具备的两个关键能力角色扮演Role-playing与上下文管理Context Management。理解这些原理能帮助你在设计工作流时做出更明智的决策。4.1 角色扮演与提示词工程为子代理注入“灵魂”当你要求 Claude “扮演一个资深系统架构师”时你实际上是在通过提示词Prompt为模型临时构建一个高度特化的“人格面具”或“思维框架”。这个提示词不仅定义了角色更关键的是限制了模型的响应空间。一个用于创建“安全审计子代理”的提示词可能长这样你是一个专注于网络安全和代码审计的专家。你的知识库涵盖OWASP Top 10、常见注入漏洞、敏感信息泄露、权限绕过等问题。你的性格特点是严谨、多疑对任何潜在风险都持零容忍态度。 你的任务分析下面这段代码找出所有可能的安全漏洞并按风险等级高危、中危、低危分类列出。对于每个漏洞必须提供 1. 漏洞类型如SQL注入、XSS。 2. 代码中的具体位置行号。 3. 简要的原理说明。 4. 具体的修复代码建议。 请只输出审计报告不要对代码功能本身做任何评价或修改建议。如果未发现漏洞请明确声明“未发现可识别的安全漏洞”。 待审计代码 [此处粘贴代码]这个提示词做了以下几件事身份锚定“网络安全和代码审计的专家”设定了基础领域。知识范围限定“涵盖OWASP Top 10...”指明了调用的知识范围避免它用无关的知识来回答。性格与立场塑造“严谨、多疑...零容忍”给了模型一个响应的“态度”这会影响它判断的严格程度。任务与格式约束“找出...按风险等级分类...必须提供4点...”这是最核心的指令给出了明确、结构化、可验证的输出要求。输出边界划定“只输出审计报告不要...”防止它画蛇添足保持输出的纯净。通过精心设计的提示词我们可以让同一个底层 LLM 模型化身为无数个具有不同专业背景、思维模式和输出规范的“子代理”。这就是子代理多样性的来源。4.2 上下文窗口子代理协作的“会议室”与“接力棒”LLM 的上下文窗口Context Window是所有交互发生的地方。你可以把它想象成一个“短期工作记忆区”。子代理之间的协作本质上是信息在这个上下文窗口内或跨窗口的传递。模式A单窗口内的角色切换适用于简单工作流。就像我们在 Claude Code 手动模式里做的所有“对话”都发生在同一个上下文窗口中。主代理用户通过提示词切换话题和角色。优点是简单直接信息传递无损因为上下文全在。缺点是容易造成“角色污染”随着对话轮次增加模型可能会混淆不同角色的指令且上下文长度有限比如 Claude 的 200K token超长任务可能装不下。模式B多窗口间的任务接力框架常用模式。这是 Agents 框架的典型做法。每个子代理任务都在一个独立的、干净的上下文窗口中发起。主代理框架将上一个任务的输出作为下一个任务的输入的一部分注入到新的提示词中。这就像一场接力赛每个子代理只跑自己的一棒接过“任务说明上游产出”这根接力棒跑完后将结果交给下一棒。优点角色隔离彻底每个子代理都从“纯净”的指令开始不易受干扰。易于并行化多个独立窗口可同时运行。缺点信息可能有损传递。上游子代理的完整思考过程那些“内心戏”不会被下游看到下游只能看到最终产出。如果上游产出有细微的歧义或隐含假设下游可能无法理解导致错误累积。这要求任务分解时接口契约必须定义得极其清晰、无歧义。模式C分层上下文与摘要传递高级模式。为了解决信息丢失问题更高级的系统会引入“摘要”或“状态向量”的概念。当一个子代理完成复杂任务后除了产出最终结果如代码文件它还会生成一份简短的执行摘要或关键决策日志说明“我做了什么”、“我做了哪些关键假设”、“遇到了什么问题以及如何解决的”。这份摘要会和核心产出一起传递给下游子代理为其提供更丰富的上下文减少误解。4.3 工具调用Function Calling子代理的“手”和“脚”一个只会“空想”的子代理价值有限。真正的威力在于让子代理能够行动——执行代码、查询数据库、调用 API、操作文件系统。这就是工具调用Tool Calling 或 Function Calling的意义。在子代理架构中不同的子代理可以被赋予不同的工具集代码专家子代理可能被授予在安全沙箱中执行python、npm install、git命令的工具。网络研究员子代理可能被授予使用search_web、fetch_webpage工具的能力。文件操作子代理可能被授予read_file、write_file、list_directory的权限。主代理或编排框架负责管理这些工具的权限和安全边界。例如一个负责代码生成的子代理可以被允许写文件到src/目录但绝不允许删除node_modules或修改系统文件。当子代理需要完成一项任务时它不仅可以“思考”生成文本还可以“行动”选择并调用一个工具。LLM 会输出一个结构化的请求如{action: execute_shell, command: python -m pytest tests/}框架则执行该命令并将结果标准输出、错误码返回给 LLMLLM 再根据结果决定下一步。这使得子代理能够完成闭环的、影响现实世界的任务。安全是这里的重中之重。必须实施严格的沙箱环境、资源限制CPU/内存/网络和操作审计防止子代理执行恶意或破坏性指令。在自动化程度很高的工作流中对于高风险操作如删除文件、向生产环境部署引入“人工审批”环节是必要的安全阀。5. 设计高效子代理系统的关键考量与避坑指南将子代理从概念落地为稳定、高效的系统会面临一系列工程和设计上的挑战。结合我自己的实践和观察到的社区案例这里总结出几个最关键的设计考量和常见陷阱。5.1 任务分解的粒度多细才算“刚刚好”这是子代理设计中最艺术的部分。分解得太粗子代理内部依然复杂失去了分工的意义分解得太细管理开销剧增子代理间通信成本可能超过收益。一个实用的启发式原则是“单一职责与可验证产出”。每个子代理的任务应该满足职责单一能用一句话清晰说明这个代理是干什么的例如“将用户自然语言描述转化为 SQL 查询语句”。输入明确任务所需的所有信息都能从上游或初始指令中获得没有隐藏的、需要它自己猜测的上下文。产出可验证产出物有明确的、可自动或人工快速检验的标准例如生成的 SQL 是否能通过语法检查返回的代码片段是否能编译。以“开发一个登录页面”为例过粗的分解“实现登录页面”。这个任务包含前端 UI、后端 API、数据库交互、密码加密太复杂。过细的分解“编写用户名输入框的 HTML 代码”、“编写密码输入框的 HTML 代码”、“编写提交按钮的 HTML 代码”……管理噩梦且失去了组件化的意义。合适的分解子代理A设计登录 API 端点接收用户名/密码返回 Token/错误。子代理B创建登录表单的 Vue 组件包含数据绑定、表单验证和 API 调用。子代理C实现密码的加盐哈希存储与验证函数。每个子任务都有清晰的边界和可交付的代码文件。5.2 错误处理与鲁棒性当一个子代理“宕机”时在自动化工作流中错误不是例外而是常态。子代理可能因为多种原因失败LLM 生成质量差胡言乱语、偏离主题、生成有害内容。工具调用失败命令执行错误、网络超时、权限不足。依赖不满足上游子代理的产出不符合预期导致下游无法处理。你的系统必须有应对策略重试机制对于暂时的失败如 API 限流、网络抖动可以自动重试 1-2 次并可能伴随一些提示词的微调例如“上次的答案格式不对请严格按照 JSON 格式输出”。降级方案如果一个负责“优化图片”的子代理失败了系统是否可以跳过这一步直接使用原始图片或者调用一个更简单但效果差一点的备用工具人工审核点在关键路径上设置检查点。例如在所有代码生成子代理完成后引入一个“代码审查子代理”或直接触发一次 CI 流水线。如果编译失败或测试不通过则暂停流程通知人类介入。超时与回滚为每个子任务设置合理的超时时间。对于有状态的操作如数据库写入要考虑如何回滚一个失败工作流中已成功步骤的影响这通常非常复杂因此要尽量设计无状态或幂等的子任务。5.3 成本与延迟的权衡子代理模式不是免费的午餐。每个子代理都是一次或多次 LLM API 调用成本随着代理数量线性增长。同时串行执行的子代理会引入累积延迟。优化策略包括并行化仔细分析任务依赖图让没有依赖关系的子代理并行执行。例如“生成文档”和“运行单元测试”这两个任务通常可以同时进行。缓存对于确定性较高的子任务如“根据固定模板生成项目脚手架代码”其输出可以缓存起来。下次遇到相同输入时直接使用缓存结果避免重复调用 LLM。使用轻量级模型并非所有子代理都需要 Claude Opus 这样的“重型大脑”。对于格式转换、简单文本提取、基础代码生成等任务使用更小、更便宜的模型如 Haiku可能完全足够能大幅降低成本。任务合并如果两个子代理总是顺序执行且通信开销很大可以考虑将它们合并为一个稍大但更连贯的任务减少一次 LLM 调用和上下文传递的开销。5.4 评估与迭代如何知道你的子代理系统在变好搭建好系统只是开始。你需要一套机制来评估其表现并持续迭代优化。定性评估人工抽查。定期检查最终产出物看是否符合预期。这是最可靠但最费力的方法。定量指标任务完成率有多少比例的工作流能从头到尾无人工干预地跑通平均处理时间从开始到结束的总耗时是多少分解到每个子任务的时间是多少成本消耗每个工作流平均花费多少 API 费用产出质量评分可以设计一些自动化的评分规则。例如对于代码生成任务可以用“编译通过率”、“单元测试通过率”、“代码风格检查得分”作为代理指标。A/B 测试尝试用不同的方式分解同一个任务或者为同一个子任务设计不同的提示词然后对比最终结果的质量和效率。数据会告诉你哪种设计更优。子代理系统的设计是一个持续迭代的过程。从一个小而精的用例开始比如自动生成项目的 README 文件验证整个流程跑通然后逐步增加复杂度扩展到一个模块、一个功能乃至更复杂的项目。在这个过程中你会积累下最适用于你自身业务场景的任务分解模式、提示词模板和错误处理策略这才是最有价值的资产。