DeepSeek Harness 自引用源码定位dsh 如何把自身检出路径注入 Agent 系统提示词【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harnessdshDeepSeek Harness CLI是一个万物皆插件的自我引用运行时——它通过内置的cordis工具集让 Agent 能够直接查看并修改自己运行其上的 Harness 源码。本文剖析该仓库中的功能决策笔记 2026-07-21-dsh-system-prompt-source-path.mdStatus: implemented2026-07-26 归档dsh 如何从自身模块 URL 推算出源码检出根目录并在系统提示词中注册一个全局harness:source提示词段让 Agent 无需任何发现步骤即可读自己的源码。读完本文你将掌握import.meta.url路径解析的边界条件、dsh-app-boot中可测试辅助函数的抽取动机、FIRST_PARTY_SECTION_ORDER的排序机制以及该功能如何通过单元测试与 PTY 端到端测试被逐字锁定。背景dsh 是自我引用的接口面DeepSeek Harness 的核心设计是Everything is a Plugin整个运行时由 Cordis 插件树组合而成。其中dshCLI 是特殊的自我引用表面——它暴露的cordis工具集见 packages/extensions/tool-cordis允许 Agent 检查并修改它正在其中运行的 Harness 运行时本身。这意味着修改 Harness 的行为不再需要人手工编辑文件Agent 可以直接通过工具读写源码。但这里存在一个前提缺口Agent 无从得知这份源码在磁盘上的具体位置。没有这个路径读取你自己的源码就只能是猜测。问题为什么 cwd 和 argv 都不可靠原文档.agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md精确刻画了这个困境dsh通常以符号链接的形式挂到PATH上用户从任意工作目录启动它而那个工作目录往往是正在被处理的项目task workspace而不是 Harness 检出目录因此process.cwd()指向用户项目process.argv[1]在 PATH 符号链接场景下指向的是符号链接自身两者都无法可靠地定位 Harness 检出根。任何依赖 cwd 或 argv 的方案都是脆弱的。真正可靠的把手只有一个启动器自身模块的 URL——也就是import.meta.url。决策从 import.meta.url 推算检出根原文档记录了当时的实现位置dsh启动器文档写作时位于apps/cli/src/tui.ts用以下表达式计算 Harness 检出根目录fileURLToPath(new URL(../../.., import.meta.url))从apps/cli/{src,lib}向上跳三级即可解析到仓库根。由于import.meta.url始终指向模块文件的真实位置无论dsh是通过 PATH 符号链接、任意 cwd 还是相对路径启动因此该计算在任意启动方式下都能稳定命中真实源码位置。需要说明的是该笔记归档于 2026-07-26当前仓库的 CLI 启动入口已演进为 apps/cli/src/bin.ts 与 apps/cli/src/profile-boot.ts后者的INSTALL_ANCHORapps/cli/src/profile-boot.ts同样使用fileURLToPath(new URL(../package.json, import.meta.url))从模块位置锚定安装目录。核心思想——路径是启动器自身的事实从模块 URL 机制性推导——被完整保留并延续到了后来的实现中。同构实现web-app bundle该模式并非孤例。在 packages/bundle/web-app/src/index.ts 中web 表面的 bundle 插件用同样的手法计算检出根const SOURCE_ROOT fileURLToPath(new URL(../../../.., import.meta.url))这里向上跳了四级packages/bundle/web-app/src→packages/bundle/web-app→packages/bundle→packages→ 仓库根并在 packages/bundle/web-app/src/index.ts 中通过ctx.inject([systemPrompt], ...)调用同一个addHarnessSourceSection(promptCtx, SOURCE_ROOT)。也就是说告诉模型自己的源码在哪已经不只是 CLI 的特权而是 Harness 各应用表面共享的引导能力。核心实现addHarnessSourceSection 与 harness:source 提示词段真正可测试的逻辑并不在apps/*而在受覆盖率门禁约束的packages/*中——即 packages/boot/app-boot/src/index.ts。该文件底部定义了export const HARNESS_SOURCE_SECTION harness:source export function addHarnessSourceSection(ctx: Context, sourceRoot: string): (() void) | undefined { const systemPrompt ctx.get(systemPrompt) if (systemPrompt undefined) return undefined return systemPrompt.section({ name: HARNESS_SOURCE_SECTION, order: FIRST_PARTY_SECTION_ORDER.HARNESS_SOURCE, text: The DeepSeek Harness implementation checkout is at ${sourceRoot}. The checkout location and current working directory are separate values and may differ; never infer the working directory from this path. Use pwd to determine the current working directory. Use this checkout only to inspect or extend DSH itself., }) }这段实现蕴含了几个值得注意的设计点1. 空操作语义。当引导出来的插件树没有systemPrompt服务时ctx.get(systemPrompt)返回undefined函数直接返回undefined空操作。这保证了对任意组合的插件树都安全没有提示词组装管线的部署不会被强加一个段。2. 文本内容刻意区分检出路径与工作目录。提示词文本明确写道检出位置与当前工作目录是两个独立的值可能不同永远不要从这个路径推断工作目录应使用pwd确定当前工作目录且该检出只用于检查或扩展 DSH 本身。这是对问题根源的直接防御——避免模型把源码路径误当成任务工作区。3. 返回 disposer。函数返回systemPrompt.section(...)的释放器调用方可以精确撤销该段为 HMR 重载场景留下退路见下文。排序机制-900 位置的微妙之处提示词段的拼接不是随意的。dsh-system-prompt包的组装管线按order升序拼接各段同 order 时按名称的代码单元顺序排列见 packages/core/system-prompt/README.md。仓库自有段通过FIRST_PARTY_SECTION_ORDER获得稀疏且唯一的位置见 packages/core/system-prompt/src/index.tsexport const FIRST_PARTY_SECTION_ORDER { HARNESS_IDENTITY: -1000, HARNESS_SOURCE: -900, WEB_SURFACE: -800, DEPLOYMENT_PERSONA: 0, // ... 其余工具段从 500 到 9900 }原文档记录该段当时以-99排序当前源码中常量值为HARNESS_SOURCE: -900——数值随演进调整但相对位置语义始终一致**harness 身份开场HARNESS_IDENTITY-1000**之后**部署 personaDEPLOYMENT_PERSONA0**之前且与所有工具段TOOL_BASH: 1000、TOOL_READ: 1100等拉开超过十个数量级差距保持一阶稀疏性使意外的排序碰撞在机制上可被检测相邻值至少相差 10见 packages/core/system-prompt/src/index.ts 的注释。也就是说在最终组装出的系统提示词里这一行会稳定出现在你是谁Harness 身份之后、你以什么 persona 工作部署角色之前——模型在读到自己被定位为 Harness 驱动 Agent 之后紧接着就知道自己的源码在哪然后才进入任务角色。为什么放在 dsh-app-boot 而不是 CLI 里原文档的Decision一节给出了一个清晰的工程约束apps/*不受覆盖率门禁约束而packages/*受约束见 .agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md。因此解析可选的systemPrompt服务、注册提示词段、返回 disposer——这些需要按文件 100% 覆盖率验证的逻辑——被抽取到deepseek-ai/dsh-app-boot包中packages/boot/app-boot/src/index.ts而启动器只保留薄薄的一层黏合计算路径、调用辅助函数。这层黏合由 CLI 的无密钥 PTY 冒烟测试覆盖既保持了覆盖率门禁的意义又不让启动器背上难以测试的注册逻辑。这一决策直接否决了两个备选方案备选方案被否原因在 system-prompt 服务构造函数内注册段会出现在每一个部署中而非仅自我引用的 CLI源码根还得穿过配置才能到达构造函数。路径是启动器的事实应由启动器注入把整个逻辑留在apps/cli/src/tui.tsapps 不受覆盖率门禁约束注册逻辑与服务缺失分支将以未受测状态发布门禁失去意义新增 cordis.yml 配置字段路径不是部署选择而是启动器自身的机制性位置配置键会招致手工填入的路径变陈旧从process.cwd()/process.argv[1]解析cwd 是用户项目PATH 符号链接使 argv[1] 是符号链接路径import.meta.url是唯一可靠的把手其中从 cwd/argv 解析的否决与问题分析首尾呼应路径必须来自模块位置而不是进程位置。依赖与类型合并dsh-app-boot通过ctx.get(systemPrompt)获取服务因此需要对dsh-system-prompt的声明合并declaration merge支持。原文档记录了一个刻意控制的依赖策略仅类型依赖peer dev不存在运行时依赖这与 acp 包的副作用型类型 import 模式保持一致。在 packages/boot/app-boot/package.json 中可以看到deepseek-ai/dsh-system-prompt同时出现在peerDependencies与devDependencies中而运行时dependencies只有deepseek-ai/dsh-atomic-write、js-yaml、resolve.exports三项——印证了编译期类型引用、运行时零耦合的设计。范围边界哪些表面获得 source 段原文档Scope一节明确划定边界只有dshCLI 加入这一段。demo bindsh-cli-demo、dsh-acp-demo原样引导它们已提交的插件树不获得 source 段因为它们不是自我修改的接口其检出根也不是模型需要知道的事实。从当前仓库源码看这一边界后来有所扩展packages/bundle/web-app的 web 表面同样调用了addHarnessSourceSectionpackages/bundle/web-app/src/index.ts并在 packages/bundle/web-app/tests/web-app.spec.ts 中断言组装后的提示词包含harness:source段。可以推断随着 web 表面也获得cordis类工具的自我修改能力它同样需要知道自己源码的位置——这与原文档的判定标准是否自我修改的接口是一致的。HMR 行为开发态的小瑕疵提示词段是针对已就位的systemPrompt服务自身 fiber注册的通过ctx.get(systemPrompt)。因此如果开发态对 system-prompt 插件做一次 HMR 重载该段会被丢弃直到下一次引导才会重新注册。原文档明确指出.agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md生产环境的 HMR 监视的是配置而非构建产物 lib所以这只是开发态独有的瑕疵可以接受。addHarnessSourceSection返回的 disposer 也为此类重载场景提供了精确撤销的能力。测试验证逐字锁定与端到端断言该功能的正确性由两个层次保证1. 单元测试按文件 100% 覆盖率门禁。packages/boot/app-boot/tests/app-boot.spec.ts 中有三个针对性用例distinguishes the source path from the current workdir between identity and persona注册段后渲染完整提示词断言 source 段文本出现且其位置严格位于 harness 身份开场You are an AI agent powered by DeepSeek Harness.与 personaYou are a coding agent.之间is a no-op returning undefined when no systemPrompt service is mounted没有systemPrompt服务的树中调用返回undefined验证空操作分支disposes the section it added, so a systemPrompt reload leaves no residuedispose 后再次组装harness:source段消失验证释放器不留残留。2. CLI 无密钥 PTY 冒烟测试端到端。该测试以脚本化配置引导dsh、运行一个轮次然后从持久化的request/header系统提示词中把源码路径读回来端到端断言模型实际收到的提示词确实包含该路径。值得一提的还有对KV Cache 的考量这一行位于按请求变化的内容之前因此不会在多个轮次之间扰动 KV Cache.agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md。这意味着将源码路径放入提示词不会带来可感知的性能开销。总结与延伸阅读harness:source提示词段的落地是自我引用运行时这一设计理念的完整闭环dsh不仅能操作 Harness 源码还主动告知 Agent 源码在哪。从实现角度看它同时示范了三条可复用的工程原则路径属于启动器事实——从import.meta.url机制性推导而不是依赖 cwd、argv 或配置可测试逻辑归属受门禁约束的包——apps/*只留薄黏合packages/*承载可验证逻辑提示词段要有确定的位置语义——通过FIRST_PARTY_SECTION_ORDER的稀疏 order把段稳定安放在身份与 persona 之间。如需进一步深入可以阅读功能决策原文.agents/notes/archived/feature/2026-07-21-dsh-system-prompt-source-path.md及其中文版 .zh.md核心实现packages/boot/app-boot/src/index.ts排序常量packages/core/system-prompt/src/index.ts单元测试packages/boot/app-boot/tests/app-boot.spec.ts同构的 web 表面使用packages/bundle/web-app/src/index.ts。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考