从 DeepSeek 到 Codex：用 DSCode 搭建可切换、默认隔离的本地编码 Agent 工作流
终端编码 Agent 的难点，往往不是“能不能生成代码”，而是如何把模型、权限、上下文、执行环境与成本信息放进一个可重复的工程流程。很多团队会分别使用不同供应商的 CLI：一个任务用 DeepSeek，另一个任务切到 Codex 或 Claude；会话记录散落在不同工具里，命令一旦放行又可能获得超出预期的网络或宿主机权限。
DSCode 是一个 MIT 许可证的 TypeScript 编码 Agent 运行时，默认偏向 DeepSeek，但并不把工作流锁死在单一模型上。它的定位不是宣称替代所有成熟 Agent，而是把本地会话、模型路由、补丁、权限和工具执行组织为同一套终端运行时。对于希望保留现有 AGENTS.md、CLAUDE.md、MCP 与 Git 工作方式的开发者，这种“默认本地、按需切换”的边界比单纯比较模型能力更值得关注。
先拆开：模型切换与执行授权是两回事
模型 Provider 决定请求发往何处、可使用哪些模型；权限和沙箱决定 Agent 在本机可以做什么。把二者混为一个“信任开关”，很容易出现两种极端：要么每一步都被确认打断，要么为了赶进度直接把整个工作区和网络交给 Agent。
DSCode 的默认运行时给出了一个较明确的起点：DeepSeek V4 Flash、responses 传输、minimal harness、auto 权限、workspace-write 沙箱，以及默认阻断网络。这里的关键并非某个默认模型，而是命令边界先收紧：Agent 可以在工作区写入，但网络访问不因“自动模式”自然打开。
它还把权限模式与沙箱分开描述。plan 用于只读规划；ask 要求操作批准；auto 可放行常规工作区操作，同时仍对破坏性操作、网络、宿主机访问和外部 MCP 保持门控；full 则是受信任环境下的开放模式。也就是说，选择更强的模型不必自动扩大命令权限，反过来也成立。
安装后，先用最小路径跑一次真实仓库
官方文档列出的前提是 Node.js 22.19+ 与 Git；工具也会使用 rg。全局安装后，进入目标仓库启动即可：
npm install -g @thinkany/dscode dscode -C /path/to/project
首次进入 TUI 后，可用 /login 选择并完成 Provider 认证。项目文档列出了 DeepSeek、OpenAI Codex、OpenAI、Anthropic、OpenRouter、Z.AI、Kimi、MiniMax 与 xAI/Grok 等选项。不要把这张列表理解成“所有模型的每一项功能都相同”：不同 Provider 的认证方式、可用模型和限制仍由各自账户与服务决定。
如果希望在自动化前先验证配置，不必立即让 Agent 修改代码。可以先在仓库内启动一次交互会话，检查 /status：它会显示当前模型、上下文、缓存命中、token、推理信息、估算成本和会话信息。之后再给一个有限的只读任务，例如让它解释认证流或列出测试入口；确认模型和权限状态符合预期，再进入修改环节。
用显式参数做模型切换，而不是复制另一套配置
DSCode 的价值之一，是在同一会话与工具模型下切换 Provider。下面的命令展示了在项目目录中显式指定 Codex Provider 与模型，或回到 DeepSeek 默认路径的方式：
dscode --provider openai-codex --model gpt-5.6-sol -C /path/to/project dscode --provider deepseek --model deepseek-v4-flash -C /path/to/project
命令中的模型标识是否对账户可用，应以登录后的实际可选项为准；尤其是 ChatGPT 计划访问受账户、工作区权限和服务限额影响。实际操作时，建议把“切换模型”用在任务边界上：例如先让成本较低的模型完成仓库探索、定位测试和整理变更计划，再在需要复杂重构或视觉输入时切换到对应能力可用的 Provider。这样做的重点不是把任务机械拆成“便宜模型”和“昂贵模型”，而是让每一步的能力、成本和授权范围都可观察。
本地会话不是日志附件，而是可恢复的工作状态
DSCode 将全局状态集中在 ~/.dscode，其中包括认证信息、配置、Skills、扩展、MCP、hooks 与会话历史。会话以本地树状 JSONL 保存；项目需要迁移或隔离时，可通过 DSCODE_HOME 改变全局目录，也可用 DSCODE_SESSIONS_DIR 单独迁移会话历史。
这给日常开发带来一个务实好处：同一个仓库不需要靠复制聊天记录来续接上下文。运行 --continue 或 --resume 可以接续或选择既有会话；/fork、/tree 可用于在本地会话树中导航。当某条实现路线失败时，保留原分支的推理和工具结果，另开分支验证替代方案，通常比在一条超长对话里不断覆盖前提更容易回溯。
dscode -C /path/to/project --continue dscode -C /path/to/project --resume dscode -C /path/to/project --mode json -p "检查当前改动并运行相关测试"
对于并行任务，DSCode 文档描述了 explorer、implementer、reviewer、tester 等角色，最多可并行四项任务；实现者在隔离 Git worktree 中工作，主 Agent 负责集成与最终验证。这里仍要保留工程纪律：并行执行不等于并行合并。主分支整合前，应重新阅读差异、运行与变更相关的测试，并确认多个 worktree 没有对同一配置文件作出互相冲突的假设。
沙箱的失败方式，比“自动执行”更重要
安全实践常见的误区，是只看 Agent 是否请求了确认，却忽略确认后命令会在哪里运行。DSCode 的文档说明：macOS 使用 Seatbelt；Linux 与 Windows 依赖配置的 Docker 沙箱。若没有可用的沙箱后端，工具应失败关闭，而不是静默退回到宿主机执行。
Linux 或 Windows 用户应显式提供经过审查的镜像，再启动工作区写入沙箱：
export DSCODE_SANDBOX_IMAGE="your-reviewed-image:tag" dscode -C /path/to/project --sandbox workspace-write
这段配置的含义不是“Docker 天然安全”，而是把运行依赖、挂载范围和网络策略变成可审查的基础设施。镜像中需要什么编译器、包管理器和测试工具，应由项目决定；如果测试依赖内部服务或网络下载，也应仅对该次任务最小化放行，而不是为了避免报错直接改用 --permission full。
文档同时提醒，dscode -y 会跳过工具批准、关闭沙箱并启用网络。它适合明确可信且可恢复的临时环境，不适合把来自 issue、网页或第三方仓库的自然语言任务直接投入执行。对不可信输入，先在 plan 或 ask 模式中收敛范围，再检查命令、补丁和依赖变化，是更稳妥的路径。
适合谁，以及不该期待什么
还有一个经常被忽略的操作细节：把项目级指令也视为代码审查对象。AGENTS.md、CLAUDE.md、MCP 配置和 hooks 会直接改变 Agent 的行为边界；在引入 DSCode 前，先审查这些文件是否要求读取无关目录、执行下载脚本或绕过测试。切换 Provider 后也应重新跑同一组小任务，因为模型对指令优先级、失败恢复和工具调用节奏的处理不同。用一份可重复的验收清单比较输出，比凭一次“看起来不错”的演示决定长期工作流更可靠。
DSCode 适合想把编码 Agent 的会话与执行留在本地、又需要按任务切换模型的个人开发者和小团队。它提供了与现有仓库约定衔接的能力：分层 AGENTS.md/CLAUDE.md、Agent Skills、MCP、hooks、后台任务，以及 JSONL 和 RPC 接口。项目还提供 safe harness，用于增加显式文件读取、搜索和自动化语言诊断。
边界同样需要说清：DeepSeek V4 Flash 是文本模型；图片输入需要选择支持视觉的模型。VS Code 扩展目前是本地集成，尚未发布到 Marketplace。Linux 与 Windows 的隔离质量取决于你配置的 Docker 镜像。项目也明确承认 Claude Code 与 Codex 在 IDE、云端、多模态和生态广度上更成熟。
因此，更合理的采用方式不是把 DSCode 当作“所有 Agent 的终点”，而是先在一个测试完备、可回滚的仓库中验证四件事：会话是否真的便于恢复、模型切换是否符合你的账户与成本策略、沙箱是否能运行真实测试、以及最终人工审查是否仍在合并链路中。若这四项能跑通，本地优先的多 Provider 运行时才会从一个新 CLI，变成可维护的团队工程流程。