做安全的团队都熟悉一个套路漏洞出现后安全研究员把它写成 CVE厂商修复社区共享情报整个行业一起补。这套机制让传统网络安全在没有统一指挥的情况下运转了几十年。现在有人想把同一套玩法搬到 AI 智能体上。Black Hat 2026 开幕当天Linux 基金会抛出了一份关于 Shared AI Findings ExchangeSAFE的征求意见稿要把智能体的安全事故变成整个生态的共享防御。智能体事故为什么值得共享SAFE 指南由开放安全 AI 联盟Open Secure AI Alliance工作组起草联盟成员已经超过 120 家NVIDIA、Cisco、CrowdStrike、Hugging Face、Red Hat 都在参与。指南的核心动作有几个保密地收集和分析 AI 事故与近失事件、通知受影响方、识别反复出现的控制失效点、发布基于证据的操作建议来降低系统性风险。值得关注的是反复出现的控制失效点这个说法。传统安全里同类漏洞反复出现是常态所以才有 CVE 编号和漏洞库。智能体的事故现在也开始呈现这种规律性——提示注入、工具投毒、权限越界很多事故换个模型换个场景又出现一遍。如果这些模式能像漏洞一样被记录、被归类、被共享防御方就不必每次从零排查。事故数据本身就是敏感数据但这里有个 SAFE 绕不开的矛盾。传统漏洞情报共享的是技术细节而智能体事故记录里全是敏感内容用户的提示词、模型的推理过程、工具调用的参数、内部系统的响应。Uber 开源的 ADR 系统Agentic AI Detection and Response每天在 3 万个端点上处理超过 20 万次智能体会话它重建的是从 prompt 到推理、工具调用、最终结果的完整因果链——这恰恰是事故分析最需要的东西也恰恰是企业最不愿意交出去的东西。保密地收集和分析这句话因此成了整个指南的承重墙。收集事故数据要保密分析结果要共享这两者之间的平衡怎么做指南目前没有给出细节。对企业来说共享一次事故记录可能等于把自己内部系统的提示词工程、工具链设计、甚至业务逻辑暴露给同行。智能体安全不是模型安全SAFE 之外联盟成员这次集中放出了一批开源工具覆盖的层次很能说明问题。NVIDIA 的 OpenShell 运行时限制智能体能看到什么、碰到什么、做什么Okta 在推跨应用访问协议 XAA 的参考实现Red Hat 的 asago 把 NIST、OWASP、EU AI Act 的治理要求映射成智能体运行时的权限Microsoft AI Red Team 开源了 PyRIT、RAMPART 等红队工具Cisco 的 DefenseClaw 直接架在 OpenShell 之上做运行时治理。这些工具的分布透露了一个共识一个智能体不只是模型它是一套系统——身份控制、运行时、护栏、日志、评估缺一不可。单靠漏洞扫描解决不了智能体安全这跟传统应用安全只靠 WAF 挡不住业务逻辑漏洞是一个道理。对部署了智能体的团队来说这意味着安全评估的清单变长了模型层要测工具层要测身份和权限层更要测。从公开到落地还有距离这份指南目前还是征求意见稿距离变成可执行的安全实践还有相当距离。至少有两个问题没有答案事故共享的粒度怎么定——是共享摘要、共享特征还是共享完整的复现路径共享后的责任边界在哪——用了别人共享的情报出了问题算谁的这些问题不解决指南就只能停在倡议层面。对大多数团队来说现在能做的不是等指南落地而是先把自己的智能体日志和工具调用记录结构化。不管共享机制最后长什么样事故数据不完整、不干净一切都是空谈。这也可能是 SAFE 最有价值的地方——它逼着每个部署智能体的团队先想清楚自己的事故数据长什么样。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版