从主要痛点来看，为什么需要「反构图」？话说回来，

在传统的 AI 编程 Agent 范式中，通常面临两难困境：

• 预置全流程图首轮就生成完整 Task Graph。导致模型被强约束束缚，无法自由体验、灵活应对未知代码库结构，一旦偏离预设方法便难以回头。
• 完全自由模式模型随意发挥。缺乏进度追踪与偏离纠正机制，一旦跑偏，上下文已被污染，强行接管需重头开始，前序工作尽废。

「反构图」正是为了解决「自由体验与强约束接管之间的状态断层」而生：让模型先跑。跑偏了再接管，且能无损继承已完成的工作成果。 话说回来，

什么是「反构图」

「反构图」是 iceCoder 双模 L2 接管阶段的主要动作。英文对应 RetrospectiveGraphBuilder。

本质定义：在模型已经自由执行了一段代码后程序接管时「逆向重建」一张任务图，把已经完成的工作回填为 done而不是从基础开始重跑模板。

使用者意图 → 模型自由段 → 偏离触发 takeover → 反构图 → replaceGraph → 强约束段继续

正向构图 vs 反构图：主要差异对比

< tr> > < td>> < strong>> 失败后果 < / strong>> < / td>> < td>> 无,自由段降级为二级强提示 < / td>> < / tr>>

维度	正向构图	反构图
触发时机	任务首轮 初始化时	L2 Takeover 后
输入依据
进度状态初始化	全部节点
游标初始位置	第一个节点	推进到第一个未完成节点

< h2> > 反 构 的完整调用链 : M5 → M6 → M7 → M8 四 阶 段 流水线 < / h2> < p> > 反 构 不 是单一类 的 行为。是 一条严格 的 、可观测 的 加工 链路 :< / p> < pre> > < code class =" language-scss " lang =" scss "> Harness 主循环 │ ▼ evaluateAfterRound -> decision.action === 'takeover' │ ▼ bridge.commit -> supervisorPhase = 'takeover' │ ▼ applyTakeoverRecoveryMainPath │ ├─ M5: WorkspaceStateExtractor.extract -> WorkspaceSnapshot │ ├─ M6: SnapshotConfidenceEvaluator.evaluate -> confidence ∈ │ ├─ M7: RecoverySafetyChecker.check -> recoverable: boolean │ └─ M8: RetrospectiveGraphBuilder.build -> graph + markedDone │ ├─ buildGraph -> 模板图 ├─ applyKnownProgress -> 回填 done └─ advanceCursorPastDone -> 游标推进 │ ▼ GraphExecutor.replaceGraph │ ▼ enterTakeover -> 强约束段接管

< h2> 四 阶 段 详细说明 : 使用者 感知 的 安全 阀门 < / h2>

< h3> M5 — WorkspaceStateExtractor : 工作区 快照 提取 < / h3> < p> 使用者痛点 ：< em>>" 接管 时,Agent 居然还要再跑 一遍 git status 或读文件?延迟太高了,且可能干扰 工作区!"< / em>>>/ p> < p> > 职责 :从 Harness 已有的 TaskStateSnapshot + RepoContextSnapshot 中。纯启发式地拼出 WorkspaceSnapshot,>不发起任何 IO< / strong>>。其实，

< h4> 输入 数据结 构:

• task : TaskStateSnapshot -任务状态快照<

---