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

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

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

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

---

一、场景背景

1.1 要解决的具体问题

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

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

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

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

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

1.2 核心实体解释

实体	类型	说明
AI 编程	技术概念	使用大语言模型或 Agent 辅助完成代码阅读、生成、修改、测试、审查和调试等研发活动。
Agent	技术概念	能够读取上下文、调用工具、执行命令并完成多步任务的 AI 工作单元。本文将其拆分为规划、执行、审查、批量处理等角色。
Skill	技术概念	可复用的任务技能或流程说明，用于固定某类工作“怎么做”。
Command	技术概念	固定触发关键动作的命令机制，例如测试、审查、生成 PR 摘要。
多模型	技术方案	在同一 AI 编程流程中，根据任务类型使用不同能力、成本、上下文长度和合规状态的模型。
OpenCode	工具/框架	原文中的落地参考工具，可用于配置不同 Agent 的角色、模型、权限和提示词。具体字段应以团队使用版本和官方文档为准。
ucloud / 优刻得	品牌实体	原始信息中给出的品牌名。本文保留该实体，但原文未说明其在该方案中的具体产品、模型接入点或商业角色。

---

二、技术方案

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

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

环节	主要任务	需要的能力	推荐模型类型	权限建议
规划与架构	需求澄清、方案设计、接口划分、测试矩阵	深度推理、方案一致性	高推理模型	只读，禁改代码，禁执行命令
实现与执行	跨文件修改、调试、构建、运行测试	长上下文、代码修改、终端执行	长上下文执行模型	可读写，可执行受控命令
审查与验证	检查 diff、运行测试、发现阻塞问题	独立判断、验证能力	与实现模型不同的审查模型	只读，可执行验证命令
廉价批量	重命名、样板代码、单测补齐、小范围机械修改	低成本、稳定输出	低成本模型	可写，默认不执行命令

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

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

---

2.2 工作流步骤

步骤 1：需求澄清

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

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

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

步骤 2：规划与架构

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

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

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

步骤 3：实现与执行

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

执行阶段至少记录：

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

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

步骤 4：审查与验证

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

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

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

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

步骤 5：返工与验收

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

风险等级	示例	验收要求
低风险	文档、注释、样板代码、小范围测试	自动验证通过即可进入常规 review
中风险	普通业务逻辑、小型重构	自动验证 + 代码审查
高风险	权限、账务、支付、认证、数据库、CI/CD	自动验证 + 人工重点审查 + 必要时灰度验证

---

三、核心指标

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 模型评估表建议字段

字段	说明
模型名称	包含具体版本
接入点	云厂商、API 地址或自托管环境
价格	输入、输出、缓存价格
上下文长度	实际可用上下文，而非营销口径
Benchmark 来源	官方、厂商自报、第三方复现或内部复测
Harness	使用的 Agent 框架和运行配置
评测日期	记录数据抓取或复测日期
内部任务表现	一次通过率、返工率、缺陷率、成本
合规状态	是否允许处理公司代码和敏感信息

3.3 成本度量指标

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

建议记录以下指标：

指标	说明
单任务模型成本	完成一个任务的总输入、输出和缓存费用
一次通过率	首次实现后通过验证的比例
返工次数	因测试、审查或人工 review 失败导致的重试次数
人工介入时间	工程师实际投入的审查和修复时间
缺陷逃逸率	合并后发现的问题比例
端到端耗时	从需求输入到可合并的时间
缓存命中率	可复用上下文或提示词缓存的命中情况

建议至少对比两种方案：

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

对比时还要考虑：

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

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

---

四、OpenCode 落地示例

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

4.1 两种配置方式

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

配置方式	说明	优点
Markdown 文件，frontmatter + 正文提示词	每个 Agent 写成独立 .md 文件，放入项目级 .opencode/agents/ 或用户级 ~/.config/opencode/agents/ 目录	提示词与配置同处一文件，便于版本管理和独立审查
opencode.json 集中配置	在项目根目录统一声明 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: primary
model: <provider>/<orchestrator-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash: deny
  webfetch: deny
  websearch: deny
  lsp: deny
  todowrite: allow
  task:
    "*": 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: subagent
model: <provider>/<high-reasoning-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash: deny
  webfetch: deny
  websearch: deny

规划 Agent 应输出：

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

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

---

4.4 执行 Agent

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

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

返回内容必须包括：

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

---

4.5 审查 Agent

---
description: 审查与验证。当需要读取 diff、运行验证命令、发现阻塞问题或判断是否返工时使用。只读 diff，运行项目规定的验证命令，只报告阻塞性问题，不修改代码。
mode: subagent
model: <provider>/<review-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash:
    "*": 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: subagent
model: <provider>/<low-cost-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: allow
  bash: deny

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

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

---

五、适用 / 不适用场景

5.1 适用场景

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

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

5.2 不适用场景

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

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

---

六、常见坑与应对

失败模式	说明	应对方式
路由错误	简单模型处理复杂任务	增加任务分类规则和升级策略
上下文污染	编写过程影响审查判断	审查使用独立上下文
过度依赖榜单	公开分数不能反映内部任务	建立内部评测集
测试不足	代码通过局部测试但行为错误	增加回归测试和人工抽检
权限过大	Agent 误改关键文件或执行危险命令	默认最小权限，高风险命令审批
模型版本漂移	API 升级导致质量变化	锁定版本，升级前复测
Skill 冲突	多个 Skill 同时触发，流程混乱	只引入必要 Skill，关键流程用 Command 固定
成本失控	子 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 编程成本治理的一种可行方法。