佬友们好久不见，正本清源系列恢复更新，让咱们直接进入正题，文章较长各位慢慢观看
一个普遍的感受是：AI 工具越来越多，混乱到让人焦虑。昨天学的 prompt 技巧今天已经过时，RAG 还没搞清楚 agent 又冒出来，agent 还没用熟练 MCP 又成了标配，MCP 没摸透 harness 又被推上舞台。每一波浪潮都宣称自己是"真正的答案"，而上一波的东西顺理成章被贬为"过时的玩法"。
但如果你把时间拉长来看这条路径，会发现它不是随机堆积的。它有一个清晰的内在逻辑。每一层新范式都在解决上一层自己制造出来的瓶颈。看懂这个演化路径，比学会任何一个具体工具都重要——因为它决定了你该站在哪一层用力。
这篇文章想做的，是沿着时间线把每一波浪潮拆开：当时人们在和什么问题搏斗？这个问题的根源是什么？解决它的过程又制造了什么新问题？然后回到一个更根本的问题——作为一个 AI 使用者，你该如何学习、该如何优化、该如何在这片工具废土里找到自己的站位。
2022：Prompt 作为一种发现
2022 年 1 月，Google Brain 的 Wei 等人发表了 Chain-of-Thought 论文，证明了一件今天看来近乎废话的事——如果你让模型把推理步骤一步一步写出来，它在多步问题上的表现会显著提升。据 Google 在 PaLM 上的测试，这一简单变化让模型在 GSM8K 数学推理基准上达到了当时的最好成绩。几个月后 ChatGPT 发布，整个世界突然意识到"怎么跟模型说话"是一门可以学的手艺。
但今天回看，prompt engineering 的真正意义不是那些"技巧集合"。few-shot、chain-of-thought、role prompting——这些范式有效的本质原因是它们逼着使用者把一个模糊的问题翻译成精确的指令。它们在做的事情，是把"人没把问题想清楚"这个底层缺陷暴露出来，然后用技巧绕过去。
这个时期真正被验证的，是一个被低估的事实：模型对精确描述的敏感度极高，对模糊表达的容错极低。在这个约束下，任何能让使用者被迫变精确的机制都有效。而这些机制里最有效的那几个，后来被抽象成了可传授的技巧。
这个阶段留下的最大遗产不是某个 prompt 模板，而是一个认知起点——你的表达精度本身就是生产力。但这个认知很快就撞上了它自己的天花板。
2022 年底到 2023：推理是可以被"拉长"的
Chain-of-Thought 证明一件事之后，很自然地衍生出下一个问题：如果让模型把一步推理变成多步有用，那么让它把多步推理变成树状搜索、图状探索，是不是更有用？2023 年初，Yao 等人的 Tree-of-Thought 给出了肯定答案——让模型在每一步都枚举多个可能的"思路"，然后用搜索算法遍历这棵思维树。之后又有 Graph-of-Thought、self-consistency 等一系列变体。
表面上看，这一阶段是 prompt engineering 的深化。但它真正传递的信号是另一件事：模型的推理能力不是一个静态的量，而是一个可以通过外部结构来放大的量。同一个模型，在线性 prompt 下可能答错，在树状 prompt 下可能答对。差别不在模型，在你给它搭的"思考脚手架"。
这个发现的深层含义，到后来才被完整消化——我们看到的不是"模型变聪明了"，是"在适当的结构下，模型能表现出的推理水平比它在单轮对话里显露的要高得多"。ToT 和 GoT 本身并没有直接成为今天主流 agent 架构的骨架——后者更多是 CoT 加工具调用的结合体——但这一阶段留下的那条认知在后来被反复验证：怎么围绕模型搭一个好的工作流程，常常比选什么模型更决定结果。
2023：RAG 和 agent，向外部世界开口
到 2023 年，人们开始撞上 prompt 层面解决不了的问题。模型不知道你公司的文档、不知道今天的新闻、不能查数据库、不能执行代码。你把 prompt 调到天上去也没用，因为它答不出它不知道的事。
两条路同时被走通。一条是 RAG（Retrieval-Augmented Generation）：在生成之前先去检索相关文档，把结果塞进上下文。另一条是 agent + tool use：让模型能调用外部工具，自己去搜索、去执行、去查询。2023 年 Yao 等人的 ReAct 论文把这两件事缝在一起——让模型交替进行"思考"和"行动"，先推理下一步该干什么，再调用工具获取信息，再根据结果继续推理。6 月 OpenAI 推出 function calling，把 agent 能力下沉到 API 层。同年 AutoGPT、CAMEL 等多 agent 实验把这条路推到极端，LangChain 顺势成了构建 agent 系统的事实标准框架。
这一阶段的技术细节很丰富，但内核只有一个问题：模型的智能被它的"信息封闭"严重限制了。训练数据截止之后的事它不知道，你桌面上的文件它看不到，生产环境的数据库它连接不上。解决这个问题需要的不是更好的模型，是更宽的接口。
但这条路走出来之后，马上显露出新的代价。每接入一个工具都要写自定义集成，每个框架有自己的一套约定，不同模型供应商的 function calling 格式不一样，同一个能力在 LangChain 里是一种写法、在自研系统里又是另一种。工具越多，维护成本呈平方级增长。这个问题后来被 MCP 的叙事正式命名为 N×M 集成问题——N 个模型、M 个工具，每一对组合都可能要写一遍。
2024：MCP 是标准化的必然
2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP），把 agent 接入外部工具的方式标准化了。概念其实很朴素——定义一套协议，让工具提供方只实现一次 MCP 服务端，模型和客户端就都能使用；反过来，客户端只对接 MCP 规范，就能连上生态里任何遵循该协议的工具。这个设计和 Language Server Protocol 的思路是同构的——用一层标准协议把 N×M 问题降维成 N+M。
MCP 推出之后的一年，生态扩展得非常快。Anthropic 官方数据显示，到 2025 年末已经有超过 75 个连接器直接挂在 Claude 上，MCP 的 Python 和 TypeScript SDK 每月下载量合计超过 9700 万。OpenAI、Google DeepMind、Microsoft 相继加入，协议最终被捐给 Linux Foundation 下的 Agentic AI Foundation。它成了这一代 agent 基础设施的公共底座。
MCP 层面真正在解决的问题，其实不是"怎么用 AI"，而是"怎么让 AI 的使用不重复造轮子"。它是一个工程范畴的胜利，不是 AI 能力范畴的胜利。这一点很关键——很多人看到 MCP 被热捧，以为自己也该去学 MCP，但如果你根本还没到需要编排多个工具的阶段，MCP 对你不会产生任何边际价值。它是为那些已经感受到 N×M 疼痛的人准备的。
2025：Context engineering，承认窗口是幻觉
到 2025 年，另一个反直觉的事实开始被广泛接受：上下文窗口不是越大越好。
早期人们默认，如果模型能看到 100 万 token，那就把所有可能相关的东西都塞进去，让模型自己挑。现实是，窗口一旦超过某个阈值，模型从长上下文里准确召回信息的能力反而下降——研究者把这种现象命名为 context rot。SWE-rebench 的维护者观察到模型性能在 100 万 token 附近会撞上一道硬墙，再往后不管窗口技术上支持多少都会明显劣化。塞得越多，模型越走神。Databricks 的一项研究甚至在 32K token 附近就观测到了明显的精度下降。
这个认识直接催生了 context engineering 的概念。2025 年 9 月，Anthropic 在官方工程博客里把它定义为 prompt engineering 的自然延续，关注的焦点从"如何措辞一条指令"变成了"如何配置模型在每一步推理时能看到的信息"。同时期，Gartner 发布报告称 prompt engineering 正在被 context engineering 取代；Andrej Karpathy 和 Shopify 的 Tobi Lütke 在社交媒体上公开支持这个转向。按 DataCamp 的测试数据，合理的上下文管理能在 agent 基准上带来 54% 的性能提升。
这一阶段真正在解决的问题是：模型的注意力是有预算的。和人一样，给它看的东西越多，它能给每一部分的关注就越少。好的使用不是最大化给它的信息，是精准地给它最少但最必要的信息。这和 prompt engineering 时代的"把话说清楚"其实是同一个原理的升级版——当年是一句话的精度，现在是整个上下文窗口的精度。
现在：Harness 是让模型能"做事"的基础设施
走到 2025 年底、2026 年初，我们来到了目前这个阶段——harness 时代。Claude Code、Cursor、Aider 这些工具被统称为 harness，不是因为它们把多次使用串起来，而是因为它们把一个只能"说话"的模型包裹进了一整套"能做事"所需的基础设施：文件系统访问、shell 执行、工具调用原语、权限和确认机制、错误回退、长任务的状态编排、多 agent 之间的协调通道、跨会话的记忆文件。语言模型本身只能产出 token，harness 负责把这些 token 翻译成对真实世界的动作，再把真实世界的反馈翻译成模型能理解的输入。
harness 要解决的问题也是前几代自己制造出来的。agent 能力足够强、工具链足够完备、上下文管理足够讲究之后，单纯的"模型 + 几个工具"已经不够用——你需要一个能让模型在真实环境里持续工作的运行时。它要决定什么操作需要用户点头、什么可以静默执行；要在工具失败时选择重试还是回退；要把一个长任务拆分成子 agent 并回收它们的结果；要在会话中断后恢复到接近中断前的状态。这些需求单独拎出来每一个都不新鲜，合起来才构成 harness 这一层。
但 harness 层本身也在迅速制造下一代问题。我自己配置过一整套 Claude Code 的定制化设施——全局规则文件、领域规则文件、subagent、slash 命令、跨会话记忆——每一个单独看都合理，但组合起来之后，系统的维护成本和认知负担开始吃掉它带来的收益。你花在记忆"每个组件的状态、每个配置的影响范围、每次更新可能的连锁反应"上的时间，开始和它节省的时间打平。harness 是一把双刃剑——它让复杂协作成为可能，也让简单任务变得复杂。
贯穿所有阶段的模式
现在站到高处俯瞰这条路径，会看到一个清晰的循环结构。
每一个时代都是这样的：某个瓶颈暴露出来，有人发明了一套新范式去解决它，这套范式确实有效，于是被广泛采用并成为行业标准。但这套范式在运行过程中必然消耗一些新资源——更多的 token、更多的集成、更多的调用、更多的协调开销。消耗积累到一定程度，就暴露出下一个瓶颈。然后下一波人又站出来，发明下一套范式。
prompt 解决的是"模型不理解你要什么"；推理链解决的是"模型一次想不了那么多"；RAG 和 agent 解决的是"模型不知道/做不了外部的事"；MCP 解决的是"每个工具接入都要重写一遍"；context engineering 解决的是"信息多了反而更糟"；harness 解决的是"模型只能说话，不能直接在真实环境里做事"。
每一步都是合理的，每一步也都是局部最优。但连起来看，你会意识到没有任何一个阶段是"终极答案"。每一层都在处理上一层的溢出。而那些宣称自己是终极答案的范式，无一例外地在下一两年内被发现有自己的天花板。
这给使用者的启示其实很简单：如果你不理解一个新范式在解决什么问题，就不要急着采用它。采用一个为解决你还没遇到的问题而设计的工具，是在用复杂度换一个你用不上的能力。
该如何学习，该如何优化
面对这条路径，合理的学习策略不是"从下往上把每一层都学一遍"，也不是"只学最新的那一层"。合理的策略是先诊断自己的真实瓶颈在哪一层，然后集中学那一层和它相邻的一点。
诊断瓶颈的方法也不复杂。你观察自己最近几次和 AI 协作的失败案例，问一个问题：这一次失败，是因为模型误解了我的意图，还是因为模型缺少相关信息，还是因为模型无法调用某个工具或执行某个动作，还是因为任务规模大到单次对话已经撑不住——需要长时运行、权限控制、多个子 agent 分工、跨会话状态？这四个答案分别指向 prompt 层、context 层、agent/tool 层、harness 层。把失败案例分个类，看分布在哪里集中，你就知道自己该去哪里用力。
一个推论是，大多数人其实应该在更低的层上停留更久。如果你的 AI 使用还处于"偶尔模糊、不知道怎么问"的阶段，你不需要 MCP、不需要 harness、不需要 agent framework——你需要在 prompt 和 context 层练更多次。反过来，如果你已经在每天处理几十个并行任务、需要让 AI 维持跨周的上下文、要协调多个工具链，那么 prompt 技巧对你边际收益极低，你真正该投资的是 harness 和工作流。
还有一个常被忽略的维度——工具的门槛不等于它的价值。很多人看到业界在谈 context engineering 就去学，以为这是"更高级"的东西。但 context engineering 只对那些已经建立了 agent pipeline、并且因为 token 预算在挣扎的人有意义。对一个日常用 AI 写邮件的人来说，context engineering 是过剩的复杂度。
真正重要的，是在每一次工具选择的时候问自己两个问题：这件工具要解决的问题，我已经遇到了吗？如果没有它，我今天的工作会不会真的卡住？如果两个答案都是"否"，这件工具就不是你现在该学的。它可能很好，但不是你的。
一句话
从 prompt 到 harness 的演化，不是一条从原始到高级的阶梯，而是一系列针对不同瓶颈的专门解决方案。它们共同构成了一个工具栈，每一层都在解决具体的问题。
作为使用者，你真正需要做的不是追着每一层的新名词跑，而是搞清楚自己当前撞在哪一层的天花板上，然后精准地在那一层用力。看懂了这个演化逻辑，工具的"混乱"就不再混乱——它只是一张地图，你需要的是知道自己站在哪里。
这件事的残酷之处在于：地图看懂之后，大多数人会发现自己的瓶颈比想象中低得多。但这恰好是好消息——因为越低层的瓶颈，通常越容易突破。
2 个帖子 - 2 位参与者