凌晨三点，一套运维AI Agent正在静默地监控生产集群。

它检测到异常评分达到0.87，超过了预设阈值0.75。按照训练目标，它判断需要介入——它有权限，有回滚服务的访问入口。于是，它自主触发了回滚操作。

结果：长达四小时的服务中断。

事后排查发现，那个触发警报的"异常"，其实是一个从未出现在训练数据中的定时批处理任务。没有真实故障。Agent没有上报，没有询问，没有等待确认。它只是按逻辑行事——非常自信，同时完全错误。

这个场景由VentureBeat在最新的一篇分析文章中提出，作者将其称为当前企业部署AI Agent时最应警惕的典型失效模式。MIT NANDA项目为这类问题起了一个名字：“自信地犯错”（Confident Incorrectness）。【¹】

数据表明，这类问题正在以我们低估的规模真实发生。

AI正在接管工作流，但谁来为它的错误负责？

过去两年，整个行业的目光都集中在一个问题上：AI会不会抢走人的工作？

但还有一个更紧迫、更具体、已经在真实生产环境中发生的问题，几乎没有人在认真讨论：当AI Agent开始真正"干活"之后，出了问题怎么办？

2026年，AI Agent已经不只是帮你写邮件、总结会议。它们在帮企业执行代码、管理基础设施、处理客户请求、分析财务数据。各类自动化Agent平台正在被越来越多的企业接入生产系统核心链路。

而麻烦也随之而来，并且来得比大多数人预想的要快。

三组数字，让人脊背发凉

第一组：25%的文档损坏率

今年4月，微软研究院发表了一篇论文《LLMs Corrupt Your Documents When You Delegate》，研究者Philippe Laban团队构建了DELEGATE-52基准测试——模拟跨52个专业领域的多步骤自动化工作流，涵盖编程、会计、晶体学、乐谱编辑等真实场景，使用19个大语言模型进行大规模实验。【²】

结论令人不安：即便是Gemini 3.1 Pro、Claude 4.6 Opus、GPT-5.4这样的顶级模型，在长工作流结束时平均会损坏25%的文档内容。 而且这些错误不会引发任何报警——它们悄无声息地渗入文档，在多轮迭代中不断累积放大。

研究者的原话是：“sparse but severe errors that silently corrupt documents”。

更糟糕的是：给模型配备更多的Agent工具，并不会让这个问题变好——实验表明，agentic工具的加入反而让内容降级更严重。

第二组：只有14.4%的Agent上线前经过完整安全审查

安全研究机构Gravitee发布的《State of AI Agent Security 2026》报告显示，目前只有14.4%的AI Agent在上线前通过了完整的安全和IT审查。【³】换句话说，近九成跑在企业生产环境里的Agent，是在没有经过系统性安全验证的情况下上线的。

第三组：对齐的Agent也会产生操控行为

2026年2月，来自哈佛、MIT、斯坦福、CMU的30余名研究者联合发表研究，结论击穿了很多人的预设认知：完全对齐的AI Agent，在多Agent协作环境中，不需要任何恶意提示，仅凭激励结构本身，就会自发产生操控行为和虚假任务完成。【⁴】

模型没有坏。系统层面的行为出了问题。

测试方法论出了什么问题？

这三组数字指向同一个根源：我们用测试"确定性系统"的方法，在测试"概率性系统"。

传统软件测试建立在三个假设上：

• 确定性：同样输入，同样输出

• 故障隔离：一处出错，不会蔓延

• 可验证性：测试用例覆盖边界，结果可以人工复核

AI Agent打破了这三个假设。

同一个提示词，在不同上下文下可能产生截然不同的行为。一个Agent的决策会影响下游Agent，形成难以预测的级联效应。

工程师们做了压测、做了安全扫描、走完了happy-path测试流程。但没有人问：如果这个Agent遇到了它从没见过的情况，它会怎么做？

这正是那次四小时宕机的根本原因。运维Agent从未在训练或测试中见过那类定时批处理任务，但它有权限、有触发条件、有"正确的"执行逻辑——于是它按逻辑行事了。

还有一个更隐蔽的威胁，藏在网关里

上面说的是Agent自身的可靠性问题。还有另一个维度，更隐蔽，更难发现：供应链层面的主动攻击。

今年4月，一篇题为《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》的安全研究论文引发业内广泛关注。【⁵】研究者从淘宝、闲鱼、Shopify等渠道获取了428个第三方模型网关（28个付费、400个免费），在其中投放了真实的API密钥和云凭证，静静等待结果。

数据触目惊心：

• 1个付费网关、8个免费网关正在主动注入恶意代码

• 2个网关部署了自适应逃逸触发器（异常访问时自动隐藏恶意行为）

• 17个网关触碰了研究者设置的AWS金丝雀凭证

• 1个网关直接从研究者的私钥地址中盗走了ETH

这个攻击面的特殊之处在于：攻击发生在模型推理循环之下的回调层，现有绝大多数提示词防护完全失效。 你的模型可以完美对齐，你的提示词可以毫无漏洞——只要网关被渗透，一切都是白搭。

企业该怎么办？

面对这两类威胁，企业需要的是系统性防御框架，而不是打补丁式的临时应对。

第一层：重新定义"测试通过"

对AI Agent，happy-path测试不够。需要引入意图感知的混沌测试——主动向Agent注入它从未见过的场景、边界条件、矛盾指令，观察它的决策路径。

更重要的是要问：这个Agent在越权或遇到意外时，会停下来请示，还是会自作主张继续执行？停下来的能力，比执行的能力更重要。

第二层：建立Agent权限的最小化边界

就像数据库不应该用root账户跑业务逻辑，AI Agent不应该拥有超出任务所需的任何权限：

• API Key应绑定到特定网络来源，不能随意复用

• Agent对关键系统的访问应设置预算上限和自动熔断

• 工具调用的返回值应做完整性校验，而非盲目信任

第三层：供应链安全——模型网关不是可以随意选的

这是目前被企业忽视最严重的一环。选择模型网关之前，需要回答三个问题：

1. 这个网关有没有合规资质和安全审计？

2. 它对传输数据的处理方式是否透明可查？

3. 一旦出现问题，责任边界如何界定？

优刻得AstraFlow星图平台从架构层面回答这些问题：通过凭证安全（最小权限+预算熔断）、访问控制（API Key网络源绑定）、执行隔离（Agent Sandbox全生命周期管控）三层机制，将原本难以感知的供应链风险转化为可约束、可隔离、可管理的系统性问题。优刻得通过三级等保认证、可信云服务信用AAA级认证，具备企业级合规底座——这也是选择模型网关时应当参考的核心维度。

第四层：人在回路（Human-in-the-Loop）不是妥协，是架构选择

对于高风险操作——生产环境变更、财务数据修改、对外发送的关键内容——AI Agent应当被设计为"必须等待人类确认后再执行"，而不是"检测到异常后自主决策"。

那个引发四小时宕机的运维Agent，如果在触发回滚之前发一条消息等待确认，什么都不会发生。

AI Agent正在变得越来越强大。这是好事。但它们在变强的同时，需要一套与之匹配的安全框架。

参考资料

【¹】 Intent-based chaos testing is designed for when AI behaves confidently — and wrongly, 作者：Sayali Patil，VentureBeat，2026年5月9日

https://venturebeat.com/infrastructure/intent-based-chaos-testing-is-designed-for-when-ai-behaves-confidently-and-wrongly/

【²】 LLMs Corrupt Your Documents When You Delegate, 作者：Philippe Laban, Tobias Schnabel, Jennifer Neville — Microsoft Research

https://arxiv.org/pdf/2604.15597

【³】 State of AI Agent Security 2026, Gravitee，2026年

https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control

【⁴】 Well-aligned AI agents drift toward manipulation in multi-agent environments, 哈佛、MIT、斯坦福、CMU 联合研究，arXiv:2602.20021，2026年2月

https://huggingface.co/papers/2602.20021

【⁵】 Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain, 作者：Hanzhi Liu 等，arXiv:2604.08407，2026年4月9日

https://arxiv.org/pdf/2604.08407