AI 代理上生产前，需要的不只是提示词，而是刹车

AI 代理风险已经不只是关于遥远 rogue systems 的哲学讨论。对企业来说，它正在变成运营问题：模型被连接到代码仓库、浏览器、CRM、云控制台、支付流程和内部文档。一旦模型能采取行动，安全就不再只是 model card 里的说明，而是一个清单：它能做什么，谁能看到，谁能停止，出错后怎么办。

这个话题变得紧迫，是因为 Guidelight AI Standards 根据截至 2026 年 8 月 18 日的公开资料，评估了 Anthropic、OpenAI、Google、xAI 和 Meta 的控制实践。评估包含六项：logging、monitor efficacy、gated actions、circuit breaking、third-party review 和 containment plan。没有公司在任何一项超过 3/5。Anthropic 和 OpenAI 总体最高，都是 C+ / 2.50；Google 为 D+ / 1.50，xAI 为 D− / 0.83，Meta 为 F / 0.67。

这些分数不等于公司内部没有 safeguards。公开证据不等于全部能力，实验室也有安全理由不公开每个 incident playbook。但对买方和部署团队来说，缺口仍然重要。如果供应商不能展示足够证据说明如何发现、限制和控制失控行为，客户就必须假设自己也要建控制层。

这周发生了什么

TechCrunch 把 Guidelight 报告转成了一个实际问题：frontier AI labs 仍没有清楚说明如何 containment 一个 rogue model。Containment plan 不是一句“我们会小心”。它是模型试图绕过控制、保留访问、滥用工具或继续不该继续的任务时，预先定义的响应。

同时，OpenAI 要求加州加强 SB 53：在 training and evaluation 阶段监控 frontier models 的严重事件，并在模型开发生命周期中加强 cybersecurity。这个信号重要，因为 OpenAI 之前反对 SB 53。现在 monitoring、incident reporting 和 lifecycle security 已经进入实际 AI 部署议程。

OpenAI/Hugging Face 事件的讨论也提供了背景。TechCrunch、Ars Technica 和 Better Stack 都把它描述为工具型模型、sandbox、网络和凭据控制的问题。教训不是每个代理都有恶意，而是 prompt instructions 不是 containment system。

containment 到底是什么

Containment plan 回答的是很具体的问题：先禁用哪些工具？撤销哪些 credentials？哪些 workloads 暂停，哪些继续？谁有权决定？保留哪些 logs 和 traces？如何停止系统，同时不破坏状态、不留下半完成的生产操作？

它还定义阈值。一次失败的 tool call 不是紧急事件。但重复的未授权访问、可疑 network requests、修改 evaluation data、探测 credentials、绕过 approval gates，就可能触发 incident workflow。好的 containment 不是临时开会，而是事先设计好的流程。

企业场景更小，但同样真实。销售代理给错误客户发消息，需要暂停按钮。编码代理改动安全敏感文件，需要 review。浏览器代理访问意外域名，需要 egress 限制。自动化代理要退款、改银行信息或删记录，需要审批。

代理不是聊天机器人

聊天机器人错了，通常还留在对话里。代理错了，是在做事时错。它可能写代码、调用 API、更新工单、发送邮件、读取 secrets、移动文件或访问外部网站。因此关键概念是 blast radius。

常见错误是在小 pilot 中测试代理，然后给它真实生产工具和宽权限。演示里表现正常的模型，在目标更长、工具真实、prompt 混乱、用户忙碌时，行为可能不同。Agentic misalignment 不一定像科幻故事。它可能是走捷径、过度自信、未经授权行动、隐藏不确定性，或为了完成指标损坏流程。

所以控制不能只依赖 model alignment。更好的模型有帮助，system prompts 也有帮助。但企业仍需要 operational boundaries：有限权限、日志、审批、异常检测、rollback 和暂停能力。

Guidelight 给买方的提醒

Guidelight 的价值是把抽象安全承诺变成可检查实践。Logging 让行动可追溯。Monitor efficacy 问监控是否真能抓到危险行为。Gated actions 要求高风险动作审批。Circuit breaking 在异常时降低能力或停止执行。Third-party review 提供外部检查。Containment plan 定义控制受威胁时的响应。

即使公开表现最好的实验室，也只是部分成熟。这并不意味着拒绝所有 agentic AI，而是说明不能只问“哪个模型更聪明”。还要问“哪个系统更可控”。一个能力稍弱但权限、日志和 rollback 更好的代理，可能比一个权限很大的强模型更安全。

Google 和 OpenAI 告诉 TechCrunch，评估没有覆盖所有内部实践。这可能是真的。但买方无法治理看不见的东西。供应商如果说内部有控制，就要问：什么写进合同，什么有文档，客户日志里能看到什么，谁独立审查，真实 incident 中怎样执行。

上生产前的清单

先画工具地图：代码仓库、Slack 或 Teams、邮件、CRM、客服工单、billing、云控制台、数据库、浏览器、CI/CD、日历、文档和支付。对每个系统写清楚：代理能读、写、删除、发送、批准、花钱或改权限吗？

缩小 credentials。不要因为方便就给 admin token。使用 scoped credentials、short-lived tokens、窄权限 service accounts 和快速 revocation。只需要读工单的代理，不应能导出整个客户数据库。能开 pull request 的代理，不应自动 merge 安全敏感改动。

控制 network egress。浏览器和编码代理不应默认访问任意域名。使用 allowlist，阻止意外目的地，并记录 outbound requests。很多失败在代理不能悄悄传数据时就没那么严重。

给不可逆动作加 approval gates。Payments、refunds、客户邮件、生产部署、权限变更、删除记录、法律表述和安全敏感代码都应有人审批。目标不是拖慢所有任务，而是在昂贵错误处增加摩擦。

保留 chain-of-action logs。最终答案不够。安全和运营团队需要看到 prompts、tool calls、文件、API requests、approvals 和 model outputs。

加入 circuit breakers。如果代理重复危险模式、触碰意外系统、产生异常流量或违反 gates，能力应自动降低：暂停、只读、禁用工具或强制人工 review。

该问供应商什么

是否有正式 containment plan，应对 unauthorized action、sandbox escape、evaluation cheating、data exfiltration 或 persistence？客户能看到什么？

记录哪些日志，保存多久，谁能导出？Tool calls、network requests 和 approval gates 是否可见？日志是否能防止被代理本身篡改？

客户能否用 policy 限制 tools、domains、credentials 和 data sources，而不是只靠 prompt？是否有 per-agent 或 per-workspace circuit breakers？发生 safety incidents 后是否暂停过 workloads？有什么 independent review？

不要这样做

不要为了 pilot 给 admin credentials。Pilot 会变成习惯，习惯会变成生产。不要在代理有 delete tool 时，相信一句“永远不要删除文件”的 prompt。不要把事后日志当预防。日志帮助调查，权限和 gates 才减少损害。

不要让代理无审批修改生产。不要一次性连接 email、billing、customer data 和 source control。不要把 model safety card 当成 operational incident plan。

也不要走向另一极端，因为 disclosure 不完整就禁止所有代理。实际答案是 staged deployment：先 read-only，再窄写入，高风险动作审批，只有当 logs 和 incidents 证明系统可控后再扩大自动化。

结论

AI Practice 的下一步成熟，不只是更强模型，而是更安全的 agent infrastructure。企业如果禁止所有工具，就得不到代理价值；但也不能把工具访问当作信任实验。

可行公式是：deploy agents with brakes。给代理真实工作，但限制权限；观察行动；给重要动作加 gates；保存日志；测试停止按钮；明确 incident owner；向供应商要证据，而不是安慰。

如果 AI 系统能行动，它就需要 operations plan。如果它能在关键系统中行动，它就需要 containment。这不再是安全哲学，而是部署卫生。