何时该升级模型？Sol Advisor“一次纠正后的Luna尝试“单一规则详解

何时该升级模型？Sol Advisor"一次纠正后的Luna尝试"单一规则详解

【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisor

在 AI 编程与智能体编排中，"何时该升级模型"常常让人纠结：用太弱的模型做不完任务，一直用最贵的模型又浪费成本。Sol Advisor 是一个面向 Codex 的架构师编排工作流，它用一条简单明确的单一规则回答了这个问题——"一次纠正后的 Luna 尝试"：默认让高性价比的 Luna 模型执行常规任务，只要"纠正规格书后重试一次"仍暴露出任务被误判为常规工作，就立即升级到更强推理能力的 Terra 模型。本文将用通俗的语言详解这条规则的设计思路、在源码中的落地位置，以及规则触发后的完整工作流。

一、先认识 Sol Advisor：一条角色分明的 AI 编程流水线 🎭

Sol Advisor 的核心思想是"按能力路由"（capability-routed）：不同难度交给不同档位的模型，而不是全程使用同一个模型。整条流水线有四个固定角色：

其中Luna / Max与Terra / High就是"什么时候该升级模型"问题中的主角：前者便宜高效，是默认车道；后者能力更强，是显式的升级车道。

完整的路由设计可以查看 README.md 中的 "Native routing" 章节，工作流细节在 plugins/sol-advisor/skills/orchestration/SKILL.md 中定义。

二、为什么模型升级需要一条"单一规则"？

没有明确规则时，升级模型的决定往往依赖临场感觉，常见问题有两个：

• 升级太晚：在弱模型上反复修补，多次失败后才想起"换个强模型试试"，白白消耗时间；
• 升级太早：一点小挫折就切到最贵的模型，成本失控，也失去了低成本模型的效率优势。

Sol Advisor 的解法是把升级条件压缩成一句话级别的规则，让任何参与编排的人（或主会话 Agent）在同一个信号出现时做出同一个决定。这个信号就是：一次纠正后的 Luna 尝试。

三、"一次纠正后的Luna尝试"规则详解

规则原文：三处定义互相印证

这条规则在项目文档中被反复强调，且三处措辞一致，属于"写进契约"而非口头约定：

1. 编排技能文档 SKILL.md："如果一次纠正后的 Luna 尝试表明任务属于判断密集、高风险或路由误判，就把纠正后的规格书交给升级角色 Terra / High"；
2. 角色契约 role-contracts.md："如果一次纠正后的 Luna 尝试显示任务被误判为常规工作，把该信号回传给主会话，升级到 Terra / High"；
3. Luna 角色自身的定义 sol-advisor-luna-implementer.toml：Luna 被要求"如果一次纠正后的尝试显示任务被误判，停下来返回该信号，由父会话升级到 Terra / High"。

拆解规则的三个关键要素 🔍

把原文拆开后，规则其实由三个动作组成：

这里有一个容易被忽略的细节，写在 SKILL.md 中：给失败车道的是"纠正后的规格书"，永远不要重复一份未修改的提示词——先排除"题目出错了"，再讨论"学生行不行"。

为什么是"一次"而不是"三次"？

• 一次失败可能是题目问题（规格书写得不清、约束遗漏），所以先纠正规格书重试，给 Luna 一个公平的机会；
• 纠正后再次失败，大概率是能力问题：任务本身超出了"常规工作"的范畴（判断密集、高风险、影响面大）。此时继续在同一模型上打补丁，边际收益很低；
• 单一规则的价值就在可预测：不数"两次"还是"三次"，团队里任何人遇到同一个信号都执行同一个动作，规则才立得住。

四、规则在源码中的落地：三份角色定义文件

Sol Advisor 的每个角色都由一份 TOML 文件"钉死"模型与推理档位，升级不是临时换参数，而是切换到另一条预设车道：

值得注意的设计是：升级决定权在主会话（Sol 架构师）手中，而不是由 Luna 自己"悄悄换模型"。Luna 的职责是发现并上报信号，主会话验证后才路由到 Terra，这保证了升级是可追溯、可审计的。

五、升级触发后的完整工作流 🔄

规则触发后并不是"换模型就完事"，而是进入一条闭环：

1. 纠正规格书→ 主会话根据 Luna 的失败证据修正任务描述；
2. 路由到 Terra / High→ 使用精确角色名sol_advisor_terra_implementer派生，不附加任何临时模型参数；
3. 父会话验证→ 主会话亲自检查真实 diff、重新运行验证命令，而不是相信工人报告；
4. 全新 Sol 复审→ 验证通过后，必须再派生一个全新上下文的 sol_advisor_sol_reviewer 做只读审查，返回ship（可交付）、fix-first（先修复）或rethink（重新设计）；
5. 任何修复都会作废旧判定→ 修复后必须再来一轮全新审查，审查员自己永远不写代码。

完整流程与证据规则见 role-contracts.md，其中 "How routing works" 部分（README.md）给出了最简短的路由说明。

六、快速上手：安装 Sol Advisor 的完整步骤

1. 按 README.md 的 "Install" 章节，把 Sol Advisor 仓库添加为 Codex 插件市场源并安装插件；
2. 单独安装三个角色模板并做完整性校验（脚本本身是只读检查，不会覆盖已有文件）：install-agents.sh，加上--check参数可验证三份已安装文件与模板逐字节一致；
3. 开启一个全新的 Codex 任务（角色是在任务创建时被发现的，老任务看不到新安装的角色），主会话选择 Sol / High；
4. 需要时显式调用编排技能：Use $sol-advisor:orchestration ...，技能入口定义在 openai.yaml。

运行时如何确认"这次到底用的哪个模型"？项目提供了只读的本地检查脚本 inspect-agent-runtime.sh，输入子线程 ID 即可输出实际的角色、模型与推理档位证据——升级是否真的发生，靠证据说话。

七、新手常见问题（FAQ）

Q1：常规任务一定要从 Luna 开始吗？是的。Luna / Max 是默认车道；只有"一开始就明确属于判断密集、高风险、影响面大"的任务，才直接走 Terra / High 显式升级。

Q2：Luna 一次纠正后成功了，还要升级吗？不需要。规则只在"纠正后的一次尝试仍然暴露误判"时触发，一次纠正后成功说明任务确实是常规工作。

Q3：主会话自己偷偷修一下 Luna 的补丁行不行？不行。SKILL.md 明确要求：不要悄悄修复失败的子任务补丁或掩盖未解决的纠正，要么走同一车道派一次有限纠正，要么按规则升级到 Terra。

Q4：换模型后之前的审查结论还有效吗？无效。任何修复（包括升级模型后产生的新代码）都会作废先前审查判定，必须重新派生全新审查员。

八、总结：一条规则背后的成本思维

Sol Advisor 的"一次纠正后的 Luna 尝试"规则，本质上回答了新手使用 AI 编程时最常见的困惑——何时该升级模型：

• ✅ 升级的依据不是"感觉做不完"，而是一个可观察的信号：纠正规格书后重试一次，仍暴露任务被误判为常规工作；
• ✅ 升级时携带的是纠正后的规格书，让更强模型站在修正过的起跑线上；
• ✅ 升级后仍有父会话验证 + 全新只读审查双保险，换更强的模型不等于可以放松验收。

先便宜、后升级、信号驱动——这条单一规则把"模型升级"从玄学变成了流水线上的一个标准动作，值得所有在用 AI 编程工具的团队借鉴。

【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisor