如何在技能与子代理之间做出恰当的选择

在 Azure 最近的一篇架构博文中，Azure 首席工程师 Kishorekumar Pattabiraman 概述了在构建 AI 系统时， 在技能、子代理和其他方法之间进行选择的实用标准 "，并强调了可复用性、简洁性和长期可维护性。 据 Pattabiraman 介绍，团队往往从错误的问题入手，只关注应该使用哪种模型。然而，“第一个真正的抉择”并非模型，而是架构： 你是在构建技能还是子代理？如果搞错了，无论选择哪种模型都无济于事。技能和子代理是两种不同的实现形式，各自都无法胜任对方的任务。 技能在持续进行的对话中运行：它可以读取文件、提出问题、与用户进行交互，并在整个过程中让用户始终参与其中。相比之下，子代理则接收单个提示词，独立运行直至完成，并输出最终结果。Pattabiraman 指出，两者各有其适用的场景，具体使用哪个取决于任务的性质。 为了决定是构建技能还是子代理，Pattabiraman 强调了四个需要考虑的关键维度：迭代模型、语音保真度、人工干预点以及任务的重复频率。 在这四个维度中，频率是界限最为分明的区分因素：“一次性手工制品更倾向于技能，而可重复的批量工作则更倾向于子代理”。其他因素则需要更审慎的考量。例如，人们很少是在“完全交互式的对话”与“简单的任务交接”之间进行选择，因此需要进行两方面的权衡：一方面是让人类参与基于技能的迭代流程所产生的成本，另一方面是强行将同一流程压缩为“一次性响应”（这种响应可能每次都需要修正）所带来的风险。针对每个维度，Pattabiraman 都概述了关键的权衡取舍以及应避免的常见陷阱。 关于何时使用技能（skill）而非子代理（sub-agent）的问题，在 Reddit 和 Hacker News 上也有人对此展开了讨论。一位名为 enthusiast_bob 的评论者指出， 子代理始终从一个干净、无污染的上下文窗口开始，而技能则始终会考虑整个对话内容 "。另一位用户 dan-does-ai 则强调了 不同的权衡 "：技能“可以在多个代理或对话流中复用”，而“子代理在以下情况下才有意义：该步骤确实需要独立的上下文、权限或不同的知识来源”。 另一个重要的考量是使用子代理时产生的协调需求。除了增加复杂性外，还必须考虑协调层带来的非确定性。例如，Reddit 评论者 Ashlesha-msft 指出， 在 Copilot Studio 中 "： 规划器会根据描述、上下文和最近的对话记录，动态决定何时调用技能、工具、主题或子代理。正因如此，并不是每个类似的提示词都会调用某项技能。 作为社区提供的最后一个视角， 用户 Vlourenco69 提出了一个简单的思维模型 "，用于“理解 AI 代理、子代理、技能、MCP 等概念”：其中，代理扮演导演的角色，子代理扮演经理的角色，技能扮演专业工作人员的角色，工具扮演专用机器的角色，而 MCP 则代表组织的治理规则或策略。 让讨论回到原点，Pattabiraman 指出，在许多情况下，技能与子代理的二分法仅是表面现象。实际上，这两种模型可以无缝组合，当问题需要时，技能可以构建在子代理之上。在许多情况下，这种分层方法代表了最成熟的设计。 原文链接： https://www.infoq.com/news/2026/08/choosing-between-subagent-skills/ "