夜雨聆风
你有没有这种感觉？明明说 AI 能帮我们写代码、做方案、省时间，结果几个月下来，自己反而更累了。以前自己吭哧吭哧写，现在变成了一轮又一轮地“伺候”AI，写提示词、看结果、不满意、再写提示词、再改。
问题出在哪？因为你的工作方式还停留在 AI 工程的第一阶段。
过去三年，AI 工程经历了四次进化。理解这四次进化，你就能明白：为什么顶级开发者已经不再手动写提示词了，以及你应该如何跟上这波浪潮。
第一阶段：Prompt Engineering（提示词工程），学会“怎么问”
时间：2022-2024 年
这是最早被大家熟悉的概念。那时候，用 AI 的画风基本是这样的，你问一句，它答一句。
你说“帮我写个登录页面”，它写完了。你一看，“不行，按钮颜色不对”，它改了。你再一看，“哎呀，手机端适配呢？”它再补。
Prompt Engineering 关心的就是：人要怎么组织指令，让模型更准确地理解任务。为此，大家研究各种技巧：
让 AI 扮演某个角色（“请扮演资深架构师”）
明确输出格式（“请输出 Markdown 表格”）
要求分步骤思考（“请分步骤思考”）
补充几个示例（Few-shot）
这些技巧在 GPT-3.5 和 GPT-4 早期确实效果显著。Prompt Engineering 解决的核心问题是：怎么问，AI 才更容易答对。
适合的场景：写一段文案、总结一篇文章、提取几个要点、生成一个表格，这些相对明确、边界清晰的任务。
但问题来了：当任务变复杂之后，光靠 Prompt 就不够了。AI 可能不知道你的项目背景、不了解代码结构、也不清楚之前做过哪些决定。于是，重点开始从“怎么问”转向了“给它看什么”。
第二阶段：Context Engineering（上下文工程）， 学会“喂什么”
时间：2025 年
2024 年开始，越来越多团队发现：模型能力越来越强，但上下文质量成了主要瓶颈。
Context Engineering 要解决的问题是：执行任务时，应该把哪些信息放进模型的上下文里。
举个例子，你让 AI Agent 修改一个项目 Bug。它需要看到的不只是你的那句需求，还有：
相关代码文件
项目目录结构
错误日志和测试结果
团队规范和 README
历史 issue 和之前的修改记录
信息给少了，AI 可能缺少判断依据；信息给错了，它可能努力在错方向上越走越远；信息给得太多，它又可能抓不住重点。
RAG（检索增强生成）的兴起就是这一阶段的重要标志。企业知识库问答、代码库检索等场景，本质都是在解决“给 AI 看什么”的问题。
据 DataHub 2026 年的《State of Context Management Report》，82% 的 IT 和数据领导者认为，仅靠 Prompt Engineering 已经不足以支撑 AI 规模化应用；95% 的数据团队计划在 2026 年投资 Context Engineering 培训。
Context Engineering 正在变成一个非常强的“放大器杠杆”，既能放大好的工程实践，也同样会放大坏的结构问题。
但 Context 仍然解决不了另一个问题：很多真实业务问题需要持续执行、多轮决策和长期状态管理。修复一个 Bug、完成一个 Feature、撰写一份研究报告，这些任务往往持续几十分钟甚至几个小时。于是，第三阶段来了。
第三阶段：Loop Engineering（循环工程）， 学会“让 AI 自己干活”
时间：2026 年
2026 年 6 月初，Anthropic 工程师、Claude Code 的创建者 Boris Cherny 说了一句话，在技术社区迅速传开，不到 24 小时获得近 70 万次播放：
“我不再给 Claude 写提示词了。我有一堆循环（loops）在运行，它们才是在提示 Claude 并判断接下来该做什么。我的工作就是写循环。”
紧接着，现在 OpenAI 任职的“龙虾之父”Peter Steinberger 也发推表示：
“你不该再给编程 Agent 写提示词了。你应该设计一套循环机制，让这些循环去提示你的 Agent。”
什么是 Loop Engineering？
简单说就是：与其反复手工调试提示词，不如设计一套让 AI Agent 自主迭代的循环系统。“循环工程”
以前你修 Bug 的流程是：你贴报错 → AI 改代码 → 你跑一下 → 还有 Bug → 你再贴新报错……循环往复。
现在不一样了。你直接跟 AI 说：“去把我仓库里所有失败的 PR 修了，测试过了才算完。修不好就记下来，明天早上告诉我。”然后你就可以合上电脑下班了。
第二天早上打开电脑一看：AI 自己开了好几个独立的小隔间，互不干扰地改代码、跑测试，通过的已经帮你把合并请求都发好了。
Loop Engineering 的核心不是“定时”，而是“闭环” ，给 AI 装上一套“感知-决策-行动-反馈”的自动驾驶仪。
一个典型的 Agent Loop 包含五个要素：
明确的目标，让 AI 知道要完成什么
上下文管理，让 AI 知道相关信息
可调用的工具，让 AI 能做事情
对产出的评估，让 AI 知道做得对不对
判断何时停止的标准，让 AI 知道什么时候算完
Loop Engineering 的核心目标是：提高任务完成率。Prompt Engineering 关注回答质量，Loop Engineering 关注任务完成质量。
有开发者已经验证了这个方式，“我就在搭建循环流程，现在配置终于调顺了”。但也有人踩了坑：循环跑起来之后 Token 消耗飞快，这说明 Loop Engineering 本身也需要工程化。
那么问题来了：当 AI 开始持续工作、同时运行几十个甚至几百个实例时，新的问题出现了，如何管理多个 Agent？如何管理工具、记忆、成本、安全边界？这些问题超出了单个 Loop 的范围。于是，第四阶段来了。
第四阶段：Harness Engineering（驾驭工程）， 学会“搭平台”
时间：2026 年至今
如果说 Loop 是发动机，那 Harness 就是整辆车。
Harness Engineering（驾驭工程）是 2025-2026 年 AI Agent 领域最重要的工程范式转移。其核心公式非常简单：Agent = Model + Harness
Model（模型）提供推理能力，Harness（驾驭系统）则是模型之外的一切：系统提示词、工具调用接口、文件系统与沙箱环境、编排逻辑、反馈循环、观测与评估体系。
一个形象的类比：Harness 之于 Model，如同操作系统之于 CPU，无论 CPU 多强大，如果操作系统频繁崩溃，实际体验依然很差。
Terraform 的创造者 Mitchell Hashimoto 给出了一个更接地气的定义：“每当 Agent 犯了一个错误，你就花时间设计一个解决方案，使得 Agent 在未来不会再犯同样的错误。”
一个典型的 Harness 包含：
执行环境：Agent 代码在哪里运行、受到什么约束
工具接口：外部能力如何被描述、发现和调用
上下文管理：模型在短期、会话级和持久化层面能看到什么
生命周期与编排：从单 Agent 循环到多 Agent 协作的工作流组织
可观测性：捕获轨迹、成本、失败和可靠性信号
验证与评估：把任务转化为评估、失败归因和反馈
治理：权限、身份、策略、安全加固、审计和人工监督
为什么 Harness 在 2026 年爆火？
2026 年 2 月，OpenAI 一个小团队用 Harness 写出了 100 万行生产级代码。OpenAI 和 Anthropic 不约而同地提出了 Harness Engineering 的概念。
原因很简单：如果 2025 年是 AI Agent 证明自己会写代码的一年，2026 年就是发现“环境”比“模型”更重要的一年。
一张图看懂四次进化
如果你还在纠结怎么写一个完美的 Prompt，恭喜你，你还在第一阶段。Prompt 在 Agent 开发中的权重，已经从原来的 90% 降到了 30% 以下。它现在只是一个 API 调用的参数，不再是核心竞争力。
真正重要的是：怎么给 Agent 设计“思考框架”，让它自己知道怎么想、怎么做、怎么判断做完没有。
未来的趋势很清晰：
AI 系统正从“让模型回答问题”向“让系统完成任务”转变
关注点从模型能力转向稳定、低成本、可复用的基础设施
工程体系正在成为决定上限的关键因素
模型能力仍然重要，但未来几年最有价值的能力，将越来越集中在系统设计、评测体系、记忆管理、可观测性和运行时工程这些方向。