智能体安全别只盯提示词：企业还得给模型建一份“成分表”

一个智能体答错了，团队往往先回看提示词、权限和工具调用。但如果它使用的模型版本被悄悄替换、微调数据不可追溯，或者运行框架带着未被发现的风险，这些检查都只能解释“它做了什么”，却解释不了“它为什么会这样做”。Google Cloud近日发布的生产级AI工作负载安全蓝图，把模型、数据集和框架纳入一份AI物料清单（AI BOM）。我认为，这个动作提示企业：智能体安全正在从“管住一次调用”，走向“管清一套供给”。

真正的风险，不只发生在对话框里

7月16日，Google Cloud在GKE安全蓝图中把AI防护拆为三层：底层保护计算与身份，模型层关注权重、数据和框架的来源与完整性，应用层再防提示注入、敏感信息泄露和会话滥用。它特别指出，传统软件物料清单并不能覆盖AI产物，因此需要把模型、数据集和框架一并记录。来源：Google Cloud，2026年7月16日

这很像食品企业的配料表：消费者看到的是成品，企业却必须能回答原料来自哪里、哪一批进入了生产、出现问题后如何召回。智能体同样如此。提示词只是“菜谱”，模型、知识库、嵌入模型、检索策略、外部工具和运行环境才共同构成“配料”。若其中任何一项变化没有被登记，今天通过的评估，明天未必仍然适用。

可审计的智能体，不只是保留聊天记录；还要能还原某次结果由哪个模型版本、哪批知识、哪些工具和哪条策略共同生成。

先做“最小成分表”，别等事故后考古

企业不必从复杂平台开始，可以先为每个生产智能体建立六项最小记录：业务负责人和用途；模型及版本；知识来源、更新时间与可访问范围；可调用的工具和写入权限；评估集与通过门槛；发生异常时的停用与回滚负责人。它不是又一张填表任务，而是让变更具备“可比较、可批准、可撤回”的前提。

第二步是把变更变成事件，而非默默发生。换模型、更新知识库、增加外部工具、修改系统提示或权限时，都应留下版本号、影响范围和复测结果。微软7月20日宣布面向数据处理、芯片设计和生产级推理提供不同优化的计算实例，也说明底层资源正在快速分化；企业更不能假定“同一个Agent”永远运行在同一种条件下。来源：Microsoft，2026年7月20日

STARBOX视角：把“来源记录”做成可运营资产

在STARBOX看来，模型不是孤立能力，而是组织工作站的一种可替换组件。组织层应定义哪些内容、数据和动作允许被AI处理；BOX层沉淀知识来源、版本、任务卡、审核规则和失败样本；智能体层只在这些边界内调用模型与工具。DDABC闭环再把被拦截、被打回和人工接管的案例变成下一轮校准依据。

这比单纯追求“更强模型”更接近企业的真实需要：当供应商、模型或工作流变化时，组织仍知道什么被改了、谁批准了、质量会受什么影响，以及需要如何回退。智能体越深入业务，越不能把安全理解为一个对话框前的拦截器；它应是一条贯穿供给、运行和复盘的责任链。

下一次给智能体加新能力前，不妨先问一句：如果它三个月后出错，我们能不能像查一件产品一样，立刻说清它的“成分”、版本和去向？答得出来，才算真正拥有了这项能力。