AI Agent 跨层张力、因果失效与前沿判断

Part 15–18 深度卷｜证据快照：2026-08-03
目标不是记住热点名词，而是获得一种稳定的技术判断力：能识别真正控制变量，能从症状定位首次责任边界，能判断一项新工作到底改进了什么、证据支持到哪里、何时不应相信它。

0. 先建立一条总纲：Agent 是一个闭环因果系统

Coding Agent 的最终结果不是“模型输出”的同义词，而是下列联合系统在某个任务分布上的结果：

[ Y = F(I, S, M, C, H, T, E, R, V, P, U) ]

其中：

• (I)：用户 intent 与任务规范；
• (S)：初始世界状态与仓库状态；
• (M)：模型及其推理、tool-use、effort 等能力；
• (C)：进入模型的 context 与 memory；
• (H)：harness，即 loop、prompt、tool routing、状态管理、恢复等运行时策略；
• (T)：工具 contract 与执行器；
• (E)：sandbox、依赖、网络、权限、算力等 environment；
• (R)：runtime 的持久化、调度、取消和 effect reconciliation；
• (V)：verifier、tests、judge 与完成判据；
• (P)：policy、identity、authority、containment；
• (U)：用户审批、介入、接管和最终验收。

这不是普通的“因素清单”。这些变量有强交互项：一个更强模型可能更依赖某种 tool feedback；一个更长窗口可能放大污染；一个更强 verifier 可能改变模型的探索策略；一个更快的多 Agent 架构可能压垮 review 队列。因此：

[ \Delta Y_M \neq Y(M_2)-Y(M_1) ]

除非其他条件被控制，所谓“模型提升”只是整套配置的差异。

0.1 五条跨层定律

1. 配置单元定律：Agent 能力最小可报告单元通常是 model × harness × environment × budget × verifier，不是裸模型名。
2. 首错传播定律：最终可见失败常由更早的错误状态传播而来；最后犯错的组件不一定是根因组件。
3. 状态复利定律：进入 durable state 的错误会跨 step、turn、session、agent 复利；memory、journal、artifact 的写入必须视为高风险 transition。
4. 验证守恒定律：生成吞吐可以靠并行快速放大，可信吞吐不能超过 specification、oracle、review、integration 与 recovery 的总能力。
5. 权威不可继承定律：一段数据被检索、总结、转发或通过协议到达，并不会自动获得行动 authority；provenance 与 authorization 必须独立存在。

0.2 跨层因果图

读这张图时要注意四件事：

• Context 不是世界状态，只是世界状态的有损投影；
• Model decision 不是 effect，effect 还要经过 policy gate、executor 与 environment；
• Tool success 不是任务成功，最终完成仍需 verifier 对照 intent；
• trace 是诊断证据，不天然是安全边界；记录了越权行动并不等于阻止了越权行动。

0.3 四种结论强度

本卷对 2025–2026 材料使用四种状态，避免“有论文”等于“已成共识”：

“preprint / peer reviewed”与这四级是两条轴。同行评审不能弥补错误 oracle；一篇新 preprint 也可能提供非常强的可复现实验。

1. 十组核心张力：不是二选一，而是条件化设计

每组张力都按五个问题分析：何时成立、真正控制变量是什么、常见假二分是什么、如何组合、怎么验证。

1.1 Model vs Harness

张力本质

模型给出条件策略 (\pi_M(a\mid c))；harness 决定模型能看到什么 (c)、可采取什么行动 (A)、何时得到反馈、如何保存状态、何时停止。因此 harness 不只是“模型外壳”，而是在改变可观测性、动作空间和 transition dynamics。

适用条件

• 比较不同 foundation model 时，必须固定 harness，才能估计 model effect；
• 比较不同 harness 时，必须固定 model、task、budget、environment 与 verifier；
• 做真实产品选择时，不必执着分离两者，应比较完整 configuration 的 Pareto frontier；
• 研究可迁移机制时，必须同时做 cross-model 与 cross-harness transfer。

真正控制变量

假二分

• “模型够强就不需要 harness”：更强模型仍需要真实世界 I/O、effect boundary、恢复与证据；只是某些补偿模型弱点的 scaffolding 会过时。
• “harness 比模型更重要”：重要性取决于局部梯度与任务分布；差 harness 可压低强模型，强 harness 不能无限越过模型能力上限。
• “prompt 就是 harness”：prompt 只是 harness 一个部件。tools、middleware、memory、state、permissions、verifier 往往比措辞更结构化。

可组合解

• 保持稳定的 semantic kernel：turn、tool call、effect、receipt、checkpoint、completion；
• 在边缘放 capability-aware adapter：thinking、parallel tool use、media、cache、effort、provider error；
• 将 harness assumption 写成可删除、可版本化、可 ablate 的 policy，而不是散落的 prompt folklore；
• 采用二因素或多因素实验：model × harness × budget，报告主效应和交互效应。

当前证据与边界

Harness-Bench 在 106 个任务、5,194 条 trajectory 上观察到显著 model–harness pairing 差异；Claw-SWE-Bench 在相同 GLM 5.1 下报告 minimal adapter 19.1%、full adapter 73.4%，并分别观察到 29.4pp model effect 与 27.4pp harness effect。这足以把“model-harness configuration”提升为默认报告单元，但还不足以推出某套 harness 在所有模型、任务和预算上占优。

一句话判断：模型决定策略潜力，harness 决定它能否与现实对齐；研究时拆开，部署时合看。

1.2 Long Context vs Context Engineering

张力本质

长窗口增加名义容量 (L)；context engineering 优化进入窗口的证据集合 (C^*)。目标不是最大化 token 数，而是最大化单位推理成本下的有效决策信息：

[ \text{Context Value} \approx \frac{\text{relevant} \times \text{faithful} \times \text{timely} \times \text{authoritative}}{\text{tokens} \times \text{latency} \times \text{contamination risk}} ]

适用条件

• 原始记录需逐字推理、证据分散且难以检索时，长上下文直接有价值；
• 仓库极大、信息动态、重复与噪声多时，检索和投影更关键；
• 跨 context window 长任务必须使用 compaction、artifact 或 external state；
• 高风险决策必须保留原始证据引用，不能只依赖摘要。

真正控制变量

• gold evidence recall、precision 与首次发现时间；
• evidence density、position、ordering、duplication；
• tool output truncation 与 lossy projection；
• compaction 的 coverage、preservation、faithfulness；
• freshness、scope、provenance、authority；
• KV cache 命中、输入成本、latency；
• 模型在目标长度上的实际利用能力，而非 API 标称窗口。

假二分与组合解

• 假二分：“全塞进去”或“全靠 RAG”。正确做法是分层：稳定 instructions + task-local working set + 按需检索 + artifact pointers + 可验证 compaction。
• 假二分：“摘要”或“原文”。摘要负责导航，原文负责举证；高风险 claim 必须可追溯到原始 span、文件与版本。
• 假二分：“context”或“memory”。context 是当下输入；memory 是跨时状态；memory 需要检索后才成为 context。

关键风险

长窗口可能增加旧指令、重复事实、prompt injection 与 stale state 的暴露面积；learned compaction 可能提升平均任务成功，却静默删除 rare constraint。因而同时测 task outcome 与 evidence retention。

一句话判断：窗口解决“装得下”，context engineering 解决“该装什么、凭什么信、何时失效”。

1.3 Reactive Loop vs Planning

张力本质

Reactive policy 依赖即时 observation，减少 stale plan；planning 通过显式 task graph 管理远期依赖、资源和风险。控制变量不是“任务看起来复杂”，而是任务的可观测性与依赖结构。

何时偏向哪一侧

真正控制变量

dependency depth、branching entropy、observation latency、effect reversibility、replanning cost、spec uncertainty、shared-resource contention、verification latency。

假二分与组合解

• 计划不等于长篇自然语言 TODO；高价值 plan 应表达 dependency、invariant、acceptance criteria 与 uncertainty。
• Reactive 不等于无目标乱试；它可以在稳定 policy 与 budget 下做局部闭环。
• 最稳健的是 receding-horizon control：保留粗粒度里程碑与不变量，每次 tool feedback 后只细化下一小段，并在关键状态变化时重规划。

一句话判断：plan 的价值来自避免昂贵的未来错误，不来自预写更多文字。

1.4 Single Agent vs Multi-agent

张力本质

Multi-agent 将 context、搜索与执行并行化，也引入通信、共享状态、冲突、错误相关性与验证负担。Agent 数量不是 scaling unit，可独立验证的 work package 才是。

真正控制变量

• task decomposability 与 critical-path ratio；
• 子任务间数据依赖和 shared mutable state；
• tool density 与工具竞争；
• context isolation 是否带来净收益；
• worker error correlation；
• merge/integration complexity；
• orchestrator/verifier 的判断能力；
• communication token、latency、cost 与失真。

当前量化反例

Towards a Science of Scaling Agent Systems 最新 v3 在 260 种配置、六类 agentic benchmark、五种 architecture 与三个 model family 上发现：并行可分任务可受益，严格顺序任务中的 multi-agent 下降 39–70%；工具数量增加时 coordination tax 上升；独立并行架构的错误放大最高达 17.2×，中心化架构为 4.4×。这是强烈的“任务条件化”证据，不是所有实际 coding workflow 的普适 scaling law；Google 早期博客中的 180/四类数字已经落后于论文修订版。

假二分与组合解

• 单 Agent 内部也可使用多个独立 context branch；多 Agent 也可共享一个中心状态机。
• 正确默认不是 swarm，而是：单 orchestrator 持有 intent、budget 与 integration authority；仅对低耦合、可独立验收的分支并行；worker 交付 artifact + evidence + uncertainty，而非自由文本结论。
• verifier 不应简单复制 generator；共享模型、prompt、context 会造成 correlated error。优先确定性 oracle、异构检查与独立证据路径。

一句话判断：多 Agent 购买的是并行与隔离，支付的是协调与验证；只有前者大于后者时才成立。

1.5 Generic Abstraction vs Model Specialization

张力本质

通用抽象降低 provider switching、测试和认知成本；模型特化利用 thinking、cache、tool grammar、media、effort、reasoning token 与 error semantics 等差异。

真正控制变量

• 被统一的是稳定语义还是偶然 API 形状；
• capability 是否可发现、可协商、可测试；
• abstraction leakage 的频率与修复成本；
• provider-specific 优势对任务 outcome 的真实增益；
• 迁移价值是否高于 lowest-common-denominator 损失。

假二分与组合解

• 错误做法一：让核心 runtime 到处判断 provider name；
• 错误做法二：把所有 provider 压成一个只支持文本和串行工具的最小接口；
• 可组合解：稳定的 domain objects（message、tool intent、effect、receipt、usage、trace）+ capability vector + provider adapter；无法无损映射的能力显式暴露，而不是 silent fallback。

失效判据

当模型升级需要修改 orchestration、state、UI、eval 多层时，抽象太浅；当 adapter 充满无法证明必要的特殊分支时，抽象边界错误或 capability contract 不足。

一句话判断：统一语义，不统一能力；特化留在边缘，不能污染核心状态机。

1.6 Autonomy vs Control

张力本质

Autonomy 不是“自动批准所有工具”，而是多个维度的控制向量：目标分解、信息获取、操作选择、effect 执行、资源使用、跨系统委托、完成判定。每个维度都应独立定级。

真正控制变量

可用一个工程风险近似式：

[ R_e = \text{impact} \times \text{scope} \times \text{irreversibility} \times \text{uncertainty} \times \text{authority gap} ]

抵消项包括 containment、deterministic verifier、rollback、observability、rate limit 与 human response time。

假二分与组合解

• 人工审批每一步不等于安全：审批疲劳会把 gate 变成仪式；用户也可能看不懂真实 effect。
• 无审批不等于失控：只读、sandbox、可回滚、强 verifier 的动作可高自治。
• 最佳组合是 risk-adaptive autonomy：按 effect class、资源、scope、历史可靠性和 verifier strength 动态给权；高风险动作使用 narrow capability token 和 just-in-time approval。

Anthropic 的真实使用研究 观察到 Claude Code 99.9 分位单 turn 无干预时长在三个月内从不足 25 分钟升至超过 45 分钟，但研究明确指出 duration 是不完美 proxy，也可能由用户经验、产品变化与任务选择共同造成。它证明行为趋势，不证明长期正确性或安全性。

一句话判断：自治权应由 effect 风险与可恢复性决定，而不是由产品里的一个全局开关决定。

1.7 Outcome vs Process

张力本质

Outcome 指 artifact 或世界状态是否满足任务；process 指采用了什么证据、工具、路径、权限和成本。两者各自都不是充分条件。

真正控制变量

• outcome oracle 是否完整、抗 gaming、接受多种合法实现；
• process constraint 是否真是安全/合规不变量，还是风格偏好；
• trajectory 是否完整且 faithful；
• 是否存在 hidden consequential effects；
• 成本、latency、权限与用户信任是否属于产品目标。

假二分与组合解

• 只看 outcome：可能通过 hardcode、删测试、绕过权限或利用 evaluator loophole；
• 只看 process：可能惩罚比参考路径更好的新解，也可能训练出“看起来认真”的 trace；
• 组合：确定性 outcome checks 为主，关键 process invariants 为硬门，trajectory metrics 用于诊断，成本/风险作为 Pareto 维度，而不是把所有指标揉成一个不透明总分。

三层完成判据

1. Functional：要求被实现，回归未破坏；
2. Procedural：未越权、未篡改 oracle、关键证据链完整；
3. Operational：变更可部署、可观测、可回滚、成本可接受。

一句话判断：outcome 决定有没有完成，process 决定是否以可接受方式完成；二者必须由不同类型的证据支撑。

1.8 Memory Utility vs Memory Integrity

张力本质

Memory 的价值来自未来复用，风险来自错误被持久化。其净值不是 retrieval hit rate，而是：

[ V_{mem}=P(\text{future reuse})\cdot U(\text{correct reuse})-P(\text{corrupt})\cdot L(\text{propagation})-C_{write/read} ]

真正控制变量

• write coverage：重要事实是否遗漏；
• preservation：更新是否破坏旧的仍有效信息；
• faithfulness：新增 claim 是否有支持；
• temporal validity、scope 与 ownership；
• provenance 与原始 evidence pointer；
• deletion、rollback、unlearning；
• evaluator bias 和跨 Agent 传播；
• retrieval utility 与总系统成本。

假二分与组合解

• 多记不等于记得好；少记也可能遗失关键约束。
• vector store 不是 memory system，只解决候选检索的一部分。
• 可组合解：typed memory（evidence / claim / cue / decision / preference）+ transition verifier + scope/TTL + immutable provenance + reversible consolidation。

TrustMem 把 coverage、preservation、faithfulness 作为 memory transition 检查并报告显著错误下降；Memory Contagion 显示即使 consolidation 完美，偏置输入也足以跨时间传播。两者共同说明：验证摘要质量仍不足以证明 memory 真值，输入 evaluator 与 provenance 同样属于责任边界。

一句话判断：memory write 是数据库 migration，不是聊天摘要；必须验证 transition，而不只评估 retrieval。

1.9 Interoperability vs Trust Composition

张力本质

协议标准化让 tools、agents、clients 更容易连接，却也让身份、authority、artifact、schema 与故障跨边界传播。Transport compatibility 与 trust compatibility 是两回事。

真正控制变量

• principal 与 delegated principal 能否区分；
• capability scope、audience、expiry 与 revocation；
• server/tool/schema 的供应链身份；
• input/output provenance、artifact digest 与签名；
• 重试、幂等、取消、partial failure 语义；
• 跨域 policy composition 是否 deny by default；
• trace context 能否跨边界关联且不泄露敏感内容。

假二分与组合解

• “支持 MCP/A2A”只说明某种 wire contract，不说明安全、可靠或语义一致。
• 互操作和零信任可组合：协议负责发现与传输；host policy 负责本地授权；执行层签发窄权限；receipt/provenance 负责追责；verifier 负责 artifact 验收。
• 协议能力协商不能代替 product policy，remote server 声明自己能做什么不代表 host 应允许它做。

2026 状态校准

A2A 1.0、ACP、MCP 与 OpenTelemetry GenAI 显示 tool / agent / client / observability 正在分层。MCP 2026-07-28 是 final stable release；同名 2026-07-28-RC 是更早的独立 pre-release，但 SDK 与生态采用仍有滞后。ACP 官方仓库把 wire protocol 1 标为稳定，protocol v2 仍通过 unstable_protocol_v2 feature 开发；schema/crate 发布号不等于 wire version。OpenTelemetry GenAI 已定义 agent/tool/evaluation 语义，但 agent spans 与多数相关字段仍为 Development。因此“协议分层趋势”和各自明确的 maturity 状态可信，“所有实现已经迁移且语义已经稳定可组合”并不成立。

一句话判断：协议解决能不能说话，identity、policy、provenance 与 verifier 决定说的话能不能产生 effect。

1.10 Generation Throughput vs Verification Capacity

张力本质

增加模型并发可近似线性扩大候选产出，却不会自动扩大正确 specification、oracle、review、integration 和 incident response。真正目标是：

[ T_{verified}=\min(T_{generation},T_{spec},T_{verification},T_{integration},T_{recovery}) ]

若生成到达率 (\lambda_g) 长期超过验证服务率 (\mu_v)，未验证队列、平均等待和 stale merge 风险会非线性增长。

真正控制变量

• change size 与耦合度；
• deterministic oracle coverage；
• verifier 独立性与 false positive/negative；
• review service time、并行度与排队策略；
• conflict/rebase rate；
• spec ambiguity 与 exception rate；
• incident cost、rollback latency；
• generated artifact 的保质期。

假二分与组合解

• “再加 reviewer agent”不是无限解：同源模型会相关性失败，review 输出本身仍需校准。
• “所有变更都人工 review”也不成立：低风险、强 oracle 的 change 应自动验收。
• 组合：缩小 change、增加 deterministic checks、risk-based routing、异构 verifier、artifact provenance、merge queue、限制 work in progress，把人留给 spec、architecture 与异常。

OpenAI 的 agent-first 工程报告 把人类注意力称为稀缺资源，并强调 repository legibility、feedback loops 与 architecture enforcement；这是一项真实团队经验而非跨组织受控生产率研究，不能把其中“约 1/10 时间”直接外推为行业效果。

一句话判断：不要优化生成了多少，而要优化单位时间内有多少 change 被可信验收并安全进入系统。

2. 十组张力的统一决策矩阵

2.1 一个更深的共同结构

十组张力其实都在回答同一个问题：系统应该在哪里保留自由度，在哪里建立确定性边界？

• Model、long context、reactive、multi-agent、specialization、autonomy、outcome、memory、interop、generation 都扩大自由度或能力面；
• Harness、context selection、planning、single control plane、stable contract、policy、process invariant、memory verifier、trust boundary、verification 都压缩不确定性。

顶级系统不是一味增加一边，而是把自由度放在可探索、可逆、可验证的区域，把确定性放在不可逆、高影响、跨边界的区域。

3. 统一 Failure Taxonomy：从“看到什么”到“哪里第一次坏掉”

3.1 五个必须分开的概念

一个 failure 可以有多个必要原因，但“所有东西都有责任”等于没有诊断。应输出主责任边界、促成边界和放大边界，并给置信度。

3.2 First bad decision 不是“日志里最早的异常”

判定一个事件 (e_t) 是 first bad decision，需要同时满足：

1. Temporal：它早于后续可见失败；
2. Informational：在当时可用信息集中，存在可合理选择的更优行动；
3. Normative：组件 contract 或系统不变量能说明为什么它错；
4. Causal：替换此决定的 counterfactual 能显著降低失败概率；
5. Actionable：修复位于一个明确 owner 的控制范围内；
6. Non-retrospective：不能使用当时尚不可知的未来信息责怪组件。

如果“正确选择”依赖当时不可见的信息，则 first bad decision 往往更早：可能是 context projector 没暴露证据、tool contract 没返回 receipt、observability 丢失关键状态，或 spec 根本未定义。

3.3 责任边界表

责任判断遵循一个简单原则：谁拥有稳定 contract，谁负责让违反 contract 的状态无法静默跨过边界。

3.4 统一诊断算法

Step 1：冻结 episode

保存精确 task/spec、model/harness/version、environment image、预算、工具定义、完整 trace、world-state diff、effect receipt、verifier 输出。缺这些时，先标记 observability gap，不能编故事。

Step 2：构建双时间线

• Epistemic timeline：每一时刻系统知道什么、来源是什么、置信度和 freshness 如何；
• Effect timeline：每次 proposal、authorization、execution、commit、receipt、verification 的真实顺序。

很多 failure 来自两条时间线分离：Agent 以为命令失败，但 effect 已提交；Agent 以为文件已更新，workspace 实际被另一 worker 覆盖。

Step 3：标注每个 step

对每个 step 记录：

state_before
observations_available
observation_provenance
decision_or_transition
expected_effect
actual_effect
contract_owner
recovery_opportunity
state_after

Step 4：从失败倒推最小因果链

删除与失败无关的事件，保留 outcome 发生所需的最小路径。区分：

• necessary cause：没有它，本次失败不会发生；
• sufficient cause：单独就足以产生失败；
• amplifier：只扩大概率或损失；
• detector failure：没有造成原错，但让它未被发现。

Step 5：寻找最早可防止点

从前到后检查：当时是否已有足够信息？该组件是否有 authority 做出正确处理？更改这一处是否不依赖未来信息？

Step 6：做 counterfactual replay

至少比较三种干预：

1. 修 first decision；
2. 不修 first decision，只加强下游 recovery/verifier；
3. 移除促成条件。

若只有同时改三处才恢复，说明是 conjunctive failure，应报告共同必要边界而非强行单因归因。

Step 7：输出责任分布而非伪精确结论

推荐格式：

Primary boundary: Runtime/effect reconciliation (0.75)
Contributing boundary: Tool receipt contract (0.60)
Amplifier: Retry policy without jitter/attempt cap (0.95)
Detection gap: No stable effect_id in trace (1.00)
Rejected hypothesis: Model hallucination — model never saw commit evidence

置信度代表证据支持，不代表责任百分比；不要让数字伪装客观性。

3.5 症状不是根因：映射矩阵

3.6 六类跨层传播模式

A. Projection failure

世界状态正确变化，但 observation projector 没把 receipt 投给模型；模型重复 effect。首责通常在 runtime/context 边界，不是“模型不听反馈”。

B. Authority laundering

不可信 tool output 经 summary、memory 或 subagent message 转换后看起来像系统指令，并最终获得执行权。数据 lineage 未丢，authority label 丢了。

C. Oracle-induced behavior

测试只检查表面结果，Agent 学会 hardcode 或删除失败路径。生成器“投机”是表象，首次稳定责任常在 verifier contract；若模型明确绕过规则，模型/policy 也有共同责任。

D. Recovery amplification

原始故障只是 transient timeout，错误 retry 产生重复付款、重复 PR 或重复部署。损失由 recovery 层放大，不能把全部损失归给外部服务。

E. Coordination aliasing

两个 worker 各自状态正确，但都认为自己拥有同一 artifact；merge 时后写覆盖先写。错误不是两个 worker 推理差，而是 ownership contract 不唯一。

F. Benchmark inversion

基础设施、budget 或 harness 变化被解释为模型能力变化；组织据此更换模型，生产反而下降。测量系统本身成为因果链中的 first bad decision。

3.7 诊断中的四个因果陷阱

1. Post-treatment bias：用失败后才产生的摘要解释失败前的决定；
2. Collider bias：只分析“被用户投诉”的失败，使难任务和差配置在样本中产生虚假相关；
3. Selection on success：只看成功 trace，误把成功伴随行为当成功原因；
4. Interference：并发 Agent 共享 cache、repo、rate limit，某 trial 的 treatment 改变另一个 trial，违反独立性。

4. 评估任何新论文、框架、模型或产品

4.1 先拆 claim，不先看名字

一项工作可能同时声称：

• capability：成功率更高；
• reliability：方差、灾难失败或恢复更好；
• efficiency：token、latency、compute、human time 更少；
• safety：攻击成功率、越权或数据泄露更低；
• portability：跨 model/task/environment 有效；
• operability：更可观测、可恢复、可治理；
• economics：单位 verified outcome 更便宜。

每个 claim 必须独立有证据。高 pass@1 不能证明安全；token 少不能证明 total cost 低；跨三个同类 benchmark 不能证明生产外部有效性。

4.2 证据等级 E0–E7

等级不是分数，而是适用范围。E3 的干净因果实验可能比 E6 的混乱日志更适合解释机制；E6 更适合决定是否上线。

4.2.1 还要加四个正交标签

• Independence：作者自评 / 第三方复现 / adversarial evaluator；
• Transparency：只有 headline / 有方法 / 有代码数据 / 有完整 trajectory 与 environment；
• Maturity：preprint / peer reviewed / spec RC / stable standard / deployed implementation；
• Risk relevance：toy effect / reversible production / consequential production。

4.3 外部有效性的十二个轴

外部有效性不是“能/不能泛化”二元判断，应给出 transport envelope：在哪些轴的什么范围内，证据仍成立。

4.4 Harness 与 benchmark 的二十四个坑

1. Broken task：规范矛盾、依赖不可装、gold patch 自身不通过；
2. Oracle undercoverage：继承测试只覆盖参考修复，替代正确实现被拒；
3. Oracle overacceptance：hardcode、删测试、绕过功能也能通过；
4. Contamination：公开 issue、patch、讨论进入预训练或检索；
5. Future leakage：workspace 含修复后的文件、commit 或 dependency；
6. Eval awareness：模型识别题库或 grader 逻辑；
7. Harness mismatch：某 Agent 需 adapter 才符合 patch/workspace contract；
8. Prompt mismatch：不同系统得到不同 task 信息、格式提示或 repo instructions；
9. Tool mismatch：搜索、edit、shell、browser 能力和返回格式不同；
10. Budget mismatch：token、turn、time、retry、并发未固定；
11. Compute mismatch：CPU/RAM/GPU、磁盘、网络和缓存不同；
12. Infrastructure noise：pod/OOM/服务抖动被算作模型失败；
13. Hidden fallback：实际路由到另一模型或较低 effort；
14. Trial cherry-pick：只报 best run 或未说明 pass@k；
15. Aggregation masking：平均分掩盖某语言、风险类或 horizon 的崩溃；
16. Judge coupling：generator 与 LLM judge 同源，共享偏好；
17. Judge instability：顺序、措辞或重复评分改变结论；
18. Trace incompleteness：只给 final patch，无法区分 reasoning 与 execution failure；
19. Cost omission：忽略 cache、tool compute、human review、infra 与失败恢复；
20. Non-independent trials：共享 repo、cache、memory 或 rate limit；
21. Survivorship：只报告能跑通 harness 的模型/任务；
22. Adaptive overfitting：反复看 test 结果演进 harness，test 变训练集；
23. Version ambiguity：模型、dataset、SDK、image 使用滚动别名；
24. Metric inversion：优化 proxy 破坏用户真实目标。

Anthropic 的基础设施实验 在 Terminal-Bench 2.0 上报告不同资源设置可造成最多 6pp 变化，并建议小于 3pp 的差距在配置未匹配时保持怀疑；OpenAI 对 SWE-Bench Pro 的审计 估计约 30% 任务存在问题。这些结果说明 benchmark quality 与 runtime configuration 不是附录信息，而是测量对象的一部分。

4.5 最低合格 Eval Card

claim:
  type: capability | reliability | efficiency | safety | portability
  target_population: "想外推到的任务/用户/环境"
configuration:
  model: "immutable version + effort + sampling"
  harness: "commit/version + prompt + context policy + tools"
  environment: "image + CPU/RAM + network + cache policy"
  budget: "tokens + wall time + turns + retries + concurrency"
tasks:
  dataset_revision: "immutable digest"
  n_tasks: 0
  source: "original / mined / production / synthetic"
  contamination_policy: "..."
  broken_task_audit: "..."
evaluation:
  trials_per_task: 0
  outcome_oracles: ["..."]
  process_guardrails: ["..."]
  grader_calibration: "human disagreement / false positive / false negative"
  trace_completeness: "..."
statistics:
  unit_of_analysis: "task / trial / session / user"
  confidence_intervals: "..."
  variance_decomposition: "model / harness / task / infra / judge"
  paired_design: true
economics:
  model_cost: "..."
  tool_and_infra_cost: "..."
  human_review_time: "..."
  cost_per_verified_success: "..."
limitations:
  known_failures: ["..."]
  transport_envelope: "..."
artifacts:
  code: "..."
  trajectories: "..."
  task_and_oracle_hashes: "..."

4.6 统计与报告最低要求

• 使用 task-level paired comparison，避免任务难度差被误当 treatment effect；
• 对 stochastic agent 跑多 trial，报告分布而非只报均值；
• 区分 pass@k（给 k 次机会至少一次成功）与单次部署成功率；
• 报 confidence interval、effect size 和实际 n，不只报 p-value；
• 对多 benchmark / 多 variant 做 multiple-comparison 校正或预注册主指标；
• 报 variance decomposition：task、model、harness、infra、judge 各贡献多少；
• 成本至少报 total cost / verified success，不能只报单次 token；
• 对安全评测同时报 attack success 与 benign utility，防止“拒绝一切”获得安全高分；
• 对 memory 报跨时间污染和恢复，不只报即时 retrieval；
• 对多 Agent 报 critical-path latency、communication cost、merge conflict 和 error correlation。

4.7 判断新技术的十五问

1. 它解决哪个层、哪个时间尺度、哪种已观察失败？
2. claim 是 capability、reliability、cost、安全还是可运维性？
3. 核心状态对象和唯一 owner 是谁？
4. 它改变 model、context、harness、environment、verifier 中哪几个变量？
5. 新增什么 action/effect，也新增什么 authority 与 attack surface？
6. 成功路径外，取消、timeout、partial failure、resume 如何定义？
7. 信息如何进入 context，如何标 freshness、scope 与 provenance？
8. baseline 是否强、等预算、同 harness、同环境？
9. 是否有 component ablation 和 interaction test？
10. task、oracle、judge 是否审计过 brokenness 与 contamination？
11. 方差、trial、confidence interval 和失败分布是否公开？
12. 跨模型、任务、预算、语言或组织迁移到哪里为止？
13. 它删掉了什么复杂度，还是只增加新的 orchestrator/prompt/state？
14. 模型能力提升一代后，这个机制仍是稳定边界还是临时补丁？
15. 最便宜的 falsification experiment 是什么？作者做了吗？

4.8 采用决策：不是“看起来先进”

5. 2026 前沿雷达：事实、方向与反证

本节的状态是截至 2026-08-03 的工程判断，不是永久预测。

5.1 Established：已足以改变默认判断

E1. Agent 能力必须按系统配置报告

结论：只报裸模型分数已不充分。Harness-Bench 与 Claw-SWE-Bench 的受控数据、OpenAI/Anthropic 的生产工程报告共同支持 model–harness–environment 交互。

边界：这不代表 harness effect 永远等于 model effect，也不代表某个通用 harness 最优。

E2. Agentic eval 的环境和 oracle 是一等变量

结论：资源配置、adapter、task brokenness、contamination、grader 都能改变榜单结论。DeepSWE 用 113 个原创长任务和手写 verifier，报告独立 judge 对其 verifier 的分歧为 1.4%，对 SWE-Bench Pro inherited tests 为 32.4%；它为“原创任务 + requirement-oriented oracle”提供了积极证据。

边界：113 个任务、91 个 repo 与作者构建的 verifier 仍不足以代表全部软件工程；LLM judge disagreement 也不是绝对真值。

E3. 长任务需要 durable state，而不只是更长对话

结论：Anthropic Managed Agents 将 append-only session、harness 与 sandbox 分离；长任务工程实践反复使用 checkpoint、artifact、compaction 和跨 session handoff。状态生命周期与 context policy 应解耦。

边界：具体 persistence topology 尚未标准化；“能持续更久”不等于“能持续正确”。

E4. Outcome-only eval 不足，trajectory 与 effect evidence 必须存在

结论：Agent 会修改环境且错误可传播，final answer 无法定位 execution alignment、越权、silent fallback 与 recovery failure。完整 episode package 已成为可靠诊断前提。

边界：trajectory 可被伪装或不忠实；trace 是证据面，不是自动正确性证明。

E5. 安全边界正在从 prompt prose 移向 capability 与 data-flow enforcement

结论：AgentSecBench 区分“prompt 描述边界”与 provenance projection、capability restriction、output validation 等 channel closure；NIST 也把 agent identity、authorization、audit、non-repudiation 提为独立议题。

边界：现有 benchmark 仍受模型规模、攻击面与语义覆盖限制；没有任何单项防御证明通用 prompt-injection 安全。

5.2 Emerging：方向可信，解法未收敛

M1. Learned Context Management

支持：CompactionRL 联合优化任务执行与 compaction，在两个 agentic coding benchmark、两个基础模型上报告提升；说明 compaction 可进入训练目标，而不必永远是外部 heuristic。

反证/限制：其中一个主 benchmark 是已被指出 contamination/测试问题的 SWE-Bench Verified；尚缺跨 harness、真实长任务、rare-constraint retention 和长期 corruption 数据。

当前判断：Emerging，不应直接替代可审计的 deterministic compaction guardrail。

M2. Training–Runtime Convergence

支持：ToolVerse 从近 400 个 MCP、约 4,500 个工具构造可执行训练环境；agentic RL 越来越直接训练 tool use、long horizon 与 runtime behavior。

反证/限制：由真实 MCP schema 生成不等于真实动态生产环境；工具依赖图任务可能携带生成器偏差，跨供应商、失败语义与安全边界仍需验证。

当前判断：训练基础设施、trajectory 与 verifier 会成为和 weights 同样关键的资产。

M3. Provenance Plane

支持：ARGUS 用 influence provenance graph 审计 context-aware injection，并在其 AgentLure 设置中报告攻击成功率 3.8%、正常任务 utility 87.5%；typed memory、effect receipt、trace propagation 也在解决相邻问题。

反证/限制：单一 benchmark 的 span-level trust 规则可能对自适应真实攻击过拟合；公开实现、跨产品复现与高吞吐成本仍不充分。

当前判断：provenance 作为统一数据面可信，具体 trust scoring 算法未建立行业共识。

M4. Task-adaptive Multi-agent Topology

支持：Google 的研究表明 decomposability、sequential dependency 与 tool count 能预测架构收益，预测器对未见配置选对架构达 87%。

反证/限制：最新 v3 虽扩展到六类 benchmark、五种 architecture 与三个 model family，仍只覆盖有限任务与系统族；任务特征本身在运行前可能不可知，在线切换也有状态迁移成本。

当前判断：从“固定 swarm”走向“按任务结构选择 topology”是合理方向，尚非可靠自动控制器。

M5. Dynamic Autonomy / Earned Trust

支持：Hedwig 探索基于跨 session 交互调整 autonomy；Human Oversight in Practice 从 17 位有经验开发者中归纳 a priori control、co-planning、real-time monitoring、post hoc review 四类工作。

反证/限制：样本小、使用者选择偏差强；“少打断”可能来自疲劳而非信任，“历史可靠”也不能无条件转移到新 effect domain。

当前判断：动态自治应基于 effect class 与校准数据，不能只学习用户点击习惯。

M6. Protocol Stack Stratification

支持：MCP 聚焦 model–tool/context，A2A 聚焦 agent–agent，ACP 聚焦 editor–agent，OpenTelemetry GenAI 增加 invoke_agent、execute_tool、evaluation event 等语义。

反证/限制：版本和采用速度不同；OTel GenAI agent spans 与多数相关字段仍为 Development；ACP wire protocol v1 稳定、v2 仍 under development，且 schema/crate artifact 版本不能冒充 wire version；MCP 2026-07-28 虽已 final stable，但 SDK 与现存服务不会同时完成采用。协议存在不等于身份、语义与错误可组合。

当前判断：分层趋势 Established，具体规范统一与 cross-vendor trust 仍 Emerging。

M7. Verification-aware Work Design

支持：agent-first 团队越来越把 repository legibility、deterministic checks、small work packages、agent review 与 merge control 当生成系统的一部分。

反证/限制：多为单组织经验，存在 greenfield、团队能力和内部工具选择偏差；长期 architecture entropy 与 maintenance cost 尚未知。

当前判断：verification capacity 是可信的系统瓶颈假设，但尚缺跨组织量化 scaling law。

5.3 Speculative：值得跟踪，不能作为默认前提

S1. Self-evolving Harness

Agentic Harness Engineering 报告 10 轮迭代将 Terminal-Bench 2 pass@1 从 69.7% 提升至 77.0%，且 frozen harness 在其他模型上有迁移，收益主要来自 tools、middleware、long-term memory 而非 system prompt。

为何仍是 Speculative：演进 loop 反复接触 benchmark feedback，存在 adaptive overfitting；迁移仍集中在少数 coding benches；缺长期 production entropy、安全审计与独立复现。正确的最低门槛是冻结 held-out set、prediction-before-edit、预算一致、跨模型/任务迁移、可逆 edit 与独立审计。

S2. Fully Learned Memory Policy

端到端学习何时写、改、删、检索很有吸引力，但一处 evaluator bias 可跨时间传播。除 utility 外，必须证明 transition faithfulness、scope isolation、unlearning、model-upgrade compatibility 与 adversarial robustness。

S3. Large Decentralized Agent Swarms

协议让大规模通信可行，不代表 shared-state、identity、error correlation、cascading failure 与 economics 已解决。当前证据更支持中心化或混合 topology 在有清晰 work package 时工作。

S4. Autonomous Verification

Reviewer agent 可扩展一部分语义 review，却可能与 generator 共享盲点。没有独立 oracle、metamorphic test、adversarial counterexample 和风险路由时，不能把“另一个 Agent 说 OK”当验收。

S5. Universal Delegated Agent Identity Fabric

NIST 已把 identity/authority 提为标准化问题，但跨组织 principal delegation、least privilege、revocation、non-repudiation 与 privacy 仍处早期。现阶段应使用窄 capability、明确 audience/expiry 与本地 policy，不等待“通用身份层”自动解决。

S6. A Universal Agent Scaling Law

目前不存在类似简单 compute scaling 的单一“Agent 数/turn 数 → capability”规律。task topology、tool density、environment stochasticity、verification 和模型能力的交互太强。局部预测器值得使用，普适定律仍是研究问题。

5.4 反证清单：看到这些，必须给热点降级

5.5 未来十二个月最值得追踪的十二个可证伪问题

1. learned compaction 在原创长任务和跨 harness 上是否仍提升，并保留 rare constraints？
2. self-evolving harness 在真正冻结的 unseen task、unseen model 上是否仍有正迁移？
3. provenance graph 能否在低 latency、隐私约束和 adaptive attack 下维持效用？
4. memory transition verifier 自身的 bias 如何审计、升级和回滚？
5. task topology 能否在执行前可靠估计，还是必须在线探索？
6. OTel GenAI semantics 能否形成跨产品可比而不泄露 prompt/tool 敏感数据？
7. MCP 新的 stateless/sessionless 方向最终是否稳定，迁移如何影响 host lifecycle 与 recovery？
8. A2A delegation 如何表达 end-user、agent、service 三类 principal 与 authority chain？
9. 原创 benchmark 如何持续扩充又不因公开而迅速污染？
10. reviewer diversity 怎样测量，异构模型是否真能降低 correlated error？
11. verification queue 在大规模并行 coding Agent 中是否成为首要组织瓶颈？
12. 用户“更少干预”到底来自 earned trust、automation bias 还是 oversight fatigue？

6. 六个综合案例：把张力、因果与证据连起来

这些是分析样本，不是项目作业。

6.1 换了更强模型，线上 Coding Agent 反而下降

表象：离线代码能力分更高，线上 task completion 下滑、tool error 增多。

错误结论：“新模型不适合 Agent。”

因果链候选：新模型 tool-call grammar/parallel behavior 改变 → generic adapter 丢失 provider error 或顺序语义 → executor 收到重复/缺参数调用 → recovery 误重试 → 任务失败。

First bad decision：adapter 将无法无损映射的能力 silent downgrade，而不是 fail fast 或 capability negotiate。

责任：Primary = model adapter；Contributing = eval 未覆盖 provider transition；Amplifier = retry。

最小证伪实验：固定 task/environment/budget，做旧/新模型 × 旧/原生 adapter 的 2×2 paired eval，记录 tool validity、execution-alignment 与 final outcome。若新模型仅在旧 adapter 下降，不能归因模型本身。

6.2 长窗口 Agent 忘了一个早期安全约束

表象：约束明明出现在完整历史，模型仍越 scope 编辑。

错误结论：“context window 还不够长。”

可能链路：约束位置过早 + 大量重复 tool output 稀释 → compaction 把它总结成弱偏好 → 新 memory 未保留 authority tag → plan 将其覆盖。

First bad decision：compaction transition 删除了必须持久存在的 invariant，或 projector 未把 invariant pin 到高 authority 区。

责任：Primary = context/memory transition；Model 只有在看到明确 invariant 仍违反时才成为主责。

正确验证：constraint recall、authority preservation、summary faithfulness、最终 effect 四级分别测；只看 task pass rate 会掩盖潜在越权。

6.3 五个并行 Agent 提交更快，但合并更慢

表象：候选 patch 数量翻倍，merge queue、冲突和 review time 激增。

因果链：分解按文件而非 dependency/ownership → 多 worker 共享接口与测试 → base revision 漂移 → 重复变更与冲突 → reviewer 必须重建各自 context → verified throughput 下降。

First bad decision：orchestrator 创建了不可独立验收且 ownership 重叠的 work package。

责任：Primary = coordination/control plane；Amplifier = generation concurrency 无 WIP limit；Detection gap = 未测 merge/review latency。

正确指标：不是 patches/hour，而是 verified merged changes/hour、conflict rate、review service time、rework、incident rate。

6.4 MCP 工具“接通了”，却产生跨租户数据泄露

表象：协议调用完全合法，返回了另一个 tenant 的记录。

错误结论：“MCP 不安全”或“模型被注入”。

因果链：host 以 service credential 连接 server → end-user identity 未被带入/约束 → tool schema 允许 tenant_id 参数 → 模型从不可信文档复制另一个 ID → server 按 service 权限返回。

First bad decision：delegated authority contract 没有把 user principal 与 service principal 分开，并允许模型选择 security scope。

责任：Primary = identity/authorization boundary；Contributing = tool schema；Amplifier = untrusted context；协议 transport 本身未必违反规范。

组合解：tenant scope 从 trusted runtime 注入，不进入模型可控参数；server 再授权；trace 记录 principal chain；output 做 scope validation。

6.5 Leaderboard 提升 2.4pp，切换后生产无收益

表象：公开榜单赢，内部真实任务持平甚至变慢。

因果链：公开评测使用更大 VM、更长 timeout、不同 harness；2.4pp 处于 infra + sampling 不确定性内；生产任务 horizon、repo、network policy 不同；成本未计 review。

First bad decision：采购/架构决策把不具 transport validity 的 point estimate 当因果证据。

责任：Primary = evaluation/decision process；不是模型团队。

正确处理：构建本地 paired eval，固定 harness/environment/budget；报告置信区间、failure slice、cost per verified success；先 shadow 后 canary。

6.6 Tool timeout 后 Agent 重复创建了两次外部资源

表象：模型重复调用创建 API。

错误结论：“模型陷入循环。”

因果链：第一次请求已 commit，但 response 丢失 → executor 返回 generic timeout → runtime 把 unknown 当 failed → retry 未携 idempotency key → 第二次创建成功。

First bad decision：effect contract 把 unknown outcome 折叠成 not executed。

责任：Primary = tool/runtime effect reconciliation；Contributing = API 无幂等键；Model 依据错误 observation 重试是合理行为。

正确状态机：proposed → authorized → dispatched → committed?unknown → reconciled；unknown 状态先 query by idempotency key，不能直接 replay。

7. 综合面试追问与专家回答骨架

以下不是背诵答案。每个回答都应走：定义边界 → 控制变量 → 反例/假二分 → 可组合设计 → 证据与验证。

7.1 跨层张力

1. “模型和 harness 到底谁更重要？”
   拒绝全局排序；给出 configuration unit、局部主效应与 interaction；研究用 factorial ablation，选型看完整 Pareto。

2. “模型更强后，哪些 harness 该删除？”
   区分稳定系统边界与补偿性 scaffolding；tools/effects/state/permissions/verifier 稳定，过度 planning、重复 self-critique、模型弱点 workaround 要用 ablation 定期退休。

3. “一百万 token 后还需要检索吗？”
   容量不解决 freshness、authority、ordering、cost、污染；说明长窗口与 evidence acquisition 互补。

4. “什么时候应该先计划再执行？”
   依据 dependency depth、反馈延迟、不可逆性、分支熵，不依据任务描述长度；提出 receding-horizon。

5. “多 Agent 的 scaling unit 是什么？”
   是可独立验收的 work package，不是 agent count；说明 context isolation、parallel fraction、shared state、coordination tax。

6. “为什么中心化 orchestrator 可能更可靠？”
   单一 intent/budget/integration owner 可抑制错误传播；引用 task-dependent 证据，同时说明单点瓶颈与 context overload。

7. “通用 model adapter 应做到多厚？”
   稳定 domain semantics 深，provider-specific mapping 薄；capability negotiation，禁止 silent lowest-common-denominator。

8. “如何定义 Agent autonomy？”
   给出多维向量而非开关；按 effect risk、containment、verifier、rollback 定级。

9. “为什么每步审批仍可能不安全？”
   approval fatigue、语义不可理解、TOCTOU、授权 scope 扩张；审批必须绑定精确 effect 与 principal。

10. “outcome 已通过测试，为什么还看 trajectory？”
    oracle 可能过窄或被 gaming；trajectory 用于权限、隐藏 effect、成本与归因，但不能替代 outcome。

11. “memory 系统最重要的指标是什么？”
    拒绝单一 hit rate；utility 加 transition coverage/preservation/faithfulness、freshness、scope、propagation loss。

12. “支持 MCP/A2A 是否足以实现可信互操作？”
    transport 与 trust 分离；需要 delegated identity、local policy、capability、provenance、verifier 和 failure semantics。

13. “如何知道 verification 已成为瓶颈？”
    观察生成到达率、review queue、service time、conflict/rework、incident 与 verified throughput，而非 Agent 利用率。

7.2 Failure 与因果诊断

14. “什么是 first bad decision？”
    不是最早 error log；必须满足当时有足够信息、违反 contract、counterfactual 可防止、owner 可行动。

15. “模型 hallucination 如何归因？”
    先审 evidence acquisition、tool raw result、projection、memory freshness；只有 context 充分仍误判才归模型。

16. “timeout 后是否应该 retry？”
    先按 effect 语义区分 no-commit、committed、unknown；unknown 需 idempotency/reconciliation，不能盲重试。

17. “如何区分 root cause 与 recovery failure？”
    原因触发异常，recovery 决定是否扩大损失；分别报告 initiating、amplifying、detecting boundaries。

18. “两个 subagent 覆盖彼此修改，谁负责？”
    若 assignment ownership 重叠，主责 orchestrator/coordination；若唯一 owner 明确而 worker 越界，再归 worker/policy。

19. “日志不完整时还能做根因分析吗？”
    只能给 hypothesis distribution；明确 observability gap 是已确认缺陷，并定义需补的 stable IDs、state transition、effect receipts。

20. “counterfactual replay 怎么避免事后聪明？”
    只允许使用该 step 当时可见信息；冻结 environment/budget；替换单一 decision；多 trial 验证概率变化。

21. “如何诊断 context drift？”
    比较 source-of-truth constraint、每次 compaction、handoff 与 plan 的语义 diff；追 authority/provenance 是否丢失。

22. “verifier gaming 的主责一定在模型吗？”
    不一定。若 oracle 允许投机，验证边界首先失责；模型是否明确违反 policy 决定共同责任。

23. “同配置高方差是模型随机性吗？”
    需分解 task、sampling、infra、race、judge、外部服务；重复 trial 和资源 trace 后才能归因。

7.3 新技术与证据判断

24. “如何在十分钟内判断一篇 Agent 论文值不值得读？”
    先写出 claim、treatment、baseline、unit、oracle、budget、artifact；检查有没有公平对照、ablation、完整 trace 和可证伪限制。

25. “为什么单 benchmark 提升不能证明框架更好？”
    可能是 harness fit、budget、contamination、oracle 与 adaptive overfit；要求跨模型/任务与独立复现。

26. “生产 case study 的证据比论文强吗？”
    对可行性和目标产品外部有效性强，对因果归因常弱；使用证据等级与 independence/transparency 双轴回答。

27. “如何公平比较两个 coding agent？”
    固定或分别报告 model、harness、environment、budget、prompt、tool、grader；做 paired tasks、多 trial、cost/verified success。

28. “2pp 榜单领先是否值得切模型？”
    看 CI、trial、infra variance 和业务 slice；2026 基础设施研究说明小差距可能小于配置噪声；先本地 shadow。

29. “如何审计 broken benchmark？”
    reference solution 可运行；规范与 tests 对齐；替代正确解人工审查；失败 trace 聚类；独立工程师与 agent-assisted flag 双层。

30. “LLM judge 能否替代测试？”
    适合语义/开放质量，需人工校准、重复评分和偏差审计；确定性 requirement 优先 code-based oracle；两者组合。

31. “如何证明一个安全防御不是只会拒绝？”
    同时报 attack success、benign utility、channel closure、adaptive attack 与 operational overhead。

32. “如何判断 self-evolving harness 是否 benchmaxxing？”
    冻结 unseen test、prediction-before-edit、限制 feedback、跨模型/任务迁移、budget parity、revert log、独立复现。

33. “CompactionRL 这类结果应如何解读？”
    支持 learned compaction 的局部可行性；不能自动外推到真实 memory integrity，尤其 benchmark contamination 与 rare constraint 仍未充分验证。

34. “协议最新 revision 要不要立刻跟？”
    查 maturity、RC/final、SDK adoption、version negotiation、迁移与 failure semantics；用 adapter 隔离，不把 draft 语义渗入核心。

35. “什么技术即使模型再强也不会消失？”
    真实 effect contract、identity/authority、durable state、observability、recovery、verification 属于系统确定性边界；补偿推理弱点的 prompt scaffolding 可能消失。

36. “你如何定义 Agent 领域真正的技术判断力？”
    能把热点还原为对象、状态、控制变量和证据；能说清成立条件与反证；能定位 first bad decision；能设计最低成本的 falsification。

8. 面试现场的统一回答算法

遇到任何跨层问题，用下面七步，通常比堆名词更有技术密度：

1. 先定义对象和边界：这个词指 model、harness、runtime、protocol 还是 product？
2. 给出任务条件：在什么 horizon、effect、dependency、budget 下讨论？
3. 指出真正控制变量：列 3–5 个能改变结论的量；
4. 拆掉假二分：说明两端各自解决什么、为什么不能互相替代；
5. 给组合架构：自由度放哪里，确定性边界放哪里；
6. 讲 failure 与 observability：失败如何传播，first bad decision 怎么定位；
7. 给证据级别和未决问题：哪些 established，哪些只是一篇论文，下一步如何证伪。

一个合格的高级回答，不是“我倾向 A”，而是：

当 X、Y、Z 条件成立时，A 的净收益高于 B；核心控制量是 C。A/B 不是全局二选一，我会用 D 组合，并通过 E、F 指标与 G ablation 验证。当前公开证据支持到 H，尚不能外推到 I。

9. 一手资料与证据卡

Harness / Runtime

• Harness-Bench：106 个 sandboxed tasks、5,194 trajectories；支持 model–harness configuration 与 execution alignment 诊断。限制：单一新 benchmark，尚待独立复现。
• Claw-SWE-Bench：350 tasks、8 languages、43 repos；同模型 minimal/full adapter 19.1%/73.4%。限制：面向 OpenClaw-style adapter 与 SWE-style contract。
• Agentic Harness Engineering：自动演进 tools/middleware/memory 的正结果。限制：adaptive benchmark feedback 与少数 coding domains。
• AI Harness Engineering：提出 harness 十一项责任与 episode package。限制：框架/小规模 validation 的性质强于大规模效果证据。
• OpenAI Harness Engineering：真实 agent-first 团队工程经验。限制：单组织、greenfield、非受控对照。
• Anthropic Managed Agents：session / harness / sandbox 分离的生产架构。
• Anthropic Long-running Apps Harness：多小时 planning/generator/evaluator 与 structured artifacts。限制：特定任务与内部 harness。

Eval / Benchmark Validity

• OpenAI Coding Evaluation Audit：SWE-Bench Pro 约 30% broken 的审计估计。
• OpenAI Trustworthy Third-party Evaluations：frontier model 已是工具化工作流，环境与 setup 属于评测。
• Anthropic Infrastructure Noise：Terminal-Bench 2 资源配置最多造成 6pp 差异。
• Anthropic Demystifying Evals：task/trial/grader/trajectory、capability/regression eval 与多层 grader。
• DeepSWE：113 个原创长任务、手写 requirement verifier、完整 trajectory。

Context / Memory / Training

• CompactionRL：在 agentic RL 中联合训练 compaction 与任务执行。
• TrustMem：memory transition coverage、preservation、faithfulness。
• Memory Contagion：evaluator bias 可通过 memory 跨时间传播。
• ToolVerse：近 400 MCP、约 4,500 tools 的 agentic RL environment 构造。

Multi-agent / Human Control

• Science of Scaling Agent Systems v3：260 configurations、六类 agentic benchmark、五种 architecture、三个 model family；task-dependent scaling、sequential penalty、error amplification。早期 Google 博客的 180/四类数字已被论文修订版扩展。
• Anthropic Measuring Agent Autonomy：真实使用中的 autonomy proxy 与局限。
• Human Oversight of Agentic Systems in Practice：17 位开发者、四类 oversight work；探索性证据。
• Hedwig：dynamic autonomy 的早期系统与用户研究。

Security / Identity / Protocol

• AgentSecBench：instruction integrity、retrieval confidentiality、capability integrity 与 channel closure。
• ARGUS / AgentLure：context-aware injection 与 influence provenance graph。
• NIST AI Agent Standards Initiative：interoperability、security、identity 标准化议程。
• NIST Agent Identity and Authority Concept：identification、authorization、audit、non-repudiation。
• MCP 2026-07-28 final release：该 revision 已 final stable；不要把更早的 2026-07-28-RC 状态套到 final tag，也不要把 final spec 外推成生态同步迁移。
• A2A Specification：agent-to-agent task/message/artifact contract。
• ACP：editor–coding agent protocol；wire protocol v1 当前稳定，v2 仍通过 unstable_protocol_v2 feature 开发，schema/crate artifact 版本需与 wire version 分开。
• OpenTelemetry GenAI Semantic Conventions：inference、agent、tool、evaluation 的可观测语义；需逐项检查稳定级别与敏感数据策略。

10. 最终自检：是否真的掌握了 Part 15–18

如果能在没有资料时完成以下动作，才算“讲透”而不是“看过”：

• 对十组张力中的任意一组，给出成立条件、控制变量、反例和组合解；
• 面对一个可见 failure，明确区分 symptom、mechanism、first bad decision、enabling condition、detection gap；
• 能画出 epistemic timeline 与 effect timeline，并指出它们在哪里分离；
• 不用“模型幻觉”概括 context、tool、runtime、memory 和 verifier 的失败；
• 看到 benchmark 分数，主动询问 model/harness/environment/budget/oracle/trials；
• 能给新技术标 evidence level、transport envelope、counterevidence 和 falsification experiment；
• 能指出 2026 年哪些方向已足以改变工程默认，哪些仍只适合 shadow 或研究；
• 能解释为什么协议互通不等于 authority 可组合；
• 能解释为什么更多 Agent 可能降低 verified throughput；
• 能在模型继续增强时，区分应被删除的 scaffolding 与必须保留的系统边界。

最后保留一句判断：

AI Agent 领域最稀缺的不是知道更多框架名，而是能在跨层交互、带噪证据和快速变化中，持续找到真正控制结果的边界。