Agent产品的安全护栏并非简单技术风控，而是产品设计的核心环节。本文深入剖析Agent安全性的本质挑战：从基础准确性提升到风险分层设计，从三层护栏构建到动态路由机制，揭示真正可靠的Agent产品如何通过精细化的边界设计，在能力与安全间取得平衡。

过去一年，很多团队做 Agent 产品时，最容易陷入一个误区：一上来就讨论“怎么拦截”“怎么审核”“怎么防越狱”。

但真正进入生产环境后你会发现，Agent 的安全问题不只是技术风控问题，而是一个完整的产品设计问题。

一个 Agent 会不会出事，不只取决于模型够不够强，也取决于产品经理有没有提前定义清楚：它能做什么、不能做什么、什么时候需要确认、什么时候必须交给人。

换句话说，Agent 的安全护栏，不是上线前临时加的一层“保险丝”，而应该是产品能力的一部分。

一、先别急着加护栏，先提高 Agent 的基础准确性

很多人理解的安全护栏，是在模型输出后做拦截。

比如发现敏感词就挡掉，发现格式不对就重试，发现回答危险就转人工。这当然有用，但它解决的是“结果已经偏了以后怎么补救”。

对 Agent 产品来说，更前置的问题是：为什么它会偏？

如果 Agent 拿到的知识不准、检索结果不相关、任务拆解混乱、工具调用没有边界，那么再多护栏也只是亡羊补牢。

所以，设计 Agent 护栏的第一步不是“加墙”，而是先提高它的原生准确性。

产品经理至少要关注三件事：

第一，知识是否可靠。

Agent 不能只靠大模型的通用记忆回答业务问题。它需要有明确的知识来源，比如产品文档、政策文件、CRM 数据、订单数据、FAQ、合同条款等。并且这些知识要经过合理切分、索引、召回和排序。

第二，推理过程是否可控。

复杂任务不能让 Agent 一步到位地“自由发挥”。例如“帮我分析客户流失原因并生成挽回方案”，应该拆成：读取客户数据、识别行为变化、匹配流失原因、调用策略库、生成建议、检查合规风险。每一步都可以被验证。

第三，输出是否有证据。

凡是涉及事实、规则、价格、权益、政策的回答，都应该能追溯来源。不能证明的内容，就不应该被 Agent 当成确定结论说出来。

对 AI 产品经理来说，这里有一个很重要的判断：安全不是只靠拦截实现的，很多安全问题本质上是准确性问题。

二、不是所有 Agent 都需要同样重的护栏

另一个常见误区是：把所有 Agent 都按最高风险标准设计。

这会带来两个问题：一是用户体验很慢，二是研发成本很高。最后团队会发现，Agent 没出大事故，但也没人爱用。

更合理的做法，是按风险分层设计护栏。

比如一个内部知识库问答 Agent，员工问“年假怎么申请”，它的风险相对较低。即使回答不完整，也可以补充纠正。

但如果是一个金融顾问 Agent，用户问“我该不该买这只基金”，风险就完全不同。它可能影响真实交易，也可能触碰监管红线。

所以，产品经理在设计 Agent 时，要先给场景分级，而不是直接讨论技术方案。

可以简单分成三类：

低风险场景：内部 FAQ、普通知识查询、低敏感度信息总结。

这类场景优先保证响应速度，可以允许流式输出，同时在后台做异步检查。

中风险场景：客服咨询、商品信息、售后政策、普通业务办理。

这类场景需要在输出前做基础校验，比如敏感信息、话术边界、格式规范、品牌语气等。

高风险场景：医疗、金融、法律、人事、支付、审批、外部发信、数据修改。

这类场景必须做完整校验，必要时引入人工确认，不能让 Agent 直接闭环执行。

这里的关键不是“Agent 能不能做”，而是“Agent 做到哪一步必须停下来”。

三、三层护栏：规则、分类器、语义校验

如果把 Agent 护栏拆成产品能力，可以分成三层。

第一层是规则型护栏。

它适合处理明确、稳定、可枚举的问题。例如手机号、身份证、邮箱、银行卡、字段格式、长度限制、必填项、禁用词、接口参数等。

这层护栏的好处是快、便宜、确定性强。只要能写成规则，就不要交给大模型判断。

第二层是模型分类护栏。

它适合处理规则难以覆盖，但又有明显模式的问题。例如辱骂、歧视、越狱提示、情绪异常、品牌语气不一致、是否偏离业务范围等。

这层更像内容风控和意图识别，适合在客服、社区、营销、销售辅助等场景使用。

第三层是大模型语义校验。

它适合处理高风险、强上下文、需要专业理解的问题。例如回答是否有依据、是否和知识库一致、是否给出了不该给的医疗建议、是否把“法律信息”包装成了“法律意见”。

这层最贵，也最慢，所以不应该滥用。它应该被放在高风险任务、关键节点、不可撤回操作之前。

一个成熟的 Agent 产品，不是所有请求都走最重流程，而是根据风险动态选择护栏强度。

四、产品经理要设计“风险路由”，不是只写异常提示

Agent 产品真正难的地方，在于它不像传统软件那样路径固定。

用户一句话可能只是闲聊，也可能触发查询、生成、审批、下单、发邮件、改数据。产品经理需要设计一个“风险路由”机制。

可以让系统先判断这次请求的风险分数，再决定走哪条路径。

判断维度包括：

• 用户在问什么：是否涉及钱、健康、法律、隐私、权限、外部承诺。
• 用户是谁：普通用户、内部员工、管理员、未授权访客。
• Agent 要操作什么：只是回答，还是要调用工具、修改数据、触发交易。
• 结果能否撤回：聊天回答可以纠正，邮件、支付、合同、审批往往不能撤回。
• 历史上是否异常：用户是否多次尝试绕过规则，或输入明显诱导模型越权的内容。

低风险请求可以快一点，中风险请求要检查，高风险请求要停下来确认。

这背后的产品原则是：不要让所有用户为少数高风险场景买单，但也不要让高风险场景套用低风险体验。

五、什么时候流式输出？什么时候必须先审核？

很多 Agent 产品喜欢做流式输出，因为用户感知快，看起来也更“智能”。

但流式输出不是默认正确。

如果 Agent 的回答出错后可以撤回，比如内部助手答错了一个流程说明，流式输出问题不大。可以先展示，再在后台校验，发现问题后提醒修正。

但如果 Agent 正在生成一封发给客户的邮件、生成法律意见、给出投资建议、提交报销审批、修改订单状态，就不能边生成边放出去。

产品经理可以用一个简单问题判断：这个结果能不能收回来？

能收回来，可以考虑先输出后校验。

不能收回来，就必须先校验后交付。

影响钱、命、合规、声誉的结果，必须有人或强规则兜底。

这也是 Agent 产品和普通聊天机器人的区别：聊天机器人主要负责“说”，Agent 往往还会“做”。只要它能做事，护栏就必须前置到行动之前。

六、把护栏写进 PRD：几个必须定义清楚的问题

很多 Agent 项目出问题，不是因为团队不知道要安全，而是 PRD 里没有把安全写成可执行需求。

产品经理在写 Agent PRD 时，至少要补上这些内容：

1. Agent 的职责边界是什么？ 它负责回答、建议、总结，还是可以执行操作？哪些事情明确不能做？
2. 哪些输入属于高风险？ 例如隐私数据、价格承诺、医疗症状、法律纠纷、投资建议、权限绕过、批量数据导出。
3. 哪些输出必须带依据？ 例如政策解释、合同条款、价格、库存、客户权益、数据分析结论。
4. 哪些操作需要二次确认？ 例如发消息、发邮件、下单、退款、审批、删除、导出、修改客户资料。
5. 哪些场景必须转人工？ 例如用户情绪激烈、合规风险高、模型置信度低、知识库无答案、连续校验失败。
6. 如何记录和复盘？ 包括护栏命中率、误拦率、漏拦案例、人工接管比例、响应延迟、用户放弃率。

这些内容不是技术细节，而是 Agent 产品经理的核心工作。

七、好的护栏不是让 Agent 更保守，而是让它更可信

很多团队担心护栏会限制 Agent 能力，让产品变得笨重。

但好的护栏不是为了让 Agent 少做事，而是为了让它在正确的边界内大胆做事。

• 低风险任务，让它快。
• 中风险任务，让它稳。
• 高风险任务，让它停下来确认。
• 不可撤回任务，让它必须有人类授权。

未来的 AI 产品经理，不只是设计页面和流程，而是设计“智能体如何判断、如何行动、如何负责”。

Agent 的产品体验，也不只是回答得像不像人，而是用户能不能放心把一部分任务交给它。

真正好的 Agent 护栏，用户未必能明显感知到；但它会让产品在关键时刻不越界、不乱答、不擅自行动。

这才是 Agent 产品从 Demo 走向生产环境的分水岭。