先别急着选模型：先想清楚「技能」与「子代理」才是关键
摘要：搭建 AI 系统时，团队常常把「选哪个模型」当作头等大事，但 Azure 首席工程师提醒：更关键的架构决策是「技能」和「子代理」二选一。本文拆解两种模式的本质区别、判断维度与社区实战经验，帮你避免在模型选择上白费功夫。
被忽略的架构决策
在 Azure 最近发布的架构博文中，首席工程师 Kishorekumar Pattabiraman 直言：团队在搭建 AI 系统时，最常问错的问题就是「该用哪个模型」。实际上，第一个关键选择与模型无关，而是架构层面：
你构建的是技能，还是子代理？如果这一步搞错了，无论选哪个模型都无济于事。技能和子代理是两种不同的实现形式，各自都无法胜任对方的任务。
这句话点到了要害：模型能力决定了系统的上限，但真正决定任务能否落地的，往往是系统如何组织工作方式。在 AI 编程和智能体开发越来越普及的今天，这个取舍几乎每天都在发生。
技能与子代理：本质区别
要理解两者的差异，先看它们的运行机制：
- 技能（Skill）：运行在持续的对话语境中。它可以读取文件、向用户提问、与用户实时互动，整个过程用户始终参与。
- 子代理（Sub-agent）：接收一个提示词后独立运行，直到任务完成，最终输出一个结果。中间过程不需要（也不允许）用户介入。
简单来说：技能像「对话式协作」，子代理像「派活干完交差」。两者各有擅长，具体选哪个，取决于任务本身的性质。
四个维度帮你决策
Pattabiraman 提出了四个关键判断维度：迭代模型、语音保真度、人工干预点和任务重复频率。
任务重复频率：最清晰的判别标准
四个维度中，频率最容易判断。Pattabiraman 指出：
一次性制作出来的「手工件」偏向于使用技能，而可重复的批量工作更倾向于子代理。
换句话说，如果任务「写完就结束」，技能更合适；如果是流水线式、需要不断重跑的工作，子代理更能发挥作用。
其他维度：需要权衡隐性成本
现实中，我们很少在面对「完全交互式对话」和「简单任务交接」时做非黑即白的选择。真正的难点在于权衡两类成本：
- 让人类参与基于技能的迭代流程，会带来持续的人力投入；
- 强行把同一个流程压缩成一次性响应，则可能每次都需要人工修正，反而更费事。
针对每个维度，Pattabiraman 都给出了权衡逻辑和常见陷阱。核心思路是：不要只看任务表面的形态，要思考在整个流程中，「人」和「自动化」分别在哪个环节介入最合理。
社区一线经验：开发者怎么看
这个问题在 Reddit 和 Hacker News 上也引发了讨论，几个观点颇值得参考。
子代理从「干净」开始，技能始终「知情」。 用户 enthusiast_bob 指出，子代理每次运行都从全新的上下文窗口开始，不携带历史信息；技能则始终能看到整个对话的来龙去脉。这意味着，如果任务依赖前文信息，技能天然更有优势；如果任务需要「专注眼前」，子代理反而能减少信息干扰。
复用性 vs 独立性。 开发者 dan-does-ai 分享了他的判断标准：技能可以在多个代理或对话流中被复用，而子代理仅在需要独立上下文、独立权限或不同知识来源时才有意义。
协调层存在不确定性。 使用子代理还需要考虑协调问题——识别何时调用哪个子代理，本身就是额外的复杂性。Reddit 用户 Ashlesha-msft 以 Copilot Studio 为例：
规划器会根据描述、上下文和最近的对话记录，动态决定何时调用技能、工具、主题或子代理。正因如此，并不是每个类似的提示词都会调用某项技能。
一个便于记忆的类比。 用户 Vlourenco69 提出了一个直观模型：
- 代理 = 导演
- 子代理 = 经理
- 技能 = 专业工作人员
- 工具 = 专用机器
- MCP = 组织的治理规则或策略
这个类比相当清晰：导演负责整体规划，经理分管具体任务，专业人士动手执行，治理规则决定谁能做什么。
组合使用才是常态
Pattabiraman 特别提醒，「技能 vs 子代理」的二分法在很多情况下只是表面现象。 实际设计中，两种模式完全可以无缝组合——一个技能可以构建在子代理之上：技能在对话中负责交互，底层调用的子代理负责独立处理重活。
在许多实际场景中，这种分层设计反而是更成熟、更经得起长期维护的方案。