MCP

「Software is eating the world.」 —— Marc Andreessen, 2011 「Now, AI is eating software, and the question for the rest of us is: what’s left for one human, alone, in front of a screen?」 —— 我于 2026 年的某个凌晨，在台灯下问自己。 引：一个人需要变得多大 2026 年 2 月，我第一次完整地把一台「过夜 agent」跑通。 那天晚上我设了一个 Prompt，把它丢进 Claude Code 里循环，然后去睡觉。第二天早上 7 点，我打开屏幕看到的是：6 个 commit、4 个 PR、3 个失败但被自动回滚的尝试，和一封我自己都没读过的研究简报。 最让我震惊的不是它做了多少事。是它做这些事的时候，我没有在场。 那一刻我意识到，所谓「超级个体」不是一个口号，也不是「一个人当三个人用」的鸡汤。它是一个正在成型的结构——当模型层趋于商品化、当 harness 工程让单人有能力调度十几个并行 agent、当 Stripe / Carta / MIT NANDA 用硬数据告诉你这件事真的在发生——一个人能撬动的杠杆，正在以一种这个世代之前从未有过的方式被放大。 这篇文章不讲鸡汤。我把过去半年读到的所有素材——Stripe 的 AI 经济索引、Carta 的 2025 单人创始人报告、MIT NANDA 的 GenAI Divide、Foundation Capital 的 Service-as-Software 论文、Geoffrey Huntley 的 Ralph Loop、VILA-Lab 的 Claude Code 逆向、Sarah Tavel 的「sell work, not software」——拼成一张可执行的全景图。 ...

「与其说我们在写提示词，不如说我们在为模型布置一间房间——决定哪些东西摆进来、摆在哪、什么时候搬走。措辞只是房间里的一张便签，而我们真正在做的，是装修。」 如果你在 2024 年问我「怎么用好 AI」，我大概率会跟你聊提示词：怎么写指令、怎么设定角色、怎么给例子。但如果你今天再问我同一个问题，我的回答会完全不同。 因为这一年里，一线工程实践已经悄悄换了一个词——Context Engineering（上下文工程）。它不是提示词工程的升级版营销话术，而是一次重心的真正迁移：从「怎么把一句话写好」，转向「怎么决定模型在每一次推理时究竟看到什么」。 这篇文章想做两件事。第一件，用逻辑核把这门正在成形的学科拆开：它到底是什么、和提示词工程的边界在哪、有哪些已经在生产环境跑起来的设计模式。第二件，用感性核回到我自己——作为一个把 AI 当成环境而非工具、坚持 local-first 的人，我为什么认为上下文工程的尽头，是一条叫「世界线」的东西。 一、先把边界划清楚：Prompt 与 Context 不是同一件事 最容易混淆的，是把上下文工程当成「提示词工程的高级版」。它们确实相关，但不是同一层的东西。 Anthropic 在它那篇被广泛引用的工程文章里给了一个干净的区分：提示词工程是「编写和组织 LLM 指令的方法」；而上下文工程是「在 LLM 推理过程中，对最优 token 集合进行筛选与维护的一整套策略」——这个集合包括系统提示、检索到的文档、对话历史、工具定义、记忆，以及所有可能落进上下文窗口、但不属于「提示词」的信息。1 Andrej Karpathy 在 2025 年 6 月那条被反复转发的推文里说得更直白：「+1 支持用『上下文工程』取代『提示词工程』……这是一门精细的艺术与科学：用恰好正确的信息，填满下一步所需的上下文窗口。」2 而 Sourcegraph 在 2026 年的实践文章里，给了一个我特别喜欢的、可操作的判据： 「如果你在替换名词和形容词，你还在做提示词工程。如果你在改变 agent 检索什么数据、以什么顺序、用什么重排、以及当窗口被填满时淘汰什么——你在做上下文工程。」3 重心从「措辞（wording）」转向了「布线（wiring）」。 这一句话，是我读完所有材料后觉得最值得记住的。提示词工程关心的是字面；上下文工程关心的是管道——数据从哪进来、经过哪些处理、在窗口里待多久、什么时候被踢出去。 这不是文字游戏。当你的 agent 只是一个单轮聊天框时，写好一句话几乎就是全部工作。但一旦它有了工具、有了记忆、有了检索层，写提示词就只剩下整个系统里很小的一块；剩下的全是围绕它的上下文工程。 二、为什么是「工程」：上下文是有限资源，而且会腐烂 把它叫「工程」而不是「技巧」，是有硬道理的。因为上下文窗口不是一个越大越好的容器——它是一种有限资源，且边际收益递减。 Anthropic 的原话是：「上下文必须被当作一种有限资源来对待，它的边际收益是递减的。」以及——「好的上下文工程，意味着找到那个信息量最高的、最小的 token 集合，去最大化某个期望结果的可能性。」1 支撑这个判断的，是一个叫 Context Rot（上下文腐烂） 的现象：随着上下文窗口里 token 数量的增加，模型从中准确召回信息的能力反而下降。1 这背后有一个「注意力预算」的论证——注意力是 n² 的两两关系，窗口越长，每个 token 能分到的注意力越稀薄；Chroma 那份针对性的「针在草堆里」基准研究，也独立佐证了这一点。4 这里有个反直觉但关键的细节，Anthropic 自己也强调了：最小，不一定等于短。 你要的不是把上下文砍到最短，而是砍到「信息密度最高」——留下高信号的，扔掉低信号的。 对我来说，这一条把「Context is the bottleneck」从一句我一年前在自己笔记里写下的判断，变成了一个有物理基础的结论。瓶颈从来不在模型本身有多聪明，而在于：在这一次推理里，它有没有看到那条恰好正确的信息。 你给它一百万 token 的噪声，不如给它一千 token 的信号。 ...

「Agent loop 是 10 行代码，Agent engineering 是 10 万行代码。」 这句话我第一次读到时愣了一下，然后越想越觉得它锋利。它把整个领域里最大的一个错觉戳破了：很多人以为做 Agent 就是把 prompt 写好、把 LLM API 调通——而真正把一个 demo 推到生产、能在无人值守下安全跑一整夜的工程量，99% 都不在那个 loop 里。 这篇文章想做一件事：把 Agent Engineering 当成一门学科来拆，而不是当成一个教程。我不会教你怎么用 LangGraph，我想给你一张地图——这门学科由哪八根支柱构成、每一根填补了前一根留下的什么缺口、它的最小实现长什么样、又会在什么时候失效。读完之后，你看任何一个 Agent 框架、任何一篇大厂工程博客，都能立刻定位它在这张地图的哪个位置。 地图的素材，一半来自我自己造 Agent 系统时反复踩的坑，另一半来自 2025 到 2026 这一年里 Anthropic、OpenAI、Cognition、Manus、Temporal 这些一线团队公开出来的实践。我会尽量把每个关键论点的出处标清楚——因为这个领域里，错传的"事实"比真相传得更快，这一点我们马上就会撞上第一个。 一、那个被反复引用的数字：98.4% 先从一个流传极广的数字开始，因为它是这篇文章的标题，也是整个领域最好的一句开场白。 2026 年有一篇逆向拆解 Claude Code 的论文 《Dive into Claude Code》（VILA-Lab，arXiv: 2604.14228），分析对象是 Claude Code v2.1.88——大约 1900 个 TypeScript 文件、51 万行代码。它的摘要里有一段我愿意原样抄下来的话： 「系统的核心是一个简单的 while 循环，它调用模型、运行工具、然后重复。然而绝大部分代码，都活在这个循环周围的系统里：一个有七种模式和一个基于 ML 的分类器的权限系统、一条用于上下文管理的五层压缩流水线、四种可扩展机制（MCP、插件、技能、钩子）、一个带 worktree 隔离的子 agent 委派机制，以及面向追加的会话存储。」 注意这里有个重要纠偏：那个广为流传的精确数字「1.6% 是 AI 决策逻辑、98.4% 是基础设施」其实不在论文摘要里，它是二次概述时的渲染。而且网上很多人把它归给 minusx 的博客、或者"UCL 团队逆向泄露源码"——这些归属都是错的。minusx 那篇《Decoding Claude Code》写得很好，但里面根本没出现过任何百分比；论文也不是基于泄露源码，而是分析公开的 TypeScript。 ...