任何方案都有取舍，用 subagent token 消耗肯定更大，但价钱不见的更…

任何方案都有取舍，用 subagent token 消耗肯定更大，但价钱不见的更贵。要是 Fable 5 耐用谁愿意这么折腾！ subagent 是独立的上下文，任务开始前需要重新交代子任务上下文，完成后还要交接工作，这是代价；缓存倒是其次的，因为初始上下文不会太大，而且缓存只有第一次有影响，后续子agent有自己的缓存。 这样带来的收益是子 agent 可以用便宜的模型，虽然 token 消耗量大，但是价格其实更便宜，如果你是 Claude Code 订阅的话，多让 Fable 指挥 Opus/Sonnet SubAgent 体感很明显。 然后由于具体子任务细节都在子agent，主agent的上下文只需要子任务的结果，这样可以节约主agent大量上下文空间，可以更专注于任务本身。 这就好比你有个能力超强的员工，他当然可以什么事情都做了，但他也可以把活派给实习生，实习生做完了检查验收一下，这样能做的事情更多了。 这个思路很有意思。我们平时用各种 Skill，感觉它们各有各的用处，但本质上都是在做同一件事：给 AI 划定一个明确的工作范围，让它在这个范围内发挥最大效能。 就像 Harness 一样，它不是限制 AI 的能力，而是引导 AI 的能力。一个好的 Skill 会告诉你：这个任务该怎么做、不该怎么做、边界在哪里、输出格式是什么。 这种边界约束的设计思路，其实和软件工程里的模块化设计很像。每个模块都有明确的输入输出接口，内部实现可以灵活变化，但对外的契约是固定的。 对于想要提升AI开发效率的开发者来说，这个设计思路值得关注。即使你现在用的是其他AI方案，也可以通过这个思路来对比一下效果。在AI开发这个领域，多了解一种方案总是好的。