feat: add exception details

[yuanchaoa]

This PR is for:

• Agent

[yuanchaoa]

@claude 当agent异常时上报导致异常的详细信息；帮我看一下这个pr是否有遗漏

[claude]

Claude finished @yuanchaoa's task in 10m 45s —— View job

---

- 事件：PR comment 触发，要求 review 这个 PR 是否有遗漏。 - 类型：代码 review，不做实现改动。 - 重点：`exception_description` 链路是否打通、是否还有遗漏场景、是否引入兼容性/编译问题。

进度

• 获取上下文并阅读 PR 改动
• 理解需求并确认 review 范围
• 检查是否有遗漏的异常上报场景
• 输出 review 结论与建议

Review 结论

我看下来，主链路已经接上了：agent/src/rpc/synchronizer.rs:783 会把 exception_handler.take() 返回的 exception_description 带到 SyncRequest，而且 socket/config 这类异常也开始写详细信息了。

但这个 PR 还有两个明显遗漏：

1. 有残留的旧签名调用，cfg 分支下会编译不过

   • agent/src/exception.rs:45 现在 set() 已经变成 set(Exception, Option<String>)
   • 但下面这些地方还在用旧的一参版本：
     • agent/src/trident.rs:645
     • agent/src/trident.rs:648
     • agent/src/trident.rs:652
     • agent/src/trident.rs:656
     • agent/src/utils/environment/windows.rs:49
   • 这意味着默认 Linux/CE 之外的构建（至少 enterprise / windows 分支）有机会直接挂编译。
   • Fix this →

2. “异常详细信息”覆盖还不完整，很多 agent 自身异常仍然上报 None

   • 目前补得比较多的是 controller/analyzer/integration 连接类异常。
   • 但下面这些异常仍然只置 bit，不带 detail：
     • agent/src/utils/guard.rs:137 SystemLoadCircuitBreaker
     • agent/src/utils/guard.rs:418 FreeMemExceeded
     • agent/src/utils/guard.rs:467 FreeDiskCircuitBreaker
     • agent/src/utils/guard.rs:581 LogFileExceeded
     • agent/src/utils/guard.rs:697 ThreadThresholdExceeded
     • agent/src/utils/environment.rs:123 DiskNotEnough
     • agent/src/utils/npb_bandwidth_watcher.rs:136 NpbFuse
     • agent/src/rpc/synchronizer.rs:1249 TooManyPolicies
     • agent/src/dispatcher/base_dispatcher.rs:305 / agent/src/ebpf_dispatcher.rs:493 RxPpsThresholdExceeded
   • 这些位置其实大多已经有现成上下文（当前值、阈值、目录、网卡、listener error 等），但现在 set(..., None) 之后 controller 侧还是拿不到根因细节。
   • 如果你这次的目标是“当 agent 异常时都尽量上报导致异常的详细信息”，这一块还没补完。
   • Fix this →

总结

如果这次只想先补 socket/config 类异常详情，那主思路是对的；但如果标题语义是“agent 异常时上报详细信息”，我建议至少把上面两类遗漏补掉，尤其是第 1 个编译问题。

这次我只做了 review，没有改代码。

[yuanchaoa]

@claude 看一下是否还有windows场景编译的问题

[claude]

Claude finished @yuanchaoa's task in 7m 36s —— View job

---

a. 事件：PR comment 触发，用户要求继续检查当前 PR 是否还存在 Windows 场景编译问题。 b. 类型：代码 review / 定向排查，不做实现改动。 c. 关键信息：本 PR 的核心改动之一是 `@agent/src/exception.rs:45` 将 `ExceptionHandler::set` 改为 `set(Exception, Option)`；上一次 review 提到的潜在编译点需要按当前 HEAD 重新确认。 d. 主要任务：复查当前分支上的相关文件、全局搜索所有 `exception_handler.set(Exception::...)` 调用、确认 Windows/enterprise 路径是否还有旧签名残留。 e. 计划：基于当前代码静态排查；若权限允许再补 Windows target 的 `cargo check`。这次实际结果是静态排查完成，但 job 未放开对应 Bash 权限，无法做目标平台实编译。 f. 结论：按当前 HEAD 看，之前提到的旧签名调用已经修掉了；没有再发现新的 Windows 场景签名类编译问题。

进度

• 复查 PR 上下文和相关改动
• 排查 Windows 专属代码路径里的旧调用或签名不一致
• 尝试做 Windows 目标编译验证
• 更新结论并回复到评论

结论

我按当前 HEAD 又复查了一遍，目前没再看到新的 Windows 场景编译问题。至少就这次 ExceptionHandler::set 签名变更来说，之前担心的点现在都已经补上了。

• @agent/src/exception.rs:45 现在的签名是 set(Exception, Option<String>)
• 我上次指出的几个点，在当前分支里都已经改成两参数了：
  • @agent/src/utils/environment/windows.rs:49
  • @agent/src/trident.rs:645
  • @agent/src/trident.rs:648
  • @agent/src/trident.rs:652
  • @agent/src/trident.rs:656
• 我又全局搜了 @agent/src/**/*.rs 里所有 exception_handler.set(Exception::...) 调用，没有再发现 还在用旧一参签名的地方。

补充说明

• @agent/src/trident.rs:641-656 虽然不是 Windows-only，但它在 enterprise feature 下也会参与 Windows 构建，所以之前确实会影响 Windows enterprise 编译；现在这块也已经修好了。
• 这次我没能实际跑 cargo check --target x86_64-pc-windows-gnu --features enterprise，因为当前 job 没有放开对应 Bash 执行权限；所以上面的结论是静态检查结论，不是实编译结论。

建议

如果你想把 Windows 这条链路彻底兜实，我建议再补一条目标平台检查：

cd agent && cargo check --target x86_64-pc-windows-gnu --features enterprise

如果你放开这条命令的执行权限，我可以继续帮你跑一遍做实确认。