当前位置：首页 > news >正文

从提示词工程到 Harness 设计范式

news 2026/6/18 4:52:11

从提示词工程到 Harness 设计范式 —— AI Agent 构建的三次范式跃迁

从提示词工程到 Harness 设计范式

AI Agent 构建的三次范式跃迁 —— 严谨性从未消失，只是不断迁移到更高的抽象层级

Prompt Engineering (2022-2024) Context Engineering (2025) Harness Engineering (2026+)

直觉总览：用"人造人"理解三次范式跃迁

 核心比喻：如果我们把构建 AI Agent 比作"造一个人"——
• 大脑 = LLM（推理、决策的中枢）
• 眼睛 = Read / Grep / WebSearch 等感知工具（LLM 用什么"看"世界）
• 双手 = Write / Edit / Bash 等执行工具（LLM 用什么"改造"世界）
• 神经系统 = 反馈循环（Doom Loop 检测、Zod 校验、输出截断）
• 骨骼 / 骨架 = 约束系统（AGENTS.md、权限、Linter）
• 记忆 = Todo + Compaction + AGENTS.md（短期工作记忆 + 长期知识）
• Harness = 造出这整个身体 + 工作环境，让大脑能调度眼睛和手去完成任务

提示词工程时代2022 — 2024"只有一个大脑"上下文窗口（罐子）LLM大脑→→提示词回答一问一答没有眼睛，没有手只能基于训练知识回答相当于一个博学的大脑被关在隔音房间里只能通过门缝传纸条上下文工程时代2025"大脑 + 眼睛 + 记忆"LLM大脑RAGMemory检索文档 | 对话历史 | 工具结果🤷还没有手！能看不能做相当于大脑有了眼睛和记忆能看到相关文件和历史但还是无法动手操作Harness 设计范式2026+"完整的身体 + 工作环境"骨骼 = 约束AGENTS.mdPermissionLinterLLM大脑ReadGrepWebSearchLSPGlobCodeSearchTodo任务追踪（计划 → 执行 → 打钩）EditWriteBash 终端QuestionTask子Agent派遣神经系统 = 反馈循环Zod校验 | 截断 | Doom Loop检测记忆 = Compaction + AGENTS.md相当于大脑 + 眼睛 + 双手 + 骨骼 + 神经在精心设计的工作环境中大脑自主调度：想看什么，想做什么Harness 造的是整个"人"和"办公室"→有了眼睛→有了身体

用人体理解"LLM 决策 + 环境"的本质转变

人体部位	对应组件	职责	OpenCode 中的工具	何时介入
🧠 大脑	LLM 推理引擎	理解意图、规划步骤、决定调用哪个工具	Claude / GPT / Gemini 模型	每轮循环的核心决策
👁️ 眼睛	感知工具（只读）	让大脑"看到"代码、文件、网络信息	Read, Grep, Glob, LSP, WebSearch, WebFetch, CodeSearch	大脑想看什么就看什么
🤲 双手	执行工具（写入）	让大脑"改造"世界——写代码、运行命令	Write, Edit, Bash	大脑决定做什么就做
🗣️ 嘴巴	沟通工具	不确定时向用户提问，获取指导	Question（阻塞式等待回答）	遇到歧义/关键决策时
👶 分身	子 Agent 派遣	派分身去做独立任务，不污染主体记忆	Task（创建独立子 Session）	复杂/耗上下文的子任务
📋 便签	任务追踪	记住计划、追踪进度、防止走偏	TodoWrite / TodoRead	任务 ≥ 3 步时
⚡ 神经	反馈循环（传感器）	自动校验、截断、检测异常	Zod 校验, Truncate, Doom Loop 检测	每次工具调用后
🦴 骨骼	约束系统（引导）	定义"不能做什么"，限制行为边界	AGENTS.md, Permission, Linter	Agent 启动前 + 持续约束
💾 记忆	记忆系统	短期工作记忆 + 跨会话长期知识	Compaction, Summary, Instruction	每轮循环自动管理

回到核心转变：

以前（提示词工程 / 上下文工程）：我们写程序，把输入喂给大脑，得到输出。
    → 就像给罐子里的大脑传纸条

现在（Harness 设计范式）：我们造一个完整的人，给它眼睛、双手、骨骼、神经，
    放在精心设计的工作环境中，让大脑自主决定——想看什么、想做什么。
    → 我们的角色从"喂信息的人"变成了"造人 + 造办公室的建筑师"

直觉总览：用"人造人"理解三次范式跃迁
核心命题：严谨性的三次迁移
第一时代：提示词工程 (2022-2024)
第二时代：上下文工程 (2025)
第三时代：Harness 设计范式 (2026+)
范式转变的本质公式
OpenCode：一个 Harness 范式的实战样本
工具即策略：每个工具解决一个 Harness 问题
Harness 四象限控制模型
行业验证：OpenAI / Stripe / Anthropic
三时代完整对比
我们的启示与行动指南

一、核心命题：严谨性的三次迁移

"Rigor doesn't disappear; it migrates toward feedback and closer to reality."— Chad Fowler, "Relocating Rigor" (2026)

在 AI 工程领域，过去四年发生了三次范式跃迁。每次跃迁都不是对前者的否定，而是包容式升级——新的范式将旧范式作为子模块吸收进来，在更高的抽象层级上解决问题。

核心类比：
年，我们学习如何写一封完美的邮件（提示词工程）。
年，我们学习如何管理整个收件箱（上下文工程）。
年，我们在设计邮件系统本身（Harness 设计范式）。

2022 — 2024

提示词工程 Prompt Engineering

核心问题："我该怎么说？"
聚焦于单次指令的设计——Few-shot、Chain-of-Thought、角色扮演。
控制单元：消息级别 (Message-level)

2025

上下文工程 Context Engineering

核心问题："我该提供什么信息？"
聚焦于上下文窗口中放入什么——RAG检索、记忆系统、工具结果、对话历史。
控制单元：会话级别 (Session-level)

2026+

Harness 设计范式 Harness Engineering

核心问题："我该构建什么系统？"
聚焦于Agent的整个运行环境——工具链、约束规则、反馈循环、生命周期管理。
控制单元：系统级别 (System-level)

关键洞察：每次范式转变都源于前一个范式的失败——
• 提示词工程的天花板：指令写得再好，如果上下文窗口里没有需要的信息，Agent 也无能为力
• 上下文工程的天花板：上下文组装得再完美，如果消费它的循环（loop）设计得不好，Agent 依然会失败
• 严谨性没有消失，只是迁移了——从写提示词，到管理上下文，到设计系统架构

二、第一时代：提示词工程 (2022-2024)

2.1 时代背景

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

2.2 核心技术

💬

Zero-shot / Few-shot

直接提问或提供少量示例，让模型校准行为。无需微调，即开即用。

🧠

Chain-of-Thought (CoT)

"Let's think step by step" — 仅加一句话，GSM8K 数学准确率从 17.9% 跳到 58.1%。

🔄

ReAct 推理+行动

Thought → Action → Observation 循环。模型自主搜索、观察、再推理。Agent 原型诞生。

🎭

角色扮演 + 格式控制

"你是一个资深开发者" + "请以 JSON 格式输出" — 通过人设和格式约束提升输出质量。

2.3 Andrew Ng 的四大 Agent 设计模式 (2024.03)

模式	原理	特点
反思 Reflection	模型审查并修正自己的输出	最稳定、最可预测的模式
工具使用 Tool Use	模型决定何时调用外部工具	区分 Agent 与 Chatbot 的关键
规划 Planning	将复杂任务分解为子任务	最强大但最脆弱
多 Agent 协作	专业化 Agent 各司其职	最具潜力，当时最雏形

关键发现：Andrew Ng 发现："用 Agent 工作流包裹 GPT-3.5，在某些基准上超越了 GPT-4 零样本。" 不换模型，只改变模型周围的模式，就能带来性能飞跃。这是提示词工程的顶峰，也暗示了"模型之外的系统很重要"。

2.4 碰壁：提示词的极限

想象这个场景：一个团队花了3周打磨编码 Agent 的提示词——"复用已有代码"、"写测试"、"不留未使用的导入"。指令越写越长，简单任务一切正常。然后项目规模扩大，问题出现了：

Agent 无视已有的工具函数，从零重写

无论你在提示词里写多少遍"复用已有代码"，如果那个工具文件不在上下文窗口里，Agent 根本不知道它的存在。

死因诊断：这不是提示词问题，是上下文问题。Mitchell Hashimoto 称之为"盲写提示词" (Blind Prompting)——通过试错来写提示词，不做严格测量。更接近炼金术而非软件工程。

三、第二时代：上下文工程 (2025)

3.1 起源：2025年6月的一周

"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

3.2 LLM-as-OS：Karpathy 的操作系统类比

传统操作系统内核 KernelRAM 内存文件系统系统调用进程管理→LLM 操作系统LLM 推理引擎上下文窗口RAG / 向量DBTool Call / API多 Agent 编排

类比解读：提示词只是输入操作系统的一条命令。真正决定性能的是RAM（上下文窗口）里加载了什么。你的 ls 命令写得再精准，如果需要的文件在一个没有挂载的磁盘上，也无济于事。

3.3 上下文工程的四大策略 (Anthropic)

Write — 写入：结构化系统提示词

关键不是"说什么"，而是"如何结构化"。清晰的格式 > 模糊的自然语言。

Select — 选择：只检索相关文档

防止 "Lost-in-the-Middle" 问题——长上下文中间部分的信息会被遗忘。信噪比 > 信息量。

Compress — 压缩：对话历史摘要化

20轮对话后，把前15轮压缩为摘要。Anthropic 报告：好的压缩能保留 80%+ 信息，显著降低 Token 消耗。

Isolate — 隔离：子 Agent 独立上下文

技术问题的诊断交给子 Agent，避免日志分析数据污染主对话上下文。

3.4 碰壁：上下文的极限

单轮局限

大多数上下文工程技术聚焦于"这次 API 调用放什么"。但 Agent 不是单轮的——它做几十个链式决策。如果第15轮需要第3轮已被压缩掉的工具结果呢？

无错误恢复

工具调用失败、模型幻觉、成本飙升……无论上下文组装得多好，处理运行时异常需要独立的机制。

安全问题

如果 Agent 处理外部输入的同时访问敏感数据并可修改状态，一次提示注入就能泄露公司数据。上下文工程解决"放什么进去"，但不解决"防止什么"。

死因：即使完美的上下文，在消费它的系统设计得很差时依然会失败。上下文是必要条件，不是充分条件。

四、第三时代：Harness 设计范式 (2026+)

4.1 起源：2026年2月的"多重发现"

2026年2月，Mitchell Hashimoto（Terraform 创始人）发表"My AI Adoption Journey"，提出了一个简洁有力的原则：

每当 Agent 犯错 → 改变系统，使该错误在结构上不可能再次发生

不是修改提示词，是改变 Agent 周围的系统——规则、工具、约束、反馈循环

两周内，OpenAI、Martin Fowler/Birgitta Böckeler（ThoughtWorks 首席技术顾问）、Ethan Mollick（沃顿商学院教授）各自独立发表了相同的结论。在科学史上，这叫"多重发现"——思想的时代到了。

4.2 核心公式

Agent = Model + Harness

Martin Fowler / Birgitta Böckeler 提出：Harness = "Agent 中除模型以外的一切"

Philipp Schmid 的 OS 类比

模型 = CPU

提供原始计算能力——推理、生成、理解。

"模型是处理器，Harness 是操作系统"

Ethan Mollick 的马具类比

Harness = 马具

将马的力量连接到犁或马车。没有缰绳和鞍具，再强壮的马也耕不了地。

"Harness 把模型的能力转化为有用的工作"

Simon Willison 的定义

Agent = LLM + 工具 + 循环

"Agent 是一个 LLM，在循环中运行工具来达成目标。" 关键词是循环——Harness 就是控制这个循环的系统。

"循环的设计，才是核心竞争力"

4.3 Harness 的五大组成部分

Guides（前馈控制 / 事前引导）

AGENTS.md 文件、.cursorrules、编码规范文档——在 Agent 开始工作之前就塑造其行为。成本接近零，但没有强制执行力。

Sensors（反馈控制 / 事后校验）

编译器、Linter、类型检查器、LLM-as-Judge——在 Agent 执行之后捕获和纠正错误。这是 OpenAI Codex 团队最强调的部分。

Toolchain Management（工具链管理）

Agent 可调用的工具集、API、数据源——包括权限范围、速率限制、参数校验。工具设计决定了 Agent 的能力边界。

Memory & State（记忆与状态系统）

持久化存储 Agent 的决策、任务历史和跨会话上下文。包括对话压缩、长期记忆（AGENTS.md）、Git 历史状态。

Lifecycle Management（生命周期管理）

Agent 的部署、版本控制、回滚、可观测性。权限升级、人在回路(Human-in-the-loop)、安全护栏。

五、范式转变的本质公式

5.1 从"程序 = 输入 → LLM"到"LLM 决策 + 环境"

这是理解三次范式跃迁的核心框架：

提示词工程时代程序 → 输入 → LLM → 输出用户输入→精心设计的提示词→LLM→单次输出上下文工程时代程序 → 上下文组装 → LLM → 输出（带工具调用）RAG检索记忆注入工具结果→LLM→输出 + 工具调用Harness 设计范式时代Harness(环境) + LLM 决策 → 循环执行 → 可靠产出工具集 bash编辑 read/write约束 AGENTS.md权限 Permission记忆 Memory反馈 LoopLLM

本质变化：以前我们写程序，输入 LLM，得到输出。现在我们设计环境（Harness），让 LLM 在这个环境中自主决策和行动。

核心转变：
• 从"我如何写出好的提示词" → "我如何设计好的运行环境"
• 从"程序控制 LLM" → "Harness 约束 LLM 的决策空间"
• 从"一次性输入输出" → "LLM 在环境中循环执行，直到任务完成"

5.2 生产力悖论：约束创造自由

Cursor 团队在"自驾代码库"计划中发现了一个反直觉的真相：约束 Agent 的解空间，反而大幅提升了生产力。

原理：当 GPT-5 或 Claude 4 能生成"任何东西"时，它会浪费大量 Token 探索死胡同和无意义的方案。一个精心设计的 Harness 划定了一条清晰的通向成功的路径——明确的边界、架构规则、有限的高质量工具——迫使 Agent 更快收敛到正确答案。

数据证明：同一个模型、同一份数据、同一个提示词，仅靠改变 Harness 配置，编程基准成功率从 42% 跳到 78%。

六、OpenCode：一个 Harness 范式的实战样本

确认：经过源码分析，OpenCode 项目确实基于 Harness 设计范式构建。它不只是一个"调用 LLM API 的应用"，而是一个完整的 Agent 运行环境——定义了工具集、权限系统、记忆机制、反馈循环和生命周期管理。

6.1 OpenCode 的 Harness 架构全景

OpenCode Harness（Agent 运行环境）① Guides（前馈引导层）System Prompt 系统提示AGENTS.mdAgent 角色定义环境信息注入Skill / Plugin 扩展② Toolchain（工具链层）bash 终端read 读取write 写入edit 编辑grep 搜索glob 匹配task 子任务question 提问todo 任务websearchwebfetchcodesearchls 目录lsp 语言服务③ Permission（权限控制层）allow 允许ask 询问deny 拒绝doom_loop④ Memory（记忆系统层）Compaction 压缩Summary 摘要Prune 裁剪⑤ Sensors（反馈循环层）Zod 参数校验输出截断 TruncateDoom Loop 检测溢出检测 Overflow重试机制 RetrySession Loop（核心执行循环）while(true) { stream → tool_call → execute → feedback → repeat }

6.2 五大 Harness 组件在 OpenCode 中的映射

Harness 组件	OpenCode 实现	核心文件	作用
Guides（引导）	System Prompt + AGENTS.md + Agent 角色定义	`session/system.ts` `agent/agent.ts`	每轮循环前注入系统提示词，按模型类型选择不同 Prompt 模板；AGENTS.md 提供跨会话持久规则
Toolchain（工具链）	20+ 注册工具（bash、read、write、edit、grep、task、question...）	`tool/*.ts` `tool/registry.ts`	每个工具有 Zod Schema 参数校验、权限请求、输出截断。Agent 自主决定调用哪个工具
Permission（权限）	三级权限系统 allow / ask / deny + Doom Loop 检测	`permission/next.ts`	按工具、文件模式、Agent 角色配置权限。.env 文件读取需询问，外部目录需授权
Memory（记忆）	Compaction 压缩 + Summary 摘要 + Prune 裁剪 + Instruction 注入	`session/compaction.ts` `session/summary.ts`	对话过长时自动压缩旧消息为摘要，工具输出自动裁剪，AGENTS.md 跨会话持久
Sensors（反馈）	Zod 校验 + 输出截断 + Doom Loop 检测 + 重试机制	`tool/tool.ts` `session/processor.ts`	工具参数无效时抛出错误让 Agent 重试；连续3次相同调用触发 Doom Loop 告警

6.3 核心循环：Session Processor

OpenCode 的 SessionProcessor 就是 Harness 的"心脏"——控制 Agent 的执行循环：

// packages/opencode/src/session/processor.ts - 简化伪代码while (true) {                          // ← Agent 执行循环let stream = await LLM.stream(input) // ① 调用 LLMfor await (value of stream) {        // ② 处理流式输出switch (value.type) {case "tool-call":            // Agent 决定调用工具// Doom Loop 检测：连续 3 次相同调用 → 请求权限确认if (lastThreeCallsAreSame()) {await Permission.ask("doom_loop")}breakcase "tool-result":          // 工具返回结果// 输出截断：超长输出自动裁剪await Truncate.output(result)break}}// ③ 检查是否需要压缩记忆if (isOverflow(messages)) await Compaction.run()// ④ 检查是否完成（无更多工具调用 → 结束循环）if (noMoreToolCalls) break
}

6.4 Agent 角色系统：多 Agent 协作

OpenCode 内置多个角色化 Agent，每个有不同的工具权限和职责：

🔨

build（默认 Agent）

执行工具、编辑代码、回答问题。拥有 question + plan 权限。是日常开发的主力。

📋

plan（规划 Agent）

只读模式——禁止所有编辑工具，只能规划。只允许编辑 .opencode/plans/ 下的 .md 文件。

🔍

explore（探索 Agent）

快速代码库探索——只有 grep、glob、list、read、bash、websearch 权限。不写只读。

🧹

compaction（压缩 Agent）

隐藏 Agent——当对话过长时被调用，将所有工具权限设为 deny，专注于对话压缩。

 Harness 体现：每个 Agent 不是"一个不同的模型"，而是"同一个模型 + 不同的 Harness 配置"。 
• 不同的工具权限（explore 只能读不能写）
• 不同的 System Prompt（不同角色有不同的行为引导）
• 不同的生命周期（compaction 是隐藏的、按需触发的）

这就是 Harness 范式的核心：模型不变，环境可变。

七、工具即策略：每个工具解决一个 Harness 问题

核心洞察：回到人体隐喻——工具就是 Agent 的眼睛（感知世界）和双手（改造世界）。但每个工具不只是"一个能力"，它背后解决一个特定的 Harness 问题：上下文污染、规划跑偏、安全控制、信息过时……
理解每个工具为什么存在，比知道它怎么用更重要。

7.1 Task（子 Agent）—— 上下文隔离策略

父 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 的任务追踪）。

7.2 Todo（任务追踪）—— 防跑偏策略

先规划，再行动

当任务需要 3 步以上时，Agent 被引导使用 Todo 工具创建结构化任务列表。相当于让 LLM 在动手之前先写"施工方案"。

做完一步，打一个钩

每个任务有 4 种状态：pending → in_progress → completed / cancelled。同一时间只允许一个任务为 in_progress。完成后立即标记，不批量操作。

用户可见的进度追踪

Todo 列表对用户可见——用户能实时看到 Agent 的计划、进度、正在做什么。这是 Human-in-the-loop 的关键机制。

解决的问题：Agent 执行复杂任务时容易"走偏"
没有 Todo 时，LLM 可能在第 5 步忘了第 1 步的目标，或者跳过了关键步骤。
Todo 本质上是 Harness 中的前馈引导 + 反馈校验——计划本身就是引导，每步打钩就是校验。

关键设计：子 Agent 被禁止使用 Todo（task.ts:79-86），因为任务追踪是父 Agent 的职责。这防止了子 Agent 创建自己的任务列表与父 Agent 的计划冲突。

7.3 Question（提问）—— 人在回路策略

Agent 遇到歧义 → 暂停执行 → 向用户提问 → 获得答案后继续

这是一个阻塞式工具——调用时 Agent 执行暂停，通过 SSE 推送问题给前端，等待用户回答后才 resume。支持预设选项和自定义回答。

解决的问题：Agent 不该在关键决策上自作主张
• "使用 React 还是 Vue？" — 实现选择
• "是否删除这个文件？" — 破坏性操作确认
• "这个需求有两种理解，你想要哪种？" — 歧义澄清

Harness 体现：这是安全护栏的核心——Agent 不是无限自主的，在关键分叉点必须寻求人类确认。对应 Stripe 的"Two-Strike"规则：不确定时，问人比猜错好。

7.4 Bash（终端）—— 执行环境策略

安全机制	实现方式	源码位置
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 解析理解命令意图，用权限系统控制执行边界，用超时防止失控。

7.5 Edit（编辑）—— 安全修改策略

精确字符串替换，而非全文重写

强制规则：必须先 Read 文件才能 Edit（防止盲改）。
匹配策略：oldString 必须唯一匹配——如果找到多个匹配，报错要求提供更多上下文。
防误操作：优先编辑已有文件，禁止主动创建新文件（除非明确要求）。

解决的问题：LLM 重写整个文件会引入意外变更
精确替换 > 全文重写。强制先读后改 > 凭记忆改。唯一匹配 > 模糊匹配。这些约束都是 Harness 的"确定性前馈控制"——在结构上阻止 Agent 犯常见错误。

7.6 其他工具：各司其职

📖

Read（读取）

解决的问题：Agent 需要"看到"代码才能操作。带行号输出，支持分页读取大文件。目录列表功能用于项目探索。

✍️

Write（创建文件）

解决的问题：创建新文件。强制规则：覆写已有文件必须先 Read。禁止主动创建文档文件（除非用户明确要求）。

🔍

Grep（内容搜索）

解决的问题：在大型代码库中快速定位包含特定模式的文件。用正则表达式搜索，按修改时间排序返回结果。

📁

Glob（文件匹配）

解决的问题：按文件名模式查找文件（如 **/*.tsx）。与 Grep 互补——一个搜内容，一个搜文件名。

🌐

WebSearch（网络搜索）

解决的问题：突破训练数据截止日期——Agent 需要获取最新的 API 文档、技术资讯。自动注入当前年份避免搜到过旧信息。

📥

WebFetch（网页抓取）

解决的问题：读取特定 URL 的内容。将网页转为 Markdown 注入上下文，让 Agent 能"阅读"文档。

💻

CodeSearch（代码搜索）

解决的问题：搜索框架、SDK、API 的最新代码示例和文档。比 WebSearch 更精准——专门针对编程场景优化。

🔗

LSP（语言服务）

解决的问题：给 Agent "IDE 级"的代码智能——跳转定义、查找引用、悬停提示、调用层级。让 Agent 理解代码结构，而不只是文本搜索。

7.7 两个"效率倍增器"工具

Batch（批量并行）—— 效率策略

解决的问题：串行执行多个独立工具调用太慢。
Batch 允许一次提交最多 25 个工具调用，并行执行。例如同时读取 5 个文件 + 搜索 2 个模式 + 运行 1 个命令。
文档明确说："BATCH TOOL WILL MAKE THE USER HAPPY"——2-5x 效率提升。

Skill（技能加载）—— 懒加载策略

解决的问题：预加载所有技能说明会浪费上下文 Token。
Skill 工具在工具列表中只显示名称和一句话描述（稳定前缀，不破坏 KV-cache）。当 Agent 判断需要某个技能时，再按需加载完整的指令、脚本、参考资料到上下文末尾（可变后缀）。
这正是 Google ADK 提出的 Stable Prefix / Variable Suffix 模式的实践。

7.8 Plan（规划模式）—— 读写分离策略

Plan Agent（只读规划）↔ Build Agent（读写执行）

解决的问题：如果让同一个 Agent 既规划又执行，它容易在规划阶段就"手痒"开始改代码。
Plan 模式通过权限系统强制分离：Plan Agent 的所有编辑工具设为 deny，只能读写 .opencode/plans/*.md 文件。规划完成后，通过 plan_exit 工具征求用户确认，切换到 Build Agent 执行。
这是 Harness 中角色化隔离的经典实践。

7.9 Truncation（输出截断）—— 上下文保护策略

解决的问题：工具输出过长会撑爆上下文窗口
当 bash 命令输出了 10 万行日志，直接注入上下文会导致后续交互质量急剧下降。

策略：
• 硬限制：最多 2000 行 或 50KB（先到先截）
• 完整输出保存到文件（7 天后自动清理）
• 如果 Agent 有 Task 工具，提示它委派子 Agent 去处理截断文件——再次利用上下文隔离！
• 如果没有 Task 工具，提示用 Grep 搜索或 Read 分段读取

这个设计把"截断"和"子 Agent"两个策略串联起来，形成完整的防护链。

7.10 工具总览：问题→策略→工具映射

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

八、Harness 四象限控制模型

Fowler/Böckeler 将 Harness 的控制机制整理为清晰的 2×2 框架。这个模型帮助我们理解，Harness 如何在 Agent 执行的不同阶段施加影响：

🔵 确定性 × 前馈（Guides 引导）

在 Agent 开始之前，通过确定性规则引导方向。

AGENTS.md 编码规范
.cursorrules 项目规则
OpenCode Agent 角色定义

成本接近零，但无强制力——Agent 可以忽略。

🟢 确定性 × 反馈（Computational 计算校验）

在 Agent 执行之后，通过机械手段捕获错误。

编译器错误、Linter 告警
OpenCode Zod Schema 参数校验
OpenCode 输出截断 (Truncate)
Doom Loop 检测

OpenAI Codex 团队最强调的象限——用 Linter 替代人类审查者。

🟡 非确定性 × 前馈（System Prompts 指令）

处理确定性规则无法覆盖的细微场景。

"对用户保持礼貌"
"不确定时请求确认"
OpenCode 按模型类型选择不同 Prompt
Few-shot 示例

更像指南而非规则，但比 Guides 更具体。

🟣 非确定性 × 反馈（Inferential 推理校验）

捕获"能编译但语义错误"的问题。

另一个 LLM 审查代码
Anthropic 的 Evaluator Agent
Playwright E2E 测试验证
语义级代码审查

成本最高，但能捕获最深层的问题。

OpenCode 的四象限覆盖：
• 引导：AGENTS.md + System Prompt + Agent 角色配置（按模型类型选择 Prompt 模板）
• 计算校验：Zod 参数校验（工具参数无效时抛错）+ 输出截断 + Doom Loop 检测
• 指令：System Prompt 中的行为约束（如 "prefer functional array methods"）
• 推理校验：Agent 可以看到工具输出（如 bash 报错），形成自我修正循环

九、行业验证：头部公司的 Harness 实践

9.1 OpenAI Codex 实验

数据：5个月 | 7名工程师 | 0 行手写代码 | ~100 万行生成代码 | ~1500 个 PR | 速度约为手写的 10 倍

七名工程师五个月没写一行代码。他们在做什么？

系统化仓库知识

Agent 反复犯同样的错——因为架构决策在 Slack 里讨论的，设计原则只在资深开发脑子里。"对 Agent 不可见的知识，等于不存在。" 所以他们把每条原则都文档化为 Markdown 写入仓库。

机械化执行约束

光写文档不够——"请使用这种模式"会被忽略。他们构建了自定义 Linter 和结构化测试来强制执行架构规则。Agent 自动修复代码以通过 Linter。

渐进式信息披露

最初尝试一次性注入大量文档——Agent 迷失了。"给 Codex 一张地图，而不是一本 1000 页的手册。"

"Agents aren't hard; the Harness is hard."— Ryan Lopopolo, OpenAI Codex Team Lead

9.2 Stripe Minions 系统

维度	实现
规模	每周自动合并 1,300+ PR，无需人类监督
Blueprint 编排	将工作流分为确定性节点（运行 Linter、推送 Commit）和Agent 节点（实现功能、修复 CI）
Two-Strike 规则	如果 Agent 第一次修复 CI 失败，第二次也失败，立即升级给人类。不允许 Agent 在无限重试循环中浪费资源

9.3 Anthropic 三 Agent 架构

Anthropic 发现了一个根本性缺陷：Agent 无法准确评估自己的工作。就像一个学生不应该批改自己的试卷。

🗺️ Planner

将简短的需求描述扩展为详细的产品规格。关注雄心勃勃的范围和高层设计，不涉及技术细节。

"过于具体的技术指令会导致级联错误"

⚙️ Generator

每次实现一个功能。每个 Sprint 后自评，然后交给 QA。通过 Sprint 机制定期重置上下文。

"分而治之，逐个击破"

🔍 Evaluator

用 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 仍然需要好的上下文，好的上下文仍然需要好的提示词
• "提示词工程已死"的说法是错误的——它没有死，只是被吸收为更大系统的子模块

十一、我们的启示与行动指南

11.1 核心思维转变

旧思维

我如何写好提示词？

关注措辞和格式
每次手动调优
出了问题加更多指令
把 Agent 当黑盒

过渡思维

我该提供什么上下文？

关注检索和信息架构
优化 RAG 管线
管理 Token 预算
区分短期/长期记忆

新思维

我该设计什么环境？

关注系统架构和反馈循环
约束用 Linter 而非提示词执行
Agent 犯错 → 改进 Harness
模型可替换，Harness 是资产

11.2 实践原则

"Agent 犯错时，不要怪 Agent——改进 Harness"

每次发现 Agent 犯了一个错误，就花时间构建一个解决方案，使它在结构上不可能再犯同样的错。这是 Mitchell Hashimoto 的核心原则。

"约束用 Linter 执行，不用提示词请求"

"请使用这种模式"写在文档里会被忽略。用 Linter 强制执行，Agent 就会自动修复代码以通过检查。

"给 Agent 一张地图，而不是一本 1000 页的手册"

渐进式信息披露——Agent 需要时再加载详细信息。一次性注入太多文档会让 Agent 迷失。

"Harness 应该可拆卸"

随着模型进步，Harness 中的一些"聪明"逻辑会变得不再必要。好的 Harness 设计在于"构建什么"和"什么容易移除"同样重要。

"对 Agent 不可见的知识等于不存在"

架构决策在 Slack 讨论的、设计原则只在资深开发脑子里的——这些 Agent 都看不到。把每条原则文档化到仓库中。

11.3 我们可以做什么

📝

完善 AGENTS.md

把团队的编码规范、架构决策、项目约定写入 AGENTS.md，让 Agent 在每次会话开始时自动加载。

🔧

构建自定义工具

基于 OpenCode 的工具注册机制，为团队特有场景构建专属工具（数据库查询、内部 API 调用等）。

🛡️

强化 Linter 约束

把架构约束转化为 Linter 规则，而非依赖提示词。Agent 写完代码后自动检查，不通过则自动修复。

📊

建立反馈循环

记录 Agent 犯过的错误，每次犯错后更新 Harness 配置。让 Harness 越来越健壮。

最终总结：

提示词工程时代，我们是写作者——精心雕琢每一条指令。
上下文工程时代，我们是图书管理员——组织和检索正确的信息。
Harness 设计范式时代，我们是建筑师——设计 Agent 生活和工作的整个环境。

严谨性从未消失。它只是迁移了——从写代码，到管理上下文，到设计系统。
我们的工作不是变少了，而是升维了。

参考资料

Mitchell Hashimoto, "My AI Adoption Journey", 2026.02
Andrej Karpathy, "Context Engineering" (X post), 2025.06.25
Tobi Lütke, "Context Engineering" (X post), 2025.06.19
Martin Fowler / Birgitta Böckeler, "Harness Engineering for Coding Agent Users", 2026.02
OpenAI, "Harness Engineering: Leveraging Codex in an Agent-First World", 2026.02
Anthropic, "Building Effective Agents", 2024.12
Anthropic, "Effective Context Engineering for AI Agents", 2025.09
Anthropic, "Harness Design for Long-Running Application Development", 2026.03
Chad Fowler, "Relocating Rigor", 2026.01
Simon Willison, "Agentic Engineering Patterns", 2026.02
Philipp Schmid, "The Importance of Agent Harness in 2026", 2026.01
Epsilla, "The Third Evolution: From Prompt to Context to Harness Engineering", 2026
Atlan, "Harness Engineering vs Prompt Engineering", 2026
bits-bytes-nn, "From Prompts to Harnesses — Four Years of AI Agentic Patterns", 2026.04
Andrew Ng, "4 Agentic Design Patterns" (Sequoia AI Ascent), 2024.03