第7篇：上下文积累——智能体难以自然拥有的东西
系列：“我们构建了一条数万行代码的流水线。智能体为何做不到。”
快速要点
- 需求只有一句话，代码却写了数万行。中间那段距离，谁走过谁知道。
- 代码是沉淀物，不是第一现场——背后是无数次“这次又坏在哪里”。
- 工具能传递别人踩过的坑，但不能替你踩第一次。
- 选择难走的路，意味着进度评审里没有漂亮的进度条，而你自己也在怀疑自己。
- AI 在抬高门槛。问题不是“要不要用 AI”，而是“哪些东西只能靠在场才能长出来”。
上篇：第6篇——杠杆差距。那篇讲的是谁从 AI 中获得更多杠杆，以及职业阶梯怎样被重新排序。自然的追问是：那些杠杆到底从哪里来？答案之一，是上下文积累——智能体无法天然拥有的东西。这篇讲的是那个过程真实的样子——包括弯路、压力和怀疑。
一句话需求，一条真实的时间线
第四个月的时候，类似的场景反复出现：新的 MCP demo、开源数据采集框架的新功能、号称能自动编排任务的智能体方案，不断出现在各种讨论里。每次气氛都很兴奋。他却说不出话来——已经在这个问题里泡了四个月，搜索引擎 API 试过了，那个开源数据采集框架也研究过了，外部数据方案也评估过了——全不够用。但没法在三分钟内解释清楚为什么。更难开口的是：自己的方向也还没有被验证过，拿什么底气去质疑别人的热情？况且到那个时间点，所有方案——包括自己的——都还没有产出任何实质性的成果。在这种局面下开口说“这个恐怕不行”，听起来不像是在解决问题，更像是在挡路。
那一刻心里真正的感觉是：我是不是那个傻子，走了一条没人认同的路？
而最初的需求只有一句话：“从企业网站采集 ESG 信息。”
这种句子看起来总是很干净。你读完会觉得：有什么难的？写个爬虫，加个正则过滤一下，完了。实际上第一版也确实就是这么做的——而且 AI 在这一步真的能帮上忙。但后来发生了什么，比任何人预期的都乱得多。
三条弯路
第一条：搜索引擎 API
项目刚开始的时候，内部讨论的第一个方案其实是搜索引擎 API。逻辑很直觉：定义一个查询条件——比如“2025 某家大型科技公司 ESG report filetype:pdf”——然后调 API。简单，可解释，谁都能理解。几周后才发现问题：搜索引擎返回的结果少得可怕，而且会悄悄地把一家公司的报告当成另一家的。用户反馈了这个问题。整个方案需要重新思考。
但回头看，这次失败其实是有价值的。如果搜索引擎 API 真的能用呢？那当然好——但也意味着在这个环节上没有提供任何额外价值。排序算法不是自己的，不知道它怎么运作，也无法控制它。第三方方案能用的时候，它就是商品——该把精力放在别的地方。反过来，第三方方案不能用的地方，才是上下文积累的入口。
第二条：开源数据采集框架
差不多同一时期，一个当时很火的开源数据采集框架进入了视野。它看起来确实不错——用起来顺手，解决了执行层的很多问题。但很快就发现它解决的是“身体”的问题，不是“大脑”的问题——它能爬，但不知道该爬什么。而且自部署的开源版本太简陋（它们其实希望你买 SaaS 服务），JavaScript 渲染的网站经常失败。花了时间研究它的底层机制，终于理解了为什么它解决不了核心问题。更何况，在公司内部自行部署这个开源框架的 Docker 环境，光是内部沟通就耗掉了大量时间。后来也试过它的 SaaS 服务——本质上是把问题外包出去：用它的搜索端点，跟调搜索引擎 API 一样，黑盒，希望它能行——行不通的话，至少我们试过了，不是我们的问题。
第三条：外部数据供应商
外部数据方案也被反复摆到桌面上。同样的希望，同样的模式：展示材料强调数据多么完整、多么方便，听起来很容易让人兴奋。但如果外部数据真的够用，那自己正在走的那条路就没有存在的必要了——这个问题必须认真评估。这里有一层微妙的压力：推动新方案比深入验证数据质量更容易被看见；而真正去评估的人，如果得出“不够好”的结论，就很容易显得像那个挡路的人。尽管对自己的路线也有怀疑，反复评估仍然指向同一个答案：外部数据很好，前提是你接受它们不完整。把这个结论说出来，总有一种给热情泼冷水的不自在。
这不是三次独立的挫折。这是同一个事实的三个侧面：难的从来不是执行，而是定义问题。
那条难走的路
到了第四个月，不得不面对一个事实：必须回到最初的思路，从头开始建。把这个想法摆到桌面上——多数人觉得现有方案已经够用了，为什么要重头来过？这些反应都完全合理。但回答这些问题本身就是上下文积累的一部分——被迫去区分“商品化的数据”和“嵌入了判断力的数据”之间的差别，而这个区分在四个月前根本说不清楚。
但还是决定走这条路。因为如果不走，这条流水线就和其他 LLM 应用停在同一个水平——用起来不错，但没有任何真正的用户会拿它当生产工具。（后来用户对这条流水线和其他轻量封装方案的真实反馈，见 11——证据。）
这种压力不只来自技术层面。可预测的工程工作很容易被进度跟踪：ETL 管道、数据质量检查，都能拆成清晰的里程碑。但探索性工作天然不可预测：你不知道这周会撞上什么边缘案例，不知道哪条路是死胡同，不知道什么时候会有突破。选择了那条难走的路之后，进度评审里往往拿不出漂亮的进度条，而更可预测的项目持续交付看得见的东西。这不是流程的错——定期评审在它该适用的场景里很好用。但它确实让“在问题里泡着”变得更难被理解、更难被看见。
而心里的怀疑也在长——每次进度评审都像一次无声的拷问：你到底在干啥？你确定这条路是对的吗？
碎片开始连接
然后一些意想不到的东西开始接上。做学术研究的那些年没少和数据打交道——爬、清洗、解析，都是为了做研究顺手学的。这些年断断续续做的业余项目——爬虫、解析、自动化——原来都是在为这一刻做准备。那些碎片化的记忆突然串联起来，嗡一下就对上了。这就是上下文积累的另一面：它不总是线性的。有些上下文休眠了很多年，直到踩进一个刚好需要它的问题里，它才被激活。但前提是得在那个问题里。
但还是不够。基线版本开始跑，新的边缘案例一个接一个冲过来（那些案例 02 和 03 已经讲过，这里不再重复）。分类大脑是最难的部分。而这里又有一块休眠的上下文突然被激活了——在 LLM 还没有流行起来的那个时期，为了研究和发表论文，他花了很长时间挣扎着用 BERT 训练一个分类器。方法论完全不同，今天的 LLM 在分类上远比 BERT 强大。但那段经历留下的不是具体的模型知识，而是对“分类”这件事本身的直觉——边界在哪里会模糊，哪些特征真正重要，分类器什么时候会崩。“预算”和“优先级”这两个核心概念，是在又一次走投无路的失败之后、深夜睡前突然冒出来的。第二天早上迫不及待地把这个想法交给 Opus，几个小时后它交付了第一版代码。这个概念不可能在第一天就想到——它是失败的饱和度到了某个临界点后自然出现的。上下文积累最典型的产出方式：不是想得更用力，而是在问题里泡得够久。
在这个过程中，有一件事印象很深。对这个领域并不陌生——但跑了一批公司之后，还是专门向更有经验的人请教平时具体怎么找这些信息。对方随口提到的几个工作习惯和判断技巧，比任何 prompt 能给出的都有用。最有价值的上下文不是检索来的，也不是 prompt 问出来的——它只发生在你真的在场、而且问对了人的时候。
回头看
回头看，每一个方案都是合理的尝试，每一个都留下了一些东西。区别不在于谁的判断更好，而在于谁和问题待得更久。只在表层用过那个开源数据采集框架的人，未必会理解为什么它不够用——但这不是能力问题，而是接触深度的问题。后来的结果也很说明问题：外部数据方案在深入评估后仍然没有达到预期；而智能体框架从演示走向真实实施时，也遇到了远比 demo 阶段复杂的基础设施与治理约束。
这些结局不是巧合。它们背后是同一个很普遍的模式：大多数人对大多数工具的了解都停在“用过”的层面。在 AI 时代，这个模式的风险变大了——因为 AI 让“用过”变得前所未有地容易，而越容易的路，就越容易被 AI 标准化。反过来，那些难走的路——花几周去触碰边界、搞懂底层机制、在失败里积累判断力——恰恰是上下文真正生长的地方。
“用过”和“用几个月”之间的差距，就是上下文积累。
上下文是压缩过的历史
上面讲的是一段经历。但在这段经历里真正积累起来的东西，不是代码。代码只是最后的产出物。真正在增长的，是一层隐藏的判断力——由反复的失败、比较和与问题的接触慢慢压缩而成。这就是“上下文”。
考古学家挖出一面墙，能看到它比旁边的墙厚一倍。但只有建造者知道那年冬天发过一次洪水。墙还在，洪水的记忆消失了——除非有人把它写下来。代码就是那面墙。
很多人听到“上下文”就想到：更长的 prompt、更全的文档、更大的知识库。这些有用，但它们解决的是传递上下文，不是生产上下文。真正有价值的上下文是压缩过的历史：为什么 PDF 要延迟处理？为什么浏览器要级联降级？为什么某类链接宁可先跳过？每一条背后都是一次具体的失败。这些判断后来被写进了代码、阈值和停止条件——但在被写下来之前，它们只是很多轮失败留下的痕迹。代码是沉淀物，不是第一现场。系统长出来了，但生长过程中那些半意识的判断——“这条路走不通”、“这个模式见过”、“这里该停下来了”——并没有被写进任何文档。它们只存在于走过那段路的人身上。
工具在缩小差距，但不是魔法
上一节说这些判断只存在于走过那段路的人身上。但 AI 生态里不缺号称能解决这个问题的工具——MCP 把能力接到模型手上，RAG 让模型检索文档，长期记忆让模型记住上次的对话，harness 工程把提示词、护栏和工具编排成可复用的流程，智能体编排让多个模型协作。它们确实在缩小差距——但不是魔法。
能帮忙，但帮不完。工具能复用已经产出的上下文，但不能发起第一轮上下文的生产。MCP 能把已有的能力接到模型手上；不能替你发明能力边界。RAG 能检索已写下的信息；不能告诉你哪份文档本来该存在却没有出现。长期记忆能记住上一次的结论，但那个结论本身得有人先趟出来。智能体编排听起来很美——主智能体分配子任务，每个产出一个 MCP 技能，组合起来完成目标。但谁来定义“完整的 ESG 信息”对化学品分销商 vs. 石油巨头 vs. 日本电子集团分别意味着什么？这些工具都默认最难的那一步已经完成：有人先走过那片没有地图的地形。
LLM 的编码能力是真实的——这条流水线正在用 Claude Opus 4.6 重构，写的是生产级代码。但“把想清楚的方案写成代码”和“知道该写什么”是两件事。代码是翻译；判断才是原文。
把逻辑推到极端
Twitter 和朋友圈的时间线上从来不缺这类声音：智能体在颠覆一切，写代码已经过时了，AI 将取代所有工程师。其中一个反复出现的说法是，用某个智能体框架可以把效率提升 10 倍。但如果你问他们到底建了什么了不起的东西——这一点他们往往不会主动提——大概率不过是又一个前端页面，又一个贪吃蛇小游戏，又一个个人笔记或日历工具。有趣的是，这些恰恰是最标准化的场景——训练数据里有无数个几乎一模一样的例子，LLM 当然能做得很好。这不是“智能体能建任何东西”的证据，这是“LLM 擅长复现训练集中充分覆盖的模式”的证据。
不久前腾讯在自家楼前摆摊帮路人安装 OpenClaw，场面一度很热闹。但据说热度消退得也很快——一个每个微小任务都要调 LLM 的个人助手，用起来的新鲜感能撑多久，是个合理的问题。
好，那推到底：既然智能体什么都能建，为什么不建一个微信？十几亿用户，市场验证过了。
建一个微信需要什么？十亿级消息的实时投递与必达保证、金融级别的支付系统与风控、小程序运行时——本质上是应用里嵌套的应用平台、朋友圈的推荐算法与内容审核、音视频通话的实时编解码、跨平台多设备同步。每一项背后是多年的工程积累和无数次在真实规模下踩出来的教训。
或者不用那么极端——建一个通用搜索引擎？搜索引擎本质上做的事和这条 ESG 采集流水线差不多：在混乱的网页世界里找到相关内容。只不过搜索引擎的规模是全网，这条 ESG 流水线只是一个垂直切面。即便这么一个“小”问题，也需要数万行代码和数月的上下文积累。
微信的例子当然极端。没有人真的期待智能体从零造出微信。但它暴露了一个平时被忽略的断层：从“能写代码”到“能建系统”，隔着的正是上下文积累——问题越复杂，鸿沟越宽。
不过——这里必须诚实——这并不意味着 AI 的威胁不真实。06 已经说过：杠杆差距正在重新排序整个职业阶梯。AI 可能无法从零构建微信，但它已经在压缩大量中间层的工作。
炒作说“智能体取代工程师”。现实没那么简单：AI 在抬高门槛。而门槛抬高之后，上下文自然分成了两类——一类可以被沉淀进系统，让 AI 顺畅地使用；另一类不能，只能靠长期待在问题里才会长出来。前者是工程任务：做好了，AI 的能力边界就往外推一圈。后者是这篇文章真正想说的东西。
为什么 LLM 结构性地做不到这件事
上下文积累难以被替代，不只是经验观察——背后有一个机械层面的原因。
想象一台收音机同时播放所有电台。你听到的是所有声音的平均值：有时候惊艳，但永远模糊。大语言模型裸跑时的状态就是这样——整个互联网的统计平均值。
说白了，LLM 是概率机器。从 2017 年《Attention Is All You Need》那篇论文到今天，每一步都是可追溯、可复现的工程——不是魔法，不是意识，更不是某些标题暗示的“类人情感”。但大多数人不是从论文开始认识 LLM 的——他们是从 ChatGPT 的新闻标题开始的。就像计算机曾经让上一代人觉得不可思议，LLM 让这一代人觉得不可思议。惊叹是合理的：它确实在深刻地改变工作方式。但它是人类造出来的技术，不是降临的奇迹。理解这一点，才能看清它的边界在哪里——也才能看清上下文积累为什么不在那个边界以内。
上下文工程（05B 已经展示过它的具体做法）做的事，是把旋钮调到一个具体的频率：跟你的问题最相似的那部分训练数据。准备的上下文越精确，模型调用的“电台”就越对。MCP、智能体框架、harness 工程——本质上都是调频旋钮：把已经积累出来的上下文，在正确的粒度上交给模型。
但旋钮能调的前提是：有人先知道该调到哪个频率。那个频率就是上下文积累的产物。
价值不在模型的原始输出——在调教那个输出的工程。模型是引擎；工程是方向盘、路线图和护栏。
这个机制在实践中长什么样子
抽象说完了。它落到具体工作里是什么样的？
一个观察角度：看看手上正在做的工作，它大致会分成两堆——
- 一堆是可以写成规则、流程、prompt、检查清单的——也就是可以喂给 LLM 的上下文。 这些是可以沉淀进系统的上下文。做好了，AI 就能用——而做这件事本身就很有价值，也许团队里还没有人意识到这些可以被结构化。但这里有一个令人不安的悖论：前面花了那么多篇幅解释为什么 AI 建不了这条流水线，可一旦它被清晰定义、结构化、沉淀进了系统——它就变成了标准化的东西。标准化的东西就是商品。商品的命运是被替代。不过说实话，光是把第一堆真正结构化好，对大多数团队来说就是好几年的事——大部分机构甚至还没开始。窗口期比恐慌暗示的要长，但不是无限的。这里有一个讽刺：谁先把自己的上下文结构化好，谁就先被 AI 放大——但放大的同时，也在加速瓦解现有的工作方式。
- 另一堆是说不清楚、写不成文档、甚至不是主动“学”来的。（这里说的是领域直觉和技术判断力——组织政治和人际管理是完全不同的维度，比这里讨论的复杂得多，不在本文范围内。）它更多是靠待在问题里、参与讨论、留意周围正在发生什么而慢慢长出来的。比如“这类公司的网站通常把 ESG 信息藏在哪里”、“这种格式的 PDF 大概率是旧版报告”、“这个指标突然变化往往意味着什么”。这些不是坐下来决定要学的——而是因为在场、因为关注、因为参与，才逐渐变成判断力的一部分。这些是 AI 暂时够不到的地方——也是值得有意识地去靠近的地方。
这个模式本身是一个循环：结构化上下文 → 变成商品 → 下一个未被结构化的问题浮出水面 → 再结构化 → 再变成商品……这个循环目前看不到终点。说起来有点沉重，但说实话，它就是一个绕不开的现实——也不是什么新事。工业自动化、离岸外包，同样的循环已经转过好几轮了。这次不同的是速度，以及它切进的是更靠近判断力的那一层。它具体意味着什么——什么可以委托，什么不能，怎样找到那条线——是后面几篇（08A、08B）的主题。
系列目录
| 篇目 | 核心观点 |
|---|---|
| 00 — 引言 | 这个系列为什么存在 |
| 01 — 不可能的任务 | 一切的起点 |
| 02 — 7400+ 行代码是怎么来的 | 流水线是怎样滚雪球的 |
| 03A — 大脑与身体 | LLM = 10% 大脑，代码 = 90% 身体 |
| 03B — 六个看起来简单的问题 | 让智能体翻车的边缘情况 |
| 04 — 诚实的对比 | 流水线 vs 智能体，用数字说话 |
| 05A — 研究到底说了什么：数据篇 | METR 的可靠性断崖，Anthropic 的劳动力研究 |
| 05B — 研究到底说了什么：框架篇 | Karpathy、SWE-CI、长尾、汇聚 |
| 06 — 杠杆差距 | 谁真正从 AI 中受益 |
| 07 — 上下文积累 | 你在这里 |
| 08A — 委托问题 | 为什么你不能直接丢给它 |
| 08B — 自主性光谱 | 找到合适的级别 |
| 09 — 另一个极端 | 当怀疑变成瘫痪 |
| 10 — 两个房间 | Demo 狂热者 vs 领域怀疑论者 |
| 11 — 证据 | 流水线作为证据 |
| 番外 — 反方论点 | AI 反驳整个系列 |
| 番外 — 站在中间地带 | 半夜醒来的那个念头 |
参考资料
- Vaswani, A. 等。 “Attention Is All You Need.” 2017。
- Business Insider. “I Went to an OpenClaw Installation Event at Tencent’s Office.” 2026。