修复 s02 工具调用中的子进程输出解码问题

[WorkHaH]

问题背景

s02_tool_use 中的 bash 工具通过 subprocess.run(..., text=True) 捕获命令输出。

在 Windows 上，text=True 会使用系统默认编码解码子进程输出，例如中文系统里通常是 GBK。
如果子进程实际输出的是 UTF-8 字节，就可能在读取 stdout/stderr 时触发解码错误。

问题表现

执行 s02_tool_use/code.py 时，某些命令输出包含 UTF-8 内容后会报错：

UnicodeDecodeError: 'gbk' codec can't decode byte ...

随后因为 stdout 读取失败，r.stdout 可能变成 None，继续拼接输出时又触发：

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

最终导致 agent loop 中断。

修复方式

将子进程输出改为先按 bytes 捕获，再显式解码：

1. 优先尝试 UTF-8。
2. 如果失败，回退到系统默认编码。
3. 如果仍然失败，使用 replacement 方式兜底，避免解码错误导致程序崩溃。

这样可以避免 Windows 默认编码和实际输出编码不一致时直接报错，同时保留对本地编码输出的兼容性。

[vercel]

Someone is attempting to deploy a commit to the crazyboym's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Gui-Yue]

@WorkHaH
感谢 PR，这个问题是合理的：subprocess.run(..., text=True) 在 Windows 中文环境下会走系统默认编码，确实可能遇到 UTF-8 输出解码失败。不过当前pr实现对 s02 这种教学代码来说有点重了：新增 decode_subprocess_output()、手动 bytes 捕获、locale fallback的实现过重。
这里我倾向于做最小修复，直接显式指定 UTF-8即可encoding="utf-8", errors="replace"。这样能解决 Windows 默认编码导致的崩溃，同时保持 s02 的代码简单。麻烦把 PR 改成这个最小版本，同步修改 s02_tool_use/code.py 和 agents/s02_tool_use.py 即可。