GUI-HARVEST：通过证据驱动的运行时框架演化实现自我改进的 GUI 智能体 GUI-HARVEST: Self-Improving GUI Agents through Evidence-Driven Harness Evolution
冻结模型权重，用重复执行的多模态证据自动改写 GUI 智能体运行时代码实现自我提升
前置知识
Agent Harness（运行时框架）
包裹 GUI 模型的可执行程序，负责把屏幕截图组装成观察与上下文、把模型输出编译成真实键鼠动作，并控制验证、恢复与终止逻辑（如何时宣告任务完成、失败后如何重试、是否用代码执行替代点击）。模型权重冻结时，harness 的实现质量直接决定同一模型在 OSWorld 上的分数：Agent S3、CoAct-1、VLAA-GUI、OS-Symphony 等框架都属于这一层的设计空间。
本文优化的对象就是 harness 而非模型权重，理解这一分层是读懂全文的前提。
OSWorld-Verified
真实 Ubuntu 桌面环境的可执行 benchmark：每个任务给定初始 VM 快照、自然语言指令和程序化评估器，动作空间是真实键鼠操作。Verified 版本修复了原版的任务缺陷，常见配置是排除 8 个 Google Drive 任务后剩 361 个任务，覆盖 OS、办公、日常、专业、多应用五个领域，指标为原始评估器得分的任务平均。
它是本文的主实验场，任务切分（80 搜索/80 验证/201 封存测试）与所有主结果数字都基于它。
执行变异性与任务翻转率
GUI 执行不具备字节级可复现性：时钟、托盘状态、通知、网页动态内容、渲染时序都会进入观察流，而每张新截图又决定下一步动作，微小早期差异会累积成完全不同的任务结局。翻转率（flip rate）指同一任务在 K 次重复执行中同时出现 0 分与正分的比例，本文实测六个骨干为 11.8%–20.4%（Qwen3-VL-32B 最高 20.4%）。
这是论文把「重复执行」当作联合证据单元、默认 $K=3$ 次重复的直接实证动机。
封存测试集与防泄漏协议
优化开始前把任务按域分层随机切成三份：搜索集（供优化器诊断用的完整轨迹）、验证集（只向优化器暴露聚合分数）和封存测试集（优化期间完全不可访问，优化停止后才评测）。该协议保证报告的增益是对未见任务的泛化，而非对参与优化任务的过拟合。
论文的核心主张是 held-out 增益，理解该协议才能正确解读 Test 与 Full 的提升数字。
双重验证门（效用硬门 + 行为软门）
候选补丁的晋升条件：先通过 L0/L1 静态代码检查，再在全部搜索+验证任务上各跑 $K$ 次重复执行；效用硬门要求 $\mathrm{HardGate}_{S,V} = (\Delta_S \geq 0) \wedge (\Delta_V \geq 0) \wedge \max(\Delta_S, \Delta_V) > 0$，即两个划分都不退步且至少一个严格提升；行为软门再核查工程师在编辑前冻结的行为预测是否被后编辑轨迹支持（裁决为 supported/contradicted/inconclusive）。
这是方法防止「碰巧提分」和过拟合的关键机制，也是与通用 harness 优化器的主要差异点。
研究动机
GUI 智能体的成败不只取决于底层视觉-语言模型，还取决于包裹在模型外围的可执行运行时框架（harness）：它决定观察如何组装、动作如何执行、验证/恢复/终止如何控制。已有的自动 harness 优化器（Self-Harness、Meta-Harness）在数学推理、Terminal-Bench、SWE-bench 等非 GUI 领域依赖文本轨迹和分数反馈，直接搬到 GUI 上会撞上三个耦合难题。其一，模型意图与观察到的视觉效果脱节：文本轨迹可能声称「已保存」，但截图显示对话框仍然开着，点击 Save 并未真正完成任务，仅凭序列化文本无法判断动作究竟改变了什么。其二，失败诊断必须面对执行变异性：即使在确定性解码下，同一任务重复执行也会时好时坏，论文实测在 OSWorld-Verified 全量 361 任务上、3 次重复执行中，六个骨干有 11.8%–20.4% 的任务同时出现 0 分和正分（Qwen3-VL-32B 高达 20.4%），单条失败轨迹是对智能体行为的严重不完整刻画。其三，单任务发现未必可复用：为一个任务打的补丁换个任务可能无效甚至有害，相似失败必须归因到共享的运行时机制并验证其行为效果——仅看聚合分数上升，无法证明复发性的失败模式真的被修复了。
本文的目标是本文要构建一个自动 harness 优化器 GUI-HARVEST，在完全冻结骨干模型权重的前提下，让 GUI 智能体从自身执行经验中持续改进：把重复执行产生的多模态证据转化为可复用的源代码修改，且每笔修改都要同时通过任务分数检查和行为预测检查。目标可量化为：(1) 在 OSWorld-Verified 361 任务（域分层切分为 80 搜索/80 验证/201 封存测试）上，六个骨干（Qwen3-VL-8B/32B-Instruct、OpenCUA-32B/72B、Gemini 3.1 Pro、GPT-5）都要在从未参与优化的封存测试集上取得一致增益；(2) 仅用 15 步预算优化出的 harness，在 50 步和 100 步预算下评测依然领先；(3) 冻结的 harness 不做任何 WAA 优化即可迁移到 WindowsAgentArena 并保持增益；(4) 在同骨干、同初始 harness、同优化器模型的条件下，超过通用优化器 Self-Harness 与 Meta-Harness，证明 GUI 特化的诊断与验证能产出更可泛化的修改。
与已有工作不同的是，本文的独特切入角度有三点。第一，把「同一任务的重复执行」当作联合证据单元：已有 GUI 失败驱动方法（如 LFF）主要分析单条失败轨迹，而本文利用同任务多次执行中成功与失败路径的分叉点，定位与结果相关的行为差异——翻转率数据说明单轨迹诊断天然不完备。第二，诊断扎根于视觉状态转移而非文本轨迹：GAFT 工具把每步的模型输出、计划/实际执行的动作与前后截图机械对齐，计算全屏像素变化 $\Delta_{screen}$ 和点击落点局部变化 $\Delta_{local}$ 等可复现事实，让「点击没生效」「编辑未提交」这类判断有截图和像素级证据支撑，并有确定性校验器核查引用。第三，要求编辑在评估前冻结可观察的行为预测，晋升时除效用硬门外还要通过行为软门：不仅验证「分数涨了」，还要验证「预测的行为改变真的发生了」，直接防止补丁只是碰巧提分而未修复目标失败模式。将视觉证据、重复执行联合诊断与行为级验证闭环起来用于 GUI harness 优化，是本文首次做到的。
核心方法
先给直觉：这就像给一位能力固定（模型权重冻结）的员工不断修订他的工作手册与工具链——不改大脑，只改流程：观察怎么组织、动作怎么执行、何时宣告完成、失败后怎么恢复。GUI 任务的麻烦在于流程缺陷往往只有看了屏幕才知道，就像日志写着「已保存」但对话框还开着。技术路线是一个自改进闭环：GUI-HARVEST 由四个 LLM 角色加确定性程序组成。每轮从当前 harness $H_t$ 出发，在搜索集每个任务上从干净 VM 快照执行 $K=3$ 次，得到任务-轮次捆绑包（多模态轨迹+分数+运行时元数据）。Evidence Analyst 对得 0 分的运行做诊断，产出带运行/步引用的「发现」；Cross-task Clusterer 把跨任务发现归纳为至少两个独立任务支持的「行为模式」；Harness Engineer 在能力清单允许的范围内把模式映射为有界源代码补丁，并在评估前记录可观察的行为预测；Validator 在全部搜索+验证任务上各跑 $K$ 次 rollout，先查效用硬门 $\Delta_S \geq 0 \wedge \Delta_V \geq 0 \wedge \max(\Delta_S,\Delta_V) > 0$，再查行为软门。四关全过才晋升为 $H_{t+1}$，否则回滚并把补丁、预测、分数与裁决写入更新账本供后续参考。全程最多 $B=10$ 轮、每轮 $P=5$ 个候选评估，连续 5 次被拒即停止；测试集始终封存，优化结束才打开。
核心创新是与 GUI 特性深度绑定的三个设计，这是它和通用优化器的本质区别。第一，证据的视觉扎根：发现（finding）必须引用决定性步骤的前后截图和 GAFT 计算的机械事实（像素变化比例），确定性校验器会核查 harness 版本、引用的运行/步号、引文局部性等——这与通用优化器把轨迹序列化成纯文本截然不同，因为 GUI 中「意图≠效果」（声称保存了但屏幕未变）只有对齐视觉证据才能发现。第二，重复执行作为联合证据单元：诊断对象不是单条轨迹而是任务捆绑包，成功运行充当参照路径，分析师在分叉步定位与结果相关的行为差异；这直接回应了 11.8%–20.4% 的任务翻转率——单次失败可能只是噪声分支，而成功-失败对比能暴露真正的机制。第三，预测先行的行为验证：Harness Engineer 必须在评估前写下补丁的可观察行为预测（例如「过早的 done() 应被拦截，随后先提交编辑再完成」），验证器用冻结的预测对比后编辑轨迹给出 supported/contradicted/inconclusive 裁决，且要求每个预测至少一个确定裁决、支持多于反驳。消融证明这不是摆设：去掉视觉证据 Test 从 53.18 掉到 44.54，去掉行为门只留硬门掉到 49.36——两个组件都贡献了真实的泛化增益，而不只是防过拟合的保险。
方法步骤详情
完整流程分七步。(1) 准备：361 个 OSWorld-Verified 任务按域分层随机切为 80 搜索/80 验证/201 封存测试（固定公开种子、跨骨干复用）；能力清单声明可编辑的 harness 文件范围；冻结骨干确定——Qwen3-VL 与专有模型从 Agent S3（配 UI-TARS-1.5-7B grounding、关闭 best-of-N）起步，OpenCUA 用其官方坐标动作运行时；四个优化角色统一使用 Claude Sonnet 5。(2) 证据采集：搜索与验证任务各执行 $K=3$ 次，每次从干净快照启动；GAFT 把每步的模型文本、计划/执行动作、工具输出与前后截图按步对齐，计算机械事实（全屏像素变化 $\Delta_{screen}$、指向动作落点局部变化 $\Delta_{local}$），打包为含 Task Card 与 Harness Card 的捆绑包。(3) 诊断：捆绑包中至少一个有效运行得 0 分时触发分析；Evidence Analyst 比较终止状态与任务目标、定位运行分叉步、核对「意图-执行-屏幕」是否一致，产出形如 $f=(r, t^\star, \sigma, m, \bar{a}, E)$ 的发现（失败运行、决定性步、动作-结果签名、可观察机制、反事实替代、证据链），再经确定性校验器核查后保留。(4) 归纳：Cross-task Clusterer 先按确定性结果类别分组，再在类内归纳开放词表的行为模式 $c=(g, d_c, \phi_c, b_c, \mathcal{F}_c)$，要求至少两个独立任务的发现支持。(5) 编辑：Harness Engineer 在受限源码会话中选择一小组兼容模式、定位相关代码、施加有界补丁，并在 GUI 评估前先写更新计划 $u=(c, E, a, \delta, \mathcal{P}, A, q)$：源码面、编辑内容、可观察预测 $\mathcal{P}$、用于核查的目标任务 $A$、必须保持的不变量 $q$。(6) 验证：L0（编辑权限/差异限制/语法/静态规则）与 L1（导入/接口兼容/单元测试/冒烟）通过后，候选在全部搜索+验证任务上各跑 $K$ 次；效用硬门与行为软门依次检查，行为验证要求每个预测至少一个确定裁决且支持多于反驳；全过则晋升并开启新一轮，否则回滚恢复 $H_t$；账本记录全部决策。(7) 停止与评测：最多 10 轮、每轮 5 个候选，5 连拒即停；停止后冻结 $H^\ast$，才打开封存测试集，并在 15/50/100 步预算及 WindowsAgentArena 上评测。
技术新颖性
与已有工作的具体区别：(1) 相对 Self-Harness/Meta-Harness 等通用 harness 优化器——它们面向分类、数学推理和终端编码，优化器可见的证据是序列化源码、文本/工具轨迹和分数；GUI-HARVEST 把前后截图、动作-屏幕对齐和像素级机械事实纳入优化器证据，并加入行为预测验证，同条件下 Test 增益 10.16 对 Meta-Harness 的 4.38、Self-Harness 的 2.00。(2) 相对 LFF——LFF 也把 GUI 失败转成运行时代码修改，但基于单条轨迹的文本历史、四类预设干预族，缺少跨任务模式归纳与后编辑行为验证；GUI-HARVEST 是开放词表模式归纳+预测驱动验证的闭环。(3) 相对 CUADebug、AdaMAST、RoTS 等 GUI 轨迹诊断工作——它们止步于定位根因、归纳错误分类或合成恢复轨迹，不修改运行时本体。(4) 相对 TextGrad/GEPA 等 prompt 优化方法——本文编辑的是可执行源码（控制流、验证、恢复、终止逻辑），表达力和可验证性更强，如实现 done() 保存门、拖拽时长归一化这类无法用 prompt 表达的机制。(5) 基础设施贡献：GAFT 与任务-轮次捆绑包把「重复执行的 GUI 证据」变成可检索、可校验的结构化数据，配合能力清单、账本与封存协议，构成一套可复用的自改进 agent 工程范式。
实验结果
逐一分析关键实验。(1) 跨骨干 held-out 增益（Table 1）：15 步、$K=3$ 协议下六个骨干的封存测试集全部提升——Qwen3-VL-8B 28.79→34.84（+6.05），Qwen3-VL-32B 43.02→53.18（+10.16），OpenCUA-32B 32.82→34.31（+1.49），OpenCUA-72B 41.25→44.18（+2.93），Gemini 3.1 Pro 66.42→72.63（+6.20），GPT-5 56.35→61.86（+5.51）；全量 361 任务上 Qwen3-VL-32B 达 50.94%（+12.33）。(2) 大步预算（Figure 1）：只用 15 步优化再冻结，Gemini 3.1 Pro 在 100 步达 79.14%、50 步 78.03%；Qwen3-VL-32B 50 步 51.52%、100 步 51.79%；与已发表系统同模型同预算对比全部领先，如 15 步对 CoAct-1/GPT-5 领先 22.61 分（62.42 对 39.81）、对 VLAA-GUI/Gemini 3.1 Pro 领先 21.68 分（73.37 对 51.69）。(3) 优化器对比（Table 2）：同初始 harness、同 Claude Sonnet 5 优化器、同 10 轮上限，GUI-HARVEST +10.16 vs Meta-Harness +4.38 vs Self-Harness +2.00；对 OpenCUA 骨干也超过 LFF 的发布补丁（OpenCUA-72B Test 44.18 对 41.29）。(4) 跨平台迁移（Table 11）：OSWorld 优化的 harness 冻结后直接评 WAA 50 步，GPT-5 50.88→64.75（+13.87），Qwen3-VL-32B 38.21→44.68（+6.47）。(5) 消融（Table 3）：去视觉证据 44.54（-8.64）、去跨任务聚类 45.66（-7.52）、单次执行证据 $K=1$ 为 47.44（-5.74）、仅硬门 49.36（-3.82），全方法 53.18；仅硬门变体跑了 9 轮反而选出更低分 harness，说明行为门改善了选择质量。$K$ 扫描显示 $K=3$ 最优（50.9%），$K=5$ 反而略降（49.7%）且成本 5 倍。(6) 成本（Figure 4/9）：GPT-5 15 步 62.4%/$72 ≈ Agent S3 100 步 62.6%/$260（成本省约 72%）；Gemini 3.1 Pro 100 步 79.1%/$125 优于 Claude Sonnet 4.5 的 58.1%/$316；Qwen3-VL-32B 50.9%/$34 是低成本档位。(7) 优化努力（Figure 3/8）：Qwen3-VL-32B 8 轮 25 次尝试晋升 7 个补丁，OpenCUA-32B 仅 3 轮 14 次尝试晋升 2 个——OpenCUA 因坐标动作协议被后训练固化、对新增控制机制适应性低，增益也最小。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| OSWorld-Verified 封存测试集（15 步） | 平均原始评估器得分 | Qwen3-VL-32B：53.18% | 同骨干初始 harness（Agent S3）：43.02% | +10.16 个百分点 |
| OSWorld-Verified 全量 361 任务（15 步） | Full 平均分 | Qwen3-VL-32B：50.94% | 初始 harness：38.61% | +12.33 个百分点 |
| Harness 优化器横向对比（Qwen3-VL-32B，Test） | Test 得分（相对初始 harness 提升） | GUI-HARVEST：53.18%（+10.16） | Meta-Harness 47.40%（+4.38）；Self-Harness 45.02%（+2.00） | 比最强基线 Meta-Harness 高 5.78 分 |
| OSWorld-Verified（Gemini 3.1 Pro，100 步） | 平均分 | 79.14% | 初始 harness 66.42%；同期最佳公开系统 OpenAPA/Gemini 3.1 Pro 78.34% | 对初始 harness +12.72 分，居同期对比首位 |
| WindowsAgentArena 零优化迁移（50 步，GPT-5） | WAA 平均分 | 64.75% | Agent S3 初始 harness：50.88% | +13.87 个百分点 |
| WindowsAgentArena 零优化迁移（50 步，Qwen3-VL-32B） | WAA 平均分 | 44.68% | Agent S3：38.21% | +6.47 个百分点 |
| 组件消融（Qwen3-VL-32B，Test） | Test 得分 | 完整方法 53.18% | 去视觉证据 44.54%；去跨任务聚类 45.66%；K=1 证据 47.44%；仅硬门 49.36% | 完整方法比最强消融变体高 3.82 分 |
| 推理成本效率（OSWorld 全量，GPT-5） | 准确率 / 全套 API 成本 | 62.4% / $72（15 步冻结 harness） | Agent S3/GPT-5：62.6% / $260（100 步） | 准确率相当，成本降低约 72% |
局限与改进
作者承认的局限：(1) 残余失败越来越难从截图和执行日志检测——动作执行成功但指向错误对象、错误路由或评估器相关状态时，运行时缺乏局部信号来触发恢复或引导纠正，harness 层面进一步修正的空间变小（Table 9 残余瓶颈列）；(2) 有效干预是骨干特异的，相似症状没有万能补丁，如「不可行误判」在六个骨干上分别用了预算裁定、约束探测、文本接地重映射等不同机制（Table 10）；(3) OpenCUA 增益最小（Test +1.49/+2.93），因其动作协议在后训练中固化；(4) Qwen 模型增加步预算收益有限（15→100 步 Full 仅 +2.54/+0.85，对比 Gemini/GPT-5 的 +5.77/+6.00），存在长程执行瓶颈。我的补充观察：(1) 优化成本未披露——每个候选要在 160 个搜索+验证任务上各跑 3 次 15 步 rollout，Qwen3-VL-32B 全程 25 次候选评估，总 rollout 量上万次，且优化器本身是 Claude Sonnet 5，这笔开销在成本对比图（Figure 4）中被明确排除；(2) 搜索/验证集各仅 80 任务，稀有失败模式可能采样不足，模式要求至少 2 个独立任务支持也会遗漏单任务问题；(3) 诊断只对出现 0 分的捆绑包触发，部分得分或「成功但低效」的运行不会被分析；(4) 行为软门依赖 LLM 裁决，虽有严格引用规则仍存在误判空间；(5) WAA 迁移仍需手工平台适配器（观察/动作/日志接口映射），「零优化迁移」并非完全自动。
独立分析的弱点
独立分析的弱点及改进方向：(1) 只诊断 0 分运行——部分得分（如 0.5 分）和「成功但绕远路」的运行不进入诊断，浪费了提升效率的机会；改进：对低于阈值或显著劣于同捆绑包最佳运行的案例也生成发现，把目标从「修复失败」扩展为「优化轨迹质量与成本」。(2) 验证成本结构僵化——每次候选评估都要在全部 160 个任务上跑 $K=3$；若目标模式只涉及少数任务域，可先用目标任务子集预筛，仅在接近晋升门槛时做全量验证，可把优化 API 开销降低一个量级。(3) 模式归纳依赖「同一机制跨任务复现」——现实中很多失败是任务特定的，80 任务搜索集难以让它们形成模式；改进：允许工程师生成合成变体任务来检验单任务发现的可泛化性，或引入跨运行的任务簇检索。(4) 效用硬门 $\Delta_S \geq 0 \wedge \Delta_V \geq 0$ 过于保守——论文自己观察到后期候选会在任务间「trade gains」，某些补丁可能提升整体但轻微损害个别域而被一票否决；改进：改为带域级下限约束的加权效用，或允许显式记录权衡后由账本辅助决策。(5) 视觉证据局限于像素级事实——GAFT 只计算像素变化，「指向了错误对象」这类语义错误无法机械化检测，而这正是残余瓶颈；改进：接入 accessibility tree、UI 层级或应用级状态 API，提供语义状态证据。(6) 优化器角色全部使用 Claude Sonnet 5——结论可能隐含对优化器模型能力的依赖；改进：消融优化器模型规模并披露优化成本，给出「最小可用优化器」规格。
未来方向
作者指出的方向：(1) 残余的「成功执行但目标错误」失败需要超越截图与日志的新信号源，如语义状态验证、应用内省；(2) 干预的骨干特异性提示可以学习「骨干画像→干预策略」的元知识，让新模型的适配更快冷启动；(3) 在更多环境与平台上验证迁移。基于成果可延伸的：(1) 把 harness 演化与轻量权重更新（如 grounding 模型微调）结合，攻克 harness-only 修不了的目标错误失败；(2) 把任务-轮次捆绑包与翻转率分析变成 GUI agent 评测的标配——任何论文都应报告重复执行分布而非单次分数；(3) 自动学习平台适配器（Linux→Windows→移动端），实现真正零手工的跨平台迁移；(4) 把「预测先行验证」推广为 agent 自我修改系统的通用实践——任何自改代码的 agent 都应先注册可观察预测再评估；(5) 在线部署场景下的持续 harness 自演化，用用户真实任务流替代静态搜索集，并配套安全性约束与回滚机制；(6) 将行为模式库作为可复用资产在不同 harness 之间移植。
复现评估
代码已开源：https://github.com/GaryYang12345/GUI-HARVEST。整体可复现性较好但成本不低。有利因素：(1) OSWorld-Verified 公开，任务切分用固定公开种子的域分层随机划分并跨骨干复用，防泄漏协议描述完整；(2) 初始 harness 全部公开（Agent S3、OpenCUA 官方运行时）；(3) 附录给出四个角色的 prompt 模板（附录 J）、记录 schema（附录 H）、算法伪代码（Algorithm 1）和一个端到端实例（Figure 11），透明度高；(4) 六个骨干中四个是开源权重（Qwen3-VL-8B/32B、OpenCUA-32B/72B），可不依赖闭源 API 复现主要结论。成本因素：(1) 优化阶段每个候选在 160 任务 × $K=3$ rollout，Qwen3-VL-32B 全程 25 次候选评估，估计上万次 15 步 GUI rollout，涉及 VM 快照重置与专有 API 调用（目标模型 + Claude Sonnet 5 优化器）；仅推理端全套评测成本已达 Qwen $34、GPT-5 $72、Gemini $125，优化成本未披露但显然数倍于此；(2) LFF 对比只能用其发布补丁，因其优化器未开源，这类复现会打折扣。总体评估：有 GPU 服务器、数百美元 API 预算和 OSWorld Docker 环境的小团队可以在开源自骨干上复现核心流程并做单骨干验证；完整复现六骨干+消融矩阵则接近大厂配置。难度评级：中等偏高。
论文图表
三组实拍证据：(a) 相隔一分钟的两次干净重置，初始帧已不同（启动器顺序变化）；(b) 执行过程中任务无关事件混入观察流（浏览器更新对话框、权限提示、备份提醒）；(c) 两次运行前四步完全一致、第五步分叉，最终分别得 0.0 和 1.0 的相反分数。
执行变异性是「把重复执行当联合证据单元」这一核心设计的实证动机，也解释了为什么单条失败轨迹不足以诊断。
同一初始 harness（Qwen3-VL-32B/Agent S3）、同一优化器模型（Claude Sonnet 5）与轮数上限下的对比：GUI-HARVEST Test 53.18（+10.16）vs Meta-Harness 47.40（+4.38）vs Self-Harness 45.02（+2.00）；下方还列出与 LFF 发布补丁在 OpenCUA 骨干上的最终 harness 对比（如 OpenCUA-72B 44.18/42.33 vs 41.29/39.50）。
直接证明 GUI 特化的诊断与验证（而非更多算力）是增益来源，是与最相关竞品的关键对照。
按运行时后果归组的跨骨干模式表：六类模式（低效执行策略、冗余动作循环、过早完成、不可行误判、工具-应用状态不匹配、动作接口不匹配），每类列出受影响骨干、共享干预原则与模型特异实现——如同是「不可行误判」，通用模型用预算/能力检查，OpenCUA 用文本接地的终止重映射。
说明「相似症状≠相同药方」：跨任务模式必须映射到各骨干可用的运行时接口，这是 Harness Engineer 设计的依据。