高智力模型作为规划+flash模型执行这种方案的可行之处在哪。和高智力模型规划+执行又有什么区别

先拿一个具体例子说。假设任务是「修一个登录接口的 bug」。 同一个强模型规划加执行：它自己打开文件、读代码、看到项目里的错误码约定、发现这个函数还被另一个地方调用、顺手改了两处、跑测试、失败、看报错、再改。全程每一步都在做判断。 强模型规划加 flash 执行：强模型读完代码，产出一份计划，比如「1. 打开 auth/session.py，把第 42 行的 timeout 从 30 改成 60；2. 跑 pytest tests/test_auth.py；3. 如果 test_refresh 失败，检查 refresh_token 的过期判断」。flash 拿着这份计划去调工具执行。 两者的差别基本都在这里。先说你问的可行之处： 一、成本结构和它是对得上的。执行侧的 token 消耗才是大头（反复读文件、生成 diff、多轮工具调用），规划只占很小一块。把大头搬到便宜模型上，账单立刻下来。参考量级：同一家厂商 Opus 到 Haiku 是 5 倍价差，RouteLLM 那类实验在不同任务上做到 1.4 到 3.7 倍的成本下降。这部分是真省钱。 二、延迟更低。小模型出 token 快，工具调用循环更短。 三、计划是可以被审查的中间产物。你可以先看计划对不对再放它执行；执行到一半失败，也知道该从第几步重来，而不是整段重来。 四、真实任务里「判断密度」分布不均。真正需要智力的决策点就那么几个，其余大量步骤是机械的。把机械部分剥出去，是这方案成立的根本理由。 但有个实验结论必须先摆出来。PEAR 这个 planner-executor 基准（MSU 等，arXiv 2510.）测下来：弱的 planner 对整体成功率的伤害远大于弱的 executor；memory 加在 planner 上有明显收益，加在 executor 上几乎没影响。也就是说这个方案的方向是对的（planner 必须强），但反过来「强 executor 加弱 planner」是灾难。同一篇还发现攻击主要从 planner 下手，成功率大多在 70% 以上，而且 utility 越高的配置越容易被攻破。 接下来是核心区别，也就是你问的第二问。 一、计划是强模型推理结果的有损压缩，这是最大的信息损失点。强模型亲自执行时，脑子里带着完整依据：为什么这么改、哪里要小心、什么算成功、这个项目的风格是什么。flash 只拿到压缩后的指令。计划里没写、执行时才需要现场判断的东西，全部丢失。回到上面那个例子：计划写「加个参数校验」，但没写项目的错误码约定和校验风格，flash 就会写出一份能跑但风格不对的代码。 二、错误恢复能力不同。工具报错时强模型能重新推理（「这个 API 没这个参数，换个写法」）；flash 更可能卡住、瞎试，或者照着已经错了的计划一路走到底。PEAR 里「弱 executor 通常还能撑住」，是因为 planner 的指令足够明确；一旦环境偏离计划，弱 executor 就救不回来。 三、上下文成本未必真的省。同模型执行时，规划和执行共享同一份上下文（包括 KV cache）；拆开之后，executor 要么重新吃一遍上下文，要么只拿到 planner 的摘要。Anthropic 自己公布的数据是 multi-agent 架构大约消耗单轮对话 15 倍 token，因为每个 worker 都有自己完整的上下文窗口。所以「用 flash 省钱」成立的前提是 executor 的上下文确实比 planner 少得多，否则省不下来。 四、什么时候两者几乎没区别。任务完全可枚举、机械、有明确验收标准时，拆不拆都一样，甚至拆了更好，因为可以并行。Anthropic 和 OpenAI 的公开建议都是先在单个 agent 上把 prompt 打磨到极限，再考虑拆。 具体到 coding 场景：大部分 coding 任务其实不适合「强模型规划加弱模型执行」，因为改代码的每一步都在做判断（读代码、理解约定、试错）。真正适合塞给 flash 的，是那些判断密度低、结果可验证的机械环节，比如批量格式化、按模板生成测试骨架、跑命令并汇总输出、从日志里抽信息。