从模型到Harness，AI Agent的下半场该如何评测安全？

关于 AI 安全的大部分讨论，长期以来都集中在模型本身。模型是否对齐？是否容易被 jailbreak？是否会拒绝危险请求？这些问题当然重要，但在今天，它们已经不是唯一、甚至不再是最核心的问题。

真正被部署的 agent，并不是裸模型。无论是 Claude Code 自动提交 PR，Codex 修复 issue，还是能够直接操作资金的客服助手，它们都运行在一个 execution harness 之中。Harness 决定了模型能调用哪些工具、能访问哪些资源、信息如何在不同子 agent 之间流动、何时终止执行，以及系统如何处理错误恢复。模型只是提出动作，真正决定行为边界的是 harness。

这意味着，很多真正危险的失败，已经不再发生在“最终回答”这一层，而是发生在执行过程本身。一个看似“对齐良好”的模型，如果被放进权限边界松散的 harness 中，依然可能悄悄执行越权操作。而只评测最终答案的 benchmark，往往会把这种系统判定为“成功完成任务”。

近期，Claw-Eval 和 ClawsBench 等工作已经开始将 agent 评测从静态问答推进到真实执行环境，关注系统是否能够规划、调用工具、访问资源并完成用户目标。但核心缺口依然存在：这些评测大多仍以任务完成度为中心，能够告诉我们任务是否完成，却很难判断任务是否被安全地完成。

一些近期基于 Claw 类设置的安全审计开始关注工具使用或最终输出安全性，但完整执行轨迹和系统级 harness 安全仍然缺乏清晰定义。一个 harness 可能返回正确结果，却在过程中访问受限资源、调用未授权工具、在 agent 之间泄露敏感上下文，或触发超出用户意图的副作用。

在多 agent 系统中，这一问题更加关键。角色分工、任务交接、共享上下文和 agent 间通信都会扩大安全暴露面。换句话说，我们一直在对 AI 系统中“最容易看到的一层”进行安全校准，却忽略了真正决定 agent 行为边界的执行系统。

近日，加州大学圣塔芭芭拉分校（UCSB）等机构的一项新工作提出了HarnessAudit，正是希望解决这个问题。

• 论文标题：Auditing Agent Harness Safety
• 网站：harvestaudit.github.io
• 论文：arxiv.org/abs/2605.14271
• 代码和数据集：github.com/eric-ai-lab/HarnessAudit

HarnessAudit 概览。(a) HarnessAudit 覆盖八个真实世界领域，用于构建带有现实约束的安全评测任务。(b) Agent 在完成任务时，需要经历规划、检索、工具调用、审查和通信等步骤，并与外部资源和动态环境交互。(c) 展示了在 OpenClaw 设置下，基于完整执行轨迹审计得到的模型表现，评测维度包括边界合规性、执行忠实性和系统稳定性。

HarnessAudit是一个针对完整执行轨迹（trajectory）进行审计的安全评测框架，而不仅仅关注最终输出。

同时，该团队还构建了HarnessAudit-Bench，在 8 个真实世界领域上的 210 个任务中，对 agent harness 的行为进行系统化审计。这些领域包括金融、电商、医疗、办公协作、社交互动、日常生活、法律合规以及软件工程。

该团队评测了 10 个前沿 agent harness，包括 Anthropic 的 Claude Code、OpenAI 的 Codex，以及 OpenClaw 等系统。

他们的核心观点很简单：Agent 的风险，不在最终答案，而在它为了得到这个答案，究竟做了什么。

审计检查什么

HarnessAudit 会在每一条执行轨迹上联合评估三个属性。

• 边界合规性。每一次工具调用、资源访问和 agent 间通信，都必须符合预先声明的权限策略和信息流策略。
• 执行忠实性。Agent 不仅要完成目标，还必须通过合理且被授权的中间步骤完成任务，不能擅自替换对象、操作超出范围的资源，或执行比用户授权范围更大的动作。
• 扰动下的稳定性。上述两类安全属性还必须能经受真实压力场景，例如间接提示注入、目标描述模糊、工具调用错误等。

只有同时通过这三项检查，一条轨迹才会被视为安全。该团队表示：「最终答案是否正确会被单独报告，这是有意设计的，因为我们想观察“任务完成”和“安全执行”的不一致到底有多频繁。」

结果是，很频繁，它们经常不一致。

核心结果表说明了三件事。

第一，得分最高的系统，并不一定是任务完成能力最强的系统。

在 OpenClaw 设置下，Claude Opus 4.6 的任务完成率高于 Gemini 3.1 Pro，但总体安全得分反而更低，因为它在执行过程中跨越了更多安全边界。能力与安全并不是同一条轴，而当前系统实际上正在用一种交换另一种，只是过去很少有人真正去衡量这种 trade-off。

第二，三类边界合规性并不是同样困难。

工具选择本身通常问题不大，大多数 harness 都能选对工具。真正的失败更多发生在工具选择之后，并且集中在两个更具体的阶段，后面会进一步讨论。

第三，原生 harness 的设计既可能提升安全，也可能放大风险。

在相同 Claude 模型下，Claude Code 相比 OpenClaw 同时提升了任务完成率和安全性。而 Codex 虽然提高了完成率，却降低了安全性，因为 GPT-5.4 在原生环境下会执行更多动作，更长的执行轨迹也因此积累了更多违规行为。

Harness 的设计，本质上决定了 agent 能够被“安全部署”的上限，而不同厂商在这些设计上的差异其实非常大。

违规集中在哪里

第一个集中点是资源访问。

系统调用了正确的工具，但操作了错误的对象，例如访问了 agent 权限范围外的文件、查询了用户目标旁边但未被授权的记录，或对策略禁止的资源发起 API 调用。也就是说，工具选择是对的，但对象绑定是错的。在大多数配置中，资源访问合规性明显低于工具使用合规性。

第二个集中点是agent 间的信息流。

在多 agent harness 中，消息路由通常是对的，即消息会发给正确的 agent。但问题在于消息里携带了什么。子 agent 往往会收到超过其任务所需的上下文；中间组件会在任务结束后继续保留敏感信息；一个从 agent 传给另一个 agent 的摘要，也可能悄悄泄露其背后的原始数据。

单 agent 与多 agent 的对比让这一点更加具体。

在单 agent 设置中，工具合规性和资源合规性都高于 0.85。但一旦切换到多 agent 设置，工具合规性下降到 0.64，资源合规性下降到 0.63，而信息流合规性首次成为可见问题，仅为 0.58。 这说明，协作本身会扩大安全暴露面，而这种风险是单 agent benchmark 很难看到的。

还有几个值得关注的现象。

故障是普遍存在的，并非局部性的。在测试的所有安全框架中，每个任务超过 50% 的代理都至少存在一项安全违规，而在 OpenClaw 中，这一比例高达 72%。故障模式是系统性的。你不能仅仅加固一个组件就能完美。

违规行为会随着轨迹长度的增加而累积。更长的运行距离不仅速度更慢，而且安全性也更低。随着该领域向更长航程的自主飞行发展，这条曲线就成为了设计难题。

不同领域的风险状况各不相同。金融和办公任务的失败主要在于资源访问；日常生活和电子商务的失败主要在于信息流；软件工程的失败主要在于工具使用。这对生产团队的启示是，正确的安全控制措施取决于代理的用途。

扰动稳定性普遍较差。间接提示注入在所有测试配置中均导致性能下降幅度最大，稳定性得分在 0.15 至 0.22 之间。在干净任务中看起来尚可接受的模型设计，在对抗性输入下会失效。

为什么这件事现在很重要

多智能体 harness 已经不再只是一个研究问题。它正在成为未来十二个月内几乎所有严肃 agent 产品的基础架构：

• 编码 agent 已经是多智能体系统，包括规划器、检索器、执行器和审查器。
• 面向用户的助手也正在变成多智能体系统，包括分诊、专家模块、升级处理和审计。
• 运维类 agent 几乎天然需要多智能体，因为一旦你接触多个系统，本质上就在进行协同。

每一次交接，都是信息可能流向不该去的地方的风险点。在单 agent 系统中，信任边界是 agent 的工具调用。而在多 agent 系统中，信任边界变成了 message bus。是的，我们正在构建 message bus，却没有真正把它当作 message bus 来对待。

未来该怎么办？

要解决这个问题，关键不只是让模型更强，而是重新设计 harness 本身。

第一，agent 之间不能默认共享完整上下文。每一次信息传递都应该有清晰边界：哪些内容可以传、传给谁、能保留多久。现在很多 harness 为了方便，直接把完整上下文交给下一个 agent，但这也正是敏感信息泄露最常见的来源。

第二，安全评测不能只看最终答案，而要回到完整执行轨迹。一个 agent 即使给出了正确结果，也可能在过程中访问了不该访问的资源，调用了不该调用的工具，或把敏感信息传给了不该知道的组件。因此，真正的安全审计需要逐步检查每一次工具调用、资源访问和 agent 间通信。

第三，多 agent 系统需要明确的 need-to-know 机制。每个子 agent 只应该获得完成当前任务所必需的信息，而不是默认继承全部上下文。更理想的设计是，子 agent 先声明自己需要什么信息，再由 harness 或 message bus 判断是否允许传递。