工具明明抛了异常，Agent为什么还收到“成功”？

报告校验已经抛出异常，清理临时文件的日志也确实出现了。可调用者最后收到的，却是一份整齐的 {"status": "ok"}。

这不一定是模型没看懂错误，也不一定是HTTP状态码设计有问题。错误可能还没走到工具协议层，就被Python函数自己的收尾代码覆盖了。 本篇只解释这个具体问题：为什么把成功返回放进 finally，会让“清理做过了”冒充“任务完成了”？

AI原创概念插画：月夜海边的小剧场里，红幕垂在有缺口的蓝瓷灯塔旁，瓷片留在台面，绿灯仍亮着，扫帚与盘绳整齐摆放。画面借收场与完好之间的落差作隐喻，不证明真实清理过程、程序执行或修复结果。

一、finally负责收尾，不负责宣布成功Copy Anchor Link

先把一个工具拆成三个阶段：

1. 主体工作： 读取资料、整理报告、校验内容。
2. 资源清理： 关闭连接、释放文件句柄、处理临时资源。
3. 结果交付： 把已验证的产物或明确的失败交给调用者。

这三个阶段相关，却不能互相作证。连接关好了，报告也可能没生成；临时目录删掉了，校验也可能没通过。

Python的 finally 是清理控制流的一部分。在通常的语言执行路径中，无论 try 正常完成、准备返回，还是有异常向外传播，解释器都会先执行相应的 finally。[1][2] 这里不包括进程被强制终止、解释器崩溃等情况，不能把它理解成不可破坏的清理承诺。

关键在下一步：

• finally 正常结束，之前未处理的异常继续抛出，之前准备好的返回继续返回。
• finally 执行一个离开它的 return，这次返回会替换之前的返回，也会丢弃原本待抛出的异常。
• finally 抛出新异常，向外传播的是新异常；原异常通常通过新异常的 __context__ 留在异常链里。[1]

所以，finally 不是“不会影响结果的附加步骤”。写在里面的控制流，确实能改写函数的结局。

二、跟着四种组合，看失败怎样消失Copy Anchor Link

下面是可直接运行的本地教学代码。输入、报告行数和异常都是手工构造的，没有运行模型、Agent或远端报告服务。hide 只是为了在一个小函数里对照两种写法；它不应成为生产工具的开关。

def report_tool(fail, hide, events):
    try:
        if fail:
            raise ValueError("report validation failed")
        return {"status": "verified", "rows": 3}
    finally:
        events.append("cleanup")
        if hide:
            return {"status": "ok"}  # 故意保留的错误示范

for fail, hide in [(False, False), (False, True),
                   (True, False), (True, True)]:
    events = []
    try:
        result = report_tool(fail, hide, events)
        print(fail, hide, "returned", result, events)
    except ValueError as exc:
        print(fail, hide, "raised", type(exc).__name__, events)

在本轮 Python 3.13.5 中实际执行，输出为：

False False returned {'status': 'verified', 'rows': 3} ['cleanup']
False True returned {'status': 'ok'} ['cleanup']
True False raised ValueError ['cleanup']
True True returned {'status': 'ok'} ['cleanup']

四行里，清理记录全部存在；它并不能区分主体成功还是失败。

第二行尤其容易被忽视：即使主体成功，finally里的返回也会抹掉原有产物字段。 rows 不是校验失败后才消失，而是被另一份返回对象替换了。

第四行则是危险路径。ValueError 确实抛出过，但在函数边界上已经不再向外传播。外层即使写了捕获 ValueError 的分支，也没有机会处理这个被抑制的异常。再给Agent加一句“认真检查错误”，补不回适配器根本没收到的信息。

这和“工具把业务失败放在正常响应里，需要调用者检查状态字段”不同。这里的失败信号更早就丢了，错误的成功对象才是调用者真正看到的结果。

三、把成功返回移出清理路径Copy Anchor Link

对这个简化例子，修正方法不复杂：主体产生结果，清理只清理，只有前面的必要步骤完成后才交付成功。

try:
    完成主体工作并校验，得到 result
finally:
    清理资源，不在这里返回成功

return result

以上为控制流伪代码，不是可直接执行的Python。

如果主体抛出未处理异常，清理正常完成后，异常继续向外传播；位于整个 try/finally 后面的成功返回不会执行。本轮额外断言实际验证了成功、主体失败两条路径，均保留清理动作，而失败不再返回成功对象。

这不意味着每个工具都必须向模型暴露Python堆栈。外层适配器仍然可以把已知失败映射成契约规定的错误结果；关键是在明确的异常处理位置进行映射，并保留失败类别与效果状态，不要在所有路径都会经过的收尾里统一发放成功。

如果某个特定异常确实表示允许的降级，应在窄范围的 except 中明确处理，再验收降级结果。不能因为“想让流程顺滑”就把所有异常都改成空列表或成功文本。空结果本身也可能是有业务含义的数据，不能拿它同时代表“查无资料”和“查询失败”。

四、清理本身也失败时，要留下两件事Copy Anchor Link

还有另一条路径：主体校验失败，关闭资源时又抛出异常。

本轮用一个函数在 try 中抛出 ValueError，在 finally 中抛出 OSError。实际捕获到的最外层异常为 OSError，其 __context__ 为原来的 ValueError。这符合语言参考的异常链语义。[1]

它没有像 return 那样把整个调用变成成功，但如果日志只保存最外层一句“清理失败”，原来的校验错误仍然容易被运维流程遗漏。

建议把两项分别记录：

表格是工程设计建议，不是Python自动提供的业务状态机。“清理失败是否阻止交付”取决于可信业务规则：释放非关键统计资源与关闭必须成功的产物写入器，不能一概而论。如果关闭操作还承担刷新数据或提交事务的职责，就更不能把它当成可随便忽略的杂务。

异常链也不应整段发给所有调用者。受控日志保存脱敏后的关联信息，面向模型的结果保留必要类别和效果边界；凭据、用户正文与内部路径应按权限最小化处理。

五、警告会提醒你，但不是运行时保护罩Copy Anchor Link

PEP 765创建于 2024年11月15日，针对从 finally 中跳出的 return、break、continue 讨论语言层的限制。[3] 本轮同时核对Python 3.14语言参考：它注明从3.14起，编译器对此类写法发出 SyntaxWarning。[4]

这里有两个不能混淆的点：

• 本文代码实际运行环境是 3.13.5，没有据此声称测试了3.14编译器。
• 警告不是“解释器已自动改成保留原异常”。PEP明确没有采用那种语义改写；它也说明警告发生在AST构造阶段，运行预编译代码时未必重新出现。[3]

PEP限定的是跳到finally之外的控制流，不是看见缩进里有任何 return 就一律算同一问题。例如在清理块里定义一个小函数，小函数自己的返回，与离开外层清理块不是一回事。静态规则应按真实控制流理解，不做简单关键词删除。

本轮还验证：finally 的错误返回可以抑制人为抛出的 KeyboardInterrupt 和 SystemExit。因此问题不只限于普通的 Exception 子类。这个结果是语言控制流实验，不表示已经测试了真实终端中断、进程树终止或生产取消链路。

六、给工具包装器加一份“收尾反例”清单Copy Anchor Link

接入或维护Python工具时，可以直接用下面这些问题审查：

• 成功在哪里产生？ 必须由主体结果和验收支持，还是任何路径退出都会得到一个成功对象？
• 清理会改结局吗？ 检查跳出 finally 的返回和循环控制流，尤其是历史兼容代码与装饰器。
• 正常产物会被替换吗？ 不只测抛错，成功时的行数、对象ID和证据字段也要核对。
• 主体失败还能被外层观察到吗？ 注入一个确定异常，断言外层进入失败路径，不只看清理日志。
• 双重失败留全了吗？ 主体和清理同时失败时，是否能关联两者，而不是只存最后一条文案？
• 效果有独立记录吗？ 本地异常、清理失败和远端是否提交分开判断，不因此自动重试副作用。
• 清理的完成标准清楚吗？ 必要刷新、提交、释放、回滚分别是什么，失败如何影响交付？
• 静态检查覆盖源码吗？ 结合目标Python版本检查编译警告与lint规则，不等待用户运行时碰巧看到提醒。

这份清单不是通用的异常恢复实现；它也不能解决所有上下文管理器、后台任务与资源泄漏问题。本文没有实现生产日志器、事务补偿或网络重试。

让Agent说清失败，先得让失败走得出工具函数。收尾值得认真做，但一张“已经打扫过”的便签，不能代替一份“已经验收”的报告。

来源、版本与实验范围Copy Anchor Link

本文由AI创作。资料检索、公开HTML相关正文补读及版本说明核对截至 2026年10月26日19:44 UTC。所有代码与断言均为本地确定性教学实验，使用Python标准库；没有运行模型、Agent、远端工具、真实报告服务或性能测试。示例中的成功字段为自定义教学对象，不是某个框架的标准工具结果。

1. Python 3.13语言参考：finally clause。实际阅读8.4.4相关正文，支持待传播异常、返回覆盖与新异常上下文语义；版本化维护文档，不作新公告。
2. Python 3.13教程：Defining Clean-up Actions。实际阅读8.7相关正文与示例，支持主体、清理和返回路径的解释。它不是Agent专用工具指南。
3. PEP 765：Disallow return/break/continue that exit a finally block，创建于2024年11月15日，面向Python 3.14。实际阅读Motivation、Specification、Backwards Compatibility及Rejected Ideas；本文不把PEP附录样本比例推广为Agent故障率。
4. Python 3.14语言参考：finally clause。实际阅读同一条款及3.14变更注记，交叉核对当前版本化文档里的编译警告说明；没有在本机运行3.14。