minimal-agent 0.8.2 → 0.9.0

package/src/ui/InputBox.js

@@ -21,6 +21,26 @@ import { Box, Text, useApp, useInput } from 'ink';
 import { useTextBuffer } from './hooks/useTextBuffer.js';
 import { usePasteHandler } from './hooks/usePasteHandler.js';
 import { useInputHistory } from './hooks/useInputHistory.js';
+// ============================================================
+//  IME 启发式（中文输入法防护）
+// ------------------------------------------------------------
+//  Ink 5.0.1 的 useInput（基于 readline）不暴露 composition event，
+//  无法原生支持 IME 状态机。本启发式做"最小可行"的兜底：
+//    1. 跟踪"短时间内连续插入"——IME 拼音→候选→提交过程中会产生
+//       一连串短间隔字符（pinyin 字母 + 单字 commit）
+//    2. 检测到 burst 后，**短时间窗口内**把 Enter 视为"IME 确认"
+//       而非"提交"（避免候选窗按 Enter 时把半截拼音+候选字提交）
+//    3. 不试图拦截或过滤 IME 字符——那是终端的活，拦了反而破坏
+//
+//  调参依据：微软拼音/搜狗拼音的 commit 节奏典型 < 100ms/char，
+//  而人手打英文 ≥ 200ms/char。500ms idle 视作 IME 结束。
+//
+//  注意：这是 best-effort，**不能 100% 解决 IME 问题**。
+//  终态方案是换掉 Ink 底层走 use-stdin 的 raw mode。
+// ============================================================
+const IME_BURST_GAP_MS = 200; // 字符间隔 < 此值视作 IME 连续输入
+const IME_BURST_MIN_COUNT = 3; // 连续 N 个字符才触发 IME 锁定
+const IME_LOCKOUT_MS = 500; // 触发后禁 Enter 提交的窗口
 function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
     const buf = useTextBuffer();
     const hist = useInputHistory();
@@ -34,6 +54,30 @@ function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
     // ✅ Delete 专用去重：只防止 Windows 双事件，不影响其他键
     const lastDeleteTime = useRef(0);
     const DELETE_DEBOUNCE_MS = 20; // 仅 Delete 键用极短防抖
+    // ✅ IME 启发式：跟踪字符插入节奏，检测 IME 草稿期间
+    //   imeBurstRef: { lastAt: 上次插入 ms, count: 当前 burst 内插入数, lastInsertEnd: 上次 IME 锁定结束 ms }
+    const imeBurstRef = useRef({
+        lastAt: 0,
+        count: 0,
+        lockoutUntil: 0,
+    });
+    /** 把"刚插入了非空非控制字符"事件喂给 IME 检测器 */
+    const noteTextInsert = useCallback((textLen) => {
+        if (textLen <= 0)
+            return;
+        const now = Date.now();
+        const s = imeBurstRef.current;
+        if (now - s.lastAt < IME_BURST_GAP_MS) {
+            s.count++;
+            if (s.count >= IME_BURST_MIN_COUNT) {
+                s.lockoutUntil = now + IME_LOCKOUT_MS;
+            }
+        }
+        else {
+            s.count = 1;
+        }
+        s.lastAt = now;
+    }, []);
     const forceRefresh = useCallback(() => {
         setRefreshCounter((c) => c + 1);
     }, []);
@@ -116,8 +160,16 @@ function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
         }
         // ---- ESC ----
         if (key.escape) {
-            if (disabled)
-                onAbort();
+            if (disabled) {
+                // try/catch 防 onAbort 异常冒泡到 Ink 渲染层（abort handler 多在 useChat 里，
+                // 内部若 throw 会黑屏；吞掉仅 stderr 注记）
+                try {
+                    onAbort();
+                }
+                catch (e) {
+                    console.error('[InputBox] onAbort threw:', e);
+                }
+            }
             return;
         }
         // ---- ✅ Ctrl+R 进入反向搜索（仅在空 buf + 非 disabled）----
@@ -135,7 +187,13 @@ function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
                 return;
             }
             if (disabled) {
-                onAbort();
+                // 同 ESC 路径，try/catch 防 onAbort 异常冒泡到 Ink 渲染层
+                try {
+                    onAbort();
+                }
+                catch (e) {
+                    console.error('[InputBox] onAbort threw:', e);
+                }
                 return;
             }
             ctrlCCountRef.current++;
@@ -152,7 +210,15 @@ function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
         //   - Alt+Enter（Mac: Option+Enter）：返回 'enter-newline' → 上面已处理为**插入换行**
         //   - Ctrl+Enter：返回 'continue' → 这里也执行**强制发送**
         //   - 粘贴期间 + Enter：返回 'enter-in-paste' → **忽略**（防误发）
+        //   - IME 草稿期间 + Enter：视为 IME 确认而非提交（启发式，见 IME_BURST_* 常量）
         if (key.return) {
+            const now = Date.now();
+            if (now < imeBurstRef.current.lockoutUntil) {
+                // IME 候选窗按 Enter → 走换行而非提交（pinyin 候选确认不打断草稿）
+                buf.insert('\n');
+                forceRefresh();
+                return;
+            }
             const text = buf.state.text.trim();
             if (text.length === 0)
                 return;
@@ -290,6 +356,7 @@ function InputBoxImpl({ onSubmit, disabled, onAbort, onClear, onCompact }) {
         // （否则 layout 永远 1 行 → ↑/↓ 失效、输入框不长高，光标只能左右）。
         if (input && !key.meta) {
             const normalized = input.replace(/\r\n?/g, '\n');
+            noteTextInsert(normalized.length);
             buf.insert(normalized);
             forceRefresh();
         }

package/src/ui/hooks/useChat.js

@@ -274,6 +274,12 @@ export function useChat(args) {
         const ac = new AbortController();
         abortRef.current = ac;
         dlog('ui', 'turn START', { input: trimmed.slice(0, 80) });
+        // 长时间运行时（如工作流 agent 步骤）的定时 token 刷新：
+        // runQuery 的 text/reasoning 事件不触发 bump，导致 StatusLine token 数
+        // 可能冻结数十秒。此定时器每 10s 强制刷新一次，确保用户看到上下文增长。
+        const tokenRefreshTimer = setInterval(() => {
+            bump();
+        }, 10_000);
         try {
             for await (const ev of runWithPlugins(trimmed, {
                 provider: args.provider,
@@ -311,6 +317,7 @@ export function useChat(args) {
         }
         finally {
             dlog('ui', 'turn END (finally)');
+            clearInterval(tokenRefreshTimer);
             setIsLoading(false);
             cancelAllThrottles();
             resetTurnState();
@@ -532,18 +539,24 @@ export function handleEvent(ev, setters) {
     switch (wf.type) {
         case 'workflow_start':
             setters.emitProgressLine?.(`▶ 工作流 ${wf.name} 开始（共 ${wf.totalSteps} 步）`);
+            // 工作流开始：立即刷新 token（可能已积累大量前置对话上下文）
+            setters.bump();
             return;
         case 'workflow_step_start':
             setters.emitProgressLine?.(`  ▶ ${(wf.index ?? 0) + 1}/${wf.total ?? '?'} ${wf.id} (${wf.kind})`);
             return;
         case 'workflow_step_end':
             setters.emitProgressLine?.(`  ${wf.ok ? '✓' : '✗'} ${wf.id}${wf.error ? `：${wf.error}` : ''}`);
+            // 步骤完成：强制刷新 token（agent/llm 步骤可能写入大量上下文）
+            setters.bump();
             return;
         case 'workflow_step_skipped':
             setters.emitProgressLine?.(`  ⊘ ${wf.id}：${wf.reason ?? ''}`);
             return;
         case 'workflow_done':
             setters.emitProgressLine?.(`✓ 工作流 ${wf.name} 完成`);
+            // 工作流结束：最终刷新（反映完整执行后的上下文量）
+            setters.bump();
             return;
     }
     // 收口到 LoopEvent：未识别的 PluginEvent type 走 default no-op

package/workflows/adaptive-research.yaml

@@ -35,8 +35,9 @@ steps:
     capture:
       content: line_report
 
-  # 3. 守门 assert
+  # 3. 守门 verify（升级自 assert，享受 verify 的 file_exists 检查器）
   - id: verify
-    type: assert
-    condition: 'fileExists("./out/notes.md")'
+    type: verify
+    checks:
+      - 'file_exists:./out/notes.md'
     onFail: "调研笔记 ./out/notes.md 未生成，检查 research 步"

package/workflows/book-review-short.yaml

@@ -92,8 +92,10 @@ steps:
           "thumbnail_prompt": "${thumb_prompt}"
         }
 
-  # 7. 守门 assert
+  # 7. 守门 verify（升级自 assert；多条 file_exists 拆成 checks 数组）
   - id: verify
-    type: assert
-    condition: 'fileExists("videos/${inputs.book}/script.txt") && fileExists("videos/${inputs.book}/meta.json")'
+    type: verify
+    checks:
+      - 'file_exists:videos/${inputs.book}/script.txt'
+      - 'file_exists:videos/${inputs.book}/meta.json'
     onFail: "脚本或 meta 未写盘，请检查 Write 工具"

package/workflows/e2e-write-greet.yaml

@@ -17,8 +17,9 @@ steps:
       args.content: note_body
 
   - id: verify_file
-    type: assert
-    condition: 'fileExists("out/${inputs.topic}/note.txt")'
+    type: verify
+    checks:
+      - 'file_exists:out/${inputs.topic}/note.txt'
     onFail: "note.txt 未落盘"
 
   - id: verify_capture

package/workflows/plan.yaml

@@ -1,189 +1,240 @@
-# ============================================================
-#  workflows/plan.yaml —— 零交互计划流程（Analyze→Verify→Synthesize→Critic→Gate→Execute→Summary）
-# ------------------------------------------------------------
-#  设计目标：① 跨模型稳（弱模型也能跑完）；② 零用户交互——全程自主；
-#            ③ 计划详细程度从 goal 自动推断，不提问。
-#  全用现有 StepKind（不改引擎）：
-#    Analyze   : analyze(agent 只读探索) → extract_findings(llm+schema 固化成可验证 claims)
-#    Verify    : verify_findings(type:vote 红队对每条 finding 反向提问证伪，存活的才进下游)
-#    Synthesize: draft_plan(llm 纯文本出计划正文) → read_existing_plan + write_plan(tool 确定性落盘)
-#    Critic    : critic_plan(skill:adversarial-review 反向提问审稿，追加进 PLAN.md)
-#    Gate      : verify(assert 守门确认 PLAN.md 生成)
-#    Execute   : execute_plan(agent 按计划执行，产出最终交付物)
-#    Summary   : exit_summary(llm 退出摘要)
-# ------------------------------------------------------------
-#  提问策略：本工作流**零交互**。计划深度从用户 goal 自动推断：
-#    - 目标含"概览/快速/简单/简短" → 快速概览
-#    - 目标含"详细/完整/分步/彻底/带风险" → 带风险回滚评估
-#    - 其他 → 详细分步（默认推荐）
-#    不询问用户选择深度——自行判断。
-# ------------------------------------------------------------
-#  注：critic 用 skill: 节点 dogfood 仓库自带的 adversarial-review skill。
-#  skill 双源查找（cwd 优先、packageRoot fallback）；异地 cwd 缺该 skill 时
-#  critic 的 onError:continue 兜底——审稿出岔不应推翻已写好的计划。
-# ============================================================
+# workflows/plan.yaml —— Plan 模式工作流
+#
+# 架构参考: Claude Code Plan Mode (commands/plan/plan.tsx)
+# 适配差异:
+#   - Claude Code 用多 sub-agent(Explore/Plan/Verification) 并行
+#   - 我们用单 TAOR 引擎 + 不同 prompt 角色扮演（共享 history 更自然）
+#   - Claude Code 有权限系统只读约束(EnterPlanMode/ExitPlanMode)
+#   - 我们通过 agent prompt 约束 + artifacts 声明达到类似效果
+#
+# 断点续执行: 由 runner 层自动处理（taskIdentity + checkpoint + capture 回放）
+# 自愈: 由 runner 的 self_heal.backoff + 内部 retry 循环控制
+
 name: plan
-description: |
-  零交互计划流程（跨模型稳、全程自主、自动推断深度）。
-  Analyze(探索+固化) → Verify(vote 红队证伪) → Synthesize(出正文+落盘)
-  → Critic(反向提问审稿追加) → Gate(assert 守门) → Execute(按计划执行) → Summary(退出摘要)。
-version: "0.4"
+description: >
+  Plan 模式：探索→设计→审查→写计划→等审批→执行。
+  5 阶段流水线，参考 Claude Code plan mode 的 Phase 1-5。
 
 inputs:
   - name: goal
     type: string
     required: true
-    description: "要做的事 / 目标"
+    description: 用户想要实现的目标
+
+self_heal:
+  backoff: 1           # step N 失败 → 回退 N 步重跑（覆盖可能有问题的产出）
+  max_retries: 2       # 每个步骤内部 retry 上限
+
+artifacts:
+  - PLAN.md            # 核心产出：实现计划文档
 
 steps:
-  # ===================== Analyze =====================
-  # [Analyze-1] 只读探索：agent 自主用 Read/Grep/Glob 摸清现状（不写盘、不副作用）
-  - id: analyze
+  # ================================================================
+  # Phase 1: Initial Understanding —— 理解需求
+  # ================================================================
+  - id: gathering
     agent: |
-      只读调研目标「${inputs.goal}」相关的代码 / 资料：用 Read、Grep、Glob 工具
-      （不要写文件、不要执行副作用命令）摸清现状，整理出 3-6 条候选关键事实
-      以及 1-3 个仍未决 / 需用户拍板的点，用简洁中文 markdown 列点返回。
-    allowed_tools: [Read, Grep, Glob]
-    capture:
-      content: analysis
-
-  # [Analyze-2] 固化成可验证 claims：llm 单轮 + output_schema（provider 不支持时由 client.ts 自动退化）
-  - id: extract_findings
-    llm: |
-      从下面的调研笔记中抽取「候选关键事实」与「未决问题」，原样保留信息、不要新增臆测。
-      调研笔记：
-      ${analysis}
-    output_schema:
-      type: object
-      additionalProperties: false
-      required: [findings, open_questions]
-      properties:
-        findings:
-          type: array
-          items: { type: string }
-          description: "每条独立成句的候选关键事实（便于逐条对抗验证）"
-        open_questions:
-          type: array
-          items: { type: string }
-          description: "仍需进一步验证 / 用户拍板的点"
-    capture:
-      findings: findings
-      open_questions: open_questions
-
-  # ===================== Verify =====================
-  # [Verify] 红队对抗：vote 对每条 finding 反向提问证伪（voter 默认倾向 refuted=true）；
-  #          存活集可能偏少甚至为空，draft 对此 graceful degrade（见其提示）。
-  - id: verify_findings
-    type: vote
-    input: "findings"
-    voters_count: 3
-    threshold: 2
-    rules: |
-      判断这条「调研结论」是否站得住脚。不要问"它对不对"，要问"它哪里是错的"：
-      是否证据不足、把假设当事实、想当然、会被反例或现有代码/资料推翻。
-      只有当你找不到任何合理反驳、且它确有依据时，才认定成立（refuted=false）。
-    capture:
-      survived: verified_findings
-      kept: kept_count
-      total: total_count
-
-  # ===================== Synthesize =====================
-  # [Synthesize-1] 生成计划正文：llm 纯文本（不开工具、不提问）——确定性、跨模型稳，
-  #   彻底避开"agent 反复调 Write"的弱模型死循环。
-  - id: draft_plan
-    llm: |
-      综合下列输入，为目标「${inputs.goal}」写一份**中文实现计划的完整 markdown 正文**
-      （直接输出正文本身：不要寒暄、不要复述要求、不要用代码围栏包裹整篇）。
+      你是一名资深的需求分析师。用户的目标是：「${inputs.goal}」
 
-      —— 通过红队对抗验证的结论（${kept_count}/${total_count} 条存活）——
-      ${verified_findings}
+      请收集实现这个目标所需的关键信息：
+      1. 目标的具体范围和边界条件
+      2. 技术约束（语言、框架、兼容性要求）
+      3. 质量要求（性能、安全、可维护性）
+      4. 优先级排序（如果涉及多个子目标）
 
-      —— 仍未决的问题 ——
-      ${open_questions}
-
-      ## 计划详细程度（自动推断，不询问用户）
-      根据用户目标「${inputs.goal}」中的关键词自动判断：
-      - 如果目标包含"概览"、"快速"、"简单"、"简短"、"简要"、"大致"等词 → 输出快速概览（高层方向与关键决策，不展开到每一步）
-      - 如果目标包含"详细"、"完整"、"分步"、"彻底"、"风险"、"回滚"、"全面"等词 → 输出带风险/回滚评估的详细计划
-      - 其他情况 → 默认输出**详细分步**计划（可执行的有序步骤，每步说清动作、涉及文件与验收点）
+      如果信息不足，使用 AskUserQuestion 工具向用户提问。
+      如果已有足够信息（从上下文或目标描述中能推断），直接输出分析结果。
 
       要求：
-      - 按上述推断的详细程度输出；
-      - "存活结论"为空时不要硬编：按目标常识给出合理的计划骨架；
-      - 凡需按需求拍板、但本工作流未询问的点（如受众/时长/范围），**自行做合理默认假设并继续**，
-        在正文开头用「## 假设（如需调整请告知）」一节列出假设，**绝不中断提问**。
-    capture:
-      text: plan_text
-
-  # [Synthesize-2] 满足 Write 的"覆盖前须先 Read"守卫：PLAN.md 已存在则先 Read；
-  #   首跑文件不存在 → Read 报错 → onError:continue 略过（不影响后续 Write 新建）。
-  - id: read_existing_plan
-    tool: Read
-    args:
-      file_path: ./PLAN.md
-    onError: continue
-
-  # [Synthesis-3] 落盘：tool:Write 确定性写入（不经 agent 循环，弱模型也稳）
-  - id: write_plan
-    tool: Write
-    args:
-      file_path: ./PLAN.md
-      content: "${plan_text}"
-
-  # ===================== Critic =====================
-  # [Critic] 反向提问审稿：dogfood 仓库自带 adversarial-review skill；onError:continue 兜底
-  - id: critic_plan
+      - 不要过度提问，对不确定的点做合理默认假设并继续
+      - 在正文开头用「## 假设」一节列出假设
+      - 最终输出结构化的需求分析（3-8 条要点）
+    capture: requirements
+    max_retries: 1
+
+  # ================================================================
+  # Phase 2: Research —— 探索代码库
+  # ================================================================
+  - id: research
+    agent: |
+      你是一名资深工程师，负责研究现有代码库以支撑「${inputs.goal}」的实现。
+
+      已知需求分析：
+      ${requirements}
+
+      请执行以下探索（并行使用 Read/Grep/Glob/RunCommand）：
+      1. 定位所有相关的源代码文件（列出路径和关键行号）
+      2. 理解现有架构和数据流（文字描述）
+      3. 找到可复用的模式和函数（格式：函数名 @ file:line — 用途）
+      4. 识别潜在的技术风险和外部依赖
+
+      输出格式：
+      ## 代码探索报告
+      ### 相关文件
+      ### 现有架构概要
+      ### 可复用资源
+      ### 风险与依赖
+    capture: research_report
+    max_retries: 1
+
+  # ================================================================
+  # Phase 3: Design —— 设计方案
+  # ================================================================
+  - id: design
+    agent: |
+      你是一名软件架构师。基于以下输入设计实现方案：
+
+      ## 用户目标
+      ${inputs.goal}
+
+      ## 需求分析
+      ${requirements}
+
+      ## 代码探索报告
+      ${research_report}
+
+      请输出完整设计方案：
+
+      ### 1. 整体架构
+      （文字描述 + 关键决策及理由）
+
+      ### 2. 文件变更清单
+      每个要修改/新建的文件一行：
+      - `path/to/file.ts` — 操作类型(new/edit/delete) — 具体改什么
+
+      ### 3. 详细变更
+      对每个文件的变更给出具体内容概要（函数签名、数据结构、逻辑流）
+
+      ### 4. 数据流和接口
+      （模块间调用关系、新增/变更的接口）
+
+      ### 5. 验证方式
+      编译命令 + 测试命令 + 手动检查项
+    capture: design_doc
+    max_retries: 1
+
+  # ================================================================
+  # Phase 4: Review —— 对抗性审查
+  # ================================================================
+  - id: review
     skill: adversarial-review
-    maxTurns: 25
     input: |
-      对当前目录下的 ./PLAN.md 做一次对抗审查（先用 Read 读它）。审完用 Edit / Write 在文件
-      末尾追加一节 "## 审稿意见（反向提问对抗审查）"，按 skill 的输出格式分
-      「🔴 真问题 / ⚪ 误报 / 🟡 待澄清」三类列出并附结论（真问题为 0 条也如实写）。
-      只新增这一节，不要重写或删改计划正文。
-    onError: continue
-
-  # ===================== Gate =====================
-  # [Gate] 守门：确认计划文件确实生成
-  - id: verify
-    type: assert
-    condition: 'fileExists("./PLAN.md")'
-    onFail: "计划文件 ./PLAN.md 未生成，检查 draft_plan/write_plan 步是否成功"
-
-  # ===================== Execute（按计划执行）=====================
-  # [Execute] 读取已落盘的 PLAN.md，agent 自主按计划步骤逐一执行，
-  #   直到完成所有任务并产出最终交付物。
-  #   onError: recover —— 执行中撞上预料之外的错误就就地降级为 agent 自适应恢复。
+      待审查的设计方案：
+      ${design_doc}
+      用户原始目标：${inputs.goal}
+    capture: review_notes
+    max_retries: 1
+
+  # ================================================================
+  # Phase 4.5: Revise —— 根据审查修订
+  # ================================================================
+  - id: revise
+    agent: |
+      你是一名资深工程师。设计方案刚经过对抗性审查，审稿意见如下：
+
+      ${review_notes}
+
+      原始设计方案：
+      ${design_doc}
+
+      请根据审稿意见修订方案：
+      - 对每个真实问题给出具体修复方案
+      - 对误报（审稿意见不合理的地方）说明为什么不改
+      - 输出最终版设计方案（完整文档，不是 patch）
+      - 保持与原设计方案相同的结构
+    capture: revised_design
+    max_retries: 1
+
+  # ================================================================
+  # Phase 5: Draft Plan —— 生成计划文档（核心产出）
+  # ================================================================
+  - id: draft_plan
+    agent: |
+      你是一名资深工程师，负责把最终设计方案写成可执行的实现计划。
+
+      ## 用户目标
+      ${inputs.goal}
+
+      ## 最终设计方案
+      ${revised_design}
+
+      请将计划写入 ./PLAN.md，内容必须包含：
+
+      # 实现计划：{goal 的简短摘要}
+
+      ## 假设（如需调整请告知）
+      （列出所有默认假设，每条一行）
+
+      ## 实现步骤
+      ### Step 1: {标题}
+      - **文件**: path/to/file.ts
+      - **操作**: 具体改什么（精确到函数/行级别）
+      - **理由**: 为什么这么改
+
+      （每个要修改的文件一个 Step，按依赖顺序排列）
+
+      ## 验证命令
+      \`\`\`bash
+      # 编译检查命令
+      # 测试运行命令
+      \`\`\`
+
+      ## 产出物清单
+      - [ ] 文件 A
+      - [ ] 文件 B
+
+      ---
+      **硬约束**：
+      ① 绝对不要输出思考过程标签
+      ② 绝对不要输出 JSON tool_call 原文
+      ③ 必须是可直接执行的实现计划（不是审查意见、不是问题列表）
+      ④ "存活结论"为空时按常识给出合理的计划骨架
+      ⑤ 凡需拍板但未询问的点自行假设并继续，不中断
+    artifacts:
+      - PLAN.md
+    max_retries: 1
+
+  # ================================================================
+  # Phase 5.5: User Review —— 用户审批（交互模式）/ 自动通过（非交互）
+  # ================================================================
+  - id: user_review
+    type: pause
+    pause:
+      message: |
+        📋 计划已生成：./PLAN.md
+        请review后回复"继续"开始执行，或提出修改意见。
+        （非交互模式将自动跳过此步骤）
+    max_retries: 1
+
+  # ================================================================
+  # Phase 6: Execute Plan —— 执行实现
+  # ================================================================
   - id: execute_plan
     agent: |
-      下面是一份已经过完整工作流验证的实现计划（./PLAN.md）。
+      你是一名资深工程师，负责执行一份已经过工作流验证的实现计划。
       请先 Read ./PLAN.md 了解完整计划内容和步骤。
-      然后严格按照计划的步骤逐一执行，直到完成所有任务并产出最终交付物。
-      执行过程中：
-      1. 如果计划中提到使用某个 skill（如 pptx/pdf/docx），先用 Read 读取对应 skills/ 目录下的 SKILL.md 了解用法
+
+      重要说明：
+      - PLAN.md 可能包含审稿意见章节（以"## 审稿意见"或"## 对抗审查结果"开头），
+        那是反向提问审查的输出，不是计划本身。请聚焦于计划正文部分提取实际任务步骤。
+      - 如果计划正文质量不佳或格式异常，请根据目标「${inputs.goal}」
+        自行推断合理的执行方案并继续推进。
+
+      执行要求：
+      1. 如果计划中提到使用某个 skill（如 pptx/pdf/docx），先用 Read 读取对应 SKILL.md 了解用法
       2. 每完成一个主要步骤后简要汇报进度
       3. 如果遇到计划中未预见的情况，自行判断合理方案并继续（不要中断等待）
       4. 全部完成后用一两句话总结产出物位置和内容
-    allowed_tools: [Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch]
-    maxTurns: 40
-    onError: recover
-    capture:
-      content: execution_result
-
-  # ===================== Exit Summary（退出摘要）=====================
-  # [Exit Summary] 用 llm 产出一句话摘要，让用户知道"做了什么、产物在哪、如何继续"。
-  #   plan 工作流到此彻底结束，之后回到正常 TUI 对话模式。
-  - id: exit_summary
-    llm: |
-      用户的目标是「${inputs.goal}」。
-      计划已制定（PLAN.md）并执行完毕。
-      执行结果：${execution_result}
-
-      请用简洁中文写一段最终摘要（3-5句话），包含：
-      1. 完成了什么
-      2. 最终产物路径（文件名和目录）
-      3. 如有后续建议也简短提及
-
-      直接输出摘要正文，不要寒暄。
-      ${execution_result ? `执行结果：${execution_result}` : '（执行步骤未产出详细结果）'}
-    capture:
-      text: summary_text
+      5. 绝不要输出 __AGENT_GIVEUP__ —— 即使计划不完美也要尽力达成目标
+    max_retries: 2
+
+  # ================================================================
+  # Phase 7: Summary —— 总结
+  # ================================================================
+  - id: summary
+    agent: |
+      工作流已全部完成。请简要总结：
+      1. 产出物位置和内容（文件路径 + 一句话描述）
+      2. 是否有遗留问题需要用户关注
+      3. 验证结果（测试是否通过、编译是否成功）
+    max_retries: 1