Bugfix: 修复llm调用抛出GeneratorExit时无trace上报的问题

[weimch]

• 原因：服务部署时，如果客户端直接断开连接，则运行中的Agent会收到协程被取消的异常，之前异常时没有上报，现在修复这个问题

[helloopenworld]

AI Code Review

我已审查 pr.diff（266 行），并核对了 _llm_processor.py、runners.py、_base_agent.py 的上下文以及 _trace.py/_metrics.py 中被调用的 trace/metrics 函数。下面是结论。

发现的问题

⚠️ Warning

• trpc_agent_sdk/runners.py:608-625：Runner 的 trace 流转重构缺少测试覆盖
  • 本 PR 将 trace_runner 从 try 末尾迁入 finally 并新增 runner_trace_recorded 标志，引入了三条新执行路径：正常完成、RunCancelledException（设标志后 finally 跳过）、以及非取消异常 / consumer 提前 aclose（finally 兜底记录）。_llm_processor.py 对等改动已补 test_partial_stream_close_traces_request_with_empty_response，但 Runner 侧无任何测试验证 runner_trace_recorded 在取消 / 异常 / 提前关闭下不重复、不漏记 trace。建议补一个用例：streaming 下 consumer 提前关闭时 trace_runner 恰好被调用一次、且与取消路径互斥。

💡 Suggestion

• trpc_agent_sdk/runners.py:608-625：异常路径下 invocation span 未标记 ERROR
  • 迁入 finally 后，非取消异常也会走到 trace_runner，但 trace_runner（见 _trace.py:106）只写正常属性、不调用 set_status(ERROR)，与取消路径的 trace_cancellation 设 ERROR 不一致，排障时失败请求的 span 可能显示成功。建议在 finally 中根据是否存在未处理异常对 invocation_span 标记 ERROR status。

总结

本次改动将 trace_call_llm / trace_runner / trace_cancellation / trace_agent 统一收敛到 finally 并通过 trace.use_span(..., end_on_exit=False) 重新进入对应 span 记录属性，正确解决了 async generator 被取消或消费者提前关闭时 trace 丢失的问题，逻辑自洽、与现有 span 生命周期一致。未发现 Critical 阻塞问题；主要缺口在 Runner 侧新流转路径的测试覆盖与异常路径 span 状态标记。

测试建议

• 建议补 Runner 侧测试：streaming 模式下消费者提前 aclose() 生成器时，trace_runner 被调用且恰好一次；以及 RunCancelledException 路径下 trace_runner 不被调用（仅 trace_cancellation）。
• 可选：验证非取消异常向上传播时 invocation span 的最终状态（与上述 Suggestion 配套）。