dsh-llm-codex-app-server

English | 中文

dsh-llm-codex-app-server 注册一个由本地登录的 Codex App Server 驱动的 DeepSeek Harness 主模型提供方。它是独立于 Harness 主仓库的组合包，因此安装时不会修改 deepseek-harness 仓库。

它与 Harness 内置的 @deepseek-ai/dsh-subagent-codex 不同。内置包将 Codex 暴露为接受委派的子 agent；本包注册到 ctx.llm，因此 Harness Agent loop 可以选择 codex-local 作为模型提供方。

工作方式

在有界缓存租约有效期间，普通 Harness 会话会复用一个固定版本为 @openai/codex@0.147.0、运行于私有空目录中的 App Server 进程和一个临时线程。该进程使用 CODEX_HOME 下的原生 Codex 账户状态；插件不会读取、复制、记录或保存 OAuth token 与 API key。没有 Session ID 的请求和辅助请求仍使用一次性进程。

适配器将 Harness 系统文本作为 App Server 的基础指令，通过在空 turn 开始前注入全部已记录的 Harness 消息来重建冷启动线程，在 App Server 的 deepseek_harness 命名空间下声明 Harness 工具，并通过原生 turn input 发送后续普通用户消息。外层 Harness 的 skill 工具在该命名空间内映射为 harness_skill；其参数 schema 只接受当前 Harness Session 目录中的名称，而 Codex 原生 skill 仍由 Codex 自己的 loader 管理。只有完整请求与预期的后续请求完全一致时才会复用热线程，否则会丢弃并重建线程。App Server 仍会加入 Codex 自有的指令和工具。这是有意设计的分层提供方，不是原始模型传输层，也不声称 Harness 取代了 Codex prompt。

推理、Assistant 文本、用量、Codex 自有上下文、诊断信息和动作生命周期会在到达时转换为 Harness 流事件。Codex 缓存输入通过 Harness 的 cacheReadTokens 上报，因此标准 token 计量器和会话统计无需提供方专用 UI 即可显示缓存命中率。每个 codex-action 块都包含 category（lifecycle、context、action 或 diagnostic）、解析后的 phase、准确的 protocolEvent 以及对应的 JSON 协议快照。即使 App Server 没有发出对应的 ThreadItem，原始 Code Mode 调用及其结果也会保留。Codex 原生动作失败或被拒绝仍属于动作结果；除非 App Server 报告整个 turn 失败，否则不会导致 Harness 模型请求失败。

在发布流事件之前，插件会解码已完成的 Codex 原生图片输出，并通过 Harness 的持久附件服务提交图片。适配器发出标准 Harness image 块供预览和下载，而动作快照与重放状态只保留小型附件标记。冷启动重建会验证附件，并且只在内存中的 App Server 请求内恢复 data URL；热 Session 续接只比较标记，不读取图片。聊天附件不等于隐式修改工作区：要生成 public/example.png 或其他项目文件，Codex 仍须为明确的目标路径请求已声明的 Harness 修改工具。

本包还包含浏览器插件。它以较低的 slot 优先级覆盖默认 Assistant 单元格，保留标准文本、推理、图片和通用回退展示，并使用 Harness 的紧凑 disclosure row 与状态点渲染 codex-action 块。折叠行显示解析后的动作、类别和阶段；展开后显示摘要、准确的协议事件、动作 ID，以及 Harness JSON tree 中的持久 JSON 记录。thread/start 会明确报告分层 prompt 所有权和发现的指令来源数量；它不会被标记为 Harness 工具或请求失败。

thread/start 块用于披露提供方生命周期，并不表示模型执行了原生动作。由 Codex 添加、且不属于注入的 Harness 历史记录的 developer、system 和 user 消息会显示为 context/injected 报告。它们会被记录以供审计，但不会在下一个无状态请求中作为 Harness 编写的历史内容再次提交。

当 App Server 请求 deepseek_harness 命名空间内的已声明工具时，适配器会发出真正的 Harness tool-call，结束当前模型 step，并保持 App Server callback 待处理。命名空间和映射后的名称必须同时匹配，调用才能进入 Harness； 还必须准确匹配当前 Harness 目录中的名称，并且只有验证后才会映射回 。即使未带命名空间的 Codex 原生调用名称与 Harness 工具相似，它仍属于提供方轨迹；只有经过验证、带 Harness 命名空间的调用才不会显示为原生动作。Harness 负责这些调用的执行、审批、展示和持久记录。后续请求完全匹配时，适配器会用已记录的工具结果回复待处理 callback，并继续同一个 Codex turn；任何不匹配都会触发冷启动重建。