plan-and-execute 预览实装 — 冻结计划、执行前授权与成本预估

日期: 2026-09-01 阶段: Phase 3 - AML 调查 Copilot 标签: #plan-and-execute #hitl-approval #cost-budget

核心问题

Day 78 选定了 4 个 UX 模式，Plan-and-Execute 是其中"同意（Consent）轴"的核心。当前 AmlCopilot.tsx 里的 AgentPlanPanel 只是个占位步骤条——它把三屏工作流的标题（证据汇集/类型学比对/SAR 草稿）当成"计划"画了出来，但没有步骤背后的工具、没有成本预估、没有"批准后才执行"的授权门。今天把它升级成真正的 plan-and-execute 预览。

回答三件事：(1) "执行前计划面板"该呈现什么——步骤、每步调用的工具、预估 token 成本、预计命中的证据源；(2) 为什么必须批准后才执行，而不是边规划边执行（这不只是体验问题，更是 prompt 注入下的控制流完整性安全问题）；(3) 怎么把成本预估接到本仓库已有的 src/agent/orchestrator/budget.ts，让"计划面板的预估"和"运行时的硬上限"是同一套口径。

主线案例锚定：Plan-then-Execute 的"冻结计划"安全性质（agentic-patterns 2026）、LangChain Plan-and-Execute 的 Planner/Executor 分离、以及 AML 场景下"执行前授权 = 监管要求的 Consent 环节"。

关键内容

A. 执行前计划面板：四要素与数据流

plan-and-execute 的核心是先产出一个完整 Plan 对象，再逐步执行（LangChain Plan-and-Execute Agents；agentic-patterns Plan-Then-Execute）。Planner 把高层目标分解成有序步骤列表，Executor 逐步执行。AML Copilot 的计划面板要展示四个要素：

计划预览的数据流（执行前一次性算出整个 Plan，不触发任何副作用）：

用户选定 case → buildPlan(case)               # 纯函数，不调 LLM、不写状态
  ├─ for each step in STEPS:
  │    ├─ tools     = planTools(step)          # 声明式：该步用哪些工具
  │    ├─ evidence  = previewEvidence(step,case)# 预跑规则引擎/预检索，列出预计证据源
  │    └─ costEst   = estimateStepCost(step,case)# B 节：估 token → USD
  ├─ totalCost = Σ costEst                      # 汇总
  └─ return Plan{ steps[], totalCost, withinBudget }

计划面板渲染 Plan → 调查员看到「3 步 / 调用 4 工具 / 预估 $0.012 / 预计引用 7 笔证据」
        │
        ▼
   ┌─────────────┐  批准   ┌──────────────────────┐
   │ 等待人工批准 ├───────►│ 冻结 Plan → 逐步执行   │
   └─────┬───────┘         └──────────────────────┘
         │ 退回/修改
         ▼
   调整范围（如缩小窗口/换 case）→ 重新 buildPlan

关键：buildPlan 是纯预览——预跑规则引擎（assessCase 本就是确定性纯函数）和预检索来"预告"证据源，但不生成 SAR、不调 LLM、不写审计轨迹。这让"看计划"零成本、可反复，符合 Day 78 反直觉③里"低信任用户该先看全计划建立心智模型"。

B. 成本预估算法：与 budget.ts 同口径

计划面板的"预估 $0.012"必须和运行时 budget.ts 的 costCapUsd 硬上限是同一套口径，否则"预估说便宜、运行时被 cap 掐断"。budget.ts 现有 addCost(usd) / assertCostOk()——运行时按实际 token 累加；计划面板需要的是执行前的预估。两者用同一公式，只是预估用估计 token、运行时用实际 token。

token 成本公式（输入/输出分开计价，这是 2026 计价的铁律——输出 token 因自回归生成，单价通常是输入的 2-5×；reasoning 模型的 thinking token 与输出同价或更高）：

estimateStepCost(step, case):
  in_tok  = sys_prompt_tok                       # 固定系统提示
          + evidence_tok(case)                   # 证据交易序列化进 prompt 的 token
          + retrieved_tok(step)                  # RAG 检索片段（类型学知识）
  out_tok = expected_output_tok(step)            # 该步预期产出（SAR 段落 ~600 tok/段）
  # 输入输出分开计价；reasoning 步额外计 thinking token
  cost_usd = in_tok  * price_in_per_Mtok  / 1e6
           + out_tok * price_out_per_Mtok / 1e6
  return cost_usd

数值示例（以 Claude Sonnet 量级 $3/$15 per Mtok 计，仅示意）：SAR 草稿步证据 2,500 tok + 系统提示 500 tok + 检索 1,000 tok = 4,000 输入 tok；6 段 × 600 tok ≈ 3,600 输出 tok。

• 输入：4,000 × $3 / 1e6 = $0.012
• 输出：3,600 × $15 / 1e6 = $0.054
• 单步预估 ≈ $0.066

反直觉洞察①（成本结构倒挂：输出比输入贵，预估错算输入是常见坑）：直觉认为"把一大堆证据交易塞进 prompt = 主要成本"，于是优化重点放在压缩输入。但 SAR 生成是输出密集型——上面例子里输出 3,600 tok 贡献 $0.054、输入 4,000 tok 只贡献 $0.012，输出占总成本 82%。原因是输出 token 单价是输入的 5×（自回归逐 token 生成 vs 输入单次前向）。所以预估算法里漏算或低估 out_tok 比低估 in_tok 危险得多——若把 SAR 段数从 6 估成 3，预估直接腰斩。计划面板的预估必须以"预期产出段数 × 每段 token"为主轴。

预估接 budget.ts：计划面板算出 totalCost 后，先对照 BudgetConfig.costCapUsd 判 withinBudget——若预估已超 cap，计划面板红字预警 + 禁用批准按钮，把"超预算"在执行前就拦住，而不是运行时 assertCostOk() 抛错半途中断（半途中断更糟：已花的钱打水漂 + 产出残缺的 SAR）。

C. 为什么"批准后才执行" = 控制流完整性，而非只是体验

"批准后才执行"直觉上是个体验/合规选择（让人类同意）。但 plan-then-execute 的冻结计划还有一层硬安全性质：agentic-patterns(2026) 的核心论点是——Planner "generates a fixed sequence of tool calls before it sees any untrusted data"（在看到任何不可信数据前就定下固定的工具调用序列），执行器"runs that exact sequence. Tool outputs may shape parameters, but cannot change which tools run"。

这叫控制流完整性（control-flow integrity）：恶意的中间结果（如被投毒的证据数据）能影响工具的参数，但不能改变调用哪些工具。对 AML 至关重要——若一个被污染的交易备注能诱导 Agent 中途去调用"对外发送"或"修改账户状态"的工具，那就是灾难。冻结计划 = 把"调用哪些工具"这条控制流在执行前就锁死、且经人工批准，中途无法被数据劫持。

agentic-patterns 同时诚实标注了局限："Content of outputs can still be poisoned"——冻结的是控制流，不是内容。被投毒的数据仍可能让 SAR 正文出现错误叙述。这正是为什么 Day 80 的置信度信号 + evalChecks 的 hallucination 检查仍不可少：plan-and-execute 防的是"工具调用被劫持"，防不了"输出内容被污染"，两者是互补防线。

反直觉洞察②（plan-and-execute 的安全价值不在"省钱"而在"锁控制流"）：常被宣传为"先规划能省 40-70% 重试成本、降 ~60% 幻觉"（agentic-patterns 引 Parisien et al. 2024）。但在受监管的 AML 场景，它更大的价值是安全而非成本——冻结的工具调用序列让 prompt 注入无法把 Agent 引向未授权操作。一个常见误判是"我的 case 数据是内部可信的，不需要冻结计划"——但 AML 证据交易的备注/对手名等字段恰恰可能携带攻击者注入的指令（钱骡账户的交易备注是攻击者可控的）。只要 prompt 里有任何外部可控文本，控制流完整性就值钱。

设计要点/决策表

对本项目的落地

• 升级 AmlCopilot.tsx 的 AgentPlanPanel：从"占位步骤条"改成 plan-and-execute 预览面板——每步展示工具列表 + 预估成本 + 预计证据源；底部展示 totalCost 与 withinBudget 状态；批准按钮在 withinBudget=false 时禁用。当前注释"Plan-and-Execute 预览模式的轻量示意（参考 Fuselab 2025-08）"正式兑现。
• 新建 src/aml/planPreview.ts：导出 buildPlan(case) → Plan{ steps, totalCost, withinBudget } 与 estimateStepCost(step, case) → number（B 节公式）。预跑复用 assessCase（typology.ts，已是确定性纯函数）来 previewEvidence，列出预计引用的证据交易——与 draftSar 的 citedTxIds 口径对齐。
• 接 src/agent/orchestrator/budget.ts：buildPlan 读取 BudgetConfig.costCapUsd 判 withinBudget；运行时（P3 接 LLM 后）走 addCost()/assertCostOk() 兜底。两处共享同一 token→USD 公式（抽到 planPreview.ts 的 tokenCostUsd(inTok, outTok, priceIn, priceOut)，运行时也调它）。
• 诚实标注：W1-W2 计划面板的"成本预估"是静态估算（token 数按经验常量估，单价按当时主流模型示意），非真实计费；真实 LLM 接入与实际计费为 P3 后续，不谎称已实现。planPreview.ts 头注写明这是执行前预估、与运行时实际计费同公式但不同 token 来源。
• 控制流完整性留给 P3 工具接入：当前原型工具是确定性规则引擎（无注入面），C 节的"冻结计划防注入"在接入真实 LLM + 外部工具后才有实际防护意义；W1-W2 先把"批准后才执行"的授权门 + 冻结 Plan 的数据结构落好，注释标注其安全意图。

参考资料

1. LangChain — Plan-and-Execute Agents：Planner 分解目标为有序步骤、Executor 逐步执行的双组件架构 (持续；配近期 agentic-patterns 来源)
2. agentic-patterns.com — Plan-Then-Execute Pattern：Planner "generates a fixed sequence of tool calls before it sees any untrusted data"；"runs that exact sequence... cannot change which tools run"；控制流完整性；"Content of outputs can still be poisoned"；规划提升完成率 40-70%、降幻觉 ~60%（引 Parisien et al. 2024） (2026)
3. arXiv 2509.08646 — Architecting Resilient LLM Agents: A Guide to Secure Plan-then-Execute Implementations：plan-then-execute 的安全实现指南，按步最小权限/沙箱 (2025-09)
4. Silicon Data / pricepertoken — LLM Cost Per Token 2026：输入/输出分开计价，输出单价为输入 2-5×；reasoning thinking token 与输出同价或更高 (2026)
5. 本仓库 src/agent/orchestrator/budget.ts（addCost/assertCostOk/costCapUsd）、src/aml/typology.ts（assessCase 纯函数）、src/aml/sarDraft.ts（citedTxIds 口径）、src/components/aml/AmlCopilot.tsx（AgentPlanPanel） (2026-06)

SOTA 检查 (2026-06-11)

• plan-and-execute 在 2026-06 是主流 agentic 模式之一：LangChain、agentic-patterns、futureagi(2026) 口径一致——规划/执行分离能提升完成率、降成本、加安全；HITL 检查点"在规划后、执行前"已是标准位置（approved/rejected/escalated 三路 + 审计轨迹）。本日 WebSearch 未见推翻此模式的主流方法。
• "冻结计划 = 控制流完整性"是 2025-2026 的安全升温点：arXiv 2509.08646(2025-09) 专门写 plan-then-execute 的安全实现；agentic-patterns(2026) 明确"工具调用序列预提交、不可被数据劫持"。这是相对早期纯"省 token"叙事的实质演进——安全价值被抬到与成本同等。
• 成本计价的输入/输出倒挂是稳定事实：2026 全行业输出 token 单价为输入 2-5×；预估算法必须以输出为主轴（反直觉①），此结构短期不会反转（自回归生成的物理成本决定）。
• 过时警示："边规划边执行（ReAct 纯交错）在所有场景更优"的早期认知已被修正——对"动作集已知、参数随数据变"的任务（AML 调查正是如此），plan-then-execute 在成本/安全上更优；纯 ReAct 适合动作集高度不确定的探索型任务。
• 待跟踪：实装（2026-09）时复核主流模型最新单价（$/Mtok 半年内会变），把 tokenCostUsd 的默认单价更新为届时主流模型口径；并复核是否出现"计划本身也要计 planner token 成本"的更细预估方法。