DeepSeek Harness将Prompt视为Runtime，模块化设计，分离指令、上下文与工具。
RT @mylifcc: 把 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 真正有意思的地方。
它根本没把 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 真正有意思的地方。