plan-arbiter

计划仲裁器

将相互竞争的计划收敛为一个可执行方向。保留最佳思路，驳回薄弱假设，并给出清晰的交接方案，而不是拼凑出一团乱麻。

工作流

1. 收集源计划。
2. 将每个计划规范化为可比较的主张。
3. 结合彼此的计划以及真实代码库或任务背景进行交叉审查。
4. 选出胜出的计划、合并为更好的混合方案，或将计划退回修改。
5. 给出一份执行交接方案，其中包含验证关卡和被否决的替代方案。

除非用户明确要求在决策后实施，否则规划阶段只读。

收集源计划

接受以粘贴文本、本地文件、会话 ID、转录文件路径、PR、评论、可视化计划链接或聊天记录形式提供的计划。在可能的情况下，解析原始材料，以便查看最终摘要中可能遗漏的提示词变更和假设。

如果计划仍在编写中，且用户要求等待，则持续监控，直到计划完成或遇到阻碍。如果无法解析某个计划，则根据现有计划文本继续，并将缺失的来源标记为风险。

规范化

对于每个计划，提取：

• 目标和范围。
• 关键假设和未解决的问题。
• 拟议的文件、模块、API、数据结构、UI 状态或工作流。
• 实施顺序。
• 验证策略。
• 回滚或迁移方面的注意事项。
• 成本、复杂度和预期执行者的适配度。

不要因内容冗长而给予额外评价。优先考虑具体、扎根于真实代码且坦诚说明权衡的计划。

交叉审查

像审查其他有能力的 Agent 所写的计划一样审查每个计划：

• 检查它是否满足用户的实际请求。
• 在相关且可用的情况下，依据代码库、文档、测试、屏幕截图或外部系统核实主张。
• 找出隐藏依赖、缺失测试、存在风险的顺序、含糊步骤、不必要的范围，以及难以撤销的决定。
• 留意互补优势：一个计划可能架构更好，另一个计划则有更好的迁移或验证路径。
• 将计划质量与执行者偏好区分开来。即使另一个模型给出了最好的评审意见，成本更低、速度更快的执行者仍可能是实施的正确选择。

如果计划规模较大、代码库范围较广，或决策受益于分别进行技术和产品评审，则使用子 Agent 进行独立审查。

决策

选择以下三种结果之一：

• **采纳：**基本按原计划选定其中一个方案。
• **混合：**组合具体内容，形成更强的执行计划。
• **先修改：**要求再次进行规划，因为两个计划都忽略了关键约束，或依赖尚未解决的决定。

按以下顺序打破平局：

1. 正确性及与用户请求的契合度。
2. 是否基于真实文件、API、测试、数据和 UI 行为。
3. 首次实施是否更简单，且不会阻碍预期的未来发展。
4. 验证和回滚方案是否更完善。
5. 在质量达标的前提下，执行所需的 token 和时间成本是否更低。

交接

返回一份简洁的决策备忘录：

Decision
- Adopt Plan A / Hybrid / Revise first.

Why
- The deciding evidence and tradeoffs.

Execution Plan
- Ordered steps with files or surfaces to touch.

Borrowed From Other Plans
- Useful pieces kept from non-winning plans.

Rejected
- Ideas intentionally not taking, with reasons.

Verification
- Tests, browser checks, screenshots, CI, review, or deploy checks needed.

Executor Recommendation
- Which agent/model should implement and why.

如果用户已要求执行，且所选路径明确，则简要报告决策后，按选定计划继续。否则，停在交接环节并请求批准。