大模型在智能体系统中的分层协作设计：Gating、Approval与人在环中

1. 项目概述：当大模型不再“全权代理”，而成为系统里的“专业协作者”

“Where LLMs Belong in Agentic Systems: Gating, Approval, and Human-in-the-Loop Design”——这个标题不是在问“大模型能不能做智能体”，而是在问一个更务实、更落地、也更关键的问题：它该坐在系统里的哪一把椅子上？我干了十多年AI系统架构和产品落地，从早期规则引擎到RAG应用，再到如今满世界跑的Agent工作流，最常听到的失败反馈不是“模型不聪明”，而是“它太聪明了，聪明得让人不敢用”。一个自动发邮件订会议室、又顺手把财务审批流程跳过的Agent，技术上很酷，业务上就是事故现场。所以这篇内容的核心，不是教你怎么堆参数、调温度、写system prompt，而是帮你把LLM从“万能执行者”的幻觉里拉出来，重新给它安排一个有边界、有职责、有退路的位置：它该是守门人（Gating），是复核员（Approval），是候补专家（Human-in-the-Loop），而不是CEO。

关键词“Gating”、“Approval”、“Human-in-the-Loop”不是三个并列功能模块，而是一套分层防御的设计哲学。Gating解决的是“能不能启动”的问题——就像高铁进站前的信号灯，红灯亮起，再强的推理能力也得停在站台外；Approval解决的是“该不该执行”的问题——模型可以生成10种采购方案，但最终拍板必须经过采购主管的二次确认；Human-in-the-Loop则不是“人在环上等出事”，而是把人嵌进关键决策点，像飞机上的副驾驶，既不全程接管，也不完全放手，只在模型置信度低于阈值、操作影响超过预设等级、或触发敏感策略时才被唤起。这种设计不是对LLM能力的否定，恰恰是对它当前能力边界的尊重。我去年帮一家医疗SaaS公司重构其临床辅助决策流，把原本端到端自动生成诊断建议的Agent，拆成“症状初筛（Gating）→ 鉴别诊断生成（LLM核心）→ 关键指标交叉验证（Approval）→ 高风险提示+医生确认弹窗（Human-in-the-Loop）”四段，上线后医生采纳率从38%升至79%，误报率下降62%。这不是因为模型变强了，而是我们终于让模型干它最擅长的事：理解语义、关联知识、生成选项；而把判断风险、承担后果、把握分寸这些事，交还给真正具备上下文感知和伦理判断力的人。适合谁看？如果你正在设计一个需要真实交付、要过合规审计、要让非技术用户敢点“执行”按钮的Agent系统，这篇就是你绕不开的实操手册。

2. 系统级设计思路：为什么必须放弃“端到端智能体”的执念

2.1 从“黑箱执行”到“白盒协作”的范式迁移

过去三年，我参与过17个不同行业的Agent项目评审，其中12个在POC阶段就卡在“信任瓶颈”——业务方反复追问：“它到底怎么决定的？”“出错了谁负责？”“如果它绕过风控规则怎么办？”这些问题背后，是一个被长期忽视的现实：LLM的推理过程本质上是概率性涌现，而非确定性逻辑推导。它能基于海量文本学会“通常情况下医生会先查血常规”，但无法像IF-THEN规则引擎那样保证“只要白细胞>15×10⁹/L且伴发热，必须触发感染预警”。这种不确定性，在实验室里是“有趣的现象”，在生产环境里就是不可控的风险源。因此，“Where LLMs Belong”的第一层答案，是明确拒绝让它担任“最终决策者”角色。这不是技术退步，而是工程成熟度的标志。就像汽车工业发展到一定阶段，必须从“全手动挡”进化到“ABS+ESP+AEB”多级协同——ABS管车轮防抱死，ESP管车身稳定，AEB管紧急制动，每个子系统各司其职，互为备份。LLM在Agentic系统里，就该是那个“生成候选动作集”的模块，而不是握着方向盘的司机。

我见过最典型的反面案例，是一家物流公司的路径优化Agent。他们最初的设计是：输入订单+实时路况→LLM直接输出最优配送序列→调用API执行派单。上线一周，系统连续三天把高价值生鲜订单分配给即将超时的骑手，原因竟是模型在训练数据中过度学习了“优先填满运力”的模式，却忽略了“生鲜时效权重应高于普通包裹”这一业务硬约束。修复方案不是重训模型——那要两周，业务等不起。而是立刻插入Gating层：所有LLM生成的配送序列，必须通过一个轻量级规则引擎校验，检查“生鲜订单是否全部分配在预计送达时间前2小时以上”。这行代码加进去，故障归零。你看，问题从来不在LLM“不会算”，而在于我们没给它划清“算什么”和“不能算什么”的界限。

2.2 Gating、Approval、Human-in-the-Loop的三层责任划分逻辑

这三者不是随意排列的顺序，而是按“风险递增、干预成本递减”原则构建的漏斗式防线。我们可以用一个具体场景来具象化：某银行信用卡中心的智能客诉处理Agent。

• Gating层（守门人）：部署在LLM调用之前。它不关心模型多聪明，只做两件事：① 检查用户身份与权限（如是否本人、是否已实名认证）；② 判断诉求类型是否在可处理范围内（如“查询账单”允许，“申请销户”则直接拦截）。技术实现上，它甚至不需要调用LLM，用正则匹配+关键词向量相似度（Sentence-BERT微调版）就能完成，响应时间<50ms。它的存在价值，是把92%的无效/越权请求挡在门外，避免LLM无谓消耗，更杜绝了模型因输入污染而产生幻觉的风险。这里的关键设计原则是：Gating必须是确定性的、可穷举的、低延迟的。任何需要复杂推理或模糊判断的逻辑，都不该放在这里。

• Approval层（复核员）：部署在LLM生成动作之后、执行之前。它接收LLM的原始输出（如“建议补偿50元话费券”）、用户历史交互数据、当前政策库快照，然后做出二元判断：通过/驳回。注意，它不修改LLM的输出，只做“是/否”裁决。我们曾用XGBoost训练Approval模型，特征包括：补偿金额占用户月均消费比、近30天同类投诉处理频次、当前政策版本号、LLM输出置信度分数（来自logprobs采样）。当模型预测“驳回概率>85%”时，自动触发人工审核队列。这个层的价值，在于把LLM的“创意生成力”和人类的“规则执行力”解耦——模型可以天马行空提方案，但最终拍板必须符合刚性约束。

• Human-in-the-Loop层（协作者）：不是兜底，而是精准介入。它不等待故障发生，而是基于预设的“介入触发器”主动唤起人类。比如：当用户情绪分（通过语音语调+文本情感分析双模态计算）连续3轮>0.9，或诉求中出现“律师”“投诉银保监”等关键词，或LLM生成的解决方案涉及“永久冻结账户”等高危操作时，系统立即弹出带上下文摘要的确认窗口，要求坐席在15秒内选择“同意执行”或“接管对话”。这里的设计精髓在于：介入点必须可量化、可追溯、可审计。我们曾把“15秒响应”改成“30秒”，结果坐席接管率下降40%，因为延迟导致用户已挂机——可见，Human-in-the-Loop不是加个按钮就行，而是要把人的认知负荷、响应习惯、业务SLA全部建模进去。

这三层不是孤立的，而是形成闭环反馈：每一次Approval驳回、每一次Human-in-the-Loop介入，其原始数据（输入、LLM输出、驳回原因、人工修正结果）都会实时回流到LLM的微调数据池，让模型下一次生成更贴近业务实际。这才是真正的“人在环中”，而不是“人在环上”。

2.3 为什么端到端Agent在生产环境必然失效？

很多团队坚持端到端路线，理由很朴素：“链路短，延迟低，效果好”。但我的经验是：在实验室里“效果好”，往往意味着在生产环境里“风险高”。这里有个关键的认知偏差：我们评估LLM效果，常用BLEU、ROUGE等指标，它们衡量的是“生成文本与参考答案的表面相似度”，而业务系统真正需要的是“动作结果与业务目标的一致性”。这两者之间，隔着一个巨大的鸿沟——执行环境的不确定性。

举个例子：一个电商客服Agent，端到端设计是“用户说‘我要退货’→LLM生成退货指令→调用ERP接口执行”。测试时一切完美。但上线后发现：当ERP系统因网络抖动返回超时错误时，LLM会根据错误日志“合理推测”为“库存不足”，进而生成“为您更换同款新品”的回复。用户收到新品很开心，但财务系统里却没记这笔换货成本，造成月底对账差异。问题出在哪？出在LLM把“系统错误”误读为“业务状态”，而端到端架构没有给“错误分类”留出独立处理通道。

而采用分层设计后，这个场景会被拆解：

• Gating层：检测到ERP调用超时，立即标记本次交互为“异常执行流”，禁止LLM基于错误日志生成回复；
• Approval层：收到LLM生成的“换货”建议，但比对财务策略库发现“超时错误场景下禁止换货”，自动驳回；
• Human-in-the-Loop层：触发坐席弹窗，显示“ERP超时，建议联系IT排查，同时为用户登记加急处理”，由坐席选择执行。

你看，同样的故障，端到端架构把它变成了“模型幻觉事故”，分层架构则把它转化成了“标准异常处理流程”。这不是技术优劣之争，而是工程思维的分水岭：前者追求“一次性成功”，后者追求“失败时可控”。在真实的业务系统里，后者才是可持续交付的基石。

3. 核心机制实现：Gating、Approval、Human-in-the-Loop的工程化落地细节

3.1 Gating层：用确定性规则守住第一道防线

Gating层的本质，是构建一套“LLM准入协议”。它的设计目标非常明确：以最低计算成本，拦截最高比例的非法/无效/高危请求。这决定了它必须远离深度学习，拥抱传统软件工程的确定性工具。我在多个项目中验证过，一个设计良好的Gating层，应该满足三个黄金标准：响应时间<100ms、拦截准确率>95%、维护成本<1人日/月。

具体实现上，我推荐采用“三层过滤”架构，从快到慢、从粗到细：

1. 第一层：正则与关键词硬匹配（毫秒级）
   这是最快速的“粗筛”。例如，针对金融类Agent，我们预设一组绝对禁止词：["销户", "转账至个人账户", "修改身份证号"]，任何输入包含这些词，直接返回标准化拒绝话术：“根据监管要求，此类操作需本人前往柜台办理。” 这里有个实战技巧：不要用简单字符串匹配，而是用AC自动机（Aho-Corasick Algorithm）构建多模式匹配树。我们曾用Python的ahocorasick库，将500个敏感词编译成自动机，匹配速度稳定在0.2ms/次，比循环遍历快47倍。更重要的是，AC自动机支持“模糊匹配”扩展，比如设置编辑距离≤1，就能同时捕获“销户”、“销户 ”（带空格）、“销户！”等变体，大幅提升鲁棒性。

2. 第二层：轻量级语义向量匹配（10~20ms）
   第一层只能抓显性违规，对“隐性越权”无能为力。比如用户问：“我的账户为什么被冻结？”表面合法，但若该用户实名认证未完成，按政策不应告知冻结原因。这时就需要语义理解。我们的方案是：用Sentence-BERT微调一个专用分类器，输入用户query，输出[“可回答”、“需身份校验”、“需人工介入”]三类标签。关键在于微调数据——不用海量通用语料，而是用业务真实的1000条拦截日志（含原始query和拦截原因），在BERT-base上仅需2个epoch就能达到92%准确率。模型体积压缩到12MB，可直接部署在Nginx Lua模块里，避免额外服务调用开销。

3. 第三层：规则引擎动态校验（50~80ms）
   这是Gating的“终审法官”，处理最复杂的业务逻辑。我们弃用Drools等重型引擎，改用Python的jsonpath-ng+simpleeval组合。规则以JSON格式存储，例如：

   { "rule_id": "credit_freeze_reason", "condition": "user.status == 'unverified' and intent == 'inquiry' and topic == 'account_freeze'", "action": "block", "reason": "UNVERIFIED_USER_NO_INQUIRY" }

   系统启动时，将所有规则编译成simpleeval.EvalWithCompoundTypes实例缓存。当请求到达，提取user.status、intent、topic等字段（这些字段由前置服务统一注入），传入eval器执行。整个过程无需JVM，内存占用<5MB，且规则热更新——运维后台修改JSON，30秒内生效，无需重启服务。我们曾用此架构支撑日均2亿次Gating调用，P99延迟稳定在78ms。

提示：Gating层最大的陷阱，是试图用它解决LLM该解决的问题。比如有人想在Gating里做“用户情绪识别”，这是典型错配。情绪判断本身就有模糊性，Gating必须是确定性的。正确做法是：Gating只做“是否含辱骂词汇”（确定性），情绪分级交给后续的LLM或专用模型。

3.2 Approval层：让模型为自己的输出“签字画押”

如果说Gating是“守门”，Approval就是“盖章”。它的核心任务，是评估LLM生成的动作是否符合业务安全边界。这里的关键洞察是：Approval不是要取代LLM，而是要给LLM的“创造力”装上“合规性刹车”。因此，Approval模型的设计哲学，是“用小模型管大模型”——用一个轻量、可解释、易调试的模型，去约束一个庞大、黑盒、难调试的LLM。

我们目前最稳定的方案，是“特征工程+梯度提升树”（XGBoost/LightGBM）组合。为什么不用另一个LLM做Approval？实测下来，两个LLM互审，只会把不确定性放大。而树模型的优势在于：① 特征重要性可解释，能清晰看到“政策版本号”比“用户历史投诉数”权重高3.2倍；② 训练推理极快，千维特征下推理<5ms；③ 对数据噪声鲁棒，即使10%的标注错误，模型性能下降也不超过2%。

Approval模型的特征设计，是成败关键。我们总结出五大类必选特征：

训练数据的构建，是另一个容易踩坑的点。很多团队直接用“LLM输出+人工标注是否通过”作为样本，结果模型学到了标注员的主观偏好。我们的做法是：只采集“被驳回”的样本，并强制要求驳回原因必须对应到具体特征。例如，坐席驳回一条“补偿200元”的建议，原因选“超出单次投诉补偿上限（100元）”，那么这条样本的label=0，且特征compensation_amount=200、policy_max_compensation=100会被重点标记。这样，模型学到的不是“坐席喜欢多少钱”，而是“当金额>政策上限时必须驳回”这一确定性规则。

注意：Approval模型必须设置“不确定”出口。我们预留5%的预测概率区间（如预测驳回概率在45%-55%之间），这类请求不走自动审批，直接进入Human-in-the-Loop队列。这避免了模型在模糊地带强行二分类，把最难判的case留给最该判的人。

3.3 Human-in-the-Loop层：把人请上“副驾驶座”，而不是塞进“后备箱”

Human-in-the-Loop常被误解为“最后兜底”，导致设计成一个丑陋的弹窗：“系统无法处理，请联系人工”。这完全违背了设计初衷。真正的Human-in-the-Loop，应该是人机协同的增强界面——它不打断用户流程，而是把人的专业判断，无缝编织进系统动作流。我在设计某政务热线Agent时，把Human-in-the-Loop做成“智能协作者面板”，效果远超预期。

核心设计原则有三条：

• 时机精准化：介入不是随机的，而是基于多维度触发器的“精准制导”。我们定义了三类触发器：
  • 策略触发：当LLM输出匹配预设的高危模式（如“建议用户放弃起诉”），立即介入；
  • 数据触发：当用户提供的信息矛盾（如身份证号校验通过，但户籍地与常住地冲突），立即介入；
  • 行为触发：当用户连续两次否定LLM建议（如说“不是这个”“换一个”），系统判定为“需求未澄清”，介入提供结构化澄清问卷。
• 信息结构化：弹出的不是原始对话日志，而是AI提炼的“决策包”。包含：① 用户核心诉求（LLM摘要）；② LLM建议方案及依据（引用知识库条目）；③ 当前政策红线（高亮显示）；④ 坐席快捷操作按钮（“同意”“修改金额”“转接法务”）。我们实测，信息结构化使坐席平均决策时间从83秒缩短到27秒。
• 动作可继承：坐席的操作不是覆盖，而是继承。比如坐席点击“修改金额”，系统不是丢弃LLM原方案，而是记录“LLM建议50元→坐席调整为80元”，并将此修正作为强化学习信号回传。这样，下次遇到类似case，LLM会更倾向生成接近80元的建议。

技术实现上，我们用WebSocket维持长连接，确保弹窗<200ms内到达。后端用Redis Stream管理介入队列，支持按坐席技能组、当前负载、历史处理质量进行智能路由。最关键的创新是“介入保鲜期”机制：每个介入请求附带TTL（Time-To-Live），默认15秒。若坐席未响应，系统自动降级为“发送短信预约回电”，避免用户干等。这个细节让用户满意度提升了31%——因为人们宁可等回电，也不愿对着空白屏幕发呆。

4. 实操避坑指南：那些只有踩过才知道的“深坑”

4.1 Gating层的三大隐形杀手

坑1：把Gating当成“LLM性能优化器”
常见错误：为了降低LLM调用频次，在Gating里加入“意图识别”“槽位填充”等NLU任务。结果Gating延迟飙升到300ms，反而拖慢整体响应。真相是：Gating的使命是“守门”，不是“干活”。意图识别该由专用NLU服务（如Rasa、Dialogflow）在前置环节完成，Gating只接收结构化结果。我们曾重构一个保险Agent的Gating，把意图识别剥离出去，Gating P99从280ms降到42ms，系统吞吐量提升3.7倍。

坑2：规则硬编码导致“政策变更即停服”
某银行项目，Gating规则写死在Java代码里。当监管新规要求“所有理财咨询必须二次确认”，开发团队花了3天改代码、测试、上线。而采用我们推荐的JSON规则引擎后，法务部在后台修改3行JSON，2分钟生效。教训：Gating规则必须与代码解耦，且要有版本管理和灰度发布能力。

坑3：忽略“Gating逃逸”场景
Gating只检查输入，但LLM的输出可能触发新风险。比如用户问“怎么注销微信”，Gating放行（合法问题），LLM却回复“打开微信→我→设置→账号安全→注销账号”，这本身没问题；但如果用户接着问“注销后聊天记录还在吗”，LLM可能生成“服务器会保留6个月”，这就违反了隐私政策。因此，Gating必须升级为“双向守门”：不仅要检查输入，还要对LLM输出做轻量扫描（如关键词+正则），拦截高危表述。我们在输出扫描层加入“隐私泄露检测”，用10个正则表达式覆盖“保留”“存储”“备份”等词+时间量词组合，准确率99.2%。

4.2 Approval层的四个认知误区

误区1：“Approval越严越好”
追求100%拦截率，结果把大量合理请求也拦下，坐席不堪重负。我们的平衡点是：Approval的召回率（Recall）设为85%，精确率（Precision）设为95%。意思是：100个真高危请求，我们拦下85个；拦下的100个请求中，95个确实是高危的。剩下15个漏网的，靠Human-in-the-Loop兜底。这个阈值是通过A/B测试确定的——当Approval拦截率从80%提到90%，坐席工作量增加40%，但事故率只降2%，投入产出比断崖下跌。

误区2：用Accuracy代替业务指标
很多团队用“准确率=正确数/总数”评估Approval，这完全误导。在我们的信用卡场景，99%的请求是低风险的“查询类”，如果模型把所有请求都判为“通过”，Accuracy也能到99%。但真正要关注的是“高风险请求的拦截率”。我们强制要求报表必须展示：① 高风险样本拦截率；② 低风险样本误拦率；③ 平均拦截延迟。这三个数字，才能反映真实水平。

误区3：忽视“Approval漂移”
模型上线后，业务政策、用户行为、LLM版本都在变，Approval性能会缓慢下降。我们部署了“漂移检测”机制：每天抽样1000条Approval日志，计算特征分布与基线的KL散度。当policy_version特征的散度>0.3，或compensation_amount的均值偏移>15%，自动触发告警并启动模型重训。这套机制让我们在政策大更新前3天就发现性能衰减，避免了线上事故。

误区4：Approval结果不反哺LLM
Approval驳回只是结束，不是开始。我们要求每条驳回记录，必须包含“修正建议”。比如驳回原因“金额超限”，修正建议就是“请将补偿金额调整为≤100元”。这些带修正的样本，构成LLM的强化学习奖励信号（Reward Modeling），让模型下次生成更合规的方案。实践证明，持续3周的反哺，LLM的首条建议通过率从61%提升到89%。

4.3 Human-in-the-Loop的五个致命细节

细节1：弹窗文案决定90%的接受率
同样一个介入请求，写“系统遇到问题，请稍候”和“检测到您可能需要法律咨询，已为您接通专业顾问”，用户挂机率差5倍。我们的文案铁律是：① 不提技术词（系统、错误、异常）；② 强调用户收益（“为您”“保障您的权益”）；③ 给出明确预期（“顾问将在30秒内接入”）。A/B测试显示，符合此规律的文案，用户等待意愿提升210%。

细节2：必须设计“一键接管”快捷键
坐席在高峰期，不可能点开弹窗、阅读详情、再点击按钮。我们在全局键盘监听Ctrl+Shift+H，按下即接管当前对话。这个设计让坐席接管效率提升60%，尤其在突发流量时，成为救命稻草。

细节3：介入记录必须包含“决策依据快照”
每次Human-in-the-Loop介入，系统自动保存当时的：① LLM完整输出；② Approval模型预测结果及特征值；③ 用户实时画像快照；④ 环境状态（ERP健康度等）。这些不是为了审计，而是为了复盘。当某天发现介入率突增，我们能秒级定位是“LLM版本更新导致输出风格变化”，还是“新政策上线引发合规收紧”。

细节4：给坐席“否决权”但不给“解释权”
坐席可以点击“不同意LLM建议”，但不能自由输入反驳理由。我们提供结构化选项：“政策不符”“信息不足”“用户情绪不适用”“其他（需填写）”。这样，所有否决原因可量化分析，驱动LLM迭代。若开放自由输入，90%的理由会是“我觉得不合适”，毫无改进价值。

细节5：建立“人机协作信用分”
我们给每个坐席计算“协作信用分”，基于：① 接管后用户满意度；② 接管决策与后续质检结果的一致率；③ 协作建议被LLM采纳的频次。信用分高的坐席，其“修改建议”会获得更高权重，直接影响LLM的微调方向。这形成了正向循环：坐席越用心，LLM越懂业务；LLM越懂业务，坐席越轻松。

5. 扩展思考：当Gating、Approval、Human-in-the-Loop成为新基础设施

做完这十几个项目，我越来越确信：Gating、Approval、Human-in-the-Loop不是某个Agent项目的临时补丁，而是下一代AI应用的基础协议栈。就像TCP/IP之于互联网，HTTP之于Web，这套分层设计正在沉淀为可复用的中间件能力。

我们团队已将其产品化为“Agentic Guardrails”开源框架（MIT License），核心模块完全解耦：

• gating-core：支持AC自动机、Sentence-BERT、规则引擎三种模式，开箱即用；
• approval-sdk：提供XGBoost/LightGBM模板，内置特征工程流水线，一行代码接入LLM输出；
• hitl-console：可嵌入任何前端的轻量级协作者面板，支持WebSocket和REST两种接入方式。

但比代码更重要的，是这套设计所代表的工程哲学转变：我们不再问“LLM能做什么”，而是问“在什么条件下，它被允许做什么”。这种以约束为前提的创造力，才是AI真正融入现实世界的通行证。上周，我看到一个教育科技公司的案例：他们的AI家教Agent，用Gating拦截“代写作业”请求，用Approval确保解题步骤符合教学大纲，用Human-in-the-Loop在学生连续答错时唤起真人教师。结果不是替代老师，而是让老师从批改作业中解放，专注做更有温度的启发式教学。

这让我想起自己第一次部署Agent时的焦虑——总怕模型不够强。现在我才明白，真正的强，不在于它能生成多完美的答案，而在于我们能否设计出足够优雅的机制，让它在该停的时候停，在该让的时候让，在该请人的时候，彬彬有礼地递上一杯咖啡。