LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering —— 精读

论文链接：https://arxiv.org/abs/2608.28281

代码仓库：https://github.com/AMAP-ML/LoopArena

发表时间：2026 年 8 月 28 日（arXiv:2608.28281v1）

机构：阿里 DreamX Team（第一单位）、北京邮电大学、UNSW Sydney、Data61 CSIRO——典型企业+高校合作，一作 Yi Wang 来自 DreamX 团队

领域标签：cs.AI，编码智能体评测 / LLM Agent 基准

一、论文背景

1.1 Loop Engineering：从手写提示词到设计循环

与编码智能体协作的方式正在经历一次范式转变。早期用法是开发者逐轮检查结果、手写下一个提示词；而 Loop Engineering（循环工程）的实践者不再逐条写提示，而是设计一个循环来监控进度、分配工作、运行检查，并决定智能体下一步做什么。论文引用了 Addy Osmani 的博客与 The New Stack 对 Claude Code 创始人的报道——后者宣称自己已经抛弃了逐条提示的写法，现在只写循环。

用一个类比来理解：写提示词像给新员工口述每一个操作步骤，而 Loop Engineering 像给一位主管岗位写职责说明书——你规定目标和验收标准，让主管自己管理节奏。这条路线兴起的技术背景是编码智能体本身已经足够强（能完成单段任务），瓶颈转移到谁来管理多轮、多小时的全过程。

1.2 为什么端到端评测无法回答这个问题

现有编码基准（SWE-bench 系列、Multi-SWE-bench 等）的评测对象是完整的编码智能体系统：跑一遍端到端流程，用可执行测试给最终仓库状态打分。但一次长时程运行的成败，可能来自两个完全不同的来源：

• 循环的引导质量：是否在错误的进度记录上继续推进、是否跳过了必要的验证、是否在预算烧完前及时止损；
• 编码智能体的执行能力：即使指令正确，智能体也可能写错代码。

端到端得分把两者混在一起，无法区分。而即便换上更强的编码智能体，循环本身仍然可能信任过时的进度笔记、把预算花错方向、或在任务还不安全可提交时就叫停。这正是 Loop Engineering 实践中反复出现的痛点——循环质量不可见。

1.3 已有评测的缺口

论文梳理了三类相邻评测均未覆盖这一对象：长时程/迭代基准仍然给整个智能体系统打分；过程导向基准评估轨迹内的单步动作质量（如仓库探索能力）；近期开始出现的循环系统基准（如 LoopsBench）比较的是不同模型与循环实现的组合配置。没有任何现有基准把『指挥循环的那个模型』单独拿出来评测。LoopArena 就是为填补这个缺口而生：它要回答的问题是——一个模型作为运行时控制者到底有多强？

二、论文定位和关联工作

2.1 三条相关研究谱系

谱系一：编码智能体基准。SWE-bench 及其变体评测最终仓库状态；SlopCodeBench（SCBench）与 BeyondSWE 把工作负载扩展到特性实现与长时程迭代任务；关于数据泄漏与任务设计的研究则磨砺了基准构建标准。这些基准的被评测对象始终是完整编码系统。LoopArena 的关键区别：把编码 Worker 与执行环境全部冻结，只比较指挥 Worker 的那个模型。SCBench 与 BeyondSWE 同时也是 LoopArena 的任务来源基准。

谱系二：Harness 与 Loop Engineering。Harness 决定模型周围的工具、上下文策略与控制逻辑。Harness-Bench 与 LoopsBench 比较完整的模型—harness 组合配置；Natural-Language Agent Harnesses 让运行级策略可用文本编辑；Meta-Harness 与 HarnessX 从执行轨迹中修订 harness 代码；LongHorizon-Harness 用 manager–executor–auditor 循环外化任务状态管理；ManagerWorker 研究一个模型指挥另一个模型的配对。LoopArena 把这种分离直接变成被评测对象——固定 Worker 与控制接口，比较 Controller 模型。

谱系三：过程与反馈评估。交互式基准（τ-bench、WebArena 等）测量多轮工具使用；过程监督工作给轨迹中的单步打分；批评与自我修正方法用反馈支持再尝试。LoopArena 的差异在于评测一个模型对另一个编码智能体的反复指令序列，并把单个控制决策与其执行下的下游效果连接起来。

谱系四：高效基准评估。ConvCodeWorld 与基准压缩方法用排序相关性（Kendall τ 或 Spearman ρ）检验低成本评估能否恢复全基准排序。LoopArena 把同样的验证原则应用到配对的任务切片与全任务执行上——这正是 Type II 设计的方法论来源。

2.2 定位总结

LoopArena 在这个研究脉络中的定位是：第一次让 Loop Engineering 中的运行时循环控制能力本身成为可测量、可比较、可低成本诊断的对象。

三、问题定义

3.1 从具体场景到抽象问题

具体场景：一个开发者在长时程编码任务中用循环管理编码智能体，需要在每轮交接时判断——继续推进？先验证？还是停止？他想知道哪个模型最适合当这个主管。

深层结构相似性在于：这本质上是一个基于不完全观察的序贯控制问题。Controller 看不到仓库本身，只看到结构化的进度报告（Evidence Packet），却要决定被控智能体的下一步与整个运行的中止时机。这与经典控制论中『控制器基于系统状态反馈发出控制信号』的结构同构。

3.2 形式化定义

对可执行任务 i 的第 k 个控制周期：harness 将 Reporter 报告与被引用的 Worker 轮次打包为 Evidence Packet x_{i,k}，Controller 模型 π 结合其对话历史 h_{i,k}（含更早的 Packet 与 Contract）输出 Loop Contract：

c_{i,k} = π(x_{i,k}, h_{i,k})

约束条件：Controller 无编码工具、无法直接访问工作区，只能通过发送给 Worker 的指令影响任务；合同要么给 Worker 一个有界下一段任务，要么结束运行。

给定：固定的 Worker、工具、任务环境、执行预算、评估器与控制接口；求：使 Strict Success Rate（通过评估器且遵守协议的运行比例）最大化的控制策略；约束：预算与协议边界。

3.3 抽象的精妙之处

这个定义把『编排能力』从『编码能力』中干净剥离——所有与执行相关的变量都被冻结，成败唯一取决于决策序列的质量。同时 Evidence Packet 是结构化只读摘要而非原始对话，使得评测不依赖于特定上下文工程的细节，控制接口是可复现的公共合同。这一剥离使『模型当管理者』（model-as-manager）从工程话题变成可科学测量的能力。

四、问题解法

LoopArena 的解法由评测 harness 设计与三级评测设置两部分组成。

4.1 控制周期：三个角色与两种结构化工件

类比一家小型外包公司：Worker 是唯一动手的工程师，Reporter 是只读的项目书记员，Controller 是不见代码的项目经理。每轮工作结束后：

1. Worker（固定为 Qwen3.7-Plus）在持续对话内以原生 ReAct 循环工作，是唯一能用编码工具的角色；
2. Reporter：harness 用 Worker 同款模型配置与 Worker 对话副本创建临时 Reporter 智能体，它可静态只读检查工作区，产出四部分报告——任务上下文与约束、已完成工作与当前状态、验证与证据、未解决问题与不确定性——所有实质性论断须引用对应 Worker 轮次（形如 [E12]）。它在临时副本中运行，不污染 Worker 的持久对话；
3. harness 确定性格式化 Evidence Packet：不含任何额外模型调用，包含四字段报告 + 被引用的完整 Worker 轮次 + 剩余预算；
4. Controller 读取 Packet 与历史，输出 Loop Contract：结构化 JSON，action ∈ {advance, verify, stop} 加理由；advance/verify 还须给出 worker_instruction（goal、context、required_outcomes、prohibited_actions、completion_condition）、protected_invariants 与 verification_acceptance_condition；
5. harness 验证合同并渲染为 Worker 持久对话中的下一条用户指令；stop 则把当前工作区提交给任务评估器。

信息流的关键设计是权限分离与引用机制：Controller 无仓库工具、无完整编码对话；引用的 Worker 轮次让『工具结果』与『智能体陈述』区分开来（前者才是状态的直接证据）。Worker 系统提示中还内置了防护——Controller 给的状态是摘要而非直接观察，工具结果与摘要冲突时以仓库证据为准并上报差异。

4.2 三级评测设置

这是 LoopArena 最有工程智慧的部分——同一能力在三种执行范围与成本下测量：

Type I（契约选择）的构建是论文最精细的环节。类比考试命题中的『执行验证』：在 Controller 引导轨迹的可恢复控制点上，保留原记录合同为候选之一，再由候选作者撰写三个完整可信的替代项（作者分配在各模型家族间平衡），四者及其呈现顺序在观察任何回放结果前冻结。然后在两个预声明的匹配回放调度（种子 S+1,000,000 与 S+2,000,000）下从同一恢复状态执行全部四个候选——相同 Worker、预算、评估器、延续策略、停止规则。只有当两个调度下按『成功且下游控制周期数最少、再比 Worker 轮次』规则识别出同一个唯一赢家时，题目才被保留；全部失败、无唯一赢家、两调度不一致均拒绝，且拒绝后不得改写候选。这意味着正确答案由执行结果定义，事后 LLM 辅助与专家审计只能评估清晰度而无法覆盖答案。

Type II（任务切片）：每个全任务选一个可从准备好的中间工作区评估的阶段，保留条件是起始工作区至少未通过该阶段引入的一条要求、且源提供的完成状态通过该点前的全部要求。每个 Type II 案例与其 Type III 全任务配对，使成本对比与排序对比成为可能。

参考策略：no control（Worker 自主工作到完成）与 fixed control（每个交接点确定性地重述原始目标、恒发 advance——受 Codex 的 /goal 启发）。两者作为共享参照但不参与 Controller 排名。fixed control 的存在使论文能直接检验『机械重复目标是否足够』这一实践中至关重要的问题。

4.3 防泄漏与质量控制

自动化检查验证任务绑定（任务文本、起始工作区、评估器指向同一冻结源实例）、方案泄漏（模型可见输入排除官方方案代码、私有评分输出与后续轨迹事件）、答案稳定性（两调度同一唯一赢家）、Type II 切片有效性与评估器有效性。版本化清单记录每道题/任务的来源、构建记录、评估器身份与审查状态。

五、评估指标与实验证据

5.1 指标体系

• Type I：Contract Accuracy——90 道四选一题的正确率；无效响应（缺失/多个/越界/不可解析）计为错误并单独报告 Invalid Rate。
• Type II/III：Strict Success Rate（SSR）——通过任务评估器且遵守控制协议的运行比例（每策略每任务 3 次独立运行）。SCBench 要求冻结计分集中每条 Core 检查通过；BeyondSWE 要求官方 Harbor 评估器 reward 为 1。
• 估计推理成本——按冻结的公开牌价（无缓存假设）对每次调用的 token 计数求和；Controller 引导运行含 Worker+Reporter+Controller 三类调用。
• 排序一致性——Controller 在 Type II 与 Type III 排序的 Spearman ρ。

5.2 基准构成

27 个源任务（SCBench 11 个 + BeyondSWE 16 个）；Type I 90 题（40/50）、Type II 27 切片、Type III 27 全任务。规模上这是个小而精的基准——它的价值不在覆盖面而在配对设计与执行验证。

5.3 主结果

四个核心结论及其实验支撑：

结论一：全任务循环控制仍然很难。 Type III SSR 范围仅 16.05%–24.69%。最强 Controller（GPT-5.5）比 no control 高 6.17 个百分点（18.52→24.69）——提升真实但绝对水平很低，说明运行时控制是尚未解决的开放问题。

结论二：机械重复目标在全任务上无效。 fixed control 在 Type II 上把成功从 39.51% 提到 46.91%（+7.40），但在 Type III 上与 no control 完全持平（18.52%）。对照实验直接证明：有界切片内持续重申目标有帮助，而全任务控制需要随运行在实现、验证、恢复、停止之间自适应切换的引导。

结论三：Type II 以 64.4% 的成本降低保留全任务比较。 配对的 Type II 相对 Type III 平均估计成本降低 64.4%；Core 准则下 Controller 排序 Spearman ρ=0.9747——九个在两设置中均严格有序的 Controller 对无一反转。这验证了切片评估作为低成本排序设置的效度。

结论四：Type I 揭示单步决策差异且无捷径可走。 Contract Accuracy 范围 72.22%–87.78%，Invalid Rate 全为 0；最强确定性捷径（多数位置）仅 31.11%，均匀选择 25%、词法重叠 18.89%——均远低于最弱 Controller，说明题目确实要求理解 Packet 与候选指令的联合语义。

5.4 诊断性分析

补充发现包括：GLM 5.2 在 Type III 有 20.39% 的 Controller 调用触及 20,480 输出上限（75.93% 的评估至少一次），DeepSeek 仅 1.69%——输出上限成为部分模型的实际瓶颈；运行间稳定性显示多数任务落在 0/3 或 3/3 成功两端；SCBench 换用 all-checks 或 all-non-error 计分会使排序相关性跌到 0.1481 / -0.2962，说明 Core 准则的选择对结论稳健性至关重要。

5.5 指标如何证明论点

这套设计的证明力来自变量控制：Worker、工具、预算、评估器、控制接口全部冻结，唯一自由变量是 Controller 模型，因此 SSR 差异可归因于决策质量；fixed control 参照隔离了『有监督』与『自适应监督』的差异；Type I 的执行验证答案把『单步决策质量』与『下游真实后果』绑定，排除了主观评分。基准能同时支撑『控制能力可测』（三设置一致的区分度）与『控制能力不足』（24.69% 上限）两个主张。

六、效果优势的根源解释

6.1 GPT-5.5 为什么在 Type III 上最强

对比对象：其他四个 Controller（Qwen3.7-Plus、DeepSeek-V4-Flash、GLM 5.2、Claude Opus 4.8）。它们都具备读结构化报告、输出合法 JSON 的基础能力。

机制差异的因果链：全任务控制要求在 8.6–13.5 个控制周期内完成从初始侦察、多阶段实现、验证到停止的完整管理。GPT-5.5 的优势不在于花更多钱（虽然它确实最贵，18.84 美元/run），而在于单步决策质量：其 Type I 准确率 87.78% 比第二名的 77.78% 高 10 个百分点——当每个控制点的决策更准，错误累积更慢，正确路径上的周期占比更高，最终体现在 SSR 领先。反过来 GLM 5.2 的 Type I（74.44%）与 Type III（16.05%，唯一低于 no control 参照 18.52% 的 Controller）同向垫底，且其 20.39% 的输出上限触及率意味着相当一部分运行因协议失败被判负——两个层面的缺陷（决策质量 + 输出纪律）共同压低了端到端结果。

反事实检验：如果决策质量不重要而只看执行预算，DeepSeek-V4-Flash 成本高于 Qwen3.7-Plus（10.24 vs 6.89）应换来更高 SSR，实际反而更低（19.75 vs 23.46）；如果只看单步准确率而忽视序列效应，Claude Opus 4.8 的 Type I（76.67%）与 DeepSeek（77.78%）接近，Type III 却差 1.24 个百分点——说明长时程控制还叠加了历史利用与预算分配能力。

6.2 为什么 fixed control 在全任务上失效

baseline 曾经有效的原因：在 Type II 切片上，任务范围预先收窄到单一阶段，持续重申目标能防止 Worker 在有限范围内漂移，故 +7.40 个百分点。

根本局限的机制：fixed control 的指令生成是状态无关的——它在每个交接点输出同一段 advance 文本，不读取 Packet。全任务的困难恰恰在于证据随运行演化：窄检查通过时另一要求可能仍未触碰、进度笔记可能过时、预算可能耗尽。状态无关策略无法表达『现在该验证而非推进』或『现在该停』，其 Type III 控制周期数（8.32）反而让 Worker 在无引导下多绕路（Worker 轮次 181.54 vs no control 的 125.14），多花的成本没有换来任何成功率提升（两者都是 18.52%）。这是论文最干净的一组对照：有用的控制信号必须是状态的函数。

6.3 为什么 Type II 能保住排序

Type II 的降本来自缩短执行范围而非削弱闭环：它仍保留 Controller–Worker 循环、任务评估器与全部控制协议，只是从中间工作区起步。控制能力的差异主要体现在『阶段内如何分配推进与验证』这一局部决策模式上，而这种模式在切片与全任务间保持一致，故排序传递（ρ=0.9747）。需要诚实的边界：换用 all-checks 计分时相关性崩塌（0.1481），说明该结论依赖于与全任务一致的成功准则定义。

6.4 为什么捷径无效

多数位置（31.11%）之所以是最强捷径，是因为候选呈现顺序可能残留轻微位置偏好，但它仍远低于 72.22% 的最弱 Controller；词法重叠（18.89%）甚至低于随机（25%），说明正确选项不是与 Packet 词面最相似的那个——题目真正考察的是『指令语义 × 当前状态』的联合推理，这种构题质量直接来自执行验证：四个候选都必须真实可执行且导致不同结局。

七、必要知识反推

假设让一个完全没有相关知识的人来完成这项工作，他至少需要掌握以下知识。

7.1 领域知识层

• 编码智能体的运行机制：ReAct 循环如何工作、上下文如何累积、工具调用如何执行——不理解这些就无法设计 Worker 的边界与 bootstrap 指令（首轮只做侦察不实现）；
• 长时程编码任务的结构：真实仓库任务如何分阶段（侦察→实现→验证→收尾）、SCBench 检查点与 BeyondSWE 官方修复的组织方式——这是切任务切片（Type II）的前提；
• Loop Engineering 实践现状：Osmani 博客、Codex /goal 机制等一线实践——fixed control 参照的设计直接受 /goal 启发，不理解实践就无法让基准回答实践关心的问题。

7.2 方法论知识层

• 受控实验设计：变量冻结与单自由度比较的原则——这是『固定 Worker 只比 Controller』的全部方法论基础；
• 基准构建的防污染标准：方案泄漏检查、答案稳定性、冻结后审计不可改答案——来自近年 agentic 基准严谨性研究的积累；
• 低成本评估的效度验证方法：用 Spearman ρ 检验廉价评估恢复全基准排序——来自 ConvCodeWorld 与基准压缩研究的既有范式；
• 过程监督与结果监督的区分：Type I 把『步骤级质量』与『结果定义的正确性』绑定，需要理解 PRM/ORM 文献中两者的张力。

7.3 工程知识层

• 多智能体 harness 实现：持久对话与临时副本的隔离、结构化工件的确定性格式化、协议失败的可验证判定——评测协议的机器可验证性全靠这些工程细节；
• 成本核算：冻结牌价、无缓存假设、按调用累加 token 的标准化估计——否则跨 Controller 的成本比较不可复现；
• 回放基础设施：可恢复控制点、匹配回放调度（种子偏移）、延续策略冻结——Type I 构建的执行依赖这套可复现执行环境。

7.4 知识融合的关键节点

• 洞察一（角色分离 = 可评测性）：把『模型指挥模型』（ManagerWorker 式探索）与『受控比较』（基准方法论）融合，才得到『冻结一切、只换 Controller』的设计——两个知识单独存在时都不产生这个想法；
• 洞察二（执行验证 + 冻结 = 无执行的步骤级评测）：把回放基础设施与考试命题思维融合，把执行成本从评测时搬到建库时，才有了 Type I 的零执行诊断；
• 洞察三（配对设计 = 成本-效度同时可得）：把基准压缩的排序一致性检验嫁接到任务切片上，才敢宣称 Type II 是 Type III 的廉价替代。

八、论文中可以提取的通用性灵感

灵感一：评测『管理者』而非『执行者』——能力解耦式评测范式

核心思想：当系统能力 = 执行能力 × 编排能力时，把执行端完全冻结，只评编排端，可以让不可见的软能力变得可测量。

论文证据：固定 Qwen3.7-Plus 为 Worker 后，五个 Controller 在 Type III 上拉开 16.05%–24.69% 的差距，而固定参照显示 no control 与 fixed control 同为 18.52%——编排能力的差异在解耦后完全显形。

推广场景：(1) 多智能体系统中的规划者/协调者角色选型；(2) 深度研究智能体中的检索策略控制模型评测；(3) 自动驾驶中的规划模块独立评级；(4) 人机协作中人类管理能力的模拟与评估；(5) RL 中的 world model 与 policy 分开评测。

灵感二：把执行成本搬到建库期——『执行验证式静态题』的构建模式

核心思想：如果一道题的正确性需要昂贵的执行才能确定，可以在构建期执行所有候选、以真实结局冻结答案，评测期就变成零执行的廉价选择。

论文证据：Type I 在两个匹配回放调度下执行全部四个候选、只有同一唯一赢家才保留，建成后评测一个新 Controller 只需 90 次四选一（GPT-5.5 成本 9.43 美元），且捷径上限 31.11% 证明题目无法被表面线索攻破。

推广场景：(1) 临床决策基准（构建期用模拟器验证每个候选处置的结局）；(2) 代码评审基准（每个评审意见的采纳与否由后续执行定义）；(3) 游戏策略评测（离线自对弈验证候选走法）；(4) 运维故障处置基准（沙箱中重放验证候选操作）；(5) 任何『选项后果可模拟但昂贵』的决策评测。

灵感三：状态无关的重复控制等于没有控制——自适应是控制的必要条件

核心思想：对长时程过程而言，不读取状态反馈的控制信号（哪怕持续存在）在统计意义上与无控制等价。

论文证据：fixed control 在 Type III 上 SSR 与 no control 完全持平（18.52%），却多花 2.8 倍成本（5.58 vs 2.01 美元）；只有在范围有界的 Type II 切片上重申目标才有 +7.40 的增益。

推广场景：(1) 项目管理中的『每日重申目标』不能替代状态检查点；(2) 教育中的持续提醒 vs 根据学习状态调整教学策略；(3) 自动交易中的固定再平衡 vs 状态驱动调仓；(4) 智能体框架设计中 /goal 类机制必须与证据感知的调度配合；(5) 健康管理中的定时提醒 vs 依据监测数据自适应干预。

灵感四：配对降范围 + 排序一致性检验——廉价评估的效度自证套路

核心思想：要证明一个低成本评估可信，不是让它单独得分高，而是证明它与全量评估在同一组被测对象上给出一致的排序。

论文证据：Type II 与 Type III 逐对配对（27 对），成本平均降 64.4%，Controller 排序 Spearman ρ=0.9747、九个严格有序对无一反转——这个数字本身就是 Type II 的『合格证』。

推广场景:(1) 面试中的电话初筛 vs 完整面试轮的一致性校验；(2) 模型评估中的子采样基准与全基准排序对齐；(3) A/B 测试中的短周期代理指标验证；(4) 招聘中的试用任务与长期绩效的相关性分析；(5) CI 中的快速冒烟测试与全量回归的排序一致性。

灵感五：结构化只读摘要 + 引用回溯——监督者信息接口的设计模板

核心思想：给决策者（监督模型/人类）的信息接口应该是『结构化、只读、可回溯到原始证据』的三合一设计，既压缩信息又保留可验证性。

论文证据：Evidence Packet 由 Reporter 四字段构成、每条实质论断强制以 [E12] 形式引用 Worker 轮次、harness 自动把被引轮次全文附上；Controller 提示词明确要求『工具结果与报告冲突时信工具结果』——这个接口让无仓库访问权的 Controller 仍能做证据分级判断。

推广场景：(1) 企业管理报表中的附注与底稿链接；(2) RAG 系统的答案必须带出处片段；(3) 医疗 AI 会诊摘要须可回溯到检验原始值；(4) 新闻聚合的结构化事实卡与信源引用；(5) 任何 LLM-as-a-Judge 系统的输入接口设计。

灵感六：对照策略先行——把『最省事的替代方案』做成 baseline

核心思想：提出复杂机制前，先把实践者最容易采用的廉价替代（机械重复、恒等策略）做成对照，才能证明复杂性的必要。

论文证据：fixed control 的设计动机直指 Codex /goal 一类实践——『重复重述目标够不够？』这个问题由 18.52% 的持平答案终结，为『自适应控制』的必要性提供了最强背书。

推广场景：(1) 推荐系统中用热门榜对照个性化模型；(2) 缓存策略中用 LRU 对照学习型替换；(3) 教学方法中用重复讲授对照自适应教学；(4) 任何声称『智能』的系统都应先与『勤能补拙』的笨办法对比。

附录：本文值得记录的工程细节

• 角色间防注入设计：Worker 系统提示把 Controller 指令定位为『进度的摘要而非直接观察』，要求工具结果冲突时以仓库证据为准——这为多智能体信息流中的信任分级提供了范本；
• 预算与协议的机器可判失败：触及输出上限、不可解析合同、Reporter 超限均计为失败而非重试——评测协议的可验证性优先于给模型留面子；
• 一个精炼的 Type I 实例：移除不支持 Django 版本的任务中，四候选分别为删除被需要的依赖（错）、删除正在使用的依赖（错）、保留孤儿依赖再检查（错）、删除孤儿 drf39 依赖同时保护活跃配置（对）——正确选项要求同时理解矩阵状态与依赖活性，词面相似度无法区分。