构建智能体：何时将子智能体整合到主智能体循环中

子代理——拥有自己的上下文窗口、工具和指令，并由协调器进行编排的代理——是代理设计的核心组成部分。它们在验证、并行工作和模块化权限管理方面非常有效。我们在使用 Claude Platform 构建的许多自有代理中都采用了子代理，例如我们的多代理研究系统。Subagents – agents with their own context window, tools, and instructions, orchestrated by a coordinator – are a core component of agent design. They are effective at verification, parallel work, and modular permissioning. We use them in many of our own agents that we build using Claude Platform, for example our multi-agent research system.

不过，最近 Applied AI 团队发现了一种企业级智能体部署模式：将路由器、规划器和领域子智能体整合进主智能体循环中，能够带来显著收益。在我们对多个企业级部署方案进行比较时，配备技能的单个智能体在质量方面经常胜过“一条提示词包办一切”的设计和子智能体设计，而且每项任务的成本和延迟往往也更低。However, recently the Applied AI team has found a pattern of enterprise agent deployments that have benefited from folding routers, planners, and domain subagents into the main agent loop. In our comparisons across several enterprise deployments, a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design on quality, and often at a lower cost and latency per task.

例如，一家公司发现，其面向客户的智能体中包含十几个专业子智能体，难以持续维持一致且符合品牌调性的体验，还增加了延迟，损害了用户体验。For example, one company found the dozen of specialist subagents within its customer-facing agent made a consistent on-brand experience difficult to maintain and added latency that hurt the user experience.

我们也经常看到一些拟议中的智能体设计遵循一种熟悉的演进路径：从意图分类器、固定的多步推理流水线、用户分群类别、独立的推荐分支，到顶层的多智能体编排器。We also often see proposed agent designs that follow a familiar progression: an intent classifier, a fixed multi-step reasoning pipeline, user-segment buckets, separate recommendation branches, and a multi-agent orchestrator on top.

在这些情况下，人们通常会反馈说，这套结构中的大部分都在替模型处理它已不再需要别人代劳的工作；一条清晰的系统提示、4 到 5 个轻量级数据工具，以及严格的输出约束，就足以满足大多数使用场景。In these cases feedback is often that most of this structure was doing work the model no longer needed done for it, and that one clear system prompt, 4-5 thin data tools, and firm output guardrails would cover most of the use case.

明确地说，子代理仍然有其用武之地，包括在研究前沿领域。以下情况可以使用它们：To be clear, subagents still have their place, including at the research frontier. Use them when:

• 单个智能体循环因上下文膨胀而出现可测量的性能下降，或
  A single agent loop hits measurable performance degradation from context bloat, or
• 多个任务需要并行处理，并使用任务完成后即可丢弃的新上下文窗口，或者
  Multiple tasks need to be tackled in parallel with fresh context windows that can be discarded once the task is done, or
• 单个智能体难以选择合适的工具，或者系统提示中存在相互冲突的指令。
  A single agent struggles to select appropriate tools or there are conflicting instructions in the system prompt.

但我们经常看到企业为每个团队或问题类型都配置一个专属子代理，结果代理架构变成了组织架构图的翻版（康威定律正在发挥作用）。But too often we see enterprises give each team or problem type its own subagent, with the agent architecture becoming a copy of their org chart (Conway’s law at work).

这篇文章介绍了何时应考虑将子代理整合到主代理循环中，并分享了我们在大型组织中构建代理时总结出的最佳实践。This post explains when to consider folding subagents into your main agent loop with best practices we’ve learned from building agents in large organizations.

大型组织构建智能体时的失败模式Agent building failure modes for large organizations

企业通常希望构建一个智能体，将多种产品和功能整合到统一的客户界面中。Companies often want to build an agent that unites multiple products and capabilities into a single customer interface.

通常，每项能力都由不同的团队负责，因此公司往往会先让各团队自行构建智能体，再由中央平台团队在此基础上构建编排器。这种架构可以有多种形式，包括编排器-子智能体模式，或由单个智能体将特定智能体作为 MCP 工具接入。Typically, each capability is owned by a separate team, so companies start by letting each individual team build their own agent, then a central platform team builds an orchestrator on top. This can take on several structures including orchestrator-subagent or a single agent with specific agents exposed as MCP tools.

这看起来是最简单的解决方案，但会立即引入以下复杂性：This looks like the simplest solution but introduces immediate complexity around:

• 上下文管理：你需要决定代理之间交换哪些上下文信息，而且在来回沟通的过程中往往会丢失细节。
  Context management: You need to decide what context is exchanged between agents and often lose details in the back and forth.
• 子代理泛滥：每个团队都自行发布子代理，导致公司最终拥有数百个功能重叠的子代理，却没有强制执行的标准，也没有明确的负责人。
  Subagent sprawl: Every team ships its own subagent, so companies end up with hundreds of overlapping subagents with no enforced standards and no specific owner.
• 弗兰肯斯坦式提示词：每个团队都往系统提示词里加上一句话，结果规则彼此冲突，整体风格也不统一。
  The Frankenprompt: Every team adds a sentence to the system prompt, resulting in conflicting rules and no consistent voice.
• 未经审核、过度局部化的评测：每个人都添加自己针对子任务过度优化的评测。没人负责维护整个评测集，领导层则根据被稀释且过度局部化的分数做决策。
  Unvetted, overly localized evals: Everyone adds their own evals that are overly optimized for their subtask. No one owns or maintains the whole set, and leadership makes decisions based on watered-down, overly localized scores.
• 延迟：多智能体架构的复杂性会增加延迟。一位客户将其多智能体测试框架与单智能体循环进行评估后发现，后者的运行速度大约快 2 倍。
  Latency: Multi-agent architectural complexity adds latency. One customer that evaluated their multi-agent harness against a single agent loop saw a roughly 2x faster runtime with the latter.

使用渐进式披露的智能体循环Using an agent loop with progressive disclosure

上文所述的编排器—子代理设计，是协调由不同团队构建的专家系统的一种合理方法。不过，通常更有效的做法是通过技能逐步提供上下文，并通过工具搜索逐步提供工具。换言之，代理只会看到技能和工具的简短说明，只有在需要时才会完整加载它们。The orchestrator-subagent design described above is a reasonable approach to coordinating specialists built across teams, but often a more effective approach can be progressively disclosing context via skills and progressively disclosing tools via tool search. In other words, the agent sees short descriptions of the skills and tools, which are fully loaded only when needed.

这种做法有三个合理之处：There are three reasons why this approach can make sense:

• 共享上下文能带来更好的回答：对于需要长期运行的智能体，我们希望将多个不同任务的上下文都放在主上下文窗口中。看过每个先前步骤结果的智能体能够将它们联系起来，从而生成比由子智能体提供一组摘要更丰富的输出和更深入的见解。这也意味着需要的上下文窗口更少，信息损耗更少。
  Shared context produces better answers: for longer-running agents, we want the context from several different tasks to sit in the main context window. An agent that has seen the result of each earlier step can connect them, which leads to richer outputs and better insights than a set of summaries handed back by subagents. It also means fewer context windows and fewer lossy handoffs.
• 渐进式披露可以避免上下文膨胀：这项技术使团队能够构建可完成多种任务的单个智能体，而不必将所有上下文都立即加载到一条冗长的系统提示词中。这消除了团队此前将工作分配给子代理的主要原因。事实上，我们将 Claude Code 面向更高级模型的系统提示词缩短了 80% 以上，其中包括与逐步披露技能和工具相关的精简。
  Progressive disclosure prevents context bloat: this technique allows teams to build single agents that can accomplish a wide variety of tasks without requiring all of the context to be immediately loaded into one long system prompt. This removes the main reason teams previously split work across subagents. In fact, we reduced Claude Code’s system prompt for more advanced models by over 80% which included cuts related to progressively disclosing skills and tools.
• 模型的能力更强了：从 Opus 4.5 开始，模型在单个循环中能够处理的事情远超大多数团队的预期。你无法关闭 Opus 5.5 和 Fable 5.1 的思考功能，而且近期的模型越来越会在执行过程中叙述进度并检查自己的工作，因此一些 harness 组件变得多余。每个新模型都让你能够把更多决策从 harness 转移到模型本身。更简单的循环也更容易迁移到下一代模型；在我们协助客户进行的迁移中，僵化的多智能体结构往往会阻碍新模型承担更多工作。
  Models are more capable: starting with Opus 4.5, models became capable of managing far more in a single loop than most teams expected. You cannot turn off thinking on Opus 5.5, and Fable 5.1, and recent models increasingly narrate their progress and check their work as they go, which makes some harness elements redundant. Each new model lets you move more of the decision-making out of the harness and into the model itself. A simpler loop is also easier to move to the next model; in migrations we have helped customers with, rigid multi-agent structures were often what stopped the new model from doing more of the work.

单智能体循环设计需要严谨：精心管理系统提示词，确保技能和工具描述能在恰当时机触发，并有意识地处理上下文窗口、记忆和笔记。本文将在后续章节深入探讨迁移和设计方面的考量。The single agent loop design requires discipline: a carefully managed system prompt, skill and tool descriptions that trigger at the right times, and deliberate handling of context windows, memory, and note-taking. This article goes deeper into migration and design considerations in subsequent sections.

应由一个核心团队端到端负责质量和系统提示词，并在每个新工具和评测上线前进行审核。精简核心团队有助于加快迭代，并降低大型组织中的协调成本。One central team should own end-to-end quality and the system prompt, vetting every new tool and eval before it ships. Keeping that central team small helps iteration move quickly and lowers coordination cost across a large org.

如果采用多智能体方案，请从能够奏效的最简单模式入手（生成器-验证器、编排器-子代理，或其他模式）。通过按上下文划分任务，合理拆分边界：给每个子代理分配一项对系统其他部分依赖很少的工作，并让它返回简洁的结果（适合的任务包括彼此独立的研究方向、接口清晰的独立组件，或黑盒验证）。如果按问题类型拆分智能体，它们就会陷入“传话游戏”，每次交接都会导致信息保真度下降。If you go the multi-agent route, start with the simplest pattern (generator-verifier, orchestrator-subagent, or other) that could work. Decompose boundaries effectively by dividing by context: give each subagent a piece of work that needs little from the rest of the system and have it hand back a compact result (good candidates are independent research paths, separate components with clean interfaces, or black-box verification). When agents are split by problem type, they engage in a "telephone game," passing information back and forth with each handoff degrading fidelity.

如何将子代理整合到主代理循环中How to fold subagents into the main agent loop

许多团队已经在生产环境中部署了一个编排器和一组专业智能体。我们建议逐步采用以下单循环设计：Many teams already have an orchestrator and a set of specialist agents in production. The following is the single loop design we'd suggest working toward:

• 一个模型和一个上下文窗口运行开放式工具循环，并由工具框架设置限制（轮次和成本预算、写入门槛）。
  One model and one context window running an open-ended tool loop, with limits (turn and cost budgets, write gates) set in the harness.
• 每一轮中，模型都会发出一批工具调用。执行框架会并行运行这些调用，并将原始结果返回给同一个模型，由它决定下一步：发起另一批调用、向用户提问，或给出答案。
  Each turn, the model emits a batch of tool calls. The harness runs them in parallel and returns raw results to the same model, which decides the next step: another batch, a question to the user, or an answer.
• 循环会在模型作答或达到预算上限时停止。回答后还可以选择运行目标检查或验证器检查。
  The loop stops when the model answers or hits a budget. A goal or verifier check can optionally run after the answer.
• 模型会在第一轮中将计划写入上下文，并随着结果陆续返回而修订计划。这是与编排器和专业代理设置相比的主要变化：制定计划的模型也会亲自执行计划，因此可以在一轮对话中途调整计划。
  The model writes its plan in context on the first turn and revises it as results arrive. This is the main change from the orchestrator and specialist agents setup: the model that writes the plan is also the one carrying it out, so it can change the plan mid-turn.
• Context still gets loaded, and is managed by the agent itself:
  • A code step that rewrites the plan from a catalog of rules is no longer needed, since the model decides each step.
  • Ordering and domain procedure move into skills.
  • Hard limits (validation, approval gates) and anything else that comes up mid-conversation (e.g. memory lookup) move into the tools.
  • Code can still be used to load anything cheap and almost always relevant (e.g. an entity resolution step), and to handle any mechanical parts (payload construction, stream parsing, resuming a clarification) inside tools the loop calls.

这种单循环设计也有助于实现许多团队正在努力达成的最终目标（打造一个能够理解用户高层次目标并代其采取行动的智能体），因为它能将智能体学到的所有内容保留在同一个上下文中。This single loop design also helps with the end state many teams are working toward (an agent that understands a user's high-level goals and acts on their behalf), since it keeps everything the agent has learned in one context.

以下建议说明了一个团队如何分阶段从多智能体系统过渡到单智能体循环，以及多个团队如何在此过程中持续为该智能体贡献力量。The suggestions below are how a team could get from a multi-agent system to a single agent loop in stages, and how several teams can keep contributing to that agent along the way.

任务完成评估Task-completion evals

第一步是创建一个评测集，帮助你判断是否应该将子代理整合到主代理循环中。我们发现，一种有效的评测结构是：由中央团队维护一套共享的端到端评测集，同时由各技能的负责团队随技能一并提供规模较小的评测集。即使只有 10 个黄金示例，也足以起步。The first step is to create an eval set that can help you determine whether you should fold a subagent into the main agent loop. The eval structure we’ve seen work is one shared end-to-end set owned by a central team with smaller eval sets shipped with each skill by the team that owns it. Even a set of 10 golden examples is enough to start.

根据评分标准对智能体的最终消息进行评分，是追踪回答质量的良好起点。如果仍然使用编排器，也应追踪路由准确性（它是否选对了子智能体？）。如果某个子智能体已被整合进来，则应改为检查智能体是否加载了正确的技能或调用了正确的工具。随着时间推移，逐步开展任务完成度评估会很有帮助，因为这在比较不同架构时最为重要。Grading the agent's final message against a rubric is a good starting point for tracking answer quality. While you still have an orchestrator, you should also track routing accuracy (did it pick the right subagent?). Once a subagent is folded in, check instead whether the agent loaded the right skill or called the right tool. Working toward task-completion evals over time is helpful as this matters most when comparing architectures.

在内部系统难以重放、用户参与情况难以模拟的环境中，这可能会很复杂。我们在内部采用过一种行之有效的方法：记录重要事件的时间戳，以便之后重放这些事件，开展有针对性的评估。This can be complex in environments where internal systems are difficult to replay and user engagement is difficult to simulate. One approach that has worked for us internally is to record timestamps on important events, so they can be replayed later to run as targeted evals.

逐步减少子代理数量Reducing subagents over time

向单一智能体循环演进，需要将子智能体整合为工具和技能。可以通过合并领域子智能体、将其作为工具调用，或用技能和工具取代它们来实现。Evolving toward a single agent loop involves folding the subagents into tools and skills. This can be done by merging domain subagents, calling them as tools, or replacing them with skills and tools.

组合领域代理Combining domain agents

在首次合并前，先构建一个小型端到端评估。然后根据共享上下文逐步整合，先从使用最多的子代理开始。Build a small end-to-end eval before the first merge. Then fold in by shared context starting with subagents that have the most use.

合并那些会基于彼此的输出继续处理、会触及相同数据，或经常被一同调用的专家。例如，如果很大一部分生产流量会先经过一个专家，再经过另一个专家，那么这就是一对紧密耦合的专家，可以考虑将其合并为一个领域智能体。Merge specialists that chain on each other's output, touch the same data, or are often called together. For example, if a significant share of production traffic is one specialist followed by a second, that is a tightly coupled pair, which makes it a candidate to merge into one domain agent.

作为工具调用的子代理Subagents called as tools

当上述三个条件之一适用且你保留了一个子代理时，让主代理将子代理作为工具调用，使其能够继续与用户对话，可能会很有效。When one of the three conditions above applies and you keep a subagent, it can be effective to have the main agent call subagents as tools so it can continue holding the conversation with the user.

只有在子代理需要直接与用户对话时，我们才建议完全移交，由子代理接管对话。其他所有情况都可以通过在主循环中使用技能和工具来处理。We’d only recommend a full handoff, where the subagent takes over the conversation, when it needs to talk to the user directly. Everything else can be a skill plus tools in the main loop.

这样，你就可以为子代理定义一个共享的响应架构，让主代理根据真实数据验证结论，并精简输入，以便进行最终综合。这是一个很好的第一步，因为你无需重写子代理。它还能为任务完成度评估提供一个基线，之后你再决定是否将某些子代理并入主代理。This will allow you to define a shared response schema for subagents, verify the conclusion against real data with the main agent, and trim the input to any final synthesis step. This is a good first step, as you don’t need to rewrite the subagents. It also gives you a baseline on the task-completion eval before deciding to fold any subagents into the main agent.

不过，某些故障模式仍将存在：However, some failure modes will remain:

• 每位专家都有自己的提示词、上下文、所属团队和评估项。
  Each specialist has its own prompt, context, owner team, and evals
• 每次调用返回的仍然是有损摘要。
  Each call still hands back a lossy summary
• 每次调用都是一个嵌套的模型循环，会增加延迟。
  Every call is a nested model loop that adds latency

通过技能和工具将子代理整合到主代理中Folding subagents into the main agent via skills and tools

逐个将子代理整合到主代理中：把每个子代理的提示词转化为技能，把 API 调用转化为 MCP 工具。比较启用和不启用该子代理时的评测表现，然后决定是否保留它。Fold subagents into the main agent one at a time by turning each one’s prompts into skills and API calls into MCP tools. Compare eval performance with and without the subagent. Then decide which to keep.

比较时，不要只看最终得分，也要看看哪些任务的结果发生了变化。我们在一个示例客服代理上进行测试时，将一个子代理合并到另一个子代理中降低了延迟，但也破坏了一个原本能够通过的流程。主代理掌握着订单查询工具，并自行作答，没有询问配送专员交货日期。When you compare, don’t just examine the final score, take a look at which tasks flipped. When we tested this on a sample support agent, folding one subagent into another lowered latency, but also broke a process that had been passing. The main agent was holding the order lookup tool and answering on its own, without asking the shipping specialist for the delivery date.

每次进行更改之前，请确保你的评估中涵盖生产环境中协同运行的每条智能体链，以及智能体必须遵守的每条规则；并且每项任务都要运行不止一次，因为像这次这样的故障，两次运行中只出现了一次。Before each change, make sure your eval has a task for every chain of agents that runs together in production and for every rule the agent must not break, and run each task more than once, since a break like this one only showed up in one run out of two.

多个团队如何为单个智能体做出贡献How several teams can contribute to a single agent

领域推理可以从知识库、技能和 MCP 工具中获取。各个团队可以将负责范围从智能体转移到技能和工具上，同时由一个小型中央团队继续负责系统提示词和端到端质量。这包括在新技能、工具和评测上线前对其进行审核。Domain reasoning can be retrieved from knowledge bases, skills, and MCP tools. Individual teams can shift their ownership from agents to skills and tools, with one small central team keeping ownership of the system prompt and end-to-end quality. This involves vetting new skills, tools, and evals before they ship.

MCP 工具MCP tools

当智能体需要执行操作、从系统中读取实时数据，或以固定格式返回结果时，工具是最合适的选择。在迁移过程中，你也可以通过工具持续调用子智能体。我们建议按用户意图对工具进行分组（而不是每个 API 对应一个工具），因为系统提示中的工具定义一旦超过 30–50 个，工具选择的效果往往会下降。Tools are the right fit when the agent needs to take an action, read live data from a system, or return a result in a fixed shape. You can also use tools as a way to keep calling subagents while you migrate. We recommend tools grouped by user intent (not one tool per API) because once you exceed 30-50 tool definitions in the system prompt, tool choice tends to degrade.

使用支持延迟加载的工具搜索，尽量减少硬性前置条件，并将必要条件移至工具中。例如，如果 Y 需要 X 的输出，Y 的工具就检查是否存在该输出，并返回一条模型可以据此采取行动的指令。用户权限也采用相同方式处理。每个工具都会检查调用用户可以查看或执行的内容，并返回模型可读的普通拒绝信息，因此，同一个循环就能服务权限各不相同的用户，无需为每个权限级别单独配置代理。Use tool search with deferred loading, limit hard preconditions, and move any needed ones into the tools. For example, if Y needs X's output, Y's tool checks for it and returns an instruction the model can act on. Per-user permissions work the same way. Each tool checks what the calling user may see or do and returns a plain refusal the model can read, so one loop can serve users with different access without a separate agent per permission level.

技能Skills

当智能体需要了解团队的工作方式时，技能就是合适的选择，例如了解工作步骤、规则，以及原本由专业子智能体提示词承载的判断准则。Skills are the right fit when the agent needs to know how a team does work, like the steps, rules, and judgment calls a specialist subagent's prompt used to hold.

我们扩展技能库的方法，是将维护工作交还给编写技能的人。Claude 可以借助能够构建、测试和精简其他技能的技能，承担繁重的工作。Our approach to growing skill libraries is to give the maintenance work back to the people writing the skills. Claude can do the heavy lifting with skills that can build, test, and prune other skills.

为避免技能泛滥，可以由各团队的直接负责人（DRI）管理本团队的技能，并确保这些技能经过精心设计、彼此区分，且随附适当的评估。To prevent skill sprawl, you can have DRIs per team own their skills and make sure they are well crafted, distinct, and shipped with appropriate evals.

• /skill-creator 可帮助你编写结构完善的新技能，并审查现有技能，以精简、去重和重组内容。
  /skill-creator allows you to author new skills that start well-formed, and audit existing ones to trim, deduplicate, and restructure them.
• /skill-doctor 可让你查看技能库中每项技能的成本和实际使用频率，并删除无用的技能。
  /skill-doctor allows you to see what each skill in your library costs and how often it’s actually used, and delete dead weight.

知识库Knowledge bases

对于代理并非每次都需要的参考资料，知识库是合适的选择。事实和参考资料（政策、指标定义、产品规格）可以存放在模型调用的搜索或查询工具中，也可以作为参考文件放在某项技能中。避免让代码检索这些上下文并将其粘贴到提示中。Knowledge bases are the right fit for reference material the agent only needs some of the time. Facts and reference material (policies, metric definitions, product specs) can sit behind a search or lookup tool the model calls, or ship as reference files inside a skill. Avoid having code retrieve and paste this context into prompts.

加速这项工作的工具Tools to accelerate this work

我们最近发布了一套 Claude API 技能，可以帮助完成上述大部分工作。我们的迁移工具包将这些技能整合到一个引导式工作流中，用于评估多智能体系统并将其迁移到单智能体循环。它还包含一个演示，你可以先试用，再在实际项目中运行：We recently released a set of Claude API skills that can help with most of the work mentioned above. Our migration kit chains these skills together in one guided workflow for assessing and moving multi-agent systems to a single agent loop. It includes a demo you can try before running it on the real thing:

• /claude-api build-eval：可以帮助创建首套由中央团队负责的端到端评测集，或由各团队随其技能一同交付的小型评测集。
  /claude-api build-eval: can help create a first end-to-end set owned by the central team or small evals each team ships with its skill
• /claude-api prompt-audit：可以标记提示词、技能和工具描述中为旧版模型编写的指令，并以差异形式提出修复建议。你可以用它检查系统提示词，找出为早期模型添加、如今却让智能体运行变慢或变得更僵化的规则。每个团队的 DRI 也可以用它检查各自的技能和工具描述。
  /claude-api prompt-audit: can flag instructions written for older models in your prompts, skills, and tool descriptions and propose fixes as a diff. This can be run on your system prompts to find any rules that were added for an earlier model and are now making the agent slower or more rigid. Each team's DRI can also run it on their own skills and tool descriptions.
• /claude-api hillclimb：可以针对现有评测迭代改进应用。这既可用于“合并与保留”的对比（将一个子代理合并为一项技能和一些工具后，让它迭代改进技能和工具描述，看看合并后的版本是否能达到或超过该子代理的表现），也可用于改进你的系统提示词。
  /claude-api hillclimb: can iteratively improve an app against an existing eval. This can be used for the "folded in vs kept" comparison (after folding one subagent into a skill plus tools, let it iterate on the skill and tool descriptions and see if the folded version matches or beats the subagent), as well as your system prompt.
• /claude-api cost-optimize：分析调用成本的去向，并逐项提出节省成本的方案，例如启用提示缓存、删减不必要的输入和输出 Token、调整 effort 和模型选择。这有助于降低特定设计的成本和延迟。
  /claude-api cost-optimize: profiles where your calls go and proposes savings from options such as prompt caching, trimming unneeded input and output tokens, effort, and model choice, one change at a time. This can help bring cost and latency down on a given design.

随着模型不断演进，我们对如何最好地使用它们的理解，以及关于最佳实践的指导也会随之演进。因此，任何一种架构都不如其背后的原则重要：进行测量，一次只改变一件事，并保留经得起检验的做法。As models evolve, our understanding of how to best use them and guidance around best practice evolve as well. That makes any one architecture less important than the principle behind it: measure, change one thing at a time, and keep what holds up.

这是其中一种情况。随着模型能力越来越强、智能体运行时间越来越长，你的更多子智能体可以变成技能和工具。不过，你不必一步到位。先构建一个小型端到端评估，将一个子智能体整合进去；只有当整合后的版本表现更差时，才保留它作为子智能体。然后重复这个过程。This is one of those cases. As models get more capable and agents get longer running, more of your subagents can be skills and tools. You don’t have to make that move in one step, though. Build a small end-to-end eval, fold in one subagent, and keep it as a subagent only if the folded version scores worse, then rinse and repeat.