关于 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 判断是否允许传递。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
广禾配资提示：文章来自网络，不代表本站观点。
