一个AI Agent系统里,模型负责思考,工具负责动手。听起来分工明确,但真把两套成熟系统拼在一起时,问题就来了:谁说了算?
codex-plugin-dsh 这个插件给出的答案有点反直觉——它把Codex的推理能力接进DeepSeek Harness(简称DSH),却主动禁用了Codex自带的Shell、MCP等原生工具。思考归思考,动手必须经过DSH的Tool Runtime。这种"自废武功"的设计,恰恰是整套方案的核心。
![]()
不是叠加,是划清边界
插件没有把两套工具生态简单叠加,而是规定了谁负责思考、谁负责动手。Codex在系统里只扮演一个角色:推理引擎(Provider)。它负责模型推理、账户认证和原生的图像生成能力。而DSH则牢牢掌控着会话持久化、工具组装、权限策略和执行日志。
这种职责划分避免了一个常见陷阱:两套系统争夺工具控制权。如果Codex能直接调用工具,DSH的权限管控就形同虚设,执行记录也会出现分叉。插件通过禁用Codex原生工具,把所有环境动作强制收拢到DSH的工具运行时里,确保权限检查和调度都在一个闭环内完成。
账号复用:不存密钥,只借状态
另一个值得注意的设计是账号复用机制。插件直接复用宿主机上 codex login 的登录状态,不需要在DSH里重复配置或存储API Key。这意味着用户既不用再填一遍密钥,也降低了密钥泄露的风险——凭证只存在于本地,不经过DSH的配置层。
这个细节解决了实际痛点:很多Agent系统集成时,最麻烦的就是账号体系打通。要么重复配置密钥,要么在多个系统间同步登录状态。codex-plugin-dsh 选择了一条更轻的路径:既然Codex已经在本地登录过了,DSH直接借用这个状态即可。
上下文管理:Thread ID 与状态回放
多轮对话的上下文管理也是这套方案的重点。插件通过将App Server的Thread ID和Turn ID写入DSH的Model Replay State,实现了跨工具步骤的连接存活,以及会话的精准Checkpoint回放。
这意味着什么?当一次任务涉及多个工具调用时,系统能准确知道每一步的状态,即使中途出错,也能从最近的检查点恢复,而不是从头再来。这种机制让长任务的稳定性有了保障。
安装与部署:本地Provider通道
从实现机制上看,插件将本地Codex CLI注册为DSH的标准LlmAdapter路由,使Codex成为会话的主模型,而非简单的子Agent。这种架构让Codex的推理能力与DSH的治理能力各司其职,互不干扰。
它解决的不是单次调用,而是运行时归属。账号、会话、工具、权限和进程,每一层的归属都被认真处理过。对于正在搭建Agent工作台的团队来说,这种"推理与控制解耦"的思路,或许比堆叠更多功能更有参考价值。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.