从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering：AI 工程重心为什么又变了

过去两年AI 工程的重心其实经历了三次迁移。最早大家关注的是Prompt Engineering提示词工程本质上是在塑造一个局部概率空间让模型更可能朝着我们期望的方向生成后来重心转向 Context Engineering关键不再只是“怎么说”而是“给模型什么信息”包括如何组织上下文、接入 RAG、沉淀 skills让模型在合适的信息条件下工作而今天真正决定系统上限的越来越不是单次生成质量而是能否把模型封装进一套可执行、可约束、可反馈、可验证的外部系统中——这就是Harness Engineering。它关注的不是让模型回答得更像人而是让模型真正开始像 agent 一样持续完成任务。一、Prompt Engineering塑造一个局部概率空间✍️ Prompt Engineering 解决的核心问题是“如何影响模型这一轮更可能生成什么”。它聚焦系统提示词、few-shot 示例、输出格式、角色设定和约束表达本质上是在模型已有能力边界内通过更好的表达方式把概率质量往目标区域推。这个阶段在单轮问答、分类、抽取、改写、摘要这类任务里一直非常有效而且直到今天也没有过时。Anthropic 在官方文档中仍然把清晰指令、示例设计、结构化输出等实践作为 prompt engineering 的核心部分。但 Prompt Engineering 很快会遇到边界。因为一旦任务从“回答一个问题”变成“连续完成一个任务”问题就不再只是“提示词怎么写”而会变成“模型在这一步到底应该看到什么、记住什么、忽略什么、调用什么”。也就是说提示词可以显著影响单次生成却很难单独支撑一个多步、长链路、带工具调用和状态管理的系统。二、Context Engineering给模型正确且合适的信息 Context Engineering 的重点不再是写出一条更聪明的 prompt而是为模型提供“此刻最有用的信息集合”。Anthropic 将它定义为在推理时持续策划、筛选和维护最优的 token 集合这些 token 不只来自 prompt也来自工具返回、消息历史、外部数据、检索结果、MCP 资源以及运行状态。因为 agent 是在循环中工作的每一步都会制造新的候选信息所以 context engineering 本质上是一个持续的组织、压缩、更新和清理过程。这也是为什么 RAG、记忆、skills、经验复用、上下文压缩会在 2025 年之后迅速变得重要。它们解决的不是“让模型更会说”而是“让模型在行动之前拿到更正确的条件”。Anthropic 在相关文章中明确强调上下文是关键但有限的资源随着 agent 运行时间变长工程重点自然会转向如何管理整个 context state而不是只优化系统提示词。与此同时SWE-ContextBench 和 ACE 这类研究也开始把“上下文如何复用、如何演化”做成可以测量和比较的问题。但 Context Engineering 仍然不够。因为它回答的是“给模型什么”却还没有完整回答“模型接下来如何行动、如何被限制、如何被纠错、如何被验证”。当系统进入真正的 agent 阶段仅仅拥有更好的上下文并不等于拥有一个可持续交付结果的系统。三、Harness Engineering把模型变成 Agent Harness Engineering 关心的是模型之外的那整套系统设计。LangChain 在 2026 年给出过一句非常直白的总结Agent Model Harness。在它的定义里harness 是一切“不属于模型本身”的代码、配置和执行逻辑一个裸模型不是 agent只有当它获得状态管理、工具执行、反馈回路和可执行约束之后才真正开始像 agent 那样工作。LangChain 进一步把 harness 的组成拆成 system prompt、tools、skills、MCP、文件系统或沙箱、编排逻辑以及围绕上下文压缩、续跑、lint 检查等能力的 hooks 和 middleware。不过这里有一个边界需要说清楚Harness Engineering 还不是一个已经统一定义的标准术语。Thoughtworks 在 coding agent 的语境里给了一个更收敛的解释所谓 harness不是笼统地包掉模型外的一切而是围绕“如何提高结果可信度”来设计 guide 和 sensor其中既有计算型控制比如测试、lint、类型检查、结构分析也有推断型控制比如 AI review、语义判断、LLM-as-judge。它甚至明确指出在 coding agent 的场景里用户自己搭建 harness可以视为 context engineering 的一种具体形式。换句话说Harness Engineering 并不是简单替代 Context Engineering而更像是把它纳入一个更大的执行与控制闭环。如果说 Prompt Engineering 优化的是“表达”Context Engineering 优化的是“信息供给”那么 Harness Engineering 优化的就是“行为闭环”。它决定的不只是模型看到了什么而是模型能做什么、做错时会被什么机制拦下、做完之后由谁验证、失败了如何回放、何时停机、何时请求人工接管。Anthropic 在 2026 年关于长时运行应用的文章里甚至直接写到harness design 已经成为 agentic coding 前沿性能的关键并总结出两条经验一是把任务拆成可处理的块二是用结构化产物在多轮会话之间传递上下文。四、为什么第三次迁移会在现在发生 这次迁移不是一个抽象概念而是 agent 的任务边界真的变了。Anthropic 在 2024 年关于 agent 的总结里指出最成功的生产实践通常并不依赖过于复杂的框架而是使用简单、可组合的 workflow 和 agent 模式。到了 2026 年他们对 Claude Code 的部署观察又显示最极端的一批 turn 正在显著变长2025 年 10 月到 2026 年 1 月99.9 分位的 turn duration 从不到 25 分钟增长到超过 45 分钟与此同时在内部使用中更高的成功率伴随着更少的人类干预。任务越长、步骤越多、运行越自主系统问题就越不可能只靠 prompt 或上下文单独解决。研究社区也在沿着同样的方向推进。METR 的长任务能力研究提出用 “50% task-completion time horizon” 来刻画 AI 可以可靠完成的任务长度LiveAgentBench 这样的新 benchmark 则试图把真实用户需求和真实场景带回 agent 评测。把这些线索放在一起一个很自然的判断就是当系统从一次回答走向几十分钟甚至更久的连续执行真正的瓶颈会从“生成得像不像”转向“系统能不能稳定、自纠、可观测地跑下去”。五、对工程团队意味着什么 如果你做的是单轮问答或轻量助手Prompt 依然很重要如果你做的是 RAG、多轮助手或知识系统Context 往往是成败关键但如果你做的是 coding agent、research agent、ops agent或者任何需要持续执行的系统真正的竞争力会越来越来自 harness。你要关心的不只是提示词而是工具权限、状态持久化、轨迹记录、验证器、环境反馈、人工接管点、失败分类、运行成本和观测能力。Anthropic 的 Agent SDK 已经把 tools、agent loop、context management 等能力做成了可编程接口这本身就说明 harness 不再只是一个抽象理念而正在被产品化、工程化。所以更实用的判断不是“Prompt 过时了”而是Prompt 已经降级为更大系统中的一个组件Context 成了运行时的信息供给层Harness 才是把这些组件组织成可工作 agent 的系统层。未来团队之间的差距不会只体现在谁写出更华丽的 system prompt而会体现在谁能设计出更可控、更可验证、更可复用的 harness。六、最新论文与相关文献 如果你想把这篇文章往更扎实的研究视角再推进下面这些文献最值得看。需要说明的是其中一部分是 arXiv 预印本更适合把握前沿方向不等于都已经过完整同行评审。Meta-Harness: End-to-End Optimization of Model Harnesses2026这篇论文直接把 harness 本身当成优化对象通过外循环搜索 harness 代码来提升模型在分类、检索增强推理和 agentic coding 任务上的表现。它的重要性在于Harness Engineering 开始从人工经验走向可搜索、可自动优化的问题。AutoHarness: Improving LLM Agents by Automatically Synthesizing a Code Harness2026这篇工作表明模型可以利用环境反馈自动合成 code harness并显著减少非法动作。它支撑了一个非常关键的判断模型能力不是唯一变量外部控制逻辑本身也是性能来源。Natural-Language Agent Harnesses2026这篇论文尝试把 harness 从控制器代码中抽出来变成可编辑、可迁移的自然语言制品并配套一个共享运行时。它非常值得关注因为这意味着 harness 未来可能像 prompt 一样变成一种显式工程资产。LiveAgentBench2026这项工作提出了更贴近真实用户需求的 agent benchmark用来衡量 agentic systems 在真实挑战中的表现。它说明 agent 评测正在从静态 benchmark转向更接近实际环境的系统评测。SWE-ContextBench2026这项研究专门评估编程 agent 的经验复用与上下文复用能力说明 Context Engineering 已经不仅是经验技巧而是能够被系统测量和比较的能力维度。Agentic Context EngineeringACE2025–2026这篇工作把上下文视为持续演化的 playbook通过生成、反思和整理来避免信息塌缩。它很适合被看作从 Context Engineering 走向 Harness Engineering 的桥梁。七、未来方向Harness Engineering 会往哪里走 我认为接下来最值得关注的不是“还有没有更厉害的 prompt 技巧”而是 Harness Engineering 会沿着以下几个方向继续展开。第一harness 会从人工设计走向自动优化。Meta-Harness 和 AutoHarness 已经给出很明确的信号harness 不再只是人手工堆出来的外壳而是可以被搜索、被合成、被迭代改进的对象。未来很可能会出现“用 agent 优化 agent harness”的完整工程流水线。第二harness 会从隐性逻辑变成显式资产。Natural-Language Agent Harnesses以及仓库中逐渐出现的 AGENTS.md 一类实践都在推动 harness 从“藏在代码里”变成“可版本管理、可审查、可迁移”的对象。团队未来很可能会像管理 API 契约、CI 配置一样管理 harness。第三确定性控制和推断型控制会长期共存。tests、linters、type checkers 这类快速稳定的计算型控制会成为 agent 的第一道护栏AI review、LLM-as-judge 这类语义级判断会负责覆盖更高层的问题但不会单独承担全部信任。高质量 agent 系统大概率会是两者的混合编排而不是偏向任何单一一侧。第四评测会越来越 harness-aware。LiveAgentBench、SWE-ContextBench以及长任务能力研究都在说明模型成绩已经不能完整解释 agent 表现runtime、scaffold、harness 本身会成为必须单独比较的变量。未来我们评价一个 agent不会只问“底模是什么”还会问“它外面的系统是怎么搭的”。第五长时自治会倒逼新的监控与治理基础设施。随着更长时长的运行、更少的人类干预和更强的自治水平同时出现Harness Engineering 最终会和 observability、safety、governance 深度合流。也就是说未来真正成熟的 agent 工程既不是纯模型工程也不是纯应用工程而是一种新的系统工程。总结✅ 如果说 Prompt Engineering 解决的是“怎么影响生成”Context Engineering 解决的是“怎么给模型提供正确的信息条件”那么 Harness Engineering 解决的就是“怎么把一个会推理的模型变成一个能持续执行、可约束、可验证、可优化的系统”。在 AI 从一次回答走向长期执行、从演示走向生产、从助手走向 agent 的过程中这个重心迁移几乎是必然的。真正的壁垒不会只在模型里也不会只在提示词里而会越来越多地出现在模型之外的那套系统设计里。