Sirius/command-code-openai-bridge
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

适配图片

Browse Source
This commit is contained in:
Sirius
2026-08-12 16:23:52 +08:00
parent f65ac095bb
commit 995392e526
12 changed files with 821 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+55 -25
View File
@@ -1,40 +1,42 @@
# Command Code OpenAI Bridge
这是一个只绑定本机地址的 OpenAI 兼容转发服务。它实现 Chat Completions 与 Responses API 的文本对话和外部 function calling。每个生成请求启动一次独立的 Command Code headless agent，将完整消息历史通过 stdin 发送给 CLI，在当前终端显示运行过程，再把结构化事件和最终 `finalText` 转换成 OpenAI 风格的 JSON 或 SSE。
这是一个只绑定本机地址的 OpenAI 兼容转发服务。它实现 Chat Completions 与 Responses API 的文本对话、受限图片/纯文本文件输入和外部 function calling。每个生成请求启动一次独立的 Command Code headless agent，将完整消息历史通过 stdin 发送给 CLI，把附件安全落为请求专用临时文件并通过真实 `read_file` 路径交给 Command Code，再把结构化事件和最终 `finalText` 转换成 OpenAI 风格的 JSON 或 SSE。
默认地址：`http://127.0.0.1:18000/v1`
## 当前机器上的调查结论
- 系统：macOS 26.4.1 arm64。
- Node.js：v22.22.2，符合 Command Code 的 Node.js 22+ 要求。
- 安装方式：`npm install --global command-code@latest`。
- 已安装 Command Code：v1.10.0，npm `latest` 也是 v1.10.0。
- 可执行文件：`command-code`；macOS/Linux 短名为 `cmd`，Windows 短名为 `cmdc`。
- 登录：`command-code login`；检查：`command-code status --json`；本机已登录。
- npm 包没有 `exports` 字段，`main` 指向会直接启动 CLI 的 `dist/cli.mjs`，包尾直接解析命令行，没有公开、稳定的可嵌入 API。
- 官方 headless 调用：`command-code -p --output-format json`。不传查询参数时会从 stdin 读取。
- 已安装 Command Code：v1.18.0；可执行文件是全局 npm 包的 `dist/index.mjs`。
- npm 包没有公开、稳定的可嵌入输入 API。官方 headless 调用仍是 `command-code -p --output-format json`。
- `--help` 没有 `--image`、`--attachment`、文件 URL、二进制 stdin 或 JSON stdin envelope。`-p` 的参数或 piped stdin 都只是查询文本。
- 官方文档同时明确支持在提示中用 `@path/to/file` 引用工作区文件；`read_file` 会把图片真正交给原生视觉模型或 VISION 工具。普通二进制只返回 MIME 提示，PDF 当前只提示使用 `pdftotext`，并不是 PDF 内容输入。
- 真实 headless 检查使用一张四象限 PNG。`moonshotai/kimi-k2.7-code` 与 `gpt-5.6-luna` 都在 NDJSON 中实际调用 `read_file`，并正确返回 `Red, Green, Blue, Yellow`。这证明本地图片路径在 `-p --output-format json` 下会被底层模型理解，不只是把文件名写进 prompt。
- 因此 Bridge 只把经过 MIME、魔数、大小和 UTF-8 校验的数据落为工作区内临时文件，再传入 `@` 路径。它不把 base64 塞进 prompt，也不做 OCR/PDF 摘要降级。
- 远程 HTTP(S)、`file://`、任意本地路径和 `file_id` 均不接受。Bridge 完全不为附件发起网络请求，从策略上消除 SSRF、重定向和 URL token 泄漏。
- JSON 输出是 NDJSON：运行中输出 `AgentEvent`，正常情况下最后输出唯一的 `result` 行；最终回答位于 `finalText`，usage 和耗时也在该行。
- `--no-session` 让每次请求只使用内存会话，不写入或恢复跨请求 session。
- `--no-session` 让每次请求只使用内存会话，不写入或恢复跨请求 Command Code session。
- 官方 headless 模式明确不提供键盘、问题回答或权限批准等交互。原始 TTY/TUI 与可靠的独立 `finalText` 目前不能同时获得。
- 官方退出码：0 成功；1 常规错误；3 未登录；4 权限拒绝；5 限流；6 网络错误；7 服务端错误；8 达到 turn 上限；9 无回复；10 余额不足；130 被信号中断。
官方资料：
- [Quickstart](https://commandcode.ai/docs/quickstart)
- [CLI Reference](https://commandcode.ai/docs/reference/cli)
- [Headless Mode](https://commandcode.ai/docs/headless)
- [Common Workflows：文件和图片路径](https://commandcode.ai/docs/workflows)
- [Vision](https://commandcode.ai/docs/vision)
- [The Read Tool](https://commandcode.ai/docs/harness-engineering/read-tool)
- [Permissions](https://commandcode.ai/docs/core-concepts/permissions)
## 为什么使用普通子进程与结构化事件
本项目使用官方 headless 子进程和 NDJSON，不使用 PTY，也不解析 TUI 文本。
原因是 v1.10.0 没有公开嵌入 API，交互式 TUI 没有独立的结构化最终结果通道。headless 的最后一行提供稳定 `finalText`，能保证工具参数、工具结果、状态、stderr、思考事件和 ANSI 内容不会混入 API 回复。
原因是 v1.18.0 没有公开嵌入 API，交互式 TUI 没有独立的结构化最终结果通道。headless 的最后一行提供稳定 `finalText`，能保证工具参数、工具结果、状态、stderr、思考事件和 ANSI 内容不会混入 API 回复。
终端会显示：请求开始、模型、turn 状态、工具事件、工具参数、工具结果、stderr、最终回答和耗时。每个 turn 结束时还会显示本轮和服务启动以来的累计 input/output/total token；服务退出时再输出一次累计，重启后从零开始。终端不会显示原始 Ink TUI、动画、键盘快捷键、人工权限批准、人工问题回答和详细内部思考文本。
本机 v1.10.0 实测表明，headless 即使设为 `auto-accept`，shell 仍会被拒绝。默认 `dangerously_skip_permissions: true`，因此实际传入 `--yolo`，让文件写入和命令工具能继续执行。它会绕过所有权限确认，只应对可信工作目录使用。若要只读，把 `dangerously_skip_permissions` 改为 `false`，同时把 `permission_mode` 改成 `plan`。
默认 `dangerously_skip_permissions: true`，因此实际传入 `--yolo`，让文件写入和命令工具能继续执行。它会绕过所有权限确认，只应对可信工作目录使用。若要只读，把 `dangerously_skip_permissions` 改为 `false`，同时把 `permission_mode` 改成 `plan`；`read_file` 在只读模式仍可读取 Bridge 创建的附件。
## 项目结构
@@ -104,9 +106,16 @@ models:
command-default:
cli_model: deepseek/deepseek-v4-flash
effort: max
supports_image_input: false
command-vision:
cli_model: gpt-5.6-luna
effort: max
supports_image_input: true
```
`command_code_working_directory` 决定 Command Code 能看到和操作的项目目录。`response_store_directory` 保存 `store: true` 的 Response；两个相对路径都以配置文件所在目录为基准。默认存储目录是隐藏目录 `.command-code-openai-bridge/responses`。`max_concurrent_requests` 是同时运行的 Command Code 请求上限，范围 `1..64`，默认 `1`。`max_queue_size` 是等待执行的生成请求上限，不包含正在运行的请求；设为 `0` 可恢复并发槽满时立即返回 429 的行为。`stream_thinking` 控制 Chat Completions 流是否把 Command Code 思考事件包装成 `<think>` 块；默认关闭。`models.<name>.effort` 会传给 Command Code 的 `--effort`，Responses 请求中的 `reasoning.effort` 优先。可用 effort 由对应底层模型决定。服务强制只监听 `127.0.0.1`。客户端只能选择配置中的模型名，不能注入额外 CLI 参数。
`command_code_working_directory` 决定 Command Code 能看到和操作的项目目录。`response_store_directory` 保存 `store: true` 的 Response；两个相对路径都以配置文件所在目录为基准。默认存储目录是隐藏目录 `.command-code-openai-bridge/responses`。`max_concurrent_requests` 是同时运行的 Command Code 请求上限，范围 `1..64`，默认 `1`。`max_queue_size` 是等待执行的生成请求上限，不包含正在运行的请求；设为 `0` 可恢复并发槽满时立即返回 429 的行为。`stream_thinking` 控制 Chat Completions 流是否把 Command Code 思考事件包装成 `<think>` 块；默认关闭。`models.<name>.effort` 会传给 Command Code 的 `--effort`，Responses 请求中的 `reasoning.effort` 优先。可用 effort 由对应底层模型决定。
`models.<name>.supports_image_input` 默认 `false`。只有对该实际 CLI 模型完成图片路径检查后才能设为 `true`；图片请求选中未声明的模型时返回 400，不会假装模型看到了图片。`GET /v1/models` 同时返回每个映射的 `capabilities.input`。服务强制只监听 `127.0.0.1`，客户端只能选择配置中的模型名，不能注入额外 CLI 参数。
### Obsidian Copilot 流式输出
@@ -139,7 +148,9 @@ OpenCode 1.18.15 实际发送的 Chat 请求包含 `stream: true`、`stream_opti
OpenCode 还会在会话标题生成、子 agent 和后台任务等场景发起独立请求。这些请求与主 agent 请求共用同一 provider；将 `max_concurrent_requests` 设为大于 `1` 可让它们与多个会话并行执行。
已知限制：Bridge 不实现 OpenCode hosted tools、图片/音频输入、Computer Use 或 Responses `/v1/responses` 路径；OpenCode 自定义 provider 走 `/v1/chat/completions`。`temperature`、`max_tokens` 等采样参数不会传给 Command Code CLI。
示例把 `command-default` 明确声明为仅文本，把已经通过真实 CLI 检查且在 `config.yaml` 中启用的 `command-luna` 声明为 `modalities.input: ["text", "image"]`。OpenCode 只有看到该字段才会把图片转换成 Chat `image_url`；不要给 `supports_image_input: false` 的映射添加 `image`。OpenCode 会把用户图片规范化为 data URL，Bridge 不接受远程图片 URL。
已知限制：Bridge 不实现 OpenCode hosted tools、音频、视频、PDF attachment、Computer Use 或托管 File Search/Code Interpreter/Hosted Shell。OpenCode 自定义 provider 走 `/v1/chat/completions`；Responses 路径由 OpenAI SDK 等客户端使用。`temperature`、`max_tokens` 等采样参数不会传给 Command Code CLI。
## 启动、停止与重启
@@ -172,11 +183,28 @@ npm run build
`GET /health` 额外返回 `active_requests`、`max_concurrent_requests`、`queue_length` 和 `queue_capacity`；`busy` 作为兼容字段保留，等价于 `active_requests > 0`。
Bearer Token 会被忽略。所有生成接口只接受文本内容。图片、音频、文件输入和其他未实现字段会返回 OpenAI 格式的 400，`code` 为 `unsupported_parameter`；服务不会静默忽略会改变行为的参数。
Bearer Token 会被忽略。服务不会静默忽略会改变行为的参数。
### 输入能力表
| 输入 | Chat Completions | Responses | 实际传给 Command Code |
| --- | --- | --- | --- |
| 文本 | `content` 字符串或 `text` part | 字符串、`input_text`、`output_text` | UTF-8 stdin prompt |
| 图片 | `image_url.url` 的 base64 data URL | `input_image.image_url` 的 base64 data URL | 校验后写入临时 PNG/JPEG/GIF/WebP，传 `@path`，由 `read_file`/视觉模型读取 |
| 纯文本文件 | 不支持 API 附件；OpenCode `read` 工具结果仍是普通文本消息 | `input_file.file_data`，必须带 filename | 校验 UTF-8 后写入临时文本文件，传 `@path`，由 `read_file` 读取 |
| HTTP(S)、`file://`、本地路径 | 拒绝 | 拒绝 | 不联网、不读取客户端指定路径 |
| PDF、Office、任意二进制 | 拒绝 | 拒绝 | 不做伪 OCR、伪摘要或二进制转文本 |
| 音频、视频、Computer Use、托管工具 | 拒绝 | 拒绝 | 未实现 |
附件最多 16 个；单张图片解码后最多 10 MiB，单个 UTF-8 文本文件最多 5 MiB，合计最多 15 MiB，并继续受 `max_request_bytes` 限制。图片 MIME 白名单为 `image/png`、`image/jpeg`、`image/gif`、`image/webp`，声明 MIME 必须与魔数一致。临时文件权限为 `0600`，位于 `.command-code-openai-bridge/inputs` 的请求专用目录，并在成功、错误、取消或超时后从 `finally` 清理。
附件原始 data URL、base64 和 `read_file` 返回的原始文件内容不会进入 Command Code prompt、桥接终端日志或 Responses 本地存储。终端 renderer 会把附件 `read_file` 的完整 tool result 替换为脱敏标记，并递归遮蔽其他事件中的 data URL、base64、凭据和 URL 查询参数；NDJSON 解析错误也不回显原始行。模型按用户要求生成的最终回答仍会照常显示。`store: true` 只保存文本/工具历史；附件 part 被省略，因此后续 `previous_response_id` 不会伪装成仍能读取旧附件。需要再次使用时必须重新提交。
### Chat Completions
支持 `system`、`developer`、`user`、`assistant` 和 `tool` 消息。文本 `content` 可以是字符串，也可以是由 `{ "type": "text", "text": "..." }` 组成的数组；assistant 工具轮次还支持 `content: null`、`tool_calls`，tool 消息支持 `tool_call_id` 和可选 `name`。
支持 `system`、`developer`、`user`、`assistant` 和 `tool` 消息。文本 `content` 可以是字符串，也可以是由 `{ "type": "text", "text": "..." }` 组成的数组；user 消息还可包含标准 `{ "type": "image_url", "image_url": { "url": "data:image/png;base64,..." } }`。assistant 工具轮次支持 `content: null`、`tool_calls`，tool 消息支持 `tool_call_id` 和可选 `name`。
`image_url` 只接受 base64 data URL；远程 URL、`file://` 和本地路径返回 `400 unsupported_parameter`，`param` 精确指向 `messages.<i>.content.<j>.image_url.url`。`detail` 只能省略或为 `auto`，因为 CLI 没有 low/high 映射。所选模型必须配置 `supports_image_input: true`。
Chat 接口接受标准 function tools、`tool_choice` 和 `parallel_tool_calls`。Bridge 把工具定义、完整消息历史和工具结果交给 Command Code 决定下一步，校验返回的工具名与 arguments JSON Schema；第一次不合格时在原请求总截止时间内执行一次修复。工具由 API 客户端执行，Bridge 不执行客户端工具，也不直接访问 Obsidian vault。该流程适用于 Obsidian Copilot 的 `localSearch`、`readNote`、`getFileTree`、`writeFile` 和 `editFile`，也适用于其他标准 function tools。协议流程参考 [OpenAI Function calling](https://developers.openai.com/api/docs/guides/function-calling)。
@@ -203,7 +231,9 @@ Chat Completions 和 Responses 共用 Command Code NDJSON 执行层。服务终
- `tool_choice`
- `parallel_tool_calls`
`input` 可以是字符串，也可以是 item 数组。message 支持 `system`、`developer`、`user`、`assistant` 角色、字符串 content，以及 `input_text`、`output_text` part。工具轮次还支持 `function_call` 和 `function_call_output` item，分别携带 `call_id`、工具名、`arguments` 和工具执行结果 `output`。
`input` 可以是字符串，也可以是 item 数组。message 支持 `system`、`developer`、`user`、`assistant` 角色、字符串 content，以及 `input_text`、`output_text`、`input_image`、`input_file` part。工具轮次还支持 `function_call` 和 `function_call_output` item，分别携带 `call_id`、工具名、`arguments` 和工具执行结果 `output`。
`input_image.image_url` 与 Chat 一样只接受图片 data URL；`file_id`、远程 URL、`file://`、本地路径和 low/high detail 不支持。`input_file` 只接受 `file_data` 加 `filename`，其中 `file_data` 可以是严格 base64 或带受支持文本 MIME 的 base64 data URL；解码结果必须是无 NUL 的 UTF-8 文本。`file_url`、`file_id`、PDF、Office 和其他二进制会返回带准确字段路径的 400。
Responses 接受标准 function tools、`tool_choice` 和 `parallel_tool_calls`。Bridge 把工具定义、完整历史（含先前 response 的完整 output items）和工具结果交给 Command Code 决定下一步，校验返回的工具名与 arguments JSON Schema；第一次不合格时在原请求总截止时间内执行一次修复。工具由 API 客户端执行，Bridge 不执行客户端工具，也不会让 Command Code 用自身文件、终端、网络等工具替代外部 tools。该流程适用于 OpenCode 等使用 `@ai-sdk/openai` 或 OpenAI Node.js SDK 的 Responses 客户端。
@@ -348,27 +378,27 @@ command-code \
--yolo
```
随后通过子进程 stdin 写入 UTF-8 的完整请求历史。消息序列被放进一个 JSON 对象，角色、顺序、空消息、Unicode、Markdown、代码块和自定义分隔符均不会被简单文本分隔符破坏。Bridge 不总结、不删除、不截断消息。Chat Completions 不保存会话；Responses 只在 `store: true` 时保存协议对象，并在新请求中把响应链重新序列化给一个新的 `--no-session` 进程。
随后通过子进程 stdin 写入 UTF-8 的完整文本历史和不含原始数据的附件路径区块。消息序列被放进一个 JSON 对象，角色、顺序、空消息、Unicode、Markdown、代码块和自定义分隔符均不会被简单文本分隔符破坏。附件 data URL/base64 不进入该对象。Chat Completions 不保存会话；Responses 只在 `store: true` 时保存去除附件数据后的协议对象，并在新请求中把响应链重新序列化给一个新的 `--no-session` 进程。
## 有限队列和错误
同一时间最多运行 `max_concurrent_requests` 个 Command Code 实例，默认值 `1` 保持原来的单并发行为。其余 Chat Completions 和 Responses 生成请求共享同一条 FIFO 等待队列；任一执行槽释放后都会按队首顺序补齐空闲槽。默认最多等待 8 个请求，队列已满时返回 HTTP 429 和 `code: queue_full`。流式请求进入队列后会立即建立 SSE 连接；非流式请求保持等待。客户端在排队期间断开会立即移出队列，活动请求取消并结束后会推进队首请求。`timeout_seconds` 从请求取得执行位置后开始计算。
请求体超过 `max_request_bytes` 返回 413。未知模型和非文本内容返回 4xx。CLI 的详细错误留在服务终端，客户端只收到简洁的 OpenAI 格式错误。
请求体超过 `max_request_bytes` 返回 413。未知模型、未声明图片能力、无效 base64、MIME/魔数不一致、超限附件和不支持的输入来源返回 4xx，并带准确 `param`。CLI 的详细错误留在服务终端，客户端只收到简洁的 OpenAI 格式错误。
一次 CLI 异常不会结束 HTTP 服务，后续请求仍可继续。
## 本机实际检查结果
检查日期：Chat Completions 原有检查为 2026-08-04；Responses 文本子集检查为 2026-08-05；Chat function calling 协议检查为 2026-08-06；Responses function calling、OpenCode 1.18.15 Chat Completions E2E 与可配置并发检查为 2026-08-12。没有编写测试用例。原有条目来自真实 CLI 和真实 HTTP/SDK 客户端；可配置并发改动完成了类型检查、生产构建和真实 Command Code 多进程 HTTP 冒烟检查。Chat function calling 完成了内部协议冒烟检查、Obsidian Copilot 当前依赖 `@langchain/openai 1.2.2` 的双轮 wire compatibility 检查，以及真实 Command Code 与 OpenAI Node.js SDK 的双轮 HTTP/SSE 调用；尚未在 Obsidian UI 中运行完整检查。Responses function calling 完成了类型检查、生产构建、真实 HTTP 双轮检查、流式 function call SSE 检查和 OpenAI Node.js SDK 双轮检查。OpenCode 1.18.15 完成了真实 `opencode run` 文本回复、`glob` 工具循环、并行 `glob`、流式 `tool_calls`/`stop` SSE、`store: false` 与 `max_tokens` 接受、工具 Schema `$schema` 兼容，以及客户端断开后的取消恢复检查。
检查日期：Chat Completions 原有检查为 2026-08-04；Responses 文本子集检查为 2026-08-05；Chat function calling 协议检查为 2026-08-06；Responses function calling、OpenCode 1.18.15 Chat Completions E2E、可配置并发和 Command Code 1.18.0 非文本输入检查为 2026-08-12。没有编写测试用例。非文本输入先由真实 CLI 图片路径检查确认，再完成类型检查、生产构建和 Bridge HTTP 冒烟检查。
- TypeScript 严格类型检查和生产构建通过。
- npm 生产依赖审计：0 个已知漏洞。
- `/health` 返回 Command Code v1.10.0、已登录、空闲。
- `/health` 返回 Command Code v1.18.0、已登录、空闲。
- `max_concurrent_requests: 2` 时实际观察到 2 个 Command Code CLI 子进程并行运行，后续请求保持 FIFO；取消排队请求会移出队列，取消活动请求后队首请求会被推进，最终健康状态恢复为 `active_requests: 0`、`queue_length: 0`。
- `/v1/models` 返回两个本地映射。
- curl 中文请求返回 HTTP 200，客户端只收到 `中文接口成功` 和标准 completion 字段。
- 字符串 content 与 text part 数组均通过；非文本 part 返回 HTTP 400。
- 字符串 content 与 text part 数组均通过；不支持的非文本 part 返回 HTTP 400。
- system、user、assistant、user 完整历史检查返回了历史 assistant 中的 `蓝鲸-42`。
- 约 96 KiB 的中文消息通过 stdin 完整传入并返回 `长文本回退成功`，没有经过命令行参数。
- read_file 工具调用、参数和文件结果显示在服务终端，API 只返回 package name。
@@ -391,7 +421,7 @@ command-code \
- OpenAI Node.js SDK 成功消费 Responses SSE；事件顺序、递增 sequence number、多个 text delta 和最终文本均正确。
- 强制 `read_file` 的两 turn 请求只向 SSE 输出第二个无工具 turn 的 6 个文本 delta，中间工具轮次没有污染 `output_text`。
- `store: false` 的流式 Response 随后查询返回 404；删除已保存 Response 返回 deleted，随后查询返回 404。
- `input_image` 返回 400 `unsupported_parameter`，并包含准确的参数路径。
- 真实 `-p --output-format json` 图片路径检查中，Kimi K2.7 Code 和 GPT-5.6 Luna 都调用 `read_file` 并正确识别四象限颜色。
- 真实 `max_turns: 1` 工具请求返回 200 `incomplete/max_turns`；1 秒总超时返回 200 `incomplete/timeout`；主动取消返回 499 `cancelled`。
- 取消后紧接着的旧 Chat Completions 请求返回 `Chat恢复成功`，证明共享执行状态和错误恢复正常。
- Responses 第一轮 `tool_choice: required` 返回 `function_call`，`output_text` 为空；第二轮提交 `function_call_output` 和 `previous_response_id` 后返回最终 message 文本。
@@ -406,10 +436,10 @@ command-code \
- headless 无法在服务终端进行批准、拒绝、选项选择或文字回答；`ask_user_question` 不能由等待中的 HTTP 客户端处理。
- 终端事件渲染由本项目完成，格式接近日志，无法等同原始 TUI。
- 普通文本 Chat Completions 会实时转发 Command Code 文本 delta；外部 function calling 以及 Chat/Responses 结构化输出需要等待 Bridge 校验完成。
- Chat Completions 和 Responses 都只实现外部 function tools，不实现图片、音频、文件输入、Computer Use、web search 等 hosted tools 或 MCP hosted tool。非 function 工具类型返回 400 `unsupported_parameter`。Responses 不实现原生 reasoning item、加密 reasoning 或隐藏思维过程。
- Chat Completions 支持受限图片 data URL；Responses 还支持受限 UTF-8 `input_file.file_data`。不实现远程/本地路径附件、PDF/Office/任意二进制、音频、视频、Computer Use、web search 等 hosted tools 或 MCP hosted tool。非 function 工具类型返回 400 `unsupported_parameter`。Responses 不实现原生 reasoning item、加密 reasoning 或隐藏思维过程。
- Chat 与 Responses 的外部 function calling 都是 Bridge 通过提示协议、JSON 解析、工具参数 Schema 校验和一次修复实现的兼容层；Command Code CLI 没有公开原生 function calling 输出接口，因此连续两次输出不合格时返回 HTTP 502 `invalid_tool_decision`。
- Responses 的本地文件存储只供本 Bridge 使用，没有跨进程锁或多实例一致性保证；并发请求应避免同时更新同一条 Response 链。
- Chat 和 Responses Structured Outputs 都是 Bridge 层约束，底层 Command Code 模型仍可能连续两次输出不合格 JSON；Chat 此时返回 `invalid_structured_output`，Responses 状态为 incomplete。
- `usage` 使用 Command Code 最终结果提供的真实 input/output token；Responses 缺失时返回 `null`，Chat Completions 为兼容旧行为返回 0。
- 长文本受 HTTP 请求体上限和 Command Code 模型上下文上限共同限制，不会由桥接服务自行截断。
- v1.10.0 的大输入会让 `run_end.nextState` 重复完整提示词。实测约 96 KiB 中文输入时，CLI 退出前可能截断该大事件并丢掉紧随其后的 compact `result` 行。桥接服务会忽略冗余 `run_end`，优先使用 `result.finalText`；若退出码为 0 且 result 缺失，只使用最后一个已完整结束、无工具调用的结构化 turn 文本和真实 turn usage，不从 TUI 文本解析。
- 大输入会让 `run_end.nextState` 重复完整提示词。实测约 96 KiB 中文输入时，CLI 退出前可能截断该大事件并丢掉紧随其后的 compact `result` 行。桥接服务会忽略冗余 `run_end`，优先使用 `result.finalText`；若退出码为 0 且 result 缺失，只使用最后一个已完整结束、无工具调用的结构化 turn 文本和真实 turn usage，不从 TUI 文本解析。