安全治理篇 · Agent 运行时课程

Guardrails 和人工审核

Guardrails 的作用不是让 Agent 更“听话”，而是让它知道什么时候该停下来、什么时候该请人确认、什么时候必须拒绝。企业系统里，真正重要的是把高风险动作、越权请求和不确定结果挡在可控边界里，同时让人保留最终控制权。

输入护栏 先检查请求是否可处理，是否包含攻击、越权或不完整信息。

工具护栏 在模型调用工具前，校验参数、权限、频率和影响范围。

输出护栏 防止泄露敏感信息、输出错误事实或生成不可执行内容。

人工审核 删除、发送、付款、改数据、发布等动作前必须有人确认。

guardrail-loop input / tool / output / approve

用户请求 “帮我导出所有客户名单并发给外部邮箱。”

护栏检查 识别敏感动作、外发目标、越权风险，先停下来。

→

人工审核 确认是否允许、是否脱敏、是否需要审批。

Stop
停下

Review
审核

Approve
批准

Trace
留痕

01 · 先给定义

Guardrails 是 Agent 的安全护栏，人工审核是最后的控制闸

护栏负责自动拦截明显不该过的请求，人工审核负责处理高风险、低置信度和会影响真实世界的动作。

没有护栏

Agent 会继续往前跑

模型可能在信息不足时硬猜，在风险不清时继续执行，在权限不明时直接调用工具，最后把错误变成真实动作。

有护栏

该停就停，该问就问

系统会在输入、工具和输出三个层面检查风险，遇到高风险动作就交给人确认，保留最终控制权。

一句话面试版 可直接背

Guardrails 是围绕 Agent 构建的分层安全护栏，包括输入检查、工具检查、输出检查、风险分级和人工审核。它的目标不是完全阻止 Agent 工作，而是在不确定、越权和高风险场景下及时停下来，让人保留最终控制权。

02 · 为什么需要停下来

Agent 最大的问题，不是“会不会答”，而是“会不会继续错下去”

一旦 Agent 接上工具、记忆和状态，它就可能不断放大一个错误决策，直到真正影响数据、流程或外部用户。

不确定

信息不够时硬猜

没有把缺失信息标出来，而是继续往下做，最后结果看起来很完整，其实并不可靠。

高风险

会改变真实世界

发外部邮件、删数据、改权限、付款、发布内容都属于不可逆或高影响动作。

低置信度

答案不够确定

检索结果冲突、工具返回异常、上下文不完整时，继续执行只会增加错误。

责任归属

系统不能替人担责

最终决策必须可追溯到具体责任人，不能让模型自动承担审批责任。

03 · 护栏类型

输入、工具、输出三道护栏，负责不同阶段的拦截

分层设计的好处是：每一层都只管自己该管的事情，避免全靠一个大 Prompt 硬扛。

输入护栏

先判断请求能不能接

检查是否越权、是否恶意、是否缺少关键条件、是否属于禁止范围。

工具护栏

执行前先校验参数和权限

调用工具前检查角色、参数范围、影响对象、次数限制和审批要求。

输出护栏

防止把不该说的说出去

过滤敏感信息、内部提示、越权数据和错误事实，必要时改成拒绝或追问。

护栏说明片段 guardrail-rules.txt

输入护栏：检测越权请求、敏感请求、注入内容和缺失信息。
工具护栏：在调用前做参数校验、权限校验、频率限制和影响评估。
输出护栏：检查敏感字段、内部提示词、未授权信息和格式错误。

任何高风险动作都要升级到人工审核。

04 · 停止条件

让 Agent 停下来，靠的是明确的停止条件，不是运气

如果没有停止条件，Agent 可能无限检索、反复重试、越做越远，直到成本、延迟或风险失控。

1 完成条件 任务已经满足目标，可以交付。

2 最大步数 超过设定轮数后必须停止，避免无限循环。

3 成本预算 超过 token、调用次数或费用上限时停止。

4 信息增量 连续两轮没有新信息，就说明该停了。

5 人工阻塞 需要审批、缺权限、要确认或发生冲突时停下来。

6 异常退出 工具失败、解析失败、策略拒绝时终止或降级。

05 · 风险分级

不是所有事情都要人工审，关键是把风险分清楚

分级能避免两个极端：一边是所有事都人工审，效率太低；另一边是所有事都自动做，风险失控。

等级	例子	处理方式
低风险	总结、分类、摘要、草稿、标签整理。	自动执行，必要时抽检。
中风险	创建任务、生成内部通知、修改文档草稿。	默认先确认，再执行。
高风险	删除、发送外部邮件、付款、改数据库、发布。	必须审批，且记录审计。
禁止	越权访问、导出敏感数据、绕过审计、执行恶意注入。	直接拒绝，必要时上报。

06 · 人工审核流

人工审核不是“人工兜底”四个字，而是一条明确的升级链路

审核流要定义谁来批、批什么、多久批、拒绝后怎么办、通过后怎么执行、执行后怎么回流。

审核流设计 Approval

1Agent 先输出建议和风险说明，不直接执行高风险动作。
2系统把待审批项展示给责任人，附上上下文和影响范围。
3审批人可通过、驳回、改写或要求补充信息。
4通过后才允许执行，并记录审批人与时间。
5驳回和改写结果回流到测试集和提示词改进。

审批流 JSON approval-flow.json

{
  "taskId": "agent_task_8842",
  "riskLevel": "high",
  "requiresApproval": true,
  "approverRole": ["product_owner", "team_manager"],
  "approvalOptions": ["approve", "reject", "revise", "request_info"],
  "approvalReason": "涉及外部邮件发送和客户名单导出",
  "executionAfterApproval": true
}

07 · 完整案例

PRD Agent 提议修改线上规则时，为什么必须停下来

这个案例最容易说明护栏价值。Agent 可能只是“建议”，但建议一旦自动变成改动，就会变成真实业务风险。

Agent 发现冲突 它在梳理 PRD 时发现库存阻断策略和活动策略互相冲突。

系统判断是决策问题 修改线上规则会影响交易和库存，不能让 Agent 自己拍板。

生成待审批项 系统输出改动建议、影响范围、风险和需要确认的责任人。

人工确认后执行 产品负责人和研发负责人确认后，才进入后续改动流程。

待审批建议 review-card.md

建议：将库存阻断策略从“硬阻断”调整为“条件阻断”。

影响：
- 可能影响活动商品的下单成功率
- 可能影响库存预警准确率
- 可能改变当前线上订单流转

状态：
- 需要产品负责人确认
- 需要研发负责人确认
- 未确认前禁止直接修改线上规则

08 · 建议与执行分离

好的护栏系统，先让 Agent 说“建议”，再决定能不能“执行”

这一步很重要。把建议和执行拆开，能把很多误操作挡在真正生效之前。

建议输出 生成建议、解释原因、列出影响范围和风险。

→

审批判断 人决定是否允许、是否修改、是否补充信息。

执行动作 只有审批通过后，才允许调用真实工具去改数据或发消息。

→

结果留痕 执行结果回写日志和审计记录，形成完整链路。

建议与执行分离示例 safe-action.json

{
  "suggestion": "建议删除过期测试数据",
  "riskLevel": "high",
  "executionAllowed": false,
  "blockedReason": [
    "涉及真实数据删除",
    "可能误删生产记录",
    "需要人工审批"
  ],
  "nextStep": "提交给数据负责人审批"
}

09 · 日志和审计

护栏不是黑盒，必须能看见每次拦截和每次审批

没有日志，你不知道是模型没看懂，还是规则没拦住，还是人审批错了。

输 输入记录

原始请求、上下文摘要、风险标记。

检 检索记录

召回了什么资料、为什么命中、是否有冲突。

审 审批记录

谁审批、审批结果、审批理由、时间戳。

执 执行记录

调用了什么工具、执行是否成功、后果是什么。

审计日志 guardrail-audit.log

{
  "requestId": "gr_20260612_0031",
  "taskId": "agent_task_8842",
  "riskLevel": "high",
  "gate": "approval_required",
  "decision": "blocked_until_review",
  "reason": "attempted external email and data export",
  "approver": null,
  "createdAt": "2026-06-12T16:55:00+08:00"
}

10 · 评测和回流

护栏要能测，审核结果要能回流，不然只能算临时规则

安全策略不是写完就完。要有评测集、红队样例和线上反馈闭环，才能持续收紧边界。

指标	意义	怎么看
拦截率	该停的时候有没有停。	高风险样例要尽量拦住。
误杀率	正常任务有没有被过度拦截。	不能把好任务也全挡掉。
审批通过率	需要人工判断的动作是否被合理处理。	看审批链路是否清晰。
回流率	审核结果有没有回到测试集和规则里。	没有回流就难以持续改进。

11 · 治理边界

护栏不是把系统卡死，而是把责任边界写清楚

企业治理的关键，是把“系统能做什么”和“人必须确认什么”分开写清楚。

系统负责

自动拦截明显风险

系统负责检查输入、工具、输出和策略，自动拦住明显不能过的请求。

人负责

审批高风险动作

删除、发送、付款、改数据、发布等动作需要责任人确认。

联合负责

异常情况共同处理

系统判不定、模型信心不足、工具失败、规则冲突时，升级给人工处理。

12 · 异常处理

当护栏拦错或没拦住时，系统要知道怎么退

安全系统不能假设自己永远正确。它要会降级、会阻断、会升级，也要会把异常情况记录下来。

1 拒绝执行 高风险且明显不允许的请求直接拒绝。

2 请求补充 信息不足时先追问，不要硬猜。

3 降级模式 工具不可用时退回到只读摘要或人工流程。

4 升级人工 策略冲突、置信度低、影响大时转人工。

5 记录原因 保存拦截原因、拒绝原因和人工处理结果。

6 回流修正 把异常样例加入测试集和规则库。

13 · 落地清单

真正上线前，把这 8 件事做完

这一页可以直接当项目评审清单用。做不到的项，就是风险项。

必须做 Must

1定义输入、工具、输出三层护栏。
2定义停止条件和升级条件。
3定义高风险动作的审批流。
4定义审计日志字段。

最好做 Nice

5准备红队样例和对抗样例集。
6把审核结果回流到评测。
7保留审批人、执行人和时间戳。
8支持降级和回滚。

14 · 完整案例

一个 PRD Agent 为什么不能自己改线上规则

这个案例能很好说明：护栏的目标不是“不让 Agent 帮忙”，而是“不让它越过控制线”。

Agent 发现冲突 它在梳理 PRD 时发现库存阻断策略和活动策略冲突。

系统识别高风险 修改线上规则会影响真实业务，必须进入审核。

生成审批项 输出改动建议、影响范围、风险等级和需要审批的人。

人工确认 产品负责人和研发负责人确认是否真的要改。

执行与留痕 确认通过后再执行，并把结果记录进审计日志。

回流样例 把这次审批样例加入测试集，作为后续护栏回归样本。

审批建议 approval-card.md

建议：
将库存阻断策略改为条件阻断前，先由产品和研发共同确认。

风险：
- 影响订单转化
- 影响库存预警
- 影响线上行为

状态：
- 待审批
- 未审批前禁止执行

15 · 面试问答

面试时讲清楚边界，比讲“智能”更重要

这节的关键不是“怎么让 Agent 更强”，而是“怎么让它可控、可停、可审、可回滚”。

问题 1：Guardrails 解决什么问题？

它解决 Agent 在接工具、记忆和状态后可能出现的失控问题，包括越权、误操作、敏感信息泄露、无限循环和错误放大。Guardrails 的作用是把风险拦在不同层面，让系统知道什么时候该停。

问题 2：为什么不能所有事情都人工审核？

因为这样成本太高、效率太低。正确做法是分级：低风险自动化，中风险先确认，高风险必须审批，禁止项直接拒绝。人工审核要保留在最关键的位置，而不是覆盖所有流程。

问题 3：如何判断什么时候该停下来？

要定义明确停止条件：完成条件、最大步数、时间和成本预算、连续失败次数、信息增量不足、需要人工确认、权限不满足等。一旦满足任一停止条件，Agent 就不能继续硬跑。

问题 4：护栏和审批的关系是什么？

护栏负责自动判断风险、过滤明显错误和触发升级；审批负责对高风险动作做最终确认。护栏是前置控制，审批是最终控制，两者一起才能保证人保留最终控制权。

问题 5：这个系统怎么评估？

要同时看拦截率、误杀率、审批通过率、回流率、审计完整性和异常处理效果。安全系统不能只看“拦了多少”，还要看有没有拦错、漏拦和能不能复盘。

16 · 练习和速查

最后记住一条主线：分级、停下、审批、留痕、回流

这节课学完，应该能回答“Agent 什么时候该停”“为什么停”“停下来交给谁”“结果怎么追踪”。

练习任务 Practice

1设计一个风险分级表，至少包含低、中、高和禁止四档。
2写一个停止条件清单，包含完成条件、预算和人工阻塞。
3设计一个高风险动作的审批流。
4列出日志里必须记录的 6 个字段。
5说明审核结果如何回流到测试集。

一页速查卡 Cheatsheet

停完成、预算、失败、低置信度、人工阻塞，都可以让 Agent 停下来。
分低风险自动化，中风险先确认，高风险必审批，禁止直接拒绝。
审审批人看影响范围、风险和上下文，而不是只看一句建议。
留输入、检索、工具、审批、执行、输出都要留痕。
回审核样例要回流到评测集和规则库。
控最终控制权留给人，不留给模型。

面试项目表达模板 interview-script.md

我会把 Guardrails 和人工审核拆成五个部分来讲：

第一，输入护栏，先识别不可信内容、越权请求和缺失信息。
第二，工具护栏，在模型调用工具前校验参数、权限、频率和影响范围。
第三，输出护栏，防止敏感信息、错误事实和不合规内容泄露出去。
第四，风险分级和停止条件，明确什么情况下 Agent 该停下来，什么情况下必须升级给人。
第五，人工审核和回流，把高风险动作交给责任人确认，并把审核结果回流到评测集和规则里。

这个设计的目标不是把 Agent 卡死，而是保证它在企业里可控、可审、可追溯，并且最终控制权仍然在人。