夜雨聆风从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering
你还在纠结怎么写 Prompt 吗？
2024 年底，Anthropic 的 Amanda Askell（Claude 的 Prompt 总架构师）在一次访谈中说了一句让很多人醍醐灌顶的话：
"大多数人以为用好 AI 的关键是写出完美的 Prompt，但实际上，真正重要的是你给了它什么信息。"
这句话标志着一个时代的转变。让我们把时间线拉开，看看 AI 工程化是如何经历三次范式跃迁的。
第一阶段：Prompt Engineering（2023-2024）
核心关注：「怎么问」
ChatGPT 横空出世后，所有人都在研究同一个问题——怎么跟 AI 说话它才能听懂？
这个阶段诞生了大量的"Prompt 技巧"：
- 角色扮演
：你是一个资深 Go 开发工程师... - Few-shot
：给 AI 几个示例，让它模仿输出格式 - Chain-of-Thought
：请一步步思考... - 约束指令
：请用中文回答，不超过 200 字...
这些技巧确实有效。但问题是——它太脆弱了。
一个精心调试的 Prompt，换一个模型版本可能就失效了。换一个使用场景、换一批输入数据，效果可能天差地别。
Prompt Engineering 的本质：你在教 AI「用什么姿势思考」，但没有给它思考所需的原材料。
就像你告诉一个新入职的员工"请像资深架构师一样审查这段代码"，但你既没有给他项目文档，也没有给他代码规范，甚至连代码长什么样都没让他看到。
他能做好吗？不能。
第二阶段：Context Engineering（2024-2025）
核心关注：「给什么信息」
当 AI Agent（如 Cursor、Claude Code、Windsurf）开始落地到真实的工程场景，开发者们很快发现：Prompt 写得再好，如果上下文不对，结果也是垃圾。
这催生了一个新的工程范式——Context Engineering。
Shopify 的 CEO Tobi Lütke 在 2025 年初对这个概念给出了一个精确的定义：
"Context Engineering 是一门将任务所需的所有信息和约束精确地打包，使 LLM 能够合理完成任务的学科。"
Context Engineering 做什么？
它解决的是「LLM 的上下文窗口里应该放什么」：
- 动态文件检索
：不是把整个代码库塞进去，而是精确地找到与当前任务相关的文件 - 记忆管理
：把历史对话压缩成摘要，在下一轮对话中复用 - 工具结果编排
：搜索结果、文件内容、终端输出——按优先级组织这些信息 - 项目规则注入
：通过 CLAUDE.md或.cursorrules文件告诉 AI 这个项目的技术栈、规范、禁区
一个典型的例子
当你在 Cursor 中让 AI 修复一个 Bug 时，Agent 并不是直接把你的 Prompt 发给 LLM。它做了大量的 Context Engineering 工作：
分析你的 Prompt，提取关键实体（文件名、函数名、错误信息） 在代码库中检索相关文件（AST 搜索、语义搜索） 读取 .cursorrules中的项目规范获取 Git 最近的修改历史 将以上信息组装成一个精心编排的上下文窗口 最后才发送给 LLM
你写的那句"修复这个报错"只占整个 Prompt 的不到 5%，剩下的 95% 都是 Context Engineering 的成果。
类比：如果 Prompt Engineering 是教你怎么写代码，Context Engineering 就是教你怎么管理内存——你需要精准地把最关键的信息放进有限的空间。
为什么 Context Engineering 如此重要？
因为 LLM 有一个致命弱点——Context Rot（上下文腐烂）。
所有 LLM 都有上下文窗口限制。即使像 Claude 3.5 有 200K token 的窗口，在实际使用中，当上下文超过一定长度后，模型的注意力会分散，"遗忘"早期的重要信息。
研究表明：上下文窗口越大，模型的推理精度反而可能下降。这就是 Context Rot。
所以，Context Engineering 的核心不是"塞更多信息"，而是"精选最关键的信息"。
第三阶段：Harness Engineering（2025-2026）
核心关注：「怎么约束和运行」
Context Engineering 解决了"给什么信息"，但还有一个更深层的问题没有解决——AI Agent 在真实环境中运行时，如何确保它的行为是安全的、可预测的、可观测的？
这就是 Harness Engineering——为 AI 构建运行时的"约束骨架"。
什么是 Harness？
在软件测试领域，Test Harness 是一个控制测试执行的框架。Agent Harness 沿用了这个概念——它是一个控制 AI Agent 执行的运行时框架。
一个完整的 Agent Harness 包含：
Harness 解决了什么问题？
安全性：LLM 可能输出危险的终端命令（rm -rf /），Harness 中的 Permission Gate 确保这些操作必须经过人类审批。
可靠性：LLM 会幻觉，可能调用不存在的 API 或者生成错误的代码。Harness 中的反馈循环机制会检测执行错误，把错误信息回传给 LLM，让它自我修正。
可观测性：当 Agent 运行了 15 分钟还没完成任务时，你需要知道它在做什么。Observability 层提供完整的工具调用链日志，让你能追踪每一步决策。
三大开源 Agent 的 Harness 实现
Claude Code（Anthropic，已开源）
TypeScript 实现的 Agent Harness，核心是一个名为 query.ts 的单线程 Agent Loop。特点是极致的 Context 压缩策略——MicroCompact（摘要对话历史）和 AutoCompact（自动检测上下文膨胀并触发压缩）。通过 CLAUDE.md 文件实现项目记忆持久化。
DeerFlow 2.0（字节跳动，60K+ Stars）
Python/LangGraph 实现的 SuperAgent Harness。独特之处在于 Orchestrator + Sub-Agent 的分层架构——一个"总调度员"负责分解任务，多个子 Agent 并行执行。还内置了沙箱隔离执行环境和 MCP Server 集成。
Hermes Agent（NousResearch，62K+ Stars）
Python 实现的自进化 Agent。最特别的是它的学习循环——Agent 在工作中会自动创建新的 Skill，并在后续使用中持续改进这些 Skill。跨会话的用户建模让它越用越了解你的偏好。
三个阶段的关系
这三个阶段不是替代关系，而是层层递进的包含关系：
Harness Engineering 包含 Context Engineering，Context Engineering 包含 Prompt Engineering。
一个好的 Agent 系统，底层依然需要好的 Prompt 设计（系统指令、工具描述），中间层需要精确的 Context 管理（信息检索、记忆压缩），但最关键的是外层的 Harness（安全边界、执行控制、可观测性）。
用一个更直观的类比：
写在最后
对开发者意味着什么？
如果你还停留在研究"怎么写 Prompt"的阶段，你可能已经落后了一个代际。
2026 年的 AI 工程化实践已经清晰地指向三个方向：
- 学会写 Context 而非 Prompt
— 为你的项目创建 CLAUDE.md或.cursorrules文件，写清楚技术栈、规范和禁区 - 理解 Agent Loop
— 阅读 Claude Code 或 DeerFlow 的源码，理解"推理→工具调用→反馈"的闭环机制 - 建立 Skills 知识库
— 把你团队的重复性工作流沉淀为可复用的 Skill，让 Agent 按标准流程执行
AI 不会取代开发者，但掌握了这三层工程范式的开发者，会拥有远超同行的生产力。
Prompt Engineering 让你和 AI 对话，Context Engineering 让 AI 理解你，Harness Engineering 让 AI 安全地为你工作。
