2026-10-27 更新：6 月写的时候是三幕，这几个月又长出第四幕 Harness，顺手把第三幕里的旧数据也换了。
前阵子翻自己的笔记，发现一个有意思的现象：2023 年我记的关键词是 "prompt engineering"，2024 年底变成了 "context engineering"，今年上半年满屏都是 "agent"，到了下半年，又冒出来一个 "harness"。
同一拨人、同一批模型厂商，每隔一年就换一个词。一开始我以为是炒概念，后来想明白了——这几个词其实是同一件事在不同阶段的名字：我们是怎么一步步学会"用好"大模型的。
模型本身当然在变强，但这条线我觉得更值得讲：不是模型突然变乖了，是我们学会了怎么喂它、怎么放手、怎么给它立规矩。
按时间，正好是四级跳。
第一幕：Prompt Engineering——把话说清楚
最早大家发现一件反直觉的事：同一个模型，你换种说法问，答案质量天差地别。
于是有了 prompt engineering。说白了就一句话：怎么跟一个聪明但完全没脾气、没记性的实习生交代任务。
你不能甩一句"帮我搞一下"就指望他懂。你得说清楚要什么、给两个例子、让他别急着下结论先一步步想。最经典的发现就是那句"让我们一步步思考"（Chain-of-Thought）——就加这么一句，复杂推理的正确率能大幅往上跳。我第一次试的时候是真的有点震惊，模型不是不会，是你得给它留出"想"的空间。
这一阶段官方的东西其实已经够用了，不用看花里胡哨的技巧贴：
- Anthropic 官方 Prompt Engineering 指南
- OpenAI 官方指南
- Lilian Weng 的综述（想系统看就看这篇，写得最清楚）
- 想看源头：Chain-of-Thought 论文、ReAct 论文
但很快就撞墙了：话说得再漂亮，一句提示里也塞不下一个真实任务需要的所有东西。 我要它改我的代码，得让它先看到代码库吧？要它写报告，得让它读到那几份文档吧？
问题就从"怎么说"，变成了"该让它看到什么"。
第二幕：Context Engineering——管好它的"工位"
这是我觉得最有技术含量、也最被低估的一幕。
打个我自己最受用的比方：模型的上下文窗口（context window）就是它的工位桌面，而你是那个帮它收拾桌面的人。
桌面就那么大。你以为把所有资料都堆上去它就能干得更好？恰恰相反。这里有个特别违反直觉的事实，叫 context rot（上下文腐烂）：喂进去的内容越多，模型从里面准确捞出关键信息的能力反而越差。 它不会"崩"，但会悄悄变笨——就像一个人桌上堆了两百份文件，他还在，但你让他找一张特定的纸，他就开始翻半天找错。
所以 context engineering 的核心不是"塞得多"，是"永远只放最少、最关键的东西"。LangChain 把所有手段归成了四类，我觉得记这四个动词就够了：
- Write（写出去）：让模型把笔记记到桌面外面，比如存成一个文件、一份待办，需要时再拿回来。
- Select（选进来）：每一步只把这一步用得上的资料拉到桌面上，而不是全摊开。
- Compress（压一压）：聊太长了就做个摘要，把前面几十轮浓缩成一段，腾出桌面。
- Isolate（拆开）：一个人忙不过来的活，拆给几个人分别干，各看各的资料。
我自己踩过最深的坑就在这——给一个子任务的 AI 连了太多工具和资料，结果它直接被信息淹死，啥也干不成。后来想通了，这其实就是没做好 Isolate 和 Select。那一刻我才意识到，我天天在干 context engineering，只是之前没这个词。
两篇权威的，我建议都读：
- Anthropic：Effective Context Engineering for AI Agents（讲透了"为什么 context 是稀缺资源"）
- LangChain：Context Engineering for Agents（上面那四个动词的出处）
这一幕到今年还在往前走，重点挪到了"记忆"：怎么让 agent 跨对话记住东西，又不把记忆全塞回桌面。LangChain 10 月那篇 Context Engineering with Deep Agents: How To Remember Without Keeping Everything In Context 讲的就是这个，可以当四个动词的续集看。
但桌面收拾得再干净，模型还是被动的——你问一句，它答一句。下一步很自然：能不能别让我一步步喂了，给它个目标，让它自己跑？
第三幕：Agent Engineering——把方向盘交出去
如果说前两幕是"怎么把任务交代给一个被动的助手"，这一幕是让助手变成一个能自己规划、自己动手、还能带几个小弟的同事。
核心是一个循环：规划 → 动手（调工具）→ 看结果 → 再规划，一直转到把事办成。你不再盯着每一步，你给目标，它自己决定下一步干嘛、要调哪个工具、要不要拆几个子任务并行。
这一幕能成，有两块地基是前两年悄悄打好的：一是 2024 年底出来的 MCP，把"模型怎么接工具"统一成一个协议，不用每家各写一套；二是 computer use，让模型能直接操作屏幕和浏览器。前者去年底进了 Linux 基金会、今年 7 月又改了一版规范，后者 8 月正式 GA。工具接口标准化了，agent 才有东西可"动手"。
更有意思的是多智能体这套玩法：一个主 agent 负责统筹，派出去好几个子 agent 各干各的脏活累活，每个子 agent 可能烧掉几万 token 去翻资料，但最后只回传给主 agent 一两千 token 的"干货摘要"。这不就是个项目经理带团队么——老板只要结论，不要你查资料的全过程。
不过 10 月 Anthropic 自己又泼了盆冷水：When to fold subagents into your main agent loop 说很多场景下，一个主循环配上 skills 和按需加载的工具，比拆一堆子 agent 更快更稳。子 agent 是手段不是目的，别为了"多智能体"而多智能体。
这一幕"现在"到什么程度？给几个今年下半年的数据感受一下：
- Anthropic 10 月在 Redesigning source control at Anthropic 里说，他们每天合入的代码量从 5 月的约 2,500 次涨到 9 月的 3 万多次，而且源码系统的客户端几乎全是 agent，人反而成了少数派。
- JetBrains 8 月调了 1.5 万开发者：90% 的人每周都在用 coding agent，68% 每天用。
- Supabase 10 月的融资公告里说，平台上每周新建超过 100 万个数据库，其中约七成是 agent 建的。
我的体感是：agent 正在从"一个工具"变成"一类用户"。 这句话对做产品、做增长的人冲击挺大的——你的下一批用户，可能根本不是人。
要入门 agent，这几篇是公认的圣经：
- Anthropic：Building Effective Agents（必读，讲清楚了什么时候该用 agent、什么时候不该）
- Anthropic：How we built our multi-agent research system（多智能体怎么搭）
- OpenAI：A Practical Guide to Building Agents
但 agent 真用起来，会撞上一个新问题：它这一次跑得好，下一次不一定。 同样的任务，换个对话它就忘了项目规范，该跑测试的时候没跑，不该碰的文件碰了。你发现自己每次开工都在重复交代同样的东西。
问题又变了：从"怎么让它跑一次"，变成"怎么让它每次都跑得稳"。
第四幕：Harness Engineering——给它立规矩
这就是现在进行时。
今年 2 月 OpenAI 发了篇 Harness engineering，3 月 Anthropic 跟了篇 Harness design for long-running application development，4 月 LangChain 也写了 Your harness, your memory。到 9 月已经有人写年度综述了。词定下来了，一个公式也定下来了：
Agent = Model + Harness
Harness 这个词原本是马具、是测试里的"测试夹具"，意思都一样：套在模型外面、让它干活可控的那一整套东西。 具体拆开就是几样：
- 规则文件：项目规范、禁区、口径，写成文件每次自动加载，不用你每次重新交代。
- Skills：把"怎么干某类活"写成一份可复用的操作手册，agent 遇到对应任务自己翻。Anthropic 去年底把它做成了开放标准，10 月捐给了 Linux 基金会，70 多个平台已经接了。
- Hooks 和权限：哪些动作要先问人、哪些命令直接拒、改完代码自动跑什么检查。
- 记忆：跨对话留下来的东西，踩过的坑、你的偏好、项目现状。
- 评测：模型改了就跑一遍题库，别凭感觉说"好像变好了"。
你看，这一幕管的不再是"这一次任务的轨迹"，而是跨任务的制度。第三幕是放手让它开一趟车，第四幕是修路、画线、装红绿灯，让它每趟都开得差不多。
Anthropic 那篇有一句我觉得最值得记：模型越强，harness 里能删的东西越多。 今天你写的很多规则，是在补模型的短板；下一代模型来了，一半规则可能就不需要了。所以 harness 不是越厚越好，是要定期减。
至于我自己，这半年真正花时间最多的不是写 prompt，是在维护这套东西：规则文件、skills、hooks，还有一个每天晚上自动跑的复盘，把当天返工的地方记下来喂给第二天的自己。具体怎么搭我在这篇里写过，当时还没有 harness 这个词，现在回头看，那篇讲的就是 harness。
四幕背后其实是同一件事
把这四幕摆一起看，那条暗线就很清楚了——我们对模型的控制粒度，一直在往上放：
一句话（Prompt）→ 整个工位（Context）→ 整条自主轨迹（Agent）→ 跨任务的制度（Harness）
从"管好我说的每个字"，到"管好它看到的所有信息"，到"管好它自己跑的整个过程"，再到"管好它每次跑的规矩"。每一跳，我们都往后退一步、把更多东西交给模型，同时把自己的精力挪到更高的地方。
最后留一个我自己最受用的判断，也是最容易被忽略的一点：这四层不是替代关系，是嵌套关系。
harness 时代了不代表 prompt 就不重要了——恰恰相反，你写的每条规则、每份 skill，本身就是一段 prompt（第一幕）；它们什么时候加载、加载多少，就是 context 问题（第二幕）；而 harness 套着的那个循环，还是第三幕那个 agent。
所以真要学，顺序别反。先会把话说清楚，再会收拾桌面，然后才谈得上放手，最后才轮到立规矩。跳着学的人，搭出来的 harness 往往就是一堆没人读的规则，套着一个说不清话的实习生。
相关：工具越强，越要警惕自己的判断力被一起外包出去——关于怎么用 AI 提效的同时自己也真的在长，写在《AI 时代如何真正提升自己，而不是成为 Prompt 指令师》。