文章开头的那句选择令我印象深刻，摘录如下：
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.
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还在。
左图中，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.
上下文工程仍是一门新兴的科学——但对于智能体系统来说，它已经变得不可或缺。虽然模型正变得更强大、更快速、更低成本，但再强的能力也无法取代记忆、环境和反馈的作用。你如何构建上下文，最终决定了智能体的行为方式：它运行得有多快、恢复得有多好、扩展得有多远。
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的进化之路也是“数据”的蜕变进化之路啊。
数据高质量数据
说到数据，正好再聊聊最近看到的另一篇文章：《[9]》，Surge AI是一家数据标注公司，2020年成立至今从未融资，创始人几乎不接受任何采访，这次与20VC的对话是其首秀。先看看他们牛逼闪闪的主页：
观点1：数据质量是最核心的原则。为此必须构建技术系统，以 测量和改进数据质量。质量是公司文化的核心，必须提供“别人给不了的数据”。要用数据开启全新的研究与产品路径。“数据质量”排第一，其次是“算力”，最后才是“算法”。
我错了。数据决定上限→高质量数据决定上限
我错了。数据决定上限→高质量数据决定上限
观点2：强调“数据的内在理解（visceral understanding）”——ML 工程师应该亲自深入理解数据，而不是只跑模型。特别是生成的是诗歌、数学推理、科研类数据，更应该“动手”理解，而非隔空操作。
非常认同。算法工程师必须亲自分析Case，下场看一些数据。
非常认同。算法工程师必须亲自分析Case，下场看一些数据。
观点3：LLM Arena就是个典型的“榜单幻觉”场所。用户输入问题，两个模型生成回答，然后由用户投票决定谁更好。问题是，很多用户投票时根本不仔细读内容。一个模型即便胡说八道，只要用了表情符号和加粗格式，就能赢得选票。Benchmark会让许多团队误以为自己模型变强了，实则训练出来的是“花哨话术模型”。
非常认同。不想多说。
非常认同。不想多说。
观点4：合成数据确实有用，但被严重高估了。它只擅长“合成场景”下的问题，对现实用例表现极差。很多公司用了一年 synthetic data，才发现训练出的模型表现不稳定、泛化性差，最终不得不“回头清洗数据”。有客户说，他们用的合成数据多达千万条，但我们提供的几千条高质量人工数据反而更有价值。合成数据容易导致模型“塌缩”到极窄语域，最终训练出的模型缺乏多样性与鲁棒性。
比较认同。我相信没有free lunch。
比较认同。我相信没有free lunch。
观点5：一个很有意思的现象：模型会犯一些人类永远不会犯的低级错误。举例来说，它会在英文回答中随机插入俄语或印地语字符。任何一个二年级小学生都能看出这是错误的，但模型却无法意识到。这说明什么？说明我们始终需要一个“外部价值体系”来检验模型的行为和产出。因为模型的思维方式和人类不同，它可能根本无法意识到自己已经偏离常识。
比较认同。不过是不是也应该分析到底为什么会出现这种低级错误？
比较认同。不过是不是也应该分析到底为什么会出现这种低级错误？
观点6：很多人认为 AI 安全问题被夸大了。但他们忽略了“回形针最大化者”这类经典悖论。模型如果在训练中被错误的目标函数误导，就可能在不知道的情况下被最大化到有害方向。今天benchmark hacking的问题本质上就是这种早期形态。如果我们现在都不重视，未来后果会很严重。
比较认同。关于回形针最大化者悖论，我在很多年前的文章提过：《与机器人共舞》读后感兼谈 AI 与 IA | Yam[10]。
比较认同。关于回形针最大化者悖论，我在很多年前的文章提过：《与机器人共舞》读后感兼谈 AI 与 IA | Yam[10]。
观点7：每家AI公司都应该问但没有问自己的一个问题是什么？如果你是前沿研究实验室，应该问：“我们的模型是在实现真正的智能进展，还是只是通过benchmark hacking在刷榜？”如果你是应用层公司，应该问：“我们做的事情，为什么大型模型厂商未来不会一秒钟就替代我们？”
非常认同。大厂吃肉，我们喝汤。
非常认同。大厂吃肉，我们喝汤。
观点8：永远专注于能带来10倍提升的事，而不是纠结于那些只能带来 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:
[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/返回搜狐，查看更多