1. 退错订单这个坏 case先别急着怪模型智商「昨天买的会员退掉」最后变成了两笔退款。事件日志里模型查到两笔候选订单后没让用户确认就调了退款接口超时后本地状态丢失恢复逻辑又当新会话重跑第二笔订单跟着被退。这种坏 case 别急着怪模型先到 TaoToken https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key把 Codex 接上再对照 harness 定位表——问题往往在运行边界不在推理能力。1.1 事故回放第一次退款成功但系统认为它没发生过把事件流按时间展开这次事故其实有五步。第一步模型收到用户工单查询后得到两笔昨日会员订单一笔是月付大会员、一笔是季付普通会员第二步模型没有列出候选订单让用户确认直接对金额更大的那笔调用了退款接口第三步外部退款系统返回成功但网络发生抖动本地没收到响应第四步任务恢复逻辑发现当前线程没有 checkpoint于是把整个任务当作新会话重新执行第五步第二次执行里模型又查了一遍订单这次按「最新一笔」选单把另一笔也退了。用户视角看到的是「想退一笔会员结果两笔都被退掉」。这里真正不对劲的不是某个推理步骤而是整个运行层没有把「第一次退款已经成功」这个事实保存下来。模型只是按上下文做出了选择后续恢复逻辑并不知道副作用已经发生。这个场景在代码 Agent 里同样常见模型改了文件、patch 已应用但事件流没写进去下次恢复把改动重复套一遍最终 diff 变得不可解释。1.2 Loop 只负责出动作harness 负责把动作接稳很多人容易把这次事故归成「模型选错订单」但这会错过真正的修复点。Agent Loop 的本质是根据当前上下文决定下一步动作循环不断重复直到任务完成、超过预算或被人工打断。它不关心动作发生之后的状态如何保存、副作用如何回滚。退款这类会改变外部状态的动作如果连幂等键都没有那问题就不是「这一步选错了」而是「这一步从头到尾没有被边界接住」。生产里判断一个 agent 是否可靠一个更稳的口径是先问它能不能解释每一步为什么发生能不能在中断后从正确的位置继续能不能在重复执行时不产生重复副作用。这三件事都不属于模型的推理能力而是运行边界的职责。所谓 harness就是把上下文构造、工具注册、policy、状态恢复、trace 这些原本零散的能力收拢成一层统一的运行边界。1.3 用定位表而不是让模型再猜一次如果直接把事故原文发给模型让它「重新分析一下」它大概率会给出一个看起来合理的订单选择方案——但这只是在上下文里多了一层猜测。排障要做的不是让模型再猜一次而是把问题拆成可以逐一验证的检查面它当时看到了什么、能调用哪些工具、policy 层是否允许直接执行、状态写到哪去了、事后能不能还原。下面这张定位表就是把这几个检查面固化成可操作的排查顺序。2. 排障第一步Codex 的 config.toml 里把 Base URL 指向 TaoToken排障工具准备好才谈得上让 Codex 查 harness 边界。这里用的是 Codex 的 CLI 形态配置写在本机不涉及外部服务。先到 TaoToken 完成注册再创建一把 API Key。Key 在本文所有配置里一律叫 YOUR_API_KEY不要写进仓库也不要贴到公开工单里。2.1 拿 Key 和模型 ID 只需要两步打开 TaoToken 后注册登录进入控制台创建 API Key得到 YOUR_API_KEY。模型 ID 不要照抄第三方博客的旧值以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场当时列表为准配置时把 YOUR_MODEL_ID 替换成广场上实际显示的模型 ID。选模型时优先看支持工具调用的型号后面要让 Codex 读文件、分析事件流纯文本对话模型可能撑不住长上下文。2.2 config.toml 里把 provider 指向 TaoTokenCodex 的配置写在~/.codex/config.toml。打开这个文件把 provider 指向 TaoTokenmodel_provider taotoken model YOUR_MODEL_ID [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY这里有三点容易踩。第一base_url 填https://taotoken.net/api末尾不要加/v1Codex 会自己处理兼容路径第二env_key 告诉 Codex 从环境变量里读 Key所以终端里要导出TAOTOKEN_API_KEYYOUR_API_KEY第三Key 和模型 ID 都来自 TaoToken 控制台和模型广场不是随便填一个官方模型的名称。导出环境变量后先用一条完全只读的请求确认线路是通的export TAOTOKEN_API_KEYYOUR_API_KEY codex 读取当前目录下的 refund_events.jsonl按时间顺序列出事件只做分析不执行任何写操作提示Codex 的权限模型里执行 bash 需要批准。这一步只允许tail、grep、cat这类只读命令看到写文件和网络请求的提案直接拒绝。2.3 排障数据先落到本地保持原始时间戳退款事件不能靠记忆描述。把这次事故的日志、事件流 JSONL、审批记录、config.toml 复制到一个临时目录命名保持原始时间戳。Codex 读取这些文件后才会有一份和线上一致的排障现场。不要把生产环境变量、私钥、外部系统密码放进这个目录避免模型输出时误带到上下文。3. bad case 定位表退款跑一半的五个 harness 检查面遇到「退款跑一半退错订单」这类事故先别急着换模型或者改 prompt按下面五个面逐项核对。每个面都能回答一个具体问题是哪一层没接住才让模型的一个普通动作变成了外部副作用3.1 上下文构造模型看到的不是一个候选订单列表事故里模型直接选了金额较大的订单退款值得先怀疑的是它根本没看到完整候选列表。如果上下文只拼了用户消息和一条模糊的订单摘要模型只能靠猜。检查 build_context 的逻辑订单查询结果有没有以结构化方式注入候选订单的金额、购买时间、会员类型有没有列全历史摘要是否被过度裁剪导致昨天的两笔订单只留下一条把进入模型的原始上下文 dump 出来看它是否包含「两笔订单」这个事实。如果只有一句「用户昨天买过会员」那模型猜单号就不是推理失误而是输入缺了关键信息。3.2 工具注册退款接口被描述成了「随手可用」第二个高频根因在工具注册表。lookup_order 和 initiate_refund 如果都在白名单里而 initiate_refund 的 schema 描述只写了「退款一笔订单」没有写明「必须确认用户指定订单后才可调用」模型就会把它当成普通查询工具一样调度。生产里应该区分 query tool 和 mutation tool查询类允许自动执行变更类默认走审批。检查工具注册表时还要看工具过滤是否生效。如果模型看到的工具列表里连「需要用户确认」的约束都没有那工具描述和过滤规则需要先补而不是让模型自己学会判断。3.3 policy 与审批多个候选订单时没有触发 askpolicy 层回答的问题是「即使模型想这么做系统允不允许」。如果策略引擎只在命中风控规则时才询问用户那么「昨天买了两笔会员、用户没有指定退哪一笔」这种常规但高风险的情况就会被直接放行。更严密的做法是把「存在多个候选订单」设成 ask 的触发条件模型必须先展示候选列表等用户确认后才能继续执行 mutation tool。排查时看审批日志确认退款动作在触发前有没有经过人工确认节点。如果没有那就不怪模型「太自信」而是 policy 少了一条规则。3.4 恢复与幂等第一次退款成功后状态丢了恢复逻辑是这次事故最微妙的地方。第一次退款其实已经成功但本地没有收到响应checkpoint 也没写盘。恢复时系统发现没有 checkpoint就把任务当成新会话重跑第二次执行又发起了一笔退款。问题不是「恢复逻辑没跑」而是它没有先确认副作用是否已经发生。这里要查两件事第一checkpoint 是否带 thread_id 持久化写入时机是在本次运行开始时还是每次工具调用后第二恢复流程有没有副作用探测——比如先查一次退款状态再决定是继续、补齐记录还是走补偿。没有幂等键的话光修重放逻辑是不够的因为网络重试同样可能把同一次退款提交两次。3.5 trace两次退款串不成一条时间线事后定位靠的是结构化事件流不是普通日志。至少要能回答第一次调用的是哪笔订单、模型输入了哪些参数、审批结果是什么、外部返回了什么、哪个环节丢失了响应。如果事件里没有 run_id、thread_id、tool_call_id或者日志里只有一行「refund success」那这次事故只能靠猜。把事件流按时间排开后第一次退款和第二次退款分别属于哪个 run、哪个 turn应该能清楚画出边界。串不起来说明 trace 层先要补结构化字段排障才有依据。五类定位表的对照关系可以整理成一张常用表退款事故里的现象harness 层优先该看什么模型没列候选订单就直接退款上下文构造订单查询结果、历史摘要、上下文裁剪退款接口和查询接口一样直接调用工具注册tool schema、query/mutation 标记、filter多个候选订单时 policy 没拦policy / approvalallow / ask / deny 规则、审批日志第一次退款成功但恢复又退一次恢复与幂等checkpoint、幂等键、effect log、副作用探测事后说不清为什么退了两单tracerun_id、thread_id、tool_call_id、事件流4. 让 Codex 带着事件记录逐项过一遍定位表TaoToken 在这里的角色是给 Codex 供模型通道harness 判断仍然要靠上面的定位表。Codex 的价值是跑腿——读文件、对配置、整理证据链顺带把可疑的代码位置标出来。全程只需要让它做只读分析和文本生成。4.1 给 Codex 的提问模板把原始报错、事件流文件路径和 config.toml 路径一起贴进 Codex让它按五个检查面输出定位报告。下面是一个可以直接用的模板请读取 refund_events.jsonl 和 ~/.codex/config.toml对照以下五点输出一份排查报告 1. 上下文构造模型在调用 initiate_refund 前输入里是否包含两笔候选订单的完整列表 2. 工具注册initiate_refund 的 schema 是否声明了「必须用户确认后调用」它和 lookup_order 的权限标记有什么区别 3. policy事件流里给第一次退款记录了什么审批结果是否存在候选订单阶段就放行 mutation tool 的路径 4. 恢复第一次退款的 checkpoint 写入成功了吗恢复逻辑是先查退款状态还是直接当作新会话重跑 5. trace用 thread_id 或 run_id 串联两次退款事件能否确认第二次退款发生在第一次响应丢失之后 只做分析和代码定位不要执行任何写操作或调用外部接口。Codex 会逐条给出证据来自哪些事件、哪段配置而不是凭感觉下结论。如果事件流里缺字段它会直接说明缺在哪一行这本身就是一次 trace 层体检。4.2 数据库状态由 Codex 生成 SQL你在本地执行退款状态可能还要和订单库对照。Codex 不能直连生产库正确做法是让 Codex 根据事件里的订单号生成只读 SQL你在本地 SQL*Plus 执行把结果贴回对话。比如它可能生成这样一条查询SELECT order_id, refund_txn_id, status, created_at FROM refund_record WHERE order_id IN (ORDER_A, ORDER_B) ORDER BY created_at;执行后把输出贴回给 Codex它会据此判断第一次退款在外部到底成功没有以及第二次退款是不是重复副作用。记住边界Codex 负责生成和解释 SQL执行永远在你自己手里如果它建议跑regsvr32、编译或直接改库一律回绝改成生成脚本由你审阅后手动执行。4.3 判定模型能力问题还是 harness 边界问题定位报告出来后用一步就能判定如果五个检查面里至少有一个缺了配置、缺了事件、缺了审批记录那问题就是 harness 边界问题先把缺的那一层补上再谈模型表现。只有当上下文完整、工具声明清晰、policy 正确拦截、checkpoint 正常写入、trace 可还原模型仍然选错订单时才值得怀疑模型能力本身。这次退款事故大概率会落在 3.3 和 3.4——policy 没在候选订单阶段触发 ask恢复逻辑没有做副作用探测。这两个都是配置和逻辑层面的问题换模型解决不了。5. 修 harness 而不是换模型给退款状态机补三道闸门5.1 退款状态机每个阶段设一道闸门把退款流程收拢成状态机模型在每个阶段能做的事和 harness 必须拦的事分开。常见关卡如下阶段模型能做什么harness 必须拦什么intent_detected判断用户是否在表达退款意图不能直接进入退款动作candidates_found展示候选订单让用户确认不能替用户选单policy_checked解释退款资格和限制不能绕过规则给承诺approval_pending等待用户或人工审批不能执行 mutation toolrefund_submitted查询退款结果、解释进度不能重复提交同一退款reconciled汇总结果并关闭任务不能丢失交易号和审计信息处在 candidates_found 阶段时即使模型非常自信地选了订单 A代码也应该拒绝调用 initiate_refund。判断逻辑写在 policy 里不放在 prompt 里。这样模型的能力边界和业务规则边界就分开了。5.2 最小 harness 四件套如果只想把改动控制在最小范围做四件事就够给工具白名单加 query/mutation 标记给 initiate_refund 这类 mutation tool 加审批规则给每次运行生成幂等键并把 checkpoint 写入 thread_id把模型输入、工具调用、审批结果、外部响应写成结构化事件。这四样已经能把一个退款 Agent 从「能跑」推进到「能审、能断、能恢复」。5.3 修复方案由 Codex 生成你审查后发布可以让 Codex 基于定位报告生成修复建议比如补 policy 规则、恢复逻辑加副作用探测、给退款调用加幂等键。生成后先由人审查再走正常发布流程不要在本地直接执行它给的整段命令。这个环节里 Codex 依然是辅助者——它负责把修改建议写清楚你负责决定改不改、怎么上线。6. 跑通排障流程后回 TaoToken 控制台对一次调用6.1 用同一把 Key 在模型对话里发条测试消息Codex 跑完一轮定位后建议把同一把 Key 放到 TaoToken 模型对话 里发一条短消息确认模型 ID 和 config.toml 里填的一致。这个动作能快速排除「模型 ID 填错但 Codex 没报错」的隐性情况。6.2 去控制台核一下这次调用的用量排障如果变成日常流程调用量会上去。用量可以从官网控制台看——https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 顶部进入也可以直接存 控制台 API Keys 这个直达链接每次 Codex 调用有没有正常计费、走的是哪个模型这里都能看到。配额不够时再看 Coding Plan以后要把同一套排障搬到 Claude Code环境变量对照写在 接入文档 里。这次退款事故最后没有升级成「换个更大模型重跑」。给 initiate_refund 加上幂等键把多候选订单的确认写进 policy再让恢复逻辑先查退款状态问题就收住了。下次再遇到类似的 bad case先别急着逼问模型为什么选错把五类 harness 边界过一遍很多玄学都会变成可改的配置项。