DeepSeek-Reasonix 双模型协作原理详解执行器与规划器如何分工配合的完整指南【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-ReasonixDeepSeek-Reasonix 是一款面向终端的开源 AI 编程智能体AI Coding Agent由单个 Go 二进制文件驱动支持 CLI、桌面端、浏览器与 ACP 编辑器接入。它的核心卖点之一是双模型协作一个执行器Executor负责动手写代码一个规划器Planner负责先想清楚再动手两者运行在各自独立的、缓存稳定的会话里互不干扰。为什么需要双模型协作普通 AI 编程工具通常只挂一个模型想和做混在一起模型边查文件边改代码长任务里容易边写边偏题。DeepSeek-Reasonix 的做法是把角色拆开角色职责典型模型拥有的工具 规划器 Planner调研代码库、产出结构化计划低频、推理强的模型如 deepseek-pro只读调研工具 submit_plan⚡ 执行器 Executor验证假设、真正执行计划高频、低成本的模型如 deepseek-flash完整工具集读写、执行命令等一句话总结规划器只看不写执行器只写不做计划。写文件、跑命令等所有副作用操作都留给执行器规划器拿到手的只是一个只读研究工具集从机制上杜绝规划阶段就把文件改乱。一分钟开启双模型协作只需改一行配置开启方式极其简单——在reasonix.toml的[agent]段加一行planner_model即可[agent] default_model deepseek-flash # 执行器 planner_model deepseek-pro # 低频规划器配置入口位于 internal/config/官方示例文件reasonix.example.toml中有完整字段说明。文档中的完整章节见 docs/GUIDE.md 的 Two-model collaboration 一节中文规格见 docs/SPEC.zh-CN.md 第 3.5 节双模型协作Coordinator。路由机制规划器何时才会启动很多双模型方案会再找一个分类器模型来判断任务复杂度既慢又贵。DeepSeek-Reasonix 反其道而行宿主用确定性规则路由不调用任何分类器模型也不从措辞、文件数量或关键词推断复杂度。规则简单到可以背下来普通请求 → 永远直达执行器。重构支付模块修登录 Bug这类话术不会触发规划器 显式说先规划 / plan first → 规划器产出计划后自动交接执行器plan_and_execute 显式要求等我确认再执行 → 计划完成后停在宿主的审批边界你点头后才交给执行器plan_for_approval 显式说只规划、不要执行 / plan only → 计划被持久化保存本轮结束、不做任何执行plan_only Goal 模式启动时也会进入规划器。四种路由在源码中被明确定义为常量见internal/agent/planner_route.goPlannerRouteExecutorOnly // 仅执行器默认 PlannerRoutePlanAndExecute // 规划并执行 PlannerRoutePlanForApproval // 规划并等待审批 PlannerRoutePlanOnly // 仅规划阶段详情只会记录一个不含用户原文的 route/reason 诊断码你的提示词不会被写进日志。规划器与执行器的工具权限边界规划器能调用的工具由internal/agent/planner_registry.go中的PlannerToolRegistry统一构建设计原则有三条只读优先从执行器的完整工具注册表中过滤出只读研究工具写类工具、工作流工具与 MCP 直连 Schema 全部隐藏结构化出口额外挂载一个submit_plan工具且只挂在规划器这一侧——这样执行器的工具前缀完全不受影响缓存稳定不做主故意不给规划器ask工具如果它需要用户拍板就用真实工具去问让答案塑造计划而不是把决定钉在一份完成的计划后面。计划如何交接submit_plan 结构化契约规划器不是用一段散文交差而是通过submit_plan提交一份结构化计划数据定义在internal/agent/submit_plan.go契约校验在 internal/plancontract/。这份契约要求相当严格目标objective一句话说清计划要达成什么假设assumptions把没验证过的前提单独列出并附上最便宜的验证手段步骤steps两层级任务且每一步必须区分verified_files你真的读过的文件和candidate_files你只是猜的——严禁把猜测伪装成已验证路径验收标准acceptance与命令级验证verification证据支持时附上可执行的校验命令非目标non_goals与回归标记regression明确圈定范围边界。如果计划格式不合法校验会在工具内部直接返回一条可操作的错误规划器下一轮就能自己修正而不是把一份烂计划静默地塞给执行器。前缀缓存稳定性为什么两个会话不能合并DeepSeek-Reasonix 的项目定位是engineered around prefix-cache stability — leave it running为前缀缓存稳定性而设计——可以挂着一直跑。双模型设计在这点上很克制规划器与执行器使用两条完全独立的 session互不混合消息两条会话的 prompt 前缀都只追加、不重排避免切换模型时把已经缓存好的前缀打碎规划器使用同一个稳定 system prompt每轮只追加一个极小的planner-turn标记块来声明显式路由前缀缓存在一次性的提示词升级后依然保留。从图中也能看到实际效果右侧当前上下文面板里 Cache Hit 高达 87%请求耗时只有 6 次、3 分 50 秒——长会话越跑越便宜这正是可以挂着一直跑的底气。兜底策略规划器卡住怎么办系统对规划器不收敛也做了分层兜底⚠️ 普通 plan-and-execute 请求规划器在有界调研和最终总结轮后仍未收敛时降级回执行器用原始任务继续干不浪费时间 plan-only 与 plan-for-approval 请求保持fail-closed失败即关闭不完整的规划回合会被回滚见internal/agent/coordinator_rollback.go绝不留下一个无法继续的烂尾给用户手动续跑。总结一张图看懂分工环节规划器 Planner执行器 Executor触发显式先规划/等确认/只规划/Goal 启动其余所有请求会话独立 session只追加独立 session只追加工具只读研究 submit_plan完整工具集产出结构化计划数据非散文代码改动 验证结果失败plan-only 回滚普通请求降级给执行器自适应守卫检测无进展并要求重新评估想动手看看完整实现核心编排逻辑在 internal/agent/coordinator.go路由决策在internal/agent/planner_route.go配置示例在reasonix.example.toml协作模式文档在 docs/COLLABORATION_MODES.md。给执行器配一个更强的规划器一行配置的事——你的终端里从此多了一位先画图纸、再动扳手的结对搭档。【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考