如何防止LLM「乱承诺」delivery-harness建议性护栏的三重防线与金额冲突检测实战【免费下载链接】delivery-harnessAI harness reference implementation for on-demand delivery workflows项目地址: https://gitcode.com/gh_mirrors/de/delivery-harnessdelivery-harness 是一个面向即时配送场景的 AI Agent 参考实现它最值得关注的设计之一正是防止 LLM「乱承诺」的护栏机制赔付金额由规则引擎决定、模型只负责解释再由 GuardrailChecker 建议性护栏通过三重防线校验模型输出——承诺性措辞、金额上限、金额冲突检测任何一条不过都不会触发支付只会转人工复核。本文将拆解这套「LLM 输出校验」方案的设计动机与落地细节。为什么金额不能让模型说了算在即时配送的赔付场景中LLM 有两类典型风险措辞风险模型对用户说「保证赔偿」「一定赔付」一旦发出去就是法律层面的承诺数字风险模型「自信地」算出一个赔付款比如 5 元而政策规定应该是 20 元——上限检查拦得住「太大」拦不住「 plausible 但错了」的数字后者才是默默亏钱的元凶。项目团队在 ADR-0002规则引擎拥有赔付金额 中给出了决策模型永远不产生金额只负责解释。这个决定的背景是早期版本让金额「穿过」一次模型采样——规则引擎算出 17.75 元塞进 prompt让模型再输出一遍然后用正则检查模型没把数字写坏。一个可审计的确定性数字经过一次 token 采样后变得无法复现、无法向审计方交代。重构后的分工见 CompensationSuggestionWorkflow.java规则引擎CompensationRuleToolkit.java根据投诉类型、超时时长、订单金额确定性地算出suggested_amount并标注decided_by: rule_engine每一笔赔付都可追溯回一条政策规则模型只写审核人能读懂的依据reason、面向用户的说明customer_message、风险标记和是否升级人工escalate护栏校验的是规则引擎的金额——即响应里真正携带的那个数字。三重防线护栏在响应组装前拦截什么在响应组装之前工作流会并行做三个独立检查全部通过才置guardrail_passed trueCompensationSuggestionWorkflow.java#L169-L176防线方法检测目标第一重checkCompensationAmount权威金额是否落在[0, 上限]闭区间第二重checkForbiddenPhrases模型文字中是否出现承诺性措辞第三重mentionsConflictingCompensationAmount模型文字里的金额是否与规则引擎冲突第一重承诺性措辞黑名单GuardrailChecker.java#L25-L27 维护了四个「一出口就是负债」的短语「保证赔偿」「一定赔偿」「必须全额退款」「我们承诺」。命中任意一个该检查即失败。值得一提的是模型的系统提示词里已经预先约束了「不要使用承诺性表述」CompensationSuggestionWorkflow.java#L53-L61但护栏依然兜底——prompt 约束是软性的正则检查才是硬性的这正是「建议性护栏」的定位它不替代提示工程而是提示工程失效时的最后一道网。第二重金额上限检查checkCompensationAmountGuardrailChecker.java#L69-L81把金额约束在[0, max-compensation-amount]默认 50.0可配置。注意三个细节它检查的是规则引擎的金额而不是模型的输出——因为那才是真正会付出去的数字失败即关闭fail closed金额为null、非有限值、负数或超上限一律判不通过上限是「建议性」的保险丝不是业务策略本身——策略由规则基座里的规则条目决定。第三重金额冲突检测最有意思的一层模型被明确告知「不要输出 suggested_amount也不要在文字中另行提出金额」但模型偶尔会不听话。此时需要回答一个微妙的问题模型提到金额就一定算违规吗mentionsConflictingCompensationAmountGuardrailChecker.java#L115-L154的答案是——重复权威金额无害报出一个不同的数字才是真实的策略冲突。它的判断逻辑可以概括为三步先判断模型是否提到了金额既看结构化字段suggested_amount: 20也看散文体写法如「20元」「20」「¥ 20.00」「订单晚了20分钟」这类时间表述不算金额逐个可比对的数字与权威金额比较例如权威金额为 20.00 元时「适用 COMP-001最高不超过20元」✅ 通过「建议赔付50元」❌ 冲突解析不了就当冲突字段值不是可比较的数字如suggested_amount:20字符串、或指数部分畸形如1e9999999999一律按冲突处理——无法安全比较的内容宁可误报也不放行。这套「允许复述、拒绝改写」的冲突检测正是「金额冲突检测」的核心护栏不是禁止模型提数字而是禁止模型报一个和政策不同的数字。护栏失败之后只报告不否决delivery-harness 把护栏定位为建议性advisory输出检查而非策略引擎。失败后发生的事响应中guardrail_passed置为falseguardrail_failed被写入approval_reasons从而推高approval_requiredOutputFormatter.java#L122-L124响应里的suggested_amount依然是规则引擎的正确金额并携带amount_decided_by: rule_engine的溯源标记OutputFormatter.java#L147-L154全程advisory_only: true——没有任何代码路径会执行支付人工复核始终在场。换言之护栏的职责是「让风险可见、让人工去审」而不是替业务拍板。测试如何验证这套防线两个测试类是这套设计的「活文档」GuardrailCheckerTest.javaallowsTheAuthoritativeAmountToBeQuotedButRejectsConflicts同时断言了「复述权威金额放行 / 报不同数字冲突 / 不可解析值按冲突处理」treatsUnparseableExponentsAsConflicts则覆盖了畸形指数这类边界情况CompensationSuggestionApiTest.java端到端断言——即使模型返回矛盾金额响应携带的仍是规则引擎的金额且护栏失败会出现在工作流步骤中steps里可查到guardrail步骤的失败记录。本地执行./mvnw clean verify即可跑通全部 114 个测试两条工作流均有基于 stub 模型的端到端覆盖无需真实模型环境。给你的 4 条可复现经验钱相关的决策确定性逻辑拥有数字模型拥有叙述。数字可复现同订单、同政策、永远同结果解释可以便宜地错——一条弱解释浪费审核人一分钟一个错数字直接亏钱护栏校验「响应真正携带的那个值」而不是去校验一个你本就不打算采用的中间产物fail closed解析不了、比较不了的内容一律按失败处理安全边界上「误报」远比「漏报」便宜把护栏当报告、不当权威失败信号汇入approval_reasons驱动人工复核系统自身不执行任何资金动作——这也是 README 反复强调的本仓库是教学 MVP模型输出仅为建议。想动手验证可以调用赔付建议接口观察完整链路curl --fail-with-body --request POST \ --header Content-Type: application/json \ --data {order_id:DEMO-002,complaint_type:OVERTIME} \ http://localhost:8080/api/v1/analyze/compensation响应中的guardrail_passed、approval_reasons与steps里的guardrail步骤就是三重防线留下的完整证据链。【免费下载链接】delivery-harnessAI harness reference implementation for on-demand delivery workflows项目地址: https://gitcode.com/gh_mirrors/de/delivery-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考