一名开发者近日在Linux.do论坛分享了一次混合模型协作的实测经历。该用户借助ccSwitch的聚合功能，在Claude Code的模型调用后端填入DeepSeek模型代称，让Opus作为主代理指导DeepSeek子代理开工。实测中发现，主模型虽然会提前规划大量任务清单交给子代理执行，但自己也非常积极地参与编码；当子代理完成初步工作后，主模型便不再依赖子代理，而是持续自行修改和完善代码。费用方面差距明显：DeepSeek子代理最终仅花费约2元，而Opus主模型消耗超过30元，成本相差十余倍。该用户还观察到，Claude Code调用子代理的倾向整体偏低，无论子代理内部配置何种模型，主模型都宁可全程独立完成任务，除非在工程流程中明确要求其在各个关键节点主动调用，否则执行过程中常转为亲自处理。相比之下，DeepSeek的Agent框架在调用子代理方面表现积极。这一现象引发了社区关于主模型编排策略、子代理调度机制与多模型协作成本控制的讨论。
事件分析
这一现象折射出当前AI Agent编排层的共性设计倾向：主模型通常被训练为对最终质量负责，在缺乏显式流程约束时倾向于保留控制权，避免将关键修改交给能力较弱的子模型。这既是能力对齐的结果，也与上下文传递损耗、任务拆分开销等工程因素有关。从成本角度看，高端模型与低成本模型的价差可达一个数量级，编排策略直接决定混合部署的经济性，仅靠用户提示词约束难以稳定奏效。后续可能的走向包括：Agent框架引入更细粒度的任务分级与强制调度策略、厂商在系统层面对子代理调用行为进行调优、社区针对Claude Code推出编排插件或规则模板。此类第一手实测也为多模型混合编排的成本优化提供了实践参考，反映出用户侧对可控编排能力的真实需求。
核心观点：主模型越强越不信任子代理，智能水平反而推高编排成本，多模型协作的关键不在模型本身而在调度机制。
原文链接：Linux.do
评论前必须登录！
立即登录 注册