第 22 章 · 通往大模型

用好大模型:Context、Harness 与 Agent

绝大多数人既不训练也不部署大模型,而是直接使用别人训练好的那个。 这一章把“用”这件事讲透:从 prompt engineering 到 context engineering, 再到 harness engineering。你会看到:提示词、RAG、工具调用、memory、MCP、Agent 并不是一堆散乱热词,而是在一步步给模型接上上下文、工具、状态、验证和工程护栏。

读完这一章,你会明白

• 为什么“用好模型”的重心正在从 prompt engineering → context engineering → harness engineering 迁移;
• 提示词(prompt)、上下文学习、few-shot、思维链(CoT)分别是什么;
• RAG、工具调用和 MCP 怎样把外部知识、工具说明和执行结果放进上下文;
• 为什么幻觉只能靠证据、工具、自检和系统兜底层层压低,不能靠一句提示词根除;
• 为什么很多评测会奖励“不会也猜”,以及机制可解释性怎样开始解剖模型内部电路;
• 提示、RAG、微调三招各自改什么、该在什么时候用;
• Agent 为什么会把“上下文管理”和“外部护栏”变成系统问题;
• 上下文工程为什么是 Agent 的工作记忆:动态压缩、外部 memory、经验手册、子 Agent 隔离上下文;
• Harness 工程怎样用执行循环、工具注册、上下文管理、状态存储、hooks 和评测接口,把模型变成稳定工作系统;
• 用大模型时该守的安全与常识底线;
• 为什么未来工程师的重点会从“写代码”转向“设计 Agent 的工作环境”。

从 Prompt 到 Context,再到 Harness

早期大家谈“用好大模型”,重点几乎都在 prompt engineering: 怎么写指令、怎么给例子、怎么让它一步步想。后来任务变长、工具变多、Agent 开始循环做事, 问题就不再只是“这一句话怎么写”,而是模型每一步应该看见什么——这就是 context engineering。再往后,模型要真的写代码、点浏览器、跑测试、维护状态、接受审查, 就需要一整套包在模型外面的工程外壳,也就是 harness engineering。

1. Prompt engineering:把话说清楚

模型参数固定了,你唯一能调的就是输入——也就是提示词(prompt)。 回忆第 17、19 章:模型会把你给的整段文字当上下文,一路影响它对“下一个词”的预测。所以 提示写得好,等于把模型往你要的方向“推”了一把。这件事有个正经名字叫 上下文学习(in-context learning):不改一个参数,只靠上下文就让模型临场“学会”做某件事。

• zero-shot 零样本直接下命令:“把下面这段翻译成英文”。
• few-shot 少样本先给几个示范再出题:“中文→英文:猫→cat;狗→dog;鸟→?”。给了例子,它照葫芦画瓢的成功率大增(这正是第 20 章说的“涌现”能力之一)。
• 思维链 CoT加一句“一步一步想”,让它把推理过程写出来。别小看这句话——复杂题目的正确率往往因此明显提高,因为它把“一步到位猜答案”变成了“顺着写、边写边推”。

2. Context engineering:让模型看见该看的

Context engineering 不是“把所有东西都塞进去”,而是为这一步选择最该看的材料、工具结果、长期记忆和任务状态。 RAG、工具调用、memory、AGENTS.md、playbook、MCP,本质上都在回答同一个问题:这次调用模型时,上下文窗口里应该放什么?

2.1 RAG:把外部知识放进上下文

第 20 章说过大模型的两个硬伤:知识截止(不知道最新的事)和幻觉(没依据也敢编)。 最实用的解药叫 RAG(检索增强生成)——不重新训练,而是先查资料,再让它带着资料回答。

它的核心机制,处处都是你学过的东西:

1. 把你的文档切成小片段(chunk),每段几百字;
2. 用专门的文本/句向量 embedding 模型把每段变成向量,存进“向量库”;
3. 提问时,把问题也变成向量,用向量相似度(点积/余弦)找出最相关的几段;
4. 把这几段和问题一起塞进提示,让模型“看着材料”回答。

2.2 可靠回答:幻觉、证据与验证

RAG 是最实用的一招,但它只是一道防线。你可能会问:那今天最顶级的模型,是怎么把幻觉压到“少见且可控”的? 先接受一个前提——幻觉无法被彻底消除,只能层层拦截。根因在第 20 章说过:模型本质是概率续写器, 在它内部,“我知道”和“我编一个通顺的”并没有一条天然的分界线。所以顶级模型不追求“消灭幻觉”,而是在从训练到产品的每个环节都设一道关卡,像漏斗一样逐层过滤。

训练阶段:让它倾向于“诚实”

• RLHF 对齐(第 20 章):人类反馈里明确惩罚“自信地胡说”、奖励“不确定就坦白”,让模型学会校准语气——没把握时说“可能 / 据我所知”,而不是一口咬定。
• 教它说“我不知道”:很多幻觉来自“被问到知识边界外还硬答”。训练时特意加入“该拒答 / 该表示不确定”的样本,让弃权成为一个合法选项,而不是硬憋一个答案。
• 事实性专项偏好:用“有据可查 vs 凭空编造”的对比数据做偏好训练,把说真话的倾向直接拉高。

推理阶段:给它外挂和草稿纸

这一阶段是效果最立竿见影的,核心思路是:别让它只靠“脑内记忆”硬答,而是把答案锚定到外部的真实证据上。

• RAG 检索增强(上一节):回答前先捞真实资料,让它照着材料答。这是性价比最高、最主流的一招。
• 工具调用(见 下文 §2.4):算数用计算器、查实时信息调 API、跑代码验证——把“需要精确”的事外包给确定性工具,不靠脑补。
• 先推理再答(思维链 / reasoning 模型):像先在草稿纸上分步推演再下结论,能显著减少“一步硬猜”导致的推理型幻觉。
• 要求给出处:让答案附引用。一旦被逼着给来源,模型编造的空间就小了,用户也能顺着链接核对。

输出后:自检与交叉验证

• 多次采样自检(self-consistency):同一问题采样多个答案,互相不一致的地方往往就是模型没把握之处,取多数或触发复查。
• 让另一个模型当“事实核查员”:用一个校验模型逐句核对“生成内容 vs 检索到的证据”是否吻合(RAG 里叫 groundedness / 忠实度检查),对不上就打回重来。
• 系统兜底:检索不到证据、置信度过低时,产品宁可回一句“无法确认”也不硬答;医疗、法律、金融等高风险场景则要求人工复核 + 显示信息来源。

评测也会塑造模型:别把“不知道”判成错

很多事实没有规律可推,比如某个人的生日、冷门论文标题、一个小项目的真实配置。 训练集中没见过,模型就不能靠“更聪明”凭空算出来。此时最可靠的行为应该是承认不确定, 或者要求检索/工具/更多上下文。但如果评测只看最终答案对不对,问题就来了:

所以“抗幻觉”不只是模型公司的训练技巧,也是整个生态的评分问题。 如果主流榜单继续奖励硬猜,模型就会被优化成看起来什么都敢答;如果榜单奖励校准、引用证据和合理弃权, 模型才会更像一个可信助手。

可解释性:不只看输出,还看内部电路

另一条正在发展的路线,是机制可解释性:不只问“模型答了什么”,还追问“它内部为什么这么答”。 Anthropic 2025 年的 On the Biology of a Large Language Model 用 归因图(attribution graph) 去追踪 Claude 3.5 Haiku 的内部计算: 节点是被激活的概念特征,边表示这些特征怎样影响后面的特征和最终输出。

这类工作已经能看到一些很具体的内部过程:多步推理里先出现中间事实,写押韵诗前会预先激活候选押韵词, 拒答时会把具体危险线索汇入更抽象的有害请求特征,幻觉时也可能是“应该补一个看似合理答案”的路径压过了“我知道/不知道”的信号。 它还远不是完整解剖,但方向很重要:可信模型不只要输出正确,还要逐步变得可检查、可干预、可追责。

2.3 提示、RAG 还是微调:三招该用哪个?

讲完提示和 RAG,一个很自然的问题冒出来了:要让模型在我的场景里表现更好,到底是改提示、接 RAG, 还是干脆微调(fine-tune,拿你的数据接着训一小段,属于第 20 章后训练的范畴)? 它们不是三选一的对立关系,而是成本从低到高、按需叠加的三层台阶。

2.4 工具调用:把工具说明和结果放进上下文

大模型不擅长精确计算,也查不到实时数据(第 20 章)。那就别让它硬算——让它调用外部工具。 这套机制最早叫 function calling(函数调用):

1. 你把可用的工具清单(计算器、搜索、日历……)连同问题一起给模型;
2. 模型判断该用哪个工具、要传什么参数,把这个“意图”返回;
3. 由程序真正执行工具、拿到结果,再喂回模型;
4. 模型结合工具结果,给出最终回答。

于是“3897 × 421 等于几”“今天北京天气”这类它本来做不好的事,就交给计算器和天气 API,它负责理解、调度、总结。 模型从“一张嘴”升级成了“会用工具的手”。

2.5 Agent:从回答问题到循环做事

当模型从“一次回答”升级成循环做事的 Agent,context engineering 就不再只是“塞几段资料”, 而是变成工作记忆问题:每一步该看什么、工具结果怎么回流、哪些探索噪声该隔离出去。

当一个系统能感知环境 → 思考决策 → 执行动作,还能看着结果继续下一步,它就成了一个 Agent(智能体)。如果负责“思考决策”的大脑是一个大模型,那它就是我们现在常说的 AI Agent。

你正在用的这个编程助手,本质就是一个 Agent:它读你的需求(感知)、决定改哪个文件、跑什么命令(思考), 真正去编辑和执行(执行),再根据报错继续修(循环)。RAG 和工具调用,都是喂给这个“大脑”的能力。

2.6 Agent 的工作记忆:动态压缩、memory 与子 Agent

到这里,你可能会觉得 Agent 的关键是“会不会调用工具”。其实还差一块更底层的东西: 上下文工程(context engineering)。它关心的不是“提示词怎么写得漂亮”, 而是每一次调用模型时,到底该把哪些信息放进上下文窗口。

动态压缩:保留状态,丢掉噪声

长任务做着做着,对话历史、工具输出和中间尝试会迅速膨胀。最直接的办法叫 compaction(上下文压缩):当窗口接近上限时,把历史压缩成一份高保真状态摘要, 再带着这份摘要开启新的上下文窗口继续工作。

好的压缩不是“越短越好”,而是能让 Agent 接着干活。它应该保留:

这里最容易犯的错是摘要化过猛:把“为什么这么做”“哪些尝试失败过”“哪个文件刚改过”都压没了。 Anthropic 的工程经验里,压缩更像给接班人写交接单:保留架构决策、未解 bug、实现细节和最近访问文件, 而不是把历史改写成一段漂亮短文。

Memory:把长期经验放在窗口外

memory 是另一种思路:别把所有信息一直留在上下文里,而是让 Agent 把关键状态写到外部, 需要时再读回来。它可以很简单,比如一个 TODO.md、NOTES.md、项目记忆文件, 也可以是数据库、向量库或专门的记忆服务。

真正难的是什么时候写、什么时候读。写得太少,下一轮忘事;写得太多,检索回来又污染上下文。 一个实用做法是把 memory 分层:

• 工作记忆:当前任务的 TODO、最近改动、下一步动作,更新频繁,生命周期短;
• 项目记忆:仓库结构、常用命令、验证脚本、部署规则,比较稳定;
• 经验手册:反复踩坑后的规则,如“改章节后跑锚点检查”“工具输出太长先摘要再读”。

可演化 playbook:从执行反馈里长经验

ACE 论文把上下文看成一份会演化的 playbook,而不是一段每次整体重写的 prompt。 它把过程拆成三种角色:

• Generator:拿当前上下文去做任务,暴露成功路径和失败轨迹;
• Reflector:根据成功/失败提炼经验,指出哪些策略有用、哪些误导;
• Curator:把这些经验整理成结构化条目,合并回上下文手册。

关键是它用增量条目而不是整段重写。每条经验都像一颗小积木,有自己的编号、内容和“有用/有害”计数。 这样能避免两个常见问题:

• brevity bias:为了摘要得短,把领域技巧、工具细节和失败模式全删掉;
• context collapse:每轮都重写整份上下文,越写越像空泛总结,细节逐轮流失。

- id: tool-calendar-timezone
  helpful: 7
  harmful: 0
  note: 调日历工具前先确认 timezone;缺省时不要猜,先查用户资料或请求澄清。

- id: codebase-anchor-check
  helpful: 12
  harmful: 1
  note: 修改电子书 h2/h3 标题后,必须跑 check_anchors.py;不要手算 slug。

这类条目比“以后注意工具参数”更有用,因为它具体、可检索、能被计数淘汰。Agent 下一次遇到类似任务时, 只需要取回相关条目,不必重读全部历史。

子 Agent:把探索噪声隔离出去

还有一种重要技巧是隔离上下文。复杂研究或大代码库排查时,一个主 Agent 如果亲自读完所有文件、日志和网页, 很快会把自己的上下文塞满。更稳的做法是让子 Agent 在独立窗口里深挖一个局部问题,最后只返回一份高密度摘要。

所以,Agent 的“聪明”不只来自模型参数,还来自这套上下文操作系统: 该压缩时压缩,该外存时外存,该检索时检索,该隔离时隔离。 会管理上下文的 Agent,才能在很长的任务里保持方向感。

2.7 MCP:工具和数据源的标准上下文接口

Agent 要调用各种外部工具和数据源,如果每接一个都要定制一套对接,就太乱了。 MCP 模型上下文协议由 Anthropic 提出,给“Agent ↔ 外部工具/数据源”定义了一套标准插头: 工具说明、资源、数据和调用结果都能用统一方式进入上下文。有了它,任何遵守协议的工具都能被任何 Agent 即插即用, 不用一个个定制(可以类比 USB 之于外设)。

A2A 也曾试图规范 Agent 与 Agent 之间怎么通信、协作,但这条线还不如 MCP 稳定,本章只点到这里,不展开成主线。 你只需要记住一个方向:大模型正从“一个聊天框”,长成一个能连接工具、数据源和专职 Agent 的工作生态。

3. Harness engineering:让模型可靠做事

如果说上下文工程解决的是“模型每一步看什么”,那 Harness 工程(harness engineering) 解决的是“模型怎么在真实环境里长期、安全、可恢复地做事”。LangChain 有个很干脆的说法: Agent = Model + Harness。模型负责智能;Harness 负责把这种智能接到状态、工具、文件、沙箱、评测和控制流上。

还可以把 Harness 理解成一座约束金字塔。越往下越便宜、越普及,但越依赖模型自己记住规则; 越往上越少见、成本越高,却越像外部系统给模型加的硬护栏。

3.1 Harness 的六个部件

一篇 2026 年的 Agent Harness survey 把这层工程外壳写成一个很清楚的六元组: H = (E, T, C, S, L, V)。它的意思不是让你背公式,而是提醒你: Agent 的可靠性不只取决于模型多强,还取决于模型外面这六件事有没有被设计好。

这也是为什么“换一个更强模型”不总能解决 Agent 的问题。模型像发动机,但执行循环、工具、上下文、状态、hook 和验证接口决定了它能不能把能力稳定地传到真实任务上。很多所谓“模型不行”,其实是工具接口混乱、上下文污染、 没有状态恢复,或者没有外部验证。

3.2 长任务 Harness:Planner、Generator、Evaluator

Anthropic 在长时间应用开发实验里,把单个“全能 Agent”拆成三个角色:

• Planner:把一句产品需求扩展成高层产品规格和交付清单,但避免过早写死细节实现;
• Generator:按 sprint 一次实现一个功能,把工作落到代码、文件和版本控制里;
• Evaluator:像用户一样点应用、跑测试、看数据库/API 状态,按明确标准给出失败原因。

这个设计的关键不是“多几个模型一起聊天”,而是职责隔离。做事的 Agent 不负责给自己打高分; 评估者用独立上下文、明确标准和真实环境反馈来挑错。长任务中间如果上下文变脏,可以直接重置 Agent, 通过结构化 handoff artifact 把当前状态和下一步交给新 Agent,而不是让同一个 Agent 背着越来越重的历史继续硬撑。

多 Agent 协作在软件工程里还有一个更硬的版本。2026 年论文 Effective Strategies for Asynchronous Software Engineering Agents 提出 CAID(Centralized Asynchronous Isolated Delegation):一个中央 manager 先把任务拆成带依赖的子任务, 多个 engineer Agent 在各自隔离的 git worktree 里并行实现,完成后用 git commit / git merge 回到主线,并用可执行测试验证整合结果。它的重点不是“大家在同一个聊天里讨论”,而是把人类软件团队早就成熟的 branch-and-merge 搬给 Agent 用。

这篇论文的实验也给了一个很实用的提醒:多 Agent 不是越多越好。并行度要匹配任务本身的模块化程度和 manager 的调度能力; 人数太多、切得太碎,反而会增加合并冲突、沟通成本和验证成本。对长代码任务来说,正确问题不是“要不要多个 Agent”, 而是哪些任务能隔离并行,哪些依赖必须先合并验证。

3.3 Harness 里的确定性护栏

Harness 还要处理模型不擅长但工程系统很擅长的事:确定性约束。比如 OpenAI 的 Harness Engineering 讨论里, 他们让 Codex 从空仓库开始生成应用逻辑、测试、CI、文档、可观测性和内部工具;人的主要工作从“写代码”转成 设计环境、明确意图、构建反馈回路。这不是把一个巨大说明书塞进上下文,而是把知识、约束和反馈做成 机器可读、可执行、可维护的仓库结构。

一个关键经验是:AGENTS.md 不该是百科全书,而该是地图。真正的信息放进结构化的 docs/、 架构文档、执行计划、产品规格、生成的 schema、参考资料和质量评分里;简短入口告诉 Agent 下一步该去哪查。 这样既避免上下文爆炸,又让知识有所有权、可交叉链接、可被 lint/CI 检查新鲜度。

另一条经验是让应用本身对 Agent 可读:让 Codex 能按 worktree 启动独立实例,用浏览器协议查看 DOM 和截图, 用日志/指标/追踪回答“启动是否低于 800ms”“关键用户旅程是否超过 2 秒”。当 UI、日志和指标都能被 Agent 读取, 它才有能力复现问题、验证修复,而不是只靠人类 QA 口头描述。

最后是熵管理。完全由 Agent 高速产出的代码会复制仓库里已有模式,包括坏模式。OpenAI 的做法是把“黄金原则”编码成 架构约束、结构测试、自定义 lint 和后台 Codex 任务,定期扫描偏差、更新质量评级、发起重构 PR。可以把它想成给 Agent 生成的代码加垃圾回收:小问题定期扫掉,技术债不要等积成山再一次性还。

所以这条演进线可以这样记:Prompt 让模型听懂你;Context 让模型看见该看的;Harness 让模型在真实系统里可靠地做完。

4. 用它,但别全信它

把这些记在心里,你就能既享受它的强大,又不被它的“自信”带偏。理解原理的人,用起工具来总是更稳、更有分寸。

小结

• 提示词是你唯一的旋钮:zero-shot 直接问、few-shot 给例子、CoT 让它一步步想。
• RAG = 先检索再回答,用词嵌入+相似度找资料,把“闭卷”变“开卷”,治幻觉与知识截止。
• 对抗幻觉是组合拳:训练时让它倾向诚实/会拒答,推理时用 RAG+工具+推理链锚定证据,输出后自检交叉验证,系统层加护栏与人工兜底;幻觉只能压低、无法根除。
• 复杂任务越来越像搜索系统:生成多个候选,用验证器挑错,用修复器补洞或重写,最后排序/投票选答案。
• 幻觉也来自评测激励:如果“不知道”永远 0 分、猜测有机会得分,模型就会被塑造成爱猜的考生;机制可解释性则尝试用归因图追踪内部特征和电路。
• 提示 / RAG / 微调是成本递增的三层:先改提示,缺知识上 RAG,只有要固化风格才微调——别拿微调补知识。
• function calling 让模型调用计算器/搜索/API,补上它不会算、查不到的短板。
• Agent = 大模型当大脑 + 感知与执行 + 多步循环;上下文工程负责管理它的工作记忆:压缩历史、写外部 memory、维护经验手册、用子 Agent 隔离噪声;MCP 则把工具和数据源变成标准上下文接口。
• Harness 工程把模型包进工作系统:执行循环负责多步推进,工具注册表治理可用能力,上下文管理器决定每步看什么,状态存储保存进度,hooks 提供硬拦截,测试/评测器提供外部反馈;多 Agent 协作还要靠依赖图、隔离工作区、显式 merge 和测试验证来避免互相踩踏。
• 始终核对关键事实、防提示注入、护隐私——理解原理才能用得稳。

动手与思考

下一章进入代码实战:第 23 章 先把 MNIST 程序逐行对上号。