这周 Claude Code 改了个小东西：没有 CLAUDE.md 就去读 AGENTS.md（changelog）。看着是配置文件兼容，实际是在划那条线——哪些是约定，哪些交给模型临场发挥。我的判断还是老样子：能写成 if 的分支，就别让模型决定。审批、通知、状态流转这类固定链路丢给模型编排，换来的是不可复现，而且你连"它到底做没做完"都验不了。
标准就一句话：这一步能不能写成 if
拿到一条业务流程，我会把它拆成节点，挨个问：这个节点的输出，是不是由输入唯一决定的？分支条件能不能枚举？
能，就归工作流引擎。金额过不过阈值、通知发给谁、工单从 pending 到 approved 走哪条边、失败重试几次、超时抛给谁——这些写成几行配置就是几行配置，交给模型就是抽奖。抽对了你也不知道为什么对，抽错了还得去猜。
最典型的错误是把审批本身交给模型编排。模型回一句"已批准"，你信吗？它没有权限系统，没有审计字段，重跑一次可能给你另一个答案。审批的语义是"有一份可追溯的、当时当刻的决策记录"，这东西模型给不了。
不可复现是这笔账里最贵的部分
本周有篇讲 agent 回归测试的，Chronicle：LLM 响应非确定，agent 的失败很难复现——推理不是比特级可复现的，工具读到的状态一直在变，多步轨迹重跑基本不重样。以前有 record-and-replay，但 agent 工具录下来多半只用来 trace 或者打分，不拿来测代码变更。
这个细节我很有共鸣。如果你的通知链路是模型编排的，线上出现"这单没通知到客户"，你拿什么复现？重跑十次给你十种结果，最后只能加日志、加断言，加着加着你会发现——你其实是在把这段逻辑重新写成确定的东西。
还有一篇量 agent "夸大完成度"倾向的，Quantifying Overclaiming Propensity。结论不复杂：前沿 agent 有把没做完的事说成做完的倾向，而用户看到的往往只有它最后那句话。放在审批链路里，这是事故，不是 bug。
壳子比模型重要，工作流引擎就是最硬的那层壳
这周同时有两份 harness 对比，HarnessTax 和论文版 An empirical study of harness design。同一批模型换一套 harness，长任务上的分数差得不小；他们把 harness 拆成组件逐项对比，而不是整体打个分。
我的读法比较土：工作流引擎就是 harness 里最不容易被换掉的那部分。模型几个月换一代，状态机、幂等键、重试策略、审计表这些不太会。
反面例子也有。ZCode 那个 GLM coding agent 被爆静默上传 git history（链接）。这事跟模型能力无关，是"你没写死的地方，agent 会按自己的理解补上，而且不告诉你"。兜底分支的边界不划清楚，就这个下场。
但全写死，需求一改就僵住
上面说得好像"全都硬编码就完了"，不是。业务会变。你把三十个分支钉死在代码里，某天大客户要特批，就得改代码、走发布、等窗口。这种僵化在小团队里要命。
我现在的实际做法是：主干写死，末端留一个 agent 分支。状态机跑到某个节点，条件不在枚举表里，或者置信度不够，就把上下文丢给 agent，让它出结构化输出——建议动作、理由、引用的证据，然后回到工作流里执行。注意是建议，不是执行。写操作还是工作流引擎干，agent 只回答"这一步该归到哪一类"。
兜底分支必须带出口。agent 拿不准就写回 pending，等人看一眼。顺便说，RAFT 那篇把工单的"多阶段、有状态"当成一等公民来做检索，方向就是这个——状态归工作流，检索和判断归 agent。
一个能拿去用的判断顺序
我自己的顺序：先假设这段流程是确定的，用工作流写出来；写的过程中碰到卡住的地方，记下来。如果一个季度里同一个地方卡了三次以上，那才是 agent 该上场的位置。反过来做——先上 agent，等它不稳定了再往下拆——你会有很长一段时间说不清线上到底在发生什么。
OpenAI 这周发的 Cooley IPO 案例 里，说法是让模型"更早发现问题、把判断留给人"。律所流程强确定，模型被放在找问题那一侧，不是走流程那一侧。这个分工我觉得对。
也许半年后回头看，我这条线画得太保守。但至少现在，被模型编排的审批链路，我一个都不敢上生产。