lifcc (@mylifcc) “把 DeepSeek Harness 的源码翻了一遍，发现一个挺有意思的变化： 它根本没把 Prompt” — TopicDigg
lifcc
@mylifcc
加入 January 2022
0 正在关注 0 粉丝
把 DeepSeek Harness 的源码翻了一遍，发现一个挺有意思的变化：
它根本没把 Prompt 当成一段 System Prompt。
而是把 Prompt 做成了一个 Runtime。
大概是：
Identity
+
Persona
+
Tool Guidance
+
Runtime Context
+
Tool Schema
+
Variables
+
Middleware
最后动态 Assembly 成模型看到的东西。
这意味着一个能力不再只是：
Tool + Code
而是：
Tool + Schema + Prompt Guidance
谁负责这个能力，谁就负责告诉模型“应该怎么用”。
比如 shell 自己拥有 shell 的 Prompt，filesystem 自己拥有 filesystem 的 Prompt，web 自己拥有 web 的 Prompt。
这其实很像软件工程里的模块化：
Capability = Implementation + Interface + Model-facing Instructions
更有意思的是，它还把 Prompt 分成了不同 Scope。
Global Prompt
↓
Agent Scope
↓
Agent-specific Override
所以不同 Agent 可以继承、覆盖或者增加自己的 Prompt。
这就不是传统的：
“给所有 Agent 塞一个巨大的 System Prompt”
而更像：
Prompt Dependency Injection。
还有一个我觉得特别重要的设计：
DeepSeek 把 Runtime Context 和 Prompt 分开了。
比如 cwd、git 状态、当前任务这些动态信息，不需要每次都修改稳定的 System Prompt，而是作为动态 Context 注入。
于是：
Instruction = 我应该怎么工作
Context = 我现在处于什么状态
Tools = 我现在能做什么
三者被明确拆开。
甚至 Prompt 里的变量也不是简单的 string.format。
未知变量、malformed variable、重复 section 等情况，会倾向于直接 fail。
换句话说：
DeepSeek 把 Prompt 当成了“程序”，而不是文案。
还有一个很容易被忽略的东西：
Tool Schema 本身就是 Prompt Engineering。
Tool 的名字、description、参数描述、tool ordering、tool availability，都在影响模型行为。
所以模型最终看到的其实不是：
System Prompt + Tools
而是：
Instructions + Context + Capabilities
统一组装。
我觉得这才是 DeepSeek Harness 最值得研究的地方。
它真正想解决的可能是
“怎么构建一个可以持续演进的 Prompt Runtime？”
如果这个方向继续发展下去，未来的 Agent Prompt 可能不会再是一份几千行的 system prompt。
而会更像一个软件工程项目：
/identity
/persona
/tools
/context
/agents
/middleware
/variables
每个能力自己携带自己的 Prompt。
Prompt 从“文案”变成“基础设施”。
这可能才是 Harness Engineering 真正有意思的地方。
显示更多
做一个下dsh和pi的对比
Pi 的目标是“最小核心 + 用户自己拼”，DSH 的目标是“几乎所有能力都插件化，官方先给你几套完整组合”。
DSH 的骨架是Cordis。
Cordis 不是普通插件加载器，它强调两件事：
1. 可逆副作用（temporal composability）：插件卸载时，注册的服务、事件、工具 schema、prompt section 全部自动撤销。
2. 依赖声明与空间组合（spatial composability）：插件通过 `inject` 声明需要什么服务，运行时按依赖挂载。
所以在 DSH 里：
- 模型适配器是插件
- 工具注册表是插件
- session log 是插件
- agent loop 本身也是插件
- 甚至 UI 也是插件
没有“神圣不可动的核心”。你想换 loop、换工具策略、换上下文压缩，挂一个新插件 + 改配置就行。
启动时是 Profile + Bundle叠出来的：
空根 → dsh-base（模型、工具、沙箱、凭证…）
→ dsh-web-app 或 dsh-headless
→ 用户自己的 cordis.patch.yml
→ 命令行 --patch
`dsh --profile web --dump-config` 能直接把当前实际挂载的树打出来。
Session 设计是硬核部分
Session 是 append-only 的事件流
模型最终看到的上下文，必须能从这条 log 完整重建出来。官方写得很死：
> Model-visible means logged.
任何会进模型请求的内容，都要先变成 session event。
所以 fork、resume、回放、UI 渲染、telemetry，全部从同一条流投影。这点比大多数 coding agent 做得更彻底。
Turn / Step 有claudecode的影子，流程如下：
turn/start
→ claim input
→ agent/pre-step（可拦截、可改写）
→ step/start
→ llm/stream
→ tool/call → tools/pre-execute → execute → post-execute
→ step/end
→ 继续 or turn/end
`agent/pre-step`、`tools/*` 这些是 waterfall，监听者必须显式 `next()` 才能往下传。扩展点设计得很规整。
Pi 的实际交集
DSH 仓库里有一个包：
`@deepseek-ai/dsh-llm-pi-ai`
它就是把 pi-ai当成 LLM 适配器的后端。
多 provider、协议兼容、reasoning effort 映射、catalog 覆盖，都走 pi-ai 的能力，再包一层 Cordis 插件契约。
所以：
- LLM 调用层：吃了 Pi 的基础设施
- Agent 编排、工具、session、UI、沙箱：完全自己的 Cordis 体系
“LLM 适配层直接用了 pi-ai，上层重做了一套更重的可组合 Runtime”。
模式上的对应
DSH 的 Minimal 模式才最接近 Pi 的默认体验：只留 shell + 文件编辑器，专门给 benchmark 用。
官方之前在 V4 的 agent 评测里就用过这个模式。
Standard 模式和 Code（PTC）模式则是完整工具集 + 程序化工具编排，已经远超 Pi 默认的 4 工具。
如果你喜欢 Pi 那种“核心极瘦、自己动手加东西”的感觉，DSH 会显得重，配置和概念也更多。
如果你要的是可替换的 agent loop、完整事件回放、多模式预设、以及官方已经搭好的 Web 界面，DSH 的插件树和 seam 设计更系统。
一句话：
Pi 是极简可扩展的 coding harness；DSH 是基于 Cordis 的完整 Agent Runtime，LLM 层复用了 pi-ai，但整体不是同一套代码。
显示更多
