Summary
问题概述
当使用 Docker runtime 运行的 Agent 输出包含多字节 UTF-8 字符的文本时,Docker 字节流可能在任意字节边界处分片,从而将一个完整的 UTF-8 字符拆分到两个输出分片中。
agent-compose 当前会将每个收到的字节分片直接转换为 Go string,并写入 protobuf 的 string 字段。如果一个中文字符或其他多字节字符恰好跨越两个分片,单个 Go 字符串就会包含无效 UTF-8,最终导致 protobuf 序列化失败。
在本次实际运行中,底层 Agent 已正常完成任务,并生成了全部预期业务输出,但 agent-compose 仍将本次 Run 标记为失败,退出码为 1。
观察到的错误:
agent execution failed: run agent stream send failed: internal: marshal message: string field contains invalid UTF-8
Steps to reproduce
- 使用 Docker runtime 启动 agent-compose v2607.7.0。
- 配置一个会输出较多中文 UTF-8 内容的 Agent。
- 启动 Agent 并保持输出流连接:
- 不进行人工干预,等待 Agent 完成任务。
- 可以观察到:Agent 自身已经完成任务并生成预期输出,但 agent-compose Run 可能被记录为
failed,退出码为 1。
该问题取决于底层字节流的实际分片边界,因此不一定每次运行都能复现。
可以通过单元测试稳定复现。以中文字符“中”为例,其 UTF-8 编码为 E4 B8 AD,将其按字节拆分后分别传给 Docker writer:
writer.Write([]byte{0xE4})
writer.Write([]byte{0xB8, 0xAD})
当前实现会分别对两个字节切片执行 string(p)。因此,第一个输出的 ExecChunk.Text 不是合法 UTF-8。
Expected behavior
预期行为
Docker 输出流不应破坏原本合法的 UTF-8 字符。
如果一个多字节 UTF-8 字符跨越底层字节读取边界,agent-compose 应暂存不完整的字节序列,并与下一分片合并后再写入 Go string 或 protobuf string 字段。
如果底层输出确实包含非法字节,也应按照明确的替换或错误处理策略生成合法文本,不应因此将一个已经完成的 Agent Run 标记为失败。
Actual behavior
实际行为
Agent 已完成任务并生成成功的业务结果,但在 provider 发出 task_complete 大约 1.4 秒后,agent-compose 记录了以下错误:
codex run failed: run agent stream send failed: internal: marshal message: string field contains invalid UTF-8
最终项目 Run 记录如下:
status: failed
exit_code: 1
error: agent execution failed: run agent stream send failed: internal: marshal message: string field contains invalid UTF-8
持久化运行状态中的时间线:
2026-07-15T05:57:04.655Z:Codex provider 发出 task_complete。
2026-07-15T05:57:06.097Z:Sandbox 发出 agent.assistant.failed。
最终落盘的 stdout、stderr 和合并输出文件均为合法 UTF-8。这与流式分片问题并不矛盾:一个原本合法的多字节字符可能在传输时被拆成两个各自非法的临时分片,而相邻分片连续写入文件后,原始字节序列又重新构成了合法 UTF-8。
Version or commit
text v2607.7.0
Runtime driver
docker
Logs
2026-07-15T05:57:04.655Z
Codex provider event: task_complete
2026-07-15T05:57:06.097027504Z
type: agent.assistant.failed
level: error
message: codex run failed: run agent stream send failed: internal: marshal message: string field contains invalid UTF-8
Final project run:
status: failed
exit_code: 1
error: agent execution failed: run agent stream send failed: internal: marshal message: string field contains invalid UTF-8
Summary
问题概述
当使用 Docker runtime 运行的 Agent 输出包含多字节 UTF-8 字符的文本时,Docker 字节流可能在任意字节边界处分片,从而将一个完整的 UTF-8 字符拆分到两个输出分片中。
agent-compose 当前会将每个收到的字节分片直接转换为 Go
string,并写入 protobuf 的string字段。如果一个中文字符或其他多字节字符恰好跨越两个分片,单个 Go 字符串就会包含无效 UTF-8,最终导致 protobuf 序列化失败。在本次实际运行中,底层 Agent 已正常完成任务,并生成了全部预期业务输出,但 agent-compose 仍将本次 Run 标记为失败,退出码为 1。
观察到的错误:
Steps to reproduce
failed,退出码为 1。该问题取决于底层字节流的实际分片边界,因此不一定每次运行都能复现。
可以通过单元测试稳定复现。以中文字符“中”为例,其 UTF-8 编码为
E4 B8 AD,将其按字节拆分后分别传给 Docker writer:当前实现会分别对两个字节切片执行
string(p)。因此,第一个输出的ExecChunk.Text不是合法 UTF-8。Expected behavior
预期行为
Docker 输出流不应破坏原本合法的 UTF-8 字符。
如果一个多字节 UTF-8 字符跨越底层字节读取边界,agent-compose 应暂存不完整的字节序列,并与下一分片合并后再写入 Go
string或 protobufstring字段。如果底层输出确实包含非法字节,也应按照明确的替换或错误处理策略生成合法文本,不应因此将一个已经完成的 Agent Run 标记为失败。
Actual behavior
实际行为
Agent 已完成任务并生成成功的业务结果,但在 provider 发出
task_complete大约 1.4 秒后,agent-compose 记录了以下错误:最终项目 Run 记录如下:
持久化运行状态中的时间线:
2026-07-15T05:57:04.655Z:Codex provider 发出task_complete。2026-07-15T05:57:06.097Z:Sandbox 发出agent.assistant.failed。最终落盘的 stdout、stderr 和合并输出文件均为合法 UTF-8。这与流式分片问题并不矛盾:一个原本合法的多字节字符可能在传输时被拆成两个各自非法的临时分片,而相邻分片连续写入文件后,原始字节序列又重新构成了合法 UTF-8。
Version or commit
text v2607.7.0Runtime driver
docker
Logs