在构建AI系统时，架构选择（技能还是子代理）比模型选择更具决定性。开发者需要基于迭代模型、语音保真度、人工干预点和重复频率四个维度进行权衡，并最终走向两者融合的分层架构设计。
在构建AI系统时，团队往往从错误的问题入手，只关注应该使用哪种模型。然而，第一个真正的抉择并非模型，而是架构：你是在构建技能还是子代理。如果架构搞错了，无论选择哪种模型都无济于事。
“第一个真正的抉择并非模型，而是架构：你是在构建技能还是子代理？如果搞错了，无论选择哪种模型都无济于事。”
决定构建技能还是子代理，需要考量四个关键维度：迭代模型、语音保真度、人工干预点以及任务的重复频率。其中频率是最分明的区分因素，而交互模式则需要权衡人类参与成本与强行压缩为一次性响应的风险。
“子代理始终从一个干净、无污染的上下文窗口开始，而技能则始终会考虑整个对话内容。”
“技能可以在多个代理或对话流中复用，而子代理在以下情况下才有意义：该步骤确实需要独立的上下文、权限或不同的知识来源。”
使用子代理时会产生额外的协调需求并增加系统复杂性。协调层（如 Copilot Studio 中的规划器）会引入非确定性，根据描述、上下文和最近的对话记录动态决定何时调用组件，这意味着相同的提示词不一定会触发同一技能。
“在 Copilot Studio 中，规划器会根据描述、上下文和最近的对话记录，动态决定何时调用技能、工具、主题或子代理。正因如此，并不是每个类似的提示词都会调用某项技能。”
技能与子代理的二分法往往只是表面现象。实际上，这两种模型可以无缝组合，当问题需要时，技能可以构建在子代理之上。这种分层方法代表了当前最成熟的AI系统设计模式。
本文揭示了一个当前AI工程落地中的普遍痛点：开发者容易陷入“模型至上”的误区，而忽视了系统架构的顶层设计。Azure首席工程师与社区的讨论共同指向了一个核心事实——上下文管理是决定AI系统表现的决定性因素。技能代表了共享上下文与高交互性，子代理代表了上下文隔离与高自治性。将协调层的非确定性风险纳入考量，体现了对生产级AI系统稳定性的深刻理解。这表明AI开发正在从“提示词工程”向“认知架构工程”快速演进。