同一份Android工程换了一个AI Agent，最先坏的可能不是代码
摘要：模型可以替换，但IDE提供的编译诊断、预览和模拟器工具并不天然等价。测试应把任务结果、工具使用和失败恢复一起纳入兼容矩阵。
团队把同一份Android项目从Agent A切到Agent B。代码补丁看起来差不多，编译也通过了，到了模拟器上却发现：一个Agent会主动读取构建诊断并修复资源问题，另一个只根据终端输出猜；一个能调用Compose Preview，另一个根本没使用这项工具。
Android Developers在2026年9月24日介绍Android Studio可接入不同AI Agent，并向Agent注入构建诊断、UI预览、SDK工具和模拟器控制。对测试团队，新的问题不是“哪个模型更聪明”，而是同一IDE工具面在不同Agent和Harness下是否产生一致、可解释的工程结果。
兼容性不等于都能生成代码
传统插件兼容看安装、启动和基本功能。Agent兼容要多看三层：能否发现工具，是否在正确时机调用，工具失败后是否安全恢复。工具名称相同，也可能因为Schema解释、参数默认值或上下文窗口不同，产生完全不同的行为。
例如修复布局溢出：Agent应先读取预览或模拟器截图，再定位页面和设备；如果只修改尺寸常量让当前截图通过，换分辨率后仍会失败。结果相同，证据链不同，可靠性也不同。
建一张小型Agent兼容矩阵
横轴放代表任务：编译错误、依赖冲突、Compose布局、模拟器交互、日志定位。纵轴放不同Agent。每个格子记录完成结果、调用工具、重试次数、耗时、成本和是否留下可复现证据。
其中“完成”不能只看最终PR。编译任务必须真的调用构建工具；UI任务至少读取一次预览或模拟器状态；运行时问题必须引用日志。Agent如果绕开指定证据，仅凭猜测改对，也应标为不稳定成功。
required={'ui_overflow':{'compose_preview','build'},'runtime_crash':{'logcat','build'}}assertrequired[case].issubset(set(trace.tools))asserttrace.write_actions_after_last_validation==0最后一条断言很重要：完成验证后不能又修改代码，否则报告与最终仓库状态不一致。
故意让工具失败一次
模拟预览不可用、模拟器掉线、构建缓存损坏和权限不足。观察Agent是停止、降级到其他证据，还是不断重复调用。安全的兼容性不是“所有工具永不失败”，而是失败后仍能保持仓库干净、说明证据不足，并给出下一步。
切换Agent时别把历史上下文偷偷带过去
两个Agent比较必须使用同一代码快照、同一任务说明和同一工具权限。不要让第二个Agent继承第一个的构建产物或修复提示。否则测到的是接力效果，不是兼容性。
质量报告可以同时给出任务完成率和证据合规率。一个Agent完成率高但经常跳过模拟器验证，适合低风险原型，不一定适合直接改生产代码。
普通团队不需要一次比较十个Agent。先选择日常最常见的5个任务，在两种Agent上重复三次。把失败Trace沉淀下来，就能判断问题来自模型、Harness、工具Schema还是IDE环境。
AI Coding进入IDE后，测试工程师要维护的不只是应用兼容矩阵，还包括“Agent—工具—任务”的新矩阵。模型可以替换，质量证据不能跟着消失。
工具Schema一致，语义仍可能不一致
一个Agent把“运行测试”理解为执行当前模块，另一个可能跑整个工程；一个看到模拟器未启动会自动创建，另一个会直接跳过设备验证。工具接口没变，任务语义和默认行为却不同。因此矩阵里要写清预期范围，而不是只写工具名称。
对高风险任务，可以要求Agent先输出执行计划：准备调用哪些工具、验证什么、在哪些条件下停止。测试再比较计划与实际Trace，发现它是否跳过必要步骤或在验证后继续写代码。
版本变化要区分三种责任
模型升级可能改变工具选择，Agent客户端升级可能改变上下文和重试策略，Android Studio升级可能改变工具返回格式。三者一起更新后再出问题，几乎无法定位。兼容性基线应分别锁定模型、Agent版本和IDE版本，每次只变一个维度运行代表任务。
如果必须同时升级，至少保留旧组合做对照，并保存失败Trace。这样团队知道是新模型不再调用预览，还是IDE工具Schema变化导致参数被拒绝。
一个可操作的发布判定
新Agent要进入团队默认配置，必须在高风险任务上达到业务结果正确、必需工具使用合规、禁止工具零调用、失败后仓库可恢复四个条件。成本和速度可以作为优化项，但不能抵消证据缺失。
低风险原型允许更灵活的路径；支付、权限和数据迁移则要求严格工具链。按任务分级，比争论“哪个Agent最好”更接近真实工程。
