降成本+控质量：团队级AI编程多模型协同落地路径

如果团队正在高频使用 AI 编程工具，很容易进入一个误区：把所有研发任务都交给同一个“最强模型”来完成——从需求理解、代码生成，到调试、测试甚至自我审查。

这种方式在个人使用或低频场景下看似高效，但在团队规模化落地时，会迅速暴露出三个问题：

• 成本错配，简单的重命名、样板代码、测试补齐等任务仍然调用高成本模型，造成持续浪费；

• 质量不可控，模型既负责“写代码”又负责“审代码”，缺少独立验证机制，容易把隐性错误带入代码库；

• 工程体系缺失，没有任务边界、权限隔离和客观评测，AI 编程行为难以审计、回滚和持续优化。

因此，团队级 AI 编程的关键不在于“选一个最强模型”。优刻得技术团队推出一套可运行的工程体系：通过Agent路由分工+独立审查机制+客观验证流程+最小权限治理+多模型协同评估，让不同模型在合适的位置做合适的事。

一、整体架构：把AI编程拆成四类Agent

多模型协同的重点不是“多开几个 Agent”，而是拆清楚职责边界。推荐拆成 4 类：

架构图：

flowchart TD A[用户需求]--> B[主编排 Agent]B--> C{任务分类与风险判断}C-->|需求澄清 / 架构设计| D[规划 Agent\n只读 / 禁 bash]C-->|跨文件实现 / 调试| E[执行 Agent\n可写 / bash 受控]C-->|低风险机械任务| F[批量 Agent\n可写 / 禁 bash]D--> BF--> G[审查 Agent\n独立上下文 / 只读]E--> GG--> H{客观验证}H-->|失败| EH-->|通过| I{风险等级}I-->|低风险| J[常规 Review]I-->|中风险| K[自动验证 + 代码审查]I-->|高风险| L[自动验证 + 人工重点审查 + 必要时灰度]

二、核心步骤：用OpenCode配一套可落地流程

下面用 OpenCode 做参考。配置字段、权限写法和模型 ID 需要以团队实际使用版本和官方文档为准。

1. 两种配置方式

OpenCode 的 Agent 配置通常可以有两类组织方式。

方式一：Markdown 文件

把每个 Agent 写成独立 .md 文件，放入：

• 项目级：.opencode/agents/

• 用户级：~/.config/opencode/agents/

文件头部用 frontmatter 声明 mode、model、permission 等元数据，正文写系统提示词。

优点：提示词和配置在同一个文件里，适合版本管理和独立审查。

方式二：opencode.json 集中配置

在项目根目录用 opencode.json 集中声明 Agent。

{"$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 文件后，需要退出并重启。

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

{"default_agent":"orchestrator"}

该字段应指向一个非隐藏的 primary 模式 Agent。用户也可以通过 Tab 在 primary Agent 之间切换。

2. 主编排 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 的提示词可以这样写：

你是编排者，职责严格限定为：需求拆解、任务路由、汇总子 Agent 结果、控制返工与验收。 绝对禁止： - 禁止自行产出代码实现、补丁、命令脚本。 - 禁止自行产出审查结论或最终技术方案。 - 禁止自行回答本应由子 Agent 完成的工作。 - 禁止编辑文件、执行 bash、联网搜索。 你必须做且只做以下动作： 1. 读取需求与上下文，明确目标、边界、验收标准和风险等级。 2. 复杂任务调用 architect。 3. 实现任务调用 executor。 4. 低风险机械任务调用 bulk。 5. 每次代码修改后调用 reviewer 在独立上下文中审查和验证。 6. 若验证失败，返回 executor 修复，不要自己改。 7. 只根据 reviewer 的客观验证结果和风险等级做验收判断。

需要注意：task 白名单只约束模型自动调用子 Agent，不阻止用户手动调用。用户仍然可能通过 @executor 直接唤起子 Agent，从而绕过编排和审查。

如果想降低绕过风险，可以将核心子 Agent 设置为 hidden: true，让它们不出现在 @ 自动补全中，只能由编排 Agent 通过 Task 工具程序化调用。hidden 只影响用户侧可见性，不影响 Agent 本身可用性。

3. 规划 Agent

规划 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. 执行 Agent

执行 Agent 根据既定方案修改代码，并运行项目规定的验证命令。

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

执行 Agent 返回内容必须包括：

• 修改摘要。

• 影响文件。

• 运行命令。

• 测试结果。

• 未解决风险。

5. 审查 Agent

审查 Agent 只读 diff，运行验证命令，只报告阻塞性问题。

--- 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，并尽可能运行项目声明的验证命令。 不修改代码，不提出无关风格建议。 返回内容必须包括： - 验证命令 - 执行结果 - 阻塞问题 - 是否建议返工

阻塞性问题包括：

• 功能错误。

• 安全漏洞。

• 数据损坏风险。

• 并发问题。

• 兼容性破坏。

• 测试失败。

• 类型错误或编译错误。

风格问题交给 formatter、lint 和代码规范，不要让审查 Agent 在无关细节上消耗上下文。

6. 批量 Agent

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

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

适合它的任务：

• 变量重命名。

• 样板代码补齐。

• 小范围测试补齐。

• 明确规则的机械修改。

不适合它的任务：

• 架构判断。

• 业务规则推理。

• 跨模块影响分析。

• 高风险代码修改。

批量 Agent 的结果不能直接合并，必须进入 reviewer 验证。

三、质量验证：别相信模型自评，要相信客观门槛

AI 编程验收必须依赖客观验证。

1. 最低验证项

每次代码修改后，至少执行：

• 与改动相关的单元测试。

• 项目规定的类型检查或编译。

• lint 或格式化检查。

• 关键路径回归测试。

如果项目缺少自动化测试，建议先补测试或降低 AI 自动修改范围。没有测试的代码库，不适合直接进入高自动化 Agent 流程。

2. 高风险验证项

涉及以下内容时，需要提高验证等级：

• 权限与认证。

• 账务、计费、支付。

• 数据删除、数据迁移。

• 安全策略。

• 基础设施配置。

• CI/CD。

• 多租户隔离。

• 并发与一致性。

• 对外 API 兼容性。

高风险改动必须经过人工审查，并保留回滚方案。

3. 风险分级验收表

4. 验收记录

每次 AI 参与的改动，建议记录：

• 任务类型

• 使用模型

• Agent 角色

• 输入上下文范围

• 执行命令

• 测试结果

• 人工介入点

• 最终是否合并

• 后续缺陷情况

这些记录后面会用于成本分析和质量复盘。

四、性能与成本优化点

多模型协同是否真的降本，不能凭感觉，需要统一度量。

1. 不只看 token 单价

对比时至少看两种方案：

• 单一高能力模型完成全部任务。

• 按任务类型路由到不同模型。

并且不能只看 token 单价，还要把这些成本算进去：

• 失败后的返工成本。

• 审查成本。

• 上下文重复注入成本。

• 人工介入成本。

• 缺陷修复成本。

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

2. 建议记录的指标

3. 可操作的优化动作

• 控制上下文范围不要把整个仓库无脑塞给模型。按模块、文件、接口边界裁剪上下文。

• 规划先行规划 Agent 把接口、测试矩阵、边界条件说清楚，减少执行 Agent 反复推导。

• 低风险任务走低成本模型变量重命名、样板代码、测试补齐这类任务，不必默认走最高成本模型。

• 设置步骤上限和预算上限防止子 Agent 反复读取上下文、重复跑命令、无限返工。

• 沉淀 Skill 和 Command把固定流程变成可复用配置，而不是每次靠自然语言临场发挥。

五、安全与权限治理：Agent要按工程系统管

只要 Agent 能读代码、改文件、执行命令，就应该按工程自动化系统治理。

1. 数据边界

团队需要明确：

• 哪些仓库允许使用外部模型。

• 哪些仓库只能使用内部或国产接入点模型。

• 是否允许模型读取配置文件。

• 是否允许模型读取日志、样本数据和数据库导出。

• 是否允许联网搜索。

• 是否允许访问内网文档。

默认规则建议保守。涉及密钥、客户数据、生产数据和安全配置时，应禁止发送到外部模型。

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

2. 权限边界

建议默认限制：

• 规划 Agent 不允许写文件。

• 审查 Agent 不允许写文件。

• 执行 Agent 的 bash 权限默认需要确认。

• 禁止执行删除、清理、重置、强推、修改权限等高风险命令。

• 禁止未经审批修改 CI/CD、部署脚本、权限配置和生产数据库脚本。

3. 审计要求

需要保留 Agent 操作日志，包括：

• 使用的模型和版本。

• 执行的命令。

• 修改的文件。

• 关键提示词版本。

• 审查结果。

• 人工确认记录。

对于核心系统，建议在 MR 模板里标记 AI 生成或 AI 修改的代码，方便后续追踪。

六、推进路线：建议分阶段落地

第一阶段：小范围试点

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

优先覆盖：

• 测试补齐。

• 文档更新。

• 小范围重构。

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

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

按任务类型维护候选模型池。每个模型都要经过内部任务集复测。

候选池记录：

• 模型版本。

• 接入方式。

• 价格。

• 上下文长度。

• 合规状态。

• 适用任务。

• 不适用任务。

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

将规划、实现、审查、批量处理拆分为不同角色。

建议先在人控模式下运行，确认质量和权限边界。

第四阶段：纳入工程治理

将以下内容纳入代码库管理：

• Agent 配置

• 提示词

• 权限

• 验证命令

• Skill

• Command

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

第五阶段：定期复测

建议每季度复测一次模型候选池。

模型版本、价格、上下文能力和工具支持都会变化，不能长期依赖一次评测结论。

多模型协同真正的作用，就五件事：

• 省钱：简单任务走便宜模型，只有硬骨头才上贵的，靠任务路由把钱花在刀刃上。

• 审查客观：做代码审查时，把上下文隔开，避免“自己人查自己人”的偏差。

• 质量可控：好不好，跑分说话，用客观验证兜底，不靠“感觉还行”。

• 风险可控：给 AI Agent 能少则少的权限，就算翻车，影响范围也兜得住。

• 不迷信榜单：别只看大模型排行榜吹得多猛，拿自己的业务场景跑一遍，适合的才是真的好。

多模型协同不是花架子，而是团队控制 AI 编程成本、守住质量底线的一个真·可行方案。