如果团队正在高频使用 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 编程成本、守住质量底线的一个真·可行方案。