泉源：男子身体不适坐路边摇椅清静去世作者： 李佳和：

从模子到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 判断是否允许转达
。。。。。