如果预算只够认真做一层，我会优先补检查点与失败接管这一层。原因是：线上“模型变强但成功率不动”，往往不是推理能力不够，而是失败后无法收敛与恢复（超时、工具副作用、状态丢失导致反复重试）。有了检查点与可恢复状态，Agent 才能在预算耗尽、工具失败、异常注入时降级退出、回滚或续跑；这直接提升稳定性与可用性。权限清单与评测隔离也重要，但它们通常是“优化与治理”，而检查点/失败接管是“生存底座”。

生产级 Harness 里，我最不建议省的是独立验证层，而不是更花哨的调度或更多 Skill。流程可以先做粗糙版，工具也可以先少接几个，但只要 Agent 还在给自己打分、自己宣布完成，系统就会在“看起来很忙、其实没做对”上越跑越远。验证层的最低配很朴素：用另一套规则或另一个角色看结果，失败就回滚或重开，而不是让同一个生成回路既当选手又当裁判。这一层在，模型怎么换都还守得住；这一层没了，后面加再多能力都只是放大自我欺骗。

Harness 工程本质上不是又一个 Agent 框架，而是把模型外面那圈“能做什么、做到哪了、做错了怎么收场”做成硬约束。我自己的判断标准很简单：换一个更弱的模型，任务成功率掉多少——掉得少，说明 harness 在扛事；掉得多，说明你其实还在靠模型运气。所以看 harness，别先看它封装了多少工具，先看权限边界、状态恢复和失败接管这三层有没有真正落到执行路径上。