把 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 真正有意思的地方。