[产品方向] 以高级模型规划、快速廉价模型执行为核心的多模型协作

## 背景

Aaron Levie 在[这条讨论](https://x.com/levie/status/2079402164988895293)中总结了 Cursor 的多模型实验：

> Few moments in a large task genuinely require frontier intelligence, such as the original decomposition, the design decisions, and certain trade-offs. Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it.

Cursor 用一组 Agent 根据 835 页 SQLite 手册重建 SQLite，最终通过了 100% 的 held-out test suite；不同模型组合的成本相差约 15 倍。这个数字来自特定实验，不应直接当成 Cindy 的收益承诺，但它清楚说明：**复杂任务的所有阶段并不需要相同等级的智能，模型组合本身就是产品和系统架构的关键变量。**

Cindy 已经具备多 Provider、多模型、子代理模型设置和 Orca Worker 等基础能力，但目前更接近“允许用户选择不同模型”，还没有把“高级模型消除歧义、快速廉价模型规模化执行”收敛为一套明确的协作策略。

## 产品方向

Cindy 应把多模型配合工作作为核心方向，而不是默认让一个高级模型包办整段任务。

建议形成三段式协作闭环：

1. **Planner / Orchestrator：高级模型**
- 理解目标、补齐必要上下文；
- 拆解任务、识别依赖与并行机会；
- 做架构、产品、风险和关键取舍；
- 为每个 Worker 生成明确的输入、边界、交付物和验收条件。

2. **Worker：快速、廉价模型**
- 按明确任务契约执行代码修改、搜索、测试、资料整理、批量转换等工作；
- 可以并行处理相互独立的子任务；
- 不自行扩大 scope，不承担仍有高歧义或高风险的决策。

3. **Review / Escalation：高级模型或满足门槛的审查模型**
- 汇总 Worker 结果，核对验收条件和跨任务一致性；
- 对失败、冲突、低置信度或超出边界的任务重新规划；
- 必要时升级回高级模型执行，而不是让廉价模型在错误方向上持续消耗 token。

核心不是“尽可能使用便宜模型”，而是**把高级智能集中用在真正需要判断力的节点，把已经消除歧义的大量工作交给高吞吐模型完成。**

## 设计原则

### 1. 路由策略由代码和显式配置保证

- 模型角色、能力门槛、升级条件和预算约束应由可测试的 policy / state machine 决定；
- 不依赖 prompt 让模型自由判断“现在该换哪个模型”；
- 实际使用的 Planner / Worker / Reviewer 模型、Provider 和升级原因必须可追踪。

### 2. 先建立清晰的任务契约，再切换模型

Planner 给 Worker 的交接至少应包含：

- 目标与非目标；
- 可访问的上下文和文件范围；
- 依赖关系；
- 允许自主决定的范围；
- 交付物格式；
- 验收命令或判断标准；
- 失败、冲突和信息不足时的升级规则。

Worker 不应默认继承整段冗长历史。应传递完成任务所需的最小稳定上下文，兼顾准确性、上下文窗口、缓存命中和成本。

### 3. 能力与风险优先于价格

- 只有模型能力、工具支持、上下文窗口和结构化输出契约均满足任务要求时，才允许进入 Worker 候选集；
- 涉及架构决策、安全、权限、隐私、数据删除、发布等高风险节点，默认保留高级模型或人工确认；
- 廉价模型连续失败、偏离验收条件或产生跨 Worker 冲突时，应有界升级，不能无限重试。

### 4. 用户看得见，也能控制

至少应展示：

- 当前任务由哪个角色、模型和 Provider 执行；
- 为什么发生模型切换或升级；
- 各角色的耗时、token 和费用；
- 内容是否会发送给第二个 Provider。

用户应能关闭自动分层、锁定模型，或选择偏质量 / 平衡 / 偏成本策略。跨 Provider 路由必须尊重隐私与数据边界，不能静默发生。

### 5. 用真实任务评测，不凭直觉优化

建立一组代表 Cindy 使用场景的 benchmark，同时比较：

- 全程使用高级模型；
- 高级 Planner + 廉价 Worker；
- 高级 Planner + 廉价 Worker + 高级 Review；
- 不同并发数、上下文交接方式和升级策略。

至少记录：

- 任务完成率与验收通过率；
- 最终结果质量和返工次数；
- 首次有效结果时间、总耗时；
- input / output / cache token；
- 实际费用；
- Worker 失败率、重试率和升级率；
- Planner 的拆解质量及跨 Worker 冲突率。

15 倍只作为外部案例。Cindy 的目标值应由自己的 benchmark 得出，任何成本优化都不能以明显降低完成质量为代价。

## 建议分阶段推进

### P0：建立评测基线

- 选择长代码任务、调研任务、批量处理任务和高风险变更等代表性场景；
- 固化任务输入、验收标准和成本口径；
- 对比单高级模型与多模型组合，找出最适合先落地的任务类型；
- 明确质量、成本、时延和升级率的门槛。

### P1：收敛多模型编排内核

- 在 Maker / Orca 层建立显式的 Planner、Worker、Reviewer 角色与模型策略；
- 定义结构化任务契约、状态机和有界升级机制；
- 支持按能力、成本、时延、Provider 和用户策略选择 Worker；
- 统一记录任务级模型路由、费用与结果。

### P2：形成用户可理解的产品体验

- 提供简单策略档位，并为高级用户开放角色级模型配置；
- 在协同界面展示实际执行角色、模型、状态和升级路径；
- 给出本次多模型协作相对单模型基线的成本 / 时延解释；
- 对跨 Provider、隐私边界和高风险操作提供明确提示。

### P3：基于数据持续优化

- 根据 benchmark 和真实匿名指标优化拆分粒度、并发度和模型组合；
- 识别哪些任务值得使用高级 Worker，哪些任务适合廉价模型；
- 评估 planner / reviewer 复用、上下文压缩和结果缓存等进一步优化。

## 与现有工作的关系

- makecindy/cindy#67：让 Codex 子代理在保留完整上下文时使用指定模型，是角色级模型配置的基础能力；
- makecindy/cindy#108：多协议 Provider adapter 与请求级诊断，是扩大 Worker 模型池和观测实际路由的基础能力；
- makecindy/cindy#68：已确认需要暴露子代理模型设置，但长期应把单一设置项纳入整体模型策略；
- makecindy/cindy#82：协同模式必须披露实际执行通道；未来同样需要披露 Planner / Worker / Reviewer 的真实模型与状态。

本 Issue 关注的是跨这些能力之上的**任务阶段分层和多模型协作策略**，不重复定义具体 Provider 协议或单个子代理模型设置。

## 非目标

- 不承诺所有任务都能获得 15 倍成本收益；
- 不默认把所有执行工作都下放给最便宜模型；
- 不让 LLM 仅凭 prompt 无约束地选择模型或 Provider；
- 不在缺少 benchmark 和可观测性的情况下直接大规模自动路由；
- 不以牺牲结果质量、隐私或高风险操作安全为代价追求 token 成本。

## 需要讨论

1. Cindy 第一批 benchmark 应优先覆盖哪些真实任务？
2. Planner 和 Reviewer 是否默认使用同一高级模型？
3. Worker 的自动升级应由哪些信号触发？
4. 面向普通用户应只暴露“质量 / 平衡 / 成本”策略，还是直接展示角色级模型？
5. 多 Provider 协作的隐私提示和默认边界应如何定义？

## 参考

- [Aaron Levie：Multi-model agentic systems clearly are the future](https://x.com/levie/status/2079402164988895293)
- [Cursor：多模型组合重建 SQLite 的实验](https://x.com/cursor_ai/status/2079256614238814551)

Start by reviewing the existing Maker and Orca orchestration layers and the related issues #67, #68, #82, and #108. Define benchmark tasks and acceptance metrics first, then determine the required Planner, Worker, and Reviewer state transitions, routing policy, escalation rules, and observability needed to compare multi-model strategies.

Written by the indexing model from the issue text.