作者把 agent 系统的失败拆成三层：harness 是模型之外的一切——工具、记忆、权限、trace；loop 是能真正失败的检查与反馈闭环；graph 是多个 loop 之间的依赖与状态传递。核心主张是三层各治一种病，而大多数人卡在改 prompt、换模型这两步，修的根本不是坏掉的那层。文中给出可照抄的结构：带 done_when 字段的任务契约、把 AGENTS.md 当索引而非手册、同一结果出现两次即退出并升级的重试循环，以及用 early-start test 删掉工作流里的伪依赖。作者也承认多数任务压回单个 loop 就够了，过早画十二节点图是常见错误。适合正在搭 agent 工作流、反复在 prompt 上打转的工程师。全文为二手综述，无自有实验数据或可复现案例。
一篇长推文形式的生产级 Agent 架构指南。作者的核心论点是：Agent 在多文件重构中失败，问题不在 prompt，也不在模型能力，而在模型之外的运行环境，也就是 harness。文中给出一条七阶段流水线：先由 Opus 生成 task_contract.json，划定路径白名单与预算上限；harness 用 git worktree 做物理隔离；Sonnet 只在边界内改代码；Haiku 实时校验工具调用参数；再由另一个模型扮演对抗审查者攻击 diff；pre-commit hook 校验测试退出码并签发 receipt.json；失败则结晶为规则、skill 与回归 eval。附录包含契约 JSON、isolate_worktree.sh、pre-tool.sh、回执结构和 10 项上线前自检清单，适合正在自建 coding agent 执行层、想找现成骨架对照的工程师。需要提醒的是，文中 Opus/Sonnet/Haiku/Fable 5.5 的型号命名，以及 18%→95% 的成功率数字均无出处，文末还附有 Telegram 引流链接。
作者把 agent 系统拆成两层：loop 活在节点内部，负责 produce / check / correct 直到 GREEN；graph 活在节点之间，决定有哪些工作单元、哪些能并行、结果回到哪里。核心判断是 loop 的第一性问题是「什么能失败」——写不出可被程序判定的检查条件，拿到的只是 scheduler。graph 层给出四种节点（splitter / worker / code node / gate）、两条回边（correction 短边修当前这次运行，learning 长边把被接受的结论变成 splitter 的约束），并主张闸门按爆炸半径而非模型置信度开合：迁移、删除、动钱这一类永久关闭。适合已经在跑 agent、但仍在逐步骤人肉审批的工程师。