半夜刷 dev.to，刷到一个叫 Shot-Delivery Guardian 的仓库，Google 那个 Agentic Cinema 黑客松的产物。作者自己在文里报了两个数：真实环境跑了 5 次，3 次跟纯规则跑出来的结果对得上——60%；全部测试下来，零条规则被违反。
我第一反应：这系统要黄。
60% 放在任何一份复盘里，都像是"写完了发现不对，只好照实说"。何况还是黑客松产物，本来最有动机把数字说漂亮。
往下看，我第一反应是错的。
拍板的不是模型
先说它干嘛的。影视后期，剪辑、特效、调色、质检、交付——一堆环节全挤在同一个截止日前面，眼看要撞线，你得决定把哪一项往后挪。挪错一个，后面全塌。
这事听着简直是给 agent 量身定做的：状态模糊、判断靠经验、几个工具之间来回查。按现在的风气，下一步就该是"让模型接管排期"了。
作者偏反着来。真正拍板的不是模型，是一段固定规则：
- 客户已经点头批准的不动
- 导演标了"重要"的不动
- 有别的活儿在等它的不动
- 剩下的，按各自距离截止日的缓冲时间，从多到少排
candidates = [job for job in jobs
if not job.client_approved
and not job.director_flagged
and job.dependents == 0]
postpone = max(candidates, key=lambda j: j.buffer_left)
挑缓冲最多的那个挪走。就这。
换成我，八成会在这段规则上面再糊一层"让模型判断一下哪个更急"——然后就掉进那个经典坑里：模型给出的理由条条在理，跟规则打架的时候你信谁。作者没给自己这个机会。
那 AI 干嘛？执行这条规则，把结果原样返回，不许润色，不许跟规则争。画外音：这大概是所有 agent 系统里最没排面的一份 JD——你不是决策者，你是传声筒，还是被盯着不许自由发挥的那种。
60% 说的不是"选得好不好"
我一开始把 60% 当成了决策准确率，这是我的错。
看清结构再读这个数：决定是规则下的，AI 压根没有"选错"的余地，它只可能"没把规则的结果送到"。五次里两次不一致——作者在评论区补了一句，两次的原因都不是评分函数挑错了候选，是 agent 自己的输出在写出最终答案之前就断了。
断句，不是断判。过滤器根本没看见那个候选被否，它只是没收到候选。
换句话说，那 40% 的缺口没告诉我这套系统判断力不行，只告诉我它的输出管道不够结实。
这个失败模式我熟得不能再熟。有次我让某个 agent 批量改一批配置文件，前三个改完，第四个写了一半，JSON 尾部悬着就没下文了。我看 diff 的时候还在找"哪里改错了"，找了十分钟才反应过来——不是改错，是没写完，它话说一半被掐了 😅。
这种失败最讨厌的地方是它不在你审的那一层。code review 你盯的是逻辑对不对、边界覆盖没覆盖，而它死在你根本没想过要审的地方——输出的完整性。你是按"它会说完"这个前提去审的，而这个前提本身没被检查过。等你发现的时候，前面那十分钟已经花在了一个错误的问题上。
所以这个系统真正被 60% 戳出来的，不是"AI 会不会判断错"，是"AI 没说完整的时候，外面的东西怎么接"。它的答案是：不接，缺口报出来。
工具挂了那次
测试里有个环节，某个被调用的工具中途不可达。
系统的反应是明确报出这个缺口——哪个工具没查到，这次建议不覆盖那部分信息——然后用剩下的工具照常给出一个可推迟的建议。推荐的那一项，距离它自己的截止日还剩大约 1 小时缓冲。
我觉得这个"1 小时"比 60% 有分量得多。一个零件掉了的系统，没沉默，没猜，给出的建议里还带着一个具体的时间量，而且那个量是从剩下还能查到的工具里算出来的。它没假装自己知道全部。
我自己的话，大概率是 try/except 兜一层然后祈祷。这条我认。
平均响应 44 秒，从开始查到出结果。这个数跟上面那条放一起才有味道——44 秒里它跑了几个工具、挂了一个、报了一个缺口、又算出一个带余量的建议。整条链路里没有一步是"先出个结果糊弄过去"。
作者说他更在意零规则违反，宁可把 60% 原样写出来，也不四舍五入成"约 60%"或者"三分之二"。这我信一半——一个人真想把数字弄好看，四舍五入只是最客气的手法。但数字怎么说其实不重要。重要的是结构上他就没给自己留选错的空间：决定权不在模型这边，那它最坏也就是个传话传不到位的传声筒。
传声筒出了故障，你能 debug 它。决策者出了故障，你得先说服自己它判断错了。
我把话说偏一点
现在讲 agent 上生产，主流问法是"模型能力够不够做这个决定"。我越来越觉得问反了。
该问的是：这套系统里，哪些决定你敢钉死在一段人读得懂的代码里。
钉不死，那这个 agent 就不该上。不是"再等等模型变强"，是这套业务的边界你自己还没想清楚，模型变多强都白搭。Vlad Zoff 在评论区那句话说得比我利索——agent 能力越强，更重要的问题不是模型能不能做决定，是系统到底需不需要它做决定。
这个判断不是我今天想通的。早年我是另一个极端，什么都往 AI 手里塞，觉得规则校验是过渡期产物、早晚要拆。后来一次数据迁移的事故把我教育了。那次不是模型自作主张，是我自己没把"哪些东西绝对不能碰"写下来，写在提示词里，以为交代过了。
交代过和钉死，是两回事。提示词里的边界是建议，代码里的边界才是边界。
扯远了，回来说这个系统。它最值得抄的不是组件怎么拆，是它给 AI 划出来的那份工作说明书有多窄：执行规则、原样返回、不许争辩。窄到这个程度，99% 的能力用不上——但剩下的那 1%，反而是你敢让它在凌晨三点自己跑的部分。
Florian Bansac 在评论里问，那两次截断的失败是自动升级给人工，还是用更紧的工具预算重跑。作者没在这个点上给答案。
我也不知道选哪个。自动升级听着稳，但夜里三点谁来接；重跑听着省心，可重跑一样可能断在同一个地方。这个我到现在也没想明白，先记着。
代码开源了，MIT，repo 叫 shot-delivery-guardian。想抄组件结构的可以去抄。但我觉得真正值钱的那部分不在代码里——是在你落笔写规则之前，先逼自己回答一个问题：这个系统里，哪几个决定是我打死都不交出去的。