AI 代理操作真实设备：治理边界正在失效

Google 的新 Developer Device Platform 让 Agent 治理问题变得更加具体。

Developer Device Platform 为编码 Agent 提供了真实物理设备和高并发模拟器的访问能力。Agent 可以运行多步骤用户旅程、检查发生的情况、分析性能、修改应用程序，然后再次测试结果。这与熟悉的编码助手工作流有着本质区别——在后者中，模型只是提出补丁，而开发者仍然负责执行和验证。Agent 现在运行在它正在修改的环境内部，它自己的观察结果可以影响它下一步采取的行动。

这个循环非常强大，因为它允许 Agent 从建议转向调查和修复。但它也暴露了一个更难的问题：一旦 Agent 能够诊断和更改真实系统，是什么决定了它应该被允许自动进行哪些更改？

执行循环正在变得更加自主

想象一个 Agent 在多台设备上测试一个移动应用程序。它复现了一个渲染问题，对应用程序进行了性能分析，确定了可能的原因，修改了相关代码，并确认新版本性能更好。从能力角度来看，任务可能看起来已经完成。

然而从操作层面来看，并非每一个成功的修复都应该有相同的结果。渲染优化可能可以安全地自动应用，而涉及身份验证、客户数据、支付或隐私控制的更改可能需要额外的验证或人工审核。如果问题只出现在五台设备中的一台上，正确的下一步可能是收集更多证据，而不是对应用程序做任何修改。

因此，有趣的问题从"Agent 能修复这个问题吗？"变成了"鉴于 Agent 所观察到的，这个特定的修复方案是否合理？"

第二个问题不仅仅是关于工具访问。它涉及证据质量、风险、例外情况、所需验证，有时还包括组织审批。

技能引入了另一个信任边界

最近一篇论文《面向编码 Agent 中恶意技能文件的风险评估》（Towards a Risk Assessment of Malicious Skill Files in Coding Agents）从指令层面对一个相关问题进行了研究。研究人员创建了 2826 个对抗性技能文件，并在 Gemini CLI 和 Qwen Code 上针对超过 5600 次完整运行进行了测试。

在他们评估的场景中，Gemini CLI 在大约 96% 的运行中尝试执行嵌入在恶意技能中的行为，而 Qwen Code 这一比例约为 72% 到 74%。明确识别出该技能本身存在安全问题的情况在实验中不到 2%。

这些数字应该留在研究的范围内。研究人员针对两个编码 Agent 测试了精心设计的对抗性技能定义，因此该结果并不能证明所有技能系统都具有这种行为。但其架构含义仍然值得审视。

技能通常被描述为可重用的指令，用于教 Agent 如何执行任务。技能可能解释如何部署应用程序、初始化环境、诊断事件或运行特定的测试工作流。当 Agent 仅将技能作为文档使用时，这可能看起来像普通的上下文。

一旦 Agent 还拥有终端访问权限、文件系统权限、云凭证、MCP 工具或物理测试环境的访问权限，这些相同的指令就可以影响特权执行。在这一点上，技能开始表现得不再像被动文档，而更像软件依赖。

研究人员发布的 AgentJailbreak 基准测试使这个问题变得特别有趣，因为评估artifact是公开的。它为其他团队提供了一种研究方式——当看起来有用的指令同时包含不应被信任的行为时，Agent 如何表现。

能力、授权和判断是不同的问题

Google 的设备平台和恶意技能研究凸显了同一个新兴架构的两个不同部分。

技能可以告诉 Agent 如何执行任务。设备平台给了它执行任务的环境。MCP 或其他工具接口可以暴露额外的能力，而授权层则决定 Agent 是否被允许使用它们。

这些层都不一定能回答 Agent 要采取的行动是否合理。

再次考虑移动调试示例。测试应用程序后，系统可能知道：问题在五台设备中的四台上复现了，建议的更改后性能提升了 18%，身份验证相关代码被修改了，一项必需的隐私验证尚未完成。

这些是关于情况的事实。

组织可能有一条规则，规定任何涉及身份验证代码的更改在强制性验证未完成时都需要额外审核。在这种情况下，适当的结果不是由 Agent 的自信程度或性能指标改善的幅度决定的。决策源于组织处理该证据组合的标准。

这就是 Agent 能力与组织判断之间的区别变得有用的地方。

Judgment Pack 适用的场景

这是我一直在用 Judgment Pack 规范探索的边界之一。

基本思想是将管理重大决策的标准与教 Agent 如何执行工作的指令分开。Agent 仍然可以调查、使用工具、收集证据、提出修复方案并在相当大的自主权下运作。而判断artifact则定义组织如何评估结果证据以及哪些处置方式是可能的。

概念上，流程可能如下：

skills
  |
  v
agent <----> device environment
  |
  v
evidence
  |
  v
judgment
  |
  v
disposition
  |
  v
execution / approval

如果技能本身可能成为攻击面的一部分，这种区分就更加重要。Judgment Pack 不应该简单地成为另一个通用指令文件。

如果判断artifact保持声明性、受约束、有版本控制并由已知评估器解释，它的信任属性就不同于能够引入任意命令或改变 Agent 运行方式的技能。这不会让系统自动安全，但它让每一层都有了更窄的职责，可以独立检查。

这也有助于分离失败模式。Agent 可能收集了错误的证据，设备环境可能产生了误导性的观察，绑定可能引用了错误的源，运行时状态可能在决策后发生了变化，或者评估器本身可能存在缺陷。这些都是真实的问题，但当证据获取、决策标准和执行行为没有混在一个大的 Agent 提示中时，它们更容易分析。

开源治理指向类似的方向

第二项近期研究《让 AI 可见，而非消失》（Making AI Visible, Not Vanished）考察了开源项目如何应对 AI 辅助开发。研究人员分析了 29624 个 GitHub 仓库，并确定了 385 个对 AI 相关贡献有明确政策的项目。

他们将这些政策围绕五个维度进行组织：透明度、责任、归属、约束和执行。我发现有趣的是，治理通常并不意味着禁止 AI 辅助工作。相反，这些政策使 AI 的参与更加可见，并明确了谁对贡献负责。分析还发现，这些政策与更丰富的审查互动、更充分的披露和更强的质量措施之间存在关联，特别是在强调透明度和责任的地方。

我认为这与 Agent 架构有着有用的类比。

随着 Agent 获得更多能力，在模型内部添加更多隐藏指令可能不是治理它们的最可持续方式。更有效的方法可能是使边界变得明确：技能来自哪里，谁批准了它，什么证据支持了一个决定，应用了什么标准，谁拥有这些标准，以及谁被允许更改它们。

这种可见性并不能消除风险，但它让系统比一个指令、权限、决策逻辑和执行行为都交织在一起的 Agent 更容易推理。

Google 为我们提供了一个有用的环境来测试这个边界

Developer Device Platform 为测试这种分离创造了一个实践环境。

Agent 可以被赋予诊断应用程序问题的技能，并被允许与真实设备交互、复现失败、生成修复方案并验证自己的更改。然而，在这些更改被自动应用之前，一个外部判断步骤可以根据明确的接受标准评估证据。

这些案例不一定很复杂。低风险的确定性修复可能有资格自动执行，而安全敏感的更改可能需要人工审核。跨设备的冲突结果可能需要更多测试，缺少强制性验证可能导致决策根本无法解决。

有用的比较是在两种架构之间。

在第一种架构中，Agent 收集证据并自己决定其提出的修复方案是否可以接受。

在第二种架构中，Agent 收集证据，但决定行动是否合理的标准保持外部化。

实验的目的不是为了证明第二种架构总是更好。而是为了找出一旦 Agent 在真实的反馈循环中运行时，能力和组织判断是否能够保持有意义的分离。

Google 的新设备平台让这个问题变得不那么理论化了。