AI 工程三次范式转移：从提示词到上下文到驾驭
本文欲回答的核心问题：AI 工程实践在过去三年里发生了什么根本性变化，为什么过去管用的方法现在不够用了？
AI 工程实践从 2023 年到现在经历了一次清晰的三代演进。每一代解决的核心问题完全不同，但后一代都包含前一代的能力范围。理解这三代范式的区别，是理解当前 Agent 工程前沿实践的前提。
三代工程范式各解决什么问题
本节欲回答的核心问题：Prompt Engineering、Context Engineering 和 Harness Engineering 分别解决什么问题，它们之间是什么关系？
三代范式对应三个不同的核心问题。搞清楚每一代”在优化什么”，就能理解为什么工程方法必须升级。
第一代：Prompt Engineering（2023—2024）
这一代的核心问题是：怎么跟模型说话，让它给出更好的回答。
所有技巧都围绕一次对话展开。措辞的微调、输出格式的约束、few-shot 示例的选取、Chain of Thought 的引导——这些方法的共同特征是，工程师的全部工作集中在”输入框”里。你写好一段提示词，发出去，拿到结果，结束。
应用场景举例： 假设你需要模型帮你写一段数据清洗的 Python 脚本。在 Prompt Engineering 范式下，你的工作是把需求描述得足够清晰——输入是什么格式、输出要什么字段、异常值怎么处理、要不要日志。写好这段提示词，发送，拿到脚本，人工检查后使用。整个过程中，工程师的掌控范围就是那段提示词本身。
这一代在今天依然有效，但它有一个硬上限：它只能优化一次交互的质量。
第二代：Context Engineering（2025）
这一代的核心问题变了：单靠提示词不够，需要把整个上下文窗口当作工程对象来设计。
Shopify CEO Tobi 有一句话被广泛传播：”Context engineering is the new skill。”这句话精确捕捉了范式切换的信号。工程师不再只写一段提示词，而是要设计模型在这次调用中”看到的所有信息”。
RAG 检索系统从知识库中拉取相关文档片段，长上下文管理决定哪些信息留在窗口里、哪些被截断，tool use 编排让模型知道能调用哪些工具以及调用顺序，memory 系统让模型记住之前的交互历史——这些都属于 Context Engineering 的范畴。
应用场景举例： 还是数据清洗的场景，但这次不是一个脚本，而是一个持续运行的流水线。在 Context Engineering 范式下，你需要设计：每次调用模型时，从数据库 schema 文档中检索哪些字段定义？从历史清洗日志中提取哪些先例？工具列表里要不要包含数据 profiling 工具的调用接口？前一轮清洗的反馈要不要注入上下文？你优化的是模型看到的全部信息，而不只是一段提示词。
第三代：Harness Engineering（2026年初）
核心问题再次升级：Agent 可以自主运行几个小时甚至几天了，单次上下文的优化远远不够。
你需要设计的不再是”一次调用的输入”，而是 Agent 的整个运行时环境。多 Agent 协作架构决定了谁负责什么、信息怎么流转；评估反馈闭环决定了 Agent 的产出怎么被验证和修正；架构约束的机械化执行保证了 Agent 不会在规模扩大后失控；记忆的治理和验证机制确保了长期运行中知识的可靠性。
应用场景举例： 假设你要让 Agent 自主完成一个完整的数据平台的搭建，从 schema 设计到 ETL 流水线到监控告警，运行时间可能是几天。在 Harness Engineering 范式下，你需要设计：规划 Agent 怎么把需求拆成子任务？生成 Agent 写代码时受什么架构约束？评估 Agent 怎么验证每个子系统的正确性？多个 Agent 之间共享的记忆怎么防止污染？这些都不是”写好提示词”能解决的，它们是运行环境的工程设计。
三代之间的关系
每一代都包含前一代。Harness 包含 Context，Context 包含 Prompt。但每一代解决的核心问题完全不同。
反思与见解： 很多人把这三代看作”替代关系”，觉得有了 Context Engineering 就不需要学 Prompt 技巧了。但从包含关系来看，这更像是”操作系统内核”的升级——你依然需要写应用层代码（提示词），但决定系统上限的已经是底层架构（驾驭体系）。忽略这个层次差异，是很多团队在 Agent 项目中踩坑的根源。
Anthropic 的实践：让 Agent 互相评估
本节欲回答的核心问题：当 Agent 需要自主完成复杂任务时，怎么保证它的输出质量？自评估为什么不行？
Anthropic 工程师 Prithvi Rajasekaran 的实验揭示了一个反直觉的事实：让 Agent 评估自己的工作，基本没用。
自评估的失效
不管输出质量高低，Agent 给自己的评价永远是正面的。这不难理解——模型的生成倾向就是”顺着自己说下去”，让它否定自己的输出，等于让它对抗自身的生成逻辑。
这个发现直接否定了很多早期 Agent 框架的设计思路：生成代码 → 自我审查 → 修改 → 自我审查 → …这种循环看似合理，实际上审查环节形同虚设。
生成器与评估器分离
把生成和评估拆成两个独立 Agent 之后，效果完全不同。
评估器不是读代码然后打分，而是用 Playwright 实际操作页面——点按钮、填表单、验证功能是否正常工作。然后根据四个维度打分：设计质量、原创性、工艺细节、功能完整度。
应用场景举例： 假设生成器 Agent 做了一个登录页面。评估器不会去看 HTML 写得漂不漂亮，而是直接启动浏览器，打开页面，尝试输入用户名密码、点击登录按钮、检查跳转是否正确、验证错误提示是否显示。这就是”实际操作”而非”代码审查”的区别。
前端设计实验
在前端设计实验中，生成器经过 5 到 15 轮和评估器的来回迭代，在第十轮做出了一个 3D 空间导航方案。这个结果说明，评估器的反馈不是简单的”好/坏”二值判断，而是能推动生成器探索更高质量的解决方案。
全栈开发实验
全栈开发实验的架构更复杂。三个 Agent 分工协作：
| Agent 角色 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 规划器 | 把一句话需求展开成完整产品规格 | 用户的一句话描述 | 完整的产品规格文档 |
| 生成器 | 逐步实现产品 | 产品规格文档 | React + FastAPI + PostgreSQL 代码 |
| 评估器 | 做 QA 测试 | 可运行的产品 | 四维度评分 + 具体问题清单 |
对比数据
两组数据的对比非常直观：
-
单 Agent 方案： 20 分钟，花费 9 美元，产出不能用 -
完整 Harness 方案： 6 小时，花费 200 美元，交付了带精灵动画、AI 集成和导出功能的完整游戏
成本增加了 22 倍，时间增加了 18 倍，但产出从”不可用”变成了”完整可交付产品”。这个性价比在传统软件工程中几乎不可能实现。
最有价值的发现
随着 Opus 4.6 能力提升，sprint 分解可以去掉了，但评估器不能去掉。
这个发现的意义非常深远。Harness 的每个组件都编码了对模型局限性的假设。模型变强之后，有些假设不再成立——比如”模型能力不够，需要把任务拆得很细”。但有些假设永远成立——比如”模型不能客观评估自己的输出”。
识别哪些组件该留、哪些该删，是 Harness Engineering 的核心技能。
反思与见解： 这个发现让我想到一个类比：汽车发动机从化油器升级到电喷，很多机械部件被淘汰了，但冷却系统和润滑系统永远不会被淘汰——因为热力学定律不会因为技术进步而改变。同样，模型能力会提升，但”自我评估不可靠”这个特性可能接近某种结构性局限，不会随参数量增长而消失。做 Harness 设计时，区分”会过时的假设”和”不会过时的假设”，是最重要的判断力。
OpenAI 的实践：百万行代码零手写
本节欲回答的核心问题：当 Agent 能力足够强时，人类工程师的角色到底是什么？如何在百万行代码级别保持架构一致性？
OpenAI 的实验更激进。五个月，一个小团队用 Codex Agent 构建了大约一百万行代码的生产系统。零手写。应用逻辑、文档、CI 配置、可观测性基础设施、工具链全部由 Agent 生成。
工程师角色的彻底转变
工程师不再写代码。他们做三件事：
-
设计开发环境——决定 Agent 在什么条件下工作 -
用结构化 prompt 表达意图——告诉 Agent 要做什么 -
给 Agent 提供反馈循环——让 Agent 知道做得对不对
这三件事没有一件是”写代码”，但每一件都需要深厚的工程经验。设计开发环境需要理解依赖管理和工具链；表达意图需要把模糊需求结构化；提供反馈循环需要知道什么是”好的输出”。
深度优先工作法
OpenAI 管这套方法叫 depth-first working：把大目标拆成小构件，让 Agent 构建每个构件，然后用这些构件解锁更复杂的任务。
应用场景举例： 假设要构建一个数据分析平台。不是让 Agent “从首页开始写”，而是先让它构建最底层的类型定义和配置系统，然后用这些类型定义去构建数据模型层，再用数据模型层去构建 API 层，最后用 API 层去构建 UI。每一层的产出都是下一层的”建筑材料”。这种顺序不是随意的，而是由架构约束决定的。
六层架构治理
架构治理是这套系统能跑起来的关键。依赖层级被严格分为六层：
| 层级 | 名称 | 职责 | 约束规则 |
|---|---|---|---|
| 第 1 层 | Types | 类型定义 | 不能依赖任何其他层 |
| 第 2 层 | Config | 配置管理 | 只能依赖 Types |
| 第 3 层 | Repo | 数据访问层 | 只能依赖 Types 和 Config |
| 第 4 层 | Service | 业务逻辑层 | 只能依赖下层 |
| 第 5 层 | Runtime | 运行时环境 | 只能依赖下层 |
| 第 6 层 | UI | 用户界面 | 只能依赖下层 |
每一层的边界不是靠文档约定，而是靠 linter 和 CI 机械化执行。Agent 违反架构约束的 Pull Request 会被自动拒绝。这意味着 Agent 不能”绕过”规则——即使它有能力写出跨层调用的代码，CI 也会把它拦住。
应用场景举例： 假设生成器 Agent 在写 UI 组件时，直接调用了一个 Service 层的函数而没有通过 Runtime 层封装。这段代码在语法上完全正确，运行时也不会报错，但 CI 中的 linter 会检测到跨层依赖，自动拒绝这个 PR。Agent 必须修改代码，通过正确的层级路径调用。这就是”机械化执行”的含义。
Martin Fowler 的评价
Martin Fowler 的评价很到位：Harness Engineering 把 Context Engineering、架构约束和垃圾回收编码成了机器可读的制品，Agent 可以系统性地执行。
“机器可读的制品”是关键短语。架构约束不是写在 Wiki 里的文档，而是写在 linter 规则里的代码。Agent 不需要”理解”为什么不能跨层调用，它只需要知道”跨层调用会被 CI 拒绝”。这和编译器不让程序员写类型错误的代码是同一个逻辑。
反思与见解： OpenAI 实验中最让我震动的一点是”零手写”。但这并不意味着”不需要工程师”——恰恰相反，它意味着工程师的价值从”写代码”转移到了”设计约束”。这和软件工程史上反复出现的模式一致：汇编时代程序员直接操作寄存器，高级语言时代程序员描述逻辑由编译器操作寄存器，Agent 时代工程师描述约束由 Agent 写代码。每一层抽象都没有消灭工程能力的需求，而是把需求转移到了更高的抽象层。
记忆系统：Harness 里最容易被忽略的一层
本节欲回答的核心问题：当多个 Agent 长期协作时，共享记忆怎么保证可信？有记忆的 Agent 系统真的会随时间变好吗？
Anthropic 讲评估闭环，OpenAI 讲架构约束，但两家都没有深入讨论记忆。这恰好是两篇学术论文填补的空白。
(S)AGE 论文：拜占庭容错的多 Agent 记忆
核心问题：当多个 Agent 共享一个知识库时，怎么保证写入的知识是可信的？
一个 Agent 可能因为幻觉写入了错误信息，也可能被对抗性攻击注入虚假记忆。在单 Agent 场景下，幻觉只影响一次输出；但在共享记忆场景下，一条错误记忆会被所有 Agent 反复读取，影响是系统性的。
应用场景举例： 假设三个 Agent 协作维护一个 API 文档知识库。Agent A 因为幻觉把某个接口的返回格式记错了，写入了共享记忆。Agent B 和 Agent C 后续在生成代码时都会参考这条错误记忆，导致整个系统的接口调用全部出错。这就是”记忆污染”的级联效应。
Proof of Experience 共识机制
(S)AGE 论文提出的方案是 Proof of Experience 共识机制。每个 Agent 有声誉权重，权重由四个因子决定：
| 因子 | 说明 | 作用 |
|---|---|---|
| 历史准确率 | 该 Agent 过去写入的记忆被验证为正确的比例 | 过滤持续产出低质量信息的 Agent |
| 领域相关性 | 该 Agent 在待写入主题上的专业度权重 | 防止跨界写入不熟悉的领域 |
| 活跃度 | 该 Agent 的参与频率 | 防止僵尸账户操纵投票 |
| 独立验证数 | 其他 Agent 独立验证过该条记忆的次数 | 提高写入门槛 |
Agent 提交的记忆需要经过加权投票验证才能写入知识库。
性能数据
这套系统部署在 4 节点 BFT（拜占庭容错）网络上，实现了 956 req/s 的写入吞吐量和 21.6ms 的 P95 查询延迟。有这套记忆系统的 Agent 校准精度是无记忆基线的两倍。
纵向学习论文：记忆真的让系统变好吗
第二篇论文回答了一个更根本的问题：有记忆的 Agent 系统，真的会随时间变好吗？
实验设计
实验设计非常巧妙，直接对比两种策略：
-
治疗组： 3 行 prompt + (S)AGE 记忆系统，每轮可以查询之前所有轮次积累的知识 -
对照组： 50 到 200 行专家精心编写的 prompt，但没有记忆，每轮从零开始
跑 10 轮之后，结果如下：
-
治疗组的红队评估难度从 0.8 增长到 3.0（Spearman rho=0.716, p=0.020），说明系统确实在变强 -
对照组完全没有增长趋势（rho=0.040, p=0.901），说明再精心的 prompt 也无法带来纵向提升
最关键的发现
两组的绝对性能水平没有统计差异（Cohen’s d = -0.07）。3 行 prompt 加记忆和 200 行专家 prompt 打了个平手。
差异在于学习轨迹：有记忆的系统越跑越好，没记忆的永远在同一个水平线上。
应用场景举例： 想象一个安全审计 Agent 团队。第一周，它们发现了 10 种漏洞模式，写入共享记忆。第二周，新任务来的时候，它们可以直接参考上周的经验，发现更复杂的变种。到第十周，它们的审计能力已经远超第一周。而另一个团队，每周都拿同样的专家 prompt 从零开始，第十周和第一周的水平一样。这就是”纵向学习能力”的含义。
反思与见解： 这个实验结果让我重新思考了”prompt 工程”的价值天花板。200 行专家 prompt 和 3 行 prompt + 记忆打平——这意味着 prompt 工程的全部努力，在纵向维度上被记忆系统轻易抹平了。但这不意味着 prompt 工程没用，它意味着 prompt 工程解决的是”初始性能”问题，而记忆解决的是”成长性”问题。一个组织如果只投资 prompt 优化而不建记忆基础设施，就像一个公司只做培训而不建知识库——每个人的起点可能高一些，但永远不会变成一个”越做越好的组织”。
记忆层给 Agent 系统带来的不是更高的初始性能，而是组织级的纵向学习能力。人类组织的第 100 个项目通常比第 1 个好，因为有过程文档、事后复盘、知识库积累。现在 Agent 系统也开始展现同样的特征。
三代范式的本质区别
本节欲回答的核心问题：如果只能用一句话概括三代范式的区别，应该怎么说？
三代工程范式的区别可以用三句话概括：
-
Prompt Engineering 优化的是人和模型之间的接口 -
Context Engineering 优化的是模型的输入空间 -
Harness Engineering 优化的是 Agent 的整个运行时环境
Anthropic 的实验证明了评估闭环比自评估有效几个数量级。OpenAI 的实验证明了架构约束可以让 Agent 在百万行代码级别保持一致性。两篇论文证明了共识验证的记忆系统可以让 Agent 组织具备纵向学习能力。
这三层加在一起就是完整的 Harness：
| 层次 | 来源 | 解决的问题 | 缺失后的后果 |
|---|---|---|---|
| 评估机制 | Anthropic | 输出质量无法保证 | Agent 产出不可用 |
| 架构约束 | OpenAI | 规模扩大后一致性崩溃 | 百万行代码变成意大利面条 |
| 记忆治理 | 学术论文 | 长期运行无法积累经验 | 系统永远停在初始水平 |
少了任何一层，Agent 系统都会在某个维度上失控。
反思与见解： 回头看这三层，我发现一个有意思的模式：评估机制解决的是”现在好不好”的问题，架构约束解决的是”大了会不会乱”的问题，记忆治理解决的是”明天会不会更好”的问题。分别对应质量控制、可扩展性、可持续性——这恰恰也是传统软件工程的三座大山。Harness Engineering 并没有发明新的工程问题，它只是在 Agent 时代重新回答了那些老问题，而且答案的形式完全不同。
图片来源：Unsplash
实用摘要与操作清单
以下是如果你正在构建 Agent 系统，可以立刻对照检查的清单。
评估机制检查清单
-
[ ] 你的 Agent 系统中，生成和评估是否由不同的 Agent 执行？ -
[ ] 评估器是否通过”实际操作”（如浏览器自动化、API 调用）而非”读代码”来验证？ -
[ ] 评估维度是否明确且可量化（如设计质量、功能完整度等）？ -
[ ] 评估反馈是否以结构化形式回传给生成器，而非简单的”通过/不通过”？
架构约束检查清单
-
[ ] 你的依赖层级是否明确划分（如 Types → Config → Repo → Service → Runtime → UI）？ -
[ ] 层级边界是否通过 linter 和 CI 机械化执行，而非仅靠文档约定？ -
[ ] Agent 违反架构约束的提交是否会被自动拒绝？ -
[ ] 约束规则是否以机器可读的格式存储（如配置文件、规则脚本），而非自然语言文档？
记忆治理检查清单
-
[ ] 多 Agent 共享的记忆是否有写入验证机制？ -
[ ] 是否有声誉权重或类似的信任模型来区分不同 Agent 的写入可信度？ -
[ ] 是否有防幻觉写入和防对抗性注入的机制？ -
[ ] 系统是否具备纵向学习能力——即第 N 轮的表现是否优于第 1 轮？
范式定位检查清单
-
[ ] 你的团队当前主要在哪个范式上工作？（Prompt / Context / Harness） -
[ ] 如果 Agent 运行时间超过 1 小时，当前的 Context Engineering 方案是否足够？ -
[ ] 如果代码量超过 1 万行，当前的架构约束是否足够？ -
[ ] 如果项目要跑超过 10 轮迭代，是否有记忆基础设施支撑纵向学习？
一页速览
| 维度 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 时间 | 2023—2024 | 2025 | 2026 初 |
| 优化对象 | 人和模型的接口 | 模型的输入空间 | Agent 的运行时环境 |
| 核心技术 | 措辞、few-shot、CoT | RAG、长上下文、tool use、memory | 多 Agent 协作、评估闭环、架构约束、记忆治理 |
| 适用场景 | 单次对话 | 单次复杂调用 | 长时间自主运行 |
| 局限性 | 无法超越一次交互的质量上限 | 无法应对长时间运行的积累性问题 | 设计复杂度最高 |
| 关键假设 | “更好的表述 → 更好的输出” | “更好的上下文 → 更好的输出” | “更好的运行环境 → 更可靠的自主行为” |
| 包含关系 | 基础层 | 包含 Prompt | 包含 Context |
常见问答
Q1：Prompt Engineering 是不是已经过时了？
没有。Harness Engineering 包含 Prompt Engineering。你仍然需要写好提示词，但提示词只是整个 Harness 中的一个组件，不再是唯一的工程对象。
Q2：为什么 Agent 不能评估自己的输出？
因为模型的生成倾向是”顺着自己说下去”，让它否定自己的输出等于对抗自身的生成逻辑。实验数据表明，不管输出质量高低，Agent 的自评永远是正面的。
Q3：评估器用 Playwright 操作页面和读代码打分有什么本质区别？
读代码打分评估的是”代码看起来对不对”，Playwright 操作页面评估的是”产品实际上能不能用”。前者可以被代码表面质量欺骗，后者只关心实际行为。
Q4：OpenAI 实验中六层架构为什么必须用 CI 机械化执行？
因为 Agent 有能力写出跨层调用的正确代码。如果只靠文档约定，Agent 可以选择遵守也可以选择不遵守。CI 机械化执行让违反架构约束的代码根本无法合入，不依赖 Agent 的”自觉性”。
Q5：为什么 3 行 prompt 加记忆能和 200 行专家 prompt 打平？
因为记忆系统提供了”纵向学习”能力，可以在多轮迭代中积累经验弥补初始 prompt 的不足。而 200 行专家 prompt 虽然初始性能高，但没有记忆的系统无法跨轮次积累，永远停在同一个水平线上。
Q6：Proof of Experience 共识机制中的”声誉权重”四个因子哪个最重要？
论文没有给出单一因子的权重排序，但四个因子各有明确功能：历史准确率过滤低质量 Agent，领域相关性防止跨界写入，活跃度防止僵尸操纵，独立验证数提高写入门槛。它们共同构成一个完整的信任模型。
Q7：Harness Engineering 的核心技能到底是什么？
不是写提示词，不是搭 RAG，而是”识别哪些组件该留、哪些该删”。Harness 的每个组件都编码了对模型局限性的假设，模型变强后有些假设不再成立，但有些永远成立。区分这两种假设，是核心判断力。
Q8：我们团队刚开始做 Agent 项目，应该从哪个范式入手？
从 Context Engineering 入手是最务实的选择。它比 Prompt Engineering 有更高的上限，又比完整的 Harness Engineering 有更低的实现复杂度。但在设计 Context 方案时，应该预留评估机制和架构约束的接口，为后续升级到 Harness 做准备。
