随着 Agent 开始参与真实的软件开发代码生成已经不再是唯一需要关注的问题。Agent 是否只修改了允许的文件执行命令前有没有经过确认任务是否有明确的验收标准如果中途出现错误能不能恢复到修改前的状态这些问题决定了 Agent 能否真正进入日常开发流程。dsh-safe-workflow 是一个为 DeepSeek HarnessDSH开发的独立插件目标是为 Agent 编码过程增加任务约束、人工审批、操作记录和文件恢复能力让一次 Agent 任务从“直接执行命令”变成一个更完整、更可控的工作流。从任务契约开始在传统的 Agent 使用方式中用户通常只需要输入一句需求例如“修复这个测试失败的问题”。Agent 会自行分析代码、修改文件并运行测试。这样的方式非常方便但任务边界往往不够明确。dsh-safe-workflow引入了“任务契约”的概念。开始任务时可以明确指定当前任务的目标具体的验收标准允许修改的目录或文件哪些操作必须经过人工审批。例如一个任务可以被描述为目标修复解析器回归问题但不要修改公共 API。 验收标准 1. npm test 通过 2. npm run typecheck 通过。 只允许修改 src/ 和 test/。 修改前需要对 bash、write、edit 和 str_replace_editor 请求人工审批。这样一来Agent 不只是“尝试解决问题”而是在一个有边界、有验收条件的任务中工作。一个统一的工作流工具插件提供了一个面向模型的工具safe_workflow用于管理任务的不同阶段start创建任务契约status查看当前任务状态checkpoint保存工作区快照restore恢复指定快照verify执行验证命令并记录结果close在任务完成后关闭契约。这几个操作对应了一个比较清晰的流程创建任务 ↓ 检查任务状态 ↓ 执行代码修改 ↓ 运行验证命令 ↓ 记录验证结果 ↓ 关闭或恢复任务在实际使用中开发者可以要求 Agent 先创建任务契约再进行代码修改。完成修改后Agent 使用safe_workflow verify执行测试和类型检查只有验收标准通过后才关闭当前任务。修改文件前的审批门禁插件最直观的能力之一是在 Agent 即将执行可变更操作时提供审批门禁。它会监听包括bash、write、edit、delete、move、copy和str_replace_editor在内的工具调用。在工具真正执行前插件会根据当前任务契约检查路径和操作类型。如果当前操作需要审批DSH 会向用户展示操作内容并等待用户选择。用户可以选择批准操作也可以保持当前契约不变。对于涉及文件修改、执行脚本或批量变更的任务这一层人工确认能够降低误操作风险尤其适合处理生产代码、配置文件和包含敏感信息的项目。插件也支持不同的审批模式approvalMode:ask默认的ask模式会在需要时请求人工审批。除此之外还可以配置为allow或deny以适应不同的自动化场景。不过即使插件配置为允许执行DSH 本身的其他安全策略仍然可能继续生效。自动创建 Checkpoint仅仅在执行前请求审批还不足以解决所有问题。用户批准了一个操作并不代表后续结果一定符合预期。因此插件还支持在副作用操作执行前自动创建 checkpoint。对于带有明确文件路径的write、edit等工具插件会保存相关文件的快照。对于 shell 工具或手动创建的工作区 checkpoint则可以递归保存当前工作区中的文件同时跳过以下目录.git/ node_modules/ .dsh-safe-workflow/如果 Agent 的修改导致任务进入不可接受的状态用户可以使用restore恢复 checkpoint 中的文件。恢复过程会把快照中的文件复制回原位置同时删除快照中记录为“不存在”的文件。需要强调的是这是一种“最佳努力”的文件恢复机制并不等同于完整的事务回滚。它无法保证恢复任意 shell 命令产生的副作用也不能回滚网络请求、数据库写入、外部服务调用或进程状态。路径策略与敏感目录保护插件默认禁止访问或修改以下路径.env .env.* .git/** node_modules/**这些规则可以避免 Agent 意外读取环境变量文件、破坏 Git 元数据或修改依赖目录。任务契约还可以使用allowedPaths限制允许修改的范围例如只允许操作src/** test/** package.json对于write、edit等能够直接识别文件路径的工具插件可以较准确地执行路径检查。但对于任意 shell 命令插件无法完美推断命令内部会修改哪些文件因此 shell 工具通常需要额外的人工审批。可追溯的操作证据除了控制操作插件还会在当前 session workspace 下创建.dsh-safe-workflow/目录保存任务相关状态contract.json 当前任务契约和验证记录 audit.jsonl session、工具、checkpoint 和验证证据 checkpoints/ checkpoint 清单与文件快照其中audit.jsonl采用追加记录的形式保存操作证据。开发者可以据此了解任务执行过程中发生了哪些工具调用、创建了哪些 checkpoint、运行过哪些验证命令以及验证结果是什么。这对于排查 Agent 行为、复盘失败任务以及审查自动化流程都很有帮助。如何安装工程已提交到 GitHub路径https://github.com/cnwutianhao/dsh-safe-workflow在插件工程中先完成构建和检查npminstallnpmrun check然后从 DSH 源码工程中将插件安装到 Web profileDSH_DIR/path/to/deepseek-harnessPLUGIN_DIR/path/to/dsh-safe-workflowcd$DSH_DIRpnpmdsh plugin--profilewebadd$PLUGIN_DIRpnpmdsh--profileweb --dump-config|grepdsh-safe-workflowpnpmdsh web安装成功后可以在 DSH 的插件列表中看到safe-workflow并确认插件处于启用状态。适用场景这个插件适合以下类型的开发任务需要限制 Agent 修改范围的代码维护任务涉及配置文件或敏感目录的项目希望所有修改都经过人工确认的工作流需要记录 Agent 操作过程的团队环境希望在失败后快速恢复文件状态的实验性开发需要明确测试标准和完成条件的自动化任务。对于个人项目它可以作为 Agent 的安全护栏对于团队项目它还可以帮助建立更规范的 Agent 使用流程。仍然需要配合其他安全机制dsh-safe-workflow的定位是工作流控制和证据记录而不是完整的安全沙箱。插件运行在 DSH 宿主进程中并继承宿主进程本身的权限。因此在生产环境中使用时仍然建议审查插件源码锁定插件版本或 Git commit同时启用 DSH 自带的 sandbox 和 approval 层在不包含生产凭据的测试 workspace 中验证对重要项目使用 Git 分支或 worktree不把.dsh-safe-workflow/中的状态文件误认为完整备份。结语Agent 编码的关键问题正在从“能不能生成代码”逐渐转向“能不能安全、可控地完成任务”。dsh-safe-workflow通过任务契约、路径限制、审批门禁、自动 checkpoint、验证记录和恢复机制为 DSH 增加了一层面向开发流程的安全控制。它并不能替代操作系统级沙箱或版本控制系统但可以让 Agent 的工作过程更加透明也让开发者在自动化效率和人工控制之间取得更好的平衡。对于希望把 Agent 真正融入日常研发流程的开发者来说这类插件的价值并不只是阻止一次错误修改更重要的是建立一套可检查、可验证、可恢复的协作方式。