DeepSeek Harness: 起動、mode、pluginの境界
安全なDeepSeek Harness初回run: isolation、mode、Trajectory、plugin audit、適用境界。
目次
DeepSeek Harness: 起動、mode、pluginの境界
DeepSeekはHarnessをDeveloper Previewとしています。最初のgoalはproduction rolloutではなく、isolated folderでの観測可能なread-only runです。custom endpointの前にschema、Base URL、authを確認します。BetterToken API Docsは自分のKeyを説明しますが、全pluginのcompatibilityを証明しません。
隔離して起動する
npx @deepseek-ai/dsh websecretやuncommitted workのないempty folderまたはclean cloneを使います。Standardでentry pointを探すだけのtaskを与え、actual filesと比べます。
modeを選ぶ
| mode | 用途 | 最初のcheck |
|---|---|---|
| Standard | full agent | tools/actions |
| PTC | 読めるorchestration | generated TypeScript |
| Minimal | diagnostic baseline | extraなしの挙動 |
| Creation | custom preset | plugins/dependencies |
PTCはbetter resultを保証せず、Minimalはbaseline、Creationは設定理解の後です。
Trajectoryを見る
append-only event streamで実際に見たfiles、tools、outputs、context sourceを確認します。pathやoutputが違えばpromptを書き直す前にaccessやcontextを直します。
pluginをauditする
pluginごとに不足capability、届くdata/service/permission、regression signal、rollbackを記録します。community bundle前にsourceとdependenciesを読み、previewでは一runに一componentだけ変えます。
permissionとsecret
test folderでもshellは自動で安全になりません。minimal permissionにし、deployを禁止し、API Key、cookie、.envをpreset、prompt、Trajectoryに入れません。
適用または延期
modelとtool layerを分離して調べる、reproducible presetを作る場合に適します。disposable environment、diff review、log processがなければreal dataは延期します。
CTAとsources
許可されたAPI testはBetterToken API Docsで自分のKeyだけを設定し、小さなread-only taskから始めます。
Developer Previewで最初に確認すること
公式リポジトリはMITライセンスで公開され、Cordisを使ってpluginを読み込み、外し、依存関係を管理します。Harness自体が魔法のようにagent能力を追加するわけではありません。model、tool、session、sandbox、storage、agent loop、UIは別々のpluginとして構成されます。modelだけを比較したり、sessionの影響だけを調べたりできる一方、pluginを一つ追加すると、agentが見られるdata、permission、外部serviceも変わり得ます。
Developer Previewでは互換性を壊す変更が起こり得ます。古い解説のoptionやpresetを固定仕様として扱わず、実データの前に公式quickstartとREADMEを確認してください。
初回起動、provider設定、検証の順番
現在のDocsが求めるNode.jsを入れた後、公式のWeb UI起動commandは次です。
npx @deepseek-ai/dsh webbrowserを自動で開かずserverだけ起動したい場合は—no-openを使います。最初はsecret、cookie、.env、未commitの変更がないempty folderまたはclean cloneを用意し、Standardを選びます。agentにはentry pointの特定やproject構造の説明など、書き込みを伴わない小さなtaskだけを与えてください。回答を実際のfileとsession eventに照合してから、初めて限定的なeditとdiff reviewに進みます。test folderはshellを自動で安全にする機能ではなく、設定ミスの影響範囲を小さくする運用です。
custom API endpointを使う場合は、pluginを増やす前にprotocol、Base URL、authentication、model設定をproviderごとに確認します。BetterTokenはcustom Base URLを受け付けるtool向けにOpenAI-compatibleとAnthropic-compatibleのinterfaceを提供しますが、これはすべてのHarness pluginとの互換性を意味しません。BetterToken API Docsで自分のKeyとprovider schemaを確認し、最初のrequestはread-only taskに制限します。
四つのmodeの使い分け
| mode | 用途 | 最初に見る点 |
|---|---|---|
| Standard | file edit、shell、search、skill、plan、goal、subagent、workflowを含むcoding agent | 実際に有効だったtoolと実行されたaction |
| PTC | Code Mode SDKで複数tool callをTypeScriptとして組み立てる | generated TypeScript、input、tool境界 |
| Minimal | persistent bashとstr_replace_editorだけのbaseline | 追加orchestrationを外した時の差 |
| Creation | runtime inspection、memory上のCordis plugin実験、preset作成 | presetが増やすplugin、dependency、permission |
初回の実作業にはStandardが適しています。PTCはorchestrationそのものを読んで再現したい場合のmodeであり、品質向上や安全を保証しません。Minimalは日常用の軽量Standardではなく、skillやsearch、UIの影響を測る基準です。Creationは現在のconfigurationを理解してからcustom presetを設計するための場所です。
Trajectoryとplugin auditで見るべき証拠
Trajectoryはsystem prompt、modelに見えたcontext、tool callとresult、subagentのschedule、context injectionをappend-onlyのevent streamとして扱います。初回taskの後には、agentが本当に見たfileとcommand output、想定外のcontextやtool call、停止理由、成功した経路を空のconversationなしで再現できるかを確認します。
たとえば「configurationを作る場所を探す。ただし書き込みは禁止」と依頼し、path、command、outputをTrajectoryとrepositoryで照合します。一致しなければpromptを言い換える前にaccessとcontextを直します。Trajectoryはaudit trailであり、API Key、秘密のprompt、production logを保存する場所ではありません。
pluginごとに、足りないcapability、到達できるfile/data/service/permission、regressionを見つけるsignal、前のpresetへのrollback手順を記録します。dsh-pluginのcommunity topicから見つけたbundleでも、install前にsourceとdependencyを読みます。Previewでは一runにつきcomponentを一つだけ変えてください。deploy、migration、secret manager、広いwrite accessは小さなtaskのために許可しません。
障害の切り分けと採用判断
最小限の合格条件は、taskが正しく理解され、logのactionが実fileと一致し、人がdiffまたはoutputをreviewしたことです。次は一度に一つだけ広げます。discardable branchでのwrite、追加tool、pluginの順です。
- 正しいfileが見つからない場合はworking directory、read permission、渡したcontextを確認します。
- command outputがagentの説明と違う場合はTrajectory event、tool version、実際のoutputを先に確認します。
- providerが応答しない場合はprotocol、Base URL、authentication、modelをprovider Docsで再確認します。一つのerrorだけでplugin非互換とは判断しません。
- pluginがaccess surfaceを広げ過ぎる場合は無効化し、前のpresetに戻して再現します。
modelとtool layerを分けて調べる、多段workflowをeventからdebugする、再現可能なpresetを作るならHarnessを試す価値があります。disposable environment、diff review、logを読む手順がなければreal dataは延期してください。許可されたAPI testでは自分のBetterToken Keyを使い、API Docsに従って短いread-only taskから始め、Docs URLにUTMを付けません。
