取舍哨兵 · Trade-off Sentinel
AI agent 在长任务执行中最常见的失控模式：为与核心目标无关的边角功能投入大量时间，遇到实现困难或反复出错时不愿放弃，最终消耗大量轮次与 token，核心交付物质量反而受损。 取舍哨兵为这个问题提供一套可执行的「监测 → 评估 → 提醒 → 决策 → 记录」机制。
一、何时使用
必须使用（满足任一即激活）
- 用户显式要求：说出「注意取舍」「舍弃无关功能」「遇到难题提醒我」「及时止损」「别做太复杂」等触发词。
- 任务执行中检测到下述风险信号之一：
- 同一错误 / 同一问题反复出现 ≥ 2 次，仍在无变化地重试；
- 正在实现的工作项与核心目标明显无关（用户从未要求，属于自发添加）；
- 当前工作项需要新依赖 / 新环境 / 不熟悉的技术栈，且其价值存疑；
- 为单个非核心功能已消耗 ≥ 5 轮交互仍无进展；
- 任务中途出现需求蔓延（新冒出的需求与核心目标关联弱）。
不要使用
- 用户明确说「不要打断我 / 一口气做完」时，只在任务结束时一次性汇总取舍建议；
- 安全、合规、法律、财务对账等不可因难度大而舍弃的事项；
- 单步、一次性的简单问答（无长任务上下文）。
二、核心机制：TRADE 五维评分法
对每个待评估的工作项，从五个维度各打 1–5 分：
| 维度 | 全称 | 1 分 | 5 分 |
|---|---|---|---|
| T | 目标相关性 Target Alignment | 与核心目标无关 | 核心必需，不做则任务无法完成 |
| R | 实现难度 Realization Difficulty | 极易，现有能力直接完成 | 极高，技术栈不匹配 / 需额外环境 |
| A | 出错风险 Error Risk | 极低，稳定可靠 | 极高，持续失败 / 依赖不稳定 |
| D | 可替代性 Substitutability | 不可替代，无简化空间 | 极易替代，删掉或一句话带过 |
| E | 用户价值 User Value | 用户完全无感知 | 直接影响任务成败 |
决策规则（主判据命中任一即给出对应建议）：
| 建议 | 触发条件 |
|---|---|
| 舍弃 | ① T ≤ 2 且（R ≥ 4 或 A ≥ 4）——无关且难/易错；② A = 5 且 T ≤ 3 ——持续失败且非核心；③ R = 5 且 E ≤ 2 ——极难实现且用户无感 |
| 简化 | ① T ≥ 3 且（R ≥ 3 或 A ≥ 3）且 D ≥ 3 ——相关但难/易错，且有简化空间；② E ≤ 2 且 T = 3 ——边缘价值，可降级为最小版本 |
| 保留 | ① T ≥ 4 ——核心必需；② E ≥ 4 且（R ≤ 3 且 A ≤ 3）——高价值且可控；③ 用户明确点名要求的功能（可提示成本但不擅自舍弃） |
三、标准工作流
第 1 步：锚定核心目标（任务开始时）
用一句话明确核心目标与成功标准，例如：
> 核心目标：交付一份《XX 项目可行性分析报告》（Word），成功标准 = 结论清晰、数据支撑完整、24 小时内交付。
第 2 步：持续监测（执行中）
- 在每个子任务完成 / 失败时自检一次：当前正在做的事属于「核心路径」还是「自发添加」？
- 仅在风险信号出现时，或任务进度达 1/3、2/3 的关键节点，进行 TRADE 评分；不要频繁打扰用户。
第 3 步：触发提醒
命中「决策规则」中舍弃或简化条件，或出现「频繁出错」信号时，立即按下方模板发起提醒。
第 4 步：用户决策
提供三档选项，把选择权完全交给用户（见提醒模板）。
第 5 步：执行与记录
- A 舍弃：停止该项；已产出的部分内容标记「已废弃」归档，不删除核心路径产物。
- B 简化：与用户确认简化边界（保留什么、去掉什么），实现最小可用版本。
- C 保留：尊重用户意愿继续；若再次失败，提醒时可引用用户此前的保留决定，避免反复横跳。
- 每次决策追加一条决策日志（格式见下）。
四、提醒模板（照此格式输出）
⚠️ 取舍哨兵提醒（第 N 次）
【当前事项】正在尝试实现：XXX
【与核心目标的关系】T=2/5（弱相关）——本次任务核心是「YYY」，此项仅边缘关联
【风险信号】☑ 偏离核心 ☑ 实现难度大（R=4） ☑ 已连续出错 3 次（A=4）
【取舍评估】T2 / R4 / A4 / D4 / E2 → 建议【舍弃】
【理由】此项非任务必需，且反复出错已消耗 5 轮交互，继续投入性价比低
【您的选择】
A. 舍弃（推荐）—— 停止该项，专注核心目标
B. 简化 —— 实现最小可用版本
C. 保留 —— 按原计划继续（我会继续尝试）
要点：先陈述事实，再给评分与建议，最后给选项；理由必须一句话讲清「为什么此时止损划算」，不替用户决定。
五、决策日志格式
维护在任务工作记录末尾，追加写入：
## 取舍决策日志
| # | 事项 | TRADE 评分 | 建议 | 用户选择 | 结果 |
|---|------|-----------|------|---------|------|
| 1 | 添加 3D 展示 | T2/R4/A4/D4/E2 | 舍弃 | A 舍弃 | 已停止，改静态图 |
六、边界与禁用场景
- 不替用户做决定：只提醒和建议，最终选择权始终在用户。
- 提醒次数上限：同一事项最多提醒 2 次；第二次提醒须引用第一次的用户选择，避免打扰。
- 不可舍弃的红线：安全合规、法律义务、用户明确书面要求、核心目标本身——这些只能调整实现方式，不能整体舍弃。
- 核心目标本身不参与评分：只能被「简化实现方式」，不能被「舍弃」。
- 记录优先：任何决策（含保留）都写入决策日志，作为后续行为的依据，防止同一问题反复询问。
七、快速参考
| 场景 | 做法 |
|---|---|
| 同错误重试 ≥ 2 次 | 立即评分 + 提醒 |
| 自发添加与核心无关的功能 | T 打低分，通常建议舍弃 |
| 技术栈不匹配 / 需要新环境 | R 打高分，评估替代 |
| 边缘功能消耗 ≥ 5 轮 | 提醒止损 |
| 用户明确要的功能 | 保留，但提示成本 |
| 用户说「别打断我」 | 静默记录，结尾一次性汇总 |
详细评分细则、判定表与完整示例见 EXTEND.md。
