Agent 工程的三次进化
去年 6 月 Shopify CEO Tobi Lutke 发了条推，说他觉得 context engineering 比 prompt engineering 好。Karpathy 转发 +1。Simon Willison 写了篇博客说这个词可能真能立住。Phil Schmid 做了完整定义。半个 AI 圈在一周之内集体换了术语。
到了 2026 年初，Phil Schmid 又抛了一个新词：Agent Harness。这次没有上一轮那么热闹，但写 Coding Agent 的人几乎都默默点了头。
三个词，三个阶段的焦点。但行业讨论有个问题：很多人把它们当成同义词的迭代版本，好像 context engineering 就是 prompt engineering 2.0，harness engineering 就是 3.0。不是这样。它们解决的是完全不同层面的问题，互相之间是包含关系而不是替代关系。
Prompt：怎么跟模型说话
Prompt engineering 火起来是 2022-2023 年。核心场景很简单：你面对一个文本框，要想办法让模型给出你想要的输出。Chain-of-thought、few-shot examples、角色扮演、格式约束，这些技巧本质上都在回答同一个问题：怎么把你的意图准确地翻译成模型能理解的文本。
这是一个语言问题。你在和一个"外星人"沟通，它的母语是 token 序列，你的母语是人类自然语言。Prompt engineering 就是学习这种翻译的技巧。写得好模型就懂你，写得差就各种幻觉和跑偏。
关键限制在于：prompt engineering 假设你跟模型之间只有一次对话。你把所有信息塞进一个请求里，模型返回一次结果，交互结束。即使是多轮对话场景，每一轮的 prompt 优化本质上也是在打磨那个静态文本。Karpathy 说得很准确，大多数人对这个词的直觉理解就是"往聊天框里打字的技巧"，可惜这个直觉没什么错。
Context：模型看到了什么
2025 年中，Tobi Lutke 给出的定义是"the art of providing all the context for the task to be plausibly solvable by the LLM"。Karpathy 的补充更精确：context engineering 是"filling the context window with just the right information for the next step"的精细艺术和科学，涉及任务描述、few-shot 示例、RAG 检索、多模态数据、工具定义、状态和历史、压缩，做好这些是高度非平凡的。
Phil Schmid 后来在博客里把这个概念凝练成一句话：设计和构建动态系统，在正确的时间以正确的格式提供正确的信息和工具，让 LLM 拥有完成任务所需的一切。
注意两个关键词：动态，系统。Context engineering 不再是一个字符串的优化问题，而是一个系统工程问题。你不是在写一段 prompt，你是在写一段程序，这段程序的输出才是 prompt。程序需要决定这次调用要不要带上用户的日历数据，要不要检索相关文档，要不要附上之前对话的摘要，要不要提供某几个工具。每次决策都不一样，因为任务不一样。
Phil Schmid 举过一个很直观的例子：同样一封邮件说"明天聊一下"，context 差的 Agent 只能回"您方便几点"，context 好的 Agent 能直接说"明天全排满了，周四上午行不行，给你发了邀请"。第二个回答之所以好，不是因为 prompt 写得更妙，而是因为系统在调用模型之前已经拉取了日历、通讯录、历史邮件。Prompt engineering 关心你对模型说了什么，context engineering 关心模型看到了什么。
Phil Schmid 在 context engineering 那篇博客里说得很直白：大多数时候 Agent 不靠谱，根本原因不是模型能力不够，而是合适的上下文没有传达给模型。这跟很多人的直觉相反，大家总觉得要等更强的模型，但往往 Opus 4.6 搞不定的任务，给它补全上下文之后 Sonnet 4 就能搞定。
Harness：谁来管 Agent 的一生
2026 年 1 月 Phil Schmid 发了一篇"The importance of Agent Harness in 2026"。他用了一个计算机的类比：模型是 CPU，上下文窗口是 RAM，Agent Harness 是操作系统，Agent 是跑在操作系统上的应用程序。
这个类比点出了一个被 context engineering 讨论忽略的维度：时间。Context engineering 讨论的核心场景是"下一次 LLM 调用之前怎么准备上下文"，但 Agent 的现实场景是连续几十甚至几百次 LLM 调用，跨越几分钟到几天。在这个尺度上，context engineering 只是操作系统里的内存管理模块，你还需要进程调度、文件系统、驱动程序、中断处理。
Harness 要管的事情包括但不限于：上下文在长会话中怎么压缩和回收（内存管理），子 Agent 怎么分配任务、怎么隔离上下文（进程管理），工具调用失败了怎么重试和降级（异常处理），模型的注意力开始漂移了怎么检测和纠正（看门狗），用户离开一小时回来之后怎么恢复状态（休眠唤醒），每一步的决策轨迹怎么记录用于后续训练（日志系统）。
拿 Claude Code 举个具体例子。它的上下文压缩分四层级联：零成本的时间清理、不破坏缓存的服务端编辑、后台笔记做免费摘要、最后才是完整的 LLM 摘要。这套分层逻辑不是 context engineering 能描述的，它是一整套运行时资源管理策略，跟操作系统的多级缓存加虚拟内存的设计思路如出一辙。
Phil Schmid 在文章里还提到了一个洞察：harness 的价值不只是让当前 Agent 跑得更好，它产生的执行轨迹数据本身就是训练下一代模型的素材。模型在第 100 步开始不听指令了，harness 记录下来，这个数据回流到训练管线，下一版模型就能在第 200 步才开始漂移。这个循环是纯 context engineering 讨论里完全没有涉及的。
三层是嵌套，不是替代
把这三者的关系理清楚：
+------------------------------------------------+
| Harness Engineering |
| Lifecycle, compaction, sub-agents, |
| hooks, state recovery, drift detection |
| |
| +-------------------------------------------+ |
| | Context Engineering | |
| | RAG, memory, tools, history, | |
| | dynamic assembly per LLM call | |
| | | |
| | +--------------------------------------+ | |
| | | Prompt Engineering | | |
| | | Instructions, format, tone, | | |
| | | chain-of-thought, few-shot | | |
| | +--------------------------------------+ | |
| +-------------------------------------------+ |
+------------------------------------------------+Prompt engineering 是内核，解决"怎么跟模型说话"。Context engineering 是中间层，解决"模型在回答之前看到了什么"。Harness engineering 是外壳，解决"整个 Agent 生命周期内的资源调度和状态管理"。
三者的决策频率也不同。Prompt engineering 的决策发生在系统设计阶段，一次写好很少改。Context engineering 的决策发生在每次 LLM 调用之前，每次都可能不同。Harness engineering 的决策跨越整个会话生命周期，在第 1 步和第 100 步的行为可能完全不同。
搞混了会怎样
搞混了会导致在错误的层面解决问题。
Agent 在某个工具调用上反复失败。如果你觉得这是 context 问题，你会去检查工具定义的格式和上下文里的相关信息够不够。但真正的问题可能是 harness 层的：没有重试机制，没有降级策略，模型被卡在一个死循环里。反过来也成立，模型理解不了你的指令，总是跑偏，这时候去改 harness 层的压缩策略和子 Agent 编排没用，问题就在最内层：prompt 写得不够清楚。
Phil Schmid 引用了 Rich Sutton 的 Bitter Lesson，说 harness 必须轻量，因为每一代新模型都会让上一代的复杂控制流变得多余。这话对，但只对了 harness 层。Prompt engineering 的技巧确实在模型升级中不断贬值，去年需要的 chain-of-thought 提示今年不需要了。Context engineering 相对稳定，因为"模型需要看到相关信息才能做好决策"这件事不会随模型升级而消失。Harness engineering 的核心价值也在变化，上下文窗口越大、模型越持久耐用，harness 需要做的治理就越少，但只要窗口有限、模型会漂移，harness 就有存在的必要。
Agent 在长会话后半段开始重复自己，你去改 prompt 加一句"不要重复"没用，问题在 harness 层的压缩策略。知道问题出在哪一层，才知道该在哪一层使劲。