这是「近五年 AI 技术演进」系列深挖的最后一篇，第十三篇。前十二篇各拆了一个零件——提示词、检索、工具、协议、编排、技能、规矩、记忆、沙箱。这一篇不再拆新零件，而是把它们装回去：为什么这些零件必须长在一起，才叫一个 Agent。全文约 6000 字，含三张表（模块全景、五年时间线、学习路径）、一段最小 Harness 骨架代码和五张原创信息图。
一、先纠正一个说法：模型不是 Agent
同一个模型，在两个产品里表现得像两个东西。
在网页对话框里，你让它修 bug，它给你一段看起来对的代码，说「请替换进去」。在终端里用同一个模型，它能自己找文件、改三处、跑测试、看报错、再改一遍。
模型是同一个，差别在模型外面那一圈东西。
2026 年 2 月，这圈东西终于有了名字。2 月 5 日，HashiCorp 创始人 Mitchell Hashimoto 写了一篇《My AI Adoption Journey》，里面有句话被反复引用：任何时候你发现 agent 犯了一个错，就花时间工程化一个方案，让它永远不再犯这个错。他把这个习惯叫 engineer the harness。六天后，OpenAI 发布了一份 Codex 团队的报告，标题直接叫《Harness engineering》：三个工程师、五个月、约一百万行代码、约 1500 个 PR，没有一行是手写的。他们的工作全部变成了设计环境。两个月内，这个词从个人博客变成了行业黑话。
模型到底是什么
把一次调用写成伪代码，只有一行：
next_tokens = model(context_tokens) # 文本进，文本出，仅此而已它没有手——不能执行任何东西；没有眼睛——看不到执行结果；没有记忆——每次调用都从零开始（详见本系列第 11 篇）；没有时钟——不知道自己已经跑了四十分钟；没有边界——不知道什么事不能做；也没有钱包——不知道这一轮花了多少钱。
做一个思想实验：把目前最强的模型放进一个只有输入框的窗口。它能把「这个 bug 该怎么修」讲得比任何资深工程师都清楚。
然后 bug 还在那里。
说对和做成之间，隔着一整个工程。这个工程就是 Harness：包裹模型的运行循环、工具、记忆、上下文、环境、护栏、协作和知识注入。一句话定位——它是给推理能力配的那副身体。
三个词，别再混着用
2026 年之后，讨论 agent 至少要分清三层：
| 词 | 是什么 | 类比 | 换一个的代价 |
|---|---|---|---|
| 模型 | 权重，文本进文本出 | 发动机 | 改一个参数 |
| 框架（LangGraph、CrewAI） | 造 harness 的零件箱 | 零件目录 | 改一批代码 |
| Harness | 装好、调好、能上路跑的整套系统 | 整车 | 重做工程 |
再往下切一刀，还有个常用区分：scaffold 是开场前搭好的（系统提示、工具定义、规则文件、仓库索引），harness 是每一步运行时做的（解析输出、派发工具、回填结果、压缩上下文、查权限、重试）。很多人争论「提示词重要还是工具重要」，其实是把这两层混在一起谈了——它们的失效方式完全不同：用错文件通常是 scaffold 的问题，第 30 轮忘了规则通常是 harness 的问题。
所以那个流行的公式要读准：Agent = Model + Harness。它的重点不是加法，是那句潜台词——模型不在 harness 里面。harness 是「除模型之外的一切」。
二、引擎与整车：为什么同一台发动机跑出不同成绩
把大模型想成发动机，很多事一下就通了。
马力是单步推理能力，排量是上下文窗口，油耗是 token 成本。参数漂亮，账面好看。
但发动机不能直接驱动车轮。它每分钟几千转地空转，中间必须过一个变速箱，把转速变成轮胎上能用的扭矩。模型也一样：它的输出是 token，不是动作。从 token 到「世界真的变了」，中间要过五道工序——解析意图、检查权限、执行、观察结果、回填上下文，然后回到模型再判断一次。
这套传动系统，就是运行循环。
再往下配：
- 方向盘是工具选择。往哪打，取决于工具描述写得清不清楚——模型只能靠那几行字决定用不用你；
- 刹车是护栏。危险操作要人点头、成本有上限、超时要掐断；
- 底盘是沙箱与运行时。决定这车能在什么路上跑，也决定翻车时是人受伤还是车报废；
- 仪表盘是可观测性。没有它，你只能靠猜；
- 线束是上下文工程。把电送到该去的地方，送错了全车失灵。
三个推论，每个都能解释一批真实事故。
第一，换发动机不等于换整车。很多团队升级了模型，agent 依旧在第 12 步崩掉。因为崩的原因从来不是「不够聪明」，而是上下文太脏、工具返回值太吵、没有检查点。
第二，同一台发动机装在不同整车上，成绩能差好几倍。2026 年初 LangChain 团队公开过一个实验：同一个模型在 Terminal Bench 2.0 上得分 52.8%，排在前 30 之外。他们没换模型，只改了 harness——启动时先给一张目录地图，强制它对着任务说明自查而不是重读自己的代码，把推理预算多分给规划和验证、少分给实现，加了循环检测，提前告知验收方式。几周后 66.5%，进了前 5。13.7 个百分点，比大多数模型换代带来的提升还大。
第三，没有刹车的车不能上路。demo 和产品的分界线不是智力，是「最坏情况下会怎样」。
顺便说个词源。harness 的本义是马具——缰绳、马鞍、嚼子、马蹄铁。马具不让马更强，它让马的力量可用、可控、可停。这比「骨架」更狠：骨架是支撑，塌了散架；马具是驾驭，松了马会冲进人群。
三、七个模块，一个横切面
把 Harness 拆开，是七个模块加一个横切面。这张表建议存下来，它是整个系列的目录：
| 模块 | 对应篇目 | 解决的问题 | 一句话实现 |
|---|---|---|---|
| 运行循环 Loop | 第 3、6 篇 | 一次推理构不成一个任务 | while：思考、行动、观察，带终止条件 |
| 工具层 Tools + MCP | 第 3、4、5 篇 | 模型碰不到外部世界 | 结构化 schema，加上统一协议 |
| 记忆 Memory | 第 11 篇 | 每轮都从零开始 | 短期对话，工作状态，长期结论 |
| 上下文工程 | 第 1、2、9、10、11 篇 | 窗口有限，注意力会稀释 | 预算分配，压缩，按需加载 |
| 执行环境 Sandbox | 第 12 篇 | 代码有破坏力 | 容器隔离，只读根，断网，限额 |
| 护栏 Guardrails | 第 4 篇 | 它会做不该做的事 | 权限分级，人工确认，输出校验，预算上限 |
| 编排 Orchestrator + A2A | 第 7、8 篇 | 单 agent 撞上下文墙 | 拆任务，上下文隔离，协议互通 |
| 知识注入 | 第 2、9、10 篇 | 不懂领域，不懂这个项目 | 事实、方法、规矩，三种知识分开装 |
最后两行严格说是四样东西，按「协作」和「知识」归成两类。而上下文工程不在任何位置上——它在所有模块之间流动，所以叫横切面。
3.1 运行循环：整个 harness 的心脏
一句话：一个 while。四个动作反复做——装配上下文、模型推理、执行动作、观察回填。三个必须有的东西：终止条件（模型说完了、任务达成、步数用完）、预算（token、时间、钱）、检查点（每步存档，崩了能续）。
2023 年 AutoGPT 的失败不是想法错，是这三样一个都没有：它不知道什么时候该停，不知道自己花了多少，也不知道自己走到哪了（详见本系列第 3 篇）。后来 LangGraph 做的事情，本质就是把这个 while 和里面的 if 变成可画、可存、可恢复的图（第 6 篇）。
3.2 工具层：模型唯一能改变世界的通道
工具描述不是注释，是接口文档。模型只能靠 description 判断「什么时候用我、什么时候别用我」，所以写工具的 description 应该像写产品文案，而不是像写函数注释（第 4 篇）。
MCP 解决的是另一个问题：接十个系统要写十套适配器，接一百个要写一百套。它把 N×M 收敛成 N+M（第 5 篇）。一个判断标准：如果一个工具需要模型读三遍说明才会用，那不是模型笨，是工具设计错了。
3.3 记忆：三层容器，三条搬运规则
短期装原话，快满了就压缩；工作装状态，用代码显式读写，抗压缩抗崩溃；长期装结论，带作用域、带时间戳、按需召回（第 11 篇）。
从 harness 的视角看，记忆的难点不在「存」，在什么时候取、取多少。取多了稀释注意力，取少了重犯错误。所以记忆系统的质量不看存了多少条，看召回时的命中率。
3.4 上下文工程：横切在每一层之间
窗口是稀缺资源，按 token 计费，而且每一轮都要重付。给一个能落地的预算：系统提示加工具定义别超过 20%，历史对话和工具结果占 40%，检索与记忆召回占 20%，剩下 20% 留给输出和意外。
超了就要压缩。压缩不是把全文摘要一遍，是保留决策和结论，丢掉原始过程——「决定用方案 B，因为 A 在 CI 上会挂」这一句，比前面 3000 token 的讨论都值钱。
还有一条反直觉的规律：Lost in the Middle 那条 U 形曲线说明，塞在上下文中间的信息召回率最低（第 11 篇）。所以重要的东西要放头尾——开头是任务和规则，结尾是当前状态和下一步。Skill 的渐进式披露（第 9 篇）也是同一个道理：不是所有东西都该进上下文。
3.5 沙箱：决定爆炸半径
一旦模型能执行代码，它就拥有了破坏力（第 12 篇）。沙箱不是防模型变坏，是防「不可预测」。四档隔离、八项检查这里不重复，只强调一句：沙箱决定 blast radius。有沙箱，你可以让它放开跑；没沙箱，你只能让它什么都别碰。
3.6 护栏：能用代码拦住的，别用提示词劝
四个动作：
- 权限分级：读、写、删、转账、发布，越危险，人介入越深；
- 危险操作确认：不可逆的动作，让人点一下头；
- 输出校验：schema、单测、lint、类型检查——用确定性的东西校验概率性的输出；
- 成本上限：单任务 token、单用户日总额、最大循环次数。
再加两样常被忘的：超时防挂死，审计防说不清。
原则一句话：提示词是建议，代码是物理定律。你在提示里写十遍「不要删生产库」，不如在工具层把那个函数直接拿掉。
3.7 编排：单 agent 撞墙之后再拆
单 agent 迟早撞上四堵墙：上下文、工具数量、职责混杂、定位模糊（第 7 篇）。拆开以后，每个子 agent 只带自己那几份材料，token 能从十几万降到几万。
跨组织就靠 A2A：一张 AgentCard、一个 Task 状态机、一套 JSON-RPC 报文，给 agent 之间定了套 HTTP（第 8 篇）。它和 MCP 是一横一纵，不冲突。
但请记住顺序：能单 agent 解决就别拆，拆是成本不是成就。
3.8 知识注入：三种知识，三个容器
装错容器是最常见的浪费：
- 事实（文档、制度、API 手册）→ RAG。检索得到就行（第 2 篇）；
- 方法（这类活该怎么干）→ Skill。检索得到但执行不了，就该用 Skill（第 9 篇）；
- 规矩（这个项目里怎么干）→ AGENTS.md。每个仓库一份，进版本库，可 review（第 10 篇）。
把方法塞进 RAG，你会得到一堆「说得对但做不对」的回答；把项目规矩塞进系统提示，你会得到每个项目复制一遍的噩梦。
四、把七个模块装进一百行
概念讲完，看代码。下面这段是能跑的最小骨架，七个模块都在里面：
# harness.py —— 最小可用 Agent Harness（约 100 行） import json, time from dataclasses import dataclass, field from typing import Callable # ---------- 护栏：权限分级与预算 ---------- LEVEL = {"read": 0, "write": 1, "danger": 2} # 0 自动，1 记日志，2 要人确认 @dataclass class Budget: max_steps: int = 30 max_tokens: int = 200_000 max_seconds: int = 600 used: int = 0 started: float = field(default_factory=time.time) def spend(self, n: int): self.used += n if self.used > self.max_tokens: raise RuntimeError("token 预算耗尽") if time.time() - self.started > self.max_seconds: raise RuntimeError("时间预算耗尽") def guard(tool, args) -> bool: """危险操作必须人来点头""" if LEVEL[tool.level] < LEVEL["danger"]: return True print(f"[需确认] {tool.name} {args}") return input("执行？(y/N) ").strip().lower() == "y" # ---------- 工具层：schema、执行、错误收敛 ---------- @dataclass class Tool: name: str desc: str # 写给模型看的，决定它什么时候用你 schema: dict level: str # read / write / danger run: Callable # 真正干活，跑在沙箱里 TOOLS = {t.name: t for t in [read_file, write_file, run_tests, shell]} # 实现从略 # ---------- 记忆：短期 / 工作 / 长期 ---------- class Memory: def __init__(self): self.messages = [] # 短期：原始对话 self.state = {} # 工作：显式状态，抗压缩 self.long_term = [] # 长期：结论，带 scope def checkpoint(self, path="run.json"): json.dump({"messages": self.messages[-20:], "state": self.state}, open(path, "w"), ensure_ascii=False) # 崩了能续 def recall(self, query, k=3): # 生产环境换成向量 + 关键词双路召回（第 11 篇） return [m for m in self.long_term if query in m["text"]][:k] # ---------- 上下文工程：按预算装配 ---------- def build_context(task, mem, tools): rules = open("AGENTS.md").read()[:4000] # 规矩放头部 tool_doc = "\n".join(f"- {t.name}: {t.desc}" for t in tools.values()) recalled = [{"role": "system", "content": f"相关记忆：{m['text']}"} for m in mem.recall(task)] # 长期记忆，按需 return [ {"role": "system", "content": f"{rules}\n\n可用工具：\n{tool_doc}"}, *recalled, *mem.messages[-12:], # 最近历史，靠尾部 {"role": "user", "content": task}, ] # ---------- 主循环：思考、行动、观察 ---------- def run(task, model): mem, budget, trace = Memory(), Budget(), [] for step in range(budget.max_steps): resp = model.chat(build_context(task, mem, TOOLS), tools=[t.schema for t in TOOLS.values()]) budget.spend(resp.usage.total_tokens) if not resp.tool_calls: # 终止：模型说完了 mem.long_term.append({"text": resp.content[:500], "scope": task}) break for call in resp.tool_calls: tool = TOOLS[call.name] if not guard(tool, call.args): # 护栏：人否决 mem.messages.append({"role": "tool", "content": "用户拒绝执行"}) continue try: result = tool.run(**call.args) # 沙箱里执行 except Exception as e: result = f"工具失败：{type(e).__name__}: {e}" # 失败也要回填 result = str(result)[:8000] # 截断，别撑爆窗口 trace.append({"step": step, "tool": call.name, "args": call.args, "result": result[:200]}) mem.messages.append({"role": "tool", "content": result}) mem.checkpoint() # 每步存档 else: trace.append({"step": "budget", "note": "步数用完，交还给人"}) print(json.dumps(trace, ensure_ascii=False, indent=2)) # 仪表盘 return mem.state一百行里，最值钱的是四行：
if not resp.tool_calls—— 终止条件。没有它，就是 AutoGPT；result[:8000]—— 截断。没有它，第 5 步一个ls -R就能撑爆窗口；guard()—— 人审。没有它，就是删库那次事故；mem.checkpoint()—— 可恢复。没有它，跑 40 分钟崩在第 39 步，全部重来。
其余部分都是在给这四行铺路。你手写过一遍，再看任何框架都知道它在哪一层加东西：LangGraph 给它加了图和持久化（第 6 篇），Claude Code 给它加了终端交互和权限 UI，云厂商把它做成了两次 API 调用。
五、核心论点：模型决定下限，Harness 决定上限
这句话值得拆开看，因为它解释了为什么「换个更强的模型」经常没用。
模型决定下限：单步能力。给它一段代码问「这里有什么问题」，能不能看出来——这是模型的事，harness 帮不上。
Harness 决定上限：能连续做多少步而不崩。
中间是一道乘法题。单步成功率 p，任务需要 n 步，端到端就是 p 的 n 次方：
- p = 0.95，n = 20 → 36%
- p = 0.99，n = 20 → 82%
- p = 0.95，n = 50 → 7.7%
所以长任务不是「难一点」，是指数衰减。这也解释了那个老现象：demo 个个惊艳，产品个个难用——demo 是 3 步，产品是 50 步。
Harness 在这里有两个杠杆，而且都不需要换模型：
- 抬高 p：上下文干净、工具好用、规则明确。每样都能把 p 从 0.95 抬到 0.98；
- 让失败可恢复：重试、回滚、检查点、人审。p 没变，但一次失败不再等于任务失败。
前者把 36% 抬到 55%，后者让它变成「八成成功，两成停下来问人」。这个差别，就是能不能上线的差别。
三个具体的倍数效应，前面都拆过：工具描述重写，同一模型选错工具的概率显著下降（第 4 篇）；上下文从 3 万压到 6 千，注意力不再被稀释（第 9、11 篇）；开工先读 AGENTS.md，少三轮探索（第 10 篇）。每一件的投入都是一两天，收益却常超过一次模型升级。
但边界要说清，否则这个论点会变成万金油：
- Harness 不能把能力不够的模型救成前沿模型。下限是硬约束，8B 就是 8B；
- Harness 不能替代评测。没有 eval，改 harness 全靠感觉；有 eval，改一行提示都能验证；
- 一句话：模型决定你能做多好，harness 决定你能不能稳定做到。
最后一层是资产视角，可能对团队最重要：模型是租的，harness 是自己造的。模型每 6 到 12 个月换一次，价格还在跌；换的时候，工具、规则、记忆、护栏绝大部分能留下。真正的护城河不是「我们用了哪个模型」，而是「我们这套环境，让任何模型进来都能干活」。
六、为什么模型越强，Harness 反而越重要
这是最反直觉的一节。直觉是：模型越来越聪明，外面那圈脚手架应该越来越薄才对。
方向没错——手写的「聪明编排」确实该变薄，2024 年那些精心设计的流程分支，2026 年的模型一句提示就能覆盖。但 harness 整体不是变薄，是变重，因为三件事同时发生了。
第一，动作半径变大。模型弱的时候，它最多把话说错；模型强的时候，它能真的删库、真的发邮件、真的花钱下单。能力越强，一次错误的代价越大，边界就必须越硬。
第二，任务长度变长。弱模型只能接 3 步的活，你不需要检查点；强模型能接 200 步的活，第 137 步崩了，你必须有存档。任务长度是被模型能力撑开的，而管理长度的是 harness。
第三，人的兜底变少。以前你盯着它一步步点，现在你让它跑 40 分钟回来看结果。没人盯着，就必须有日志、有校验、有回滚。
换个说法：模型弱的时候，你只需要一个输入框；模型强的时候，你才需要一整套制度。就像刚入职的实习生，你只让他复印文件；等他成了能签字的人，就需要印章管理、审批流和审计日志——不是因为他变坏了，是因为他的动作开始有后果了。
行业侧的证据也很直接：2026 年 4 月，AWS 把 harness 做成了托管能力（AgentCore harness，6 月正式可用），两次 API 调用就能定义一个 agent，沙箱、记忆、身份、可观测性全归平台。当云厂商开始卖 harness，说明它已经是标准件，不再是手艺。OpenAI 那边流传最广的一句话则是：Agents aren't hard; the Harness is hard.
另一个数字可作参照：2026 年多份报告估计，企业 agent 真正进入生产的比例在 5% 到 12% 之间。死在 demo 到生产路上的那些，绝大多数不是模型不行。
由此得出一条给工程团队的方法论：harness 要薄、要可换、要与模型无关。判断标准很土但很好用——换一个模型，你需要改几行？改得越少，harness 越健康。
七、五年回望：五个阶段
把十三篇连起来看，这五年其实是五个阶段，每个阶段解决一个卡点，也留下一种资产。
阶段一，2022 到 2023，Prompt 时代。卡点是「模型不听话」，资产是话术。ChatGPT 让自然语言成了编程接口，Few-shot 和思维链教会大家怎么问（第 1 篇）。
阶段二，2023 到 2024，工具时代。卡点是「不知道、也做不到」，资产是适配器。RAG 让模型开卷考试，Function Calling 让意图和执行分离，Tool 给了它手脚（第 2、3、4 篇）。
阶段三，2024 到 2025，协议时代。卡点是「接得太贵、连不起来」，资产是标准接口。MCP 统一工具层，A2A 打通 agent 之间，AGENTS.md 和 Skill 把规矩和方法也变成了可分发的东西（第 5、8、9、10 篇）。
阶段四，2025，编排时代。卡点是「单 agent 撞墙」，资产是图与状态。LangGraph 把循环画成图，Orchestrator 把任务拆开（第 6、7 篇）。
阶段五，2025 到 2026，系统化时代。卡点是「不稳定、不敢上生产」，资产是 harness 本身。记忆、沙箱、护栏、可观测性从高级功能变成基础设施（第 11、12 篇和本篇）。
一条主线贯穿这五步：人的工作，从优化输入，到扩展能力，到标准化连接，到组织协作，最后到设计环境。每一步都把上一层的经验固化成基础设施，再把人的注意力往上推一层。
完整时间线：
| 时间 | 事件 | 阶段 | 本系列 |
|---|---|---|---|
| 2022.10 | LangChain 开源，链式编排出现 | 一、Prompt | 第 1 篇 |
| 2022.11 | ChatGPT 发布，自然语言成为编程接口 | 一、Prompt | 第 1 篇 |
| 2023.03 | AutoGPT 爆火又退潮，第一波 agent 泡沫 | 一、Prompt | 第 3 篇 |
| 2023.06 | OpenAI 推出 Function Calling | 二、工具 | 第 3 篇 |
| 2023 下半年 | RAG 成为企业落地 LLM 的第一选择 | 二、工具 | 第 2 篇 |
| 2024.10 | LangGraph 开源，把循环画成图 | 四、编排 | 第 6 篇 |
| 2024.11 | Anthropic 发布 MCP | 三、协议 | 第 5 篇 |
| 2025.04 | Google 发布 A2A，agent 之间开始互通 | 三、协议 | 第 8 篇 |
| 2025.06 | A2A 捐赠给 Linux 基金会 | 三、协议 | 第 8 篇 |
| 2025.08 | AGENTS.md 随 Codex 进入代码仓库 | 三、协议 | 第 10 篇 |
| 2025.10 | Agent Skills 发布，方法可以打包分发 | 三、协议 | 第 9 篇 |
| 2025.10 | LangGraph 1.0 发布，编排框架进入稳定期 | 四、编排 | 第 6 篇 |
| 2025.12 | MCP 捐赠 AAIF，协议走向中立 | 三、协议 | 第 5 篇 |
| 2026.02 | Harness 被正式命名：Hashimoto 博文与 OpenAI 报告 | 五、系统化 | 第 13 篇 |
| 2026.03 | A2A v1.0 发布，150 多个组织采用 | 三、协议 | 第 8 篇 |
| 2026.06 | AWS AgentCore harness 正式可用，harness 成为托管标准件 | 五、系统化 | 第 13 篇 |
八、给开发者的行动建议
前面都是认知。这一节是动作，按优先级排。
8.1 学习顺序：从下往上，别跳
| 顺序 | 学什么 | 为什么放在这一层 | 投入 |
|---|---|---|---|
| 第 0 层 | Prompt，加手写一个 while 循环（不引框架） | 所有框架都是它的变体 | 一个周末 |
| 第 1 层 | 工具设计、上下文预算、一层文件记忆 | 决定 80% 的使用体验 | 两周 |
| 第 2 层 | 护栏（权限、确认、预算、审计）加 Docker 沙箱 | 决定敢不敢上生产 | 一个月 |
| 第 3 层 | 多 agent 编排、MCP、A2A | 撞墙之后再上 | 按需 |
8.2 小团队和个人最值得先做的三件事
第一件：用 200 行裸循环跑通 3 个真实工具。不引任何框架，就while加requests加subprocess。验收标准：能读文件、能跑测试、能根据测试输出改代码，完成一个真实的小任务。做完这一步，你再看 LangGraph 的文档会突然变简单，因为你知道它在包装什么。
第二件：把工具描述当产品文案写。写清四件事：什么时候用、什么时候别用、返回什么格式、失败长什么样。验收标准：拿 5 个真实需求去测，模型第一次就选对工具的比例超过 80%。这是投入产出比最高的一件事——改几行字，可能顶一次模型升级。
第三件：加三道最便宜的护栏。危险操作白名单（删除、发布、转账必须先问人）、单任务 token 上限、全链路 trace（每一步的输入、工具、参数、结果、耗时）。一天工作量。验收标准：故意让它删一个重要文件，它会停下来问你；任务跑飞了，你能从 trace 里指出第几步开始错。
这三件事有个共同点：都不用换模型，都不用买服务，当天就能动手。
8.3 看起来重要、其实可以先跳过的
- 多 agent 编排。单 agent 加好工具能覆盖大部分场景。先撞墙（上下文爆、职责混）再拆，否则只是把一个问题拆成五个问题；
- 复杂 RAG。「它不懂这个项目」这类问题，AGENTS.md 加目录树加 grep 往往比向量库更准，而且可解释。向量库留给文档量真大、查询语义真模糊的场景；
- 自建 MCP server。先用官方和社区现成的；等同一类集成的需求出现三次，再自己写；
- 微调。永远是最后一步：格式话术用 Prompt，知识问题用 RAG，能力问题才考虑微调。
8.4 未来一到两年值得关注
- 上下文从「截断」走向「换页」。虚拟上下文、按需换入换出，像操作系统管内存一样管窗口；
- 记忆的标准化与可迁移。现在记忆锁在各家产品里，接下来会出现「跟着人走」的记忆格式；
- 评测成为 harness 的一等公民。没有 eval 的 harness 无法迭代，趋势是把线上 trace 直接变成测试用例；
- agent 自己的身份与权限。最小权限、可审计的委托链、agent 专用的 OAuth——这块现在最原始，也最容易出事故；
- 长任务的可恢复性与成本工程。检查点、人审节点、断点续跑会成为默认配置；模型级联与按任务分配推理预算会成为常规优化项。
九、结语：这场变革的本质
十三篇走完，如果只留一句话：
AI 工程的重心，从「怎么让模型说得好」，移到了「怎么让系统做得成」。
这句话背后是五次重心的平移：优化输入、扩展能力、标准化连接、组织协作，最后到设计环境。每一层都把上一层的经验沉淀成基础设施，再把人的注意力往上推一层。
所以「模型会越来越强，harness 会不会不重要」这个问题，答案正好相反。模型越强，它替你把「想」做得越好，剩下的全是「做」的工程；而「做」的工程，永远需要人来定边界。
给这个系列收个尾。十二个零件，一句话各归其位：
Prompt 是话说清楚，RAG 是资料递对，Function Calling 是意图与执行分离，Tool 是手脚，MCP 是接口，LangGraph 是循环的图纸，Orchestrator 是分工，A2A 是跨公司的握手，Skill 是方法，AGENTS.md 是规矩，Memory 是记性，Sandbox 是边界。
而 Harness，是让这十二样同时成立的那个整体。
最后留一个问题，建议每个做 agent 的人都答一遍：
如果让它自己跑 40 分钟，最坏情况下它能弄坏什么？
答得出来，你就可以放心地让它跑得更久。答不出来，先把护栏补上，再谈能力。
能力决定它能做什么，边界决定你敢让它做什么。用户真正放心把活交出去的那一刻，通常不是模型变聪明了，而是他知道——最坏的情况，有上限。
参考资料
- Mitchell Hashimoto,My AI Adoption Journey（2026 年 2 月），harness engineering 的命名出处：My AI Adoption Journey – Mitchell Hashimoto
- OpenAI,Harness engineering: leveraging Codex in an agent-first world（2026 年 2 月）
- Amazon Web Services,Amazon Bedrock AgentCore harness is now generally available：Amazon Bedrock AgentCore harness is now generally available: Go from idea to production-grade agent in minutes | Artificial Intelligence
- Birgitta Böckeler / Martin Fowler, 关于 harness engineering 的评述（2026 年 2 月）
- Anthropic,Building effective agents（2024 年 12 月）：Building Effective AI Agents \ Anthropic
- Anthropic,Effective context engineering for AI agents：Effective context engineering for AI agents \ Anthropic
- Liu et al.,Lost in the Middle: How Language Models Use Long Contexts（TACL 2024）：[2307.03172] Lost in the Middle: How Language Models Use Long Contexts
- LangChain, Terminal Bench 2.0 上的 harness 改进实验记录（2026 年初）
文中数据以各家公开材料为准，会随版本更新。
