大模型实战指南（5）——从 Prompt 到 Harness：Agent 时代的工程范式跃迁

大模型实战指南（5）------从 Prompt 到 Harness：Agent 时代的工程范式跃迁

2023 年，"提示词工程师"年薪 33.5 万美元，Anthropic 的招聘启事不要求计算机专业学位，只要求"会跟 AI 对话"。三年后，这个岗位从大厂招聘系统里彻底消失。不是 AI 变聪明了自己写 Prompt 了，而是所有人发现------Agent 出不出错，根本不取决于你 Prompt 写得好不好，而取决于你给它搭的那套"缰绳"够不够牢。

---

写在前面

这是《大模型实战指南》系列第五篇。前四篇我们聊了 Token、上下文窗口、温度采样、Embedding 向量检索，都在拆解大模型本身的"内部零件"。从这一篇开始，视角变了------我们不再盯着模型本身，而是看如何在模型外面搭一套系统，让它真正稳定干活。

如果你用过 Claude Code、Cursor、Codex 这些 AI 编程工具，大概率经历过这种崩溃：

• 让 AI 改一个按钮颜色，它把整个页面布局重写了
• 明明说了"单文件不超过 200 行"，几轮对话后 AI 写了个 1000 行的巨无霸
• 让 AI 修一个 Bug，结果修出了三个新 Bug
• 跑了一晚上 Agent，第二天发现它在一个循环里打了 6 小时转

大多数人的第一反应是：换个更强的模型。但 2026 年的数据告诉你，这是一个方向性错误。

---

一、Prompt 工程师之死：一个 33.5 万美元岗位的三年生命周期

1.1 那些曾经刷屏的"咒语"

你一定见过这些":

• "Let's think step by step"------2022 年刷屏的 Chain-of-Thought 提示，据说能让 GPT-4 数学成绩翻倍
• "你是一位拥有 20 年经验的高级架构师"------角色扮演提示，朋友圈教程标配
• "请仔细检查你的答案"------Self-Consistency 自我检查
• "按照以下格式输出：1. xxx 2. xxx"------结构化提示

2023 年，这些技巧真的有用。那时候模型还不太聪明，你多写几句引导词，输出质量确实肉眼可见地提升。Prompt 工程师这个岗位应运而生------Anthropic 开出 33.5 万美元年薪（约合人民币 230 万元）招募提示词工程师，不要求计算机专业学位，职责就一句话：写 Prompt。

1.2 为什么这些技巧不灵了

三个原因：

第一，推理模型把思维链内置了。

2024 年 9 月 OpenAI 发布 o1，2025 年 DeepSeek-R1 开源。这些推理模型（Reasoning Model）在内部自己展开了思维链------你在 Prompt 里写"Let's think step by step"纯属画蛇添足，它本来就会自己想。

就像你已经给一辆车装了 GPS 导航，这时候还在车顶上贴一张纸质地图，觉得自己"帮了导航系统一个大忙"。

第二，角色的重要性下降了。

打一个比方：你去医院看病，专家门诊的主治医师不需要你提前跟他说"你是一位拥有 20 年临床经验的主任医师"------他本来就是。同理，2026 年的模型已经足够聪明，你给它一个任务，它自己知道该用什么身份、什么策略去完成。角色扮演提示从"锦上添花"变成了"多此一举"。

第三，结构化输出标准化了。

OpenAI、Anthropic、DeepSeek 都提供了 Structured Output / JSON Mode，你在 API 参数里指定 response_format，模型直接按 JSON Schema 输出。再也不用在 Prompt 里用自然语言描述格式。

1.3 智源研究院的判词

2026 年 3 月 14 日，智源研究院（BAAI）在技术大会上公开表态：

"Prompt Engineering 过时了，Context Engineering 也过时了，现在是 Harness Engineering 的时代。"

这不是一家之言。腾讯云、阿里云、ThoughtWorks、Hugging Face 的 Philipp Schmid 都在 2026 年发出了类似判断。Philipp Schmid 直接把 Harness Engineering 称为"2026 年最重要的工程学科"。

那个年薪 33.5 万美元的"提示词工程师"岗位，2026 年已经从大厂招聘系统彻底消失。它的职责被拆解重组：一部分进了"AI 应用优化师"------负责调 API 参数和搭工具链；一部分进了"AI 产品经理"------负责定义 Agent 的业务流程和验收标准。但没有一个岗位叫"写 Prompt"了。

从 Prompt 到 Harness，到底跳了多远？我们用一个四阶段模型来看清这条轨迹。

---

二、四级跃迁：从 Prompt 到 Loop，到底跃迁了什么

AI 工程的范式在四年里跳了四个台阶。不是为了造概念，而是每一级解决的是越来越底层的问题。

2.1 第一级：Prompt Engineering（2022-2024）------关注"怎么说"

核心问题：怎么把任务描述清楚，让模型理解你的意图？

代表技术：Zero-shot / Few-shot / Chain-of-Thought / Self-Consistency / ReAct

你的角色：翻译官------把人类意图翻译成模型能理解的文字指令

典型操作：精心设计系统提示词、加 few-shot 示例、写思维链引导

打比方：你雇了一个刚毕业的实习生，你得把每一步要干什么用文字说清楚------"先做 A 再做 B，如果遇到 C 就怎么办"。你说得好不好，直接决定他活干得好不好。

2.2 第二级：Context Engineering（2024-2025）------关注"看到什么"

核心问题：不在于你说得对不对，而在于模型在干活时能看到什么信息？

2025 年中，Tobi Lütke（Shopify CEO）和 Andrej Karpathy 相继为 Context Engineering 背书后迅速成为 Agent 栈显学。

代表技术：RAG、分段上下文管理、上下文窗口压缩、分层记忆

你的角色：资料员------在模型开始干活前，把相关资料整理好放进它的"工作台"

打比方：实习生已经很聪明了，你不用再教他怎么干活。但他的桌子太小（上下文窗口有限），你得帮他把这任务相关的文件挑出来、编号排好，让他需要哪份就翻哪份。

为什么从 Prompt 跳到 Context：因为大家发现，模型出错的根因不是"你描述不够好"，而是"它手边没有正确的参考资料"。把"怎么说"的精力转移到"给什么"上，效果提升更明显。

2.3 第三级：Harness Engineering（2026.2）------关注"运行在什么系统里"

核心问题：不在于模型聪明不聪明，也不在于它看到什么，而在于它跑在一个什么样的系统环境里？

代表技术：AGENTS.md / CLAUDE.md、JSON 特性追踪器、结构化任务模板（影响图）、Sprint 契约、三 Agent 架构（规划器/生成器/评估器）

你的角色：系统设计师------给模型搭一套"脚手架"，让它在该停的地方停、该查的地方查、该重试的地方重试

打比方：实习生已经聪明了，资料也备齐了，但你总不能把他扔到一家没有流程、没有质检、没有版本管理的公司里。Harness 就是那套"公司制度"------项目规范文档（AGENTS.md）、进度看板（progress.json）、质检流程（CI/CD）、审核制度（评估器 Agent）。

为什么从 Context 跳到 Harness：因为光给资料不够，你还需要一套系统在模型跑偏时把它拉回来、在它犯错时自动检测到、在它需要重试时给它清晰的反馈。

2.4 第四级：Loop Engineering（2026.6）------关注"让循环自己跑起来"

核心问题：不在于单次任务做好，而在于怎么设计一个循环系统让 Agent 自己发现任务、自己执行、自己验证、自己迭代？

2026 年 6 月，Google Cloud AI 总监 Addy Osmani 在博客上发布长文《The Architecture of a Long-Running Agent》，正式命名 Loop Engineering。同月，Anthropic Claude Code 负责人 Boris Cherny 公开说"我不再给 Claude 写提示词了，我的工作就是写循环"；OpenClaw 创始人 Peter Steinberger 在 X 上发帖"你不应该再提示编码 Agent，而应该设计那些提示 Agent 的 Loop"，浏览量超 800 万。

你的角色：循环设计师------设计一套自动发现工作、分派任务、执行验证、不断迭代的闭环系统，让它自己跑

打比方：你不再管一个实习生，你开了一家"无人值守工厂"------不需要你逐个分配任务，流水线自己找活干、自己质检、自己调整，你只在关键节点审批。

为什么从 Harness 跳到 Loop：Harness 解决的是"单次任务怎么可靠"，Loop 解决的是"怎么让任务自己循环跑起来"。当 Harness 成熟后，自然有人想把它装进一个无人值守的循环里。

2.5 四级不是竞争，是分层

这里最容易产生一个误解：以为每一级是"取代"上一级。不是的。

层级	解决的问题	典型问题	比喻
Prompt	怎么表达任务	你说得太模糊模型猜不到	实习生的任务说明
Context	模型看到什么	模型手边缺少参考资料	实习生的工作台
Harness	模型跑在什么系统里	模型跑偏了没人拦、错了没人查	公司制度与质检流程
Loop	怎么让任务自己跑起来	你不想逐个分配任务	无人值守工厂

今天你同时需要四级 。写一段 Chain-of-Thought 提示仍然有用（Prompt 层），RAG 检索仍然有用（Context 层），AGENTS.md 和反馈回路仍然有用（Harness 层），而如果你的场景需要自动化批量执行，那还需要设计 Loop。只不过重心在移动------2026 年的重心从 Prompt 和 Context 移向了 Harness 和 Loop。

用一句话说清：Prompt 研究的是"怎么说"，Context 研究的是"给什么看"，Harness 研究的是"在什么系统里跑"，Loop 研究的是"怎么让循环自己转"。

---

三、Harness 到底是什么：模型是大脑，Harness 是手脚

3.1 一行公式

ThoughtWorks 工程师 Sunit Parekh 给了一个最简洁的定义：

Agent = Model + Harness

Model 是大模型本身------负责推理、理解、生成。

Harness 是除了模型之外的一切------约束 Agent 不跑偏的规则、捕捉错误的反馈回路、告诉 Agent 当前处境的文档、它被允许使用的工具、它的权限边界。

去掉 Harness，模型就是在代码库里瞎猜的裸 AI。配上合适的 Harness，它就是一个能上线生产代码的系统。

3.2 马具的隐喻

这个名字来自英文"Harness"，原意是马具------缰绳、马鞍、嚼口。

一匹马强壮但不可预测。没有缰绳和嚼口，它想去哪就去哪，骑手根本管不住。骑手的工作不是让马变得更聪明，而是通过装备设计让马的力量变得可控。

AI Agent 也是一样。模型能力很强，但没有合适的 Harness，它会按自己的理解随意修改文件、在同一个地方反复犯错、上下文窗口耗尽后无声丢弃需求、产出的代码本地能跑上线就炸。

Harness Engineering 的目标，就是成为那套"缰绳+鞍+嚼口"。

3.3 操作系统类比：最精准的技术比喻

Hugging Face 的 Philipp Schmid 给出了一个更技术性的类比，值得你好好琢磨：

传统系统	AI Agent 系统
CPU（原始算力）	Model（原始推理能力）
内存（有限的、易失的工作记忆）	上下文窗口（有限的、易失的工作区）
操作系统（管理 CPU 看什么、什么时候看到）	Harness（管理模型的行为边界）
运行在上面的应用	Agent（最终交付产物的载体）

模型很强大，但没有操作系统来管理内存、调度任务、执行规则，它就只是一块硅片。大多数人在用 Agent 时，实际上缺少的正是这样一个"操作系统层"------这也是为什么很多 Agent 在生产环境里不稳定的原因。

3.4 控制框架视角

如果你有金融或风控背景，还有一个更直接的理解方式：Harness 就是控制框架。就是那套确保自主系统在可接受边界内运行的策略、检查点和审计链。合规团队做这件事做了几十年，现在 AI 世界给它起了个新名字。

---

四、五条共识原则：三家团队殊途同归

三个团队从完全不同的起点出发，撞上了同一堵墙------OpenAI 在造产品、Anthropic 在搭架构、ThoughtWorks 在看 50 多个客户团队重复踩坑。他们从未协调过，但独立得出了完全相同的五条原则。这种独立收敛通常意味着发现了真实存在的东西。

原则一：上下文胜过指令

让 Agent 看到 世界的当前状态，效果始终优于抽象地告诉它该做什么。

标签不同，发现一样。OpenAI 总结为"给一张地图，而不是一本手册"。Anthropic 构建了 JSON 功能列表和进度文件让 Agent 随时知道自己在哪。Red Hat 的整个工作流建立在分析真实代码库之后才生成任务的基础上。ThoughtWorks 称之为"前馈"。

# 错误做法：抽象指令
prompt = "在这个项目里，User 结构体在 models/user.go，\
          积分服务在 services/loyalty.go，请遵循现有模式"

# 正确做法：给真实文件路径和真实符号名
context = {
    "real_file_paths": ["models/user.go", "services/loyalty.go"],
    "real_symbols": ["User.Level()", "LoyaltyService.AddPoints()"],
    "existing_patterns": ["errors.Wrap(err, 'context')"],
    "acceptance_criteria": [
        "AddPoints(100) 后 User.Points = 100",
        "Level 变更触发 user.level_changed 事件"
    ]
}

基于真实文件路径工作，产出的代码自然融入代码库。基于模糊描述工作，结果就是臆造的文件路径和编造的 API。

原则二：规划和执行必须分开

让 Agent 在同一个过程里既规划又执行，产出不可靠。

OpenAI 把环境设计（人类负责）和代码生成（Agent 负责）分开。Anthropic 在 Generator 碰任何代码之前先跑专属的 Planner Agent。ThoughtWorks 规定在规划和实现之间要有人工审查检查点。Red Hat 分为阶段 1（影响图分析）和阶段 2（实现），中间有硬性关卡。

# ❌ 错误：边想边干
result = model("实现一个用户积分系统，先规划再实现")

# ✅ 正确：规划先独立完成、审查通过后再实现
plan = planner_agent("规划用户积分系统的实现方案")
review_result = human_or_evaluator_review(plan)
if review_result["approved"]:
    code = generator_agent(plan)  # 基于已审查的计划写代码

规划步骤不必由人类或独立 Agent 完成，但它必须是一个独立的步骤，其输出在实现开始之前需要经过审查。

原则三：反馈回路不可商量

没有反馈机制的 Harness，不过是加了多余步骤的提示词。

OpenAI 把 Agent 接入 CI/CD 管道和可观测性系统。Anthropic 构建专用 Evaluator Agent 用 Playwright 浏览器自动化像真实用户一样与运行中的应用交互。ThoughtWorks 把这正式化为"传感器"，并警告说仅有前馈的方法（有指导但无验证）永远无法确认指导是否真的有效。

# 一个最小反馈回路
def run_with_feedback(task, max_retries=3):
    for attempt in range(max_retries):
        result = agent.execute(task)
        # 反馈：跑测试套件
        test_result = run_tests()
        if test_result["passed"]:
            return result  # 通过，提交
        # 把测试失败信息喂回去让 Agent 改
        task = f"上次结果：{result}\n测试失败：{test_result['errors']}\n请修复"
    return None  # 重试 3 次仍未通过，人工介入

三种方案，同一条原则：先计算型反馈（快、便宜、确定性），再推断型反馈（慢、贵、语义级），两者缺一不可。

原则四：一次只做一件事

Agent 试图同时做太多事情，就会耗尽上下文、失去连贯性，或悄悄丢掉需求。

OpenAI 把目标拆成更小的构建块，深度优先推进。Anthropic 强制每次 Sprint 只实现一个功能，实现后即提交。ThoughtWorks 描述了分阶段生命周期：预集成、后集成、持续监控。

Anthropic 的会话初始化流程是最清晰的表达：

读取进度 → 选一个功能 → 实现 → 验证 → 提交 → 循环

强制增量主义------Agent 完成一个工作单元后再开始下一个------在每个成功的 Harness 实现中都是普遍原则。

原则五：代码库本身就是文档

没有人为 Agent 维护独立的知识库。仓库就是唯一事实来源。如果一个规范、约束或架构决策不在代码库里，Agent 就不知道它的存在。

OpenAI 在仓库中嵌入 AGENTS.md 文件。Anthropic 将功能列表、进度文件和 git 历史作为 Agent 的连续性机制。ThoughtWorks 衡量"harnessability"------即代码库本身对 Agent 的可读程度。Red Hat 说把所有规范都纳入版本控制。

# AGENT.md - 项目AI助手指南

## 技术栈
- 后端：Go 1.24 + GORM
- 前端：React 18 + TypeScript 5
- 数据库：PostgreSQL 17

## 硬规则
- 单文件不超过 200 行
- 禁止删除文件（只允许归档到 archived/ 目录）
- 所有数据库操作必须在事务中
- 提交前必须运行 make lint && make test

这里有个关键细节：ETH Zurich 对 138 个仓库的研究发现，AGENTS.md 保持在 60 行以内 效果最好。超过这个长度，Agent 开始忽略它。而且人类写的 AGENTS.md 比 AI 生成的效果好------研究发现 AI 生成的 AGENTS.md 实际上会降低性能，且多消耗 20% 的 token。

---

五、三个真实实验：数据告诉你 Harness 有多值钱

理论说再多不如数据。三个实验，三个视角，全来自权威机构官方报告。

5.1 OpenAI 百万行代码实验：88 个 AGENTS.md

时间：2026 年 2 月，OpenAI 工程师 Ryan Lopopolo 带队

背景：构建 Sora Android 应用，团队规模有限，需要快速交付

做法：不是雇更多人或换更强模型，而是设计了一套严格的 Harness

维度	数字
团队规模	4 名工程师
开发周期	28 天
消耗 Token	约 50 亿
代码总量	约 100 万行
人工编写比例	0%
人工 Review 比例	0%
合并 PR 数	1500 个
人均每天 PR	3.5 个
Codex 每周处理内部 PR	70%
崩溃率	低于 0.1%
Play Store 排名	第一
用的模型	公开的 Codex，无秘密模型

他们最核心的教训，是用血和汗换来的：给 Codex 一张地图，而不是一本 1000 页的使用手册。

怎么做到的？

1. 严格的依赖流规则：Types → Config → Repo → Service → Runtime → UI，每层只能依赖下层，用结构测试强制执行，违反则 CI 失败
2. 分布式 AGENTS.md 文件：在整个代码库各角落嵌入 88 个 AI 引导文档，每个主要模块一个，随项目演进不断更新
3. Agent 直连 CI/CD：每次提交自动触发完整测试流水线
4. JSON 特性追踪器：跨会话记录每个特性的完成状态，200 多个独立功能全部从 "failing" 开始

核心理念：设计好环境，然后放 Agent 进去。人的角色是架构师，不是程序员。

5.2 LangChain 控制实验：同一模型，53% → 67%

时间：2026 年 3 月，LangChain 发表《The Anatomy of an Agent Harness》

这是最能说明 Harness 价值的实验，因为只改了一个变量。

维度	旧 Harness	新 Harness
模型	GPT-5.2-Codex	GPT-5.2-Codex（完全不变）
Terminal Bench 2.0 得分	52.8%	66.5%
排名	Top 30 以外	Top 5

+13.7 个百分点，排名从 30 名外杀进前 5。模型一个参数都没动。

改了哪些 Harness 组件？

• 上下文文件（结构化注入真实文件路径、符号名、已有模式，替代模糊描述）
• 结构化输出约束（JSON Schema 强制校验，替代自然语言格式描述）
• 自验证闭环（每步操作后自动跑测试，失败则反馈错误信息让 Agent 修复）
• 工具优化（精简工具集，砍掉冗余选项，减少"选择瘫痪"）

有一个更极端的数据点：部分子任务从 42% → 78%，几乎翻倍。

5.3 Vercel 减法实验：砍掉 80% 工具反而更好

Vercel 走了另一个方向------他们砍掉了 Agent 80% 的工具。

结果性能反而更好了。

为什么？工具越多，Agent 越容易陷入"工具选择瘫痪"：它花在判断"用哪个工具"上的 token 和时间，比实际干活还多。砍掉冗余工具后，决策路径变短，每个工具的使用频率提升，Agent 的行为更可预测。

这与 OpenAI 的"给地图而非手册"原则遥相呼应------约束不是限制，而是把模型的有效注意力集中到正确的地方。

5.4 一个对比表：三家流派，三种路线

维度	OpenAI / Codex	Anthropic / Claude Code	ThoughtWorks
核心哲学	环境优先	执行与评审分离	分类与系统化
核心机制	依赖流 + AGENTS.md + CI/CD	三 Agent 架构（规划器/生成器/评估器）	2×2 控制矩阵（前馈×反馈 / 计算型×推断型）
擅长	大型长期维护的代码库	质量要求极高的应用	已有成熟代码库的团队
代表数据	100 万行 / 0% 手写	完整 200 美元 / 残缺 9 美元	50+ 客户团队经验提炼
你的角色	架构师	设计审判系统的人	系统分类师

---

六、代码实战：25 行写一个最小 Harness

理论看够了，上手写一个。我们用纯 Python 手搓一个最小可用 Harness，不依赖任何框架。它具备 Harness 的五个核心能力：工具调用、反馈回路、重试机制、状态追踪、权限控制。

import json, subprocess

# ① 工具注册表------Harness 的"工具系统"
TOOLS = {
    "read_file":   {"run": lambda path: open(path).read(), "safe": True},
    "write_file":  {"run": lambda path, content: open(path, "w").write(content), "safe": False},
    "run_command": {"run": lambda cmd: subprocess.run(cmd, shell=True,
                     capture_output=True, text=True).stdout, "safe": False},
}

# ② 权限控制------Harness 的"安全边界"
BLOCKED = ["rm -rf", "DROP TABLE", "git push --force", "format"]

def check_permission(action):
    """危险操作拦截------Harness 的权限层"""
    for blocked in BLOCKED:
        if blocked in action:
            raise PermissionError(f"危险操作被 Harness 拦截: {blocked}")
    return True

# ③ 反馈回路------Harness 的"质检系统"
def verify(result, criteria):
    """验证 Agent 输出是否符合验收标准"""
    if not result or "error" in str(result).lower():
        return False, "输出包含错误"
    if criteria and criteria not in str(result):
        return False, f"输出缺少验收标准: {criteria}"
    return True, "验证通过"

# ④ 核心 Harness 循环
def harness_loop(task, model_fn, max_retries=3):
    """
    最小 Harness 主循环：
    task = 用户任务描述
    model_fn = 你接入的任意大模型 API（返回 JSON：{"tool": "..., "args": [...], "done": bool}）
    max_retries = 失败重试上限
    """
    context = task  # 当前上下文
    for step in range(max_retries):
        # 调用模型------模型只负责"想"，Harness 负责"做"和"查"
        decision = json.loads(model_fn(context))

        tool_name = decision["tool"]
        tool_args = decision["args"]

        # 权限检查
        if tool_name == "run_command":
            check_permission(tool_args[0])

        # 工具执行------Harness 接管执行权
        tool = TOOLS[tool_name]
        result = tool["run"](*tool_args)

        # 反馈验证
        ok, msg = verify(result, decision.get("criteria", ""))

        if ok:
            if decision.get("done"):
                return result  # 任务完成，退出
            context = f"上一步成功：{result}\n请继续下一步。"
        else:
            # 失败重试------把错误反馈给模型让它自己改
            context = f"上一步失败：{msg}\n结果：{result}\n请换个方案重试。"

    return "达到最大重试次数，需要人工介入"

# ⑤ 模拟一个模型调用（实际使用时换成你的 API）
def mock_model(context):
    """模拟模型返回 JSON 决策------真实场景接入 OpenAI / DeepSeek / Claude API"""
    if "读取" in context or "第一步" in context:
        return json.dumps({"tool": "read_file", "args": ["test.py"],
                           "criteria": "def", "done": False})
    return json.dumps({"tool": "write_file", "args": ["out.txt", "done"],
                       "criteria": "done", "done": True})

# 运行
if __name__ == "__main__":
    result = harness_loop("第一步：读取 test.py 文件内容；第二步：把结果写入 out.txt",
                          mock_model)
    print(result)

运行这段代码，你会看到 Harness 的完整工作流程：模型决策 → 权限检查 → 工具执行 → 结果验证 → 成功则继续/失败则反馈重试。

这 25 行代码涵盖了 Harness 的五个核心构件：

1. 工具系统 （TOOLS）：模型只能用注册过的工具，不能直接操作系统
2. 权限控制 （check_permission + BLOCKED）：危险操作被拦截
3. 反馈回路 （verify）：每步输出都经过验收标准检查
4. 重试机制 （harness_loop 的 for 循环）：失败时把错误反馈回去让模型自己改
5. 状态追踪 （context 变量）：每步结果都沉淀进上下文，模型知道之前发生了什么

关键洞察：注意一个设计细节------模型只负责"想"（输出 JSON 决策），Harness 负责"做"（执行工具）和"查"（验证结果）。这种"想做分离"正是 Harness 的核心哲学。

---

七、三个真坑：每个坑都让 Agent 在凌晨三点炸过

坑一：Agent 跑到第 30 步崩了------上下文溢出

场景：你写了个自动化 Agent 跑报销审核流程，12 步工具调用 + 3 次人工复核。前 35 分钟一切正常。第 36 分钟，系统突然把"阿司匹林肠溶片"识别成"阿莫西林胶囊"，而且拒绝承认自己错了。

根因：上下文窗口满了。模型自动丢弃了第 1 步 OCR 的原始图像哈希值和第 4 步的拒付案例匹配依据------它不是报错，而是用残缺记忆编造答案。

这是真实案例，出自某省级医保局智能报销审核 Agent 项目。更致命的是，没有 event log，无法回放 session：不知道是哪一步的 tool call 返回了异常数据，最终只能让业务方重跑整条链路，耗时 47 分钟------而 SLA 要求 15 分钟内响应。

解法：用 Session-as-Event-Log 模式。把每一步操作（timestamp、tool name、input hash、output hash、execution duration、error code）写入独立的持久化存储，与模型上下文完全解耦。Harness 只负责按 event log 的顺序调用工具，模型只负责理解当前 step 的输入和生成下一步指令。

import json, time

# 每一步操作都记录到 event log，与模型上下文解耦
def execute_with_log(tool_name, tool_input, event_log_path="events.jsonl"):
    event = {
        "timestamp": time.time(),
        "tool": tool_name,
        "input_hash": hash(str(tool_input)),
        "status": "running"
    }
    with open(event_log_path, "a") as f:
        f.write(json.dumps(event) + "\n")

    try:
        result = TOOLS[tool_name]["run"](*tool_input)
        event["output_hash"] = hash(str(result))
        event["status"] = "success"
    except Exception as e:
        result = None
        event["error"] = str(e)
        event["status"] = "failed"

    # 更新 event log
    with open(event_log_path, "a") as f:
        f.write(json.dumps(event) + "\n")

    return result  # 只把精简结果传给模型，不传全部历史

# 这样即使跑到第 50 步，模型也只看到当前 step 的上下文
# 完整历史在 event log 里，随时可以回放和审计

经验：Agent 不是"上下文越多越好"。上下文窗口溢出后，模型会静默丢失早期信息并编造答案------这比报错危险 100 倍，因为你看不出来它错了。

坑二：成本爆炸------Agent 自己给自己发工资

场景：你给团队铺开 Claude Code 后，四个月烧穿了全年 AI 预算。采用率从 2 月的 32% 飙到 3 月的 84%，人均月支出 150-250 美元，重度用户 500-2000 美元，CTO 本人一次两小时的会话就花掉了 1200 美元。

这是 Uber 的真实案例。管理层把这描述为"脑袋要炸"的时刻。微软自己也遇到了一样的问题------要求数千名工程师在财年末从 Claude Code 迁回 GitHub Copilot CLI，真实动因就是成本。

根因：Agent 的运行模式是"持续运行模型"，不是"按需调用模型"。每一次工具调用、每一步验证、每次重试，都在烧 token。没有成本上限和熔断机制，Agent 会像一台没人盯的印钞机。

解法：在 Harness 里加成本熔断。

class CostGuard:
    """Harness 成本熔断器"""
    def __init__(self, budget_usd=10.0, price_per_1m_input=3.0, price_per_1m_output=15.0):
        self.budget = budget_usd
        self.spent = 0.0
        self.input_price = price_per_1m_input / 1_000_000   # 每 token 价格
        self.output_price = price_per_1m_output / 1_000_000

    def charge(self, input_tokens, output_tokens):
        cost = input_tokens * self.input_price + output_tokens * self.output_price
        self.spent += cost
        if self.spent >= self.budget:
            raise BudgetExceeded(f"预算用尽: 已花 ${self.spent:.2f} / ${self.budget:.2f}")
        return cost

# 在 harness_loop 里加入成本检查
def harness_loop_with_budget(task, model_fn, budget=10.0):
    guard = CostGuard(budget_usd=budget)
    for step in range(20):  # 步数上限
        decision = json.loads(model_fn(task))
        # 模拟 token 计费
        guard.charge(input_tokens=500, output_tokens=200)
        # ... 执行工具、验证 ...
        if decision.get("done"):
            return "完成"
    return "步数耗尽"

经验：Harness 不只是让 Agent"干得好"，还要让它"干得起"。成本预算应该像 CI/CD 里的测试阈值一样，是 Harness 的一等公民。

坑三：无限循环------Agent 在原地打转

场景：你让 Agent 跑一晚上修 Bug。第二天早上回来，发现它在同一个错误上循环了 6 小时------每次跑测试失败，它"换了方案"重试，但换的方案跟上一轮一模一样。烧了 200 美元的 token，Bug 一个没修好。

根因：没有循环检测和终止条件。Agent 没有记忆"我上一步就已经试过这个方案了"。

解法：在 Harness 里加循环检测和硬性终止条件。

def harness_loop_safe(task, model_fn, max_steps=20, max_retries_per_step=3):
    """带循环检测和终止条件的安全 Harness"""
    history = []  # 记录每步的决策摘要，用于循环检测

    for step in range(max_steps):
        decision = json.loads(model_fn(task))

        # 循环检测：判断这一步的决策是否跟之前某一步一样
        decision_hash = hash(json.dumps(decision, sort_keys=True))
        if decision_hash in history:
            # 同样的决策出现了------说明 Agent 卡住了
            print(f"⚠️ 检测到循环：第 {step} 步与历史决策重复")
            task += "\n注意：你刚才的方案已经试过了，请换一个完全不同的思路。"
            history.append(decision_hash)
            continue

        history.append(decision_hash)

        # 执行 + 验证 + 重试（每步最多 3 次）
        for retry in range(max_retries_per_step):
            result = execute_tool(decision)
            ok, msg = verify(result, decision.get("criteria"))
            if ok:
                break
            task = f"失败原因：{msg}\n请修复后重试。"
        else:
            # 3 次重试都失败------不是简单错误，需要人工介入
            print(f"⚠️ 第 {step} 步连续 {max_retries_per_step} 次失败，请人工检查")
            return None

        if decision.get("done"):
            return result

    print(f"⚠️ 达到最大步数 {max_steps}，强制终止")
    return None

经验：Harness 的核心不是"让 Agent 能跑"，而是"让 Agent 在该停的时候停"。一个好的 Harness 有四道终止条件：任务完成（done）、预算耗尽（budget）、步数上限（max_steps）、循环检测（循环检测）。少任何一道，Agent 都可能在无人值守时烧钱。

---

八、Harness 衰减悖论：好的约束会随模型变强而变成阻碍

这是 Harness Engineering 里最反直觉、也最深刻的洞察。

8.1 什么是 Harness 衰减

Harness 里的每个组件都编码了一个关于"模型做不到什么"的假设。

• AGENTS.md 里写"单文件不超过 200 行"------因为假设模型管不住文件长度
• 评估器 Agent 用 Playwright 做端到端测试------因为假设模型自己的自评不靠谱
• Sprint 分解把大任务切成小块------因为假设模型长上下文处理能力不行，容易跑着跑着忘事

随着模型改进，这些假设会过期。那个曾经补偿模型弱点的组件，变成了纯粹的开销。

8.2 Anthropic 的三代模型证明了这个趋势

Opus 4.5：需要 Sprint 分解 + 逐 Sprint 评估        成本 ~200 美元 / 6h
Opus 4.6：去掉 Sprint 分解 + 单次评估               成本 ~125 美元 / 3h50m（降 38%）
Opus 4.7：模型开始自验证，评估器角色进一步缩小   工具错误只有以前的 1/3

三月份的承重墙，四月份就成了死重。每一代模型都在啃掉评估器的工作职责。

8.3 Build to Delete：为删除而构建

Philipp Schmid（Hugging Face）提出的建议，值得你记下来：

"Build to delete."（为删除而构建。）

把每个 Harness 组件设计成可移除的。定期关掉每个组件，测量输出质量是否变化。如果不变------删掉它。

这不是理论。业界真实发生着：

• Manus 在 6 个月内重构了 5 次 Harness
• LangChain 在一年内调整了 3 次
• Vercel 砍掉 80% 的工具后性能反而更好

每个案例都是同一个故事：上个月有用的东西，这个月成了负担。

Philipp Schmid 把这和 Rich Sutton 的机器学习"苦涩教训"联系起来：随计算规模扩展的简单方法，始终优于复杂的手工设计方案。应用到 Harness 上，含义很清晰：不要构建复杂的、紧耦合的控制系统，而要构建模块化的、可以逐块删除的系统。

8.4 这个悖论给工程团队制造了什么挑战

现在需要 Harness 才能从 AI Agent 那里得到可靠的输出，但今天构建的 Harness 明天就需要部分拆除。而在模型已经超越之后还死抱 Harness 架构的团队，会在每次运行中交税：多花 token、多花延迟、多花维护，零额外质量。

实际建议很简单，即使感觉反直觉：给每个 Harness 组件设计一个开关，定期关掉它测量输出质量，质量不变就删掉。

---

九、Loop Engineering：Harness 的下一步

最后聊一个 2026 年 6 月最火的延伸概念：Loop Engineering。它不取代 Harness，而是站在 Harness 上面再套了一层。

9.1 一句话讲清

Loop Engineering = 设计一套自动发现任务、分派执行、验证纠错、循环迭代的闭环系统，让 Agent 自己跑起来。

你不逐个给 Agent 发指令了，而是设计一个"包工头"脚本------它自己找出有什么活要干，把一块丢给 AI，检查交回来的东西，不合格就带报错再丢一次，直到通过、或者撞到预设的次数和预算上限才停。

9.2 为什么需要 Loop

2023 年的 AutoGPT 就试过让 AI 自己跑循环，没验证、没边界，撒开了跑，最后失败了。2026 年的 Loop Engineering 能落地，因为它有控制、有验证、有边界------而这些控制和验证，正是 Harness 提供的。

换句话说：Loop 是把 Harness 装进了一个无人值守的循环里。

9.3 Loop 的六大核心组件

Addy Osmani 在长文中提炼了 Long-Running Agent 的五层架构：

1. Automation（自动化）：自动发现和触发任务
2. Worktrees（工作树）：隔离每个任务的执行环境（Git worktree 实现）
3. Skills（技能）：复用已有 Harness 配置和工具集------相当于"标准化作业手册"
4. Connectors（连接器）：连接外部系统（数据库、API、消息队列）
5. Sub-agents（子代理）：将复杂任务分解给多个专职 Agent
6. Memory（记忆）：跨会话维护上下文和进度

Anthropic 和 OpenAI 的循环组件高度相似：Automations、Worktrees、Skills、Connectors、Sub-agents、Memory，六大件几乎一一对应。这不是巧合，而是两家在同一套工具下撞到了同一面工程墙，自然收敛到同一个答案。

9.4 警惕"管道生意"

这里必须给你泼一盆冷水。钛媒体在 2026 年 6 月发表了一篇冷静的分析文章，指出一个被忽视的视角：

"每一次概念迭代（Prompt → Context → Harness → Loop）都在传递同一个潜台词：'模型已经足够聪明，瓶颈在使用方式'。这句话未必是假的------但厂商在用力利用这个节奏，把模型增长放缓的压力，悄悄转译成了用户能力不够的焦虑。"

从 Context 到 Loop，大约九个月。每一轮都有行业顶流背书，每一轮都宣称上一轮过时。技术迭代的自然节奏从来缓慢（TCP/IP 从提出到普及用了二十年），而这条线是快速的、自上而下的、齐声合唱的。

Loop Engineering 表面提高效率，实际上在两头烧钱：

• 锁定成本：循环越复杂、沉淀的规则越多，对这套体系的依赖越深
• 运行账单：从"叫它才动"变成"它自己一直在动"，token 消耗倍增

Uber 给约 5000 名工程师铺开 Claude Code 后，四个月烧穿了 2026 年全年 AI 预算。CTO 一次两小时的会话就花掉 1200 美元。

看懂管道的生意，用好管道的价值，同时永远守住自己的判断力。同一个循环，用在自己真懂的活上是杠杆，用来逃避理解就是加速下滑------做看得懂循环的工程师，而不是只会按下运行键的操作员。

---

十、你的行动清单：从今天开始用 Harness 思维

如果你是开发者，读完这篇不要只停留在"有道理"。下面是三步落地方案。

第一步：给现有项目加 AGENTS.md

这是最简单、性价比最高的一步。在你的项目根目录创建一个 AGENTS.md（或 CLAUDE.md、.cursorrules），内容保持 60 行以内，人类手写，不要 AI 生成：

• 技术栈（语言、框架、数据库）
• 编码规范（单文件行数上限、错误处理方式、命名约定）
• 硬规则（禁止删除文件、禁止改 .env、提交前必跑什么命令）
• 当前进行中的工作和稳定区（哪些目录不许改）

第二步：给 Agent 工作流加反馈回路

在你现有的 Agent 工作流里加一个验证步骤：每次 Agent 产出代码后，自动跑 make lint && make test，失败就把错误喂回去让它改，而不是手动检查。这就是一个最小反馈回路。

第三步：定期做 Build-to-Delete 检查

每个月拿一天，关掉 Harness 里的某个组件（比如关掉评估器 Agent，或关掉某个约束规则），看输出质量有没有变化。如果没变------删掉它。带着无用的 Harness 组件每次运行都要多花 token，但什么好处都得不到。

---

经验清单：5 条带走

① 模型已经不是瓶颈，Harness 才是。 LangChain 用同一个模型从 30 名外杀到前 5 名，靠的不是换模型。Vercel 砍掉 80% 工具反而更好。2026 年的重心已从"换个更强的模型"转向"搭一套更牢的缰绳"。

② Harness 五件套缺一不可：工具、权限、反馈、重试、状态。 任何一个缺失，Agent 都会在某个深夜给你惊吓。特别注意反馈回路------没有反馈的 Harness，只是加了多余步骤的 Prompt。

③ 上下文胜过指令。 别再用自然语言描述文件结构和 API------直接给 Agent 真实文件路径、真实符号名、真实验收标准。基于真实状态工作，产出自然融入代码库。基于模糊描述，产出就是臆造和幻觉。

④ 为删除而构建（Build to Delete）。 模型每一代都在变强，昨天的承重墙今天是死重。给每个 Harness 组件设计开关，定期关掉测试质量，不变就删。Manus 六个月重构五次不是水平差，是在快速进步的模型之上构建的必然结果。

⑤ 别被概念迭代追着跑。 Prompt → Context → Harness → Loop 的步伐越来越快，但你要看清楚：这是四级分层而非替代，你同时需要四级。守住你的判断力------在自己真懂的场景里用 Harness 和 Loop 是杠杆，用来逃避理解就是加速下滑。

---

下篇预告

下一篇《大模型实战指南（6）------微调入门：让模型说你的"行话"》。

我们回到模型本身。当通用模型不够用时，微调（Fine-tuning）是让模型适配你行业领域的方式。但它到底改了什么？Full Fine-tuning、LoRA、QLoRA 有什么区别？从零微调一次要花多少显存和时间？为什么有人花了几千块调出来的模型还不如直接写 Prompt？

我们将手把手跑一次 LoRA 微调全流程，用真实数据、真实代码、真实显存账单，把微调这件事彻底拆透。

---

数据来源声明

本文所有事实性数据均来自以下公开来源，已在写作前完成交叉核实：

• Mitchell Hashimoto 博客《My AI Adoption Journey》（2026.2.5）------Harness Engineering 命名起源
• OpenAI Ryan Lopopolo 百万行代码实验报告（2026.2.11）------88 个 AGENTS.md、100 万行、0% 手写
• LangChain 《The Anatomy of an Agent Harness》（2026.3）------Terminal Bench 52.8% → 66.5% 控制实验
• 智源研究院（2026.3.14）------"Prompt Engineering 过时了"公开表态
• ThoughtWorks Birgitta Böckeler 框架（2026.4）------2×2 分类学
• Addy Osmani《The Architecture of a Long-Running Agent》（2026.6.7）------Loop Engineering 正式命名
• Anthropic 工程博客（2024.9-2026.3）------三 Agent 架构、Managed Agents、Opus 4.5/4.6/4.7 成本数据
• Vercel 工程实践------砍掉 80% 工具后性能提升
• Hugging Face Philipp Schmid------"2026 年最重要的工程学科"、操作系统类比、Build to Delete
• ETH Zurich 对 138 个仓库的研究------AGENTS.md 60 行以内效果最佳、AI 生成反而降低性能
• 钛媒体《Loop Engineering：新的循环收费站》（2026.6.23）------对概念迭代节奏的商业视角分析
• OpenAI Codex Harness 开源公告（2026.8.19）------Apache-2.0 协议，github.com/openai/codex，ARC-AGI-3 同模型 13.3% → 38.3%
• Uber / 微软 Claude Code 成本案例------2026 年公开报道

以上数据截至 2026 年 8 月 23 日。大模型领域迭代极快，部分数据（模型版本、基准成绩、定价等）可能在阅读时已有更新。