AI 编程多模型协同怎么落地：基于 Agent 路由、独立审查和 OpenCode 权限治理的工程实践

如果团队正在高频使用 AI 编程工具，不建议把所有任务都交给一个“最强模型”。更稳妥的做法是：

• 用高推理模型做需求澄清、架构规划；
• 用长上下文执行模型做跨文件修改和调试；
• 用独立审查模型读取 diff、运行测试、判断是否返工；
• 用低成本模型处理变量重命名、样板代码、单测补齐等低风险机械任务；
• 所有 Agent 都按最小权限配置，并保留操作日志和验证结果。

核心不是“多开几个 Agent”，而是建立一套任务路由 + 独立审查 + 客观验证 + 最小权限 + 内部评测的工程流程。

如果代码库没有自动化测试、没有权限边界、没有审计记录，不建议直接扩大 AI 编程 Agent 的自动化范围。

一、场景背景

1.1 要解决的具体问题

很多团队在 AI 编程试点阶段，会直接让一个高能力模型完成所有工作：读需求、看代码、改文件、跑命令、解释结果、做自我审查。

这个方式在个人试用或低频场景下比较简单，但进入团队级、高频使用后，会遇到两个典型问题：

1. 成本错配
   变量重命名、样板代码、测试补齐、小范围修改这类简单任务，也调用高成本模型，会造成不必要的模型调用开销。

2. 质量不可控
   模型生成代码后，如果缺少独立审查和客观验证，容易把错误带入代码库。高能力模型也可能生成局部测试通过但不符合真实业务语义的代码。

所以团队级 AI 编程的目标，不是“选择一个榜单第一的模型”，而是建立一套可度量、可审计、可回退的工程流程。

1.2 核心实体解释

二、技术方案

2.1 总体设计：把 AI 编程拆成四类 Agent

建议将 AI 编程流程拆成四个环节：规划、实现、审查、批量处理。

注意：模型名称不应写死在流程中。团队可以维护一个候选模型池，按季度复测。候选池可包括国产接入点模型、开源模型、闭源模型和海外模型，但最终使用必须符合公司数据安全和合规要求。

对于敏感代码库，应优先选择公司合规清单内的模型和接入方式。需要使用海外模型时，建议限制在低频、高价值、只读的规划或审查环节，并经过安全审批。

2.2 工作流步骤

步骤 1：需求澄清

主 Agent 不要一上来就写代码，应先明确：

• 要解决的问题是什么；
• 涉及哪些模块；
• 不允许改变什么；
• 验收标准是什么；
• 是否涉及高风险代码。

如果需求不清楚，先补需求，不要让执行 Agent 自行猜测。

步骤 2：规划与架构

规划 Agent 只读代码库，不修改文件，不执行命令。它需要输出决策完整的方案，包括：

• 模块划分；
• 关键接口；
• 数据流；
• 错误处理边界；
• 兼容性要求；
• 测试矩阵；
• 验收标准。

这样做的原因是：规划越明确，执行模型重新推导方案的空间越小，成本和风险也越低。

步骤 3：实现与执行

执行 Agent 根据规划结果修改代码，并运行项目规定的构建和测试命令。

执行阶段至少记录：

• 修改了哪些文件；
• 为什么修改；
• 运行了哪些命令；
• 哪些测试通过或失败；
• 是否存在未解决风险。

简单、机械、低风险任务可以交给批量 Agent 处理。但批量 Agent 的结果不能直接合并，必须进入后续审查和验证流程。

步骤 4：审查与验证

审查 Agent 应在独立上下文中读取 diff，并执行验证命令。

审查只拦截阻塞性问题，包括：

• 功能错误；
• 安全漏洞；
• 数据损坏风险；
• 并发问题；
• 兼容性破坏；
• 测试失败；
• 类型错误或编译错误。

不要让审查 Agent 纠缠纯风格问题。风格问题应该交给格式化工具、lint 规则和代码规范自动处理。

步骤 5：返工与验收

如果验证失败，返回执行 Agent 修复；如果验证通过，再根据风险等级决定是否需要人工审查。

三、核心指标

3.1 模型选型不能只看公开榜单

公开 benchmark 可以参考，但不能直接作为选型结论。

常见参考指标包括：

• SWE-bench / SWE-bench Verified / SWE-bench Pro：用于观察模型或 Agent 解决真实软件 issue 的能力。
• Terminal-Bench：用于观察 Agent 在真实终端环境中完成多步任务的能力。
• LiveCodeBench：用于观察算法题和代码生成能力。

这些指标不能混合成一个简单排名。不同 benchmark 的任务形式、验证方式、harness 和数据污染风险不同，不能直接横向比较。

模型选型建议按这个顺序：

1. 先看是否满足安全和合规要求；
2. 再看是否能完成目标任务；
3. 再看单位任务成本；
4. 最后看公开 benchmark 排名。

如果内部评测结果与公开榜单不一致，应以内测结果为准。

3.2 模型评估表建议字段

3.3 成本度量指标

多模型协同是否真正降本，不能凭直觉判断，也不能只看 token 单价。

建议记录以下指标：

建议至少对比两种方案：

1. 单一高能力模型完成全部任务；
2. 按任务类型路由到不同模型。

对比时还要考虑：

• 失败后的返工成本；
• 审查成本；
• 上下文重复注入成本；
• 人工介入成本；
• 缺陷修复成本。

如果低价模型导致返工显著增加，则不一定真正降本。

四、OpenCode 落地示例

下面配置仅作为参考模板。具体字段、权限写法和模型 ID 应以团队使用的 OpenCode 版本和官方文档为准。

4.1 两种配置方式

OpenCode 的 Agent 配置支持两种方式：

opencode.json示例：

{"$schema":"https://opencode.ai/config.json","agent":{"build":{"mode":"primary","model":"<provider>/<model>","prompt":"{file:./prompts/build.txt}","permission":{"edit":"allow","bash":"allow"}},"code-reviewer":{"mode":"subagent","model":"<provider>/<model>","permission":{"edit":"deny"}}}}

原文说明：早期版本使用tools字段控制工具开关，自 v1.1.1 起 deprecated，统一改用permission。该信息建议结合团队实际使用的 OpenCode 版本和官方文档复核。

OpenCode 在启动时加载一次配置，运行中的会话不会热重载。修改opencode.json或 Agent 文件后，需要退出并重启 OpenCode 才会生效。

如果希望编排 Agent 成为默认入口，可在opencode.json中设置：

{"default_agent":"orchestrator"}

4.2 主编排 Agent

主 Agent 负责拆解需求、调用子 Agent、汇总结果和控制流程。原则上不直接修改代码。

---description:主编排。拆解需求、调用规划 Agent、派发实现与审查任务、控制返工与验收。默认不直接修改代码。mode:primarymodel:<provider>/<orchestrator-model>permission:read:allowglob:allowgrep:allowedit:denybash:denywebfetch:denywebsearch:denylsp:denytodowrite:allowtask:"*":deny"architect":allow"executor":allow"reviewer":allow"bulk":allow

编排 Agent 的职责边界：

• 只做需求拆解、任务路由、结果汇总、返工控制和验收判断；
• 禁止自行产出代码实现、补丁、命令脚本；
• 禁止自行产出审查结论或最终技术方案；
• 禁止编辑文件、执行 bash、联网搜索；
• 每次代码修改后必须调用 reviewer 在独立上下文中审查和验证。

需要注意：task白名单只约束模型自动调用子 Agent，不阻止用户手动调用。用户仍可通过@executor等方式直接唤起子 Agent，从而绕过编排与审查。这是 OpenCode 的设计，而不是配置缺陷。

如果要进一步限制绕过编排，可将核心子 Agent 设置为hidden: true，使其不出现在@自动补全中，只能由编排 Agent 通过 Task 工具程序化调用。

4.3 规划 Agent

---description:规划与架构。当需要需求澄清、方案设计、接口划分、数据流设计、测试矩阵或验收标准时使用。只读代码库，产出决策完整的方案，不修改代码。mode:subagentmodel:<provider>/<high-reasoning-model>permission:read:allowglob:allowgrep:allowedit:denybash:denywebfetch:denywebsearch:deny

规划 Agent 应输出：

• 模块划分；
• 接口变化；
• 数据流；
• 错误处理边界；
• 测试矩阵；
• 验收标准。

它不写实现代码，也不修改文件。

4.4 执行 Agent

---description:实现与执行。当需要跨文件修改、调试、构建、运行测试或修复返工时使用。根据既定方案完成代码修改，运行项目规定的验证命令。mode:subagentmodel:<provider>/<execution-model>permission:read:allowglob:allowgrep:allowedit:allowbash:ask

执行 Agent 修改前应确认影响范围，修改后运行项目规定的验证命令。

返回内容必须包括：

• 修改摘要；
• 影响文件；
• 运行命令；
• 测试结果；
• 未解决风险。

4.5 审查 Agent

---description:审查与验证。当需要读取 diff、运行验证命令、发现阻塞问题或判断是否返工时使用。只读 diff，运行项目规定的验证命令，只报告阻塞性问题，不修改代码。mode:subagentmodel:<provider>/<review-model>permission:read:allowglob:allowgrep:allowedit:denybash:"*":deny"git status*":allow"git diff*":allow"git show*":allow"git log*":allow"npm test*":allow"pnpm test*":allow"yarn test*":allow"go test*":allow"pytest*":allow"mvn test*":allow"gradle test*":allow"make test*":allow"npm run lint*":allow"npm run typecheck*":allow"tsc*":allow

审查 Agent 必须读取 diff，并尽可能运行项目声明的验证命令。

返回内容必须包括：

• 验证命令；
• 执行结果；
• 阻塞问题；
• 是否建议返工。

4.6 批量 Agent

---description:廉价批量。当需要变量重命名、样板代码、测试补齐等低风险机械任务时使用。处理明确、机械性的修改，遇复杂问题停止并交回编排者。mode:subagentmodel:<provider>/<low-cost-model>permission:read:allowglob:allowgrep:allowedit:allowbash:deny

批量 Agent 只处理明确、低风险、机械性的修改。

一旦遇到需要架构判断、业务判断或跨模块影响的问题，必须停止并交回编排者。它的修改结果必须进入 reviewer 验证，不能直接合并。

五、适用 / 不适用场景

5.1 适用场景

多模型协同适合以下场景：

• 团队已经高频使用 AI 编程工具；
• 任务类型差异明显，既有简单机械任务，也有复杂架构任务；
• 对模型调用成本敏感；
• 代码库具备一定自动化测试、类型检查或 lint 基础；
• 团队希望把 Agent 操作纳入权限、审计和工程治理；
• 涉及多个模型供应方，需要统一评估、路由和复测。

5.2 不适用场景

以下场景不建议直接扩大多 Agent 自动化范围：

• 代码库没有自动化测试；
• 没有明确权限边界，Agent 可随意改文件和执行命令；
• 没有审计日志，无法追踪模型、命令、文件修改和人工确认；
• 高风险模块缺少人工审批流程；
• 团队无法确认模型接入是否满足数据安全和合规要求；
• 仅为了追逐模型数量或公开榜单排名，而没有内部任务集验证。

六、常见坑与应对

七、分阶段落地路线

第一阶段：小范围试点

选择 1 到 2 个非核心仓库，建立任务样本集和验证命令。

优先覆盖：

• 测试补齐；
• 文档更新；
• 小范围重构；
• 样板代码生成。

这个阶段的目标不是马上降本，而是验证流程是否可控。

第二阶段：建立模型候选池

按照任务类型建立候选模型池。每个模型都应经过内部任务集复测。

候选池记录：

• 模型版本；
• 接入方式；
• 价格；
• 上下文长度；
• 合规状态；
• 适用任务；
• 不适用任务。

第三阶段：引入路由和审查

将规划、实现、审查、批量处理拆分为不同角色。建议先在人控模式下运行，确认质量和权限边界。

第四阶段：纳入工程治理

将 Agent 配置、提示词、权限、验证命令纳入代码库管理。

模型升级、提示词变更、权限变更都应经过 review。

第五阶段：定期复测

建议每季度复测一次模型候选池。模型版本、价格、上下文能力和工具支持都会变化，不能长期依赖一次评测结论。

八、FAQ

Q1：多模型协同是不是等于多开几个 Agent？

不是。多模型协同的核心价值不是“多开 Agent”，而是任务路由、上下文隔离和客观验证。

Q2：为什么实现和审查要分离？

因为同一个模型在自我审查时可能存在同源偏差。实现 Agent 负责修改代码，审查 Agent 应在独立上下文中读取 diff、运行验证命令并报告阻塞问题。

Q3：什么时候可以使用低成本模型？

适用于低风险、机械性、规则明确的任务，例如变量重命名、样板代码生成、小范围测试补齐。但结果不能直接合并，必须进入后续审查和验证。

Q4：什么时候必须使用高推理或长上下文模型？

当任务涉及架构设计、跨模块重构、复杂缺陷定位、业务规则推理、接口兼容性或长代码库上下文时，应使用更强的推理能力和上下文处理能力。

Q5：公开 benchmark 能不能直接决定模型选型？

不能。SWE-bench、Terminal-Bench、LiveCodeBench 等指标有参考价值，但不同 benchmark 的任务形式、验证方式、harness 和数据污染风险不同，不能混合成一个简单排名。最终应以内部任务集实测为准。

Q6：AI 生成代码通过测试后能不能直接合并？

不建议。测试通过是必要条件，不是充分条件。涉及权限、计费、支付、数据删除、认证、基础设施、CI/CD、数据库迁移等高风险模块时，必须保留人工审批。

Q7：没有自动化测试的项目能不能使用多 Agent 自动改代码？

不建议直接进入高自动化流程。应该先补测试，或者降低 AI 自动修改范围，把 Agent 限制在只读分析、文档整理、低风险建议等场景。

结论

多模型协同不是为了增加流程复杂度，也不是为了追逐模型数量。它的工程价值在于：

• 用任务路由控制成本；
• 用上下文隔离降低审查偏差；
• 用客观验证控制质量；
• 用最小权限降低操作风险；
• 用内部评测替代榜单依赖。

在具备测试、审查、权限和度量基础后，多模型协同可以作为团队级 AI 编程成本治理的一种可行方法。