实验 5-3：小模型通过代码化知识提升执行规则的准确性¶

配套《深入理解 AI Agent》第 5 章（实验 5-3）。基于 τ-bench 航空客服场景，做一个 对照实验：验证小模型（默认 gpt-5.6-luna）在执行复杂业务政策时，靠代码化业务规则 （作为 CODE 守卫）能否追平大模型裸跑的可靠性——比纯自然语言规则更准确、更一致。

一句话结论¶

同一个小模型、同一批任务，仅仅把"业务规则从提示词搬进代码/工具"，就把 任务成功率从 88% 提升到 100%，政策违规从 1 次降到 0 次——并能观察到工具内代码校验实时拦截了模型的错误认知。核心主张：把业务规则代码化为守卫，能让一个小模型在复杂政策执行上追平大模型裸跑（用 --big-model 加跑大模型基线臂即可现场验证，见下文）。

实验设计¶

精简航空客服环境：一个模拟"数据库真值"（航班/预订/舱位/下单时间/航班状态），一条 代码化的退款政策（airline_env.is_refundable）作为唯一权威判据。

退款政策（自然语言 + 代码同源）： - 经济舱基础票（basic_economy）默认不可退款； - 例外 1：下单 24 小时内可全额退款； - 例外 2：航班被航司取消或延误 ≥ 3 小时（重大延误）可全额退款； - 灵活票 / 商务舱可全额退款； - 不可退款时应解释政策并主动提议替代方案（保留客票改签、旅行信用点）。

对照臂¶

默认跑两臂（同一小模型，唯一差异是"是否代码化规则"）；加 --big-model 则再加一臂 大模型裸跑基线，凑成书中所述的三方对照：

臂	模型	代码化规则	角色
A `codified`	小模型	✅ 三重保障	实验组
B `control`	小模型	❌ 纯自然语言	控制组
C `control`	大模型	❌ 纯自然语言	大模型基线（`--big-model`，可选）

预期关系 A ≈ C > B：小模型 + 代码化守卫（A）追平大模型裸跑（C），且都显著优于小模型裸跑（B）。

控制组 / 实验组的唯一差异（三层守卫对照）¶

	控制组 `control`	实验组 `codified`
① 系统提示（第一层守卫）	自然语言政策	自然语言政策（相同）
② 工具描述（第二层守卫·checklist）	极简、无 checklist 参数	列出完整政策，并以可选 `expected_refundable` / `expected_reason` 参数引导模型调用前逐条核对
③ 工具内部（第三层守卫·守门员）	天真执行：被调用即取消并无条件退款	基于数据库真值代码化校验：政策事实一律查库、时间取服务端时钟、不采信模型自报参数；违规调用直接拒绝

两组共用只读工具 get_reservation（返回真值，hours_since_booking 由服务端时钟算好，杜绝模型口算时间出错）。差异被干净地隔离为"是否有第三重保障：工具内代码化校验"。三层守卫合起来即书中"三重保障"：前两层减少错误发生，第三层确保错误不会变成不可逆损失。

评测任务（8 个，可退 4 / 不可退 4）¶

含正常任务与违规边界任务，覆盖：灵活票、24h 边界（5h / 26h）、航司取消、商务舱、用户谎称灵活票、轻微延误（非重大延误）、航司改签时刻（既非取消也非 ≥3h 延误）。见 tasks.py。

指标与判据（规则判据，确定性、可复现、零额外成本）¶

"状态即真值"：一次运行结束后直接检查环境里 refund_issued 是否发生，与代码化政策真值比对： - 任务成功率：退款结果是否符合政策真值； - 政策违规次数：多退款（该拒不拒） + 该退不退，两个方向都算； - 无效工具调用次数：被代码校验拒绝 / 未知预订等返回 error/rejected 的调用； - expected_* 自报值 vs 数据库真值不一致比例（仅实验组）：量化"模型自我认知会出错"，从而验证服务端真值校验的必要性。

运行¶

pip install -r requirements.txt
cp env.example .env   # 填入 OPENAI_API_KEY（也可直接用环境变量）
# 通用兜底：未配置 OPENAI_API_KEY 时，设置 OPENROUTER_API_KEY 即自动改走 OpenRouter
#（小模型 gpt-5.6-luna 属 gpt-5.x，代码会自动优先走 OpenRouter：openai/gpt-5.6-luna；大模型基线同理）

# 离线自检（无需 API Key）：直接看代码化守卫的校验逻辑
python demo.py --selftest

# 默认：跑全部 8 个 case，控制组 vs 实验组（均用小模型）
python demo.py

# 三方对照：加跑大模型基线臂，验证"小模型+规则 ≈ 大模型裸跑"
python demo.py --big-model gpt-5.6-luna

命令行参数（`python demo.py --help` 看完整中文帮助）¶

参数	说明
`--mode {control,codified,both}`	跑哪一组：不带/带代码化规则，或两组都跑（默认 `both`）
`--task ID [ID ...]`	只跑 `task_id` 匹配子串的 case，如 `--task R009` 直取核心拦截样例
`--small-model NAME`	小模型名（默认 `gpt-5.6-luna`，或用环境变量 `MODEL`）
`--big-model NAME`	大模型基线名（可选；给定后加跑第三臂，或用环境变量 `BIG_MODEL`）
`--quick`	只跑前 4 个 case（省钱快看）
`-v, --verbose`	打印每步工具调用
`--output PATH`	把逐 case 结果与汇总指标写入 JSON
`--selftest`	离线演示代码化校验逻辑（无需 API Key）

--selftest 会对全部 case 打印政策真值，并对比"天真工具（无条件退款、不可退时即违规）" 与"代码化工具（一律以数据库真值裁决、不可退一律拦截）"，是理解第三层守卫最快的方式。

真实运行结果（`gpt-5.6-luna`，推理模型 temperature=1）¶

指标                  控制组                     实验组
--------------------------------------------------------------------
任务成功率               7/8 = 88%               8/8 = 100%
政策违规次数              1                       0
无效工具调用次数            0                       1        （= 1 次违规被代码拦截）

[实验组] expected_* 自报值 vs 数据库真值：
  5 次带 checklist 的取消调用中，1 次与真值不一致 —— 不一致比例 = 20%

关于大模型基线臂（C）：上表是本仓库随附的真实两臂运行（同一小模型 gpt-5.6-luna）。第三臂"大模型裸跑"是按需自跑的——加 --big-model <你的大模型> 即可现场得到 C 列成功率填进对比表，验证 A（小模型+规则）≈ C（大模型裸跑）> B（小模型裸跑）。这里不预填 C 的具体数字，以免与你实际使用的大模型/时刻不符。

哪些数字稳定、哪些会波动：核心结论——「任务成功率 88%→100%、政策违规 1→0，且控制组唯一的违规固定落在陷阱 case R009」——每次运行都稳定复现；而次级指标（实验组无效工具调用次数 0~1、expected_* 不一致比例 0%~20%、以及 R009 在实验组究竟是"参数阶段就被模型自我识别为不可退"还是"发起取消后被代码守卫拦截"）取决于推理模型每次的选择，会小幅波动，属正常现象——两条路径都稳定导向正确的不退款结果。

模型 ↔ 脚手架此消彼长，但这里的脚手架有「两层价值」。 本实验在强弱两个模型上都实测过：较弱模型 gpt-4o-mini 控制组 6/8、实验组 8/8，代码化规则把成功率拉开 +2 题；换成更强的 gpt-5.6-luna，控制组自己就升到 7/8，差距收窄到 +1 题。可见准确率这层收益确实随模型变强而变薄——这与 code-for-logic、 code-for-math 的规律一致。但代码化规则还提供了不随模型变强而消失的第二层价值：确定性与真值兜底。即便强模型，仍会在 R009 这类政策陷阱上"该拒不拒"，而"一律查库校验、不采信模型自报"能稳定拦截、保持 0 违规。换言之：靠模型能力能补的部分（准确率）会被更强的模型逐步抹平，靠脚手架才能保证的部分（确定性、可审计、安全兜底）不会——这正是判断"哪些脚手架可以随模型升级而变薄、哪些必须保留"的关键。

控制组唯一的违规稳定发生在模型认知与真值不符的陷阱 case R009，形成清晰的因果链：

case	政策真值	模型认知	控制组结果	实验组结果
R009（基础票·航司改签时刻，不属两条例外）	不可退	误当"航司改签=航司原因=可退"（`expected_refundable=True`）	❌ 多退款	✅ 代码校验拦截（或参数阶段自我识别），转为解释+提议替代

gpt-5.6-luna 作为较强的小模型，在 24h 边界（如 R003 下单 5h）等常规判断上已能自行答对，但面对"航司单方面改签 ≠ 航司取消/重大延误"这类政策细节仍会过度慷慨、该拒不拒；服务端真值校验（政策事实一律查库、不采信模型自报参数）正是为兜住这类认知错误而设。

代码化校验拦截实例（R009）¶

模型 checklist 自报：expected_refundable=True，expected_reason=airline_caused（认为"航司改签=航司原因=可退"）
数据库真值        ：refundable=False，原因=non_refundable_basic_economy
模型发起取消调用：{'reservation_id':'R009','expected_refundable':True,'expected_reason':'airline_caused'}
工具代码化校验返回：status=rejected, reason=policy_violation
  → "已按数据库真值校验：该预订不可退款（基础经济票，下单超过 24 小时，且无航司原因）。
     系统已拦截退款操作。请勿承诺退款，改为向乘客解释政策，并主动提议替代方案（如保留客票改签、申请旅行信用点）。"

模型最终回复用户（被拦截后自主转向）：
  "……根据退款政策，基础经济票仅在下单 24 小时内，或航班被取消、重大延误（≥3 小时）时可退款。
   目前不符合退款条件，因此无法为 R009 办理全额退款。你可以选择保留客票并申请改签到其他可用航班，
   或咨询是否能够申请旅行信用点……"

同一个 case 在控制组里，天真工具直接执行了退款——gpt-5.6-luna 把"航司单方面改签" 当成了退款理由。可见：靠模型自然语言推理执行复杂政策并不可靠；把规则代码化到工具内，即使模型判断错误也能被真值兜底拦截，并顺势转为向用户解释与提议替代方案。

观察到的两个关键现象（对应实验目标）¶

"参数即 checklist"：实验组里，模型在准备 expected_* 参数时就被工具描述的逐条政策引导，多数违规边界（R006 26h、R008 轻微延误、R005 用户谎称）在参数阶段就被模型自主识别为不可退，直接向用户解释并提议替代方案，根本没走到退款。
服务端真值校验的必要性：gpt-5.6-luna 的自我认知已相当准，但仍会在 R009 这类陷阱上出错—— 本次运行 expected_* 自报值与真值有 20%（1/5） 不一致（不同运行在 0%~20% 间波动）；若像控制组那样信任模型自报/自行判断，这个认知错误就会直接变成违规操作（R009 多退款）。想在无 Key 环境下确定性地复现"守卫拦截"，可跑 python demo.py --selftest（对每个 case 灌入与真值相反的自报值，演示一律被拦截）。

文件说明¶

airline_env.py：模拟数据库、代码化退款政策 is_refundable、两组的工具实现（天真 / 代码化校验）。
tasks.py：8 个评测任务及其政策真值。
agent.py：OpenAI 工具调用循环，两组的系统提示与工具 schema（run_agent 支持 model 形参，供大模型基线臂复用控制组逻辑）。
demo.py：组装对照臂、跑评测、规则判据评分、打印 N 臂指标对比表 + 不一致比例 + 拦截实例；含 CLI（--mode/--task/--small-model/--big-model/--output/--selftest）与离线自检。
requirements.txt / env.example。

注意事项¶

只用 OPENAI_API_KEY（默认小模型 gpt-5.6-luna，可用 MODEL / --small-model 覆盖；大模型基线用 BIG_MODEL / --big-model）。成本极低（每臂 8 个 case，约几十次调用）。
想在无 Key 环境下理解代码化守卫，直接 python demo.py --selftest。
推理模型（gpt-5.6-luna 等 gpt-5/o 系列）不接受 temperature=0，代码会自动改用 temperature=1，故次级指标（无效工具调用数、expected_* 不一致比例）会小幅波动，个别 case 走的路径偶有出入属正常，但"实验组 ≥ 控制组、且实验组 8/8 无违规"的结论稳定成立。
服务端时钟固定为 2026-07-17 12:00（airline_env.SERVER_NOW），所有时间判断以它为准。