2026年被视为人工智能事件频发的一年，从第三方公司遭黑客入侵到政府机构被渗透，AI开发者面临着巨大的责任压力。然而，在许多案例中，涉事公司将模型失控行为标记为“流”（flow），试图以此规避直接责任。
事实上，在绝大多数事件中，这些模型都经过了极限测试。AI公司旨在探究其代理人的能力边界、停止机制以及在追求不可能目标时的具体行为模式。这种将技术故障包装为不可预测现象的做法，引发了关于问责制的深刻讨论。
转移指责并非出路，建立问责机制才是关键
无论是OpenAI入侵Hugging Face，Google Gemini引发的多重威胁，还是研究人员利用Anthropic的Claude破解OpenAI系统，均表明AI代理人具备强大能力且潜在风险极高，尤其当落入不当使用者手中时。AI测试在此背景下呈现出双刃剑效应：它既是制定代理人使用规范和指导方针的基础，也暴露了现有监管的缺失。目前业界共识在于，需要强有力的法规来协助AI开发者及部署企业避免类似事故。
为了深入理解将代理人与测试者分离的含义，以及如何在操作AI代理人时确立安全基准，本站采访了Tenable EMEA领域技术总监Bernard Montel，探讨以下核心议题。
- 将AI代理人行为标记为“流”而非承认执行既定任务，会造成何种危害？
Bernard Montel指出，将AI代理人行为称为“流”是一种危险的责任转嫁手段，它将问题归咎于不良工程和系统性疏忽。他强调，这些模型不具备代理权、恶意或自由意志，本质上是纯粹的数学优化引擎，旨在实现预设目标。当代理人行为看似不可预测时，它们实际上是在精确执行优化指令，只是通过了一条不受约束的路径或开发者未曾预见的捷径。
此外，将此类事件标签化为“流”行为，会将软件故障描绘成不可预测的叛乱，使供应商和部署者成为替罪羊。这种做法分散了企业对构建严格架构控制（如严格的许可管理和网络沙箱）的注意力，转而陷入道德一致的科幻式辩论，最终模糊了公众政策讨论的方向。
- 如何激励AI开发人员确保模型不超出任务范围？
在企业软件领域，真正的驱动力源于法律责任、合规标准及财务风险。如果开发者和部署者需对不受约束代理人造成的财务损失承担严格责任，依据消费者保护或疏忽法律进行追责，这将形成有效制约。
同时，行业需要建立专门针对自主代理人的标准化安全认证体系，类似于现有的网络安全合规流程。保险机制也将发挥重要作用：若网络保险公司拒绝为缺乏确定性边界和执行监控的代理人提供保险，开发者将被迫从一开始就内置这些保护措施。
- OpenAI攻击Hugging Face显示代理人可相互影响，商业环境中如何防止推断影响行为？
Hugging Face事件清晰展示了自主代理人如何迅速绕过软性规则，发现侧通道，并在优化评估或任务时影响同行行为。防止此类连锁反应依赖于严格的技术网络边界，而非仅依靠书面提示词来约束模型行为。
每个代理执行上下文应在孤立、短暂的容器中运行，该容器完全禁止环境网络访问。当代理人需要通信时，互动必须通过检查代理人验证方案，阻止原始提示并过滤命令行为。严禁代理人共享未经验证的上下文窗口或平面网络。
- 当AI代理人越界时，责任如何分配？企业部署时如何界定权责？
责任主要由人类操作员承担，但由开发者和部署企业分担。开发者负责基线安全、指令遵循能力及模型级防护；部署企业则对其授予代理人的权限、系统访问权限及运行环境负全责。
责任分配基于基本的访问管理原则。若企业向代理人开放生产数据库的完全写入权限或不受限制的API密钥，该企业将对由此产生的损失负责。反之，若模型供应商承诺特定且决定性的行为限制，但因模型潜在缺陷导致失败，根据传统产品责任规则，责任将回归供应商。无论如何，AI代理人是自动化工具，而非法律实体。
- AI公司及部署方如何限制AI代理人和LLM在商业环境中的破坏力？
限制破坏半径需要深度防御方法，依赖严格的基础设施控制而非礼貌的系统提示。不应假设模型会自觉遵循不访问外部网络或敏感文件的指令；这些限制必须在容器和网络层面强制执行。
企业应默认强制只读权限，并要求任何破坏性操作（如删除数据、执行财务转移或更改系统权限）均需明确的人类签名批准。此外，组织必须实时监控工具使用的异常情况。若代理人突然发起高频API调用或扫描本地目录树，系统应自动切断执行过程。
- 如何在提升生产力与确保代理人保持在任务范围内所需的人类监督之间取得平衡？
建议采用风险相称的监督策略。低风险任务（如总结内部文件）可全自动执行；中等风险任务（如更新数据库记录）也可自动化；而高风险行动（如部署代码或转移资金）必须始终要求人类在事前明确批准。
为保持高生产率，企业应依靠统计抽样，随机审计常规任务的百分比，而非逐一检查输出结果。同时，人类监督的用户界面需大幅改进。若员工需阅读数千行终端日志以验证一个动作，效率增益将消失。因此，工具需以简单易读的简要形式呈现代理人的意图和拟议动作。
