ETF Agent 将清理与结果结算分离
AI 总结
一项关于 ETF Agent 的工程分析考察了等待取消或关闭操作为何会延迟已经确定的失败、替换错误分类，或影响重试与降级判断。文章基于受控复现和经过教学简化的代码，而非线上事故复盘，分析覆盖网页响应超限、远端 MCP 服务返回 HTTP 401、Wind MCP 共享连接、检索降级和资源所有权等路径。报道的修复保留了原始失败分类，使调用无需等待清理即可结算；但调用完成并不能证明远端请求已经停止或所有资源均已回收。文章还指出，HTTP 错误分类与 Host 重试规则是分别测试的，尚未验证完整的 401 到重试链路。
深度见解
这项分析为智能体基础设施划定了明确边界：清理操作不应悄然决定业务结果何时返回，也不应改变重试与降级路径。文章同时说明，共享的逻辑状态与物理容量不能混为一谈；物理容量可能必须等到资源回收得到确认后才能重新使用。
失败已经确定，为什么还返回不了？清理与结果结算的责任边界
读取网页时，响应已经超过大小上限；连接远端 MCP 服务时，服务器已经返回 401。接下来应该发生什么？
直觉上很简单：停止读取，释放资源，再告诉调用方“超限”或“需要认证”。于是代码先 await cancel()，再抛出原来的错误。它看起来很负责：失败归失败，善后总要做完。
问题恰恰出在“做完”。如果取消操作一直没有完成，已经确定的失败也交不出去；如果取消本身失败，调用方还可能收到另一个错误，并按错误的分类发起重试。
一个 await 不只安排执行顺序，也让被等待的操作参与决定：结果何时返回，以什么身份返回。 清理是否应有这份决定权，取决于接口承诺完成什么。
下面沿 ETF Agent 的 Web、MCP 与资源管理路径拆开这个问题。案例来自工程修复及受控复现，代码做了教学简化；它们说明实际依赖关系，不是线上事故的复述，也不代表公开教学仓库已包含同样实现。