护栏
Guardrails
高级通用护栏（Guardrails）是在 AI Agent 执行任务时，对它能做什么、何时停下、哪些结果可接受设置的运行限制。它解决的是模型可能误解指令或越权行动的问题，例如让客服 Agent 在退款前先核对条件，并把超额退款交给人处理。
你可能会说：「我想让 AI 帮用户办事，但碰到退款、删数据这类操作时，先检查条件，不能自己直接做。」
动手看看鞋子订单退款护栏
1
顾客要退一双鞋，助手提出退款请求。请求必须先经过护栏，不能直接调用退款接口。
要点护栏怎样挡住不该发生的操作？
- 1
先划清能自动处理的范围
我们先列出 Agent 可以独立完成的事，以及需要停下来交给人的事。比如客服 Agent 可以查询订单和起草回复，但退款超过设定金额时，得等员工确认。
- 2
在执行动作的位置做检查
只在提示词里写「别乱退款」不够，因为模型可能理解错，也可能受用户输入干扰。把金额、订单状态和操作权限的检查放在退款工具调用前，拦截才不会只靠模型自觉。
- 3
拦下之后给出明确去向
护栏不只是返回失败。检查没通过时，我们可以让 Agent 解释缺少什么信息、请求用户补充，或提交给员工审批。这样既控制了风险，也让用户知道任务卡在哪里。
容易混淆的地方
护栏比权限控制更宽：权限控制回答「这个身份能不能调用退款接口」，护栏还会考虑金额、订单状态，以及是否需要人工确认。提示词可以告诉模型如何判断，但它本身不是可靠的执行限制；涉及真实操作时，还要由工具或后端检查。
什么时候用
适合用
- 做客服 Agent，允许它查询订单，但让退款和修改收货地址先经过条件检查。
- 做能操作后台的 AI 助手，让它批量删除记录前展示影响范围，并等待人工确认。
- 做代码 Agent，允许它读文件和运行测试，但把部署生产环境留给明确授权的步骤。
不适合用
- 只是做一张不接接口的聊天界面原型，用模拟消息展示交互即可，不必设计 Agent 的运行护栏。
- 普通注册表单要检查邮箱格式和必填项，用数据校验就够了，不必引入 Agent 护栏。
- 只是控制付费用户能否看到某项功能，用功能权益和权限控制，不必把它设计成 AI 行为护栏。
练一练选一个答案，看看解释
你在做客服 Agent：它能查订单，也能调用退款工具。用户要求退一笔超过自动处理额度的订单。哪种设计最能体现护栏？
让 AI 帮你做复制给 AI Agent 直接用
请为客服 Agent 设计退款护栏：先核对订单状态和退款金额，再决定是否调用退款工具；超过自动处理额度时停止执行，说明原因并提交人工确认。把检查放在工具调用前，不要只写在提示词里。