你以为AI越强越该让它独自搞定一切？Anthropic内部测试发现，让AI"分头行动"反而能把研究任务完成质量拉高90%。
这不是简单的"人多力量大"。当任务复杂到需要调研三个竞品、整合结论、输出报告时，单个大模型会像塞满文件的办公桌——什么都看得见，什么都理不清。子智能体（Subagent，即被主智能体调用的专项AI实例）的本质，是把一张大桌子拆成几张小桌子，每张只放一件事。
一图读懂：子智能体的核心架构
子智能体的设计围绕一个核心矛盾展开：模型能力在膨胀，但上下文窗口的"带宽焦虑"从未消失。你让它同时处理搜索、分析、写作，它会在某一步突然"失忆"——忘了最初要回答什么问题。
Anthropic的解决方案是层级分工。顶层是编排器（Orchestrator），它不做重活，只负责拆任务、派任务、收结果。底层是子智能体，每个拿到的是精简指令包：明确目标、输出格式、可用工具。干完活，交一份摘要，不带走一片云彩。
这种设计的精妙之处在于上下文隔离（Context Isolation）。子智能体在自己的窗口里折腾，只把结论抛给上层，而不是把整个思考过程倒上去。编排器始终清爽，像项目经理只看周报，不参与每行代码的争论。
Claude Agent SDK的文档里，子智能体被赋予两个硬指标：并行化（Parallelization）和上下文隔离。前者省时间，后者保质量。两者叠加，才撑得起那句"比单模型提升90.2%"的内部数据。
三种实战模式：别在流水线上开并联
子智能体不是万能药，用错模式反而添乱。Anthropic梳理了三种典型场景，选错是新手最常见的事故。
第一种是顺序模式（Sequential）。任务有依赖关系，A的输出是B的输入。比如先抓竞品数据，再分析定价策略，最后生成报告。强行并行会让B拿到空指针，编排器只能干瞪眼。
第二种是并行模式（Parallel）。子任务相互独立，各查各的竞品，最后汇总。这时候开并行是真提速，四个子智能体同时跑，理论上四倍效率——当然，API账单也是四倍。
第三种是混合模式（Hybrid）。真实业务往往是乱序：先并行抓三家竞品数据，再顺序执行"分析→撰写"，最后并行做格式检查和翻译。编排器的价值在这里体现：它得读懂任务图，知道哪里能分叉、哪里必须排队。
一个常见反模式是"为了并行而并行"。把本可一步做完的串行任务拆成子智能体，编排开销会吃掉所有收益，最后比单模型还慢。判断标准是：子任务之间有没有数据依赖？没有，再考虑并行。
动手：两种创建方式，殊途同归
Claude Code把子智能体的创建门槛压得很低。两种方式最终都落到一个.md文件，存在.claude/agents/目录下。
交互式最省事。敲/agents create，跟着向导填：名称、描述、可用工具、模型版本、作用范围。填完立即生效，适合快速试错。
手动创建则更可控。直接写markdown，frontmatter（文件头元数据）定义行为，正文写系统提示词。Anthropic的示例里，一个安全审计子智能体长这样：
name: security-reviewer
description: "Expert security reviewer. Use..."
正文部分就是给这个"虚拟专员"的入职培训——什么该查、什么该放过、输出格式是表格还是列表。这种设计把"提示工程"从一次性对话变成了可版本控制的资产。
工具权限是细粒度开关。子智能体可以被允许浏览网页、执行代码、读写文件、调用外部API，也可以被锁死在只读模式。Anthropic的建议是：给最小必要权限。一个只负责查资料的子智能体，没必要拿到生产环境的写权限。
为什么现在谈这个：从玩具到基础设施
子智能体的概念不新，但2024年以来的变化让它从"可做"变成"必做"。
一是模型能力溢出。Claude Opus 4、GPT-4级别的模型，单任务性能已经摸到天花板，但复杂任务的失败模式从"不会做"变成了"做不完"——上下文被中间步骤挤爆，首尾难顾。子智能体是工程层面的补丁，用架构弥补接口限制。
二是成本结构变化。API调用按token计费，长上下文意味着高单价。把大任务拆成小任务，每个子智能体用短提示、窄窗口，总成本可能反而更低——尤其是当多数子任务不需要最强模型时，可以降级到轻量版本。
三是可维护性。单体提示词超过一定长度，调试变成噩梦。子智能体把系统拆成模块，哪个环节出问题，单独拎出来复现。Anthropic内部的研究系统就是这么跑的：主智能体派活儿，子智能体各探一路，最后汇总。
这种架构也在重塑"AI工程师"的工作内容。以前拼的是谁能写更长的提示词，现在拼的是谁能设计更清晰的任务分解图。编排器提示词的质量，直接决定整个系统的天花板。
落地陷阱：那些文档没写的坑
子智能体不是银弹，实际部署有几处暗礁。
第一个是结果合并的复杂度。四个子智能体各交一份报告，编排器怎么消歧、怎么去重、怎么发现矛盾？这需要额外的提示工程，甚至引入第二层子智能体专门做"内容主编"。
第二个是延迟与成本的权衡。并行确实快，但并发API调用有速率限制。任务图设计得太激进，会在云端排队，实际耗时反而不如保守的串行方案。
第三个是调试可视性。子智能体在黑盒里运行，出问题时要能追溯到具体哪个实例、哪一步、原始输出是什么。Claude Code的/agents命令提供了基础列表，但复杂工作流的日志聚合仍是待解难题。
Anthropic的文档里埋了一句实话：子智能体"在其被分配的范围内是主动执行单元"——能浏览、能跑代码、能调API。这意味着它们也会犯错，而且错得更有隐蔽性。一个被派去爬网页的子智能体，可能拿到过时数据却自信满满地返回，编排器如果不做交叉验证，就会把垃圾喂给下游。
行业镜像：不止Claude在玩
子智能体的架构模式正在跨平台扩散。OpenAI的Assistants API支持函数调用链，Google的Vertex AI有类似的Agent Builder，开源生态里CrewAI、AutoGen都在押注多智能体编排。
差异在于工程深度。Anthropic把子智能体做成了文件系统里的一等公民（.claude/agents/下的.md文件），意味着可以版本控制、可以代码审查、可以复用。这比对话历史里的临时配置更贴近生产环境的需求。
另一个信号是岗位描述的变化。LinkedIn上"AI Orchestration Engineer"（AI编排工程师）的出现频率在2024年下半年陡增，JD里明确要求"设计多智能体工作流""优化子任务分解策略"。这不再是研究员的玩具，而是基础设施团队的KPI。
子智能体的本质，是把AI从"更聪明的个体"重新定义为"更可组合的基础设施"。当单模型能力逼近物理极限，架构创新成为新的杠杆点。
Anthropic的90.2%提升数字背后，是一个朴素认知：复杂问题的解法，往往藏在问题的分解方式里。这和人类组织的演进逻辑一致——从手工作坊到流水线，从全能工程师到专业分工，每次跃迁都伴随着协调成本的上升与边际收益的重新计算。
现在的问题是：当你的竞争对手开始用四个子智能体并行调研市场，而你还在等一个"超级模型"搞定一切，谁的迭代速度会更快？更重要的是，当AI系统的复杂度超过人类能直观理解的阈值，我们该如何设计"编排器的编排器"——那个能审核、能干预、能在子智能体集体跑偏时拉闸的最后防线？
热门跟贴