为什么AI Agent写的代码总差点意思Sol Advisor的能力路由哲学给出答案【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisorAI Agent 写的代码为什么总差点意思Sol Advisor 用一套能力路由capability routing工作流给出答案让 Sol 主会话担任架构师负责规划与验收Luna 常规车道实现明确边界的工作Terra 升级车道处理高风险任务最后由一个新鲜的 Sol 只读评审把关。这套 Codex 原生的多 Agent 协作哲学正是 AI 编程时代代码质量的关键解法。一、先找病因AI Agent 代码差点意思的 3 个根源 如果你用过 AI 编程助手大概率遇到过这些场景症状背后的原因小改动写一堆架构级任务又显得不够聪明一个模型打天下所有任务用同一个模型、同一个推理强度改着改着方向跑偏、上下文越来越乱上下文污染架构思考和代码实现挤在同一个会话里说已完成但 bug 还在自审偏差自己写、自己验完成声明缺乏独立证据核心问题可以归结为一句话不是模型不够强而是谁干什么活没有路由。简单的活浪费高配算力复杂的活交给低配模型硬扛最后谁来审又是自己审自己。Sol Advisor 的设计出发点就是针对这三点把工作按能力需求路由到不同的 Agent 车道并强制一道新鲜的独立评审。二、能力路由4 条车道各司其职 ️Sol Advisor 把一次完整的软件交付拆成 4 个阶段每个阶段由不同配置的 Agent 承担完整定义见 README.md 中的路由总表阶段角色车道模型配置职责 规划Sol / High主会话GPT-5.6 Sol 高推理解决需求歧义、定架构、写完整规格、验证与验收⚙️ 常规实现Luna / MaxGPT-5.6 Luna 最大推理边界清晰、完全规格化的常规工作默认车道 升级实现Terra / HighGPT-5.6 Terra 高推理判断密集、高风险、影响面大的工作️ 终审Fresh Sol / HighGPT-5.6 Sol 高推理只读沙箱审查真实 diff给出ship/fix-first/rethink三条工作车道都以 Codex 原生自定义 Agent 的形式注册模型和推理强度直接钉死在角色文件里而不是在每次调用时临时指定常规车道sol-advisor-luna-implementer.toml升级车道sol-advisor-terra-implementer.toml终审车道sol-advisor-sol-reviewer.toml并声明sandbox_mode read-only关键设计升级规则而不是试到对为止能力路由里最值得玩味的规则是显式升级escalation默认走 Luna——只要工作边界清晰、规格完整就用常规车道一次修正机会——如果 Luna 做完、父会话验证后发现不对允许修正规格后让 Luna 再做一次第二次信号即升级——如果这次修正尝试证明这活根本不该归类为常规工作就带着修正后的规格转交Terra / High。这套规则在 SKILL.md 中写得非常硬不允许悄悄换模型、换角色、降推理强度——没有静默回退no silent fallback。路由证据不可观测时宁可停住这条车道也不许凑合交付。三、新鲜评审为什么终审必须是新会话 Sol Advisor 强制规定父会话验证完 diff 之后必须启动一个全新的评审 Agent而且评审者永远不亲手修自己发现的 bug。完整评审契约见 role-contracts.md。这个新鲜fresh是刻意设计的上下文干净评审者不带实现过程中的思维惯性不会被我当时为什么这么写带偏只读沙箱评审 Agent 请求只读隔离只能看文件和 diff不能改代码物理上杜绝边审边修三选一裁决ship可交付、fix-first有限修正后重审、rethink架构层面重来不许报完成修正即作废一旦fix-first后真的改了代码原裁决作废必须再跑一次新的新鲜评审。用大白话说验收官必须是新来的而且手里没有扳手——只能开单子不能自己上手。这就是解决自己写自己审偏差的机制。四、证据驱动验证把我写完了当声明不当事实 ✅多 Agent 协作最怕的是汇报即完成。Sol Advisor 给每个实现任务都下发一份五段式规格完整模板见 role-contracts.md段落内容OBJECTIVE可观测的结果以及为什么重要FILES AND OWNERSHIP明确你只负责这些文件并声明你不是代码库里唯一的编辑者必须保留他人并发改动INTERFACES必须保持兼容的签名、类型、命令、行为CONSTRAINTS仓库约定、安全边界、已定的决策VERIFICATION要跑的确切命令 预期结果要检查的确切文件 预期证据而父会话的验收动作是写死的检查真实 diff → 确认只改了范围内的文件 →自己重新跑一遍验证命令→ 拿证据对照规格。工作 Agent 的汇报只被视为声明无证据的完成声明一律无效。配合这套路由哲学的还有一组守门脚本安装/校验 Agent 角色文件、只读检查运行时路由证据角色安装与一致性检查install-agents.sh运行时路由证据检查inspect-agent-runtime.sh一键验证脚本verify.sh五、3 步上手 Sol Advisor 前置要求较新的 Codex CLI 或启用插件的 ChatGPT 桌面端主会话使用 GPT-5.6 Sol High 推理且环境支持 GPT-5.6 Luna / Max 与 Terra / High。第 1 步把仓库装成 Codex 本地插件市场codex plugin marketplace add /absolute/path/to/sol-advisor codex plugin add sol-advisorsol-advisor第 2 步注册三个原生自定义 Agent并做非破坏性校验sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check第 3 步开新任务显式调用编排技能注意Codex 在创建任务时才会发现新安装的 Agent 角色所以装完必须开新任务。随后选中 Sol / High并这样提示即可Use $sol-advisor:orchestration to build this feature, verify it, and obtain the fresh Sol review before reporting done.完整的安装与升级说明见 README.md整套编排规则见 SKILL.md。六、总结能力路由哲学教会我们什么 Sol Advisor 真正有参考价值的不是某条命令而是三条可以迁移到任何多 Agent 工作流的原则按能力路由而不是按习惯分配——常规工作走默认车道高风险工作显式升级让算力与任务难度匹配架构决策与代码实现物理隔离——架构师留在主会话实现交给有明确文件所有权的工人验收只认真实证据——新鲜评审 只读沙箱 父会话亲自复跑验证杜绝自我感觉良好的交付。下次当 AI Agent 写的代码又差点意思时不妨先问一句这个任务派对车道了吗【免费下载链接】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辅助生成（AIGC），仅供参考
为什么AI Agent写的代码总差点意思？Sol Advisor的“能力路由“哲学给出答案
为什么AI Agent写的代码总差点意思Sol Advisor的能力路由哲学给出答案【免费下载链接】sol-advisorCodex-native architect orchestration with Luna and Terra implementation lanes and mandatory fresh Sol review.项目地址: https://gitcode.com/gh_mirrors/so/sol-advisorAI Agent 写的代码为什么总差点意思Sol Advisor 用一套能力路由capability routing工作流给出答案让 Sol 主会话担任架构师负责规划与验收Luna 常规车道实现明确边界的工作Terra 升级车道处理高风险任务最后由一个新鲜的 Sol 只读评审把关。这套 Codex 原生的多 Agent 协作哲学正是 AI 编程时代代码质量的关键解法。一、先找病因AI Agent 代码差点意思的 3 个根源 如果你用过 AI 编程助手大概率遇到过这些场景症状背后的原因小改动写一堆架构级任务又显得不够聪明一个模型打天下所有任务用同一个模型、同一个推理强度改着改着方向跑偏、上下文越来越乱上下文污染架构思考和代码实现挤在同一个会话里说已完成但 bug 还在自审偏差自己写、自己验完成声明缺乏独立证据核心问题可以归结为一句话不是模型不够强而是谁干什么活没有路由。简单的活浪费高配算力复杂的活交给低配模型硬扛最后谁来审又是自己审自己。Sol Advisor 的设计出发点就是针对这三点把工作按能力需求路由到不同的 Agent 车道并强制一道新鲜的独立评审。二、能力路由4 条车道各司其职 ️Sol Advisor 把一次完整的软件交付拆成 4 个阶段每个阶段由不同配置的 Agent 承担完整定义见 README.md 中的路由总表阶段角色车道模型配置职责 规划Sol / High主会话GPT-5.6 Sol 高推理解决需求歧义、定架构、写完整规格、验证与验收⚙️ 常规实现Luna / MaxGPT-5.6 Luna 最大推理边界清晰、完全规格化的常规工作默认车道 升级实现Terra / HighGPT-5.6 Terra 高推理判断密集、高风险、影响面大的工作️ 终审Fresh Sol / HighGPT-5.6 Sol 高推理只读沙箱审查真实 diff给出ship/fix-first/rethink三条工作车道都以 Codex 原生自定义 Agent 的形式注册模型和推理强度直接钉死在角色文件里而不是在每次调用时临时指定常规车道sol-advisor-luna-implementer.toml升级车道sol-advisor-terra-implementer.toml终审车道sol-advisor-sol-reviewer.toml并声明sandbox_mode read-only关键设计升级规则而不是试到对为止能力路由里最值得玩味的规则是显式升级escalation默认走 Luna——只要工作边界清晰、规格完整就用常规车道一次修正机会——如果 Luna 做完、父会话验证后发现不对允许修正规格后让 Luna 再做一次第二次信号即升级——如果这次修正尝试证明这活根本不该归类为常规工作就带着修正后的规格转交Terra / High。这套规则在 SKILL.md 中写得非常硬不允许悄悄换模型、换角色、降推理强度——没有静默回退no silent fallback。路由证据不可观测时宁可停住这条车道也不许凑合交付。三、新鲜评审为什么终审必须是新会话 Sol Advisor 强制规定父会话验证完 diff 之后必须启动一个全新的评审 Agent而且评审者永远不亲手修自己发现的 bug。完整评审契约见 role-contracts.md。这个新鲜fresh是刻意设计的上下文干净评审者不带实现过程中的思维惯性不会被我当时为什么这么写带偏只读沙箱评审 Agent 请求只读隔离只能看文件和 diff不能改代码物理上杜绝边审边修三选一裁决ship可交付、fix-first有限修正后重审、rethink架构层面重来不许报完成修正即作废一旦fix-first后真的改了代码原裁决作废必须再跑一次新的新鲜评审。用大白话说验收官必须是新来的而且手里没有扳手——只能开单子不能自己上手。这就是解决自己写自己审偏差的机制。四、证据驱动验证把我写完了当声明不当事实 ✅多 Agent 协作最怕的是汇报即完成。Sol Advisor 给每个实现任务都下发一份五段式规格完整模板见 role-contracts.md段落内容OBJECTIVE可观测的结果以及为什么重要FILES AND OWNERSHIP明确你只负责这些文件并声明你不是代码库里唯一的编辑者必须保留他人并发改动INTERFACES必须保持兼容的签名、类型、命令、行为CONSTRAINTS仓库约定、安全边界、已定的决策VERIFICATION要跑的确切命令 预期结果要检查的确切文件 预期证据而父会话的验收动作是写死的检查真实 diff → 确认只改了范围内的文件 →自己重新跑一遍验证命令→ 拿证据对照规格。工作 Agent 的汇报只被视为声明无证据的完成声明一律无效。配合这套路由哲学的还有一组守门脚本安装/校验 Agent 角色文件、只读检查运行时路由证据角色安装与一致性检查install-agents.sh运行时路由证据检查inspect-agent-runtime.sh一键验证脚本verify.sh五、3 步上手 Sol Advisor 前置要求较新的 Codex CLI 或启用插件的 ChatGPT 桌面端主会话使用 GPT-5.6 Sol High 推理且环境支持 GPT-5.6 Luna / Max 与 Terra / High。第 1 步把仓库装成 Codex 本地插件市场codex plugin marketplace add /absolute/path/to/sol-advisor codex plugin add sol-advisorsol-advisor第 2 步注册三个原生自定义 Agent并做非破坏性校验sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check第 3 步开新任务显式调用编排技能注意Codex 在创建任务时才会发现新安装的 Agent 角色所以装完必须开新任务。随后选中 Sol / High并这样提示即可Use $sol-advisor:orchestration to build this feature, verify it, and obtain the fresh Sol review before reporting done.完整的安装与升级说明见 README.md整套编排规则见 SKILL.md。六、总结能力路由哲学教会我们什么 Sol Advisor 真正有参考价值的不是某条命令而是三条可以迁移到任何多 Agent 工作流的原则按能力路由而不是按习惯分配——常规工作走默认车道高风险工作显式升级让算力与任务难度匹配架构决策与代码实现物理隔离——架构师留在主会话实现交给有明确文件所有权的工人验收只认真实证据——新鲜评审 只读沙箱 父会话亲自复跑验证杜绝自我感觉良好的交付。下次当 AI Agent 写的代码又差点意思时不妨先问一句这个任务派对车道了吗【免费下载链接】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辅助生成（AIGC），仅供参考
