推理独立性和起源独立性
当 AI 代理能够编写测试、触发运行并判断结果时，一份通过报告很容易让团队产生错觉：测试已经由另一个智能体复核过，结论就足够可靠了。但真正需要追问的不是代理是否足够聪明，而是它据以判断的证据从哪里来。
为避免人工智能自行批改作业，常见做法是引入第二个模型、独立评估者或没有共享历史记录的审查代理。这种设计确实有价值。新的推理者能够发现前一个代理的意图偏差、逻辑错误和自洽结论，这就是推理独立性。
但它解决不了另一类问题：两个代理即使彼此独立，只要依据的是同一份不完整证据，仍会继承同一个盲点。决定性证据尚未生成时，第二个代理不会因为推理更强而凭空发现缺陷。问题不在推理本身，而在证据从未出现。
这正是证据来源独立性与推理独立性的差别。本文并不否定多代理审查，而是讨论它的边界：哪些故障必须由真实设备、真实主机和真实运行产生证据，才能被可靠地判定。
下文的五类案例说明，模型可以读取设备返回的日志、视频和状态，却无法生成这些运行事实。质量护栏的关键因此不只是增加一个更强的审查代理，而是让最终判定建立在模型无法自行制造或控制的证据之上。
什么是脱离上下文的故障
脱离上下文的故障，是指只有应用程序运行在真实硬件上时才能发现的缺陷。无论模型的上下文窗口多宽、能力多强，都无法凭空提供这类证据。
这个名称本身就说明了它为何不能被更好的模型取代。关键在于证据的来源，而非推理是否严密：运行尚未产生结果时，上下文窗口中没有可读取的信息；更大的窗口只会带来更多同样缺失的信息。
这些案例如何产生
以下所有失败都源于同一个循环。一个人工智能编码代理通过 Kobiton 的 MCP 服务器向真实设备发送测试运行请求，并将会话视频、设备日志和模型未写入的捕获状态返回给模型。代理可以请求运行并读取结果，但无法生成证据，因为证据由硬件对构建的响应产生。
这一区分是全文论证的核心：代理发送请求，硬件生成证据，最终结论取决于实际运行的返回结果。每个发现都可以追溯其产生过程。
这里有一种颇具讽刺意味的关系。代理通过模型上下文协议（Model Context Protocol，MCP）访问设备；这一协议本就是为了扩展模型的访问范围。它揭示的故障，恰恰是模型自身无法产生的。扩展访问范围的工具，也暴露了访问范围的边界。
只有真实运行才能产生的证据
以下列出五类脱离上下文的故障。每一类都代表模型无法仅凭现有上下文解释的缺陷，并包含我亲身经历过的案例。另有一类相关问题不属于这个分类体系，将在五类案例之后单独讨论。
| 类别 | 模型可以读取什么 | 只有真实运行才能产生什么 |
|---|---|---|
| 缓存工件状态 | 它构建并服务的代码、密钥和制品 | 设备当前实际运行的是哪个版本 |
| 安装来源 | 逐字节相同的二进制文件 | 操作系统认为该二进制文件是如何安装的 |
| 传感器和主机依赖性 | 已验证正确的构建 | 运行该程序的特定机器状态 |
| 宿主状态随时间漂移 | 先前的合格结果 | 此后该机器发生了哪些变化 |
| 争议输入区域 | 应用程序绘制的布局 | 操作系统保留了哪些区域，以及谁赢得了触摸权 |
缓存工件状态
该原型构建报告自身配置错误，但代理可以读取的所有工件都显示正常。代码正确，密钥已加载，提供的包已正确内联并验证了值。模型检查了自身工作并通过验证。设备却静默运行着几天前缓存的旧包，代码、密钥和提供的工件都没有记录手机上实际驻留的是哪个包。
强制停止并重新启动后，设备会拉取当前包，缺陷随即消失，无需改动代码。驻留构建状态存在于设备上，也在设备上过期；如果没有运行产生这一事实，就没有内容会将它传递出来。
安装来源
假设两个安装环境中的二进制文件完全相同，但其中一个环境的应用内购买功能正常，另一个却无法使用。二进制位完全相同，因此文件本身无法解释差异。真正的区别是操作系统如何判断应用的安装方式，而这会影响操作系统如何验证应用商店签名。逐字节比较二进制文件，无法得到文件本身不包含的安装路径信息。
这不是假设，而是客户实际遇到的问题：一家度假产权公司提交支持案例，指出设备报告的已安装版本与实际发布版本不符。这种差异出现在生产环境，而不是我的实验室环境。关于如何在真实硬件上运行这些检查，可参阅现场日志文档；这里要强调的是，安装来源是设备的属性，不是文件的属性。
传感器和主机依赖性
同一个 APK 先经反汇编，并在字节码层面验证无误，因此代码本身并非问题所在。它在一台 Kobiton 设备主机上运行成功，却在另一台同型号主机上抛出连接错误。差异来自特定机器的状态，而非构建过程中包含的任何内容。
没有任何工件记录运行主机的状态，因此无论如何重新读取构建过程，都无法发现问题。只有在故障主机上运行一次才能发现它；在成功主机上运行一次，才能证明构建过程本身没有问题。
宿主状态随时间漂移
一台主机此前顺利通过相同构建的测试，随后在应用没有任何更改的情况下失败。后台端口迁移，导致两个服务争用同一端口。二进制文件没有变化，先前的通过结果也无法预测之后的失败，因为变量是机器在稍后时刻的状态。这正是我们已经验证过一次了这种说法的缺陷：测试结果取决于运行时观察到的主机状态，而主机状态并非固定不变。
这两台主机都属于 Kobiton，也是我的工作场所。故障已被发现、记录并修复。保留这份记录，是因为论证需要它：缺陷确实存在，在构建过程中无法察觉，只有在实际机器上运行才能发现。
争议输入区域
该应用将下一步和计算按钮绘制在系统手势导航栏上方。屏幕上，按钮清晰可见且位于最上方；主页图标和返回箭头则绘制在其内部。点击按钮所在位置会被识别为系统主页按钮，因为操作系统保留该区域。无论应用在其上绘制什么，系统都优先响应触摸操作。控件存在、可见且位于最上方，却仍然无法点击。
在运行 Android 16 的较新设备上，还出现过一个变体：系统报告应用预期的内嵌区域为零。
需要保持客观。审查布局代码的模型很可能会指出底部内嵌区域缺失；这并不是任何模型都无法察觉的缺陷。模型无法独立呈现的是问题的表现和诊断结果：在这个操作系统版本和设备上，该区域被系统保留，触摸操作会被识别为主屏幕手势。
我此前对这个漏洞的文字诊断是错误的，直到截图纠正了我的判断。文档和图片呈现了两种不同情况，最终图片胜出。这正是本文的论点：逻辑推理生成的记录可能与设备生成的记录不一致，而其中只有一方真正接触过手机。
一个相关失误：没有人想到要检查的事
以上五项都是尚未被任何测试程序发现的失败案例。最后一个例子的机制不同，值得单列，而不是简单归入这套分类。在一次普通测试会话中，自动辅助功能扫描在 27 个屏幕上发现了 87 个问题，而此前我的测试和代理测试都已通过：对比度不足、触摸目标过小、表单输入框缺少标签。
问题确实存在，扫描程序也发现了它们，我可以查看每一项发现。失败原因不在证据来源，而在覆盖范围：我和代理编写的断言都没有针对辅助功能，因此没有标记出这些问题。这是注意力缺陷，不是来源缺陷。但它对发布负责人造成同样的实际影响：真实缺陷被标记为已通过。你无法为从未想到的风险编写断言，代理也会完全继承已有断言的边界。
只需把设备状态放进上下文即可吗
这是最强烈也最合理的反对意见，值得直接回应。反对意见是：截图、日志、视频、插图和本地构建哈希等都可以捕获并导入模型上下文，所以这只是工具缺口，可以用更好的接口弥补，而不是永久障碍。
答案是：模型可以接收设备数据，但无法生成设备数据。所有这些数据都源于某个程序先在真实硬件上运行。模型无法直接导入三类信息：
- 从未被记录的事实，因为它发生时没有任何记录
- 从未运行过的设备所产生的结果，因为条件存在于该主机状态中
- 从未想到要检查的情况所发出的信号，因为没有针对该情况进行捕获
捕获、执行与关注，将设备证据输入模型确实有用；但这发生在一次物理运行之后。硬件始终承受负载，问题从来不在模型是否足够智能，而在证据是否曾被生成。正是这种证据缺失，使脱离上下文的故障成为一种长期存在的限制，而不只是工具上的缺口。
证据来源：记录的制作人
以下是工程副总裁或首席技术官可以采取行动的版本。审计跟踪通常由计算机生成，这本身从来不是问题。真正使审计跟踪可信的是一系列控制：完整性、可追溯性、保留期限和分离性。被审查者不能同时创建并悄悄篡改证明其工作合规的记录。
编写代码、编写测试、运行测试并提交结果的人工智能代理，从本质上违反了最后一个控制。记录确实存在，但被审查对象生成了所有记录，也可以修改它们。因此，这些记录只能证明其工作量，不能证明独立验证已经发生。
在监管严格的环境中，这不是个人偏好，而是签署问题。在银行、医疗器械和游戏行业，拥有签署权的人必须证明发布内容的可靠性，系统自身生成的记录并不能充当全部依据。这也是过去需要人工质疑参与决策的原因。例如，美国一家大型航空公司的质量主管受无障碍法规约束，一旦出现问题就可能面临实际经济处罚。他需要补救计划和独立证据来证明修复有效，也需要能够郑重声明我已经验证过了。
这不是官僚主义，而是溯源问题。
即使故障数量减少，其占比也可能增长。随着模型能力提升，意图不匹配和逻辑错误越来越多地被擅长推理的第二个代理捕获。即使更强的捕获能力和更广的设备覆盖持续降低故障频率，来源端故障在漏检故障中的比例仍可能上升。如果团队只依赖更好的模型制定质量保证策略，最终面对的仍会是最后一公里。
判决必须源于模型之外
回到 QA 主管最初的问题：如果代理对刚报告的测试结果判断错误，会发生什么？他的直觉是对的。对于脱离上下文的故障，第二个代理基于相同测试数据继续推理也无济于事，因为两个代理都没有生成可供推理的决定性证据。
结论无需刻意强调：对于这类故障，判定及其依据必须来自模型无法影响的领域，来自它未曾驱动的硬件，来自它未曾创建的工件。这不是针对任何特定厂商工具的结论，而是由故障机制本身决定的。
请将这五个类别及其对应的覆盖缺口应用到本周的缺陷泄漏日志，并把上季度的事件归类到这些类别中。归入这些类别的事件，是更智能的代理仍难以独立检测、值得优先建设安全防护的重点。
相关阅读
##### FunTester 名片｜万粉千文，百无一用