Agent 就绪度检查

它解决的具体问题

大模型接到「帮我优化这个项目」这类模糊需求时，常常直接进入即兴发挥：没有目标边界、没有项目记忆、没有验收标准。用户其实只想优化数据库查询，Agent 却默认改起了应用代码，返工几乎是必然结果。这种缺 harness 的「模型模式」在多步骤任务、不可逆操作、涉及外部系统的场景下风险尤其高——方向偏了、红线碰了、改完无法验证。

核心机制：先盘点，再执行

该技能在复杂任务启动前插入一个就绪度检查环节，按五个维度逐项判定 ✅ / ⚠️ / ❌：

• 目标边界：交付物、范围、验收标准是否明确
• 约束规矩：红线、强制流程、兼容性要求
• 上下文记忆：调用 conversation_search、读取 MEMORY.md / 项目 memory（必须有实际检索动作，不能凭感觉）
• 工具能力：所需 MCP 连接器、Skill 是否就绪
• 验证方案：验收方法、回滚预案、基线对比

触发信号覆盖：≥3 步的复杂任务、长链路产出、不可逆操作（删除/发布/迁移）、涉及 CI/数据库/第三方 API、一句话描述但关键信息不足。指令明确、单步、无歧义的任务（如「把这个变量改名」）直接执行，不触发检查。

三种执行路径

• 路径 A（全 ✅）：Agent 模式直接执行
• 路径 B（部分缺口）：先自补（检索记忆、查工具、读规范），仍缺则用 AskUserQuestion 反问（单轮最多 4 问，推荐项置首）；不可逆操作无法补齐验证方案时暂停
• 路径 C（≥3 维 ❌）：大面积缺失，暂停并向用户报告风险

边界与注意点

补齐顺序不可颠倒：先自补，再反问，最后降级。反问只针对真正影响执行结果的缺口，避免过度打扰。执行完成后必须对照维度 5 复述验证结果，不凭「我觉得做完了」收工；有价值的决策应写回 MEMORY.md，供后续任务复用。