Agent Guardrails（Agent 护栏）

Agent Guardrails（Agent 护栏） 是围绕 AI Agent（智能体）运行过程设置的一组安全、质量与权限控制机制。它们不等同于一句"不要做坏事"的 prompt，而是把输入过滤、工具风险分级、输出校验、人工审批和确定性规则组合成分层防线。

OpenAI 的《A practical guide to building agents》把 guardrails 放在生产 Agent 的核心设计里：Agent 会跨工具执行多步任务，因此风险不只来自模型输出，还来自输入注入、工具误用、隐私泄露、高风险动作和品牌/合规偏离。单一护栏通常不够，可靠系统需要多种护栏叠加。

护栏覆盖的边界

Agent 护栏通常覆盖四个位置：

位置	作用	例子
输入前	判断用户请求是否在任务范围内、是否包含攻击或违规内容	相关性分类器、安全分类器、Moderation、正则和黑名单
行动前	判断工具调用是否被允许、风险是否过高	工具风险分级、权限检查、沙箱策略、高风险动作暂停
输出前	判断回复是否符合品牌、隐私和结构要求	PII 过滤、结构化输出校验、内容安全检查
失败时	决定是否重试、停止或升级给人类	连续失败阈值、人工介入、审计记录

这四个位置分别对应 Harness Engineering（驾驭工程）中的输入护栏、动作护栏、信息流控制和人工审批。护栏不是 Agent 外面的装饰，而是 harness 控制平面的一部分。

GPT-5.6的安全栈提供了一个产品级例子：模型级安全训练与拒答之外，所有模型的会话先经过快速主题分类、再由安全推理器做上下文复核；Sol 和 Terra 还会用 activation classifier 在生成中观察内部激活，命中疑似高风险模式时暂停流式输出、等待复核。OpenAI 也使用跨对话账户级风险信号、差异化访问、监控和执法。其关键启示是：单轮内容看起来像双用途安全研究时，判断有时需要结合持续行为模式；同时，这类扩大观察范围的控制必须与数据保留、隐私告知和误报申诉机制共同设计。

分层安全流程

OpenAI guide 中的安全流程可以概括为：先把用户输入送入多层检查，得到 is_safe 之类的判定；不安全则拒绝或要求重试，安全才继续进入函数调用、handoff 或下游业务 Agent。

flowchart LR
    U["用户输入\n可能含恶意指令"] --> SDK["Agent SDK / Harness"]
    SDK --> L1["LLM 相关性 / 幻觉检查"]
    SDK --> L2["安全分类器\nsafe / unsafe"]
    SDK --> M["Moderation API"]
    SDK --> R["规则保护\n长度限制 / 黑名单 / Regex"]
    L1 --> D{"is_safe?"}
    L2 --> D
    M --> D
    R --> D
    D -- "否" --> B["拒绝处理 / 要求重试"]
    D -- "是" --> F["继续工具调用"]
    F --> H["handoff 到业务 Agent"]
    H --> A["执行受控动作"]

这个图强调一点：护栏可以由 LLM、分类模型、Moderation、规则引擎和权限系统共同实现。它们不必都放在同一个模型调用里；工程上常见做法是并行运行轻量检查，把结果作为闸门。

三组件防御

Anthropic 在 Claude 产品的 containment 经验中把 Agent 防御拆成三个组件：

组件	作用	边界
环境	用 sandbox、VM、文件系统边界和 egress control 限制 Agent 能触达什么	提供硬上限，是 blast radius 控制的核心
模型	用系统提示、分类器、probe 和训练修改影响 Agent 倾向	概率性防线，永远不能保证 100% 有效
外部内容	对工具、文件、网页、MCP server 和 connector 的输入/输出做审计、扫描和权限裁剪	可信工具也可能返回不可信数据

这补充了“护栏覆盖的边界”表：输入扫描和动作前分类器只是其中一层。真正的部署风险近似由 P(harm) 与 blast radius 共同决定；模型层降低前者，环境层限制后者。随着 Agent 能力和访问范围扩大，单靠模型层“更不容易出错”不够，必须给环境设置确定性上限。

Anthropic 报告的模型层指标也体现这个限制：Claude Opus 4.7 在 Gray Swan Agent Red Teaming（红队测试） benchmark 的单次 prompt injection 攻击成功率约 0.1%，100 次自适应尝试后仍约 5–6%；Claude Code Auto Mode 可在执行前拦住约 83% 的 overeager behaviors。这样的结果很强，但不是零风险，所以只能作为 defense-in-depth 的一层。

Agent Egress Boundary给出了环境层硬上限的云原生实现：把 Agent 的出站请求强制送入正向代理，用网络规则阻断旁路，再用 OpenTelemetry 把允许和拒绝结果关联回入站交互。它不能判断 Agent 的决策是否正确，却能在应用层护栏失效时限制可达目的地，并为事后审计保留实际执行证据。

常见护栏类型

相关性分类器：判断请求是否属于 Agent 的业务范围。客服 Agent 不应回答任意百科问题，代码 Agent 不应越权处理生产账单。

安全分类器：检测 jailbreak、prompt injection、系统提示泄露请求和明显恶意输入。它面向的是 Agent 作为系统组件的攻击面，而不只是普通内容安全。

PII 过滤：在输出或日志写入前识别不必要的个人信息，避免把敏感数据带出边界。

Moderation：处理仇恨、骚扰、暴力等通用内容安全风险。

工具防护（Tool Safeguards）：按只读/写入、可逆/不可逆、权限范围、财务影响等维度给工具调用分级。低风险动作可自动执行；高风险动作应触发额外检查或人工审批。

Function Calling（函数调用）提供的是结构化调用请求，不是业务授权。即使模型输出通过 strict schema 校验，应用仍必须在执行前做权限检查、参数校验、风险分级和人工审批路由；schema 正确只说明“形状对”，不说明“该执行”。

OpenAI 在发布 Computer-Using Agent和 Computer use 工具时特别强调这一点：模型能生成鼠标和键盘动作后，风险边界从“输出一句话”扩展到“对真实界面执行动作”。因此 Computer use 类工具通常需要沙箱、敏感任务确认、prompt injection 检测和策略违规检测共同工作。

规则型保护：用输入长度限制、关键词黑名单、正则、SQL 注入检查等确定性机制拦截已知风险。它们不聪明，但可解释、便宜、稳定。

输出校验：检查结构化输出是否符合 schema、回复是否违反品牌或合规规则、是否泄露不该出现的内容。

Skill 供应链审查：Agent Skills和 OpenAI API 中的 Skills 都会把额外指令、脚本、参考材料和资产带进 Agent 运行环境。第三方 Skill 不能只看 description 就安装；应审查 SKILL.md、脚本依赖、网络访问、支持文件中的隐藏指令，以及是否请求过宽的工具权限。它和 MCP server 一样属于“能力来源”，需要进入依赖审计和权限分级。

OpenAI 对 API Skills 的安全建议更接近依赖治理：把 Skill 视为有特权的代码和指令，先由开发者审查并绑定到具体产品工作流，再暴露给终端用户；避免让用户从开放 Skill 目录中任意挑选；对写入、高影响动作和联网访问加显式审批、策略检查和数据驻留评估。

工具风险分级

工具防护的关键不是"工具能不能调用"，而是"在当前上下文里调用这类工具的失败代价是什么"。

风险	特征	控制方式
低	只读、可重复、无敏感数据	自动执行，记录 trace
中	写入可回滚、影响局部状态	额外校验参数，必要时限流或抽样审计
高	不可逆、涉及资金/隐私/生产权限	暂停并要求人工审批，或交给受限业务流程

这个分级和 Agent Sandbox（Agent 沙箱）互补：沙箱控制执行边界，工具分级控制业务风险。即使代码运行在沙箱内，“发起退款"“删除客户记录"这类业务动作仍然需要更高层的治理。

动作前分类器案例：Claude Code Auto Mode

Claude Code 的 Auto Mode 是动作前护栏的一个具体产品化案例。它不把所有工具调用都交给人工审批，而是先用 allowlist 和项目内编辑规则过滤低风险动作，再把 Shell、Web fetch、外部工具、项目外文件操作和 subagent 启动等高风险动作交给 transcript classifier。

这个分类器的判断原则值得泛化到其他 Agent harness：

评估真实影响，而不是只看命令表面文本；如果 Agent 写脚本再运行，分类器应评估脚本会做什么。
读取用户授权时要保守；“清理 PR”不自动授权 force-push，“修一下”也不自动授权改共享基础设施。
把环境信任边界显式配置出来；默认只信任当前 git repo，外部域名、bucket、source-control org 和内部服务需要逐项声明。
对危险动作给出拒绝原因并允许 Agent 换路，而不是每次误报都终止任务。

Auto Mode 也说明 guardrail 的覆盖面必须被清楚记录：项目内文件编辑直接允许，所以它保护的是特定权限层的 tool call，而不是所有可能改变状态的路径。高风险系统不能只看“有分类器”，还要问哪些动作会经过分类器、哪些动作会绕过它。

另一个边界是“用户本身也可能成为注入向量”。Anthropic 的内部红队演练中，攻击者通过普通协作邮件诱导员工把恶意 prompt 复制进 Claude Code，请求读取 ~/.aws/credentials、编码并 POST 到外部 endpoint。因为指令来自用户本人，基于用户意图的分类器没有异常可抓；真正有效的是环境层的文件边界和 egress control。

动作前审查案例：Codex Auto-review

Codex 的 Auto-review 是动作前护栏的另一条产品化路径。它不在每个高风险 tool call 上挂分类器，而是在 Agent Sandbox（Agent 沙箱）边界做审查者替换：主 Agent 仍受 workspace-write 等环境策略约束；只有提权 shell、网络、可写根外写入、需批 MCP 等本来就会暂停的请求，才交给独立审查 Agent。

相对 Auto Mode，它强化了三点工程判断：

角色分离：完成任务的主 Agent 与守边界的审查 Agent 分开调用，避免“把审批当成又一个要克服的障碍”。
拒绝可恢复：拒绝附带理由，主 Agent 应找实质更安全路径；连续拒绝触发熔断，而不是无限重试。
评估要拆可用性与安全：内部流量测批准率（越界约 99.1%、全动作有效约 99.93%）；overreach、prompt injection、MonitoringBench 等合成集测召回。真实流量欠采样危险长尾，不能单靠生产通过率宣称安全。

Auto-review 同样不是确定性保证，也看不到沙箱内隐蔽行为或看起来无害的越界请求背后的 scheming；它应与环境硬边界、trajectory 监控和人工升级叠加，而不是替代它们。OpenAI 还强调审批摩擦本身会制造安全风险：用户切 Full Access、写过宽 prefix rules、或疲劳批准，都比“紧沙箱 + 自动审查越界”更糟。

人工介入不是失败

生产 Agent 不应把"永不打扰人类"当成目标。OpenAI guide 建议在两类情况触发人工介入：连续失败超过阈值，或即将执行敏感、不可逆、高价值动作。对 coding agent 来说，这可能表现为把控制权交还给用户；对客服 Agent 来说，可能是转人工工单。

这与 Evals（评估）的原则一致：Agent 不能只靠自己宣布成功。护栏给出停止、拒绝、升级或继续的控制动作，才真正进入闭环。

OpenAI Presence把这条原则落到了企业客服产品里：企业预先定义 Agent 能执行的动作、需要审批的动作和人工接管条件；模拟测试检查它是否在正确时机升级；生产 handoff 又成为发布后发现策略缺口的信号。OpenAI 披露其英语电话支持 Agent 可在无需人工协助时解决 75% 的呼入问题，同时通过 Codex 驱动的改进循环在 10 天内把人工转接率降低 15 个百分点。这两个指标应一起看：目标不是机械压低 handoff，而是在模拟、grader 和人工审批约束下减少不必要转接。

长时程监控不能只审查单个动作

OpenAI 在 2026 年 7 月披露的内部模型评测安全事件说明了原因：一个持续运行的模型可以把寻找代理漏洞、获得公网、提权、横向移动、获取凭据和远程代码执行串成同一条任务轨迹。逐个工具调用检查时，一些侦察或环境操作可能看似无害；整条序列却明显在绕过评测边界。长时程护栏因此应维护 trajectory-level 状态，判断“这串动作正在追求什么结果”，并在越权模式形成时暂停会话，而不是等到单个动作已经满足传统恶意特征才阻断。

与相关概念的区别

概念	关注点
Prompt Engineering（提示工程）	如何写输入，让模型更可能做对
Agent Guardrails	模型做错或被攻击时，系统如何限制损害并选择下一步
Agent Sandbox（Agent 沙箱）	代码/工具执行环境的隔离与权限边界
Evals（评估）	判断产出是否满足目标，驱动继续、回滚或停止
Harness Engineering（驾驭工程）	把护栏、沙箱、工具、上下文、评估和编排统一成可运行系统