夜雨聆风从一个投诉说起
有个外卖平台做了一套保险售后流程。
客户买了 放心吃，拿到餐觉得有问题——糊了、有异味、不好吃。点进投诉页面，选了"包装异常"，在描述里写了一大段"这虾是臭的"。
AI 客服一看：选的选项是包装，描述说的是食品问题，语义不匹配。于是给出提示——"您选择的投诉原因和描述内容可能不一致，请调整后再提交。"
逻辑上没错。但客户什么反应？
"老子餐都吃出问题了，还要教我怎么填投诉？"
继续点提交。
一次，提示。两次，提示。第三次、第四次，全部挤在一两分钟内。
这时候系统做了一个决定：不再拦截，柔性通过，转人工。
这就是我们今天要聊的事。
1. 柔性通过到底在防什么
这个机制回答了一个很实际的问题：AI 判对了，但客户不配合，怎么办？
严格来说 AI 没错——"包装异常"和"食品变质"确实不匹配。但客户没有义务配合你的分类体系，他只想解决问题。如果系统一直卡着他，要么他觉得你是故意的，火上浇油；要么他真放弃投诉了——但那笔单子的真实问题也落不了地。
所以柔性通过在防两件事：
- AI 误判
——客户选对了，但 AI 理解错了，卡住了真实投诉 - 客户情绪
——客户选错了，但他没心情改，你再怎么提示他只会更火
这两个场景的共同点是：继续让 AI 判断已经没有意义了。 不管 AI 这次判对还是判错，继续卡的结果都是负面收场。
但柔性通过有个隐含前提——你相信行为信号比语义信号更可靠。 客户重复提交 N 次，这个行为本身就在替他说话："我很坚持，别拦我。" 系统认了这个信号，放行。
2. 恶意逃逸
柔性通过是给善意客户准备的退出路径。但它同时也是给恶意攻击者准备的入场券。
攻击者不需要骗过 AI 的语义判断。他只需要知道"重复提交 N 次就会被放行"这个规则，然后故意构造投诉文本触发这个路径。
放行之后呢？后面的流程还有 AI——自动审核材料、自动判断是否理赔、自动执行赔款。那些环节的 prompt 可能更脆弱，因为设计时的假设是"走到这里的都是正常 case"。
柔性通过本来是用来兜底的保险，结果打开了一个更大的攻击面。
3. 怎么封？我的做法
当一次请求走了柔性通过之后，我给它打一个标记：
{"passed": true,"mode": "flex_pass","restriction": "human_only"}
这个标记跟着请求走完全程。后续所有 AI Agent 看到这个标记，只做一件事：什么都不做。 不做自动审核、不做自动判断、不做自动理赔。整理资料、输出摘要可以，但任何涉及决策和执行的环节全部跳过。
路径就变成了这样：
第一关：AI 语义判断 + 行为频次监控→ 正常通过 → 后续流程正常走→ 柔性通过 → 标记 human_only↓第二关：标记一路传递↓后续所有 AI Agent 见到 human_only：做分析 → 可以做决策 → 跳过↓直接转人工
为什么不是每个下游 Agent 各自加一层安全检测？因为防不过来。
下游可能有三个 Agent、五个 Agent，每个都有自己的 prompt、自己的上下文、自己的弱点。攻击者只要进来一次，就能在每个下游尝试逃逸。你不可能在每个 Agent 前都加一道同等级的防护墙。从架构上在入口处一刀切断，比在每个下游打补丁便宜得多。
4. 各大厂的处理方案
当然不止我一个这么干
上面这套思路不是拍脑袋想出来的。如果你去看大厂的 AI 系统设计，会发现它们早就把"在合适的地方切断 AI"当成了架构原则——只是用词不同。
美团：按不可逆程度分三级
美团智能客服团队在他们的 Agent 设计里明确分了三个风险等级：
| L1 低风险 | ||
| L2 中风险 | ||
| L3 高风险 |
分级的依据只有一个：错了能不能回滚。 查信息查错了——没事，再查一次。退款退错了——钱出去了回不来，AI 说"退"不算，得人点头。
而且他们的转人工不是把聊天记录一甩了事。美团的规范是生成结构化摘要——用户诉求是什么、已确认哪些信息、已执行哪些动作、当前卡在哪一步。人工客服接到的是完整上下文，不是要从头读对话。
这跟我们的 human_only 标记一模一样——前面 AI 做的分析可以留下来，但后续的决策权交给人类。
字节跳动：机器管宽度，人管控深度
字节的内容审核体系也是类似的思路。抖音每天要处理海量上传内容，他们的策略是：
- 机器负责"宽度"
——所有内容先进机器审核，覆盖面越广越好 - 人工负责"深度"
——专业、敏感、疑难的 case 交给人精准研判
具体到流程上：内容上传 → 机器识别 → 高危直接拦截 → 疑似送人工 → 低风险放基础流量 → 后续举报/评论异常/流量激增还会重新触发审核。
注意一个细节：高危直接拦、低风险直接放、中风险送人工。 这不是"AI 能力不够所以找人补"，而是故意的架构选择——AI 在两端做事，人在中间做关键决策。
OpenAI：在副作用前暂停
OpenAI 的 Agent SDK 里有个 Guardrails & Approvals 机制，核心逻辑是：
当 Agent 要执行一个会产生副作用（side effect）的操作时——取消订单、发邮件、调 shell 命令、调敏感 MCP 工具——run 暂停，返回
interruptions标记，等你同意才继续。
他们的分类也很明确：
输入 guardrail → 检查用户请求是否合规 输出 guardrail → 检查模型回复是否安全 工具 guardrail → 检查工具调用参数和结果 - Human-in-the-loop approval
→ 在执行副作用之前暂停
OpenAI 甚至有一个词叫 "workflow boundaries matter"——agent 级别的 guardrail 不是到处都生效的。输入 guardrail 只管第一个 agent，输出 guardrail 只管最后一个 agent，工具 guardrail 只绑在特定工具上。把安全放在最该放的地方，不要幻想一层防护覆盖所有。
这跟我们说的"不要在入口放行之后指望每个下游自己防守"是同一个道理，只是方向不同——我们说下游防不过来，他们说上游的防护管不到下游。
而且这对真实用户也是正确的
客户已经因为"你总说我选错了"不爽了。柔性通过之后又看到 AI 在处理他的投诉——他会怎么想？
"这 AI 怎么回事，刚才拦我半天，现在又替我来回倒腾。"
走到柔性通过这一关，就交给人。真实用户的体验是加分，不是减分。
美团的转人工设计也贯彻了同一个思路：不只考虑自己的系统架构，也考虑用户此刻的情绪。 他们的规范里"连续 3 次意图不明、触发敏感词、用户情绪激昂"作为硬性转人工条件——不光是技术上判断 AI 不行了，也是用户层面判断"这时候机器再说话就是找骂"。
5. 最后一个细节
行为频次这个信号也有讲究。它不是"提交 N 次就算"，而是频率 + 时间窗口。
客户一分钟内连点 5 次 = 情绪信号很强。但如果一天内断断续续提交 5 次——那是他在试验不同的投诉分类，不是激动。反过来，如果你把阈值设得太低（两次就放行），那就变成了"但凡犹豫一下就走柔性通过"，AI 的拦截机制形同虚设。
这三个维度——次数、间隔、窗口——组合起来才是行为信号。只数次数容易被试探。
说到底，还是同一个原则
之前聊过一个观点：别按任务类型分边界，按错误代价分边界。
柔性通过这个机制是同一个道理的反面——模型的输出不是最终判决，用户的行为信号同样有分量。 两个信号矛盾的时候，系统不是无条件信任模型，而是走了第三条路。
但放开之后一定要管住后续。放行不意味着把整条线都交给概率模型继续跑。恰恰相反——放行意味着你知道 AI 在这一关已经不可信了，后面的事不该再交给它。
美团的 L1/L2/L3、字节的宽度深度、OpenAI 的副作用暂停——这三个看似完全不同的系统，底层是同一条规则：AI 做判断，行为信号做修正，规则做兜底，人工做收尾。 少一环都会出事。
而且这套规则嵌入架构的位置也有讲究——放在入口处一刀切，比分散在每个下游打补丁便宜得多。不是因为你懒，是因为下游永远有你看不到的薄弱点。
