AI Agent 构建的三次范式跃迁 —— 严谨性从未消失，只是不断迁移到更高的抽象层级
Prompt Engineering (2022-2024) Context Engineering (2025) Harness Engineering (2026+)
"Rigor doesn't disappear; it migrates toward feedback and closer to reality."
在 AI 工程领域，过去四年发生了三次范式跃迁。每次跃迁都不是对前者的否定，而是包容式升级——新的范式将旧范式作为子模块吸收进来，在更高的抽象层级上解决问题。
核心类比：
2022 年，我们学习如何写一封完美的邮件（提示词工程）。
2025 年，我们学习如何管理整个收件箱（上下文工程）。
2026 年，我们在设计邮件系统本身（Harness 设计范式）。
2022 — 2024
核心问题："我该怎么说？"
聚焦于单次指令的设计——Few-shot、Chain-of-Thought、角色扮演。
控制单元：消息级别 (Message-level)
2025
核心问题："我该提供什么信息？"
聚焦于上下文窗口中放入什么——RAG检索、记忆系统、工具结果、对话历史。
控制单元：会话级别 (Session-level)
2026+
核心问题："我该构建什么系统？"
聚焦于Agent的整个运行环境——工具链、约束规则、反馈循环、生命周期管理。
控制单元：系统级别 (System-level)
关键洞察：每次范式转变都源于前一个范式的失败——
• 提示词工程的天花板：指令写得再好，如果上下文窗口里没有需要的信息，Agent 也无能为力
• 上下文工程的天花板：上下文组装得再完美，如果消费它的循环（loop）设计得不好，Agent 依然会失败
• 严谨性没有消失，只是迁移了——从写提示词，到管理上下文，到设计系统架构
2022年6月，GitHub Copilot 公开发布；同年11月，ChatGPT 上线，5天破百万用户。Andrej Karpathy 将这个时刻称为 "Software 3.0"——如果 Software 1.0 是人写代码，2.0 是神经网络权重，那 3.0 就是自然语言指令即程序。
"The hottest new programming language is English." — Andrej Karpathy, 2023
💬
直接提问或提供少量示例，让模型校准行为。无需微调，即开即用。
🧠
"Let's think step by step" — 仅加一句话，GSM8K 数学准确率从 17.9% 跳到 58.1%。
🔄
Thought → Action → Observation 循环。模型自主搜索、观察、再推理。Agent 原型诞生。
🎭
"你是一个资深开发者" + "请以 JSON 格式输出" — 通过人设和格式约束提升输出质量。
| 模式 | 原理 | 特点 |
|---|---|---|
| 反思 Reflection | 模型审查并修正自己的输出 | 最稳定、最可预测的模式 |
| 工具使用 Tool Use | 模型决定何时调用外部工具 | 区分 Agent 与 Chatbot 的关键 |
| 规划 Planning | 将复杂任务分解为子任务 | 最强大但最脆弱 |
| 多 Agent 协作 | 专业化 Agent 各司其职 | 最具潜力，当时最雏形 |
关键发现：Andrew Ng 发现："用 Agent 工作流包裹 GPT-3.5，在某些基准上超越了 GPT-4 零样本。" 不换模型，只改变模型周围的模式，就能带来性能飞跃。这是提示词工程的顶峰，也暗示了"模型之外的系统很重要"。
想象这个场景：一个团队花了3周打磨编码 Agent 的提示词——"复用已有代码"、"写测试"、"不留未使用的导入"。指令越写越长，简单任务一切正常。然后项目规模扩大，问题出现了：
!
Agent 无视已有的工具函数，从零重写
无论你在提示词里写多少遍"复用已有代码"，如果那个工具文件不在上下文窗口里，Agent 根本不知道它的存在。
死因诊断：这不是提示词问题，是上下文问题。Mitchell Hashimoto 称之为"盲写提示词" (Blind Prompting)——通过试错来写提示词，不做严格测量。更接近炼金术而非软件工程。
"I much prefer the term 'context engineering' over 'prompt engineering'. It describes the core skill much better. The art of providing all the context for the task to be plausibly solvable by an LLM." — Tobi Lütke, Shopify CEO, 2025.06.19
"Context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy, 2025.06.25
传统操作系统 内核 Kernel RAM 内存 文件系统 系统调用 进程管理 → LLM 操作系统 LLM 推理引擎 上下文窗口 RAG / 向量DB Tool Call / API 多 Agent 编排
类比解读：提示词只是输入操作系统的一条命令。真正决定性能的是RAM（上下文窗口）里加载了什么。
你的 ls 命令写得再精准，如果需要的文件在一个没有挂载的磁盘上，也无济于事。
W
Write — 写入：结构化系统提示词
关键不是"说什么"，而是"如何结构化"。清晰的格式 > 模糊的自然语言。
S
Select — 选择：只检索相关文档
防止 "Lost-in-the-Middle" 问题——长上下文中间部分的信息会被遗忘。信噪比 > 信息量。
C
Compress — 压缩：对话历史摘要化
20轮对话后，把前15轮压缩为摘要。Anthropic 报告：好的压缩能保留 80%+ 信息，显著降低 Token 消耗。
I
Isolate — 隔离：子 Agent 独立上下文
技术问题的诊断交给子 Agent，避免日志分析数据污染主对话上下文。
1
单轮局限
大多数上下文工程技术聚焦于"这次 API 调用放什么"。但 Agent 不是单轮的——它做几十个链式决策。如果第15轮需要第3轮已被压缩掉的工具结果呢？
2
无错误恢复
工具调用失败、模型幻觉、成本飙升……无论上下文组装得多好，处理运行时异常需要独立的机制。
3
安全问题
如果 Agent 处理外部输入的同时访问敏感数据并可修改状态，一次提示注入就能泄露公司数据。上下文工程解决"放什么进去"，但不解决"防止什么"。
死因：即使完美的上下文，在消费它的系统设计得很差时依然会失败。上下文是必要条件，不是充分条件。
2026年2月，Mitchell Hashimoto（Terraform 创始人）发表"My AI Adoption Journey"，提出了一个简洁有力的原则：
每当 Agent 犯错 → 改变系统，使该错误在结构上不可能再次发生
不是修改提示词，是改变 Agent 周围的系统——规则、工具、约束、反馈循环
两周内，OpenAI、Martin Fowler/Birgitta Böckeler（ThoughtWorks 首席技术顾问）、Ethan Mollick（沃顿商学院教授）各自独立发表了相同的结论。在科学史上，这叫"多重发现"——思想的时代到了。
Agent = Model + Harness
Martin Fowler / Birgitta Böckeler 提出：Harness = "Agent 中除模型以外的一切"
Philipp Schmid 的 OS 类比
提供原始计算能力——推理、生成、理解。
"模型是处理器，Harness 是操作系统"
Ethan Mollick 的马具类比
将马的力量连接到犁或马车。没有缰绳和鞍具，再强壮的马也耕不了地。
"Harness 把模型的能力转化为有用的工作"
Simon Willison 的定义
"Agent 是一个 LLM，在循环中运行工具来达成目标。" 关键词是循环——Harness 就是控制这个循环的系统。
"循环的设计，才是核心竞争力"
G
Guides（前馈控制 / 事前引导）
AGENTS.md 文件、.cursorrules、编码规范文档——在 Agent 开始工作之前就塑造其行为。成本接近零，但没有强制执行力。
S
Sensors（反馈控制 / 事后校验）
编译器、Linter、类型检查器、LLM-as-Judge——在 Agent 执行之后捕获和纠正错误。这是 OpenAI Codex 团队最强调的部分。
T
Toolchain Management（工具链管理）
Agent 可调用的工具集、API、数据源——包括权限范围、速率限制、参数校验。工具设计决定了 Agent 的能力边界。
M
Memory & State（记忆与状态系统）
持久化存储 Agent 的决策、任务历史和跨会话上下文。包括对话压缩、长期记忆（AGENTS.md）、Git 历史状态。
L
Lifecycle Management（生命周期管理）
Agent 的部署、版本控制、回滚、可观测性。权限升级、人在回路(Human-in-the-loop)、安全护栏。
这是理解三次范式跃迁的核心框架：
提示词工程时代 程序 → 输入 → LLM → 输出 用户输入 → 精心设计的提示词 → LLM → 单次输出 上下文工程时代 程序 → 上下文组装 → LLM → 输出（带工具调用） RAG检索 记忆注入 工具结果 → LLM → 输出 + 工具调用 Harness 设计范式时代 Harness(环境) + LLM 决策 → 循环执行 → 可靠产出 工具集 bash 编辑 read/write 约束 AGENTS.md 权限 Permission 记忆 Memory 反馈 Loop LLM
本质变化：以前我们写程序，输入 LLM，得到输出。现在我们设计环境（Harness），让 LLM 在这个环境中自主决策和行动。
核心转变：
• 从"我如何写出好的提示词" → "我如何设计好的运行环境"
• 从"程序控制 LLM" → "Harness 约束 LLM 的决策空间"
• 从"一次性输入输出" → "LLM 在环境中循环执行，直到任务完成"
Cursor 团队在"自驾代码库"计划中发现了一个反直觉的真相：约束 Agent 的解空间，反而大幅提升了生产力。
原理：当 GPT-5 或 Claude 4 能生成"任何东西"时，它会浪费大量 Token 探索死胡同和无意义的方案。 一个精心设计的 Harness 划定了一条清晰的通向成功的路径——明确的边界、架构规则、有限的高质量工具——迫使 Agent 更快收敛到正确答案。
数据证明：同一个模型、同一份数据、同一个提示词，仅靠改变 Harness 配置，编程基准成功率从 42% 跳到 78%。
确认：经过源码分析，OpenCode 项目确实基于 Harness 设计范式构建。它不只是一个"调用 LLM API 的应用"，而是一个完整的 Agent 运行环境——定义了工具集、权限系统、记忆机制、反馈循环和生命周期管理。
OpenCode Harness（Agent 运行环境） ① Guides（前馈引导层） System Prompt 系统提示 AGENTS.md Agent 角色定义 环境信息注入 Skill / Plugin 扩展 ② Toolchain（工具链层） bash 终端 read 读取 write 写入 edit 编辑 grep 搜索 glob 匹配 task 子任务 question 提问 todo 任务 websearch webfetch codesearch ls 目录 lsp 语言服务 ③ Permission（权限控制层） allow 允许 ask 询问 deny 拒绝 doom_loop ④ Memory（记忆系统层） Compaction 压缩 Summary 摘要 Prune 裁剪 ⑤ Sensors（反馈循环层） Zod 参数校验 输出截断 Truncate Doom Loop 检测 溢出检测 Overflow 重试机制 Retry Session Loop（核心执行循环） while(true) { stream → tool_call → execute → feedback → repeat }
| Harness 组件 | OpenCode 实现 | 核心文件 | 作用 |
|---|---|---|---|
| Guides（引导） | System Prompt + AGENTS.md + Agent 角色定义 | session/system.tsagent/agent.ts |
每轮循环前注入系统提示词，按模型类型选择不同 Prompt 模板；AGENTS.md 提供跨会话持久规则 |
| Toolchain（工具链） | 20+ 注册工具（bash、read、write、edit、grep、task、question...） | tool/*.tstool/registry.ts |
每个工具有 Zod Schema 参数校验、权限请求、输出截断。Agent 自主决定调用哪个工具 |
| Permission（权限） | 三级权限系统 allow / ask / deny + Doom Loop 检测 | permission/next.ts |
按工具、文件模式、Agent 角色配置权限。.env 文件读取需询问，外部目录需授权 |
| Memory（记忆） | Compaction 压缩 + Summary 摘要 + Prune 裁剪 + Instruction 注入 | session/compaction.tssession/summary.ts |
对话过长时自动压缩旧消息为摘要，工具输出自动裁剪，AGENTS.md 跨会话持久 |
| Sensors（反馈） | Zod 校验 + 输出截断 + Doom Loop 检测 + 重试机制 | tool/tool.tssession/processor.ts |
工具参数无效时抛出错误让 Agent 重试；连续3次相同调用触发 Doom Loop 告警 |
OpenCode 的 SessionProcessor 就是 Harness 的"心脏"——控制 Agent 的执行循环：
// packages/opencode/src/session/processor.ts - 简化伪代码
while (true) { // ← Agent 执行循环
let stream = await LLM.stream(input) // ① 调用 LLM
for await (value of stream) { // ② 处理流式输出
switch (value.type) {
case "tool-call": // Agent 决定调用工具
// Doom Loop 检测：连续 3 次相同调用 → 请求权限确认
if (lastThreeCallsAreSame()) {
await Permission.ask("doom_loop")
}
break
case "tool-result": // 工具返回结果
// 输出截断：超长输出自动裁剪
await Truncate.output(result)
break
}
}
// ③ 检查是否需要压缩记忆
if (isOverflow(messages)) await Compaction.run()
// ④ 检查是否完成（无更多工具调用 → 结束循环）
if (noMoreToolCalls) break
}OpenCode 内置多个角色化 Agent，每个有不同的工具权限和职责：
🔨
执行工具、编辑代码、回答问题。拥有 question + plan 权限。是日常开发的主力。
📋
只读模式——禁止所有编辑工具，只能规划。只允许编辑 .opencode/plans/ 下的 .md 文件。
🔍
快速代码库探索——只有 grep、glob、list、read、bash、websearch 权限。不写只读。
🧹
隐藏 Agent——当对话过长时被调用，将所有工具权限设为 deny，专注于对话压缩。
Harness 体现：每个 Agent 不是"一个不同的模型"，而是"同一个模型 + 不同的 Harness 配置"。
• 不同的工具权限（explore 只能读不能写）
• 不同的 System Prompt（不同角色有不同的行为引导）
• 不同的生命周期（compaction 是隐藏的、按需触发的）
这就是 Harness 范式的核心：模型不变，环境可变。
核心洞察：回到人体隐喻——工具就是 Agent 的眼睛（感知世界）和双手（改造世界）。
但每个工具不只是"一个能力"，它背后解决一个特定的 Harness 问题：上下文污染、规划跑偏、安全控制、信息过时……
理解每个工具为什么存在，比知道它怎么用更重要。
父 Agent (build) 上下文窗口 A 用户消息 + 对话历史 System Prompt + AGENTS.md 工具调用结果 → Task → 只传递 prompt 子 Agent (explore/general) 独立上下文窗口 B 父 Agent 的任务描述 子 Agent 自己的工具调用 子 Agent 的中间推理 ← 结果 ← 只返回最终文本 所有中间过程 不会污染父 Agent 上下文！
解决的问题：上下文窗口有限
Agent 的上下文窗口是固定大小的"工作记忆"。如果让一个 Agent 同时完成"搜索代码库 + 修改代码 + 运行测试"，
搜索产生的大量中间结果会填满上下文窗口，挤压后续操作的空间。
Harness 策略：
• Task 工具创建一个独立的子 Session（子 Agent 有自己的上下文窗口）
• 子 Agent 在自己的上下文中自由探索、调用工具、产生中间结果
• 完成后只返回最终文本结果给父 Agent——中间过程全部丢弃
• 父 Agent 的上下文窗口保持干净，只看到精炼的结论
源码证据：task.ts:73-103 — 子 Session 通过 Session.create({parentID: ctx.sessionID}) 创建，
且子 Agent 被禁止使用 todowrite/todoread 工具（避免干扰父 Agent 的任务追踪）。
1
先规划，再行动
当任务需要 3 步以上时，Agent 被引导使用 Todo 工具创建结构化任务列表。相当于让 LLM 在动手之前先写"施工方案"。
2
做完一步，打一个钩
每个任务有 4 种状态：pending → in_progress → completed / cancelled。同一时间只允许一个任务为 in_progress。完成后立即标记，不批量操作。
3
用户可见的进度追踪
Todo 列表对用户可见——用户能实时看到 Agent 的计划、进度、正在做什么。这是 Human-in-the-loop 的关键机制。
解决的问题：Agent 执行复杂任务时容易"走偏"
没有 Todo 时，LLM 可能在第 5 步忘了第 1 步的目标，或者跳过了关键步骤。
Todo 本质上是 Harness 中的前馈引导 + 反馈校验——计划本身就是引导，每步打钩就是校验。
关键设计：子 Agent 被禁止使用 Todo（task.ts:79-86），因为任务追踪是父 Agent 的职责。
这防止了子 Agent 创建自己的任务列表与父 Agent 的计划冲突。
Q
Agent 遇到歧义 → 暂停执行 → 向用户提问 → 获得答案后继续
这是一个阻塞式工具——调用时 Agent 执行暂停，通过 SSE 推送问题给前端，等待用户回答后才 resume。支持预设选项和自定义回答。
解决的问题：Agent 不该在关键决策上自作主张
• "使用 React 还是 Vue？" — 实现选择
• "是否删除这个文件？" — 破坏性操作确认
• "这个需求有两种理解，你想要哪种？" — 歧义澄清
Harness 体现：这是安全护栏的核心——Agent 不是无限自主的，在关键分叉点必须寻求人类确认。 对应 Stripe 的"Two-Strike"规则：不确定时，问人比猜错好。
| 安全机制 | 实现方式 | 源码位置 |
|---|---|---|
| AST 解析命令 | 用 tree-sitter 解析 bash 命令的 AST，提取每个命令和操作的路径 | bash.ts:84-141 |
| 外部目录保护 | 如果命令涉及项目目录外的路径（如 rm /etc/xxx），触发 external_directory 权限询问 | bash.ts:144-156 |
| 命令权限 | 每个命令都需要 bash 权限确认，支持"always allow"记忆 | bash.ts:158-165 |
| 超时保护 | 默认 2 分钟超时，超时后自动 kill 进程树 | bash.ts:225-228 |
| 输出截断 | 超长输出自动保存到文件，建议用子 Agent 处理 | truncation.ts |
解决的问题：Agent 需要执行能力，但执行是危险的
Bash 是 Agent 最强大的工具——能运行任何命令。但也最危险。
Harness 策略：不是限制能力，而是在能力外面包一层安全壳。
用 AST 解析理解命令意图，用权限系统控制执行边界，用超时防止失控。
E
精确字符串替换，而非全文重写
强制规则：必须先 Read 文件才能 Edit（防止盲改）。
匹配策略：oldString 必须唯一匹配——如果找到多个匹配，报错要求提供更多上下文。
防误操作：优先编辑已有文件，禁止主动创建新文件（除非明确要求）。
解决的问题：LLM 重写整个文件会引入意外变更
精确替换 > 全文重写。强制先读后改 > 凭记忆改。唯一匹配 > 模糊匹配。
这些约束都是 Harness 的"确定性前馈控制"——在结构上阻止 Agent 犯常见错误。
📖
解决的问题：Agent 需要"看到"代码才能操作。带行号输出，支持分页读取大文件。目录列表功能用于项目探索。
✍️
解决的问题：创建新文件。强制规则：覆写已有文件必须先 Read。禁止主动创建文档文件（除非用户明确要求）。
🔍
解决的问题：在大型代码库中快速定位包含特定模式的文件。用正则表达式搜索，按修改时间排序返回结果。
📁
解决的问题：按文件名模式查找文件（如 **/*.tsx）。与 Grep 互补——一个搜内容，一个搜文件名。
🌐
解决的问题：突破训练数据截止日期——Agent 需要获取最新的 API 文档、技术资讯。自动注入当前年份避免搜到过旧信息。
📥
解决的问题：读取特定 URL 的内容。将网页转为 Markdown 注入上下文，让 Agent 能"阅读"文档。
💻
解决的问题：搜索框架、SDK、API 的最新代码示例和文档。比 WebSearch 更精准——专门针对编程场景优化。
🔗
解决的问题：给 Agent "IDE 级"的代码智能——跳转定义、查找引用、悬停提示、调用层级。让 Agent 理解代码结构，而不只是文本搜索。
B
Batch（批量并行）—— 效率策略
解决的问题：串行执行多个独立工具调用太慢。
Batch 允许一次提交最多 25 个工具调用，并行执行。例如同时读取 5 个文件 + 搜索 2 个模式 + 运行 1 个命令。
文档明确说："BATCH TOOL WILL MAKE THE USER HAPPY"——2-5x 效率提升。
S
Skill（技能加载）—— 懒加载策略
解决的问题：预加载所有技能说明会浪费上下文 Token。
Skill 工具在工具列表中只显示名称和一句话描述（稳定前缀，不破坏 KV-cache）。
当 Agent 判断需要某个技能时，再按需加载完整的指令、脚本、参考资料到上下文末尾（可变后缀）。
这正是 Google ADK 提出的 Stable Prefix / Variable Suffix 模式的实践。
P
Plan Agent（只读规划）↔ Build Agent（读写执行）
解决的问题：如果让同一个 Agent 既规划又执行，它容易在规划阶段就"手痒"开始改代码。
Plan 模式通过权限系统强制分离：Plan Agent 的所有编辑工具设为 deny，只能读写 .opencode/plans/*.md 文件。
规划完成后，通过 plan_exit 工具征求用户确认，切换到 Build Agent 执行。
这是 Harness 中角色化隔离的经典实践。
解决的问题：工具输出过长会撑爆上下文窗口
当 bash 命令输出了 10 万行日志，直接注入上下文会导致后续交互质量急剧下降。
策略：
• 硬限制：最多 2000 行 或 50KB（先到先截）
• 完整输出保存到文件（7 天后自动清理）
• 如果 Agent 有 Task 工具，提示它委派子 Agent 去处理截断文件——再次利用上下文隔离！
• 如果没有 Task 工具，提示用 Grep 搜索或 Read 分段读取
这个设计把"截断"和"子 Agent"两个策略串联起来，形成完整的防护链。
| Agent 面临的问题 | Harness 策略 | 对应工具 |
|---|---|---|
| 上下文窗口有限 | 上下文隔离 | Task（子 Agent 独立上下文） |
| 复杂任务容易跑偏 | 结构化规划 + 进度追踪 | TodoWrite / TodoRead |
| 关键决策不应自作主张 | 人在回路（阻塞式提问） | Question |
| 需要执行能力但执行危险 | 安全壳（AST解析+权限+超时） | Bash |
| 全文重写引入意外变更 | 精确替换 + 先读后改 | Edit |
| 不知道代码库结构 | 多维度搜索 | Read + Grep + Glob + LSP |
| 训练数据过时 | 实时信息获取 | WebSearch + WebFetch + CodeSearch |
| 串行执行太慢 | 并行批处理 | Batch |
| 预加载技能浪费 Token | 懒加载（按需注入） | Skill |
| 规划和执行混在一起 | 角色化读写分离 | Plan (enter/exit) |
| 工具输出撑爆上下文 | 截断 + 委派子 Agent | Truncation |
Fowler/Böckeler 将 Harness 的控制机制整理为清晰的 2×2 框架。这个模型帮助我们理解，Harness 如何在 Agent 执行的不同阶段施加影响：
在 Agent 开始之前，通过确定性规则引导方向。
成本接近零，但无强制力——Agent 可以忽略。
在 Agent 执行之后，通过机械手段捕获错误。
OpenAI Codex 团队最强调的象限——用 Linter 替代人类审查者。
处理确定性规则无法覆盖的细微场景。
更像指南而非规则，但比 Guides 更具体。
捕获"能编译但语义错误"的问题。
成本最高，但能捕获最深层的问题。
OpenCode 的四象限覆盖：
• 引导：AGENTS.md + System Prompt + Agent 角色配置（按模型类型选择 Prompt 模板）
• 计算校验：Zod 参数校验（工具参数无效时抛错）+ 输出截断 + Doom Loop 检测
• 指令：System Prompt 中的行为约束（如 "prefer functional array methods"）
• 推理校验：Agent 可以看到工具输出（如 bash 报错），形成自我修正循环
数据：5个月 | 7名工程师 | 0 行手写代码 | ~100 万行生成代码 | ~1500 个 PR | 速度约为手写的 10 倍
七名工程师五个月没写一行代码。他们在做什么？
1
系统化仓库知识
Agent 反复犯同样的错——因为架构决策在 Slack 里讨论的，设计原则只在资深开发脑子里。"对 Agent 不可见的知识，等于不存在。" 所以他们把每条原则都文档化为 Markdown 写入仓库。
2
机械化执行约束
光写文档不够——"请使用这种模式"会被忽略。他们构建了自定义 Linter 和结构化测试来强制执行架构规则。Agent 自动修复代码以通过 Linter。
3
渐进式信息披露
最初尝试一次性注入大量文档——Agent 迷失了。"给 Codex 一张地图，而不是一本 1000 页的手册。"
"Agents aren't hard; the Harness is hard." — Ryan Lopopolo, OpenAI Codex Team Lead
| 维度 | 实现 |
|---|---|
| 规模 | 每周自动合并 1,300+ PR，无需人类监督 |
| Blueprint 编排 | 将工作流分为确定性节点（运行 Linter、推送 Commit）和Agent 节点（实现功能、修复 CI） |
| Two-Strike 规则 | 如果 Agent 第一次修复 CI 失败，第二次也失败，立即升级给人类。不允许 Agent 在无限重试循环中浪费资源 |
Anthropic 发现了一个根本性缺陷：Agent 无法准确评估自己的工作。就像一个学生不应该批改自己的试卷。
将简短的需求描述扩展为详细的产品规格。关注雄心勃勃的范围和高层设计，不涉及技术细节。
"过于具体的技术指令会导致级联错误"
每次实现一个功能。每个 Sprint 后自评，然后交给 QA。通过 Sprint 机制定期重置上下文。
"分而治之，逐个击破"
用 Playwright 运行 E2E 测试——点击按钮、检查 API、验证数据库。低于阈值？退回 Generator 并附带具体反馈。
"独立评估者比自我批评更容易工程化"
成本对比：单独运行 = 20分钟 / $9（但产出有 bug）；完整 Harness = 6小时 / $200（但功能完整）。
成本差了 22 倍，但能力差异才是关键——这不是成本增加，而是成本的重新分配：从事后人工修复，转移到事前系统验证。
| 维度 | 提示词工程 (2022-2024) | 上下文工程 (2025) | Harness 设计范式 (2026+) |
|---|---|---|---|
| 核心问题 | "我该怎么说？" | "我该提供什么信息？" | "我该构建什么系统？" |
| 类比 | 写一封完美的邮件 | 管理整个收件箱 | 设计邮件系统本身 |
| OS 类比 | 一条命令 | RAM 管理 | 整个操作系统 |
| 控制层级 | 消息级 Message-level | 会话级 Session-level | 系统级 System-level |
| 关键指标 | 输出质量（主观） | KV-cache 命中率 | 任务完成率、单任务成本 |
| 失败模式 | 盲写提示词、非确定性 | 上下文污染、中间遗忘 | 编排 Bug、安全事件 |
| 严谨性所在 | 提示词文本 | 上下文窗口组装 | 整个系统架构 |
| 代表工具 | ChatGPT, 早期 Copilot | Cursor Composer, RAG 管线 | Claude Code, OpenCode, Copilot Coding Agent |
| 所需技能 | 语感 + 领域知识 | 信息架构 | 系统设计 + 安全 |
| 包含关系 | 上下文工程的子集 | Harness 工程的子集 | 包含前两者 |
关键理解：这三个范式不是竞争关系，而是嵌套包含关系。
• Harness 工程包含上下文工程，上下文工程包含提示词工程
• 一个好的 Harness 仍然需要好的上下文，好的上下文仍然需要好的提示词
• "提示词工程已死"的说法是错误的——它没有死，只是被吸收为更大系统的子模块
旧思维
过渡思维
新思维
1
"Agent 犯错时，不要怪 Agent——改进 Harness"
每次发现 Agent 犯了一个错误，就花时间构建一个解决方案，使它在结构上不可能再犯同样的错。这是 Mitchell Hashimoto 的核心原则。
2
"约束用 Linter 执行，不用提示词请求"
"请使用这种模式"写在文档里会被忽略。用 Linter 强制执行，Agent 就会自动修复代码以通过检查。
3
"给 Agent 一张地图，而不是一本 1000 页的手册"
渐进式信息披露——Agent 需要时再加载详细信息。一次性注入太多文档会让 Agent 迷失。
4
"Harness 应该可拆卸"
随着模型进步，Harness 中的一些"聪明"逻辑会变得不再必要。好的 Harness 设计在于"构建什么"和"什么容易移除"同样重要。
5
"对 Agent 不可见的知识等于不存在"
架构决策在 Slack 讨论的、设计原则只在资深开发脑子里的——这些 Agent 都看不到。把每条原则文档化到仓库中。
📝
把团队的编码规范、架构决策、项目约定写入 AGENTS.md，让 Agent 在每次会话开始时自动加载。
🔧
基于 OpenCode 的工具注册机制，为团队特有场景构建专属工具（数据库查询、内部 API 调用等）。
🛡️
把架构约束转化为 Linter 规则，而非依赖提示词。Agent 写完代码后自动检查，不通过则自动修复。
📊
记录 Agent 犯过的错误，每次犯错后更新 Harness 配置。让 Harness 越来越健壮。
最终总结：
提示词工程时代，我们是写作者——精心雕琢每一条指令。
上下文工程时代，我们是图书管理员——组织和检索正确的信息。
Harness 设计范式时代，我们是建筑师——设计 Agent 生活和工作的整个环境。
严谨性从未消失。它只是迁移了——从写代码，到管理上下文，到设计系统。
我们的工作不是变少了，而是升维了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。