核心用法
Checkmate 是一种迭代式任务完成框架，专为需要质量保障而非一次性最佳尝试的场景设计。其工作流程分为四个阶段：
1. Intake（需求转化）：将模糊任务转化为机器可检验的明确标准（criteria.md）
2. Worker（执行生成）：子代理根据标准产出初稿（output.md）
3. Judge（质量评判）：对照标准自动检验，生成通过/失败判定（verdict.md）
4. Feedback Loop（反馈迭代）：若未通过，将问题写入 feedback.md 并重新触发 Worker，直至 PASS 或达到最大迭代次数
用户通过触发词如 checkmate: TASK、keep iterating until done、quality loop 激活该技能。主代理需创建独立工作空间、写入任务描述，并孵化长期运行的 Orchestrator 子代理（默认 4 小时超时，最多 20 轮迭代）。
显著优点
- 质量可量化：将主观要求转化为客观检验标准，避免"差不多就行"
- 自主迭代：无需人工介入即可多轮优化，支持数十轮、数小时的长时间运行
- 失败可控：明确的最大迭代次数防止无限循环，失败时提供完整轨迹
- 模块化设计：Intake、Worker、Judge 职责分离，便于替换或扩展
潜在缺点与局限性
- 启动成本高：需要预定义明确标准，不适合探索性、开放式任务
- 资源消耗大：每轮迭代都需重新生成完整输出，Token 和时间成本显著
- 评判偏差风险：Judge 的检验逻辑若设计不当，可能导致误判或过度严苛
- 延迟交付：质量保障以时间为代价，不适合即时响应场景
- 上下文累积：长迭代中 feedback 文件膨胀，可能影响后续生成质量
适合人群
- 需要结构化输出的内容创作者（技术文档、代码生成、报告撰写）
- 对输出质量有硬性标准的企业流程自动化
- 愿意用时间换质量的非紧急任务场景
- 具备一定技术背景、能定义清晰验收标准的高级用户
常规风险
- 迭代耗尽：复杂任务可能在 20 轮内仍无法达标，需人工介入调整标准或策略
- 标准僵化：过度具体的标准可能扼杀创造性解决方案
- 子代理故障：Worker 或 Orchestrator 超时/崩溃会导致任务中断，依赖
sessions_send的回调机制恢复 - 成本失控：长时运行的多代理系统产生显著 API 费用，需监控预算
- 反馈循环污染：某轮的错误反馈若被后续迭代继承，可能导致偏差放大