模型只是及格线，支架才定输赢

有篇长文把 Harness Engineering（运行时支架工程）讲透了，核心判断：模型能力只是及格线，Harness 才是产品成败的关键——长链路场景里（代码重构、多步数据分析），光挑个聪明模型配几个 Prompt 早就不够了。 它给了四件机制—— 一，上下文生命周期：任务一长历史就臃肿，全量保留既烧钱又稀释注意力，得裁决：哪些留在上下文、哪些压成摘要、哪些沉淀成外部状态按需取；二，确定性执行与安全沙箱：模型给的只是"调用意图"，鉴权、副作用隔离、执行监控、操作拦截都得支架来兜； 三，断点恢复与容错：网络波动、工具报错、人为中断难免——要有状态快照和检查点，断点重试、轨迹回放，而不是一出错就重来；四，可观测与精准调试：Agent 失败时换模型往往治不了本，起效的是改工具接口粒度、调信息注入格式、加失败兜底。 口径三条：①四件机制是它的框架、非标准定义——以各家工程实践为准；②"护城河"是它的结论——借结构不作断言；③示例场景（重构、数据分析）是举例——未验。 要抄的三条：一，先照四件套自检：上下文怎么裁、沙箱拦不拦、断点存不存、失败看不看得见；二，别迷信换模型——先查工具接口和信息格式；三，把 Prompt 调优的力气，挪一半到支架上。 夜里任务跑到一半断了、早上接着跑——四件都在，概率才算是包成了流水线。