插件目录 / Developer / deepseek-harness-action
deepseek-harness-action
已验证 · 实测可装 Lixiaoyiao
功能简介
DeepSeek Harness社区GitHub Action——AI代码审查·CI诊断·自动修复·Issue转PR
可用 — 实测通过,早期项目
DeepSeek Harness社区GitHub Action——AI代码审查·CI诊断·自动修复·Issue转PR 实测能干净安装、正常启动。早期项目,但功能可用。
「已验证」表示我们的自动化 CI 在干净 profile 里实际执行了 dsh plugin add 并启动成功——仅此而已。功能描述与版本兼容性均为作者声明。这不是安全审计,也不代表对第三方代码的背书。
README
DeepSeek Harness for GitHub
Run DeepSeek Harness directly from GitHub pull requests, issues, failed CI jobs, and maintainer-authored automations.
GitHub PR / Issue / CI → DeepSeek Harness → Review / Diagnose / Fix / Issue → PR
The Action starts a credential-isolated DSH worker, validates its structured result, and lets a trusted Controller publish comments or validated changes. This is a community project, not an official DeepSeek or GitHub product. It is maintained by @Lixiaoyiao.
Core capabilities
| Capability | What it does |
|---|---|
| Pull request review | Reviews new commits, publishes one summary, and adds high-confidence inline findings |
| General tasks | Answers repository questions or performs an explicitly authorized coding task |
| CI diagnosis and repair | Reads failed checks and logs; trusted workflows may validate and publish a fix |
| Issue implementation | Turns an authorized Issue request into a validated branch and pull request |
| Composition modes | Keeps the existing controlled tool profile by default and offers an experimental native DSH mode |
| Controlled tools | Adds exact profiles for native, fixed-command, typed Controller GitHub, MCP, Bundle, and Plugin tools |
| Structured results | Keeps the schema-v1 audit envelope and can validate an optional maintainer-defined task result |
v0.9.0 retains the experimental dsh-mode: native path over the locked DSH 0.1.7-rc.2 runtime and its official ecosystem composition. Native MCP servers, Profile Bundles, direct Cordis Plugins, repository Skills, Subagents, and Workflows retain DSH-native discovery and behavior. controlled remains the compatible default, so workflows that omit dsh-mode retain their existing composition, permissions, tools, budgets, receipts, and outputs.
Native mode is not an unsafe mode. It returns ownership of DSH's internal headless composition, capability graph, and model-visible inventory to DSH. Native MCP servers load through official @deepseek-ai/dsh-mcp-client; Bundles become official Profile layers; direct Plugins load through Cordis; and repository Skills, Subagents, and Workflows retain DSH-native behavior. Its definition-only extension schema declares owners and process requirements, not Action tools, grants, or per-tool budgets. Dynamic ecosystem tools appear only in runtime observedTools, and native toolPolicy never claims Controller effectiveTools.
The Action still owns trusted-workflow admission, exact package pins, lifecycle-script suppression, runtime inventory audit, Docker and .git-less workspace boundaries, the run-scoped DeepSeek credential proxy, GitHub credential isolation, actor/repository trust, validation and deferred writes, deadlines, cancellation, and secret redaction. Native remains Docker-only. Bridge network and read/write mounts are whole-worker capabilities, not per-extension or per-tool sandboxes. A user-configured GitHub MCP with its own credential is a trusted external extension whose direct effects do not receive the Controller Gateway's binding, revalidation, validation, or deferred-mutation guarantees. Controller-owned command.* and github.* capabilities remain a separate, mode-independent plane.
v0.9.0 targets the fixed DSH 0.1.7-rc.2 migration candidate. Version selection alone is not a support declaration: qualification must cover the exact candidate SHA through the release process. The migration preserves existing inputs, outputs, permissions, and business paths. A bounded, tool-free result repair never reruns the worker task; valid Headless NDJSON or final events still require strict Controller schema and business validation. This work adds no cross-run Session/Resume, file/image input, Agent Teams, Browser/Computer Use, or new GitHub capability. The v0.8.2 release and tag remain unchanged.
Live runs
These public runs show the comments and Actions logs produced by this repository.
| Scenario | Run |
|---|---|
| PR review, including a rerun without duplicate comments | PR #3 · Actions run |
| Diagnosis based on failed checks and logs | Actions run |
| Fix and validation in trusted write mode | Actions run |
| Issue implementation followed by a pull request | Issue #4 → PR #5 |
Quick Start
Run the installer from the root of the repository you want to configure:
npm create deepseek-harness-action@latest
Choose one of these modes:
- PR Review creates
.github/workflows/dsh-review.yml. - @dsh Coding Commands creates
.github/workflows/dsh-commands.yml. - Both creates both workflow files.
For CI or another non-interactive environment, pass the mode explicitly so the installer never waits for stdin:
npm create deepseek-harness-action@latest -- --mode both
For non-interactive use, omitting --dsh-mode keeps the compatible controlled
default. The interactive flow asks explicitly; choose Controlled there unless
native composition is intended:
npm create deepseek-harness-action@latest -- --mode both --dsh-mode native
The installer creates .github/workflows/ when needed and refuses to overwrite
an existing target workflow. It does not add secrets, commit or push changes,
or open a pull request. Installer v0.3.0 is prepared for the formal v0.9.0
release. After its tag, GitHub Release, and release canary agree, the verified
immutable Action commit is supplied through DSH_ACTION_RELEASE_SHA when
packing. Generated workflows never use a candidate SHA, floating tag, or branch.
After installation, add DEEPSEEK_API_KEY under Settings → Secrets and variables → Actions. Open or update a non-draft pull request to trigger Review. For Coding Commands, put an @dsh command on the first line of an Issue or pull request comment. See Setup for the complete onboarding and security guide.
Manual installation
Add DEEPSEEK_API_KEY under Settings → Secrets and variables → Actions, then create .github/workflows/dsh-review.yml:
name: DSH review
on:
pull_request_target:
types: [opened, synchronize, ready_for_review, reopened]
permissions:
contents: read
pull-requests: write
jobs:
review:
if: github.event.pull_request.draft == false
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
with:
ref: ${{ github.event.pull_request.base.sha }}
persist-credentials: false
fetch-depth: 1
- uses: Lixiaoyiao/[email protected]
with:
deepseek-api-key: ${{ secrets.DEEPSEEK_API_KEY }}
dsh-version: 0.1.7-rc.2
Open a non-draft pull request. The Action checks out only the trusted base SHA, reads the pull request through GitHub APIs, and never executes fork code.
For production, replace v0.9.0 with the full immutable release commit SHA. See Setup for permissions, pinning, checkout rules, and complete templates.
Common @dsh commands
Put the command on the first line of an Issue or pull request comment.
| Command | Purpose |
|---|---|
@dsh task --read <question> |
Explain code, inspect the repository, or answer a general question |
@dsh task --write <task> |
Request a coding task; every write gate must still pass |
@dsh review |
Review the current pull request again |
@dsh diagnose |
Diagnose failed checks and logs |
@dsh fix |
Repair a same-repository pull request in trusted write mode |
@dsh implement |
Implement an Issue and open a pull request |
--write, fix, and implement request capabilities; they do not grant them. The workflow must explicitly enable write mode and provide Controller-run validation. See Usage for commands and automation, and Configuration for the gates.
Maintainers can change the trigger phrase, add label/assignee routes, filter actors or historical comments, select a base branch, and choose a deterministic branch template. These settings change routing and naming only; GitHub authority still comes from the Controller policy and workflow token scopes.
Security
- The Agent receives neither the real
GITHUB_TOKENnor the real DeepSeek key. Only the Controller can call Action-ownedgithub.*mutation APIs; an explicitly configured external GitHub MCP uses its own credential and authority as described below. - Repository content, diffs, issues, pull requests, comments, logs, model output, and tool output remain untrusted data.
- Fork review uses a
.git-less, credential-free worker and must check out only the trusted base SHA withpersist-credentials: false. - Writes require a trusted same-repository context, authorized actors, Docker,
allow-write: "true", non-empty fixed validation commands, and successful validation. Protected-path and Validation Integrity checks still apply. - Typed
github.*mutations are exact-ID, entity-bound, deferred until Controller validation, and reconciled with bounded receipts. No arbitrary REST, GraphQL, URL, or credential pass-through exists. - Validation Integrity provides high-confidence weakening detection plus baseline replay for its supported entrypoints, scripts, test/config weakening, lock/toolchain controls, and known wrappers/interpreters; it is not complete cross-language dependency provenance or a formal proof.
- Validation may use Docker bridge networking. On self-hosted or corporate-network runners, repository validation code may reach runner-accessible network services; use dedicated runners and runner-level segmentation/egress controls.
- An approved Bundle, Plugin, or stdio MCP server is trusted worker code. Controlled ToolRuntime limits model-routed calls; native leaves routing and inventory to DSH. Neither model is a sandbox for extension startup, background work, or direct process I/O, and any bridge/RW capability applies to the whole worker.
github.*uses the Controller GitHub Gateway. A separately configured GitHub MCP uses its own external credential and is outside the Gateway's binding, revalidation, validation, and deferred-write guarantees.
Read the complete Security policy before enabling write mode, host execution, network access, or third-party extensions.
Documentation
| Guide | Contents |
|---|---|
| Setup · 中文 | Installer, manual setup, Secret, permissions, safe checkout, and templates |
| Usage · 中文 | @dsh commands, tasks, review, diagnose, fix, implement, and automation |
| Configuration | Inputs, permission profiles, tools, validation, extensions, and outputs |
| Architecture · Invariants | Component ownership, authority boundaries, and stable system invariants |
| Troubleshooting | Denials, Docker, timeouts, cancellation, validation, and extension failures |
| Security policy | Trust model, credential boundaries, network behavior, and known limitations |
| Extension contracts | Deep technical contracts for MCP, Profile, Bundle, Plugin, ToolRuntime, and receipts |
| Maintainer release guide | Local checks, Core E2E, release canary, version updates, and publishing |
| Contributing · Changelog | Development workflow and release history |
Development
Node.js 24 is required.
npm ci
npm run check
See CONTRIBUTING.md. The Marketplace dist/ bundle is committed for releases and must not be edited by hand.
License
MIT. Third-party licenses are listed in THIRD_PARTY_NOTICES.md and BUNDLED_DEPENDENCIES.md.
DeepSeek Harness supplies the headless runtime and official extension mechanisms. The GitHub integration also draws on the MIT-licensed Claude Code Action patterns and the execution/publication separation described by Codex GitHub Action; exact attributions are recorded in the third-party notices.
安装
装一次目录插件,之后本站所有插件都能让 DeepSeek Harness 自动找、自动装:
dsh plugin add dshbase-catalog 然后对 agent 说「帮我装 deepseek-harness-action」,它会在目录里找到并自动安装。文档:dshbase-catalog · 已验证场景包。
该插件是 GitHub 源码(未发 npm)——直接从仓库装:
Web profile:
dsh plugin --profile web add github:Lixiaoyiao/deepseek-harness-action Headless(CLI)profile:
dsh plugin --profile headless add github:Lixiaoyiao/deepseek-harness-action 实测报告
验证通过:从 GitHub 源码完成 L1 安装 + L2 加载 + L3 运行(dsh 0.1.0-rc.6)。
使用场景
扩展 agent 的编码能力面——给它一个新工具、工作流或集成,让它接手以前做不了的开发任务。
适合谁
想让 dsh 在真实代码库上像队友一样干活的开发者——能改、能跑、能验证,而不只是回答问题。
二次开发建议
工具/命令面就是缝:暴露更多 SDK 能力、加更聪明的上下文接线,或收紧改代码与验证之间的循环。