多个AI代理同改一个代码库不打架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-advisorSol Advisor 是一个面向 Codex 的 AI 多代理编排工具它用文件所有权模型让 Sol、Luna、Terra 三个 AI 代理协作修改同一个代码库而不互相覆盖。本文带你快速理解这套多智能体协作机制为什么多个 AI 同时改代码会打架以及 Sol Advisor 如何用明确的责任边界、强制验证和全新终审把混乱变成可复现的交付流程。多个AI代理改代码为什么会打架 想象你同时让 3 个 AI 代理改一个项目代理 A重构了utils.ts代理 B 基于旧版本重写同一文件 → A 的改动被悄悄抹掉代理 C把代理 A 刚加的函数当重复代码删掉了每个代理都自信地汇报已完成但合并后测试全挂根本原因没有责任边界。每个 AI 都以为自己是唯一开发者。多代理协作的关键不是模型有多强而是先定好规则谁改哪些文件、谁不能动什么、改动如何验收。Sol Advisor 就是围绕这个问题设计的。Sol Advisor 是什么Sol / Luna / Terra 三条车道 ️Sol Advisor 采用架构师 实施者 审查者的分工模式三条车道各司其职车道代理角色职责 规划Sol / High主会话需求、架构、分解、完整规格说明、验收 常规实施sol_advisor_luna_implementer执行有明确边界的常规开发任务 升级车道sol_advisor_terra_implementer处理判断密集、高风险、影响面大的任务 最终审查sol_advisor_sol_reviewer全新只读代理审查真实 diff给出ship/fix-first/rethink三个角色都是 Codex 的原生自定义代理模型与推理强度在代理模板文件中写死不靠临场发挥。你可以直接查看三个角色的定义常规车道sol-advisor-luna-implementer.toml升级车道sol-advisor-terra-implementer.toml终审角色sol-advisor-sol-reviewer.toml一个值得注意的升级规则如果 Luna 修正一次后仍暴露出这活儿根本需要更多判断力就必须升级到 Terra / High 车道而不是硬让 Luna 再试第三次。没有静默降级也没有偷偷换模型。文件所有权模型给每个AI代理划出领地 ️这是 Sol Advisor 防冲突的核心。每个实施任务提示词必须包含五个固定段落其中第二个就是所有权声明完整契约见 role-contracts.mdOBJECTIVE—— 可观察的结果和它的意义FILES AND OWNERSHIP—— 你只拥有精确的文件或模块INTERFACES—— 必须保持兼容的签名、类型、命令CONSTRAINTS—— 仓库约定、安全边界、已定决策VERIFICATION—— 精确的验证命令和预期证据而所有权段里最关键的三句话几乎逐字出现在每个实施提示词中你不是代码库里唯一的人。其他代理或用户可能正在并发编辑。保留他们的改动不要回退无关工作适配已存在的变更不要修改所有权范围之外的文件。这段约束直接写进了 Luna 和 Terra 两个代理的系统指令里见 sol-advisor-luna-implementer.toml 的developer_instructions代理出厂自带协作意识而不是依赖主会话每次口头叮嘱。并发与串行的三条规则编排技能 SKILL.md 对并发给出了非常克制的策略✅ 互不重叠的独立任务可以并行跑✅ 每个代理只领一个拥有的文件集合或有界职责❌共享文件的修改和依赖链必须串行简单说领地不重叠才允许并行重叠就排队。这一条简单规则消灭了绝大多数代理互相踩的问题。验证与终审AI 的完成不算数 ✅文件所有权只解决不打架不解决改对了。Sol Advisor 对验收同样严格1. 父会话亲自验证主 Sol 会话把实施代理的汇报当作声明而非事实必须自己检查完整 diff确认只有范围内文件被改动在主会话里重新跑一遍规格中指定的验证命令用证据对照目标、接口和约束逐条比对2. 强制的全新终审fresh review父验证通过后必须再启动一个全新的只读审查代理审查真实文件和累积 diff只允许返回三种裁决ship→ 携带验证证据宣告完成fix-first→ 委托修复、再验证、再发起一次全新审查rethink→ 修改架构不许宣称完成两条铁律防止自审自批审查者永远不修自己的问题任何修复都会使旧裁决失效。而且审查者请求只读沙箱运行时会实际观测沙箱策略——观测到不是read-only就不能宣称强制只读。这些细节都在 role-contracts.md 中有完整定义。3. 运行时留痕怀疑路由没走对用仓库自带的只读检查器查看原生线程的运行时证据sh $plugin_dir/scripts/inspect-agent-runtime.sh 子代理线程ID该工具inspect-agent-runtime.sh只输出白名单路由字段拒绝推测缺失的模型或推理强度——证据不足就停止该车道绝不脑补。三步安装上手 Sol Advisor 前提当前版本 Codex CLI或开启插件的 ChatGPT 桌面端、jq以及支持 GPT-5.6 Sol / Luna / Terra 的原生自定义代理功能。第一步添加插件市场并安装插件codex plugin marketplace add DannyMac180/sol-advisor --ref main codex plugin add sol-advisorsol-advisor第二步单独安装三个角色模板并校验插件安装不会自动注册角色文件需要运行随附的安装脚本再跑一次非破坏性的精确性检查plugin_dir$(codex plugin list --json | jq -r .installed[] | select(.pluginId sol-advisorsol-advisor) | .source.path) sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check安装器install-agents.sh是 fail-closed 的被修改过、符号链接、内容不一致的目标文件都原样保留并报告冲突绝不静默覆盖。仓库级自检脚本 verify.sh 还会验证整套三角色架构的一致性。第三步开启新任务并调用编排技能原生代理类型在任务创建时被发现所以检查通过后务必开一个新任务主会话选择 Sol / High然后显式调用Use $sol-advisor:orchestration to build this feature, verify it, and obtain the fresh Sol review before reporting done.完整的编排流程说明在 SKILL.md角色契约与提示词模板在 role-contracts.md。总结秩序来自规则而非更强的模型 回到开头的问题——多个 AI 代理同改一个代码库如何不打架Sol Advisor 给出的答案是三句话所有权先行每个实施代理只拥有一组明确文件并被告知你不是唯一的人并发克制不重叠才并行共享文件永远串行验证与终审不可跳过父会话亲跑验证全新只读 Sol 终审修复后重新审查这套文件所有权模型不依赖某个模型特别聪明而是把多代理协作变成一套可检查、可留痕、可复现的流程。如果你正在用 Codex 或类似工具做多智能体开发值得把这套规则借鉴到自己的工作流里。【免费下载链接】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代理同改一个代码库不打架：Sol Advisor文件所有权模型实战
多个AI代理同改一个代码库不打架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-advisorSol Advisor 是一个面向 Codex 的 AI 多代理编排工具它用文件所有权模型让 Sol、Luna、Terra 三个 AI 代理协作修改同一个代码库而不互相覆盖。本文带你快速理解这套多智能体协作机制为什么多个 AI 同时改代码会打架以及 Sol Advisor 如何用明确的责任边界、强制验证和全新终审把混乱变成可复现的交付流程。多个AI代理改代码为什么会打架 想象你同时让 3 个 AI 代理改一个项目代理 A重构了utils.ts代理 B 基于旧版本重写同一文件 → A 的改动被悄悄抹掉代理 C把代理 A 刚加的函数当重复代码删掉了每个代理都自信地汇报已完成但合并后测试全挂根本原因没有责任边界。每个 AI 都以为自己是唯一开发者。多代理协作的关键不是模型有多强而是先定好规则谁改哪些文件、谁不能动什么、改动如何验收。Sol Advisor 就是围绕这个问题设计的。Sol Advisor 是什么Sol / Luna / Terra 三条车道 ️Sol Advisor 采用架构师 实施者 审查者的分工模式三条车道各司其职车道代理角色职责 规划Sol / High主会话需求、架构、分解、完整规格说明、验收 常规实施sol_advisor_luna_implementer执行有明确边界的常规开发任务 升级车道sol_advisor_terra_implementer处理判断密集、高风险、影响面大的任务 最终审查sol_advisor_sol_reviewer全新只读代理审查真实 diff给出ship/fix-first/rethink三个角色都是 Codex 的原生自定义代理模型与推理强度在代理模板文件中写死不靠临场发挥。你可以直接查看三个角色的定义常规车道sol-advisor-luna-implementer.toml升级车道sol-advisor-terra-implementer.toml终审角色sol-advisor-sol-reviewer.toml一个值得注意的升级规则如果 Luna 修正一次后仍暴露出这活儿根本需要更多判断力就必须升级到 Terra / High 车道而不是硬让 Luna 再试第三次。没有静默降级也没有偷偷换模型。文件所有权模型给每个AI代理划出领地 ️这是 Sol Advisor 防冲突的核心。每个实施任务提示词必须包含五个固定段落其中第二个就是所有权声明完整契约见 role-contracts.mdOBJECTIVE—— 可观察的结果和它的意义FILES AND OWNERSHIP—— 你只拥有精确的文件或模块INTERFACES—— 必须保持兼容的签名、类型、命令CONSTRAINTS—— 仓库约定、安全边界、已定决策VERIFICATION—— 精确的验证命令和预期证据而所有权段里最关键的三句话几乎逐字出现在每个实施提示词中你不是代码库里唯一的人。其他代理或用户可能正在并发编辑。保留他们的改动不要回退无关工作适配已存在的变更不要修改所有权范围之外的文件。这段约束直接写进了 Luna 和 Terra 两个代理的系统指令里见 sol-advisor-luna-implementer.toml 的developer_instructions代理出厂自带协作意识而不是依赖主会话每次口头叮嘱。并发与串行的三条规则编排技能 SKILL.md 对并发给出了非常克制的策略✅ 互不重叠的独立任务可以并行跑✅ 每个代理只领一个拥有的文件集合或有界职责❌共享文件的修改和依赖链必须串行简单说领地不重叠才允许并行重叠就排队。这一条简单规则消灭了绝大多数代理互相踩的问题。验证与终审AI 的完成不算数 ✅文件所有权只解决不打架不解决改对了。Sol Advisor 对验收同样严格1. 父会话亲自验证主 Sol 会话把实施代理的汇报当作声明而非事实必须自己检查完整 diff确认只有范围内文件被改动在主会话里重新跑一遍规格中指定的验证命令用证据对照目标、接口和约束逐条比对2. 强制的全新终审fresh review父验证通过后必须再启动一个全新的只读审查代理审查真实文件和累积 diff只允许返回三种裁决ship→ 携带验证证据宣告完成fix-first→ 委托修复、再验证、再发起一次全新审查rethink→ 修改架构不许宣称完成两条铁律防止自审自批审查者永远不修自己的问题任何修复都会使旧裁决失效。而且审查者请求只读沙箱运行时会实际观测沙箱策略——观测到不是read-only就不能宣称强制只读。这些细节都在 role-contracts.md 中有完整定义。3. 运行时留痕怀疑路由没走对用仓库自带的只读检查器查看原生线程的运行时证据sh $plugin_dir/scripts/inspect-agent-runtime.sh 子代理线程ID该工具inspect-agent-runtime.sh只输出白名单路由字段拒绝推测缺失的模型或推理强度——证据不足就停止该车道绝不脑补。三步安装上手 Sol Advisor 前提当前版本 Codex CLI或开启插件的 ChatGPT 桌面端、jq以及支持 GPT-5.6 Sol / Luna / Terra 的原生自定义代理功能。第一步添加插件市场并安装插件codex plugin marketplace add DannyMac180/sol-advisor --ref main codex plugin add sol-advisorsol-advisor第二步单独安装三个角色模板并校验插件安装不会自动注册角色文件需要运行随附的安装脚本再跑一次非破坏性的精确性检查plugin_dir$(codex plugin list --json | jq -r .installed[] | select(.pluginId sol-advisorsol-advisor) | .source.path) sh $plugin_dir/scripts/install-agents.sh sh $plugin_dir/scripts/install-agents.sh --check安装器install-agents.sh是 fail-closed 的被修改过、符号链接、内容不一致的目标文件都原样保留并报告冲突绝不静默覆盖。仓库级自检脚本 verify.sh 还会验证整套三角色架构的一致性。第三步开启新任务并调用编排技能原生代理类型在任务创建时被发现所以检查通过后务必开一个新任务主会话选择 Sol / High然后显式调用Use $sol-advisor:orchestration to build this feature, verify it, and obtain the fresh Sol review before reporting done.完整的编排流程说明在 SKILL.md角色契约与提示词模板在 role-contracts.md。总结秩序来自规则而非更强的模型 回到开头的问题——多个 AI 代理同改一个代码库如何不打架Sol Advisor 给出的答案是三句话所有权先行每个实施代理只拥有一组明确文件并被告知你不是唯一的人并发克制不重叠才并行共享文件永远串行验证与终审不可跳过父会话亲跑验证全新只读 Sol 终审修复后重新审查这套文件所有权模型不依赖某个模型特别聪明而是把多代理协作变成一套可检查、可留痕、可复现的流程。如果你正在用 Codex 或类似工具做多智能体开发值得把这套规则借鉴到自己的工作流里。【免费下载链接】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），仅供参考