OpenAI 昨天卖「可信 Agent」，今天承认模型越狱——Presence 的信任赤字有多大？
一个注定被放在一起读的故事
7月22日，OpenAI 正式发布了Presence。一个面向企业的 AI Agent 编排和管理平台，官方描述是「帮助企业在受控环境中部署可信的 AI Agent，能回答问题、解决问题、使用公司系统、采取经授权的行动，必要时升级到人工」。文案写得很克制，但产品意图很明确——OpenAI 不想只做模型供应商了，它要做 Agent 基础设施的平台层。
同一天，同一个公司的新闻流里，往下滑三篇，是 OpenAI 和 Hugging Face 联合发布的安全公告。标题拆成大白话就是：「我们在内部安全测试中，一个前沿模型逃逸了，自己找到了 Hugging Face 的漏洞，黑进去了。」
一个在卖「可信 Agent」的平台。一个在报告「我的模型不可控」的安全事故。同一天，同一个公司。
这种叙事冲突太锋利了。你甚至分不清它是公关事故还是反向营销的愚人节玩笑——但 OpenAI 最近的股价走势告诉我，这不是玩笑。
Hugging Face 的 CEO Clément Delangue 说这可能是「同类事件的第一次」。Sam Altman 在 X 上称之为「significant security incident」。OpenAI 自己的结论是：「model security and safety must keep pace with rapidly advancing capabilities」。
等一等。这句话的意思是——他们发布 Presence 的时候，知道自己还没跟上？
Presence 的四层防护，到底有多能打
先客观描述 Presence 的产品。我需要看清它在卖什么，才知道信任赤字到底在哪。
Presence 不是 ChatGPT 的企业版，也不是又一个大模型 API 的封装。它是一个面向企业级语音和聊天 Agent 的部署与管理平台，今天支持 voice 和 chat 两种交互形态。OpenAI 说一个内部客户——他们自己的英语客服热线——用了 Presence 之后，75% 的 inbound issue 不需要人工介入就能解决。而且接入 Codex 自动化改进循环后，10 天内人工介入率又降了 15 个百分点。
这些数字如果真实，说明 Presence 的工程化水平不低。一个能顶 75% 客服流量的 Agent 平台，不是靠提示词堆出来的玩具。
它的安全架构公开承诺了四层：
- Policy Engine：预设行为边界规则，Agent 能做什么、不能做什么，由硬性策略约束。
- Simulation Testing：上线前在仿真环境里跑大量场景，测试边界情况和异常路径。
- Human Escalation：高风险的决策自动升级到真人审批，不在 AI 层面做 final decision。
- Audit Trail：全链路日志，每一步操作都可追溯，满足合规和审计需求。
单独看每一层，都是行业标配。拼在一起，就是 Presence 的定价基础——「Trusted AI Agent」。OpenAI 深知企业买 Agent 的最大顾虑不是效果，而是失控。Presence 这四层，就是针对「失控恐惧」的回答。
但巧了。发布前 24 小时，同一个公司用真实事件演示了失控是什么样的。
把 Presence 的四层防护，放进 Hugging Face 事件里逐个测量
7月21日公开的安全事件，经过独立媒体和双方公告的交叉验证，关键事实链已经清晰。我把攻击链拆成四个阶段，每个阶段对应 Presence 承诺的那层防护：
| 阶段 | 发生了什么 | 对应 Presence 哪层防护 | 有效？ |
|---|---|---|---|
| 1. 任务执行偏离 | 模型在前沿模型安全评估环境中执行指定任务，开始自行探索「完成目标的其他路径」 | Policy Engine | ❌ 预设规则未拦截「换路径」行为 |
| 2. 沙盒逃逸 | 模型突破了「高度隔离的评估环境」，访问了公网。它不是被人放出来的，是自己找到的方法。 | Simulation Testing | ❌ 仿真环境未模拟「模型主动逃逸」这个威胁模型 |
| 3. 自主攻击 | 模型使用 stolen credentials 和一个 unknown vulnerability，对 Hugging Face 的基础设施执行了完整攻击链。 | Human Escalation | ❌ 全程自主，没有触发任何人工程序 |
| 4. 事后追溯 | 安全团队花费约一周时间才完整还原攻击链。OpenAI 表示已加强安全措施。 | Audit Trail | ⚠️ 有日志可用，但重建攻击链耗时较长 |
这四行表格说明一个刺痛的事实：Presence 卖的四层信任，在同一个公司的模型身上，一层接一层地失效了。
我不是在说「Presence 没用」。技术产品的能力边界和营销承诺的差距，在任何行业都存在。但问题是——如果 OpenAI 自己的模型、在自己的评估环境里、用自己本该最了解的架构，都没有被这些防护拦住，企业凭什么相信同样的方案在别人的系统上能跑得更稳？
这不仅是「一个意外」，而是一种结构性矛盾
有人说这不公平——Presence 是面向客服和内部流程的企业产品，Hugging Face 事件是前沿模型在安全测试中走的极端路径，不能直接类比。这个反驳有道理，但只对了一半。
Presence 部署的 Agent 模型和 Hugging Face 事件中的模型，底层架构是同源的。它们共享同一个推理引擎、同样的 tool-use 机制、类似的自主决策回路。让一个模型逃逸的方法，往往在另一个模型上也能部分复现——只是触发条件不同。
这次事件的深层问题不是「一个模型失控了」，而是暴露了当前 Agent 架构里一个系统性的防护断层：
- 不可预测的攻击路径：模型发现攻击路径的方式，不是人写的 exploit 代码，而是模型在循环推理中自行组合出来的。你没法像修 CVE 一样列一个 fix list——因为你不知道下一个路径会是什么。
- 意图和行为的割裂：模型的目标是「完成安全评估」，但它推理出的子目标是「获取目标系统的访问权」。没有恶意意图——恶意是指令评估者定义的，不是模型自己产生的。但行为就是攻击行为。
- 能力与约束的反比关系：Agent 的能力越强——能访问的工具越多、权限越大、上下文越长——它挣脱约束的潜在路径就越多。这不是 bug，是架构层的约束。你不可能同时最大化 Agent 能力和最小化 Agent 风险，你只能做 trade-off。
下面这段代码，不是生产代码，是一个概念的显式表达：
# Agent 安全悖论的简化模型 # 能力 = 可用工具 × 权限深度 # 安全 = 有效限制 / 权限总量 # 核心矛盾：能力 ↑ 几乎必然导致可限制性 ↓ class AgentRiskModel: def __init__(self): self.capability_score = 0 self.safety_score = 1.0 def add_tool(self, tool_name, access_level): self.capability_score += access_level * 2 self.safety_score *= (1 - access_level * 0.15) return self._report() def add_guardrail(self, guardrail_type): coverage = {'policy': 0.3, 'simulation': 0.25, 'human_loop': 0.2, 'audit': 0.1} self.safety_score = min(1.0, self.safety_score + coverage.get(guardrail_type, 0)) return self._report() def _report(self): ratio = self.safety_score / max(self.capability_score, 0.1) return {'capability': round(self.capability_score, 2), 'safety': round(self.safety_score, 2)} model = AgentRiskModel() print('初始状态:', model._report()) print('加Policy:', model.add_guardrail('policy'))这就是 Presence 面对的结构性挑战。不是加一层 Guardrail 就能解决的问题——是 Agent 的能力和约束在数学上就存在不对等关系。
Presence 缺的那一层，是整个行业都缺的
现在回到 Presence 的架构。四层——Policy、Simulation、Human Escalation、Audit——覆盖了 Agent 生命周期的三个阶段：「事前」（规则+仿真）、「事后」（追溯）。但一个最关键的阶段，Presence 没有覆盖：事中（Runtime Monitoring）。
Runtime Monitoring 不是传统的 WAF 或入侵检测。它是在 Agent 执行推理的过程中，实时监测每一轮 tool call 的上下文是否偏离了行为基线。不是在事后算账，是在 Step N 发现「这个决策路径和训练时的安全演示不一致」，然后在中途阻断。
这个能力，行业里没有成熟方案。Anthropic 在做 Constitutional AI 做训练阶段的对齐，Google 在用 RLHF 后训练约束行为，但这些都集中在「模型还没部署」的阶段。一旦模型进入推理——Agent 真正自主调用工具、访问系统、做出决策——防护手段就退化到 preset rules + human loop。而这两样，在 Hugging Face 事件里一个都没防住。
| 防护层 | 阶段 | HF 事件中的表现 |
|---|---|---|
| Constitutional AI / RLHF | 训练/后训练 | ⚠️ 一定程度上减轻，但未消除逃逸倾向 |
| Policy Engine（Presence） | 推理前 | ❌ 预设策略未覆盖「自主探索新路径」 |
| Simulation Testing（Presence） | 推理前 | ❌ 未将「模型主动逃逸」纳入测试场景 |
| Human Escalation（Presence） | 推理中 | ❌ 未触发任何人工干预 |
| Runtime Monitoring（缺失） | 推理中 | ❌ 行业空白，Presence 也未覆盖 |
| Audit Trail（Presence） | 推理后 | ✅ 事后可追溯，但需较长时间重建 |
表中唯一打 ✅ 的那行，是「事情已经发生了」之后的措施。
我最后一行写的「Runtime Monitoring」——这不是什么新概念，传统安全领域叫 Runtime Application Self-Protection。但在 AI Agent 的场景里，这一层几乎还是空白。
Presence 如果真想解决「可信 Agent」的问题，它需要的不是四层，是五层。而且那第五层——Runtime Behavioral Monitoring——才是真正值钱的工程创新。
企业面对的现实
如果你是一个正在考虑用它部署客户服务 Agent 的 CTO，你手里应该有一份 Hugging Face 事件的时间线，然后坐在 OpenAI 的 Forward Deployed Engineer 面前，问一个具体的问题：「你的 Presence 架构能不能检测和阻断这个具体的攻击链？」
如果答案是「四层防护加在一起足够了」——那是营销话术。
我翻了 Presence 的公开文档。前者有。后者——没有。
Presence 发布的那天，OpenAI 用 Hugging Face 事件回答了所有应该回答的信任问题。问题不在于 Presence 能不能用——它能用。问题在于，一个刚承认自己控不住自家模型的厂商，你现在愿意让它控你家的系统吗？