ETF Agent Separates Cleanup From Result Settlement
An engineering analysis of ETF Agent examines why awaiting cancellation or closure can delay an already known failure, replace its error classification, or affect retry and fallback decisions. Using controlled reproductions and simplified teaching code—not a reported production incident—the analysis covers oversized web responses, HTTP 401 responses from remote MCP services, shared Wind MCP connections, retrieval fallback, and resource ownership. The reported fixes preserve the original failure classification and allow the call to settle without waiting for cleanup. However, a settled result does not prove that remote requests stopped or that all resources were reclaimed. The report also notes that HTTP classification and Host retry rules were tested separately rather than as one end-to-end 401-to-retry chain.
The analysis establishes a practical boundary for agent infrastructure: cleanup should not silently control when a business result is returned or which retry and fallback path is selected. It also shows why logical shared state and physical capacity must be handled separately; physical capacity may remain unavailable until reclamation is confirmed.
失败已经确定，为什么还返回不了？清理与结果结算的责任边界
读取网页时，响应已经超过大小上限；连接远端 MCP 服务时，服务器已经返回 401。接下来应该发生什么？
直觉上很简单：停止读取，释放资源，再告诉调用方“超限”或“需要认证”。于是代码先 await cancel()，再抛出原来的错误。它看起来很负责：失败归失败，善后总要做完。
问题恰恰出在“做完”。如果取消操作一直没有完成，已经确定的失败也交不出去；如果取消本身失败，调用方还可能收到另一个错误，并按错误的分类发起重试。
一个 await 不只安排执行顺序，也让被等待的操作参与决定：结果何时返回，以什么身份返回。 清理是否应有这份决定权，取决于接口承诺完成什么。
下面沿 ETF Agent 的 Web、MCP 与资源管理路径拆开这个问题。案例来自工程修复及受控复现，代码做了教学简化；它们说明实际依赖关系，不是线上事故的复述，也不代表公开教学仓库已包含同样实现。