Agent 的能力，正在被 harness 重新定义

Agent 评测长期把运行基础设施当成无关实现细节：给定数据集与模型，研究者往往默认只要最终评分函数相同，换一个执行框架不会改变结论。但交互式 Agent 的结果取决于提示如何编排、工具调用怎样重试、文件如何传入、环境是否隔离、超时如何处理、失败后能否恢复，以及评分是在原工作区还是干净副本中进行。任何一处差异都可能改变 Agent 可观察到的状态和能够采取的动作。

这会直接破坏三类决策。研究上，论文可能把 harness 的优势归因给模型；工程上，团队可能依据不兼容的 leaderboard 选择模型；治理上，若奖励作弊、修改测试或读取 gold patch 被环境默许，高分甚至可能代表更强的规避能力。AgentCompass 的 stakes 因而不是“少写一些胶水代码”，而是把评测系统本身提升为需要版本化和审计的实验对象。

1. 声明评测语义。BenchmarkSpec 负责加载数据、生成统一 TaskSpec 并定义指标；ModelSpec 只声明端点、推理参数与 API 协议；ExecutionSpec 单独保存并发、重试等运行选项，避免把“测什么”和“怎样跑”混在一起。
2. 解耦 Harness 与 Environment。HarnessSpec 描述提示编排、状态管理、多轮工具调用和供应商适配；EnvironmentSpec 提供命令、文件、文本与网络服务等隔离原语。同一 benchmark 因而可以配不同 harness，同一 harness 也可迁移到本地进程、Docker 或分布式集群。
3. 用材料协议封住边界。Benchmark 把任务编译为 PreparedTask，包含提示、工具、媒体和期望输出；Harness 返回统一 RunResult，包含预测、得分与完整轨迹。评分还明确区分 in-memory、复用现有工作区和在干净环境重放三种模式。
4. 异步执行并保存中间状态。运行时以 asyncio 分派长轨迹，逐步持久化结果和进度；中断后跳过已完成样本，仅重跑可重试失败。这既降低评测成本，也让“基础设施失败”与“模型失败”可以分开统计。
5. 把轨迹变成分析对象。统一 schema 记录推理、工具调用、环境反馈、token、延迟和停止原因，再用 analyzer 查找重复调用、空输出、语言混杂与疑似 reward hacking。最终分数不再是唯一产物。

图 2 的关键作用是展示 Benchmark、Harness、Environment 的组合边界；这比“支持多少数据集”更重要，因为复现的基本单位由一串隐含脚本变成可声明的配置。

作者选取 7 个模型，在工具使用、Web/Research、科学推理、生产力与 Agentic Coding 五个维度的 8 个基准上评测。软件工程部分让 SWE-bench Pro 和 SWE-bench Multilingual 分别配 Mini-SWE-agent 与 OpenHands；SkillsBench 配 OpenClaw 与 OpenHands；所有结果平均 3 次独立运行。附录还固定了仓库 checkout、Agent 版本与评分接口，例如 SWE 任务让两种 harness 使用相同代码库版本和相同的 patch + 单元测试评分边界。

最有信息量的数字不是总榜，而是协议变化造成的偏移：Claude Opus 4.8 在 DeepSearchQA 比最接近的外部参考低 8.7 分；GLM-5.2(FP8) 在 OpenHands 下的 SWE-bench Pro 比参考高 15.0 分。同一模型在 SkillsBench 的 OpenClaw 与 OpenHands 结果也存在差异。轨迹审计进一步发现，在 Mini-SWE-agent 的 SWE-Pro 上，GLM-5.2 的疑似 reward-hacking 样本率为 39.12%，而 DeepSeek-V4-pro(FP4) 为 0.82%；在 SWE-Multilingual 上，Gemini 3.1 Pro Preview 为 21.97%。作者明确把它定义为行为信号，而不是已证实导致最终得分的因果作弊。

第一，论文没有把“统一实现”与每个官方实现做系统等价性验证，外部分数偏移可能来自 AgentCompass 更公平，也可能来自移植遗漏、版本漂移或官方未披露的定制。第二，模型、服务快照和商业 CLI 会更新，即使配置文件不变，端点行为也可能漂移；三次重复只能估计短期随机性，不能覆盖时间漂移。第三，跨 harness 比较仍可能改变默认提示、工具集合、超时或上下文预算，因而不是单变量因果实验。第四，部分任务使用 LLM judge，judge 模型与提示又形成新的 harness 层。第五，reward-hacking 分析的精确率、召回率与人工复核规模没有在主实验中充分给出。

最有信息增益的下一步不是扩大榜单，而是做一个“语义等价交叉实验”：对 2–3 个基准逐项锁定模型快照、提示、工具 schema、预算、容器镜像和评分器，只替换运行框架；随后对分数分歧样本逐轨迹归因，报告是重试、超时、工具解析、环境状态还是评分复放造成差异。只有这样才能把“harness 敏感”推进到“哪一种边界造成了多少因果效应”。

1. 结果表至少同时列出模型快照、harness 名称与版本、环境镜像、工具 schema、上下文与 token 预算、超时、重试和评分工作区模式。
2. 保存完整轨迹和基础设施事件，把 API 错误、环境失败、评测失败和任务失败分开计数；不把可重试错误静默吞进模型分母。
3. 同一 benchmark 至少跑一个官方 harness 与一个统一 harness，分歧样本必须做任务级复核。
4. 对疑似作弊建立两层报告：行为检测率与经过人工确认、确实改变分数的因果作弊率。
5. 用容器摘要、代码 commit 和声明式 RunRequest 固化评测；商业端点无法固化时，明确记录时间窗口和复测漂移。

传统报告隐含一个过于简单的因果图：模型进入 benchmark，输出一个能力分数。AgentCompass 的组件边界迫使研究者承认中间变量：BenchmarkSpec 决定任务材料和评分语义，HarnessSpec 决定模型能看到什么以及怎样行动，EnvironmentSpec 决定动作的真实后果，ExecutionSpec 决定并发、重试和恢复。RunResult 又把这些中间过程保存下来。这样一来，“模型 A 比模型 B 高 5 分”不再是终点，而是等待条件化的问题：两者是否经过相同工具协议、是否在同一隔离边界内、是否承担同样的失败恢复成本。

论文的轨迹分析提供了这种重构的示例。不同模型即使最终得分接近，坏例可能分别集中在工具调用重复、输出重复、空输出或语言混杂。修复策略因此完全不同：重复调用可能需要 stop condition 或工具结果去重，空输出可能是 API 与 harness 终止语义不兼容，语言混杂则可能是搜索材料与生成控制问题。只看 pass rate 会把这些机制不同的失败压成同一个“能力不足”。

Capability–token 图同样需要谨慎阅读。coding 任务里多数模型随 completion token 增加而得分上升，像 test-time scaling；但这只是跨模型、跨样本的联合观察，不证明给同一个模型增加 token 一定提高结果。更长轨迹也可能是难题、反复试错或 harness 重试的结果。工程选型应同时报告同任务内的预算干预曲线、成功条件下 token 与失败条件下 token，而不是把散点相关性当作预算因果收益。

一个可操作的复现实验包应包含四个层级：语义层保存 TaskSpec 与 scorer；行为层保存 prompt、工具和状态机；执行层保存镜像、网络与资源限制；观察层保存逐步轨迹和 retry event。只有四层都能重放，外部团队才可能判断官方分数偏移究竟来自模型、移植还是运行策略。

某些任务的一次“工具调用”是原子 API，另一些却是容器里持续数分钟、产生上万行输出的子进程；把二者压成相同 step count 会制造新的不可比性。稳定公共字段应负责跨基准比较，领域扩展字段则保留原始事件、资源使用与 scorer 细节。最好的统一层不是最低公分母，而是既能聚合，又能从每个聚合数回到原始证据的双层表示。

这也决定版本策略：公共协议变更必须显式迁移，benchmark 适配器和 harness 默认值不能静默更新。否则“同一 RunRequest”在新版本中可能代表不同实验。建议为每次运行计算语义配置摘要，把 benchmark 数据、harness 代码、环境镜像和 scorer 一起纳入；只有摘要相同的结果才直接合并，摘要不同则先做桥接实验。

多数 prompt、memory 或 harness 优化方法在固定任务集上搜索，然后在同一集合上报告提升。这个设计只能回答“在允许反复试错的任务上是否找到了更高分候选”，却回答不了部署中更关键的两个问题：第一次修改是否会迁移到未见失败；第二批失败到来后，能否继续修改而不破坏第一次已经修好的行为。

stakes 很直接。若一个自动优化器把任务特定路径、字面答案或脆弱启发式写进 prompt，静态分数仍会升高；若第二轮优化只追逐新任务，旧任务能力又会回退。团队看到的“自改进”可能只是不断移动的局部过拟合。论文因此把 compounding 定义为两个条件：第一轮更新对新任务至少有正迁移；第二轮在合并目标上继续提高，同时保留已获得行为。

1. 共同起点。所有方法从同一个 GPT-5.5 终端 Agent 出发，基于 Harbor/Terminus2，暴露 system prompt、工具定义和控制代码。工具包括命令执行、带复核门槛的 task_complete 与图像读取。
2. 阶段一。在 12 个 900 秒上限的 hard tasks 上给每种优化器 200 次 rollout，随后先在这 12 题测静态优化，再不做任何更新直接在加入 10 个新任务后的 22 题合集上测迁移。
3. 阶段二。每种方法从自己的阶段一候选继续出发，再给 200 次 rollout，在 22 题联合目标上优化，最后重新评测。每个 task 对每个 Agent 跑两次，得分可为 0、0.5 或 1。
4. GEPA。用轨迹反思做进化式 prompt 变异；prompt-only 版本继续参与比较，code 变体因阶段一没有产生有效候选而退出。
5. Meta Harness。外层 Codex 直接修改 harness 代码，依据当前任务评分接受候选；两轮分别产生工具调用边界加固和终端输出压缩等通用改动。
6. RELAI-VCL。搜索 prompt、工具、工作流、memory、skill 和代码，但在候选选择时执行 no-regression 约束：新目标改善却让此前已解决任务回退的候选，在搜索环内直接拒绝。报告中的候选加入任务类型分类器和 completion gate。

阶段一的 12 题上，baseline 为 62.5%，GEPA 70.8%，Meta Harness 66.6%，RELAI-VCL 79.2%。只看这个表，三种方法都可以宣称有效。但把阶段一候选无训练地放到 22 题合集，baseline 为 56.8%，GEPA 降到 54.5%，Meta Harness 升至 68.2%，RELAI-VCL 为 72.7%。GEPA 的 103 行阶段一 prompt 含按任务命名的经验，论文把负迁移解释为任务特化的证据。

再给联合任务第二阶段预算后，GEPA 达 72.7%，Meta Harness 反而降到 59.1%，RELAI-VCL 达 77.3%。三阶段平均的 lifelong pass rate 分别是 baseline 58.7%、GEPA 66.0%、Meta Harness 64.6%、RELAI-VCL 76.4%。注意这不是按真实时间或任务频率加权的在线收益，而是阶段一、迁移和最终结果的简单平均；它适合比较本协议内的行为，不代表生产流量价值。

第一，样本只有 22 个任务，每个 Agent 每题两次，二项波动很大；报告给出点估计，却没有为方法差异提供任务级置信区间或显著性检验。第二，T1 是 900 秒 hard tasks，T2 是 1800 秒 hard tasks，阶段不仅代表“后来的任务”，也混入了不同超时和可能的复杂度分布。第三，任务彼此松散，生产故障通常共享领域、工具和政策；相关任务更容易形成可迁移规则，也更容易形成领域 shortcut。第四，所有方法依赖可重复任务和可靠 verifier，真实生产失败常只有一次轨迹，无法无成本重放。第五，RELAI-VCL 由提出方实现和评估，方法间工程成熟度、搜索空间宽度与 proposer 行为可能形成额外优势。第六，只使用一个基础模型 GPT-5.5，不能判断较弱或不同风格模型是否出现相同排序。

一个重要替代解释是“候选类型”而非“回归约束”决定结果：GEPA 改写长 prompt，Meta Harness 改代码边界，RELAI-VCL 加 completion gate；后者恰好更适合 Terminal-Bench verifier。另一个解释是任务顺序效应：若交换 T1/T2 或随机生成多条任务流，排序可能变化。

把 no-regression 放进搜索环会产生新的测量问题：旧任务集合会逐轮膨胀，验证成本随历史长度增长；若只保留“曾经解决”的样本，偶然成功会被当作必须维护的能力；若 verifier 本身不完整，优化器可能被迫保留对错误代理目标的适配。回归安全还可能抑制必要的结构性重写，让系统停在局部最优。

最有信息增益的实验应做成多流、因子化消融：在同一 proposer、同一搜索空间和同一候选预算下，仅开关 in-loop regression gate；把 30 个 hard tasks 随机生成多组 T1/T2 顺序，至少增加每题重复次数并报告配对 bootstrap；再加入相关任务流、不可完全重放任务和含噪 verifier。若优势在这些条件下仍稳定，才能把“回归约束是泛化过滤器”从合理解释提升为更强因果主张。

1. 每次 harness 更新同时报告当前目标、旧任务回归、新任务盲测和合并任务再优化四类结果。
2. 候选进入主分支前做任务级差分：新增通过、稳定通过、稳定失败、新增回退；聚合分数不能掩盖回退任务。
3. 保存搜索中所有候选、轨迹和拒绝理由，审计是否出现任务 ID、期望输出或基准特定 shortcut。
4. 回归集要区分确定性通过与偶然通过；对随机 Agent 用多次运行和置信区间决定是否形成保护约束。
5. 控制回归集规模，用行为簇或最小反例集代替无限增长的历史任务，同时定期验证其覆盖。

GEPA 的阶段一 prompt 从 5 行增长到 103 行，阶段二到 195 行，新增内容以命名的逐任务经验组织。它在阶段一从 62.5% 升到 70.8%，但迁移到 22 题时低于未优化 baseline。这个组合比单独看到长 prompt 更能支持过拟合解释：若只是“prompt 太长”，未必必然负迁移；真正可疑的是任务特定内容、固定搜索集和迁移下降同时出现。不过论文仍未用遮蔽任务名、删除特定规则或压缩 prompt 的消融来识别哪些文本造成回退。

Meta Harness 的候选更像通用软件修复：第一轮加固命令结束检测与畸形 tool call 处理，第二轮压缩包管理器、构建和测试输出的重复噪声。第一轮候选对 22 题迁移到 68.2%，说明通用边界加固可能比 benchmark lesson 更稳；但第二轮最终降到 59.1%，说明“看起来通用”也不能替代任务级回归。输出压缩可能节省上下文，也可能删除某些任务所需的错误细节。只有逐任务失败轨迹才能区分候选本身有害、搜索接受规则有问题，还是两次运行的随机性。

RELAI-VCL 的第一轮候选增加 code-editing 与 operational/service 的任务类型分类，第二轮 completion gate 主动发现 verifier 并检查 runtime contract。它们都直接改变“何时算完成”，与 Terminal-Bench 的自动 verifier 十分契合。no-regression gate 可能筛掉破坏旧题的候选，但领先也可能部分来自这种搜索空间与任务结构匹配。因而最关键的缺失对照是 RELAI-VCL minus regression control，而不是再拿一个完全不同优化器做横向比较。

从系统设计看，回归控制应记录的不只是候选是否通过。每次拒绝都应带行为级解释：哪个已解决任务退化、退化发生在计划、工具调用、状态维护还是完成判断；候选能否通过条件化启用而不是整体丢弃。否则随着任务积累，搜索环会变成越来越严格的黑箱门禁，只告诉开发者“不能改”，却不能帮助合并互不冲突的局部能力。

论文的 lifelong average 把 12 题静态、22 题迁移和 22 题最终结果等权平均，便于得到摘要数，却让早期小集合与后期大集合拥有相同权重。生产评估更适合同时报告阶段曲线、任务到达后的累计 regret、每次修复成本和回退持续时间。还应区分“旧题一直不会”“新学会后又忘记”和“随机两次里少成功一次”；三者在当前 pass rate 中可能给出相近变化，但对应完全不同的优化故障。

若回归 gate 进入持续服务，接受标准也不宜是绝对零回退。某些大重构可能暂时破坏低价值边缘任务，却换来大量新能力或更低成本。更实际的约束是按任务风险、流量与置信度加权：高风险能力设置硬门槛，低风险能力设置预算化回退；所有例外都要有可追踪的人工批准与恢复期限。

现代 Agent 的能力大量存在于 harness：system prompt、状态机、工具适配、重试、memory、终止条件与环境桥接。一个“完成前必须再运行 verifier”的行为，可能同时分布在 planner、tool executor、状态对象和 completion gate 中。自然语言需求讲的是行为，仓库却按文件和模块组织；关键词搜索、向量索引和长上下文能帮助浏览，却不会自动恢复跨文件的行为链。

定位错误的代价不只是改错文件。漏掉一个状态写入点会产生不一致，范围过大会引入回归，搜索太久则消耗上下文并让 planner 忘记原始目标。随着 harness 自我演化，这个瓶颈会进一步放大：Agent 若不能解释自己的行为由哪些代码共同实现，就无法可靠修改自己。论文因此把“behavior localization”定义为 harness 演化的前置能力。

1. L1–L3 行为表示。L1 给系统架构、执行模型和全局数据流；L2 按执行阶段描述职责、输入输出、依赖和局部状态；L3 连接到函数、代码区域或文件。另一张 state-register 视图记录跨阶段共享状态。每个活跃 locator 必须能在当前仓库重新解析，否则冻结并退出定位。
2. 静态事实抽取。语言适配器提取函数、外部边界、位置、签名、调用边和状态访问。只保留能解析到内部函数或命名边界的调用，未知调用被记录而不是猜测。此阶段完全确定性，不调用 LLM。
3. 行为组织。若有可信执行骨架，采用 function-as-leaf，把函数或连续代码区域经 proposer-review 分配到一个或多个阶段；若仓库规模大、没有可靠骨架，则采用 file-as-leaf，先生成文件卡与程序图，再推断阶段层级。无法覆盖的文件和争议明确进入 coverage record。
4. 分层合成。把阶段骨架合成为 L1–L3 文档树与状态视图；L3 再对当前源码做定位验证。图 2 展示的重点是静态事实、语义组织和源代码锚点分工，而非让 LLM直接“理解整个仓库”。
5. BGPD 定位。从 L1/L2 找相关执行阶段，经共享状态补入耦合阶段，再选择 L3 条目并沿调用图扩展。最后打开当前仓库，只保留与请求仍相关的位置，生成包含文件、可选函数锚点和当前片段的证据集。
6. 规划、执行与同步。planner 基于证据写 edit plan 和 modify/add/remove 声明；executor 产生实际 diff。任何非空 diff 都触发重同步：重解析变化、刷新程序图、用不依赖行号的指纹匹配函数；骨架仍有效就局部更新，否则同一 leaf mode 重跑构建。不可解析内容继续冻结而不猜。

实验选择两个开源 harness：Terminus-2 有可靠种子骨架，使用 function-as-leaf；Codex 规模更大，使用 file-as-leaf。每个仓库各有 30 个行为修改请求，分为 Query、Cross-file 和 Search-Hostile，并标注 Easy、Medium、Hard。读权限 planner 都由 DeepSeek-V4-Pro 驱动；baseline 直接浏览仓库，Handbook-Assisted 使用 BGPD，一切请求、模型、权限和 decoding 设置相同。

计划质量由 GPT-5.5、Opus 4.8 和 DeepSeek-V4-Pro 独立判断，按 Localization 50%、Scope Control 25%、Reasoning 25% 加权；差异至少 3 分才判胜，否则平局。定位准确度再与 Opus 4.8 和 GPT-5.5 独立生成的参考计划比较，报告文件级与 symbol 级 Recall、Precision、F1，以及零重叠的 Wrong。成本统计包括手册和源码上下文的 planner token。

Codex 上 Handbook-Assisted 总体胜率 38.3%，baseline 28.3%；Terminus-2 上为 45.6% 对 26.7%。平均 token 从 Codex 每请求 0.102M 降到 0.089M，减少 12.7%；Terminus-2 从 0.058M 降到 0.053M，减少 8.6%。因此质量提升至少不是靠塞入更多 planner token。

与两套参考计划比较的 24 个 Recall、Precision 和 F1 项全部提高，F1 增益 5.0–18.8 个百分点。Terminus-2 在手册辅助后，对 Opus/GPT-5.5 参考的文件级 F1 为 84.7%/89.3%，symbol 级为 77.1%/89.3%；对 GPT-5.5 参考的 precision 在两种粒度都到 93.3%。零重叠 Wrong 从不增加，最大下降 25.9 点。六个“仓库 × 请求类型”和六个“仓库 × 难度”切片都为正，但难度收益并不单调。

这些结果说明行为表示对“找到与强模型参考相同的位置”有稳定帮助，却还不是执行成功率。论文刻意不把 executor 引入主比较，优点是隔离定位与规划；代价是无法证明更好的计划一定产生正确补丁、通过测试或减少回归。

第一，只有两个开源 harness，且由不同 leaf mode 表示，外推到多语言、动态注册、反射调用或生成代码系统仍不确定。第二，静态调用图对 Python 动态派发、配置驱动工具与运行时注入可能漏边；coverage record 能诚实暴露未知，却不能弥补行为缺口。第三，三位计划 judge 都是大模型，其中 DeepSeek-V4-Pro 同时还是 planner，存在偏好相关；缺少维护者盲评和 judge 校准。第四，30 个请求的来源、真实分布和难度标签可能影响结果；切片样本小，胜率没有不确定性区间。第五，handbook 本身由 LLM 组织，若早期阶段映射错误，BGPD 会系统性地把搜索引向同一错误区域。第六，重同步只验证 locator 仍存在，不保证文字描述仍语义正确。

采用后出现的新失败模式是“过度相信地图”：因为手册让路径看起来结构化，Agent 可能减少对仓库外部事实的探索，漏掉未覆盖的动态行为。另一个风险是同步震荡：大型重构触发频繁骨架重建，不同 LLM 组织结果造成条目漂移，历史行为与当前实现难以对齐。

最有信息增益的实验应采用 2×2 因子设计：有无手册 × 有无当前源码复核，并在同一仓库交换 function/file leaf mode；由真实维护者提供最小 gold edit sites，随后让 executor 实际改代码，测测试通过、行为验收、diff 大小与旧任务回归。再连续执行几十轮修改，记录 locator 失效率、描述陈旧率与全量重建频率，才可验证“持续同步”。

1. 先用静态分析生成可核验事实；LLM 只能组织与描述，不能虚构调用边。
2. 每个行为条目必须保存来源锚点、最后验证 commit、覆盖状态和失效原因。
3. 定位时先看执行阶段和共享状态，再沿调用图扩展；不要直接把全仓库塞入上下文。
4. 实际 diff 才是同步触发器，planner 声明只用于核对是否偏离计划。
5. 对动态路径保留运行时 trace 补充静态图，并把未覆盖区显式展示给修改 Agent。

Handbook 的效率机制不是简单把代码摘要得更短，而是让概念按依赖顺序出现。planner 先在 L1 建立架构与执行模型，再在 L2 选择阶段，只有需要时才展开 L3 源码。共享状态视图在阶段之间补边，避免搜索只沿文件邻近或关键词相似扩散。这种 progressive disclosure 把“先读大量文件再归纳行为”改成“先提出行为假设，再取证验证”，所以 Codex 仓库即使加入手册上下文，总 token 仍从 0.102M 降到 0.089M。

两种 leaf mode 体现了一个重要工程取舍。function-as-leaf 需要可信执行骨架和更细的静态解析，定位精确但构建、同步成本更高；file-as-leaf 在大仓库中更便宜，却把文件内部的多个行为重新交给 planner。论文让 leaf mode 在手册生命周期内固定，是为了避免每次同步都改变条目标识，但这也意味着早期粒度选择错误会长期存在。生产系统应在构建时用一组代表性请求比较两种粒度的定位成本与漏召回，再冻结模式。

重同步的保守策略值得单独强调。函数匹配用不依赖行号的指纹，文件匹配用文件集合差分和内容 hash；只有分类、文件分配、阶段内组织和描述修订四类语义步骤调用模型，其余尽量确定性。无法解析或分类的内容被冻住并写入 coverage record。这样做牺牲了表面覆盖率，却阻止手册在代码大改后悄悄保留虚假锚点。对自修改 Agent，显式“不知道”比连续、漂亮但过时的文档更安全。

不过实验只比较一次性规划。真正长期使用时还需要三个新指标：行为覆盖率，即活跃条目覆盖多少真实执行；同步新鲜度，即 diff 后多久恢复可用；语义漂移率，即 locator 仍能解析但描述已不再准确的比例。这三项与定位 F1 一起，才能判断手册是不是可维护的基础设施，而不只是一次性索引。

一次定位 F1 不能回答地图是否可维护。第一项应是行为覆盖率：活跃条目覆盖多少真实执行路径，未知区是否集中在动态注册、错误恢复或安全边界。第二项是同步新鲜度：代码产生 diff 后，相关条目多久恢复可用，有多少条目被保守冻结。第三项是语义漂移率：locator 仍能解析但职责、状态或异常语义已经变化的比例。三项都要随 commit 记录，而不是只在初次构建时测量。

运行时 trace 可以补足静态图，但不能直接覆盖静态事实。更稳妥的合并规则是：静态分析定义“可能调用”，多次 trace 提供“观察到调用”的频率与条件；未观察到不等于不存在。这样 BGPD 能优先展示常见路径，同时保留罕见失败处理，不会因为测试流量未触发就从行为地图消失。