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