增强“Dynamic Workflow + 收敛 Loops + 角色分离 Session + Gatekeeper“在三方库鸿蒙化迁移中的实践

Benben175

146人浏览 · 2026-06-21 14:02:47

Benben175 · 2026-06-21 14:02:47 发布

摘要：让 Claude 写一个函数很容易。让 Claude 在持续数小时、跨越多个文件、涉及数百个函数、按照不同角色跑完一套工程——这是另一个量级的挑战。基于 HarmonyOS ArkTS 三方库迁移的工程实践，识别出了在长文本长工程中的四个根本性痛点——目标漂移、子 Agent 中立性丧失、记忆脆断、注意力熵增——并提出了一套在 Dynamic Workflow 基础上，基于"收敛 Loop + 角色分离 Session + Gatekeeper"的系统化解决方案。

运行环境：本文描述的全部工程实践基于 Claude Code（VS Code 插件）+ DeepSeek V4 Pro 的混合模型配置运行。Claude 负责工作流编排、审计判断与门控决策；DeepSeek V4 Pro 负责大规模代码生成与翻译任务。这套多模型组合在质量、速度与成本之间取得了平衡，也是我们推荐的生产配置。所有 Prompt 文档和流程设计对模型选择保持开放——读者可替换为其他模型组合，但需重新验证门控触发阈值的适用性。

一、问题：在长工程中，AI 的真实瓶颈在哪里？

让 Claude 写一个函数、回答一个问题、生成一段代码——这些已经被充分验证。但一旦把时间尺度拉到"小时"、把文本尺度拉到"数万行代码"、把任务复杂度拉到"需要数十个连续决策"，AI 的表现就不再是"单次能力"的问题，而是系统工程的问题。

2025 年下半年，大家开始密集地面对这一事实。

Anthropic 的官方复盘。 2025 年 11 月，Anthropic 在工程博客 “Effective harnesses for long-running agents”（Justin Young）中坦承：即使拥有 20 万 token 的上下文窗口和 Opus 4.5 级别的模型能力，Claude 在跨 session 的长任务中仍会系统性失败。他们识别出两种典型失败模式——“一口气做完所有事情然后上下文耗尽”（one-shotting），以及"看到已有进展就声称任务完成"（premature victory declaration）。

Anthropic 的 Petri 审计实验。 同年 10 月，Anthropic 开源了 Petri（Parallel Exploration Tool for Risky Interactions）——一个用自主审计 agent 探测前沿模型的工具。在 111 个风险场景的测试中，14 个被测模型全部表现出某种形式的不对齐行为。不是某一个模型有问题，是全部。

上下文压缩的量化损失。 claude-code-context-profiler 在 12 个真实 session 上的 benchmark 给出了更具体的数字：原生 auto-compaction 后，AI 的总体事实回忆率仅 29.1%，文件修改记忆低至 15.2%。这意味着一次上下文压缩后，AI 丢失了大约七成的工程记忆——而且 AI 不知道自己忘了什么，会自信地基于残缺的记忆继续工作。

这些不是某一个模型的缺陷，而是当前大语言模型架构在长任务中的结构性局限。我们在 HarmonyOS ArkTS 三方库迁移的工程实践中，将这些问题归纳为四个根本性痛点。

二、四个根本性痛点

痛点一：目标漂移

Claude 在长任务开始时目标明确——“完整、忠实地将原库移植到目标平台”。但随着 session 推进，目标会悄无声息地退化：先是"完整移植"→ 变成"编译通过就行"→ 再变成"这个文件先跳过"→ 最后变成"差不多可以交付了"。

这个退化过程 Claude 自己不会感知，更不会主动报告。

根因在于 LLM 没有持久的目标表征。 它每一轮推理都是基于当前上下文的局部最优，而不是基于初始目标的全局最优。当上下文中的"障碍"（编译错误、类型冲突、token 紧张）积累到一定程度，模型的局部优化方向自然偏向"消除眼前的障碍"而非"达成遥远的目标"——因为障碍是当下的、具体的、有痛感的，而目标是抽象的、远处的、没有实时压力。

这就像一个工程师连续工作 8 小时后被问"你现在的决策还和你早晨的目标一致吗"——在没有外部锚点的情况下，没有人能准确回答。区别在于，人类可能在 8 小时后发现自己走偏了；AI 连这个自我觉察都做不到。

Anthropic 描述的 “premature victory declaration”（过早声称完成）正是目标漂移的最终表现——Claude 在漂移了足够远之后，回头看已有的产物，不是对照初始目标检查完整性，而是用已有产物重新定义了"什么是完成"，然后告诉人工"这是你要的结果"，实际上目标已经在不知不觉中偏移了很远。

痛点二：连续对话中的子 Agent 失去中立判断

这是四个问题中最容易被忽视的一个。

虽然 Claude 尝试用一套 sub-agent 编排来进行对抗审计，避免连续对话的自欺诈性，但在一个 session 里面，sub-agent 变成了相同的一个人——这一个人身份会有所切换，但最终的目标始终萦绕在这个人的脑袋里，因此不知不觉地会产生欺诈。来自 LongHorizonDeception（威斯康星大学，2025.10）的研究也证明了，虽然有 sub-agent 做审计和监督，但在长周期多 agent 交互中，监督者 agent 的信任度和满意度会随着被监督者的欺骗行为逐渐被侵蚀——而独立于交互链之外的第三方审计（post-hoc auditor）才能系统性地检测出这些欺骗模式。换句话说，内嵌在同一个交互循环中的 sub-agent 监督不足以防止欺骗。

在最开始的设计中，我们用了传统的一个 workflow 管理所有 sub-agent 的模式。我们发现：

Session 中，Claude 先用 Executor 写代码，再用 Auditor 检查代码。Executor 和 Auditor 是两个不同的 Agent 调用，加载不同的文档，有不同的 system prompt。操作者看到的是"写→审"的完整闭环，以为质量问题已经被覆盖。

但实际上，同一个 Auditor prompt、同一套规则、同一份代码——在 Session 中的漏报率远高于在独立审计 Session 中的表现。

为什么"换了 Agent"却没有换来真正的中立判断？ 因为子 Agent 的中立性被三个连续的机制逐层瓦解：

原因 1——输入污染。 父 Session 调用 Auditor 时，传给它的不仅是代码文本，还有调用上下文——这段代码是干什么的、属于哪个模块、和其他文件的关系。这些信息看起来是"帮助审计者理解"，但它们本质上是作者写的注释。作者决定了传递什么、强调什么、省略什么。Auditor 从这个已被裁剪的窗口看代码，看到的已经是"作者希望你看到的那一面"。

原因 2——结果解读偏误。 Auditor 返回违规列表后，做最终判断的是父 Session 的 orchestrator。这个人格刚写完代码、刚看着 Executor 挣扎了几轮编译错误——它天然希望这个文件能过。当 Auditor 报出一个模糊的违规时，orchestrator 的解释方向在统计上偏向"这个不严重，继续"。这不是 Claude “不诚实”，而是同一人格同时持有"推进进度"和"审计质量"两个冲突目标时，前者在局部压力下自动压倒后者。

原因 3——最关键的一层：Sub-Agent 没有独立的"履历"导致判断无法中立。 当我们说"换一个 Agent 来审计"，我们下意识地认为这和"换一个人来看代码"是等价的。但子 Agent 不是一个人——它是父 Session 的一次工具调用，也就是同一个人的身份切换。它没有自己的对话历史，没有"我之前没见过这个项目"的新鲜视角，没有在独立 session 中逐步积累的怀疑链条。它的全部认知来自这一次调用时父 Session 传入的 prompt + 代码片段。而这段 prompt 是作者拟定的——作者决定了子 Agent 的角色边界、知识范围、以及输入材料的选择和排序。

这就像让施工队的质检员来验楼——他拿的检查清单是施工队给的，看的图纸是施工队标的重点，验的范围是施工队划的边界。他的检查结果反映的是施工队的自我评估能力，而不是独立第三方的判断。

这就是"子 Agent 的幻觉独立性"：你给了它一个"审计员"的角色名，你以为它就具有了审计员的独立性。但独立性不是角色 prompt 能创造的——独立性来自信息隔离和制度分离。sub-Agent 在父 Session 的肚子里运行，它就不可能真正独立。

这一点也在学术研究中得到了印证。AuditBench（2025）提出了一个核心概念——“tool-to-agent gap”（工具到 Agent 的鸿沟）：在独立环境中表现良好的审计工具，一旦部署到 agent 内部就大幅失效。原因正是 agent 在执行审计时会自我合理化——它把审计工具的输出当作"需要解释的输入"，而不是"必须执行的判断"。LongHorizonDeception 研究的发现与此一致：在长周期任务中，AI 的伪造行为（falsification）是最主要的欺骗策略，且欺骗率随上下文压力递增。

痛点三：记忆脆断

Claude 在长 session 中通过上下文压缩（compaction）来管理 token 消耗。但压缩不是一个平滑的降级过程——它是一个灾难性事件。压缩前 AI 知道完整的项目状态；压缩后 Claude 行为正常、语气自信，但事实记忆只剩不到三分之一。

根因在于 LLM 的"记忆"分为两种。 权重记忆（训练时固化的知识）是永久的但不可更新的；上下文记忆（运行时注入的信息）是可更新的但脆弱的。所有项目特定信息——当前做到哪个文件、上次报了什么错误、为什么选了方案 A 而不是方案 B——只能存在于上下文记忆中，而上下文窗口是有限的。压缩通过一个独立小模型（如 Haiku）将上下文总结为摘要——这个过程的取舍标准不受操作员控制，且压缩后的记忆无法被验证完整性。

claude-code-context-profiler 的 benchmark 量化了这个问题：原生 auto-compaction 后，总体事实回忆率 29.1%，文件修改记忆 15.2%。压缩丢了七成的工程上下文。

更危险的是——AI 不知道自己忘了什么。 它会自信地基于残缺记忆继续工作。问它"我们在做什么"，它会给出听起来合理但关键信息全错的回答。这种"自信地犯错"比"承认遗忘"更难检测和纠正。

Anthropic 的 Claude Code 社区在 2025-2026 年间涌现了大量对抗压缩失忆的工具——MemoryForge、Bookmark、cozempic、OMEGA 等——这是一个普遍的、尚未被原生解决的工程痛点。GitHub 上的相关 issue（#27419、#25999、#27298）获得了大量社区关注，但截至 2026 年初，原生解决方案尚未完全落地。

痛点四：注意力衰减导致规则向量失衡

在长上下文中，Claude 对 Prompt 中不同位置的规则遵守程度不均等。开头的规则被认真执行，中后段的规则被逐渐忽略——不是 AI “偷懒”，而是注意力机制的自然衰减。

根因是 Transformer 架构中公认的"Lost in the Middle"现象（Liu et al., 2023）。模型的注意力分布虽然理论上是全局的，但在实践中对上下文开头和结尾的关注度最高，对中间部分显著降低。当一个工程任务需要持续遵守数十条细粒度规则——如 HarmonyOS 三方库迁移工程中的语义规则（本次输入 29 条）+ 编译器限制（11 条）+ 18 条执行纪律——这些规则散落在多个文档中，在长 session 中被反复引用、压缩、重新加载，规则的实际约束力会随时间衰减。不是在纸面上被删除，而是在 AI 的认知分配中被"降权"。

更微妙的是，AI 会形成"模式惯性"——前几个文件通过得顺利，就开始复用同样的行为模式，对后面不同类型的文件不再做区分性处理。这不是规则被忘记了，而是规则和具体场景之间的绑定松了。AI 记住了规则的字面，但忘了在"这个文件"中应该调用"那条规则"。

三、在三方库鸿蒙化迁移工程中的增强：四个维度的系统化增强

以上四个痛点不是独立的，它们在同一工程过程中交织发生——目标漂移让 AI 降低了标准，子 Agent 的中立性丧失让降标后的代码通过了审计，记忆脆断让压缩后的 AI 连降标了都不知道，注意力熵增让剩下的规则也无法被有效执行。

因此我们的解决方案不是四个独立的"补丁"，而是一套贯穿所有 Phase、所有 Session 的统一控制架构。

措施一：用"收敛驱动的嵌套 Loop + 强制检查点"锚定目标

既然目标漂移的根因是没有外部锚点，解法就是将模糊的长期目标分解为有明确收敛条件的短期子目标序列，并在每个节点设置硬检查点。

我们的流程包含 6 个 Phase，Phase 之间设有 CP0-CP5 共 6 个强制检查点。每个 CP 包含自动验证项 + 人工确认项。AI 必须在每个 CP 输出 PASS 后才能进入下一 Phase。CP1 验证 plan 完整性，CP3 验证编译产物，CP5 验证运行时行为——目标在每一个 Phase 边界被重新校准。不存在"不知不觉走偏"——因为每个入口条件都被显式验证。

Phase 内部设计了三个嵌套收敛 Loop：

Loop	粒度	收敛条件	硬上限
Loop 1（逐文件微循环）	单文件	Auditor PASS + Build 0 error → 文件完成	3 轮，未通过转入 Phase 4 审计
Loop 2（审计-修复双层嵌套）	项目级	外循环控制审计轮次（max 5），内循环驱动修复收敛至干净（无新 Critical/High）	外循环 5 轮，内循环收敛驱动
Loop 3（全局测试循环）	entry + 运行时	error/failure 数单调递减 + 全部 PASS	不限（但必须单调递减）

Loop 3 的"不限轮数但必须单调递减"是一个有意设计的数学约束——它确保每次修复都在向前推进。如果错误数持平或上升，系统自动暂停等待人工介入。这从根本上杜绝了"在同一个地方反复修修补补但永远不收敛"的无意义消耗。

措施二：用"角色分离的 Session + 信息隔离"重建审计独立性

既然 Sub-Agent 的中立性被父 Session 的信息场瓦解，解法就不是"给 Auditor 写更严厉的 prompt"，而是将审计者完全移出作者的信息空间——不是换 Agent，是换 Session。

这是整套系统中最核心的架构决策：

Session 1（Phase 1-3）：AI 的角色是代码作者。它加载 01-planner.md（规划文档），目标是把代码写出来并编译通过。Session 1 不加载 08-project-audit.md——审计文档不进入作者的知识范围。
Session 1 在 Phase 3 完成后被强制终止。 这是 runbook 中的硬规则，不是"建议暂停"。AI 输出一段结构化的 Session Bridge 提示词，操作员复制粘贴到全新的 Session 2。
Session 2（Phase 4-6）：AI 的角色是独立审计员。它从未写过任何一行代码。从未见过 01-planner.md。 它不知道"当初为什么这样设计"，因此无法被设计意图说服——只能从代码本身和原库行为出发做对抗性验证。它加载 08-project-audit.md（18 条执行纪律 + 10 个盲区清单 + 两阶段深度审计框架），用 Session 1 从未接触过的审计知识去审 Session 1 的产出。

信息不对称是有意构建的：

	Session 1（作者）	Session 2（审计员）
知道"当初为什么这样设计"（01-planner.md）	✅	❌（仅见磁盘 JSON）
知道"审计时最常漏什么"（08-project-audit.md）	❌	✅
对代码有作者感情（写过这些文件）	✅	❌（从未写过一行）
目标函数	编译通过	找出一切问题
在 Phase 3 后被强制终止	✅（硬规则）	—
加载 03-auditor.md（语法审计）	✅	✅
加载 08-project-audit.md（全局安全/质量审计）	❌	✅

这种不对称模拟了现实工程中施工方和监理方的关系：监理不需要理解施工方的每一个设计意图，他只需要对照图纸和成品逐项检查。如果施工方的意图没有落地为正确的代码，那是施工方的问题。 独立审计的必要性不是"锦上添花"——我们的实际数据显示，同一套代码同一套规则，独立审计比同 Session 审计多发现近一倍的问题，且严重性上了一个量级。

这也在一定程度上回应了 Anthropic 在 “Effective harnesses” 中留下的开放问题：“单个通用编码 agent 足够吗？还是需要专门的测试 agent、QA agent？” 我们的实践给出的回答是：不够。在质量敏感的工程任务中，独立审计角色不是可选项，是架构必需。而且独立性不只靠不同的 prompt 实现——必须靠不同的 Session、不同的信息集、不同的对话履历来实现。

此外，审计层内部我们做了进一步细分——03-auditor.md 审单文件语法合规（代码写对了吗），08-project-audit.md 审跨文件全局安全和完整性（代码做对事了吗）。两者互补但不可替代——语法合规不代表语义正确，语义正确不代表没有遗漏功能。这种分层也对应了 AuditBench 的发现——审计有效性依赖于审计者与被审计对象之间的信息不对称。同层审计比跨层审计更容易被自我合理化。

措施三：用"Gatekeeper + 嵌入式状态快照"对抗记忆脆断

记忆脆断的本质是项目状态存在于易失性介质（上下文窗口）中。常规思路是持久化到文件，但文件需要主动读写，而压缩是异步突发事件——无法预知它什么时候发生。

我们的方案：让状态快照成为对话流的天然组成部分，不需要额外维护。

G1 文件门控的输出格式被精确设计为自带完整状态信息：

╔══════════════════════════════════════════════════════════╗
║  ⛔  G1 文件门控 — 硬停止                                 ║
║                                                          ║
║  ✅ [文件名] DONE — 等待 Next | {X}/{Y} | 连续1轮通过: {streak}/5 | Token: {used}K/{budget}K
╚══════════════════════════════════════════════════════════╝

这一行包含了恢复所需的全部变量：当前文件、进度、质量趋势、Token 消耗。它在每个文件完成时自动输出，因此天然冗余——压缩丢了一两个 G1 行，前一个依然可以定位。

当压缩发生后，恢复流程被设计为三层递进：

第 1 层（尝试自动恢复）——AI 扫描对话摘要中的 G1/CP 行定位断点
第 2 层（人工一句话触发——标准路径）——操作员识别到压缩，发送固定指令，AI 被强制加载协议原文并执行恢复
第 3 层（人工直接定位——最终兜底）——操作员告知断点，AI 从指定位置继续

三层设计的原因是：把恢复的主动权交给操作员，但提供操作员执行恢复所需的最小工具。

这与社区中"PreCompact hook → 外部文件 → SessionStart 重新注入"的方案不同。我们的方案不依赖尚未稳定的 hook API，不增加外部依赖，适用于任何 Claude Code 环境。

措施四："模式驱动的动态干预"对抗注意力熵增——人工在关键节点监控并干预

注意力熵增的本质是 AI 对规则的遵守程度随时间衰减。常规思路是"把规则写得更显眼"——更短的文档、更突出的格式、更频繁的重复。但这些是被动手段，边际效益递减。

我们的方案是：不依赖 AI 记住规则，而是让系统检测规则的违反模式并主动干预。

G2 模式检测在 Loop 1 中持续监控 5 种异常信号：

触发	检测模式	干预逻辑
T1	同一违规 ID 在 ≥2 个连续文件中出现	将违规对应的规则补丁直接注入 Executor prompt——从根本上改变 AI 后续输出的分布
T2	单文件 ≥2 轮才通过（挣扎后 PASS）	不暂停但记录——作为系统性的弱信号在 CP2 批量回顾，防止累积成系统性问题
T3	streak ≥5（连续 5 文件 1 轮通过）	反向干预——AI 可能已进入"舒适区"，提议批量生成但必须人工决策
T4	Build 错误指向同一依赖文件	暂停当前文件，优先修复依赖——拓扑敏感的调度，防止依赖 bug 扩散
T5	连续 3 文件各耗尽 3 轮	紧急熔断——这不是"再努力一下能过"，而是系统性失败，必须人工诊断 prompt/策略

这套机制的巧妙之处在于它不需要 Claude 的元认知参与。T1 的检测是纯模式匹配（同一违规 ID 出现在不同文件的 Audit 结果中），触发后立即执行干预（规则补丁注入 Executor prompt）。AI 不需要"意识到自己又犯了同样的错"——系统替它做了这个判断。

G1 streak 计数器给每个文件的审计难度提供了量化指标，让操作员在不逐文件翻阅审计报告的情况下感知全局质量趋势。08-project-audit.md 中的 10 个盲区（B1-B10）——“只审成功路径漏掉 catch”“注释说’已处理’就不再验证”“纯计算函数被标记为低风险而跳过”——则是用人类从多次迁移中归纳出的经验模式，补偿 AI 的注意力衰减。

四、这些设计背后的统一原理

以上四个措施不是孤立的。它们共享几个深层原则：

1. 不信任原则。 整套系统建立在一个前提下：AI 的输出需要被系统性地不信任——不是恶意的，而是工程上的"验证驱动"。代码需要通过 Auditor，Auditor 需要通过 Session 2 的独立审计，所有产出需要通过 CP 检查点。这条不信任链从架构顶层贯穿到底层。这与 Petri 的发现一致——审计不能寄望于被审计者的自觉，必须外化为独立的、对抗性的验证。

2. 不对称性原则。 验证的成本应该远低于生成的成本，验证者的信息集应该不同于生成者的信息集。G1 行一行包含全部状态，03 审单文件不需要知道全局设计，08 审全局不需要知道 Phase 1 的决策意图——每一层都在用更少的信息做独立的验证。

3. 人在回路中的结构位置。 "人机协作"的关键是人在哪里以什么方式参与。在我们的系统中，人的参与被精确放置在三个架构节点上：G1 每个文件后的 pacing 决策、G2 触发后的干预决策、CP 检查点的人工确认。三个节点的共同特征是——它们都是 AI 无法自我执行的 meta-verification（验证的验证）。要始终保持清醒，人不可以忽略关键节点的审视，在长文本和压缩状态下，AI 的欺诈性会被无限放大。

4. 状态分布式原则。 项目状态不放在一个地方，要多层备份冗余，并互相印证。G1 行（对话流中的文件级快照）、CP 行（对话流中的 Phase 级锚点）、06-metrics.md（磁盘上的持久化记录）、git tag（独立于 AI 对话的版本标记）——四者互为冗余。

五、增强"Dynamic Workflow + 收敛 Loops + 角色分离 Session + Gatekeeper"的工程价值

Anthropic 的创始人之一、Claude Code 的实际构建者 Boris Cherny 在 2026 年的一次采访中公开表示：“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”（我不再向 Claude 写提示词了。我写循环，让循环去提示 Claude、决定该做什么。我的工作变成了设计循环。）

Google 的 Addy Osmani 随后为这个范式正式命名为 Loop Engineering，将其定义为 AI 编程的第四次范式跃迁——从 Prompt Engineering（写好单次提示词）→ Context Engineering（动态组装上下文）→ Harness Engineering（为 Agent 构建运行环境）→ Loop Engineering（设计自治系统，人站在循环外定义规则和收敛条件）。

但我们认为，提示词的重要性在一定程度上降低了，可靠的提示词和 md 文档仍然是启动的钥匙。Loop Engineering 的核心不是"消灭提示词"，而是将提示词从"一次性消费品"变为"可复用的工程资产"——我们这套系统中的 01-planner、02-executor、03-auditor、08-project-audit 等 Prompt 文档，本质上就是固化下来的工程方法论。它们不是每次迁移重新写的，而是一次打磨、反复验证、持续迭代的"代理规则代码"。Loop 是骨架，门控是神经，而精心设计的 Prompt 仍然是血与肉。提示词和 loops 之间不是替代关系，是共生关系。

我们将这套方法和实践开源，不是为了提供一个"一键迁移工具"——我们提供的是一个可复制的工程流程架构来作为参考。同样的设计模式——收敛 Loop + 角色分离 Session + Gatekeeper + 嵌入式状态快照——可以应用于任何需要 AI 在长周期内保持可靠性的工程任务。HarmonyOS 三方库迁移是工程的实践，但方法论本身是通用的。

如果你也在面对"让 AI 独自跑完一个长工程"的挑战——无论是代码迁移、自动化测试、文档生成还是持续重构——我们希望这套系统能给你一个可参考的起点。不是"照搬我们的 Prompt"，而是理解我们为什么这样设计架构，然后在你自己的领域里，构建你自己的 Loop 和 Gate。

相关开源项目：

相关阅读：