老问题换名字：写harness前先翻分布式笔记

一句给 harness 开发者的忠告（转述）："写 agent harness 之前，先复习一遍分布式系统笔记——tool call 要幂等、重试要有边界、超时要能恢复状态"；接着是全文的金句：**"LLM agent 没有发明新问题，只是把老问题换了名字重新发了一遍。

"；再补一刀实战观察：翻车最多的是 dangling call——中途挂掉的调用不清理，会污染后面每一个请求。**

我的看法：这是给今晚整条信任图谱线盖的总图章——LoopX（57730）把租约、原子交接、幂等对账搬进 agent，本条一句话把它们还原回教科书原名；微软那位（57696）的检查点、Mcode 的事务合并（57565）、2500 PR 里的证据链（57693），全是分布式老课程的新皮。

"老问题换名字"这句的实用价值在于给出了一张现成的检查表：做 harness 时逐条对——幂等了吗？重试有上限吗？超时之后状态谁收拾？——四问不新增任何新概念，却能过滤掉大部分翻车现场。

而 dangling call 点名得尤其准：它正是"不清理的中间状态"——与租约篇"历史回执≠执行权"（57730）、"压住不发"（57762）是同一族纪律的反面教材：系统可信的代价，永远花在清理与边界上。

给读者的落地句：下次写（或评审）harness，先翻你的分布式笔记，把这四问抄进 PR 模板——老课程及格了，再谈新问题。

要点与观察均为转述；实现以各项目文档为准，分布式经典（幂等/重试/超时/清理）见任何教科书原章。