过去一年Agent 技术里有两个方向同时快速升温。一个是Multi-AgentManager├── Research Agent├── Planning Agent├── Coding Agent├── Review Agent└── Test Agent另一个是Agent SkillGeneral Agent├── Research Skill├── Coding Skill├── PPT Skill├── RAG Skill├── Review Skill└── Benchmark Skill这就带来一个越来越现实的问题一个复杂任务到底应该增加 Skill还是增加 Agent比如代码开发需要需求分析、架构设计、编码、测试、Review是不是应该拆成 5 个 Agent做一次 Deep Research需要搜论文、搜 GitHub、查产品、查公司、汇总证据是不是定义 5 个 Skill 就够了过去这个问题并没有非常清晰的答案。但如果把 Anthropic 最近几份材料放在一起看会发现他们其实已经逐渐给出了一条非常明确的技术路线Tool 解决 Agent“能做什么”Skill 解决 Agent“应该怎么做”Subagent 解决“什么时候值得单独开一个 Context”Multi-Agent 解决“什么时候值得并行扩展多个 Context”。本文重点结合三份材料《The Complete Guide to Building Skills for Claude》解释 Skill 的结构、Progressive Disclosure、多 Skill 组合与工程实践《How we built our multi-agent research system》解释 Claude Research 为什么选择 Lead Agent Parallel Subagents《A guide to the anatomy of effective commerce agents》Anthropic 在生产级 Commerce Agent 中进一步提出“Skills, not subagents”。把这三份材料串起来会得到一个非常重要的判断Agent 架构正在从“任务复杂就拆 Agent”逐渐转向“先判断 Context 应该共享还是隔离”。这可能才是 Skill 与 Multi-Agent 真正的分界线。一、从 Tool 到 Skill 再到 Multi-AgentAgent 架构到底在解决什么问题理解 Skill 和 Multi-Agent不能从“哪个更高级”开始而应该从 Agent 架构不断遇到的新瓶颈开始。1.1 第一阶段Tool Calling——先让模型能够“做事”早期 LLM 最明显的问题是模型只能生成文本不能真正操作外部世界。于是 Agent 开始拥有LLM │ ├── Search ├── Database ├── Shell ├── Browser └── API后来 MCP 又进一步解决不同 Agent 如何用更统一的方式连接外部工具、系统和数据源这一阶段解决的是What can the Agent do?也就是Action Space。但 Tool 多了以后新的问题出现了。给一个模型GitHubLinearSlackFigmaDrive并不意味着模型自动知道一个设计稿交付研发到底应该先做什么、后做什么、什么时候校验、失败以后怎么办。于是第二层开始出现。1.2 第二阶段Skill——Tool 有了但 Agent 还不知道“应该怎么做”Anthropic 在 Skill Guide 中用了一个非常形象的类比MCP KitchenSkill RecipeMCP 给你厨房、工具和材料。Skill 告诉你这道菜应该怎么做。Anthropic 对二者的区分非常清楚Tool / MCPWhat Claude can doSkillHow Claude should do it所以 Skill 的本质并不是“又一种 Tool”。它更接近Procedural Knowledge——可复用、按需加载的过程性知识。一个典型 Skillmy-skill/├── SKILL.md├── scripts/├── references/└── assets/其中SKILL.md→ 方法、规则、Workflowscripts/→ 确定性执行references/→ 专业知识、协议、规范assets/→ 模板与资源Skill 做的事情本质是General Agent Domain Knowledge Workflow Best Practice Scripts从而让通用 Agent 在需要的时候临时具备某种专业能力。这也是为什么 Skill 的出现并不是为了再造一批“RAG Agent / PPT Agent / PDF Agent / Review Agent”而是为了避免one use case, one agent。1.3 第三阶段Multi-Agent——当一个 Context 已经装不下整个问题如果 Skill 可以让一个 Agent 获得大量专业能力那么为什么 Anthropic 自己又在 Claude Research 中使用 Multi-Agent答案不是Research 比 Coding 更复杂。而是Research 可以被拆成多个相互独立的信息探索空间而每个探索空间都值得拥有自己的 Context。Anthropic 的 Research 架构可以抽象成Lead Agent │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Subagent A Subagent B Subagent C │ │ │ Context A Context B Context C │ │ │ Search Search Search Think Think Think Retry Retry Retry │ │ │ └──────────────┼──────────────┘ ▼ Summary │ ▼ Lead Agent每个 Subagent 拥有自己的ContextSearch TrajectoryTool Calls中间结果失败重试局部判断。最终只把压缩后的高价值结果交给 Lead Agent。所以 Multi-Agent 真正 Scale 的并不只是“角色数量”而是Parallel Context WindowsParallel Token BudgetParallel Tool Calls换句话说Skill 是 Context ExtensionSubagent 是 Context IsolationMulti-Agent 是 Parallel Context Scaling。1.4 第四阶段Hybrid Agent——未来不是 Single-Agent 和 Multi-Agent 二选一如果把 Anthropic 最近几年的路线串起来会发现技术演进并不是Single Agent ↓Multi-Agent ↓More Agents ↓More More Agents而更像LLM ↓Tools ↓Workflow ↓Agent Loop ↓Skills ↓Context Engineering ↓Selective Subagents ↓Adaptive Multi-Agent也就是说复杂度是在真正需要的时候逐层增加。未来更合理的架构很可能是Main Agent │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ Progressive Adaptive Tools Skills Subagents │ │ ▼ ▼ Long-tail Parallel Context Capability Scaling │ ▼ Artifact / Memory │ ▼ Harness重点不再是“到底单 Agent 还是多 Agent”而是当前问题应该扩展能力、扩展 Context还是扩展并行计算二、Skill 解决什么问题什么时候“多能力”仍然应该留在一个 Agent 里Skill 最容易被误解成“小型 Agent”。但 Anthropic 的 Skill Guide 其实给出了一个非常明确的边界Skill 的核心不是独立决策主体而是按需进入当前 Agent Context 的 Procedural Knowledge。2.1 Skill 真正重要的不是 SKILL.md而是 Progressive Disclosure假设系统里已经有 100 个 SkillRAGvLLMRayPythonJavaPPTPDFResearchBenchmarkSecurity...最简单但最糟糕的方式是Agent 启动 ↓把 100 个 Skill 全部塞进 Context结果就是Context Explosion↓Token Cost ↑↓Attention Dilution↓Latency ↑↓Skill Selection Accuracy ↓所以 Anthropic 设计了三级 Progressive Disclosure。Level 1只暴露 Metadata例如name: code-reviewdescription: Review code changes for bugs,security issues and regressions.Use when...模型只需要知道系统里有这个 Skill它大概解决什么问题。Level 2真正需要时加载 SKILL.md模型判断当前问题需要 Code Review才加载code-review/SKILL.md完整的方法、规则和流程才进入 Context。Level 3再按需加载 Reference / Script / Asset例如code-review/├── SKILL.md├── references/│ ├── security.md│ └── performance.md└── scripts/ └── check.py只有真正需要 Security Review 时才继续读取security.md所以 Skill 本质上是一种Context Placement Strategy不把所有知识永久放在 Context而是在需要时动态装载。2.2 多步骤 Workflow不代表需要 Multi-Agent这是 Skill Guide 给出的第一个很重要的信号。Anthropic 明确列出了多种 Skill PatternSequential WorkflowMulti-MCP CoordinationIterative RefinementContext-aware Tool SelectionDomain-specific Intelligence。这意味着步骤很多本身不是拆 Agent 的理由。例如创建客户 ↓创建支付方式 ↓验证支付 ↓创建订阅 ↓发送欢迎邮件这里已经包含Step DependencyValidationError HandlingRollback。但它依然完全可以被建模成One Agent │ └── Customer Onboarding Skill │ ├── create_customer() ├── setup_payment() ├── validate() ├── create_subscription() └── send_email()所以Step 多≠Agent 多2.3 多 MCP也不代表需要 Multi-Agent例如Figma ↓Drive ↓Linear ↓Slack完成一次设计 → 研发交付。更合理的抽象是Design Handoff Skill │ ├── Figma MCP ├── Drive MCP ├── Linear MCP └── Slack MCP而不是Figma Agent ↓Drive Agent ↓Linear Agent ↓Slack Agent所以Tool 多≠Agent 多MCP 多≠Agent 多2.4 Generate → Review → Refine也未必需要三个 Agent现在很多 Multi-Agent 架构喜欢设计Writer Agent ↓Reviewer Agent ↓Revision Agent但如果 Review 本身只是检查格式检查完整性检查是否遗漏判断是否满足某些确定性规则那么完全可以使用Generate ↓Validate ↓Find Issues ↓Refine ↓Validate ↓Repeat甚至如果 Validation 可以代码化更合理的是scripts/check_report.py而不是再调用一个 LLM。于是可以得到一个非常重要的复杂度递增原则能代码解决 ↓不要交给 LLM能 Tool 解决 ↓不要做 Skill能 Skill 解决 ↓不要急着拆 Agent2.5 Commerce Agent 为什么是“Skills, not subagents”Anthropic 最新的 Commerce Agent 文章把这件事讲得更直接。Commerce 看起来包含很多领域SearchComparePlanningCartCheckoutCustomer CareMemory第一反应很容易设计成Intent Router │ ┌───┼────────────┐ ▼ ▼ ▼Search Cart RefundAgent Agent Agent但 Anthropic 在生产实践里反而强调Skills, not subagents。原因是 Commerce 是一个典型的Strong Context Coupling场景。例如用户说刚才第二个酒店不错有没有便宜一点的最好还是靠近机场。如果合适的话把之前那个换掉。Agent 要完成这个任务需要同时知道Conversation HistoryPrevious Search ResultsUser PreferenceCurrent ItineraryCurrent CartStaged Changes如果拆成Main Agent ↓Hotel Agent ↓Main Agent ↓Cart Agent ↓Main Agent每一次 Handoff 都要重新传递状态。Anthropic 把这种操作称为state-lossy operation因为它既可能丢失状态也会增加 token 和延迟。因此Main Agent │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Search Skill Care Skill Planning Skill反而更加合理。2.6 所以Skill 最适合什么任务如果一个任务满足下面这些特征优先考虑 Skill大量步骤共享同一个上下文后一步高度依赖前一步只是专业知识不同只是 Tool 或 MCP 不同Workflow 很长但流程整体仍然属于一个责任域需要循环优化但不要求独立认知视角需要持续保留用户状态、业务状态或 Repo 状态。典型场景包括CodingCoding Agent├── architecture Skill├── codebase-analysis Skill├── Python Skill├── testing Skill└── code-review SkillRAG PipelineRAG Agent├── Parse Skill├── Retrieval Skill├── Rerank Skill└── Evaluation Skill企业业务流程One AgentWorkflow SkillsMulti-MCP AutomationOne AgentMulti-MCP Coordination Skill2.7 但 Skill 也不是无限扩展的Skill 同样有自己的 Scaling Problem。如果SKILL.md 太大同时 Enable 太多 Skills没有 Progressive Disclosure一样会造成Large Context Issues所以大量 Skill 场景需要继续演进Skill Registry │ ▼ Candidate Selection │ ┌────────┼────────┐ ▼ ▼ ▼ Skill A Skill B Skill C │ ▼ Progressive Load未来 Skill Engineering 本身会包含Skill DiscoveryTrigger AccuracySelective EnablementSkill PackSkill EvalContext Budget。换句话说Multi-Skill 不是“无限把 Skill 往 Agent 身上挂”而是一个需要独立治理的 Context Routing 系统。三、Multi-Agent 解决什么问题什么时候值得为一个任务创建新的 Context如果 Skill 可以解决长 Workflow、多 Tool、多 MCP甚至 Iterative Refinement那么 Multi-Agent 到底什么时候才真正值得Anthropic 的 Multi-Agent Research 给出了最清楚的答案当一个问题可以拆成多个相对独立的信息空间并且这些空间值得并行探索时。3.1 Research 为什么是 Multi-Agent 的天然场景Research 最大的特点是Breadth-first。例如调研 30 家 AI Coding 公司。单 Agent公司 A ↓公司 B ↓公司 C ↓... ↓公司 Z大量工作只能串行完成。Multi-AgentLead │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Agent A Agent B Agent C 公司1~10 公司11~20 公司21~30不同 Agent 可以在彼此独立的 Context 中同时完成搜索阅读筛选重试分析总结。最终 Lead Agent 只拿到高价值压缩结果。3.2 Multi-Agent 的核心不是“群体智慧”而是 Parallel Context Scaling很多人会把 Multi-Agent 理解成多个 AI 专家讨论以后会产生更好的答案。但 Anthropic 的 Research 实践揭示了一个更工程化的事实Multi-Agent≈Parallel Context WindowsParallel Token BudgetParallel Tool Calls单 AgentContext │ ▼ Search Trajectory AMulti-AgentContext A Context B Context C │ │ │ ▼ ▼ ▼ Trajectory A Trajectory B Trajectory C │ │ │ └───────────────┼───────────────┘ ▼ Synthesis所以 Multi-Agent 的核心价值是把单 Context 的推理和搜索带宽扩展成多个 Context。这就是为什么 Deep Research、竞品分析、多 Repo 调研这类任务非常适合 Multi-Agent。3.3 Context Isolation 才是真正的 Agent Boundary假设一个 Research 子任务需要搜索 30 次读 10 篇论文打开 8 个 GitHub Repo写 Python 验证失败几次重新搜索可能产生几十K甚至更多临时 Context。Main Agent 根本不需要这些全过程。它只需要ConclusionEvidenceSources所以Main Context │ ▼Research Subagent │ ├── huge context ├── search ├── code ├── retry └── exploration │ ▼ Compression │ ▼ Main Agent这时候 Subagent 才真正有价值。因此一个非常实用的问题是这个子任务是否值得单独拥有一个 Context Window如果答案是否定的大概率不需要新 Agent。3.4 Conversation Ownership 什么时候应该真正切换Anthropic 的 Commerce Agent 文章还给出了另一个很有价值的判断Conversation Ownership。可以把三种模式区分开。Skill能力变化但主 Agent 始终拥有对话User ↓Main Agent ↓Skill ↓Main Agent ↓UserDelegated Subagent任务委派但主 Agent 仍然拥有对话User ↓Main Agent ↓Research Agent ↓Main Agent ↓UserHandoff责任主体真正发生变化User ↓General Agent ↓Financial Agent ↓User ↓Financial Agent例如PharmacyFinancial ServicesLegalSecurity Operations。如果一个领域拥有独立 Compliance独立 Policy独立 Tool独立权限独立 Agent Loop那么它已经不只是一个 Skill而是一个真正的 Agent Responsibility Boundary。因此可以总结为能力变化→ Skill任务委派→ Subagent责任主体变化→ Handoff3.5 独立判断什么时候值得一个新 AgentReviewer 是一个很典型的灰色区。如果只是检查代码风格测试覆盖常见 bugAPI 是否满足规范那么Code Review Skill往往已经足够。但如果你的目标是Reviewer 必须避免受到 Coder 原始假设、推理路径和实现偏好的影响。那就应该Coder Context │ ▼ Diff │ ▼Reviewer Fresh Context这时候 Reviewer Agent 的价值来自Fresh Context Independent Judgment。不是因为“Reviewer 是另一个角色”。3.6 权限边界和安全边界也可以形成 Agent Boundary例如Code Agent→ Repo Read / WriteProduction Agent→ Deploy PermissionSecurity Agent→ Read Only这时 Agent Boundary 已经不仅仅是 Prompt Boundary而是Permission BoundarySecurity BoundaryExecution Boundary这种情况下使用 Multi-Agent往往比把所有能力继续塞进同一个超级 Agent 更合理。3.7 Multi-Agent 的成本不能忽略Anthropic 在 Research 系统中观察到相比普通 ChatAgent 和 Multi-Agent 都会显著增加 token 使用。所以Multi-Agent 效果更好绝不等于默认 Multi-Agent正确的判断应该是Multi-Agent 带来的 Value Token Latency Coordination Debug Cost Failure Risk只有当左边明显更大Multi-Agent 才值得。3.8 为什么 Coding 默认并不适合无限拆 AgentAnthropic 在 Multi-Agent Research 文章里专门指出需要所有 Agent 共享同一 Context或者 Agent 之间强依赖的任务不是当前 Multi-Agent 最理想的场景。Coding 就是典型例子。很多 Coding 任务是理解代码 ↓修改接口 A ↓导致模块 B 改变 ↓测试失败 ↓重新理解 A / B ↓继续修改其本质是Strong DependencyShared Repository StateShared Context如果强行拆成Architect AgentCoder AgentTester AgentFix Agent很可能大量开销花在Context TransferState SyncHandoffMerge ConflictRe-explanation而不是解决问题本身。所以 Coding 更适合Main Coding Agent Multi-Skill Selective Subagents。四、工程选型什么时候用 Skill什么时候用 Multi-Agent真正做 Agent 架构时不应该问这个任务复杂不复杂而应该问这个任务的复杂性到底来自能力、流程、Context还是并行搜索空间4.1 第一判断维度Context Coupling这是最重要的维度。Context Coupling 高 │ ▼Single Agent SkillsContext Independence 高 │ ▼Subagent / Multi-Agent例如强 ContextCoding订单处理旅游规划文档生成长业务 Workflow。更偏 Skill。弱 Context多公司调研多 Repo 调研多论文搜索多市场并行研究。更偏 Multi-Agent。4.2 第二判断维度Parallelizability任务是不是可以真正并行例如收集数据 ↓分析数据 ↓生成报告 ↓检查 ↓修订虽然步骤多但后一步依赖前一步。这是Sequential Dependency更适合 Skill / Workflow。而调研 LangGraph调研 AutoGen调研 CrewAI调研 OpenAI Agents SDK调研 Claude Agent SDK彼此可以独立完成。这是Parallel Exploration更适合 Multi-Agent。4.3 用二维矩阵做第一轮选型可以把两个最核心的维度组合起来并行价值低并行价值高Context 强耦合Single Agent Multi-SkillHybrid谨慎拆分Context 弱耦合Single Agent / Single SubagentMulti-Agent第一象限强 Context 低并行典型Coding订单处理文档生成Multi-MCP WorkflowRAG Pipeline。优先Single AgentMulti-Skill第二象限弱 Context 高并行典型Deep Research竞品调研多 Repo 分析多论文调研多家公司分析。优先Lead AgentParallel Subagents第三象限强 Context 高并行这是最难的一类。例如大型软件工程FrontendBackendInfraAI表面上可以并行但又共享API ContractRepositoryArchitectureState。这时候不要简单拆十个 Agent。更合理的是Main Coding Agent │ ┌─────────┴─────────┐ ▼ ▼ Research Subagent Review Subagent │ Independent Context也就是核心状态留在主 Agent只把真正可隔离的部分委派出去。4.4 六个问题快速判断要不要 Multi-Agent实际工程评审时我建议问六个问题① Context 是否可以隔离② 子任务是否可以真正并行③ 是否需要独立判断④ 是否存在权限边界⑤ 是否存在独立责任域⑥ 子任务是否会产生大量临时 Context每满足一项1可以粗略得到0~1→ Single Agent Skill2~3→ 考虑 Delegated Subagent4~6→ Multi-Agent 很可能值得这不是 Anthropic 官方公式而是一种基于上述工程原则整理出来的 heuristic。4.5 一个更完整的选型表判断问题更偏 Skill更偏 Multi-Agent是否共享大量 Context是否子任务是否强依赖是否是否只是专业知识不同是不一定是否只是 Tool 不同是否是否只是 Workflow 很长是否是否需要大量独立搜索否是是否能高度并行否是是否需要独立 Context Window否是是否要求独立判断可选是是否存在权限隔离否是是否需要接管用户对话否是子任务会产生大量临时 Context否是Coordination Cost 是否低—是Task Value 是否能覆盖额外成本—是4.6 最常见的两个 Multi-Agent 反模式反模式一One Agent per Domain例如Manager├── RAG Agent├── Python Agent├── PDF Agent├── PPT Agent├── Git Agent├── Search Agent├── SQL Agent├── Test Agent└── Review Agent看起来非常 Agentic。但很多所谓 Agent 其实只是“我知道一种专业方法。”这种更适合Engineering Agent├── RAG Skill├── Python Skill├── PDF Skill├── Search Skill└── Review Skill否则会产生大量RouterHandoffContext CopyPrompt状态同步。反模式二One Agent per Step例如Parse Agent↓Chunk Agent↓Embedding Agent↓Retrieval Agent↓Rerank Agent这不是 Multi-Agent。这是PipelineAgent 至少应该具备GoalDecision LoopContextAutonomy没有这些就不应该因为组件名字后面加了 Agent就把系统变成 Multi-Agent。4.7 Skill 和 Multi-Agent 不是竞争关系而是不同层次的抽象真正成熟的架构应该是Main Agent │ ┌───────────────┼───────────────┐ │ │ │ ▼ ▼ ▼ Skills Subagents Tools │ │ │ Procedural Independent Actions Knowledge Context可以进一步定义ToolPrimitive Action回答能做什么SkillReusable Procedural Context回答应该怎么做AgentGoalContextDecision LoopTools回答谁拥有这个任务的决策过程SubagentIndependent ContextIndependent Trajectory回答哪一部分值得单独开一个推理空间Multi-AgentParallel Context ScalingCoordination回答一个 Context 不够时如何扩展整个系统可以投入的推理与探索能力4.8 最终推荐的复杂度递增路线如果今天让我重新设计一个 Agent 系统我不会从“要不要 Multi-Agent”开始。我会按下面的顺序增加复杂度Prompt ↓ 不够Tool ↓ 不够Workflow ↓ 不够Skill ↓ 不够Single Agent Multi-Skill ↓ 不够Delegated Subagent ↓ 不够Multi-Agent ↓Agent Graph / Orchestrator而不是“这是一个复杂问题先设计十个 Agent。”结语真正成熟的 Agent 架构不是 Agent 越多越好Multi-Agent 很容易让一张架构图看起来高级。Planner、Researcher、Coder、Reviewer、Tester……每个角色都有自己的 Prompt每个 Agent 都有自己的名字再画上一张 Orchestration Diagram整个系统立刻显得非常“Agentic”。但 Agent 系统最终不是比谁的框更多。真正应该问的是为什么这个 Agent Boundary 必须存在如果只是专业知识不同Workflow 不同Tool 不同MCP 不同步骤不同那么答案很可能只是Skill。只有当开始遇到Context 无法共享信息空间可以独立探索任务天然可以并行需要 Fresh Context需要独立权限需要独立责任主体单个 Context 已经成为计算瓶颈才真正应该考虑Subagent / Multi-Agent。所以比“什么时候使用 Multi-Agent”更值得问的问题其实是什么时候值得为一个任务创建新的 Context Window如果答案是“不值得”那大概率不需要新的 Agent。如果答案是“值得而且这些 Context 还能并行工作”Multi-Agent 才开始真正发挥价值。最后可以把整篇文章压缩成三句话Skill 解决能力扩展。Subagent 解决 Context 隔离。Multi-Agent 解决并行 Context Scaling。而 Agent 工程真正成熟的标志也许不是系统里有多少个 Agent而是你知道什么时候根本不应该增加一个 Agent。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】