DeepSeek Harness for GitHub
在 GitHub PR、Issue 和失败的 CI 任务中运行 DeepSeek Harness，完成审查、诊断与经验证的修复。
- Star 数
- ★ 46
- 最近更新
- 今天
- License
- MIT
- 主语言
- TypeScript
- FA 评分
- 77/100 · 表现良好
30 秒速览
- 运行形态
- 可在哪里用
- 平台专用
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 维护者希望在每个非草稿 PR 打开或更新时自动获得审查摘要和高置信度行内发现。
- 不适合
- 不使用 GitHub Actions 的团队
- 不愿向 DeepSeek 提交任务数据的团队
- 源码审查
- 77/100 · 表现良好
这个 Agent 能做什么，适合哪些场景？
这是一个社区维护的 GitHub Action，由可信 Controller 启动与 GitHub 凭据隔离的 DSH worker，并校验其结构化结果。它可响应 Issue 和 PR 中的 @dsh 评论，也可自动审查非草稿 PR；默认入门配置保持只读。工作流通过 GitHub Actions 在托管 Linux runner 上运行，使用 DeepSeek API 密钥，worker 可在 Docker 隔离环境中执行。获准的写入任务须通过可信上下文、权限、固定验证命令和验证结果等门控，之后 Controller 才能发布变更或 PR。该项目不是 DeepSeek 或 GitHub 的官方产品。
工作流触发后，Action 在可信基础分支上检出代码，通过 GitHub API 读取 PR、Issue、评论或失败检查信息，并启动不持有真实 GITHUB_TOKEN 或 DeepSeek 密钥的 DSH worker。worker 可进行代码审查、回答仓库问题、诊断 CI 失败，或在写入模式获准时提出并实施修复。Controller 校验结构化结果；写入操作还须经过权限检查和配置的验证命令，验证成功后才可发布评论、提交变更或创建 PR。入门工作流默认只读；自然语言写入需显式开启相关设置。
- 维护者希望在每个非草稿 PR 打开或更新时自动获得审查摘要和高置信度行内发现。
- 有写权限的协作者想在 Issue 或 PR 评论中用
@dsh询问仓库代码或问题。 - CI 维护者需要基于失败检查和日志诊断故障，并在可信写入工作流中验证修复。
- 团队希望把获准的 Issue 实现请求转换为经过验证的分支和拉取请求。
- 维护者需要通过 Actions 日志检查 Agent 的执行进度与失败原因。
如何安装或部署这个 Agent？
在目标仓库的本地克隆中登录 GitHub CLI，安装器会使用该仓库并在创建文件、设置密钥、提交和推送前询问。Windows 需先安装 Node.js 24 或更高版本、Git for Windows 和 GitHub CLI；macOS/Linux 使用 npm。设置时提供 DeepSeek API 密钥，安装器将其保存为仓库 Actions secret DEEPSEEK_API_KEY。也可手动创建工作流并添加同名 secret；手动工作流需配置权限和安全检出规则。
cd "C:\path\to\your-repository"
gh auth login
npm.cmd create deepseek-harness-action@latest若工作流采用自然语言写入，还需在写入工作流中启用 natural-language-write: "true" 和 allow-write: "true"，并设置仓库专属验证命令。
如何使用这个 Agent？
确保 .github/workflows/dsh-review.yml 已进入默认分支。协作者可在 Issue 或 PR 评论中发送以下请求；入门配置只读，修复类自然语言请求只会产生分析或建议，不会编辑文件。
@dsh Help me understand this issue自动审查会针对非草稿 PR 运行。查看进度和失败详情，请打开 Actions → DSH review。要请求写入，必须使用启用了写入门控和验证命令的可信工作流；例如：
@dsh Please fix this bug and open a PR这个 Agent 有哪些优点和局限？
- 把 PR 审查、CI 诊断、修复和 Issue 转 PR 集成到 GitHub Actions 工作流。
- 默认只读；写入需经过可信上下文、权限、Docker 和验证命令等门控。
- Controller 与 DSH worker 分离，真实 GitHub token 和 DeepSeek 密钥不会交给 Agent。
- 提供受信基础分支检出规则，并避免执行 fork 代码。
- 依赖 GitHub Actions 和 DeepSeek API；使用者需提供 API 密钥并承担可能产生的模型费用。
- 写入能力需要额外配置可信工作流、验证命令和权限，不能直接从只读入门配置获得。
- Action 的运行时版本与 DSH 版本有明确锁定；生产部署建议固定 Action 完整提交 SHA。
- 扩展插件和 MCP 属于可信 worker 代码；Docker 隔离不限制扩展启动或直接进程 I/O。
这个 Agent 与同类方案有什么区别？
README 将本项目与 Claude Code Action 的集成模式，以及 Codex GitHub Action 所述的执行与发布分离方式联系起来；没有给出功能或性能对比。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| DeepSeek Harness for GitHub 当前 | 77 · 表现良好 | 聊天机器人免费 + 模型费 | ★ 46 | 今天 | TypeScript | — |
| Vet 代码变更验证器 | 65 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 511 | 1 个月前 | Python | Codex · Claude Code · OpenAI API · Claude API |
| Remote SWE Agents | 66 · 存在缺口 | 自托管服务免费 + 模型费 | ★ 244 | 17 天前 | TypeScript | — |
| TAKT 工作流编排器 | 57 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 1.4k | 1 天前 | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示最小权限设计相当扎实：默认 allow-write=false、natural-language-write 独立默认关闭、strict 权限档、Docker 隔离、worker 不持有真实 GITHUB_TOKEN 与 DeepSeek key、Controller 侧凭据代理、typed github.* 精确 ID 延迟写入、fork 只检出可信 base SHA 且 persist-credentials:false。扣分点：isolation:none 与 dsh-executable 主机执行路径仍作为受信任输入存在，一旦误配即失去 OS 边界；native 模式下 bridge 网络与读写挂载是整 worker 级能力而非逐工具沙箱，文档自认扩展启动与后台进程不受 ToolRuntime 约束。用户确认方面，写入需多重显式开关与验证，但安装器会创建文件、设置 secret、提交并推送，确认流程仅在 README 中描述，未见代码级证据。数据流透明度较好：明确区分可信控制面与不可信数据、凭据路由输入、CI 日志脱敏与限长。敏感数据处理有脱敏、限长、凭据不入 argv、Session 排除凭据等说明。依赖安全方面，仓库自述 npm audit 仍非零（12 条受影响条目、5 high），存在 MCP OAuth 与 fflate 嵌套副本未修复，仅以可达性论证缓解，属已知未修复风险，故扣分。外部效应有延迟写入与验证门控，但写模式一旦开启可创建分支与 PR，回滚仅靠分支/PR 与不直接推送，未见显式回滚或撤销机制。来源归属有 MIT 与 THIRD_PARTY_NOTICES 引用，但发布者身份未经验证，归属证据仅限文档自述。
自洽性：文档对命令语义、写入门控、模式默认值的描述大体一致，但 README 与 docs 中 DSH 版本出现 0.2.1-rc.2 与依赖审计文档中的 0.2.0-rc.2 并存，存在版本叙述不一致，扣分。依赖可用性：锁定精确版本与镜像 digest 有利于可复现，但依赖审计文档自认审计非零、存在未修复嵌套依赖，且要求 Node 24 与 Docker，环境前提较重。失败消息：文档描述了失败分类、脱敏、step summary 与 result-json，但多为断言，未见具体错误码或消息样例，故仅给中等分。
受众与场景覆盖广：PR 审查、CI 诊断、自动修复、Issue→PR、通用问答、自动化 dispatch，且有中英双语文档与多份模板。能力边界说明非常充分：明确 native 非沙箱、扩展为受信任 worker 代码、Validation Integrity 非完整证明、PDF/Office 不解析等。触发精度高：明确 @dsh 行首、非引用非代码、单次提及、bot 忽略、命令首词保留等规则。环境适配扣分：强依赖 GitHub-hosted Linux runner、Docker、Node 24，自托管/企业网络需额外分段，Windows 安装步骤冗长且 PowerShell 特例较多。
信息架构清晰：README 加 docs 目录分层，含 setup/usage/configuration/security/troubleshooting/architecture 等，且有生成式输入表。安装说明详尽，含交互安装器、手动安装、恢复指引。命名稳定性扣分：安装器版本 0.7.2、Action v0.12.0、DSH 0.2.1-rc.2 多套版本号并存，且文档要求生产环境改用完整 commit SHA，命名与版本对应关系对用户不够直观。示例与 FAQ：有多个 examples 模板与 troubleshooting，但本次证据未包含 examples 文件内容，FAQ 形式不突出。已知限制写得非常充分，是明显强项。许可证为 MIT 全文，明确。版本与变更：README 引用 CHANGELOG 但未提供内容，版本号多处并存，扣分。维护责任：声明由 @Lixiaoyiao 维护、社区项目非官方，但发布者未经验证，维护承诺缺乏外部佐证。
输出可用性：结构化 schema-v1 结果、sticky comment、行内高置信度发现、step summary 与 outputs，设计面向可用；但证据未展示实际输出样例，仅链接 live runs，无法静态确认质量。边际价值：在已有 CI 与人工审查之上提供 AI 审查与诊断，价值真实但同类产品众多，差异化主要在安全边界而非能力本身。成本效益：需要 Docker、Node 24、DeepSeek API 额度与较长超时（默认 20 分钟、3 轮），对小型仓库可能偏重；文档未给出成本估算或 token 预算数据。
主张可追溯性：大量主张附有文档章节、invariants 编号、advisory 链接与复现命令，较好；但核心安全保证多为文档断言，缺少对应代码或测试证据在本次材料中呈现。交叉来源佐证：README、SECURITY、configuration、usage 之间相互印证，一致性尚可；但依赖审计文档与 README 的 DSH 版本号不一致，削弱交叉印证。事实与推断分离：依赖审计文档明确区分已修复、争议中与可达性推断，做得较好；但 live runs 与 CI 徽章属外部主张，静态审查无法核实，故不给高分。
- 依赖审计文档自认 npm audit 非零（12 条受影响条目、5 high），MCP OAuth 与嵌套 fflate 未修复，仅以可达性论证缓解；启用 Office 或自带 OAuth 的扩展前需独立评估。
- isolation:none 与 dsh-executable 会移除容器边界；native 模式下 bridge 网络与读写挂载是整 worker 级能力，扩展启动与后台进程不受 ToolRuntime 约束。
- 安装器会创建文件、写入仓库 secret、提交并推送；请在运行前确认目标仓库与变更内容，生产环境改用完整不可变 commit SHA 而非浮动 tag。
- 文档中 DSH 版本号（0.2.1-rc.2 与 0.2.0-rc.2）与安装器/Action 版本并存，升级前请核对实际锁定版本。
- 发布者身份未经验证，属社区项目；对写入模式、自托管 runner 与第三方扩展应保持额外审慎。
常见问题
运行它要付费吗？
默认会直接修改仓库吗？
它会运行来自 fork 的代码吗？
.git、无凭据的 worker；工作流不执行 fork 代码。