核心内容摘要
78穿13：数字里的奇迹，命运的齿轮如何转动
文章系统介绍了AI agent开发中的context engineering概念分析了海量工具调用和长推理导致的上下文管理瓶颈提出了五大解决方案转移(Offload)、压缩(Reduce)、检索(Retrieve)、隔离(Isolate)和缓存(Cache)。
结合The Bitter Lesson启示探讨了在模型能力快速迭代背景下如何通过精简结构和通用方法构建高效AI agent为开发者提供了实用的context管理策略。
Context Engineering 是什么很多人认为 2025 年是 agent 元年但在实践中开发者普遍发现虽然 agent 的搭建流程看起来简单但要让整个系统高效运行却非常困难context 管理是其中的关键瓶颈。
今年 6 月Karpathy 发布一条篇推文正式提出了 context engineering“filling an LLM’s context window with just the right information for the next step在大语言模型的上下文窗口中放入正好适合它执行下一步所需的信息”这个概念迅速引起了众多开发者的共鸣。
Karpathy 发布的推文Chroma 的联合创始人 Jeff Huber 认为 context engineering 本质上是 AI engineering 的一个子集核心在于每次调用 LLM 时都要明确哪些信息需要放入 context window这其实包含了两个循环**•**内循环inner loop即时筛选明确当前结果生成所需的 context•外循环outer loop长期优化通过迭代确保 context window 始终只包含相关信息。
Chroma 是一家 AI 初创公司核心产品是开源向量数据库 ChromaDB可以为 AI 应用提供高效的数据检索和存储解决方案。
为什么需要 context engineeringPrompt engineering 是 context engineering 概念的子集和早期形式。
ChatGPT 这样的 Chatbot 主要依赖人类输入因此优化 prompt 非常重要。
但在构建 agent 的过程中输入的 context 不仅来自人类指令还来自 agent 运行中的工具调用和检索的多元信息这时 context engineering 就变得格外重要。
随着工具调用的次数越来越多agent 会动态生成大量新的需要管理的 context。
Manus 团队在技术博客中指出一个典型任务通常需要约 50 次工具调用。
Anthropic 的一个 multi-agent 研究也表明生产级 agent 在运行时甚至可能需要多达数百次工具调用Lance Martin 在开发开源 AI 研究助手 Open Deep Research 这个项目时发现agent 每次工具调用都会消耗大量 token如果不对此进行优化单次运行可能就要消耗 50 万个 token成本会达到
美元。
Manus 在官方发布的《AI 代理的 context 工程构建 Manus 的经验教训》中表示Manus 中的一个典型任务平均需要大约 50 次工具调用。
这是一个很长的循环——由于 Manus 依赖 LLM 进行决策它很容易偏离主题或忘记早期目标尤其是在长上下文或复杂任务中。
通过不断重写待办事项列表Manus 将其目标复述到上下文的末尾。
这将全局计划推入模型的近期注意力范围内避免了丢失在中间的问题并减少了目标不一致。
实际上它使用自然语言来使自己的注意力偏向任务目标——而不需要特殊的架构变更。
而且如果每次工具调用产生的 context 都直接传入模型很快就会触及 LLM 的 context window 上限。
Chroma 在 7 月发布的报告Context Rot: How Increasing Input Tokens Impacts LLM Performance显示随着 context 长度增加模型的注意力会分散推理能力也会随之下降。
Jeff Huber 把这种现象称为 context 衰减context decay他甚至认为当前大多数出色的 AI 初创公司或 AI native 应用的核心能力实际上就是 context engineering。
Source: Chroma,Context Rot: How Increasing Input Tokens Impacts LLM PerformanceClaude Sonnet 4, GPT-
1, Qwen
B, and Gemini
5 Flash on Repeated Words Task总而言之简单 agentnaive agent在实际运行时往往陷入双重困境它必须要处理几十到上百次工具调用累积出来的大量 context它在面对过长 context 时不仅可能因超出 context window 而无法继续运行还可能容易发生 context decay 让模型能力下降。
正是这些痛点催生了“context engineering”这一新方向目标就是在 agent 的构建过程中通过精心设计和选择传递给模型的 context 来提升模型的效率和效果。
围绕这一目标学界和业界提出了多种方法其中比较具有代表性的做法可以归纳为五类Offload转移、Reduce简化、Retrieve检索、Isolate隔离和 Cache缓存。
context engineering 的五种方法
方法一Offload 转移Lance Martin 在 Latent Space 的分享中提到 offload context 有以下用法使用文件系统来记录笔记使用文件系统如 todo.md来规划/跟踪进度使用文件系统读写 token 占用很大的 context使用文件来存储长期记忆。
Offload 方式如前文所述基础版 agent 在执行过程中会进行多次工具调用每一次调用的结果都会直接传回给 LLM这导致所有 context 也会被完整传入 LLMcontext window 会迅速膨胀token 消耗过高效率也会下降。
为了解决这个问题Manus 认为 offload context 是非常重要且有用的。
Offload context 的核心思想在于 agent 不必在每次工具调用时都把完整的 context 原封不动地传回模型而是可以将这些信息转移到其他形式。
最常见的方式是把文件系统当作一种外部 memory。
在这种模式下agent 仅会给模型返回一个摘要或 URL 作为标识模型只在需要时才会调用这些外部存储的内容而不是一直持有全部原始 context因此这种方式能够显著优化资源利用率使得 agent 运行更高效、更具扩展性。
offload context 运行原理有一个值得关注的问题是应该如何在 context 中保留足够的摘要或元数据让模型能够理解被 offload 的内容到底包含什么。
尤其是在 deep research 时agent 往往需要 offload 整页的内容因此必须要生成一个有效的摘要来描述文件中的信息prompt engineering 在其中起到了非常重要的作用用户可以通过反复打磨 prompt让摘要在能够覆盖文档核心信息的同时实现显著的内容压缩。
•以 Open Deep Research 为例Lance Martin 表示在实践中Open Deep Research 生成摘要的方式是通过精心设计的 prompt 来引导模型产出一份详尽的要点将文档的核心信息逐条列出。
这样不仅能在信息压缩的过程中尽量保持内容的准确还原还能让 LLM 在必要时判断是否要调取完整的 context。
**•**Cognition 在Don’t Build Multi-Agents这篇博客中强调摘要生成是一个值得投入大量精力的环节不能被简单对待。
他们甚至提出可以用微调模型fine-tuned model专门来做摘要工作。
虽然 Cognition 当时的语境主要是讨论 agent 边界和历史消息摘要但 Lance Martin 认为这个逻辑同样适用于由工具调用产生的大量 context核心目标始终是让模型清楚 context 里有什么。
Source: Cognition,Don’t Build Multi-Agents
方法二Reduce 压缩Lance Martin 在 Latent Space 的分享中提到reduce context 有以下几种用法和
注意事项
总结 agent 的消息历史剪裁消息历史中不相关的部分对工具调用的输出进行
总结或剪裁在 agent 之间交接时进行
总结或剪裁但要小心信息丢失Reduce 用法和
注意事项Context reduce 指的是通过摘要summarization、剪裁pruning等方法来减少 context 所包含的内容。
一个典型场景是当 Claude Code 里 95% 的 context window 都被占满时系统会自动触发 reduce 机制。
context reduce 运行原理但 context reduce 也存在风险。
Manus 认为如果 reduce 是不可逆的将可能会导致严重的信息丢失这也是 Manus 选择使用 context offload 的原因先将工具调用的完整结果 offload 到磁盘保存确保原始数据不丢失然后再进行 reduce即使 reduce 后的信息是有损的仍然可以随时回溯原始 context。
Cognition 也强调摘要生成必须非常谨慎如前文所述他们甚至认为可以用微调模型fine-tuned model专门来做摘要来确保关键信息不会遗漏。
Manus 在官方发布的《AI 代理的 context 工程构建 Manus 的经验教训》中表示许多代理系统实现了上下文截断或压缩策略。
但过度激进的压缩不可避免地导致信息丢失。
这个问题是根本性的代理本质上必须根据所有先前状态预测下一个动作——而你无法可靠地预测哪个观察结果可能在十步之后变得至关重要。
从逻辑角度看任何不可逆的压缩都带有风险。
这就是为什么我们在 Manus 中将文件系统视为终极上下文大小不受限制天然持久化并且代理可以直接操作。
模型学会按需写入和读取文件——不仅将文件系统用作存储还用作结构化的外部记忆。
我们的压缩策略始终设计为可恢复的。
例如只要保留 URL网页内容就可以从上下文中移除如果沙盒中仍然保留文档路径则可以省略文档内容。
这使得 Manus 能够缩短上下文长度而不会永久丢失信息。
在开发这个功能时我发现自己在想象**状态空间模型State Space Model SSM**在智能体环境中有效工作需要什么条件。
与 Transformer 不同SSM 缺乏完整的注意力机制并且在处理长距离的后向依赖关系时表现不佳。
但如果它们能够掌握基于文件的记忆——将长期状态外部化而不是保存在上下文中——那么它们的速度和效率可能会开启一类新型智能体。
基于 SSM 的智能体可能是神经图灵机真正的继任者。
Manus 官方发布的《AI 代理的 context 工程构建 Manus 的经验教训》考虑到不同任务场景对 context reduce 的要求可能并不相同有一个值得讨论的问题是 context reduce 是否应该保留 agent 之前的错误路径wrong paths。
有观点认为如果错误路径被保留下来agent 可能会不断重复相同的错误操作因此必须去掉错误信息明确告诉 agent 不要再沿着错误方向继续下去而是需要去尝试新的方法。
**•**Drew Breunig 在文章How to Fix Your Context中表示模型产生的幻觉如果被写入 context就会持续污染 agent 的后续决策**•**Gemini 在技术报告中也记录了相关案例比如 Gemini 在玩宝可梦游戏时出现了幻觉这会导致 Gemini 在后续的步骤中不断偏离正确方向。
Source: Drew Breunig,How Long Contexts Fail但从工程角度看判断应该什么时候在消息历史中移除错误记录往往是非常复杂的这会加大 agent 框架agent scaffolding/harness的逻辑负担和维护成本。
因此有人认为与其增加这种复杂性不如直接保留错误信息。
此外还有观点认为保留错误信息可以让 agent 在下次行动时根据错误调整自己的行为比如在 coding 场景中agent 需要持续构建和修改代码保留较完整的历史信息通常能提升模型表现即便是在代码修改任务里模型如果能理解早期的决策依据整体效果会更好•Manus 认为保留错误能让 agent 从失败中学习•Claude Code 会打印错误日志并在后续过程中利用这些日志进行调整。
方法三Retrieve 检索 Memory 记忆Lance Martin 在 Latent Space 的分享中提到retrieve context 有以下几种用法结合多种检索方法并进行重排序构建系统将检索结果组装进提示词中基于工具描述检索相关工具。
Retrieve 用法Retrieve context 指的是从外部资源比如知识库、历史对话、文档、工具输出等检索与当前任务相关的信息然后把这些检索到的内容加入到模型的 context 中来辅助模型生成更准确、可靠的输出。
Retrieval 的出现时间虽然早于 context engineering但已经成为 context engineering 的重要组成部分。
其中RAG 就是一种传统检索方法用经典的向量检索或语义检索。
比如 Windsurf 从引擎设计的角度切入先根据精心设计的语义边界把代码拆分成独立的代码块并为这些代码块生成向量嵌入embedding然后利用语义相似性向量搜索来完成检索。
但 Windsurf 并不只依赖这一手段还会结合传统的 grep 搜索甚至构建知识图谱最后将所有检索结果统一排序和整合形成了一个典型的复杂、多步骤 RAG 流程。
grep 搜索全称为 global regular expression print是一种基于字符串匹配的文本搜索方法能逐行扫描文件内容查找与给定正则表达式或关键字匹配的结果。
还有一种方法是通过调用简单的工具例如 grep在文件中进行探索式搜索poke around files完全绕过了传统机制方式非常简洁效果却很好有些团队甚至公开表示他们只做抓取scrap不做索引indexing比如在 Anthropic 负责 Claude code 的 Boris Cherny 就表示 Claude Code 完全没有做任何索引只依靠生成式检索。
为了系统比较不同方法的效果Lance Martin 在今年 4 月设计了一次基准测试核心问题是如何在多语言文档中实现有效检索。
测试内容包括 20 个与 LangGraph 相关的编码任务不同的 coding agent 需要依靠文档检索来生成 LangGraph 代码。
对比对象为 Claude Code 和 Cursor采用的检索方法分为三类经典向量检索将有约 300 万 token 的文档导入向量数据库再通过标准向量搜索完成检索文件工具检索基于文本文件和简单文件加载工具的检索更接近生成式搜索做法是提供一个包含所有文档 URL 和简要描述的 Markdown 文件让 agent 可以借助工具调取所需文档context 填充context stuffing直接将全部约 300 万 token 的文档一次性输入到 coding agent 的 context 中。
结果表明在特定测试场景下第二种方法效果最佳。
在第二种方法下agent 会先根据 Markdown 文件的描述判断需要调用哪些文档再逐步调取并阅读最终生成正确代码。
这个结果也印证了 Anthropic 的 Boris 的观点为 LLM 提供基础文件工具的访问能力并通过文本描述让它能够理解文件内容往往就能取得良好效果。
同时这种做法还避免了复杂索引所带来的高成本和高维护负担。
Lance Martin 后来长期采用这一方法他认为仅依靠文本和简单搜索工具并结合 Claude Code就能满足大部分检索需求。
Latent Space 主持人 Shawn Wang 认为简单的方法往往已经能够解决 80% 的问题而复杂的索引和多步骤检索可能只在少数追求极高精度的场景下才是真正必要的。
特别的是在代码仓库的文档管理与检索中“文本”形式展现出了独特优势它不仅简洁而且可读性极高**•**Cognition 的 DeepWiki 用的就是类似“文本”的思路它可以将任意公开 GitHub 仓库自动转换成类似 wiki 的文档形式并附带架构图、源代码链接、摘要等以便让开发者快速理解仓库结构与内容**•**Shawn Wang 开发了一个浏览器插件能在任意代码仓库中直接打开 Wiki**•**Lance Martin 开发了一个小项目可以将代码仓库整理成易读的文本格式并借助 LLM 生成高质量描述具体流程是这个工具会先自动遍历仓库内的所有文档页面再将每个页面传递给 GPT 或其他 LLM然后生成详尽摘要最后将这些摘要汇总成一份文本文件。
Claude Code 得到这个文本文件后就能准确判断该调用哪个文档页面例如依据问题快速定位到对应 URL。
记忆检索是特定 Context 下的检索Agent 的记忆可分为四类情景记忆episodic memory、语义记忆semantic memory、程序记忆procedural memory和背景记忆background memory。
对于长期运行的 agent 来说区分这些记忆类型尤为关键。
但在传统的 context engineering 讨论中这种细分的记忆分类还没有得到充分重视。
Source: LangChain,Context Engineering在记忆与context engineering的关系上Lance 认为可以从写入记忆writing memories和读取记忆reading memories这两个维度来理解同时还要考虑自动化程度degree of automation。
在实际应用中agent 依据自动化程度可以分成两种模式类似 Claude Code 的极简模式Claude Code 的设计非常直观在读取记忆时它会在启动时自动加载用户的 GitHub 仓库而在写入记忆时则需要用户手动指定将内容保存到 GitHub 的某个文件。
全自动记忆在这种模式下agent 会在后台自动决定何时写入或读取记忆。
但这种方式存在明显风险尤其是记忆检索的不可控性。
比如曾有用户希望生成某个场景的图片模型却自动检索到用户的地理位置并把这个位置信息意外融入生成内容中而这并非用户的真实意图。
从实际发展来看OpenAI 在 ChatGPT 的记忆功能上投入了大量精力但效果依然有限这也表明了全自动记忆仍是一个极具挑战性的方向。
Lance 认为写入记忆的难点在于如何判断何时写入而读取记忆在大规模场景下则可以直接理解为 retrieval。
换句话说大规模的记忆读取本质上就是在做检索操作。
因此记忆的读取部分应当被视为检索的一种特定应用场景。
只是这种检索的特殊性在于它并不是检索外部知识库或公开网页而是检索过去的对话内容。
例如当系统需要回顾用户的历史对话时本质上就是一种带有 context 约束的检索。
进一步来说复杂的记忆系统往往就是复杂的 RAG 系统。
虽然外界并不清楚 OpenAI 记忆工具的具体实现细节但很可能是通过对用户过往对话做索引并结合向量搜索或类似方法来实现检索功能。
这与 Windsurf 提出的多步骤 RAG 流程在逻辑上类似。
相比之下Claude Code 的做法则非常简单它在每次启动时自动加载用户的代码仓库虽然方式朴素但在实际使用中效果出奇地好。
这些案例表明记忆的读取与检索在很多情况下可以视为同一类问题只是场景和语境有所不同。
方法四Isolate 隔离Lance Martin 在 Latent Space 的分享中提到isolate context 有以下几种用法和
注意事项将 context 拆分给多个 agent但要谨慎Multi-agent 可能会做出相互冲突的决策如果能让 sub-agent 避免参与决策则能降低风险。
Isolate 用法和
注意事项Isolate context 指的是将 context 拆分开来从而避免不同类型信息相互干扰这与 multi-agent 架构密切相关。
在 Isolate context 的背景下不同角色的 agent 能够各自压缩并管理不同的内容从而避免单一 agent 承担全部 context 的负担这种分工被认为是更高效的。
isolate context 运行原理但 Cognition 认为在 multi-agent 架构下sub-agent 要获得足够的 context 是极其困难的。
为此Cognition 投入了大量精力在 context 的摘要与压缩上。
特别的是在 coding 场景中如何在 sub-agent 之间分配和传递 context 是一个非常棘手的问题。
在 coding 任务中sub-agent 之间往往存在状态依赖state dependency这意味着不同 sub-agent 的决策可能会相互影响甚至产生冲突。
例如一个 sub-agent 负责写测试另一个负责修改逻辑如果它们各自独立决策最后在整合时可能会出现不一致的问题。
因此Cognition 认为不要依赖 sub-agent 来处理此类任务。
此外Cognition 的 Walden Yan 还提到过“反向书写任务reverse write tasks”比如 coding 这类任务需要不同 sub-agent 分别负责最终系统的不同组件这会导致 agent 之间必须频繁沟通而当前 agent 间的通信机制仍处于早期阶段这使得 coding 类场景的问题更加突出和复杂。
这也反映了 Cognition 与 Anthropic 的核心分歧Cognition 认为不要使用 multi-agent而 Anthropic 则认为 multi-agent 非常有用。
Lance Martin 认为这取决于 multi-agent 要解决的具体问题应用场景和使用方式会极大影响 multi-agent 的运行效果应该将 multi-agent 用于易并行、只读read-only 的场景。
比如在 deep research 场中agent 的工作主要是读取信息也就是收集 context当所有并行的读取任务完成后最后才会统一进行书写比如撰写最终的研究报告。
Anthropic 的报告中提到他们的 deep research agent 就是采用了这种架构sub-agent 并行收集信息最后统一产出结果。
相比之下coding agent 的情况更加复杂虽然现在 Anthropic 的 Claude Code 已经支持 sub-agent 模式表明 Anthropic 认为这种架构在 coding 任务中至少是值得尝试的但 Lance Martin 还是认为如果 sub-agent 的任务需要高度协同coding 场景就会非常棘手。
Cognition 与 Anthropic 的观点分歧
方法五Cache 缓存Lance Martin 在 Latent Space 的分享中提到cache context 有以下几种用法缓存输入的 tokens在 Claude-sonnet 上成本可降低 10 倍将 agent 的指令、工具描述缓存到前缀中。
将可变 context / 最近的观测结果添加到后缀中。
Cache 用法开发者在初次搭建 agent 时常遇到高昂的循环成本问题因为 agent 每一次循环都需要重复传递之前的工具调用结果从而要消耗大量 token。
为了降低延迟和成本将消息历史进行缓存被视为一种有效策略。
2025 年 7 月Manus 提出了缓存caching概念利用键值KV缓存机制来提高 AI agent 在处理多步骤任务时的效率和成本效益。
Manus 在官方发布的《AI 代理的 context 工程构建 Manus 的经验教训》中表示如果我必须选择一个指标我认为 KV-cache 命中率是生产阶段 AI 代理最重要的单一指标。
它直接影响延迟和成本。
为了理解原因让我们看看典型代理是如何运作的在接收用户输入后代理通过一系列工具使用链来完成任务。
在每次迭代中模型根据当前上下文从预定义的动作空间中选择一个动作。
然后在环境中执行该动作例如Manus 的虚拟机沙盒以产生观察结果。
动作和观察结果被附加到上下文中形成下一次迭代的输入。
这个循环持续进行直到任务完成。
正如你所想象的随着每一步的推进上下文不断增长而输出——通常是结构化的函数调用——保持相对简短。
这使得代理agents相比聊天机器人的预填充和解码比例高度倾斜。
例如在 Manus 中平均输入与输出的 token 比例约为 100:1。
幸运的是具有相同前缀的上下文可以利用 KV 缓存这大大减少了首个 token 的生成时间TTFT和推理成本——无论你是使用自托管模型还是调用推理 API。
我们说的不是小幅度的节省例如使用 Claude Sonnet 时缓存的输入 token 成本为
30 美元/百万 token而未缓存的成本为 3 美元/百万 token——相差 10 倍。
但不同的 API 在实际应用中存在差异比如 OpenAI 会自动缓存从而避免重复传输而早期的 Anthropic 需要用户自己显式设置缓存请求头caching header。
需要注意的是缓存只能优化延迟和成本问题但无法解决 long context 的根本问题也就是说即使缓存生效当 context 达到十万 token 时模型仍然需要完整处理这么长的 context无论是否有缓存模型的性能衰减context decay问题依然会存在。
更进一步缓存策略往往与服务商绑定。
如果用户非常依赖厂商提供的缓存机制那用户可能面临“厂商锁定”难以自由切换服务但如果是运行自有开源模型那能完全掌控缓存策略实现更高灵活性。
the Bitter Lesson的启发OpenAI 的 Hyung Won Chung 在the Bitter Lesson in AI Research的演讲中指出在相同成本下计算能力每五年大约增长十倍这种 scaling 的趋势是推动 AI 进步的关键因素。
历史经验表明那些归纳偏置较少、更通用、更依赖大量数据和计算的算法往往比依赖手工特征设计或内置归纳偏置的算法表现更好。
简单来说the Bitter Lesson指出了让机器通过大量数据和计算自主学习如何思考比人工教机器如何思考更有效。
Hyung Won Chung 曾是 OpenAI 的 Research Scientist主要研究推理reasoning与 agents他是 o1-preview、o
Deep Research 等项目的核心贡献者并领导过 Codex mini 的模型训练。
“归纳偏置”Inductive bias指的是系统在面对有限数据时为了能够进行合理的泛化而内在带有的一套假设或偏好。
换句话说它是一种先验约束让模型在无限可能的解释中更倾向于选择某些解释从而提高学习效率。
Source:the Bitter Lesson in AI ResearchHyung Won Chung 还提出在任何研究阶段为了在当时的计算条件下获得理想性能通常需要为算法添加一些结构structure例如更多的建模假设或归纳偏置。
这在计算资源有限时确实是有帮助的但随着计算能力增加这些人为添加的结构反而会成为进一步发展的瓶颈。
Source:the Bitter Lesson in AI Research只要框架透明就有实用价值Lance 表示当人们讨论架构框架frameworks时往往包含两类不同的东西agent 抽象agent abstractions和底层编排框架low-level orchestration frameworks。
很多开发者反对的其实是前者而不是后者。
Source: LangChain,How to think about agent frameworks以 Shopify 的 Roast 框架为例这是一个开源的 AI 工作流编排workflow orchestration工具提供了可组合的底层构建块没有预设状态判断no judges state允许用户自由搭建 agent 和工作流。
Lance 并不反对这种架构他认为这种方式可以充分利用底层构建块的灵活性他在搭建 Open Deep Research 时也是先搭工作流再拆解重构成 agent。
相比之下agent 抽象agent abstractions则容易隐藏逻辑使系统在模型能力提升时难以拆解和重构。
Lance 认为开发者需要警惕 agent 抽象agent abstractions但这并不意味着要排斥底层编排框架只要框架提供的是透明、可自由组合的节点而非黑箱就具有实用价值。
企业客户在内部尝试搭建 agent 和工作流时往往一开始都选择自行搭建但随着代码难以管理、协作和评审问题逐渐出现标准化框架和可组合组件就显得尤为必要。
比如在 2024 年年中随着 Anthropic 模型的工具调用能力提升许多企业纷纷开始集成但由此带来了很多混乱。
于是 MCP 出现为工具访问制定标准协议降低协同成本与认知负担。
这表明大型组织推动标准化框架的根本动因是为了解决实际的协作问题而不是为了框架本身。
实践经验Lance Martin 在过去一年搭建 Open Deep Research 的过程中最初采用的是高度结构化的流程几乎不依赖工具调用因为当时业界普遍认为工具调用并不可靠所以他在系统中预先嵌入了大量假设将研究问题拆解为多个部分并行处理最后再整合成完整报告。
这个流程在当时确实更稳定但随着模型能力的快速提升这种繁复的结构反而限制了模型对 MCP 和工具调用能力的使用。
因此 Lance 转向使用 agent 架构去掉过多结构允许 agent 自主决定研究路径实现工具调用。
这验证了 Hyung Won Chung 的观点researcher 需要不断重新评估“基于当前模型能力我的假设是否还成立”。
Lance 甚至用 GPT-5 进行了测试结果表明随着模型能力不断提升Open Deep Research 这个开源系统也能够同步跟进并适应这些进展。
此外Anthropic 的 Boris 在设计 Claude Code 的时候也遵循了the Bitter Lesson让 Claude Code 的系统保持尽可能地简单、通用为用户提供广泛的模型访问权限。
值得注意的是传统企业采用 AI 的常见做法是将 AI 嵌入已有工作流因为这些企业已经拥有成熟的流程和结构AI 的作用主要是优化和增强这些流程。
但 AI-native 产品则往往不会受限于现有流程而是在模型能力达到足够水平后从零开始构建产品**•**相比 VSCodeCursor 和 Windsurf 更适合 AI coding因为它们无需改造旧流程**•**Cognition 也是从一开始就以 agent 为核心进行原生设计而不是把 agent 当作现有工具的补充。
过去两年半企业常常在纠结应该是将 AI 嵌入现有流程还是重构流程产生这种纠结的原因在于早期模型能力不足重构效果不好因此结构化方法往往表现更好因此容易让人误以为这些结构是长久有效的解决方案。
但现在模型能力已超过临界点最佳策略是用更少结构化来搭建系统。
Anthropic 创始人 Jared Kaplan 表示构建“目前尚不完美的产品”或许是合理策略因为随着模型指数级进步产品价值会被逐步释放。
这也正是the Bitter Lesson在企业应用中的具体体现早期依赖结构获得短期优势但长期来看灵活、少结构、通用的方法才能在模型能力增长的浪潮中取得最终胜利。
**•**Cursor 早期并不完美但随着 Claude
5 发布正好匹配了模型能力追上产品需求的节点。
•Windsurf 的产品曲线表现出一个平台期ceiling随后快速爆发boom增长最终放缓。
如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。
但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。
这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。
我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。
那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。
我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2025 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。
正确的学习路线可以为你节省时间少走弯路方向不对努力白费。
这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。
在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。
以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有
年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。
风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。
本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。
以上全套大模型资料如何领取