context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

assumed_defect_reflection_interrupt_20260607_deep_research

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

← 返回方法论库索引 · 返回方法论区

本页是 <code>contexts/methodology/assumed_defect_reflection_interrupt_20260607_deep_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 contexts/methodology/assumed_defect_reflection_interrupt_20260607_deep_research.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）
name: assumed_defect_reflection_interrupt_20260607_deep_research
description: 假设缺陷探针中断机制
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

疑错探针：把“好像有问题”变成 Agent 运行机制

结论先说：这个机制值得做，但它的理论支撑不应写成“你预设有问题，所以问题被唯心地创造出来”。更准确的说法是：你用“可能有问题”改变了模型的观察框架、搜索目标和注意力分布，于是原先被默认执行路径压低权重的反例被提到前台。落到工程上，它应该成为一个有边界的 interrupt：暂停执行、只做取证、生成可定位反例、再带着明确的 resume packet 回到原任务。最重要的限制是，疑错不能直接触发改代码；它只能触发 evidence-backed review。没有证据的怀疑只能进入 watchlist 或补采任务。

这件事和“唯心”的关系

如果把唯心理解成“意识创造现实中的 bug”，这个类比会误导工程设计。代码缺陷不会因为一句提示而在文件系统里凭空出现。但如果把它理解成更弱、更有用的一层：对象如何被经验到，取决于观察者携带的概念框架，那么这个类比就成立。

哲学上，这更接近 observation is theory-laden。Stanford Encyclopedia of Philosophy 在讨论科学观察时指出，观察证据的价值依赖背景理论，甚至观察和证据使用本身都带有理论负载（https://plato.stanford.edu/entries/science-theory-observation/）。映射到 agent coding：同一个代码 diff，在“实现完成”框架下会被读成进度，在“可能有问题”框架下会被读成假设集合。模型没有看到新的字节，但它改变了哪些模式会被激活。

Tversky 和 Kahneman 的 framing effect 给了认知层证据：同一个选择问题换一种表述，人的偏好会系统性变化（https://psych.hanover.edu/classes/Cognition/Papers/tversky81.pdf）。这不是说现实变了，而是问题表述改变了决策表征。用户说“好像有问题”相当于把 agent 从 builder frame 切到 critic frame。

Dewey 的反思理论更贴近这个机制。他把 reflective thought 定义为对信念及其依据和后果的主动、持续、谨慎考察，并强调思考起源于疑惑、困惑或不确定；疑惑会引发进一步搜索，以确认或否定初始信念（https://www.gutenberg.org/cache/epub/37423/pg37423.txt）。这正是“疑错探针”的原型：不是宣判有错，而是制造一个足够具体的 doubt，使系统进入 inquiry。

Popper 的 critical rationalism 可以提供方法论边界：知识增长不靠证明自己对，而靠让想法暴露在批判中，并用批判替代 justification（https://iep.utm.edu/karl-popper-critical-ratiotionalism/）。对应到 AI 编程，plan 写完后最危险的状态不是“它已经错了”，而是“它还没有被有效反驳过”。疑错机制的目标不是让模型自责，而是让 plan 变得可反驳。

为什么不能只靠一句“反思一下”

LLM 论文给出一个很清楚的边界：反思有用，但纯内源自我修正不稳定。

Reflexion 表明，agent 可以把任务反馈转成语言反思，并放进 episodic memory 影响下一次尝试（https://arxiv.org/abs/2303.11366）。Self-Refine 也显示，同一个模型可以生成反馈再迭代改进输出（https://arxiv.org/abs/2303.17651）。这支持“反思产物要进入状态，而不是停留在对话里”。

但 Chain-of-Verification 的关键不是“多想一次”，而是先生成验证问题，再独立回答，最后修正，避免答案被初稿污染（https://arxiv.org/abs/2309.11495）。Huang 等人的 ICLR 2024 论文则直接提醒：没有外部反馈时，LLM 在 reasoning self-correction 中可能无法改正，甚至会变差（https://arxiv.org/abs/2310.01798）。Valmeekam 等人对 planning self-critique 的研究也发现，用 GPT-4 同时生成和验证 plan 时，false positives 会损害可靠性（https://arxiv.org/abs/2310.08118）。

所以工程规则必须很硬：疑错是一种传感器，不是裁判。它产生候选缺陷，真正能改变 plan 或代码的，是可定位证据、独立验证、测试结果、用户需求锚和原始 source。

机制命名：疑错探针

疑错探针的定义：

在 agent 从计划进入执行、或从一个执行单元进入下一个执行单元之前，临时注入“当前产物可能存在关键缺陷”的反事实假设，要求 agent 暂停原任务，只寻找可定位反例；审查结束后，以结构化 resume packet 回到原任务。

它解决的不是“审查不够多”，而是审查进入得太晚。你提到的熵增控制源头化是关键。代码一旦写下去，后续上下文会被实现细节污染，模型会开始维护自己刚刚生成的结构。源头审查应该卡在两个点：

  1. plan 已经成形但还没写代码；
  2. 一个原子执行单元刚完成但还没交给下游消费。

第一个点控制方向熵，第二个点控制传递熵。

运行流程设计

最小可行状态机如下：

PLAN_DRAFT
  -> ASSUMED_DEFECT_PROBE
  -> PROBE_DECISION
       -> pass: EXECUTE_OR_RESUME
       -> patch_plan: PLAN_DRAFT_vN+1
       -> split: UNIT_DECOMPOSITION
       -> needs_evidence: EVIDENCE_GATHERING
       -> blocked: ASK_OR_REPORT_WITH_EVIDENCE
  -> EXECUTE
  -> VERIFY_WITH_REAL_SIGNAL

ASSUMED_DEFECT_PROBE 必须输出 ledger：

probe_ledger:
  target: plan_v3 | diff_abc123 | task_card_AUP003
  assumption: "there may be a serious defect"
  findings:
    - id: F1
      status: evidence_backed_issue | false_alarm | unresolved_suspicion
      defect_class: requirement_loss | interface_mismatch | hidden_state | test_gap | overreach | unsafe_side_effect
      evidence: "path:line / command output / source URL / requirement id"
      proposed_action: patch_plan | add_test | split_unit | watchlist | no_change
  resume_packet:
    return_to: "original_task_pointer"
    plan_version: "v3 or v4"
    next_allowed_action: "execute | revise_plan | gather_evidence"

这里最重要的是三态，而不是二态。很多疑错会变成 false alarm 或 unresolved suspicion。如果把每个怀疑都当成 issue，模型会进入 false-correction loop，把本来对的设计改坏。

插入位置

第一处是方案结束、实践开始之前。这是你问题里的核心。实现上不该试图捕捉模型隐藏思维的结束，因为 hidden reasoning 不可控。应捕捉 artifact boundary：当 agent 产出 plan、task card、design doc、implementation outline，且下一步准备 Write/Edit/patch 时，进入疑错探针。

第二处是跨单元 handoff 前。workflow_unit_decomposition_and_context_injection.md 已经指出，熵管理应从 essential state 重组，不能复制上一轮 raw transcript。疑错探针应该在 handoff 前检查：下游拿到的上下文包是否丢了用户原始约束、是否把上游修辞误当需求、是否缺 locator 链路。

第三处是 review 输出准备闭环时。contexts/observations/OBSERVATIONS.md 记录过历史问题：review 只汇报不转 dispatch。疑错探针应检查 review 是否生成了 binding next action，否则它只是报告，不是控制。

第四处是高风险写入前。比如 API/schema 变更、数据库迁移、认证/支付/删除逻辑、多文件重构、用户明确指出过的敏感点。这里可以像 stop-authority 那样授予机制正式叫停权：不是“提醒一下”，而是没有过 probe 就不得继续。

Interrupt 与 Resume

基础实现不做物理回滚，只做注意力中断：

  1. 冻结当前任务指针：需求锚、plan version、已读 source、当前 write scope。
  2. 切换到 critic frame：只读计划和证据，不继续实现。
  3. 产出 probe ledger。
  4. 生成 resume packet。
  5. 回到原任务，按 next_allowed_action 执行。

这相当于插拔式 interrupt。它的关键不是让同一个上下文“记得回来”，而是让回来所需的信息被显式写入 packet。

激进实现做逻辑回退，不做破坏性 git 回退：

  1. 每个 plan artifact 都有 plan_version 和 parent_plan_version。
  2. probe 若判定 plan 级缺陷，禁止在旧 plan 上继续 patch。
  3. controller 将状态回退到 PLAN_DRAFT(parent)，从 original requirement + confirmed evidence + probe ledger 重组新上下文。
  4. 新 plan 生成后再次过 probe。

注意这里的“回退”是控制状态回退，不是 git reset --hard。它符合本仓库 git safety 的精神：保留历史，重建执行状态。

与现有 workspace 机制的接法

这套机制不需要从零发明。现有技能已经有四块承重墙：

推荐落地分三层：

第一层，prompt 纪律。给 coding agent 加一句硬约束：进入实现前，必须输出 assumed_defect_probe，且只允许 evidence-backed issue 改 plan。这个成本最低，但容易被长上下文稀释。

第二层，artifact gate。要求 task card 或 design doc 中有 probe_ledger 字段，字段为空则不能进入 implementation。这个比 prompt 稳，因为下游能机械检查。

第三层，运行时 hook。在 Write/Edit 前检查当前任务状态是否已有有效 probe。没有就 interrupt。这个最强，但实现成本最高，需要与 controller loop、trace validator 或 tool receipt 机制接合。

触发策略

不要每一步都疑错。泛化的怀疑会变成噪声，模型会疲劳式应付。触发条件应按风险密度决定：

低风险任务可以只跑轻量版：列三个最可能的失败模式，每个给 pass/issue/watchlist。高风险任务跑完整 ledger，并要求独立 verifier 或确定性测试。

失败模式

第一个失败模式是仪式化：模型输出“我检查了，没有问题”。解决办法是 ledger 必须有 defect class、evidence 和 proposed action；空泛自信不算 probe。

第二个失败模式是过度修正：模型为了回应“有问题”而改坏正确代码。解决办法是无证据不得改代码，unresolved suspicion 只能进 watchlist。

第三个失败模式是同源审查：builder 用同一套注意力盲点审自己。解决办法是高风险场景用第二 agent 或确定性 verifier；若只能单 agent，至少换 frame、限制审查范围、要求引用原始 source。

第四个失败模式是回不去主线：interrupt 后 agent 忘了原任务。解决办法是 resume packet 作为硬产物，包含 return pointer、plan version、next allowed action。

第五个失败模式是事后堆 gate：每次失败后再加一层后验审查。解决办法是把疑错放在 plan-to-code 和 unit-to-handoff 两个源头点，不把它变成 final report 前的又一张 checklist。

推荐的下一步

如果要把这份设计落地，我建议先不改全局 AGENTS/CLAUDE，而是做一个小范围 production candidate：

  1. 新建或修改一个 draft workflow skill，暂名 workflow_assumed_defect_probe.md。
  2. 在一个真实 coding loop 中只接入 plan-to-code gate，不碰所有 phase。
  3. 定义一个最小 detector：检查 task card 是否有 probe ledger，且每条 issue 是否带 evidence。
  4. 用两个历史 case 回放：一个真实有缺陷，一个无缺陷但容易被过度修正。
  5. 通过后再接入 controller loop 的 task phase plan。

版本判定：本文件是新的调研型对外承诺。按 rules/skills/workflow_version_evolution.md，它应在落定后作为 research artifact 记录一次 Y 级研究版本；当前未打 tag，因为文件尚未 commit，且工作区已有大量无关变更。

Source Index

← 返回方法论库索引 · 返回方法论区