Skill还是Subagent？Agent架构关键抉择

大多数人在决定是用 subagent 还是 skill 时，思路大概是：任务大就用 subagent，其他情况用 skill——但这个判断维度是错的。大小不是问题，隔离才是。

两者实际是什么

skill 是你的 agent 加载到当前上下文中的一个流程——同一 session、同样的记忆（包含之前发生的所有事情）、同一段正在进行的对话。而 subagent 是一个独立的工作上下文，完成自己的任务后再汇报结论。模型可能相同，但工作集不同。

这个差异——共享上下文 vs 隔离上下文——才是应该决定用哪个的因素，而不是任务看起来有多难或多耗时。

检验标准：任务需要"忘掉"其他一切吗？

直接问这个问题：当前任务会不会因为看不到对话的其他部分而受益？

当工作需要上下文已有的信息时，用 skill。比如：调试一个已经讨论了十条消息的故障；根据 session 中早些时候做出的决定来 review 一个 diff；撰写必须匹配前面三次交流建立起来的语气的内容——所有这些场景放到隔离上下文中都会变差，因为隔离会丢弃任务恰好需要的确切信息。

当任务会往上下文里灌入大量不需要的噪音时，用 subagent。比如：在两百个文件中搜索来回答"这个代码库是否已经做了 X"，会产生大量的中间读取和 grep 结果。你不想让这座"山"留在主 session 里——你只想要答案。同样适用于对抗性的第二意见：它不受它所要检查的推理的污染，会更有用。

实际中容易犯的错误

常见的错误不是"明明 skill 就能搞定却选了 subagent"，而是本能地、反射性地对任何看起来费力的任务都先想到 subagent。这样做会丢失本可以让答案变得优质的上下文。subagent 的输出是一个结论，剥离了产生它的推理轨迹。如果下一步需要这个轨迹——"你为什么得出那个结论"——你就已经把它扔掉了。

反过来犯的错误更少，但代价更高：因为觉得比委托出去更简单，就把一个极宽泛的搜索放在主 session 里内联执行。你读过的每个文件都会留在上下文中，无论它是否重要，等到第四十条消息时，你的 agent 就在一个充满冗余的 session 中推理了。

两者是组合关系，不是竞争关系

更好的模式不是二选一，而是把 skill 附加在 subagent 上派出去，让隔离的工作仍然遵循一个硬化的流程，而不是临时发挥。subagent 决定工作在哪里发生；skill 决定一旦到达那里如何把事情做好。多阶段 pipeline 通常两者都需要：每个阶段隔离以保证上下文卫生，每个阶段携带自己的流程，这样委托出去的步骤不会变成一个监管更弱的主流程版本。

如果你在构建这类流程的库，而不是在每个 session 中重新写，Skill Forge 提供了 43 个预硬化的流程，涵盖五个领域——主要适用于你更希望从经过测试的触发器和门控开始，而不是从零调试自己的流程。

Full answer: https://agentkitworks.com/answers/skill-vs-subagent