周六下午出去日常“漫游”，地铁上看了数据标注公司Surge AI创始人Edwin Chen的访谈和Manus的上下文工程两篇文章，结合自己之前的一些思考，感觉很多东西又串联起来了，突然就想把它们写出来。晚上回来，从23点写到凌晨3点，终于搞定，是有此文。

一切皆是上下文

最近Kimi的K2发布，第一时间看了报告，万亿参数很震撼。当然，本文并不是聊K2，也不是聊模型，而是想聊聊上下文。之所以开头提到K2，是因为发布后出现一个新的名词——LLM即Agent，这和上下文很有关系，所以就从这个词开聊。我们关注的重点并不是上下文长度，虽然它也很重要，我们关注的是仅使用LLM即可完成复杂任务。

从R1之后，使用LLM进行复杂推理就变成一个热门领域，尤其是GRPO引领的这波RL热潮，至今仍在持续。光笔者本人博客就介绍过不少文章，感兴趣的读者可以在这里^[1]找到相关文章。近期的GiGPO^[2]更是将其推广到Agent领域——LLM通过强化微调可以提升完成Agent任务的能力。这看起来好像和指令跟随有关系（这里^[1]也有一些相关研究），都体现出LLM的能力，只不过指令跟随更加侧重指令本身。

总而言之，我们可以明显感受到LLM的能力在不断变强，昔日的提示词技巧现在已经完全不重要了（关于这点已经提过多次了，比如这里^[3]）；目前看来，很多Agent可能也开始变得不重要了。当然，并不是说Agent没了，而是这种能力被设计进LLM内部了。LLM的边界在不断延升，感觉真的距离LLM即产品越来越近了。

其实，关注笔者本人博客的读者应该知道，除了提示词，还有几个很火的东西也基本没涉及过，一个是RAG，一个是ToolCall、还有Agent，以及前不久火的一塌糊涂的MCP。作为一个从17年开始搞AI算法的“老NLPer”来说，智能客服快做吐了，RAG这个东西实在是提不起来兴趣，也从来没觉得这东西能玩出什么花儿来。所以很干脆地，从出现到现在没看过一篇相关研究，倒是工作中几个项目用到了，不过也都是自己写的，没用框架。Agent同理，但它是个新玩意儿，所以当时借着一个给人培训的机会读了MetaGPT和部分Langchain的源码——工程的东西太多了，基本和算法无关了，自然不会关注太多。同样，工作项目不可避免地写了Agent，当然没MetaGPT那么复杂就是了。其实，因为要给人培训，我实在是“没办法”才去看了几个相关项目，一开始看抱的期望很大，迫不及待地上手一用，只能说一言难尽。最不能接受的就是错了后不停地重新开始改啊改，结果总是改不对，我的Token顶不住。至于ToolCall，甚至还不如Agent，我到现在都没理解这玩意儿有啥值得大肆宣扬的。至于MCP，我其实接触的比较早（比较关注LLM之间的通信协议），当时还没有那么火，看了后感觉想法确实很好，但其实和算法也是关系不太大的。我记得在3月份写《DeepSeek R1后应用、职业与行业影响——2025年梳理 | Yam^[4]》时它还不火呢，那时候DeepSeek还在发力中，结果没想到没过多久突然火成那样子，真是莫名其妙。。。

现在回想起来，自己一直以来的感觉是没问题的，无论是提示词、RAG、ToolCall还是Agent、MCP，它们其实都是偏应用层面的东西，当然不是说它不是算法，至少它们都是以LLM为核心的。当然，这和个人取舍、兴趣有关，只是我自己兴趣不在那些上面而已。不过，有一次在给人讲解MCP概念的时候突然意识到：其实无论这些概念有多少，无论是新的还是旧的，无论怎么变化，都有一个共同核心——它们都是LLM的“上下文”。简单来说，它们都是给LLM提供某种信息的。我记得自己当时想到这里时，感觉念头通达，很多事情豁然开朗。作为一名LLM算法工程师，不懂这些显然是不行的，但要是把这些看的太重而忽略了LLM本身，那恐怕有点本末倒置。至少对我自己来说是这样的。

好了，让我们重新认识一下“上下文”——它就是能让LLM完成一项任务需要的所有外部信息。

上下文工程

这个词来自《Context Engineering for AI Agents: Lessons from Building Manus^[5]》，接下来的一些观点也可能和这篇文章有关。但显然，我们已经重新定义了一下“上下文”。

文章开头的那句选择令我印象深刻，摘录如下：

Manus would bet on context engineering. This allows us to ship improvements in hours instead of weeks, and kept our product orthogonal to the underlying models: If model progress is the rising tide, we want Manus to be the boat, not the pillar stuck to the seabed.

对LLM算法来说，如果单说RAG、MCP、提示词什么的，可能确实不需要过于关注，但“上下文工程”可能就得稍微关注一下了，因为它直接涉及到能否用好LLM。其实我自己也没太多思考，主要整理下这篇文章的几个观点。

围绕KV Cache设计

显然这是一个推理性能相关问题，KV Cache能够极大地提升推理效率。而且，随着上下文越来越长，输入输出Token比会越来越大，KV Cache的作用会更加明显。所以，尽量保证输入前缀的稳定性，新的信息从后面追加。如果使用vLLM，记得启动时开启prefix-caching^[6]，这样能够大大缩短预填充时间。这在长上下文任务和多轮对话场景下尤其有用。

Mask而非按需加载

主要说的就是这些提供上下文的“信息源”，动态增删不仅会导致KV Cache失效，而且当先前的动作和观察仍然涉及当前上下文中不再定义的工具时，模型会感到困惑进而可能导致幻觉。Manus使用一个上下文状态感知状态机管理工具可用性，通过在解码过程中掩蔽token的logits，以基于当前上下文阻止（或强制）选择某些动作。

左图中，Action/Obs1使用的Tool A在下一步中没了，但Action/Obs1还在。

文件系统作为上下文

Agent的上下文信息经常太长，超出模型限制后性能下降，而且长输入成本也高。上下文截断或压缩策略可能导致信息损失，而且更关键的，Agent必须根据所有先前状态预测下个动作，我们没法保证那个信息在未来可能非常有用。所以，Manus将文件系统视为上下文，按需写入和读取。这里的压缩策略始终设计为可恢复的。比如，只要保留URL，网页内容就可以从上下文中移除。

通过复述控制记忆

通过不断重复TODO，将目标复述到上下文末尾，缓解主题偏离和早期目标遗忘问题。

保留错误内容

把错误的尝试保留在上下文中。当模型看到一次失败的动作——以及由此产生的观察结果或错误堆栈信息——它会在内部隐式地更新自己的信念。这会让模型对类似动作的“先验”偏好发生转变，从而降低再次犯同样错误的概率。

增加提示样本结构多样性

LLM模仿上下文中的行为模式。如果上下文充满了类似的过去行动-观察对，模型将倾向于遵循该模式，即使这不再是最优的。Manus在行动和观察中引入少量的结构化变化——不同的序列化模板、替代性措辞、顺序或格式上的微小噪音。这种受控的随机性有助于打破模式并调整模型的注意力。

小结

都是相当实用的设计，而且它是“通用”的，因为它针对的就是“上下文”。最后，引用文章最后的话：

上下文工程仍是一门新兴的科学——但对于智能体系统来说，它已经变得不可或缺。虽然模型正变得更强大、更快速、更低成本，但再强的能力也无法取代记忆、环境和反馈的作用。你如何构建上下文，最终决定了智能体的行为方式：它运行得有多快、恢复得有多好、扩展得有多远。

The agentic future will be built one context at a time. Engineer them well.

虽说LLM is Agent美丽动人，但不得不说，Context Engineering也不乏迷人魅力。大家喜欢哪个？还是说，两手抓，两手都要硬。

再次重新认识数据

为什么说“再次”，因为R1出来后已经让我们重新认识了什么叫“高质量数据”。感兴趣的读者可以阅读《DeepSeek R1后LLM新范式 | Yam^[7]》和《DeepSeek R1深度技术解析及其影响 | Yam^[8]》。这里的再次，当然是指“LLM即Agent”的数据，具体来说就是K2的数据构造。

为什么K2能够LLM即Agent？我想高质量的相关数据恐怕是最重要的原因。请打开K2技术报告，我们不谈预训练阶段的Rephrasing，直接把报告翻到第9页，看SFT的《Large-Scale Agentic Data Synthesis for Tool Use Learning》，整整一小节介绍如何搞数据。数据合成pipeline如下图所示。

有真实的3000个和生成的各个领域超过2万个工具；成千上万个风格和能力各异的Agent和针对每个Agent一系列有明确评分标准的从简单到复杂的任务；用户模拟+工具模拟生成高质量多轮对话；质量评估和过滤，以及真实环境数据补充。

不知道大家有没有再次重新认识数据。果然，还是机器学习那句老话——数据决定上限，算法逼近上限。LLM的进化之路也是“数据”的蜕变进化之路啊。

数据高质量数据

说到数据，正好再聊聊最近看到的另一篇文章：《Surge AI创始人Edwin Chen首次接受采访：为什么我看不上Scale AI和Alex Wong^[9]》，Surge AI是一家数据标注公司，2020年成立至今从未融资，创始人几乎不接受任何采访，这次与20VC的对话是其首秀。先看看他们牛逼闪闪的主页：

文章里对这个做了翻译，质量非常不错（另外，文章作者的小声BB也很有意思），感兴趣的读者可以阅读原文。这里只是罗列其中一些比较有意思的观点（相似的放一起了），每个观点后面有我的BB。

1. 数据质量是最核心的原则。为此必须构建技术系统，以测量和改进数据质量。质量是公司文化的核心，必须提供“别人给不了的数据”。要用数据开启全新的研究与产品路径。“数据质量”排第一，其次是“算力”，最后才是“算法”。

我错了。数据决定上限→高质量数据决定上限

2. 强调“数据的内在理解（visceral understanding）”——ML 工程师应该亲自深入理解数据，而不是只跑模型。特别是生成的是诗歌、数学推理、科研类数据，更应该“动手”理解，而非隔空操作。

非常认同。算法工程师必须亲自分析Case，下场看一些数据。

3. LLM Arena就是个典型的“榜单幻觉”场所。用户输入问题，两个模型生成回答，然后由用户投票决定谁更好。问题是，很多用户投票时根本不仔细读内容。一个模型即便胡说八道，只要用了表情符号和加粗格式，就能赢得选票。Benchmark会让许多团队误以为自己模型变强了，实则训练出来的是“花哨话术模型”。

非常认同。不想多说。

4. 合成数据确实有用，但被严重高估了。它只擅长“合成场景”下的问题，对现实用例表现极差。很多公司用了一年 synthetic data，才发现训练出的模型表现不稳定、泛化性差，最终不得不“回头清洗数据”。有客户说，他们用的合成数据多达千万条，但我们提供的几千条高质量人工数据反而更有价值。合成数据容易导致模型“塌缩”到极窄语域，最终训练出的模型缺乏多样性与鲁棒性。

比较认同。我相信没有free lunch。

5. 一个很有意思的现象：模型会犯一些人类永远不会犯的低级错误。举例来说，它会在英文回答中随机插入俄语或印地语字符。任何一个二年级小学生都能看出这是错误的，但模型却无法意识到。这说明什么？说明我们始终需要一个“外部价值体系”来检验模型的行为和产出。因为模型的思维方式和人类不同，它可能根本无法意识到自己已经偏离常识。

比较认同。不过是不是也应该分析到底为什么会出现这种低级错误？

6. 很多人认为 AI 安全问题被夸大了。但他们忽略了“回形针最大化者”这类经典悖论。模型如果在训练中被错误的目标函数误导，就可能在不知道的情况下被最大化到有害方向。今天benchmark hacking的问题本质上就是这种早期形态。如果我们现在都不重视，未来后果会很严重。

比较认同。关于回形针最大化者悖论，我在很多年前的文章提过：《与机器人共舞》读后感兼谈 AI 与 IA | Yam^[10]。

7. 每家AI公司都应该问但没有问自己的一个问题是什么？如果你是前沿研究实验室，应该问：“我们的模型是在实现真正的智能进展，还是只是通过benchmark hacking在刷榜？”如果你是应用层公司，应该问：“我们做的事情，为什么大型模型厂商未来不会一秒钟就替代我们？”

非常认同。大厂吃肉，我们喝汤。

8. 永远专注于能带来10倍提升的事，而不是纠结于那些只能带来 10% 改进的细节。

非常认同。老哥，请告诉我哪些是能带来10倍提升的事，我现在就去做。

总之，老哥一直在各种强调高质量数据非常重要，围绕着它360°打转，但是关于他们具体怎么做的却是半点没透露；D。不过，我们确实能感受到那句**“The quality of your data determines the ceiling of your ambitions.”**

小结

本文从K2带来的“LLM即Agent”开始，首先重新梳理了上下文，将提示词、RAG、ToolCall、MCP、Agent（部分）均统一归为“上下文”，进而引出上下文工程。而Manus在这方面怎么说也算是经验丰富了，通过它的一篇文章我们可以学到很多实用的工程知识。接下来再次回到K2，重点谈论数据的重要性，再次重新认识数据。最后通过一篇数据标注公司CEO的访谈记录更进一步认识到数据、尤其是高质量数据对AGI的重要性。总的来说，高质量数据与LLM能力有关，但上下文工程可以更有效率地释放其能力。

References

[1] 这里: https://yam.gift/series/
[2] GiGPO: https://yam.gift/2025/07/25/NLP/LLM-Training/2025-07-25-GiGPO/
[3] 这里: https://yam.gift/2023/02/21/NLP/2023-02-21-ChatGPT-Impact/
[4] DeepSeek R1后应用、职业与行业影响——2025年梳理 | Yam: https://yam.gift/2025/03/15/AI/2025-03-15-LLM-App-Develop/
[5] Context Engineering for AI Agents: Lessons from Building Manus: https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
[6] prefix-caching: https://docs.vllm.ai/en/latest/features/automatic_prefix_caching.html#limits
[7] DeepSeek R1后LLM新范式 | Yam: https://yam.gift/2025/03/15/NLP/LLM-Training/2025-03-15-R1-New-Paradigm/
[8] DeepSeek R1深度技术解析及其影响 | Yam: https://yam.gift/2025/02/17/NLP/LLM-Training/2025-02-17-DeepSeek-R1/
[9] Surge AI创始人Edwin Chen首次接受采访：为什么我看不上Scale AI和Alex Wong: https://mp.weixin.qq.com/s/n8AdurwSLsULuG1xKfVnKA?open_in_browser=true
[10] 《与机器人共舞》读后感兼谈 AI 与 IA | Yam: https://yam.gift/2016/03/31/AI/2016-03-31-Machines-of-Loving-Grace/