@stephen-lord/other2 1.0.8 → 1.0.10

package/dist/docs/manus/CN-/346/211/222/345/256/214/345/205/250/347/275/221/346/234/200/345/274/272-AI-/345/233/242/351/230/237/347/232/204-Context-Engineering-/346/224/273/347/225/245/346/210/221/344/273/254/346/200/273/347/273/223/345/207/272/344/272/206/350/277/231-5-/345/244/247/346/226/271/346/263/225-/346/231/272/346/272/220/347/244/276/345/214/272.md

@@ -0,0 +1,2464 @@
+# 扒完全网最强 AI 团队的 Context Engineering 攻略，我们总结出了这 5 大方法 - 智源社区
+
+**Source:** https://hub.baai.ac.cn/view/49301
+
+---
+
+URL: https://hub.baai.ac.cn/view/49301
+
+扒完全网最强 AI 团队的 Context Engineering 攻略，我们总结出了这 5 大方法 - 智源社区
+
+# 扒完全网最强 AI 团队的 Context Engineering 攻略，我们总结出了这 5 大方法
+
+DDPM
+
+Gen AI
+
+DL
+
+极客公园 2025-09-30 00:40 分享
+
+以下文章来源于mp.weixin.qq.com
+
+当下 AI Agent 开发的一大痛点是，海量的工具调用和 long horizon reasoning 所产生的 long context，严重地制约了Agent 的性能和成本，甚至会导致模型能力的下降。在正确的时间为 Agent 提供正确的信息，是当下「上下文工程」（context engineering）旨在实现的目标，也是 Agent 开发的核心关键。这篇文章系统地梳理了来自 LangChain 工程师 Lance Martin、Chroma 的联合创始人 Jeff Huber、Manus、Anthropic、Cognition 等一线团队的「上下文工程」实践经验。作者将他们的解决方案归纳为了五大策略：转移（Offload）、压缩（Reduce）、检索（Retrieve）、隔离（Isolate）和缓存（Cache）。同时结合 AI 领域的The Bitter Lesson，探讨了在模型能力飞速迭代的当下，如何构建一个真正灵活且高效的 AI agent 框架。这是一份汇集了 AI 顶尖团队 Context engineering 实践精华的攻略。非常值得一读。本文来自「海外独角兽」。
+
+---
+
+超 14000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
+
+邀请从业者、开发人员和创业者，飞书扫码加群：进群后，你有机会得到：
+
+最新、最值得关注的 AI 新品资讯；
+
+不定期赠送热门新品的邀请码、会员码；
+
+最精准的AI产品曝光渠道
+
+---
+
+## 01
+
+## 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 engineering？
+
+Prompt 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，成本会达到 1-2 美元。
+
+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 Performance
+
+Claude Sonnet 4, GPT-4.1, Qwen3-32B, and Gemini 2.5 Flash on Repeated Words Task
+
+总而言之，简单 agent（naive agent）在实际运行时往往陷入双重困境：
+
+1. 它必须要处理几十到上百次工具调用累积出来的大量 context；
+
+2. 它在面对过长 context 时不仅可能因超出 context window 而无法继续运行，还可能容易发生 context decay 让模型能力下降。
+
+正是这些痛点，催生了“context engineering”这一新方向，目标就是在 agent 的构建过程中，通过精心设计和选择传递给模型的 context 来提升模型的效率和效果。围绕这一目标，学界和业界提出了多种方法，其中比较具有代表性的做法可以归纳为五类：Offload（转移）、Reduce（简化）、Retrieve（检索）、Isolate（隔离）和 Cache（缓存）。
+
+context engineering 的五种方法
+
+## 02
+
+## 方法一：Offload 转移
+
+Lance Martin 在 Latent Space 的分享中提到 offload context 有以下用法：
+
+使用文件系统来记录笔记；
+
+使用文件系统（如 todo.md）来规划/跟踪进度；
+
+使用文件系统读写 token 占用很大的 context；
+
+使用文件来存储长期记忆。
+
+Offload 方式
+
+如前文所述，基础版 agent 在执行过程中会进行多次工具调用，每一次调用的结果都会直接传回给 LLM，这导致所有 context 也会被完整传入 LLM，context 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
+
+## 03
+
+## 方法二：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 会打印错误日志，并在后续过程中利用这些日志进行调整。
+
+## 04
+
+## 方法三：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，采用的检索方法分为三类：
+
+1. 经典向量检索：将有约 300 万 token 的文档导入向量数据库，再通过标准向量搜索完成检索；
+
+2. 文件工具检索：基于文本文件和简单文件加载工具的检索，更接近生成式搜索，做法是提供一个包含所有文档 URL 和简要描述的 Markdown 文件，让 agent 可以借助工具调取所需文档；
+
+3. 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 依据自动化程度，可以分成两种模式：
+
+1. 类似 Claude Code 的极简模式：Claude Code 的设计非常直观，在读取记忆时，它会在启动时自动加载用户的 GitHub 仓库，而在写入记忆时，则需要用户手动指定，将内容保存到 GitHub 的某个文件。
+
+2. 全自动记忆：在这种模式下，agent 会在后台自动决定何时写入或读取记忆。但这种方式存在明显风险，尤其是记忆检索的不可控性。比如曾有用户希望生成某个场景的图片，模型却自动检索到用户的地理位置，并把这个位置信息意外融入生成内容中，而这并非用户的真实意图。从实际发展来看，OpenAI 在 ChatGPT 的记忆功能上投入了大量精力，但效果依然有限，这也表明了全自动记忆仍是一个极具挑战性的方向。
+
+Lance 认为写入记忆的难点在于如何判断何时写入，而读取记忆在大规模场景下则可以直接理解为 retrieval。换句话说，大规模的记忆读取本质上就是在做检索操作。因此，记忆的读取部分应当被视为检索的一种特定应用场景。只是这种检索的特殊性在于，它并不是检索外部知识库或公开网页，而是检索过去的对话内容。例如，当系统需要回顾用户的历史对话时，本质上就是一种带有 context 约束的检索。
+
+进一步来说，复杂的记忆系统往往就是复杂的 RAG 系统。虽然外界并不清楚 OpenAI 记忆工具的具体实现细节，但很可能是通过对用户过往对话做索引，并结合向量搜索或类似方法来实现检索功能。这与 Windsurf 提出的多步骤 RAG 流程在逻辑上类似。相比之下，Claude Code 的做法则非常简单，它在每次启动时自动加载用户的代码仓库，虽然方式朴素，但在实际使用中效果出奇地好。这些案例表明，记忆的读取与检索在很多情况下可以视为同一类问题，只是场景和语境有所不同。
+
+## 05
+
+## 方法四：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 的观点分歧
+
+## 06
+
+## 方法五：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 成本为 0.30 美元/百万 token，而未缓存的成本为 3 美元/百万 token——相差 10 倍。
+
+但不同的 API 在实际应用中存在差异，比如 OpenAI 会自动缓存，从而避免重复传输；而早期的 Anthropic 需要用户自己显式设置缓存请求头（caching header）。
+
+需要注意的是，缓存只能优化延迟和成本问题，但无法解决 long context 的根本问题，也就是说即使缓存生效，当 context 达到十万 token 时，模型仍然需要完整处理这么长的 context，无论是否有缓存，模型的性能衰减（context decay）问题依然会存在。
+
+更进一步，缓存策略往往与服务商绑定。如果用户非常依赖厂商提供的缓存机制，那用户可能面临“厂商锁定”，难以自由切换服务，但如果是运行自有开源模型，那能完全掌控缓存策略，实现更高灵活性。
+
+## 07
+
+## 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、o1、Deep Research 等项目的核心贡献者，并领导过 Codex mini 的模型训练。
+
+“归纳偏置”（Inductive bias）指的是系统在面对有限数据时，为了能够进行合理的泛化而内在带有的一套假设或偏好。换句话说，它是一种先验约束，让模型在无限可能的解释中，更倾向于选择某些解释，从而提高学习效率。
+
+Source: the Bitter Lesson in AI Research
+
+Hyung 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 framework
+
+以 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 产品则往往不会受限于现有流程，而是在模型能力达到足够水平后，从零开始构建产品：
+
+• 相比 VSCode，Cursor 和 Windsurf 更适合 AI coding，因为它们无需改造旧流程；
+
+• Cognition 也是从一开始就以 agent 为核心进行原生设计，而不是把 agent 当作现有工具的补充。
+
+过去两年半，企业常常在纠结应该是将 AI 嵌入现有流程还是重构流程，产生这种纠结的原因在于早期模型能力不足，重构效果不好，因此结构化方法往往表现更好，因此容易让人误以为这些结构是长久有效的解决方案。但现在模型能力已超过临界点，最佳策略是用更少结构化来搭建系统。
+
+Anthropic 创始人 Jared Kaplan 表示构建“目前尚不完美的产品”或许是合理策略，因为随着模型指数级进步，产品价值会被逐步释放。这也正是 the Bitter Lesson 在企业应用中的具体体现：早期依赖结构获得短期优势，但长期来看，灵活、少结构、通用的方法才能在模型能力增长的浪潮中取得最终胜利。
+
+• Cursor 早期并不完美，但随着 Claude 3.5 发布，正好匹配了模型能力追上产品需求的节点。
+
+• Windsurf 的产品曲线表现出一个平台期（ceiling），随后快速爆发（boom），增长最终放缓。
+
+Source: Lance Martin 在 Latent Space 演示的 PPT
+
+更多阅读
+
+对话 Plaud 莫子皓：你还记得 PMF 的感觉吗？
+
+18 年 SEO 增长经验专家：别再收藏各种 AEO 最佳攻略了，自己动手实验才是做好的关键
+
+Nano Banana 核心团队：图像生成质量几乎到顶了，下一步是让模型读懂用户的intention
+
+时隔 7 年，Notion 发布 3.0 版本，全面进入 Agent 时代
+
+转载原创文章请添加微信：founderparker
+
+内容中包含的图片若涉及版权问题，请及时与我们联系删除
+
+点赞 收藏 评论 分享到Link
+
+举报反馈
+
+举报类型（必选）
+
+- 其他
+- 内容涉黄
+- 政治相关
+- 内容侵权
+- 内容抄袭
+- 涉嫌广告
+- 样式问题
+
+举报详情（选填）
+
+0/200
+
+取消
+
+提交
+
+### 评论列表
+
+沙发等你来抢
+
+去评论
+
+### 评论
+
+登录后可提问交流
+
+沙发等你来抢
+
+像“内行人”一样看懂 AI Agent
+
+我知道了
+
+# 看完 Manus、Cursor 分享后的最大收获：避免 Context 的过度工程化才是关键 - 智源社区
+URL: https://hub.baai.ac.cn/view/51790
+
+看完 Manus、Cursor 分享后的最大收获：避免 Context 的过度工程化才是关键 - 智源社区
+
+# 看完 Manus、Cursor 分享后的最大收获：避免 Context 的过度工程化才是关键
+
+Data
+
+Agent
+
+DL
+
+极客公园 2026-01-11 12:40 分享
+
+以下文章来源于mp.weixin.qq.com
+
+毫无疑问，上下文工程的优化，仍然是 Agent 创业公司在新一年都在「卷」的重点。
+
+在实际落地开发中，上下文信息的质量，很大程度上决定了 Agent 的表现。
+
+Manus 的首席科学家季逸超在之前访谈中提到过一个观点：
+
+初创公司真的应该尽可能长时间地依赖通用模型和上下文工程，而不是过早地构建专用模型，也包括微调。上下文工程是应用层和模型层之间最清晰、最实用的边界。
+
+做好上下文工程，开发者能够在不触及模型底层权重的前提下，灵活驾驭模型，同时还能适应快速变化的产品需求。
+
+最近，Cursor 也发表了一篇文章《Dynamic context discovery》，分享了他们是怎么做上下文管理的。
+
+结合 Manus、Cursor 这两家 Agent 领域头部团队的思路，我们整理了如何做好上下文工程的一些关键要点。
+
+Cursor 原文：https://cursor.com/cn/blog/dynamic-context-discovery
+
+此前 Founder Park 分享的文章 《来自 Manus 的一手分享：如何构建 AI Agent 的上下文工程？》
+
+⬆️关注 Founder Park，最及时最干货的创业分享
+
+---
+
+超 19000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
+
+邀请从业者、开发人员和创业者，飞书扫码加群：进群后，你有机会得到：
+
+最新、最值得关注的 AI 新品资讯；
+
+不定期赠送热门新品的邀请码、会员码；
+
+最精准的AI产品曝光渠道
+
+---
+
+## 01
+
+## 「上下文缩减」是最直接有效的策略
+
+在 Agent 的构建过程中，会发现一个现象：上下文会持续增长，并且是以一种非常特殊的方式增长。
+
+Agent 每调用一次工具，就会返回一个工具的观测结果，这个结果会被追加到聊天记录中。随着时间的推移，消息列表会越来越长，导致 Agent 在运行时消息数量出现无限制的爆炸性增长。
+
+Manus 之前提到，典型的任务大约需要调用 50 次工具。Anthropic 也提到过类似的情况，生产环境中的 Agent 可能会进行长达数百轮的对话。
+
+上下文长度的持续增长，会导致推理性能断崖式的下跌。业内叫做「上下文腐烂」（Context Rot），具体表现是：推理变慢、质量下降、甚至开始无意义地重复。
+
+如何解决？业内目前共识的一个方法是「上下文卸载（Context Offloading）」，核心思路是别把所有东西都硬塞进 Agent 的短期记忆里，把它卸载出去。放到上下文窗口之外，但在需要时，又能被精确地检索回来。
+
+将信息转移到文件系统中，是目前生产级 Agent 中主流、最 Work 的一种做法。
+
+Cursor：万物皆可文件化
+
+Cursor 把「卸载」这个思路，发挥到了极致。用文件作为基础单元，将冗长的工具结果、终端会话、聊天记录全部转化成文件。
+
+Cursor 提到，
+
+我们不确定未来 LLM 工具的最佳接口是什么。但文件是一个简单、强大的基础单元，比发明一套新抽象要安全得多。
+
+基于这个思路，Cursor 提出了「动态上下文发现」（Dynamic Context Discovery）模式。核心是，别急着把信息塞给模型，而是让模型在需要的时候自己去找。
+
+Cursor 把这套模式用到了他们的多个实际场景中：
+
+将冗长的工具结果转化为文件
+
+工具调用，特别是 Shell 命令或第三方 MCP（模型上下文协议），经常返回巨大的 JSON 响应，瞬间就能撑爆上下文。目前的编程 Agent 通常采取的简单粗暴做法是：直接截断过长的 Shell 命令或 MCP 结果，但很可能会丢失最关键的信息。
+
+Cursor 的做法是，将这些输出直接写入到一个文件，然后在上下文中只告诉 Agent：「结果在 output.log 里，你自己去看。」Agent 可以先用 tail 命令查看文件末尾，如果需要更多细节，再读取整个文件。
+
+在「总结」阶段引用聊天记录
+
+当模型的上下文窗口被填满，Cursor 会触发一个「总结」步骤，给 Agent 腾出一个新的上下文窗口，其中包含之前工作的摘要。
+
+但 Agent 的知识会在这个过程中「退化」，因为「总结」本质上是对上下文的一种有损压缩。 Cursor 把完整的聊天历史记录也看做是一个文件。当触发总结时，Agent 会拿到一份摘要，以及一个指向「历史记录文件」的引用。如果 Agent 意识到摘要中缺少某些它需要的细节，它就可以通过搜索这份历史记录文件来找回这些信息。
+
+将所有集成终端的会话视为文件
+
+在 Cursor 中，不再需要手动复制粘贴满屏的终端报错信息，会自动将集成终端的所有会话输出同步到本地文件系统。 提问「为什么我的命令失败了？」时，Agent 能直接定位问题，甚至可以使用 grep 这样的命令，在长篇的服务器日志中只搜索相关的错误行。这种做法模仿了 CLI Agent 的体验，拥有之前的 Shell 输出作为上下文，但不同的是，它是动态发现，不是被静态注入。
+
+Manus ：一套结构化的可逆、缩减系统
+
+对比 Cursor「简单粗暴」的解决思路，Manus 的做法是，把「上下文缩减」设计成了一套有明确触发机制、分阶段执行的结构化流程。
+
+首先，Manus 的系统会持续监控上下文长度，设定一个远低于模型硬件极限的「腐烂前阈值」（Pre-rot Threshold）。
+
+季逸超：你的模型有一个硬性的上下文限制，比如说 100 万个 Token，这在今天是相当普遍的。但实际上，大多数模型在远低于这个值时性能就开始下降，通常可能在 20 万个 Token 左右，你会开始看到我们所说的「上下文腐烂」，比如重复、推理变慢、质量下降等。
+
+所以，通过大量的评估，识别出那个「腐烂前」的阈值非常重要，通常是 12.8 万到 20 万个 Token，并将其作为触发上下文缩减的条件。
+
+当信号被触发后，系统会启动第一阶段的操作：
+
+第一步：紧凑化（Compaction）
+
+这是一种无损、可逆的缩减。核心是，剥离掉任何能从外部状态（比如文件系统）重建的信息。
+
+举个例子，Agent 调用了一个向文件写入内容的工具，这个操作在历史记录中可能包含 path 和 content 两个字段。一旦执行成功，那个可能极其冗长的 content 字段就可以被安全地从上下文中剥离，只保留 path。
+
+信息并没有丢失，它只是被「外部化」了。如果 Agent 在 10 步之后需要再次读取该文件，它凭借保留的 path 就能轻易将其检索回来。
+
+Manus 提到，这种可逆性是非常关键的，因为你永远不知道哪个过去的动作会成为未来的关键。
+
+通常情况下，紧凑化只会用作最早的 50% 的历史记录，来保留最新的、完整的工具调用作为模型学习的范例（Few-shot Examples）。
+
+但紧凑化收益有限。多轮操作后，上下文削减的收益变得微乎其微时，系统会启动第二阶段：
+
+第二步：摘要化（Summarization）
+
+这是一种有损、但带保险的压缩。把它当做最后手段，在执行时需要极其谨慎。
+
+它的「保险」在于：在生成摘要之前，系统会更激进地将整个摘要前的完整上下文，转储（Dump）到一个文本或日志文件中。 相当于给历史创建了一个完整的快照存档。如果模型足够聪明，它甚至能用 grep 或 glob 自己去这个日志里捞数据。
+
+季逸超：紧凑化是可逆的，而摘要化不是。两者都减少了上下文长度，但它们的行为方式非常不同。
+
+在进行摘要化时，总是会使用完整版本的数据，不是紧凑版本。
+
+摘要化依然会保留最后几次完整的工具调用记录。 这能让模型清楚地知道自己从哪中断，能平滑地继续工作，保持风格和语气的连贯性。
+
+两个步骤下来，通过「紧凑化」（Compaction）剥离可重建信息，以及在「摘要化」（Summarization）之前，将完整的上下文转储（Dump）到日志文件中。实现上下文缩减。
+
+## 02
+
+## 给工具搭建一套灵活的行动空间
+
+当 Agent 能力逐步增强，配备的工具集也越来越丰富。
+
+如果将所有工具的冗长描述，都放到上下文窗口中，会带来两个问题：
+
+一是出现上下文混淆（Context Confusion）的情况，工具太多，模型直接懵掉。可能会调用错误的工具，甚至是幻觉出根本不存在的工具。
+
+二是最直接的 Token 浪费，大多数工具，在绝大多数时候根本不会被用到。如果，还使用了多个 MCP 服务器，情况会变得更糟。
+
+工具过载的问题怎么解决？一个核心思路是：动态发现，让 Agent 自己去找要调用哪些工具。
+
+Cursor：把工具说明书，全部文件化
+
+Cursor 的策略，更简单、粗暴。把所有 MCP 工具、Agent Skills 的详细定义，全部都同步到文件夹里，让 Agent 在需要时自己去查阅。
+
+在 Cursor 的框架中，分成了索引层和发现层。
+
+索引层，Agent 的系统提示词（System Prompt）里只包含一小部分静态信息，比如 MCP 工具或 Agent Skills 的名称列表。
+
+这些工具和技能的详细描述、参数定义、使用方法，则被全部同步到一个本地文件夹中。当模型需要时，Agent 会像一个聪明的程序员一样，进入发现层，用 grep 或语义搜索，主动去文件夹里查找它需要的工具的详细信息，然后拉取到上下文中来处理。
+
+Cursor 做了一次 A/B 测试，结果发现，对于调用了 MCP 工具的运行任务，这种策略把 Token 的总消耗降低了 46.9%。
+
+同时，Cursor 提到，这种全部文件化的方式，还解锁了一个意想不到的能力：向 Agent 传达工具的状态。
+
+例如，以前如果一个 MCP 服务器需要重新认证，Agent 可能会直接「忘记」这些工具的存在。但现在，Agent 可以主动发病、告知用户去重新认证。
+
+Manus：设计了一套分层的行动空间
+
+Manus 认为，常见的方法对工具描述进行动态的 RAG，不可行。 因为动态加载工具定义，会「干掉」KV 缓存，且历史记录里的旧调用会成为陷阱。
+
+季逸超：目前一个常见的方法是对工具描述进行动态的 RAG，比如，根据当前任务或状态按需加载工具。
+
+但会导致两个问题：首先，由于工具定义位于上下文的开头，每次变动都会导致你的 KV 缓存重置；最重要的是，模型过去对那些已被移除的工具的调用记录仍然存在于上下文中，这可能会误导模型去调用无效的工具或使用无效的参数。
+
+为了解决这个问题，Manus 设计了一套分层行动空间。把 Agent 的能力划分为三个层次：函数调用、沙盒工具、软件包和 API。
+
+第一层：原子函数调用（Function Calling）
+
+核心层，只包含极少数固定的、正交的原子函数，比如：读写文件、执行 shell 命令、在文件和互联网中搜索。因为这层是固定的，所以对 KV 缓存友好，且功能边界清晰，不会导致混淆。
+
+第二层：沙盒工具（Sandbox Tools）
+
+卸载层。Manus 将绝大多数工具，格式转换器、语音识别工具，甚至 MCP 调用本身（通过一个 MCP CLI 命令行工具），都作为预装软件放在一个定制的 Linux 虚拟机沙箱里。 Agent 不在上下文中「看到」这些工具的详细定义，更像是一个真正的开发者，通过第一层的 shell 命令来动态地与它们交互。比如，它可以用 ls /bin 来查看有哪些可用的工具，或者用 mcp_cli --help 来学习如何使用 MCP 命令行工具。
+
+第三层：软件包与 API（Packages & APIs）
+
+代码层。对于需要大量内存计算或者需要与复杂第三方服务交互的任务，允许 Agent 编写并执行 Python 脚本。比如，分析一整年的股票数据，Agent 不会把原始数据加载到上下文中，而是会写一个脚本去完成计算，只把摘要结果返回。
+
+季逸超：在这一层，Manus 可以编写 Python 脚本来调用预先授权的 API 或自定义软件包。例如，Manus 可能会使用一个 3D 设计库进行建模，或者调用一个金融 API 来获取市场数据。实际上，我们已经代表用户购买了所有这些 API 并支付了费用，这都包含在订阅里。
+
+所以，我们基本上在 Manus 中预装了大量的 API 密钥，Manus 可以用这些密钥访问 API。我认为这对于需要大量内存计算，但又不需要将所有数据都推送到模型上下文的任务来说是完美的。
+
+这套思路，和 CodeAct *论文类似。
+
+代码是可组合的，可以在一步内做很多事。但它同样不是模式安全的，在代码上做约束解码非常非常困难。所以我们认为你应该为这些功能找到合适的场景。对我们来说，所有能在一个编译器或解释器运行时内处理的事情，我们都用代码来做；否则，我们就用沙箱工具或函数调用。
+
+CodeAct *：《Executable Code Actions Elicit Better LLM Agents》：
+
+https://arxiv.org/pdf/2402.01030
+
+Manus 这套分层设计非常优雅，而且高效。从模型的角度看，无论想使用第二层还是第三层的复杂工具，最终都会通过 L1 的那几个原子函数执行。这种接口设计，对模型极度简洁，且缓存稳定。
+
+## 03
+
+## 多 Agent 协作，
+
+## 需要反复使用模式、结构化输出
+
+多个 Agent 之间如何协作，也是个难题。
+
+Cognition 之前在博客中提到：不要滥用多 Agent 设置，因为当你有很多 Agent 时，它们之间的信息同步会成为一场噩梦。
+
+怎么利用多 Agent，实现「上下文隔离」，让每个子 Agent 都有自己独立的上下文窗口，从而实现关注点分离。是一个核心问题。
+
+Manus 的解决思路是，借鉴 Go 语言：不要通过共享内存来通信，而是通过通信来共享内存。
+
+把这句话里的「内存」替换为「上下文」，就是两种截然不同的 Agent 协作模式。
+
+两种 Agent 协作模式
+
+任务委托模式：「通过通信」实现隔离
+
+这是经典的主-子 Agent（Master-Sub-agent）设置。主 Agent 将一个任务封装成一条简短、清晰的指令，然后发送给子 Agent。子 Agent 的上下文是完全独立的，从零开始，只包含这条指令。
+
+简单来说，主 Agent 发任务，子 Agent 交结果，中间过程免打扰。
+
+这个模式，适用于「过程不重要，只关心结果」的任务。举个例子，主 Agent 需要在一个大型代码库中搜索特定的代码片段。它只需要委托子 Agent：「在 A 项目中找到所有调用了 some_function 的地方」，然后等待返回结果列表即可。主 Agent 不关心子 Agent 是如何使用 grep 或其他工具完成搜索的。
+
+在内部，Manus 将这种模式叫做「Agent 即工具」。从主 Agent 视角，它只是调用了 advanced_search 函数，但背后实际上是另一个拥有独立工作流的子 Agent 在执行。
+
+信息同步模式：「通过共享上下文」实现协作
+
+但对于更复杂、需要完整历史记录的场景，简单的任务委托是远远不够的。
+
+Manus 的思路是，通过共享上下文来实现协作。子 Agent 被创建时，能够看到主 Agent 完整的先前上下文，包括所有的历史工具调用和观察。但这个子 Agent 拥有自己独立的系统提示词和新的行动空间。
+
+这种模式，更适用于高度依赖历史信息、需要综合分析的任务。比如，在进行一项深度研究任务时，最终的研究报告需要综合大量的中间搜索结果和笔记。
+
+如果使用第一种通信模式，主 Agent 需要将所有中间产物写入文件，再让子 Agent 去一一读取，这会造成巨大的延迟和额外的 Token 消耗。在这种情况下，直接让子 Agent 继承完整的上下文反而会更高效。
+
+但 Manus 也提到，共享上下文的模式成本是相当昂贵的。因为每个子 Agent 启动时都需要 Prefill 一个非常大的输入，并且因为系统提示词不同，无法复用主 Agent 的 KV 缓存，所以必须支付全价。
+
+所以，需要根据任务的性质，灵活地在这两种模式中间进行选择。
+
+多 Agent 通信，发信息不难，难的是收结果
+
+多 Agent 通信的一个难点是「接收」，如何从多个并行工作的子 Agent 那里，获得结构一致、内容准确的输出？
+
+Manus 设计了一套内部代号叫做「Agent 化的 MapReduce」的系统。简单来说，
+
+共享沙箱
+
+每个 Manus 会话都在一个完整的虚拟机沙箱中运行。当主 Agent 创建子 Agent 时，共享同一个沙箱。这意味着，共享同一个文件系统，信息的传递可以简单到只传递不同的文件路径，解决了输入信息同步的问题。
+
+输出模式（Schema）
+
+这是关键。主 Agent 在创建子 Agent 之前，必须先定义一个输出的 Schema 。这个模式就是一份强制执行的 API 合同，规定了子 Agent 最终必须返回什么样的数据结构。
+
+约束解码
+
+子 Agent 有一个专用工具 submit_result。Manus 使用约束解码（Constrained Decoding）技术，强制子 Agent 提交的结果，必须严格符合主 Agent 定义的 Schema。
+
+这套设计的核心思路是，无论是做摘要还是 Agent 间通信，都反复使用模式和结构化输出作为一种「契约」，来保证信息以结构化、完整的方式传递。
+
+## 04
+
+## 最后，聊聊两家的设计哲学
+
+最后，回到原点，聊聊这两家的上下文工程设计哲学。
+
+Cursor 的「Dynamic Context Discovery」，强调：少即是多。Cursor 认为，在最开始提供给模型的细节越少，效果反而越好，因为能让 Agent 更轻松地自行抓取相关的上下文。
+
+Manus 的思路是：「少构建，多理解」，避免上下文的过度工程化。上下文工程的目标是让模型的工作变得更简单，而不是更难。
+
+季逸超：回顾 Manus 发布以来的六七个月，我们见过的最大的飞跃，不是来自增加了更多花哨的上下文管理层或巧妙的检索技巧，它们都来自于简化，来自于移除不必要的技巧，以及对模型多一点的信任。
+
+每一次我们简化架构，系统都会变得更快、更稳定、更智能。上下文工程的目标是让模型的工作变得更简单，而不是更难。
+
+两家的实践大方向都是，从「如何把更多信息塞进上下文」，变成「怎么给 Agent 创建一个信息丰富、易于探索的外部环境」。
+
+引用宝玉老师的一句话：未来，随着基模能力的提升，把主动权交给模型会是一个趋势。
+
+更多阅读
+
+泛娱乐 AI 赛道观察： 从「猜你喜欢」到参与共创，角色才是 AI 时代最核心的资产
+
+两次拿到陆奇投资，张浩然这次想用 Agencize AI 干掉所有工作流 Agent
+
+AI 陪伴赛道复盘：2026 年了，为什么还没有一款千万级 DAU 的产品跑出来？
+
+想成为下一个 Manus，先把这些出海合规问题处理好
+
+转载原创文章请添加微信：founderparker
+
+内容中包含的图片若涉及版权问题，请及时与我们联系删除
+
+点赞 收藏 评论 分享到Link
+
+举报反馈
+
+举报类型（必选）
+
+- 其他
+- 内容涉黄
+- 政治相关
+- 内容侵权
+- 内容抄袭
+- 涉嫌广告
+- 样式问题
+
+举报详情（选填）
+
+0/200
+
+取消
+
+提交
+
+### 评论列表
+
+沙发等你来抢
+
+去评论
+
+### 评论
+
+登录后可提问交流
+
+沙发等你来抢
+
+# Manus 内部的 Context 工程经验（精校、高亮要点） | 人人都是产品经理
+URL: https://www.woshipm.com/ai/6244818.html
+Author: 一泽Eze
+
+Manus 内部的 Context 工程经验（精校、高亮要点） | 人人都是产品经理
+
+## Manus 内部的 Context 工程经验（精校、高亮要点）
+
+2025-07-21
+
+0 评论 2128 浏览 0 收藏 22 分钟
+
+构建AI智能体时，上下文工程是塑造其行为的核心。如何通过优化KV缓存、动态管理工具、利用文件系统拓展记忆等策略，让智能体更高效、稳定地运转？这些来自实践的经验，或许能为智能体开发提供关键指引。
+
+Manus 团队刚分享了他们构建 Agent 的 Context 工程经验。
+
+想来会对同样做 Context 工程、Agent 开发的朋友有所帮助。
+
+刚好我在自己读的过程中，对全文进行了精校翻译，并高亮要点与排版。来自一线的分享，总共 6 条经验，共 5K 字。
+
+也提炼了一份思维导图。不过还是建议直接阅读，不要省流。
+
+分享给你们，enjoy～
+
+From：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
+
+译文：《 AI 智能体的上下文工程：构建 Manus 的经验》
+
+2025 年 7 月 18 日，Peak @Manus
+
+在 Manus 项目启动之初，我们面临一个关键抉择：
+
+是应该利用开源基础模型，训练一个端到端的智能体模型？还是基于前沿大模型已有的上下文学习（in-context learning）能力，构建我们的智能体？
+
+在我投身 NLP 领域的头十年里，我们没有这样的选择。
+
+在遥远的 BERT 时代（没错，已经过去七年了），模型必须经过微调和评估，才能迁移到新任务上。即便那时的模型与今天的 LLM 相比小得可怜，但这个过程的每次迭代也常常需要数周时间。
+
+我上一个创业项目给我留下了一个惨痛的教训：对于快速迭代的应用，尤其是还没找到 PMF 之前，缓慢的反馈循环是致命的。
+
+当时我为开放信息提取（Open information extraction）和语义搜索从零开始训练模型。然而，GPT-3 和 Flan-T5 相继问世，我自研的模型一夜之间就过时了。颇具讽刺意味的是，也正是这些模型，开启了上下文学习的时代，并由此揭示了一条全新的路径。
+
+这个来之不易的教训让我们的选择变得清晰：Manus 决定押注在上下文工程上。
+
+这让我们能将改进的发布周期从数周缩短到几小时，并使我们的产品与底层模型的发展保持“正交”关系：如果说模型的进步是水涨船高的浪潮，我们希望 Manus 成为潮头上的船，而不是被固定在海底的石柱。
+
+尽管如此，上下文工程的实践远比想象的要复杂。
+
+上下文工程是一门实验科学——我们已经重构了四次 Agent 的框架，每一次都是因为发现了塑造上下文的更优方法。
+
+我们亲切地称这个手动进行架构搜索、调试提示词和经验猜测的过程为“随机研究生下降法”（Stochastic Graduate Descent）。
+
+虽然听起来不那么优雅，但确实有效。
+
+译者注：“研究生”在学术界和科技界，常常与“做实验、调参数、熬夜、靠直觉和运气”等形象挂钩，形容这个过程不是一个严谨、自动化的数学优化过程（如梯度下降），而是充满了人工调试、反复试错和“体力活”的探索。
+
+本文将分享我们通过自己的“SGD”找到的局部最优解。如果你也在构建自己的 AI Agent，希望这些原则能帮助你更快地收敛。
+
+- Flan-T5：https://arxiv.org/abs/2210.11416
+- GPT-3：https://arxiv.org/abs/2005.14165
+- Open information extraction：https://en.wikipedia.org/wiki/Open_information_extraction
+- BERT：https://arxiv.org/abs/1810.04805
+- In-context learning：https://arxiv.org/abs/2301.00234
+- Manus：https://manus.im/
+
+## 1）围绕 KV 缓存进行设计
+
+如果非要我只选一个指标，我会说 KV 缓存命中率 是生产环境中 AI 智能体最关键的单一指标。它直接影响延迟和成本。
+
+要理解其中缘由，我们先来看看典型 AI Agent （a typical agent）是如何运作的：在收到用户输入后，智能体通过一系列的工具调用链来完成任务。在每次迭代中，模型根据当前上下文，从预定义的动作空间中选择一个动作。该动作随后在环境（例如 Manus 的虚拟机沙箱）中执行，并产生一个观测结果。这个动作和观测结果会被追加到上下文中，形成下一次迭代的输入。这个循环持续进行，直到任务完成。
+
+你可以想象，上下文在每一步都会增长，而输出通常是结构化的 Function Call，相对较短。
+
+与聊天机器人相比，这使得智能体中预填充（prefilling）和解码（decoding）的比例严重倾斜。以 Manus 为例，其输入与输出的 token 数量比平均达到了 100:1。
+
+幸运的是，拥有相同前缀的上下文可以利用 KV 缓存（KV-cache）机制。
+
+无论你是自部署模型还是调用推理 API，都能极大降低首个 token 生成时间（TTFT）和推理成本。
+
+这带来的成本节约非同小可：以 Claude Sonnet 为例，命中缓存的输入 token 成本为 0.30 美元/百万 token，而未命中缓存的成本则为 3 美元/百万 token——相差整整十倍。
+
+从上下文工程的角度看，提升 KV 缓存命中率涉及几个关键实践：保持提示词前缀的稳定性。 由于大模型的自回归（autoregressive）特性，哪怕只有一个 token 的差异，也可能使缓存从该 token 之后开始失效。一个容易犯的错误是，在系统提示词的开头包含时间戳（尤其是精确到秒的时间戳）。它确实能让模型告诉你当前时间，但也会直接破坏你的缓存命中率。只对上下文进行追加（append-only）。 避免修改之前的动作或观测结果。确保你的序列化（serialization）过程是确定性的。许多编程语言和库在序列化 JSON 对象时，不保证键的顺序是固定的，这会在不知不觉中破坏缓存。在需要时明确标记缓存断点。 一些模型提供商或推理框架不支持自动的增量前缀缓存，而是需要手动在上下文中插入缓存断点。在分配断点时，要考虑到缓存可能的过期时间，并至少确保断点包含在系统提示词的末尾。
+
+此外，如果你在使用 vLLM 等框架自部署模型，请确保启用了 prefix / prompt caching ，并用 Session IDs 等技术保持分布式工作节点间的一致路由。
+
+- prefix / prompt caching：https://docs.vllm.ai/en/stable/design/v1/prefix_caching.html
+- vLLM：https://github.com/vllm-project/vllm
+- Autoregressive：https://en.wikipedia.org/wiki/Autoregressive_model
+- KV-cache：https://medium.com/@joaolages/kv-caching-explained-276520203249
+- A typical agent：https://arxiv.org/abs/2210.03629
+
+## 2）遮蔽（Mask），而非移除
+
+随着智能体能力的增加，其动作空间（action space）自然会变得愈发复杂。直白地说，就是工具的数量会爆炸式增长。
+
+最近 MCP 的流行更是火上浇油。如果你允许用户配置工具，相信我：总会有人把你精心构造的动作空间里，塞进上百个来历不明的工具。其后果是，模型更容易选错行动或采取低效路径。
+
+简而言之，你构造出来的智能体反而会变笨。
+
+一种自然的想法是设计一个动态的动作空间——比如类似 RAG 一样，按需动态加载工具。（我们在 Manus 中也尝试过）
+
+但我们的实验揭示了一条清晰的规则：除非绝对必要，否则避免在迭代中途动态增删工具。
+
+主要原因有二：
+
+1. 在大多数大模型中，工具定义在序列化后通常位于上下文的靠前位置，通常位于系统提示词之前或之后。因此，任何更改都会导致后续所有动作和观测的 KV 缓存失效。
+
+2. 当此前的动作和观测仍然引用着当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码（constrained decoding），这通常会导致模式违规或产生幻觉动作。
+
+为了解决这个问题，同时又能优化动作选择，Manus 使用一个上下文感知的状态机（state machine）来管理工具的可用性。它并不移除工具，而是在解码阶段遮蔽掉 token logits，从而根据当前上下文，阻止（或强制）模型选择某些动作。
+
+在实践中，大多数模型提供商和推理框架都支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间。
+
+函数调用通常有三种模式（我们以 NousResearch 的 Hermes format 为例）：自动（Auto）：模型可以选择调用函数，也可以不调用。通过仅预填充回复前缀实现：<|im_start|>assistant必需（Required）：模型必须调用一个函数，但具体调用哪个不受限制。通过预填充至工具调用 token 实现：<|im_start|>assistant 指定（Specified）：模型必须从一个特定的子集中调用函数。通过预填充至函数名的开头实现：<|im_start|>assistant {“name”: “browser_
+
+利用这一点，我们通过直接遮蔽 token logits 来约束动作选择。
+
+例如，当用户提供新输入时，Manus 必须立即回复，而不是执行动作。
+
+我们还有意地设计了具有一致性前缀的动作名称——例如，所有浏览器相关的工具都以 browser_ 开头，而命令行工具则以 shell_ 开头。这使得我们能够在特定状态下，轻松地强制智能体只能从某一类工具中进行选择，而无需使用有状态的 logits 处理器。
+
+这些设计有助于我们确保 Manus 的智能体 loop 在模型驱动的架构下，依然保持可靠稳定。
+
+- Hermes format：https://github.com/NousResearch/Hermes-Function-Calling
+- State machine：https://en.wikipedia.org/wiki/Finite-state_machine
+- Constrained decoding：https://platform.openai.com/docs/guides/structured-outputs
+- RAG：https://en.wikipedia.org/wiki/Retrieval-augmented_generation
+- MCP：https://modelcontextprotocol.io/introduction
+
+## 3）将文件系统作为上下文
+
+现代前沿大模型如今已提供高达 128K 甚至更长的上下文窗口。但在真实的智能体场景中，这往往还不够，有时甚至是一种负担。
+
+这里有三个常见痛点：
+
+1. 观测结果（Observations）可能极其庞大，尤其是当智能体与网页、PDF 等非结构化数据交互时，轻易就可能撑爆上下文长度限制。
+
+2. 即便窗口技术上支持，模型的性能在超过一定上下文长度后往往会下降。
+
+3. 长输入非常昂贵，即使有前缀缓存。你仍然需要为每个 token 的传输和预填充付费。
+
+为应对此问题，许多智能体系统采用了上下文截断或压缩策略。
+
+但过于激进的压缩不可避免地会导致信息丢失。这是一个根本性问题：智能体的天性决定了它必须基于所有先前的状态来预测下一个动作，因为你无法可靠地预测十步之后，之前的哪个观测结果会变得至关重要。
+
+从逻辑上讲，任何不可逆的压缩都伴随着风险。
+
+因此，我们将文件系统视为 Manus 的终极上下文：它容量无限，天然持久，并且智能体自身可直接操作。模型学习如何按需读写文件——不仅是将文件系统用作存储，更是将文件系统当作结构化的外部记忆体。
+
+我们的压缩策略始终被设计为可恢复的。
+
+例如，只要保留了网页的 URL，其内容就可以从上下文中丢弃；只要文档在其沙箱中的路径可用，其内容也可以被省略。
+
+这使得 Manus 可以在不永久丢失信息的前提下，缩减上下文长度。
+
+在开发此功能时，我常常思考，要让一个状态空间模型（SSM）在智能体场景中有效工作需要什么。与 Transformer 不同，SSM 缺乏全局注意力，难以处理长程的回溯依赖。但如果它们能掌握基于文件的记忆——将长期状态外化，而不是保留在上下文中——那么它们的速度和效率或许能开启一类全新的智能体。具备智能体能力的 SSM，或许才是 Neural Turing Machines 真正的继承者。
+
+Neural Turing Machines：https://arxiv.org/abs/1410.5401
+
+## 4）通过“复述”来操控注意力
+
+如果你用过 Manus，你可能已经注意到一个有趣的现象：在处理复杂任务时，它倾向于创建一个名为 todo.md 的文件，并随着任务的进展逐步更新它，勾掉已完成的项。
+
+这并不仅仅是为了看起来“可爱”，而是一种精心设计的注意力操控机制。
+
+在 Manus 中，一个典型任务平均需要约 50 次工具调用。
+
+这是一个很长的循环——由于 Manus 依赖大模型进行决策，它很容易出现偏离主题或忘记早期目标等问题，尤其是在长上下文或复杂任务中。
+
+通过不断重写待办事项列表，Manus 实际上是在将任务目标“复述”到上下文的末尾。
+
+这会将全局计划注入到模型的近期注意力范围，从而避免“中间遗忘”（lost-in-the-middle）问题，并减少目标偏离。
+
+实际上，它是在不依赖特殊架构的情况下，用自然语言来引导自身的注意力，使其聚焦于任务目标。
+
+## 5）保留出错记录
+
+Agent 会犯错。这不是 bug，而是现实。
+
+语言模型会产生幻觉，环境会返回错误，外部工具会出故障，各种意想不到的边界情况层出不穷。
+
+在多步任务中，失败不是例外，而是循环的一部分。
+
+然而，一种常见的冲动是隐藏这些错误：清理痕迹、重试动作，或者重置模型状态，然后把它交给神奇的“温度（Temperature）”。这似乎更安全、更可控。
+
+但它是有代价的：消除失败记录，也就消除了过往的行动证据。而没有过往的行动证据，模型就无法适应。
+
+根据我们的经验，提升智能体行为最有效的方法之一简单得令人意外：将失败的尝试保留在上下文中。
+
+当模型看到一个失败的动作——以及由此产生的观测结果或堆栈跟踪（stack trace）——它会隐式地更新其内部认知，改变它对相似动作的先验判断，从而减少重复犯同样错误的可能性。
+
+事实上，我们认为错误恢复能力是真正智能体行为最明确的标志之一。
+
+然而，在多数学术研究和公开基准测试中，这一点仍然没有得到充分的体现，它们往往只关注理想条件下的任务成功率。
+
+Temperature：https://arxiv.org/abs/2405.00492
+
+## 6）不要陷入 Few-Shot 陷阱
+
+Few-shot Prompting 是一种改进大模型输出的常用技术。但在 Agent 系统中，它可能会以一些微妙的形式，适得其反。
+
+语言模型是出色的模仿者，它们会模仿上下文中的行为模式。
+
+如果你的上下文中充满了相似的“动作-观测结果”对，模型就会倾向于遵循这种模式，即便这种模式已不再是最佳选择。
+
+这在涉及重复性决策或动作的任务中可能很危险。
+
+例如，在使用 Manus 协助审阅 20 份简历时，智能体常常会陷入一种惯性节奏——仅仅因为它在上下文中看到了类似的行为，就不断重复相似的动作。这会导致行为漂移、过度泛化，有时甚至产生幻觉。
+
+解决方法是增加多样性。
+
+Manus 会在动作和观测结果中引入少量结构化的变动——使用不同的序列化模板、变换措辞、在顺序或格式上引入微小的噪音。这种受控的随机性有助于打破模式，调整模型的注意力。
+
+换言之，不要让自己陷入“少样本”的思维定势中。
+
+上下文的模式越单一，智能体的行为就越脆弱。
+
+Few-shot Prompting：https://www.promptingguide.ai/techniques/fewshot
+
+## 结语
+
+上下文工程仍是一门新兴的学科，但对于 Agent 系统而言，它已至关重要。
+
+模型也许会变得更强、更快、更便宜，但无论原始能力有多强，都无法取代对记忆、环境和反馈的需求。
+
+你如何塑造上下文，最终定义了智能体的行为方式：它的运行速度、恢复能力以及扩展的潜力。
+
+在 Manus，我们通过反复的重构、失败的尝试以及面向数百万用户的真实世界测试，才学到了这些经验。
+
+我们在此分享的一切并非是放之四海而皆准的真理，但这些模式对 Manus 行之有效。
+
+如果它们能帮你哪怕只减少一次痛苦的迭代，这篇文章的目的就达到了。
+
+智能体的未来，将由一个个上下文构建而成。
+
+Engineer them well～
+
+本文由人人都是产品经理作者【一泽Eze】，微信公众号：【一泽Eze】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
+
+题图来自Unsplash，基于 CC0 协议。
+
+收藏已收藏{{ postmeta.bookmark }} 点赞已赞{{ postmeta.postlike }}
+
+更多精彩内容，请关注人人都是产品经理微信公众号或下载App
+
+Manus 技术原理 经验分享
+
+一泽Eze
+
+公众号：一泽Eze｜知名AI提示工程师，单条prompt全网10w+阅读量
+
+24篇作品 79115总阅读量
+
+产品经理如何应对变化？
+
+数据产品需求文档自查清单，让你的需求文档更加无可挑剔
+
+1688，是时候思考如何更好的服务C端“平替需求”了
+
+年中盘点 | 小红书最新动态及种草趋势
+
+从产品经理角度，看待猎奇网红食品
+
+大厂卷向扁平化
+
+社交电商——小红书竞品分析
+
+如何设计销售CRM×运营CRM×社交化SCRM系统？（九） 如何设计会员体系系统？
+
+# 【深度專題】Context Engineering 是什麼？為什麼 Manus 團隊花千萬美金踩坑，只為搞懂「怎麼喂模型」？
+URL: https://www.aiposthub.com/context-engineering-ai-agent-manus-principles/
+
+【深度專題】Context Engineering 是什麼？為什麼 Manus 團隊花千萬美金踩坑，只為搞懂「怎麼喂模型」？
+
+## 什麼是上下文工程（Context Engineering）？
+
+在生成式 AI 崛起後，越來越多開發者開始打造 AI Agent：讓語言模型像助理一樣，連續思考、多步操作、甚至自己規劃任務。這些 Agent 不需要自己「從零訓練一個模型」，因為 GPT-4、Claude、Gemini 等模型已經夠聰明了——真正的挑戰，變成了「你餵進去的上下文好不好」。
+
+### 所謂「上下文」，其實就是模型的輸入
+
+對語言模型來說，它不記得你是誰，也不會主動學習，它只會根據「這一次輸入的內容」來猜下一個字要說什麼。這次的輸入，就是上下文（context）。
+
+所以，如果你希望一個 AI Agent 有記憶、有邏輯、有工具使用能力，那你就必須：
+
+- 幫它整理資訊（壓縮 / 儲存觀察到的資料）這一切的「設計上下文流程」的技術，就叫做 Context Engineering。
+- 教它怎麼執行工具（Tool 使用規則）
+- 讓它記得前面發生過什麼事（歷史輸入/輸出）
+- 給它一個設計好的系統提示（system prompt）
+
+### 你可以把 Context Engineering 想像成「餵模型吃好吃的 prompt 食譜」：
+
+就像一位語言模型是天才廚師，但你不給食材、或亂給食材，它也煮不出你想吃的東西。Context Engineering 就是那位掌控食材的人——它決定：
+
+- 任務怎麼規劃：先做什麼？做完要不要複查？錯了要怎麼補救？
+- 記憶怎麼儲存：要放進上下文嗎？還是寫進檔案？
+- 資料怎麼整理：要 JSON 嗎？還是 YAML？還是像自然語言？
+- Prompt 要怎麼寫：清楚、具體、有格式
+
+這一切都不改模型本身，只透過喂它更好的上下文，就能大幅改變它的表現。
+
+### Manus 團隊：用千萬美金踩坑後得出的設計哲學
+
+Manus 是一個 AI agent 平台，從一開始就做出了一個與眾不同的決定：
+
+> ❝ 不自己訓練模型，也不靠微調，而是全力投注在 Context Engineering 上。 ❞
+
+他們在實作過程中踩遍各種地雷、重寫了 6 次框架，最終把經驗整理成一套極具參考價值的準則，稱得上是「實戰中淬鍊出的上下文工程七大原則」。
+
+這些原則背後，並不是空泛的哲學，而是與現實中的 API 成本、執行延遲、錯誤率、使用體驗息息相關的架構設計關鍵。
+
+接下來，我們就來逐條拆解這七個 Manus 團隊的「Context Engineering 生存法則」，看看如何透過 prompt、記憶、工具與錯誤處理的精細設計，讓一個 AI Agent 真的能用、能學、能修正。
+
+---
+
+## Manus AI 團隊七大實戰心法：反共識卻實用
+
+### 上下文工程比自己訓練模型更香
+
+> ❝ 別造輪子，造路給模型走就夠了。 ❞
+
+Manus 團隊一開始就做出戰略選擇：不訓練自己的模型，而是用現成的大模型＋自己控制上下文。這樣不但能更快出產品，每次模型更新（例如 Claude、GPT 升級）也能立刻受益。
+
+### KV-Cache 命中率是效能的命門
+
+> 一個 prompt prefix 不穩，就讓你損失 10 倍成本。
+
+KV-Cache（Key-Value Cache） 是大模型記憶機制的一部分，若上下文前綴保持一致，就能節省大量重複計算。例如：Claude Sonnet 的 cache 命中每 1M tokens 僅需 $0.3 美元，未命中則要 $3！
+
+避免 cache 失效的技巧包括：
+
+- 不動舊內容，只 append 新訊息
+- JSON 序列要穩定（key 順序一致）
+- Prompt 前綴不能動（不能加 timestamp）
+
+### 上下文只能「加」，不能「改」
+
+> 就像寫日記，不能刪昨天的內容。
+
+這是為了維持上下文一致性與 cache 命中率。哪怕只改了一行錯字或換了格式，都可能導致重新編碼整個上下文。最好的做法是：永遠追加、永不修改。
+
+### 工具多，不代表要亂加減
+
+> ❝ 遮蔽程式碼比刪除更聰明。 ❞
+
+當 Agent 能使用的工具越來越多（例如 plugin、生成功能等），你會想根據任務刪掉無用工具。但這會讓上下文改變，導致 cache 崩潰＋模型混亂。
+
+Manus 的做法是「不刪除工具，只在解碼時用 token 掩碼遮住它們」，讓模型看不到不該選的選項。例如：
+
+- `shell_`是終端工具這種命名讓模型能按情境選工具，上下文卻維持不變。
+- `browser_`開頭的是網頁工具
+
+### 檔案系統是「外掛記憶」
+
+> 大語言模型記憶有限，但檔案系統沒限制。
+
+當 agent 執行複雜任務時，可能會與 PDF、網頁、Codebase 等交互，大量內容無法塞進上下文。
+
+Manus 的解法：直接讓模型學會寫入/讀取 sandbox 中的檔案。只要記住「檔案路徑」，需要時再抓內容回來，這讓 context 永遠保持輕巧，但 agent 卻像有無限記憶一樣聰明。
+
+### 錯誤紀錄是 agent 成長的關鍵
+
+> 別刪錯誤訊息，那是模型學會「別再做傻事」的依據。
+
+模型會犯錯，像選錯工具、看錯格式、工具回傳錯誤等。不要清掉這些紀錄，因為 留下錯誤紀錄，模型才能調整行為。這是一種「自然語言式的 reinforcement」。
+
+### Few-shot 太單一，模型會陷入套路
+
+> 多樣化提示，才有多樣化行為。
+
+過去提示學習講求「一致性」，但對 Agent 來說，過度一致會導致「模式僵化」。例如讓 Agent 檢查 20 份履歷，它會逐漸「進入機械模式」，開始複製貼上、不看上下文。
+
+解法是：加入微小變異（phrasing、順序、格式等），讓模型「保持清醒」，不被自己的例子誤導。
+
+## 結論：真正的 Agent 時代，不靠大模型，而靠上下文工程
+
+AI Agent 的真正威力，不在於模型有多強，而在於能不能處理複雜上下文、連續任務與不確定環境。
+
+這篇 Manus 團隊的 blog，展示了「模型升級靠 OpenAI，Agent 智慧靠你自己」的關鍵觀念。如果你正要做 AI 應用，這 7 條上下文設計原則，可能會讓你少走 3 個月冤枉路、少燒 3 萬美金。
+
+## Source:
+
+Context Engineering for AI Agents: Lessons from Building Manus
+
+## Read more
+
+### NVIDIA 佈局 AI Agent ！推出NemoClaw，終結 AI 代理市場的亂象
+
+NVIDIA 計畫推出名為 NemoClaw 的開源 AI 代理平台，目標是讓企業能夠建立並部署自己的 AI agents，用來自動化完成各種工作流程與任務。在 NVIDIA 年度開發者大會 GTC 將公布更多細節。 10 Mar 2026
+
+### Cortical Labs 開設全球首座「人腦細胞驅動」資料中心：活體神經元取代傳統晶片，顛覆 AI 運算未來
+
+澳洲生物科技新創公司 Cortical Labs 於 2026 年 3 月 10 日正式宣布，在澳洲墨爾本揭幕全球首座生物資料中心，並同步與新加坡合作夥伴 DayOne Data Centers 啟動第二座設施建設。這些資料中心不使用傳統矽晶片，而是以實驗室培養的「活體人類腦細胞」作為運算核心——這是人類首次將「濕件運算（Wetware Computing）」技術部署於商業資料中心環境中。 10 Mar 2026
+
+### AI 寫 code、AI 審 code，工程師的下一步是什麼？Claude Code Review 正式登場
+
+本週大家都在爭論 AI 發展是否已經撞上「算力之牆」，但 OpenAI 的研究員 Noam Brown 很自豪地說出了 "We see no wall" ，並推出 GPT-5.4，標榜的是「超越人類控制電腦的能力」（必須說，我個人對於 Computer use 的想法是捨近求遠） 。 然而，當技術端宣告無上限進化的同時，Anthropic 的最新研究卻揭露了一個更殘酷的現實：AI 確實還沒開始大規模裁員，但職場新鮮人的求職入口已經被這堵「看不見的牆」擋住了。 接著馬上讓我們進入本週的五件 AI 大事，搭配觀察筆記 讓你不只是看熱鬧，也能看懂門道。 AIPost Academy：影響力講師合作計畫（限額審核） 與其擔心被自動化取代，不如成為定義自動化的人。 AI 郵報學院正式啟動「首批影響力講師計畫」 10 Mar 2026
+
+### 【AI工具地圖】DomoAI 是什麼？AI 一鍵把圖片變影片、角色開口說話
+
+DomoAI 是一款 AI 圖片與影片生成平台，可以將圖片轉成動畫、讓角色開口說話，甚至用 AI 直接生成影片。本篇完整教學將帶你了解 DomoAI 的核心功能，以及 Nano Banana 圖片編輯與 Talking Avatar 的實際操作流程，新手也能快速上手。 lock-1 09 Mar 2026
+
+# 大白话读懂Manus 上下文优化策略 - 文章 - 开发者社区 - 火山引擎
+URL: https://developer.volcengine.com/articles/7542490848336805907
+
+大白话读懂Manus 上下文优化策略 - 文章 - 开发者社区 - 火山引擎
+
+
+
+
+
+文档 备案 控制台 登录 立即注册
+
+
+
+首页
+
+AI 大模型体验中心
+
+动手实验室
+
+Agent 评测集
+
+AI 案例广场 学习中心
+
+社区
+
+去发布
+
+首页
+
+AI 大模型体验中心
+
+动手实验室
+
+Agent 评测集
+
+AI 案例广场 学习中心
+
+社区
+
+# 大白话读懂Manus 上下文优化策略
+
+木乐乐数据
+
+技术
+
+技术
+
+究竟是花时间费力气去训练模型，还是基于最新最强的模型，再通过上下文学习能力构建一个智能体？
+
+相信这个是所有 AIAgent 开发者都会面临的问题。
+
+在朋友的鞭策下，我研究了7月19日 Manus 联合创始人兼首席科学家季逸超（Yichao 'Peak' Ji）的《Context Engineering for AI Agents: Lessons from Building Manus》文章。
+
+在这篇文章中，季逸超慷慨的把 Manus迭代多次的策略手动架构搜索、提示调整和经验猜测的过程总结了出来。那么，他们以"SGD"命名，是如何达到局部最优解？今天，我把Manus的优化策略，用小白都能听得懂的方法讲给你听。
+
+首先，直接一句话总结：
+
+“别去训练模型，去训练上下文。”
+
+与其花几周去微调模型，不如花几小时去设计上下文（prompt、工具、缓存、文件系统），让大模型在现有能力下表现得像个专业 Agent。
+
+接下来，把每个优化策略，逐个说清楚，讲明白。
+
+策略一： KV-Cache 命中率，为什么它比你想的更重要？
+
+想象你在玩一个文字冒险游戏，每次你输入一个动作，游戏都要重新加载前面的剧情。如果前面的剧情每次都要重新加载，游戏就会卡到爆炸。
+
+- KV-Cache 是大模型用来“记住”前面说过的内容的缓存。
+- 如果你每次对话的开头都变一点点（比如加了个时间戳），缓存就失效了，模型得重新算一遍前面所有内容。
+- 结果就会导致 延迟变高，成本暴增。（以Claude -sonnet 4 的 api 价格为例：缓存命中 0.3 美元/百万 token，不命中 3 美元，差 10 倍）。
+
+## 那么，该怎么做？
+
+- ✅ 固定前缀：系统提示（system prompt）别动。
+- ✅ 追加式更新：别改历史记录，只追加新内容。
+- ✅ 显式缓存断点：告诉系统“这里可以缓存”。
+
+策略二：Mask，不要 Remove：工具太多怎么办？
+
+工具（函数调用）太多，模型容易选错，而且流行的MCP只会火上浇油。
+
+直接动态加载/卸载工具会破坏缓存（KV-Cache），还会让模型困惑（历史动作引用了已删掉的工具）。
+
+这好比你开了一家餐厅，菜单上有 500 道菜。顾客点菜时眼花缭乱，厨师也容易做错。
+
+你可能会想：“那把菜单藏起来一部分？”——但这样顾客会点不到菜，厨师也会晕。
+
+## 怎么做？
+
+- ✅ 不删工具，只“遮”工具：用“logit masking”技术，告诉模型“现在你只能选这几个工具”，而不是真的从上下文里删掉。
+- ✅ 工具命名规范：比如所有浏览器工具都叫`browser_*`，方便按前缀统一遮罩。
+
+策略三：用文件系统当“无限记忆”
+
+假设你的大脑只能记住最近 10 分钟的事，同时你有一个无限大的笔记本，可以随时翻找。
+
+你会怎么做？——把重要信息写进笔记本，忘记时先翻一下重要的信息。
+
+同样的，虽然现在的大模型上下文窗口越来越大，但是也架不住你疯狂的加码。
+
+- 大模型的上下文窗口再大（比如 128K），也可能不够装整个网页或 PDF。
+- 压缩或截断会丢失信息，而且不可恢复。
+
+## 怎么做？
+
+- ✅ 把文件系统当外脑：让 Agent 自己读写文件（如`.md`,`.json`）。
+- ✅ 可逆压缩：比如网页内容可以暂时从上下文里删掉，但保留 URL，需要时再爬。
+- ✅ 未来展望：如果 State Space Model（SSM）也能学会用文件系统，可能比 Transformer 更快更省。
+
+策略四：用“复述”来操控注意力
+
+你正在做一个复杂的项目，怕忘记目标，于是每做完一步就把目标写在便利贴上，贴在屏幕边。
+
+每次走神时，看一眼就拉回来。
+
+- 在长任务中，模型容易“跑偏”或“忘记初心”。
+- 通过反复把目标写在上下文末尾（比如`todo.md`），让模型每次决策时都“看到”目标。
+
+## 怎么做？
+
+- ✅ 动态更新 todo 文件：每完成一步，就更新并重新读入上下文。
+- ✅ 自然语言操控注意力：不需要改模型架构，只需要让目标总在“最近记忆”里。
+
+策略五：别把错误藏起来，让模型从失败中学习
+
+你学骑自行车，摔了一跤。如果把这段记忆删掉，下次你还会在同一个地方摔。但如果你记得“上次这里有个坑”，你就会绕开。
+
+- 很多系统会自动“清理”失败的工具调用或报错，让上下文看起来更“干净”。
+- 但这会让模型重复犯错。
+
+## 怎么做？
+
+- ✅ 保留错误信息：把报错、空结果、失败动作都留在上下文里。
+- ✅ 让模型自己调整：看到“上次`git push`失败了”，下次它可能会先检查权限。
+
+策略六： 别让模型“死记硬背”：避免 Few-Shot 陷阱
+
+如果你教小孩做题，每次都给他看一模一样的例题。最终的结果是，他只会套模板，题目一变就不会了。
+
+- 如果上下文里全是类似的“动作-结果”对，模型会机械模仿。
+- 这会导致“漂移”或“幻觉”。
+
+## 怎么做？
+
+- ✅ 增加多样性：同样的动作用不同格式写，偶尔打乱顺序，加点噪音。
+- ✅ 打破模式：让模型每次都“重新思考”，而不是复制粘贴。
+
+原文链接： https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
+
+0
+
+0
+
+0
+
+0
+
+点赞评论收藏
+
+关于作者
+
+
+
+木乐乐数据
+
+关于作者
+
+
+
+木乐乐数据
+
+文章
+
+0
+
+获赞
+
+0
+
+收藏
+
+0
+
+相关资源
+
+云原生数据仓库ByteHouse性能白皮书（企业版）
+
+如何让万台节点的OLAP性能大涨？
+
+点击下载
+
+相关产品
+
+推荐阅读
+
+『NAS』请显卡吃毒蘑菇，用Volume Shader BM测GPU性能
+
+『NAS』告别片荒，全网资源一键搜，CloudSaver 部署全攻略
+
+2025远程桌面软件年终推荐榜单：ToDesk、RustDesk、向日葵、UU和QQ远程
+
+Python 如何高效抓取股票实时行情数据？
+
+『NAS』在飞牛部署 Solara 开源音乐播放器，无损音乐听下两不误！
+
+评论
+
+未登录
+
+看完啦，登录分享一下感受吧～
+
+暂无评论
+
+window.mermaid.init({ noteMargin: 10 }, '.language-mermaid'); --
+
+# 上下文工程崛起：Manus天才少年Peak Ji揭示AI Agent核心突破 - 53AI-AI知识库|企业AI知识库|大模型知识库|AIHub
+URL: https://www.53ai.com/news/LargeLanguageModel/2025102619402.html
+
+上下文工程崛起：Manus天才少年Peak Ji揭示AI Agent核心突破 - 53AI-AI知识库|企业AI知识库|大模型知识库|AIHub
+
+2026年3月27日，来腾讯会议（限50人）了解掌握如何用Openclaw构建企业AI生产力
+
+抢占你的席位
+
+
+
+免费POC， 零成本试错
+
+首页
+
+产品服务
+
+热门场景
+
+工作+AI 大模型提升全员工作效率
+
+工作对话
+
+内容创作
+
+方案撰写
+
+魔法菜单
+
+业务+AI 大模型掌握企业知识与流程
+
+微信分身
+
+海外客服
+
+官网客服
+
+抖音客服
+
+数字老师
+
+数字督导
+
+智能服务台
+
+AIx业务 大模型驱动产品智能化改造
+
+智能问数
+
+智能审核
+
+智能工单
+
+企微跟进助手
+
+智能报价
+
+企微销售助手
+
+应用智改
+
+企微客服助手
+
+落地咨询
+
+ConsultingAI生产力教练了解更多 >
+
+场景共创
+
+Co-creationAI场景共创了解更多 >
+
+热门产品
+
+53AI Brain 让知识在人与AI之间高效流动
+
+53AI Studio 高准确率的企业级智能体开发平台
+
+53AI Hub开源 三分钟搭建出独立的企业AI门户
+
+53AI Browser “AI专家”效率倍增的秘密武器敬请期待...
+
+客户案例
+
+行业案例
+
+政府央国企 政府央国企大模型落地应用案例
+
+能源矿业 新能源与矿业大模型落地应用案例
+
+电子科技 电子科技行业大模型落地应用案例
+
+贸易流通 贸易流通大模型落地应用案例
+
+制造行业 高端制造行业大模型落地应用案例
+
+企科数服 企科数服行业大模型落地应用案例
+
+生物医药 生物医药行业大模型落地应用案例
+
+地产与消费品 地产与消费品行业大模型落地应用案例
+
+场景案例
+
+【智能问答】场景案例 让大模型掌握企业的知识和流程
+
+【应用智改】场景案例 让大模型融入企业的产品和业务
+
+【智能工单】场景案例 让大模型创建和受理业务工单
+
+【智能问数】场景案例 与业务系统数据对话式互动
+
+AI知识库
+
+企业AI落地知识库
+
+前沿技术
+
+大模型技术 多模态技术 RAG技术 知识图谱 模型微调 Skill 提示词技巧 开源大模型 智能硬件 Palantir
+
+Agent框架
+
+langchain llamaindex RAGFlow coze Dify Fastgpt Bisheng Qanything MaxKB Openclaw
+
+行业应用
+
+AI+汽车 AI+金融 AI+工业 AI+培训 AI+SaaS AI+电商 AI+医疗
+
+企业落地
+
+内容创作 个人提效 智能客服 AI面试 数字员工 ChatBI AI知识库 智能营销 智能化改造 Glean
+
+行业报告
+
+研究报告 行业报告 技术分享 专题报告 课件讲义
+
+关于我们
+
+公司介绍 渠道合作
+
+GitHub Star 9.1K+ 预约演示
+
+53AI知识库
+
+学习大模型的前沿技术与行业应用场景
+
+立即咨询 预约演示
+
+我要投稿
+
+# 上下文工程崛起：Manus天才少年Peak Ji揭示AI Agent核心突破
+
+发布日期：2025-10-26 15:19:23 浏览次数： 2150
+
+推荐语
+
+中国90后天才Peak Ji突破AI Agent性能瓶颈，揭秘上下文工程五大核心策略。 核心内容： 1. Peak Ji从iPhone破解者到AI创业者的技术成长之路 2. AI Agent面临的上下文爆炸挑战与性能下降问题 3. 解决上下文工程的五大策略：卸载、缩减、检索、隔离与优化
+
+杨芳贤
+
+53AI创始人/腾讯云(TVP)最具价值专家
+
+一个任务50次工具调用，上下文无限膨胀，性能急剧下降——这就是AI Agent面临的核心挑战。一位中国90后天才提出了革命性解决方案。
+
+在ChatGPT引爆全球AI热潮后，一个全新的领域——上下文工程正在悄然崛起。当各大科技公司还在比拼模型参数规模时，一位来自中国的年轻技术天才已经找到了让AI真正智能化的关键所在。
+
+他就是季逸超，更为人熟知的名字是Peak Ji，Manus的联合创始人兼首席科学家。近日在与LangChain的联合研讨会中，他揭示了构建高效AI智能体的核心技术——上下文工程，并分享了从数百万次真实交互中总结的宝贵经验。
+
+---
+
+# 01 天才之路：从iPhone破解者到AI创业者
+
+Peak Ji的技术天赋在少年时期就已显现。不到18岁，他就因成功升级iPhone OS 4.0系统而被誉为"中国iPhone OS 4.0第一人"。
+
+早在高中时期，他就独立开发了猛犸浏览器，并因此获得了真格基金和红杉资本的天使投资。
+
+凭借出色的技术成就，季逸超在19岁时就登上了《福布斯》杂志的封面，并多次入选"30岁以下精英榜"。
+
+他后来创立了Peak Labs实验室，并成为Manus的联合创始人兼首席科学家。作为《麻省理工科技评论》评选的2025年35岁以下创新者之一，他正带领团队在AI Agent领域开辟新的天地。
+
+---
+
+# 02 上下文工程：AI Agent的核心挑战
+
+随着AI Agents执行日益复杂的长期任务，其上下文窗口会因大量的工具调用而急剧膨胀，导致性能显著下降。
+
+LangChain的创始工程师Lance Martin在最近的联合研讨会中解释道："典型的任务可能需要大约50次工具调用，生产环境中的代理可能会进行长达数百轮的对话。"
+
+这就形成了一个核心矛盾：Agents的强大功能依赖于利用大量上下文信息，但模型的性能却会因为上下文过长而受损。
+
+Anthropic在一份关于"上下文腐烂"（context rot）的报告中确认了这一现象——随着上下文长度的增加，模型性能会显著下降。
+
+# 03 五大策略，解决上下文爆炸难题
+
+面对这一挑战，业界逐渐形成了一套系统的解决方案。Lance Martin总结了上下文工程的五大核心策略：
+
+### 上下文卸载
+
+将信息从核心的对话历史中移出，存放到外部系统（如文件系统），只在上下文中保留一个轻量级的引用。
+
+比如，将工具消息的输出转储到文件系统中，然后只向智能体返回必要的最简信息。
+
+### 上下文缩减
+
+通过总结或压缩来减少信息量，例如修剪旧的工具调用记录。
+
+Manus将缩减操作细分为两种：压缩和总结。压缩是一种可逆的缩减，而总结则是不可逆的精炼。
+
+### 上下文检索
+
+在需要时，按需从外部系统将信息取回。实现方式包括基于索引的语义搜索，或更简单的基于文件系统的搜索工具。
+
+### 上下文隔离
+
+通过将任务分解给多个子代理（sub-agents），每个子代理拥有自己独立的、更小的上下文窗口，从而实现关注点分离和上下文管理。
+
+### 上下文缓存
+
+对上下文信息进行缓存，以提高效率（这一点在Manus的实践中被特别提及）。
+
+---
+
+# 04 Manus实践：从理论到生产的核心洞见
+
+在Manus的官方技术博客中，Peak Ji分享了团队从四次重构和数百万次真实交互中总结的宝贵经验。
+
+### 围绕KV-Cache进行设计
+
+"如果我必须选择仅一个指标，我认为KV-cache命中率是生产阶段AI Agent最重要的单一指标。它直接影响延迟和成本。"
+
+Peak Ji解释道，在Manus中，平均输入与输出token比率约为100:1，这使得KV缓存优化变得至关重要。以Claude Sonnet为例，缓存的输入token成本为0.30美元/MTok，而未缓存的成本为3美元/MTok——相差10倍。
+
+### 掩码，而非移除
+
+随着Agent能力增强，其行动空间会自然变得更加复杂。Manus使用上下文感知的状态机来管理工具可用性，它不是移除工具，而是在解码过程中屏蔽token logits，防止基于当前上下文选择某些行动。
+
+### 将文件系统作为上下文
+
+"现代前沿大语言模型现在提供128K个token或更多的上下文窗口。但在真实世界的Agent场景中，这通常不够，有时甚至是一种负担。"
+
+Manus将文件系统视为终极上下文：容量无限、天然持久，并且代理可直接操作。模型学会按需读写文件——把文件系统不仅当作存储，更当作结构化、外化的记忆。
+
+### 通过"背诵"操控注意力
+
+在Manus中，一个典型任务平均需要约50次工具调用。这是一个很长的循环——Agent很容易在冗长上下文或复杂任务中偏离主题或遗忘早期目标。
+
+通过不断重写待办清单，Manus把目标"背诵"到上下文的末尾。这会将全局计划推入模型的近期注意力范围，避免了"迷失在半道"的问题，并减少了目标错位。
+
+---
+
+# 05 战略抉择：为何上下文工程胜过模型微调
+
+在创办Manus之前，Peak拥有超过十年的自然语言处理经验，他的上一个创业项目就是从零开始训练自己的语言模型。
+
+这段经历让他痛苦地认识到，过早地构建专用模型会带来巨大风险：
+
+- • 扼杀创新速度：产品的迭代速度完全被模型的迭代速度所限制。一个训练加评估的周期可能需要一到两周，这对于需要快速验证产品市场契合度的初创公司是致命的。
+- • 优化目标错位：在产品方向尚未完全明朗时，团队可能会花费大量时间去提升一些对产品价值可能毫无意义的基准测试分数。
+
+"初创公司应该尽可能长时间地依赖通用模型和上下文工程。"
+
+然而，随着产品成熟和开源基础模型的崛起，另一个陷阱也随之出现：用自有数据微调一个强大的基础模型，使其在特定用例上表现出色。
+
+Peak指出这同样是危险的，因为AI和Agents的早期阶段是极其脆弱的，底层技术可能一夜之间发生颠覆。
+
+MCP的发布就是一个典型例子——它彻底改变了Manus的设计，使其从一个紧凑、静态的行动空间，转变为一个几乎无限可扩展的系统。
+
+---
+
+# 06 技术精粹：压缩与总结的艺术
+
+上下文精简是上下文工程的核心技术之一，但Manus在实践中将其细分为两种截然不同但相辅相成的方法：压缩（Compaction）和总结（Summarization），并建立了一套严谨的工作流程来协同使用它们。
+
+### 压缩：可逆的信息外化
+
+压缩的核心思想是一种可逆的信息缩减。它并非真正地"减少"信息，而是将信息的一部分外化到上下文窗口之外的某个地方（如文件系统或外部状态），同时在上下文中保留足以重建完整信息的线索。
+
+具体例子：假设一个工具的功能是向文件中写入内容，它可能包含两个字段：path（路径）和content（内容）。一旦这个工具执行成功，我们就可以确定该文件已经存在于环境中。因此，在紧凑格式中，可以安全地丢弃可能非常长的content字段，只保留path。如果Agent后续需要再次读取该文件，它可以通过path轻松地检索到全部内容。
+
+可逆性至关重要：Agents的决策是链式的，基于之前的行动和观察。我们永远无法预知过去的哪个动作会在十步之后突然变得至关重要。可逆的压缩确保了没有任何信息被真正丢失，只是被暂时移出了即时上下文。
+
+### 总结：不可逆的谨慎精炼
+
+当仅靠压缩已无法将上下文大小控制在阈值以下时，就需要动用更传统的总结方法。总结是不可逆的，意味着信息会有损失，因此必须非常谨慎地使用。
+
+在执行总结之前，一个最佳实践是先将上下文中的关键部分卸载到文件中。在更激进的情况下，甚至可以将整个待总结的上下文作为一个文本或日志文件转储到file system中。
+
+### 基于阈值的工作流程
+
+为了让压缩和总结能够和谐共存，Manus设计了一套基于多层上下文长度阈值的自动化流程：
+
+- • 确定阈值：模型性能开始显著下降的实际阈值通常在128K到200K token之间。
+- • 触发压缩：当上下文长度接近"预腐烂阈值"时，首先触发压缩。
+- • 必要时总结：只有在多轮压缩后，上下文长度仍然接近性能"腐烂"的临界点时才会触发总结。
+
+---
+
+# 07 超越技术：一种新的工程哲学
+
+Peak Ji在研讨会尾声分享了一个深刻洞见：优秀的上下文工程不仅是技术组合，更是一种 "less is more" 的哲学。
+
+"回顾Manus发布过去的六、七个月，我们最大的性能提升并非来自添加更花哨的上下文管理层或更精巧的检索技巧，恰恰相反，它们都源于简化架构、移除不必要的技巧和更多地信任模型。"
+
+他总结道："上下文工程的目标是让模型的工作更简单而不是更复杂。如果要从今天分享中带走一句话，那就是——建造更少，理解更多。"
+
+---
+
+关注我并回复“上下文工程”，获取LangChain与Manus关于上下文工程的完整原始PPT资料
+
+大模型技术 大模型技术原理 大模型技术架构
+
+分享：
+
+53AI，企业落地大模型首选服务商
+
+产品：场景落地咨询+大模型应用平台+行业解决方案
+
+承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
+
+上一篇：AI出码率70%+的背后：高德团队如何实现AI研发效率的量化与优化 下一篇：如何让你的内容出现在AI生成的答案中？
+
+返回列表
+
+相关资讯
+
+2026-03-21编程选GPT-5.4，还是GPT-5.3-Codex？
+
+2026-03-21AI Coding前端实践后的复盘总结
+
+2026-03-21OpenAI 首席科学家：Codex 只是雏形，我们要造的是「全自动 AI 研究员」
+
+2026-03-21谷歌Stitch「氛围设计」干崩Figma 8.8%股价：十年经验，败给巨头一次更新（附实测）
+
+2026-03-21为什么 CLI 比 MCP 更适合 LLM
+
+2026-03-21渐进式披露（Progressive Disclosure）：Agent 从 Demo 到企业级落地的 “救命架构”
+
+2026-03-21AI 编程工具怎么选？Codex 和 Claude Code 的本质区别
+
+2026-03-21Karpathy 最新播客：我得了 AI 精神病、App 将消失、Agent 将碾压实验室
+
+联系获取
+
+联系获取
+
+160+中大型企业正在使用53AI
+
+立即咨询 预约演示
+
+把握AI发展的机遇，共同探索、共同进步2025-01-22
+
+如何打造基于GenAI的员工服务机器人2025-01-22
+
+
+
+热点资讯
+
+Pencil：设计和写代码，以后就全让AI干了 2026-01-24
+
+独家实录｜唐杰、杨植麟、林俊旸、姚顺雨...All Star 对话上，大家聊了啥？ 2026-01-10
+
+2026 开年 AI 工具推荐，让你新的一年效率起飞！（建议收藏） 2026-01-01
+
+从0到1玩转Clawdbot：我花了40小时，把这些坑都踩完了 2026-01-26
+
+终于！Gemini CLI支持Agent Skills，一键搬运Claude Code的“绝招” 2026-01-09
+
+Claude Code Skills 国内实践全指南：从安装部署到高阶开发 2026-01-09
+
+深度解析——为什么Claude code CEO Dario 如此反中？ 2026-01-23
+
+谷歌没想到：Antigravity 竟成了 Claude Code 的“免费充电宝”？ 2025-12-30
+
+不会封号的Claude Code使用方法！已稳定测试一个月，还能共享给团队。 2026-01-14
+
+我装了 9 个 Skill，终于看懂了 Google Antigravity 的野心 2026-01-21
+
+大家都在问
+
+编程选GPT-5.4，还是GPT-5.3-Codex？ 2026-03-21
+
+真实测评MiniMax M2.7，不吹不夸，它到底什么水平？ 2026-03-20
+
+深度分析：Agent Harness/框架到底有没有竞争壁垒？ 2026-03-19
+
+咨询 | OpenAI、Anthropic纷纷和咨询公司合作的背后，折射除了行业落地AI什么样的趋势？ 2026-03-19
+
+大伙都在养虾，MiniMax 带着新模型来偷偷上分了？ 2026-03-19
+
+Harness Engineering 为什么是 Agent 时代的“控制论”？ 2026-03-18
+
+阿里云新品发布：Agent ID Guard，谁来管理“小龙虾们”的身份安全？ 2026-03-17
+
+香港终于能直接用 Gemini 了，内地用户能用上吗？ 2026-03-17
+
+热门标签
+
+内容创作 大模型技术 个人提效 langchain llamaindex 多模态技术 RAG技术 智能客服 知识图谱 模型微调 RAGFlow coze Dify Fastgpt Bisheng Qanything AI+汽车 AI+金融 AI+工业 AI+培训 AI+SaaS Skill 提示词技巧 AI+电商 AI面试 数字员工 ChatBI AI知识库 开源大模型 智能营销 智能硬件 智能化改造 AI+医疗 MaxKB Palantir Glean Openclaw
+
+应聘简历请发送至： ceo@53ai.com
+
+产品服务
+
+工作+AI 工作对话 内容创作 方案撰写 魔法菜单
+
+业务+AI 微信分身 海外客服 官网客服 抖音客服 数字老师 数字督导 智能服务台
+
+AIx业务 智能问数 智能审核 智能工单 企微跟进助手 智能报价 企微销售助手 应用智改 企微客服助手
+
+落地咨询 场景共创
+
+客户案例
+
+行业案例 场景案例
+
+AI知识库
+
+前沿技术 Agent框架 行业应用 企业落地 结构化提示词
+
+关于我们
+
+公司介绍 渠道合作
+
+联系我们
+
+售前咨询
+
+186 6662 7370
+
+预约演示
+
+185 8882 0121
+
+微信扫码
+
+添加专属顾问
+
+回到顶部
+
+加载中...
+
+扫码咨询
+
+
+
+预约演示 微信咨询 电话咨询
+
+--
+
+# Manus 揭秘自己的7大核心技术：上下文工程架构设计与落地经验
+URL: https://blog.csdn.net/musicml/article/details/149521057
+Author: 成就一亿技术人!
+
+Manus 揭秘自己的7大核心技术：上下文工程架构设计与落地经验-CSDN博客
+# Manus 揭秘自己的7大核心技术：上下文工程架构设计与落地经验
+最新推荐文章于2025-11-10 15:42:21发布
+原创最新推荐文章于2025-11-10 15:42:21发布·794 阅读·14
+·28·
+CC 4.0 BY-SA版权
+版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。
+文章标签：#人工智能
+大家好，我是玄姐。
+▼全新《AI 大模型应用新架构师课程》重磅发布，预约保你有收获
+随着AI 智能体技术的快速发展，如何高效构建和优化 AI 智能体系统已成为业界关注的焦点。本文是对7月19日 Manus 联合创始人兼首席科学家季逸超（Yichao 'Peak' Ji）在撰写的《Context Engineering for AI Agents: Lessons from Building Manus》一文的整理。
+Image
+Manus 团队在构建AI 智能体过程中关于上下文工程的宝贵经验，包括： KV 缓存优化设计、动态动作空间管理设计以及利用文件系统作为扩展上下文等7大核心技术架构设计。
+这些经验不仅揭示了当前AI 智能体开发的技术架构设计的挑战和解决思路，也为未来  AI 智能体技术的发展提供了重要参考。下文我们详细剖析之，
+******—*1****—***
+****Manus 智能体6大核心技术剖析****
+1、围绕 KV 缓存进行设计如果必须选择一个关键指标，KV 缓存命中率无疑是生产环境中AI 智能体最重要的指标。KV 缓存是Transformer 模型中用于存储注意力计算结果的机制，高命中率意味着可以重用之前的计算结果，从而显著降低延迟和成本。
+#### 第一、KV 缓存的重要性典型AI 智能体的运作流程如下：
+用户输入后，AI 智能体通过一系列工具调用来完成任务。在每次迭代中，模型根据当前上下文从预定义的动作空间中选择一个动作，并在环境中执行（比如：Manus 的虚拟机沙盒环境，用于确保代码安全运行），从而产生观测结果。动作和观测结果被附加到上下文中，形成下一次迭代的输入，循环直到任务完成。
+由于AI 智能体的上下文随着每一步增长，而输出（通常是结构化的函数调用）相对较短，因此 AI 智能体的预填充（prefilling，一次性处理输入 token 的阶段）和解码（decoding，逐个生成输出 token 的阶段）比例与聊天机器人相比高度倾斜。比如：在 Manus 中，平均输入与输出 token 比例约为100:1。
+幸运的是，具有相同前缀的上下文可以利用 KV 缓存，这大大减少了首 token 时间（TTFT，Time-To-First-Token）和推理成本。比如：使用Claude Sonnet 时，缓存的输入 token 成本为0.30美元/百万 token，而未缓存的成本为3美元/百万 token，相差10倍。
+Image
+#### 第二、提高KV 缓存命中率的关键实践* **保持提示词前缀稳定**
+由于LLMs 的自回归特性（模型按顺序生成 token，每个 token 的生成都依赖于之前的所有token），即使是单个 token 的差异也可能使该token 之后的缓存失效。一个常见错误是在系统提示词的开头包含时间戳（特别是精确到秒的时间戳），这虽然能让模型告诉你当前时间，但会直接降低缓存命中率。
+* **使上下文仅追加（append-only）**
+避免修改之前的动作或观测结果，确保序列化过程是确定性的。许多编程语言和库在序列化 JSON 对象时不保证稳定的键排序，这可能会悄无声息地破坏缓存。
+* **明确标记缓存断点**
+一些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。分配这些断点时，要考虑潜在的缓存过期时间，并确保断点包含在系统提示词的末尾。
+此外，如果你使用 vLLM（一个高性能的 LLM 推理框架）等框架自托管模型，请确保启用前缀/提示词缓存，并使用会话 ID 等技术在分布式工作节点间一致地路由请求。2、遮蔽（Mask），而非移除
+随着AI 智能体能力的提升，其动作空间（action space）会变得愈发复杂，工具数量也会呈爆炸式增长。最近 MCP 的流行更是加剧了这一问题。如果允许用户配置工具，总有人会将大量不明来源的工具塞入精心设计的动作空间中，导致模型更容易选错行动或采取低效路径，从而使 AI 智能体变得迟钝。一种自然的想法是设计一个动态的动作空间，按需动态加载工具，在 Manus 中也尝试过这种方法。但实验表明，除非绝对必要，否则应避免在迭代中途动态增删工具，原因主要有以下两点：
+1. 在大多数大模型中，工具定义在序列化后通常位于上下文的靠前位置，通常在系统提示词之前或之后。因此，任何更改都会导致后续所有动作和观测的 KV 缓存失效。2. 当此前的动作和观测仍然引用着当前上下文中不再定义的工具时，模型会感到困惑。如果没有约束解码（constrained decoding），这通常会导致模式违规或产生幻觉动作。
+为了解决这个问题，同时又能优化动作选择，Manus 使用一个上下文感知的状态机来管理工具的可用性。它并不移除工具，而是在解码阶段遮蔽掉 token logits，从而根据当前上下文，阻止（或强制）模型选择某些动作。
+Image
+在实践中，大多数模型提供商和推理框架都支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束动作空间。函数调用通常有以下三种模式（以 NousResearch 的Hermes format 为例）：
+* **自动（Auto）**：模型可以选择调用函数，也可以不调用。通过仅预填充回复前缀实现：`<<|im\_start|>>assistant`。
+* **必需（Required）**：模型必须调用一个函数，但具体调用哪个不受限制。通过预填充至工具调用token实现：`<<|im\_start|>>assistant<<tool\_call>>`。
+* **指定（Specified）**：模型必须从一个特定的子集中调用函数。通过预填充至函数名的开头实现：`<<|im\_start|>>assistant<<tool\_call>>{""name"": ""browser\_""}`。
+利用这一点，我们通过直接遮蔽 token logits 来约束动作选择。比如：当用户提供新输入时，Manus 必须立即回复，而不是执行动作。
+我们还设计了具有一致性前缀的动作名称，比如：所有浏览器相关的工具都以`browser\_`开头，而命令行工具则以`shell\_`开头。这使得我们能够在特定状态下，轻松地强制 AI 智能体只能从某一类工具中进行选择，而无需使用有状态的 logits 处理器。这些设计有助于确保Manus 的AI 智能体loop 在模型驱动的架构下，依然保持可靠稳定。
+3、将文件系统作为上下文
+尽管现代前沿大模型已经能够支持高达128K 甚至更长的上下文窗口，但在实际的 AI 智能体应用场景中，这往往仍然不够，甚至有时会成为负担。以下是三个常见的痛点：
+* **观测结果过于庞大**
+当AI 智能体与网页、PDF 等非结构化数据交互时，观测结果可能极其庞大，很容易超出上下文长度的限制。
+* **模型性能下降**
+即使模型在技术上支持长上下文窗口，其性能通常会在上下文长度超过一定阈值后显著下降。
+* **成本高昂**
+长输入的成本非常高，即使有前缀缓存，你仍然需要为每个 token 的传输和预填充支付费用。为了解决这些问题，许多 AI 智能体系统采用了上下文截断或压缩策略。然而，过于激进的压缩不可避免地会导致信息丢失。这是一个根本性问题，因为 AI 智能体需要基于所有先前的状态来预测下一个动作，而你无法可靠地预测哪些观测结果在未来会变得至关重要。从逻辑上讲，任何不可逆的压缩都伴随着风险。
+#### 第一、文件系统作为终极上下文因此，我们将文件系统视为 Manus 的终极上下文解决方案。文件系统具有以下优势：
+Image
+* **无限容量**：文件系统的容量几乎是无限的。
+* **天然持久**：文件系统是持久化的，数据不会因为上下文的限制而丢失。
+* **直接操作**：AI 智能体可以直接操作文件系统，按需读写文件。
+模型不仅将文件系统用作存储，更是将其视为一个结构化的外部记忆体。通过这种方式，模型可以按需读写文件，而不是将所有信息都保留在上下文中。
+#### 第二、可恢复的压缩策略我们的压缩策略始终被设计为可恢复的，比如：
+* **网页内容**：只要保留了网页的 URL，其内容就可以从上下文中丢弃。
+* **文档路径**：只要文档在其沙箱中的路径可用，其内容也可以被省略。
+通过这种方式，Manus 可以在不永久丢失信息的前提下，有效缩减上下文长度。
+#### 第三、对状态空间模型的思考在开发此功能时，我常常思考，如何让一个状态空间模型（SSM）在 AI 智能体场景中有效工作。与Transformer 不同，SSM 缺乏全局注意力，难以处理长程的回溯依赖。但如果它们能够掌握基于文件的记忆——将长期状态外化，而不是保留在上下文中——那么它们的速度和效率或许能开启一类全新的 AI 智能体。具备AI 智能体能力的SSM，或许才是 Neural Turing Machines 真正的继承者。4、通过“复述”来操控注意力
+如果你使用过Manus，可能已经注意到一个有趣的现象：在处理复杂任务时，Manus 会创建一个名为`todo.md`的文件，并随着任务的进展逐步更新它，勾掉已完成的项。这并非只是为了看起来“可爱”，而是一种精心设计的注意力操控机制。
+Image
+在Manus 中，一个典型任务平均需要约50次工具调用。这是一个相当长的循环，由于 Manus 依赖大模型进行决策，很容易出现偏离主题或忘记早期目标的问题，尤其是在长上下文或复杂任务中。
+通过不断更新待办事项列表，Manus 实际上是在将任务目标“复述”到上下文的末尾。这将全局计划注入到模型的近期注意力范围，从而避免“中间遗忘”（lost-in-the-middle）问题，并减少目标偏离。实际上，这是一种用自然语言引导自身注意力的方式，使其聚焦于任务目标，而无需依赖特殊的架构。
+5、保留出错记录
+AI 智能体会犯错，这不是一个缺陷，而是现实的一部分。语言模型可能会产生幻觉，运行环境可能会返回错误，外部工具可能会出现故障，各种意想不到的边界情况也屡见不鲜。在多步骤任务中，失败并不是例外，而是整个流程的组成部分。
+然而，一个常见的做法是隐藏这些错误：清理错误痕迹、重试动作，或者重置模型状态，然后将其交给所谓的“温度（Temperature）”参数来调整。这种做法看似更安全、更可控，但却有代价：它消除了失败的记录，也就抹去了过往行动的证据。而没有这些证据，模型就无法从中学习和适应。
+Image
+根据我们的经验，提升 AI 智能体行为表现最有效的方法之一其实非常简单：将失败的尝试保留在上下文中。当模型看到一个失败的动作——以及由此产生的观测结果或堆栈跟踪（stack trace）——它会隐式地更新其内部认知，改变对相似动作的先验判断，从而减少重复犯同样错误的可能性。
+事实上，我们认为错误恢复能力是真正 AI 智能体行为最明确的标志之一。然而，在大多数学术研究和公开基准测试中，这一点仍然没有得到充分的体现，它们往往只关注理想条件下的任务成功率。
+6、不要陷入 Few-Shot 陷阱**Few-shot Prompting**是一种常用技术，用于通过少量示例提升大语言模型的输出表现。然而，在构建 AI 智能体系统时，它可能会带来一些意想不到的问题。
+语言模型本质上是出色的模仿者，它们会学习并模仿上下文中呈现的行为模式。如果上下文中充斥着大量相似的“动作-观测结果”对，模型往往会倾向于遵循这些模式，即使这些模式已经不再是最优选择。
+这在涉及重复性决策或动作的任务中尤其危险。比如：在使用 Manus 协助审阅20 份简历时，AI 智能体可能会陷入一种惯性节奏，仅仅因为它在上下文中看到了类似的行为，就不断重复相似的动作。这不仅会导致行为漂移和过度泛化，有时甚至会产生幻觉。
+Image
+为了解决这一问题，Manus 在动作和观测结果中引入了少量结构化的变动，比如：使用不同的序列化模板、变换措辞、在顺序或格式上引入微小的噪音。这种受控的随机性有助于打破单一的模式，调整模型的注意力，使其更加灵活。
+简而言之，不要让自己陷入“少样本”的思维定势中。上下文的模式越单一，AI 智能体的行为就越脆弱。多样化是提升AI 智能体稳定性和适应性的关键。#### 7、上下文工程：AI 智能体系统的核心上下文工程虽然还是一门新兴学科，但对于 AI 智能体系统来说，它已经变得至关重要。无论模型变得多么强大、快速或低成本，都无法替代对记忆、环境和反馈的需求。你如何塑造上下文，最终决定了AI 智能体的行为方式：它的运行速度、恢复能力和扩展潜力。
+#### 第一、Manus 的经验在Manus，我们通过不断的重构、失败的尝试以及面向数百万用户的真实世界测试，才逐步积累了这些宝贵的经验。我们分享的这些经验并非放之四海而皆准的真理，但它们对 Manus 来说是行之有效的。如果这些经验能帮助你减少哪怕一次痛苦的迭代，那么我们的分享就达到了目的。
+#### 第二、AI 智能体的未来AI 智能体的未来将由一个个精心设计的上下文构建而成。希望你能精心设计它们，让AI 智能体发挥出最大的潜力。Enjoy！
+PS：
+以上干货内容只是全新《AI 大模型应用新架构师课程》的很小一部分内容，新课会在8月1日重磅发布，也是业界首发，欢迎点击预约。
+▼全新《AI 大模型应用新架构师课程》重磅发布，预约保你有收获
+****—**2*****—*
+**加我微信**
+**扫码加我👇****有很多不方便公开发公众号的我会直接分享在****朋友圈****，****欢迎你扫码加我个人微信来看****👇**
+图片
+**加星标★****，不错过每一次更新！**
+**参考来源：
+**
+**https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus**
+⬇戳”阅读****原文“，立即预约！****
+END
+
+确定要放弃本次机会？福利倒计时*:**:*
+立减 ¥普通VIP年卡可用
+立即使用
+musicml
+关注关注
+* 14
+点赞* 
+踩* 28
+收藏觉得还不错?一键收藏
+* 知道了
+0
+评论* 分享
+复制链接分享到QQ
+分享到新浪微博扫一扫
+* 
+举报
+举报
+
+
+智能体协作的“记忆”秘诀：*Manus*团队的*上下文*工程实战*经验*分享！
+
+张伟的专栏
+08-061067
+
+这种从“个体记忆”到“集体记忆”的转变，意味着需要*设计*更复杂的架构，例如统一的共享内存或通用知识库，以及更精妙的协作机制。在AI智能体光鲜的能力背后，也隐藏着一个核心且常常被忽视的挑战：智能体的“记忆”问题，即我们常说的“*上下文*管理”。*上下文*工程的目标是为AI智能体搭建一个“舞台”，确保它在执行任务前，已经拥有了所有必要的“道具”和“剧本”，使其能够随着时间的推移进行适应并保持连贯性。它能防止*上下文*漂移和核心事实的误解，确保智能体始终“记得”用户的核心需求，例如“记住，用户的衬衫尺码是L码”。
+
+参与评论您还未登录，请先登录后发表或查看评论
+*Manus**技术*架构*与*应用实践深度解析
+
+西木风落
+04-051335
+
+*Manus*的突破标志着AI从“建议生成”走向“行动执行”的范式转移。其*技术*架构为行业提供了可复用的蓝本——多代理协同、沙箱隔离、动态规划等*设计*理念，正在成为下一代智能体的标准配置。本文从*技术*架构、实现机制、应用场景及行业影响四个维度，深度解析*Manus*的核心*技术*创新。
+
+
+开源AI新协议！AI Agent*与*前端交互的轻量级协议，轻松构建交互式AI应用！
+
+bugyinyin的博客
+06-041336
+
+AI Agent 的兴起让前端交互需求激增，但传统开发中，连接Agent后端*与*前端需大量定制代码，效率低下。
+在MCP（模型*上下文*协议）、A2A（Agent-to-Agent 通信协议）之后，AI Agent 的生态正在走向一个更完整的方向：AG-UI 协议横空出世，专为Agent*与*前端应用的通信交互而*设计*。
+
+
+*Manus*七*大核心**技术*：*上下文**工程架构**设计*
+
+weixin\_43939320的博客
+07-21899
+
+随着AI智能体*技术*的指数级演进，如何构建高效且可扩展的智能体系统架构，已成为*人工智能*领域*技术*攻坚的核心命题。本文基于*Manus*联合创始人兼首席科学家季逸超（Yichao 'Peak' Ji）于*7*月19日发表的深度*技术*论文《Context Engineering for AI Agents*:*Lessons from Building*Manus*》，对AI智能体*上下文*工程的关键*技术*路径*与*行业实践进行了系统性梳理*与*解读。
+
+
+AI 爱好者必读！*Manus*采用*上下文*工程构建AI智能体*经验*分享
+
+边逛边看边学习
+07-25957
+
+在当前阶段，构建高效、可靠的AI智能体（Agent），其成功的关键并不在于从零开始训练一个更庞大的模型，而在于对输入给模型的“*上下文*（Context）”进行精心*设计*和管理，即所谓的“*上下文*工程”（Context Engineering）
+
+
+2025*Manus*核心*揭秘*：下一代AI+Agent的多智能体架构.pptx
+
+03-08
+
+*Manus*核心*揭秘*：下一代AI+Agent的多智能体架构 AI*技术*发展至今，已逐渐渗透到人们生活的各个领域。然而，下一代AI*技术*的发展趋势和应用前景是什么？在这样背景下，*Manus*作为一款通用AI智能体，其核心架构和*设计*理念...
+
+
+企业数字化转型的智能协作平台：*Manus*核心*技术**与*行业解决方案
+
+03-12
+
+平台涵盖五*大核心*模块：行业背景*与*市场需求、核心价值体系、行业解决方案、*技术*安全保障和服务体系*与*生态。平台不仅具有强大兼容性和高效的微服务架构，还提供独特的三维数字孪生协同、智能工单系统和AR远程指导等...
+
+
+【*揭秘*全球首款通用AI Agent——*Manus*】：12*大核心**技术*解析*与*行业应用全览
+
+[
+![【*揭秘*全球首款通用AI Agent——*Manus*】：12*大核心**技术*解析*与*行业应用全览]...# 1.*Manus*AI Agent简介 ## 全球首款通用AI Agent的定义*与*背景 随着*人工智能**技术*的不断进步，通用AI Agent作为一个全新概念应运而生...
+]
+
+多智能体协作系统*Manus*的*技术*架构、应用场景及其Prompt工程实践
+
+03-08
+
+内容概要：本文详细介绍了一个名为*Manus*的多智能体协作系统的各个方面，首先解析了其核心*技术*架构——‘规划—执行—验证’三阶段架构以及底层支持*技术*。之后介绍了*Manus*的强大*技术*特点：在多项性能指标超越现有顶尖...
+
+
+*Manus*六大*上下文*工程法则：智能体系统*设计*的底层约束
+
+2501\_92798394的博客
+07-22881
+
+在构建Agent 系统、优化prompt 调度、处理RAG 链路、日志记录时，我们常常会踩到各种“坑”：cache miss、*上下文*错乱、模型行为漂移……这些问题让人既熟悉又头痛。明明知道问题出在哪里，却难以总结成一条普适的法则；明明优化了性能，却无法从认知层面解释其原理。这时，*Manus*的*上下文*工程法则就像一盏明灯，系统化地总结了这些*经验*教训，用优雅的方式为我们指明方向。
+
+
+AI智能体“*上下文*工程”实践：来自*Manus*项目的*经验*总结
+
+yanqianglifei的专栏
+07-221027
+
+*上下文*工程仍然是一门新兴科学，但对于智能体系统而言，它已经至关重要。模型可能变得越来越强大、越来越快、越来越便宜，但再多的原始能力也无法取代对记忆、环境和反馈的需求。你如何塑造*上下文*，最终决定了你的智能体如何表现：它运行的速度、恢复的能力以及扩展的程度。在*Manus*，我们通过反复重写、走入死胡同以及在数百万用户真实世界中的测试，汲取了这些*经验*教训。我们在此分享的并非普遍真理，但这些模式对我们来说是行之有效的。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的使命。
+
+
+*Manus*深度解析：*上下文*工程，AI领域的护城河，非常详细收藏我这一篇就够了！
+最新发布
+2401\_84204207的博客
+11-10628
+
+我在一线科技企业深耕十二载，见证过太多因*技术*卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率*与*薪资上形成代际优势，我意识到有很多*经验*和知识值得分享给大家，也可以通过我们的能力和*经验*解答大家在大模型的学习中的很多困惑。
+
+
+别再纸上谈兵！听*Manus*AI分享AI Agent*上下文*工程的实战干货*与*避坑指南！
+
+m0\_65555479的博客
+08-05940
+
+摘要：*Manus*AI分享了构建高效AIAgent的*7**大核心**经验*：1）优化KV-Cache缓存*设计*降低延迟；2）采用遮蔽而非移除工具的动态管理；3）将文件系统作为扩展记忆；4）通过复述机制保持注意力；5）保留错误信息促进学习；6）避免少样本导致的模式僵化；*7*）强调*上下文*工程对Agent行为的关键影响。这些实践源于实际生产环境中的数百万用户测试，为AIAgent开发提供了可*落地*的优化方案。（149字）
+
+
+Linux内核：文件系统之超级块
+
+m0\_74282605的博客
+08-101195
+
+当操作系统启动后，系统内核会把超级块中的内容复制到内存中，并周期性的利用内存里的最新内容去更新硬盘上的超级块中的内容。为此除非所有的超级块都损坏了，否则的话，只要有一个超级块是可用的，那么文件系统*与*操作系统就可以正常挂载*与*启动。做一个形象的比喻，这个超级块就好像是企业的资产负债表，一个文件系统中有哪些资源都记录在这个表中。VFS超级块是各种具体文件系统在安装时建立的，并在这些文件系统卸载时自动删除，可见，VFS超级块确实只存在于内存中，同时提到VFS超级块也应该说成是哪个具体文件系统的VFS超级块。
+
+
+【平头哥RVB2601创意应用开发】使用体验02 -- KV存储
+
+OCC\_THEAD的博客
+05-01706
+
+使用KV组件在RVB2601进行项目参数的本地持久化。
+
+
+*Manus*团队倾囊相授：AI Agent开发避坑宝典，6个实战秘籍让你少走半年弯路！
+
+xxue345678的博客
+08-25968
+
+*Manus*团队倾囊相授：AI Agent开发避坑宝典，6个实战秘籍让你少走半年弯路！
+
+
+美团万亿级KV 存储架构*与*实践
+
+勇往直前的专栏
+07-021045
+
+KV 存储作为美团一项重要的在线存储服务，承载了在线服务每天万亿级的请求量。在2019 年QCon 全球软件开发大会（上海站）上，美团高级*技术*专家齐泽斌分享了《美团点评万亿级 KV 存储架构*与*实践》，本文系演讲内容的整理，第一部分讲述了美团 KV 存储的发展历程；第二部分阐述了内存KV Squirrel 架构和实践；第三部分介绍了持久化KV Cellar 架构和实践；最后分享了未来的发展规划和业界新趋势。美团点评KV 存储发展历程美团第一代的分布式KV 存储如下图左侧的架构所示，.
+
+
+*Manus*多智能体系统：架构、部署及Prompt工程实践
+
+
+一、*Manus*核心原理*与**技术*架构 1. 多智能体协作体系*Manus*采用"规划-执行-验证"的三阶段架构，包含规划型Agent（任务拆解）、执行型Agent（工具调用）和监控验证Agent（结果校验）。这种架构使得*Manus*能够处理复杂...
+
+
+musicml
+博客等级
+码龄19年
+553原创6270点赞6451收藏2730粉丝
+关注私信
+
+
+### 热门文章* DeepSeek + 本地知识库：真的太香了！保姆级教程，建议收藏！20930
+* 一文搞懂 LangChain 新利器：LangGraph18210
+* 微软重磅开源 GraphRAG：新一代 RAG 技术来了！9925
+* GraphRAG + Ollama 本地部署全攻略：避坑实战指南8607
+* 人人需要掌握的大模型技术架构深度剖析5902
+上一篇：OpenAI 最新发布ChatGPT Agent 架构设计剖析下一篇：基于 LangGraph 构建Open Deep Research 架构设计与落地实践
+### 大家在看* 嵌入式领域中的追踪漏斗（Trace Buffer）是什么 ？282
+* 阿里云OSS 如何统计Bucket 文件占用大小？
+* 【BuildFlow & 筑流】时间段架构演进：从泛型统一到编译期精算的智慧升华（新duration/mod.rs）688
+### 最新文章* 让智能体自主成长！演化式上下文工程的实践革命
+* 评估工程：AI 智能体下一步演进的重要技术方向
+* Palantir 创始工程师深度分享：FDE 模式是Agent 时代的PMF 新范式
+2025
+11月24篇
+10月22篇
+09月15篇
+08月27篇
+07月28篇
+06月26篇
+05月16篇
+04月17篇
+03月20篇
+02月13篇
+01月9篇
+2024年222篇
+2023年52篇
+2022年1篇
+2021年3篇
+2020年29篇
+2019年23篇
+2018年1篇
+2017年4篇
+2016年9篇
+
+### 目录展开全部
+收起
+
+### 目录展开全部
+收起
+
+上一篇：OpenAI 最新发布ChatGPT Agent 架构设计剖析下一篇：基于 LangGraph 构建Open Deep Research 架构设计与落地实践
+### 最新文章* 让智能体自主成长！演化式上下文工程的实践革命
+* 评估工程：AI 智能体下一步演进的重要技术方向
+* Palantir 创始工程师深度分享：FDE 模式是Agent 时代的PMF 新范式
+2025
+11月24篇
+10月22篇
+09月15篇
+08月27篇
+07月28篇
+06月26篇
+05月16篇
+04月17篇
+03月20篇
+02月13篇
+01月9篇
+2024年222篇
+2023年52篇
+2022年1篇
+2021年3篇
+2020年29篇
+2019年23篇
+2018年1篇
+2017年4篇
+2016年9篇
+### 目录评论
+被折叠的条评论为什么被折叠?到【灌水乐园】发言
+查看更多评论
+添加红包祝福语请填写红包祝福语或标题红包数量个红包个数最小为10个
+红包总金额元红包金额最低5元
+余额支付当前余额3.43元前往充值 \>
+需支付：10.00元
+取消确定下一步
+知道了
+
+成就一亿技术人!
+
+hope\_wisdom
+发出的红包实付元使用余额支付
+点击重新获取
+扫码支付
+钱包余额0
+
+抵扣说明：1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
+2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。
+余额充值
+
+
+# AI智能体“上下文工程”实践：来自 Manus 项目的经验总结-腾讯云开发者社区-腾讯云
+URL: https://cloud.tencent.com/developer/article/2545989
+
+AI智能体“上下文工程”实践：来自 Manus 项目的经验总结-腾讯云开发者社区-腾讯云
+
+## AI智能体“上下文工程”实践：来自 Manus 项目的经验总结
+
+关注作者
+
+腾讯云
+
+开发者社区
+
+文档 建议反馈 控制台
+
+登录/注册
+
+首页
+
+学习
+
+活动
+
+专区
+
+圈层
+
+工具
+
+MCP广场
+
+文章/答案/技术大牛搜索
+
+搜索关闭
+
+发布
+
+致Great
+
+社区首页> 专栏>AI智能体“上下文工程”实践：来自 Manus 项目的经验总结
+
+# AI智能体“上下文工程”实践：来自 Manus 项目的经验总结
+
+致Great
+
+关注
+
+发布于 2025-07-23 08:41:39
+
+发布于 2025-07-23 08:41:39
+
+1.9K0
+
+举报
+
+文章被收录于专栏： 自然语言处理自然语言处理
+
+转载：https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
+
+在启动 Manus (manus.im/app) 项目之初，我的团队面临一个关键抉择：究竟是基于开源基础模型训练一个端到端的智能体模型，还是在前沿大模型的“上下文学习”（In-Context Learning）能力基础之上构建智能体？
+
+在我从事自然语言处理 (NLP) 的第一个十年里，我们没有这样“奢侈”的选择。在久远的 BERT (arxiv.org/abs/1810.04805) 时代（没错，已经七年了），模型必须经过微调和评估才能迁移到新的任务上。即使当时的模型比现在的大语言模型（LLM）小得多，这个过程每迭代一次也常常需要数周时间。对于快速发展的应用，尤其是在达到产品市场契合点 (PMF) 之前，如此缓慢的反馈周期是无法接受的。这是我上一家创业公司留下的痛苦教训，当时我从零开始训练模型以实现开放信息提取（Open Information Extraction）和语义搜索。后来，GPT-3 (arxiv.org/abs/2005.14165) 和 Flan-T5 (arxiv.org/abs/2210.11416) 横空出世，我内部开发的模型一夜之间便失去了竞争力。讽刺的是，正是这些模型开启了上下文学习（In-Context Learning）的新时代，也为我们指明了新的前进方向。
+
+这次来之不易的教训使我们明确了选择：Manus 将侧重“上下文工程”（Context Engineering）。这让我们能够将改进的交付时间从数周缩短到数小时，并使我们的产品与底层模型保持独立：如果说模型进步是水涨船高，那么我们希望 Manus 成为那艘随波而动的船，而不是深陷海底的柱子。
+
+尽管如此，实践证明上下文工程绝非易事。它是一门实验性科学——我们已经四次重构了我们的智能体框架，每一次都是在发现了更好的上下文构建方法之后进行的。我们亲切地将这种架构搜索、提示词调整和经验性猜测的手动过程称为“随机梯度下降法”（Stochastic Graduate Descent）。它虽然不够优雅，但确实有效。
+
+本文将分享我们通过这种“随机梯度下降法”找到的局部最优解。如果你也在构建自己的 AI智能体，我希望这些原则能帮助你更快地收敛。
+
+##### 围绕 KV-缓存（KV-Cache）进行设计
+
+如果只能选择一个指标，我会认为 KV-缓存命中率是生产阶段 AI 智能体最重要的单一指标。它直接影响延迟和成本。为了理解原因，我们来看看一个典型智能体 (arxiv.org/abs/2210.03629) 的运行方式：
+
+智能体接收到用户输入后，会通过一系列工具使用来完成任务。在每次迭代中，模型会根据当前上下文从预定义的操作空间中选择一个动作。该动作随后在环境中执行（例如，Manus 的虚拟机沙箱）以生成一个观察结果。动作和观察结果会被附加到上下文中，形成下一次迭代的输入。这个循环持续进行，直到任务完成。
+
+可以想象，上下文会随着每一步的执行而增长，而输出（通常是结构化的函数调用）则相对较短。这使得智能体中的预填充（prefilling）与解码（decoding）之间的比例，与聊天机器人相比，呈现出高度倾斜。例如，在 Manus 中，平均输入与输出 token 的比例大约是 100:1。
+
+幸运的是，具有相同前缀的上下文可以利用 KV-缓存（ medium.com/@joaolages/kv-caching-explained-276520203249），这大大减少了首个 token 的生成时间（TTFT）和推理成本——无论你是使用自托管模型还是调用推理 API。而且我们谈论的不是节省一小部分：以 Claude Sonnet 为例，缓存的输入 token 成本为 0.30 美元/百万 token，而未缓存的则需要 3 美元/百万 token——相差 10 倍。
+
+从上下文工程的角度来看，提高 KV-缓存命中率涉及以下几个关键实践：
+
+1. 在需要时明确标记缓存断点。 某些模型提供商或推理框架不支持自动增量前缀缓存，而是需要在上下文中手动插入缓存断点。在设置这些断点时，请考虑潜在的缓存过期，并且至少要确保断点包含系统提示词的末尾。
+2. 确保上下文只追加不修改。 避免修改先前的操作或观察结果。确保你的序列化是确定性的。许多编程语言和库在序列化 JSON 对象时无法保证键的顺序稳定，这可能会悄无声息地破坏缓存。
+3. 保持提示词前缀的稳定性。 由于大语言模型 (LLM) 的自回归（autoregressive）特性，即使是单个 token 的差异，也可能导致从该 token 开始的缓存失效。一个常见错误是在系统提示词的开头包含时间戳——特别是精确到秒的时间戳。当然，这可以让模型告诉你当前时间，但也会极大地降低你的缓存命中率。
+
+此外，如果你使用像 vLLM (github.com/vllm-project/vllm) 这样的框架来托管模型，请确保前缀/提示词缓存（ docs.vllm.ai/en/stable/design/v1/prefix_caching.html）已启用，并且你正在使用会话 ID 等技术来确保请求在分布式工作节点之间保持一致地路由。
+
+##### 遮蔽，而非移除
+
+随着智能体功能变得越来越强大，其操作空间自然也变得更加复杂——简单来说，就是工具的数量呈爆炸式增长。最近 MCP（ modelcontextprotocol.io/introduction）的流行更是火上浇油。如果你允许用户配置工具，相信我：总会有人将数百个神秘工具插入到你精心策划的操作空间中。结果就是，模型更有可能选择错误的操作，或者采取低效的路径。简而言之，你的“全副武装”的智能体反而变得更笨了。
+
+一个自然的反应是设计动态动作空间——也许使用类似 RAG (en.wikipedia.org/wiki/Retrieval-augmented_generation) 的方式按需加载工具。我们在 Manus 中也尝试过。但我们的实验表明了一个清晰的规则：除非绝对必要，否则避免在迭代过程中动态添加或移除工具。这主要有两个原因：
+
+1. 当之前的动作和观察结果仍然引用当前上下文中未定义的工具时，模型会感到困惑。如果没有约束解码（constrained decoding），这通常会导致模式（schema）违规或幻想出的动作。
+2. 在大多数大语言模型 (LLM) 中，工具定义在序列化后位于上下文的前部，通常在系统提示词之前或之后。因此，任何更改都将使后续所有动作和观察结果的 KV-缓存失效。
+
+为了解决这个问题，同时仍然改进操作选择，Manus 使用了一种上下文感知的状态机（state machine）来管理工具的可用性。它不是移除工具，而是在解码时遮蔽（mask）token 逻辑值，以根据当前上下文阻止（或强制）选择某些操作。
+
+在实践中，大多数模型提供商和推理框架都支持某种形式的响应预填充，这允许你在不修改工具定义的情况下约束操作空间。函数调用通常有三种模式（我们以 NousResearch 的 Hermes 格式 [github.com/NousResearch/Hermes-Function-Calling] 为例）：
+
+- 指定（Specified） –模型必须从特定子集中调用函数。通过预填充到函数名称的开头来实现：`<|im_start|>assistant {"name": “browser\_`
+- 必需（Required） – 模型必须调用函数，但选择不受限制。通过预填充到工具调用 token 来实现：`<|im_start|>assistant `
+- 自动（Auto） – 模型可以选择是否调用函数。通过仅预填充回复前缀来实现：`<|im_start|>assistant`
+
+通过这种方式，我们直接通过遮蔽 token逻辑值来约束操作选择。例如，当用户提供新输入时，Manus 必须立即回复而不是执行操作。我们还特意设计了具有一致前缀的操作名称——例如，所有与浏览器相关的工具都以`browser_`开头，命令行工具以`shell_`开头。这使我们能够轻松地在给定状态下强制智能体只能从特定工具组中选择，而无需使用有状态的逻辑值处理器。
+
+这些设计有助于确保 Manus 智能体循环保持稳定——即使在模型驱动的架构下也是如此。
+
+##### 将文件系统用作上下文
+
+如今前沿的大语言模型拥有 128K token 甚至更长的上下文窗口。但在实际的智能体应用场景中，这往往不够，有时甚至会成为一个负担。通常有三个痛点：
+
+1. 长输入成本高昂，即使有前缀缓存。你仍然需要为传输和预填充每个 token 付费。
+2. 模型性能往往在超过一定上下文长度后下降，即使窗口技术上支持更长的上下文。
+3. 观察结果可能非常庞大，尤其是当智能体与网页或 PDF 等非结构化数据交互时，很容易超出上下文限制。
+
+为了解决这个问题，许多智能体系统会实施上下文截断或压缩策略。但是，过度激进的压缩不可避免地会导致信息丢失。这是一个根本性问题：智能体天生就需要根据所有先前的状态来预测下一个动作——而你无法可靠地预测十步之后哪一个观察结果可能变得至关重要。从逻辑角度来看，任何不可逆的压缩都带有风险。
+
+这就是为什么在 Manus 中，我们将文件系统视为终极上下文：它大小无限、本质上是持久的，并且可以直接由智能体本身操作。模型学习按需写入和读取文件——将文件系统不仅用作存储，还用作结构化的外部化内存。
+
+我们的压缩策略总是被设计为可恢复的。例如，只要保留 URL，网页内容就可以从上下文中删除；如果文档的路径在沙箱中仍然可用，其内容就可以省略。这使得 Manus 可以在不永久丢失信息的情况下缩短上下文长度。
+
+在开发此功能时，我发现自己一直在思考，如何才能让状态空间模型（SSM）在智能体环境中有效工作。与 Transformer 不同，SSM 缺乏完整的注意力机制，并且在处理长距离向后依赖方面存在困难。但如果它们能够掌握基于文件的内存——将长期状态外部化而不是将其保存在上下文中——那么它们的速度和效率可能会开辟一类新的智能体。智能体 SSM 可能成为神经图灵机（Neural Turing Machines）的真正继承者。
+
+##### 通过复述（Recitation）操控注意力
+
+如果你使用过 Manus，你可能会注意到一个有趣的现象：在处理复杂任务时，它倾向于创建一个`todo.md`文件——并随着任务的进展逐步更新，勾选已完成的项目。这不仅仅是“可爱”的行为，更是一种刻意为之的“注意力操控”机制。
+
+在 Manus 中，一个典型的任务平均需要大约 50 次工具调用。这是一个漫长的循环——由于 Manus 依赖于大语言模型（LLM）进行决策，它很容易偏离主题或忘记早期的目标，尤其是在长上下文或复杂任务中。
+
+通过不断重写待办事项列表，Manus 将其目标重复写入上下文的末尾。这会将全局计划推入模型的近期注意力范围，从而避免“迷失在中间”的问题，并减少目标错位。实际上，它正在使用自然语言来引导自己的注意力集中在任务目标上——而无需特殊的架构更改。
+
+##### 将“错误的数据”保留在上下文中
+
+智能体（Agent）会犯错。这不是 Bug，而是现实。语言模型会产生幻觉，环境会返回错误，外部工具会表现异常，意想不到的极端情况也时常出现。在多步骤任务中，失败并非例外，而是循环的一部分。
+
+然而，常见的本能是隐藏这些错误：清理轨迹、重试操作，或重置模型状态并将其留给神奇的“温度（temperature）”参数。这感觉更安全、更容易控制。但这会带来代价：抹去失败就等于消除了证据。而没有证据，模型就无法适应。
+
+根据我们的经验，改进智能体行为最有效的方法之一出奇地简单：将错误的路径保留在上下文中。当模型看到失败的操作以及由此产生的观察结果或堆栈跟踪时，它会隐式地更新其内部信念。这使得它不再倾向于类似的操作，从而减少重复相同错误的机会。
+
+事实上，我们相信错误恢复是真正智能体行为最清楚的指标之一。然而，这在大多数学术研究和公共基准测试中仍然关注不足，这些研究和测试通常侧重于理想条件下的任务成功率。
+
+##### 警惕少样本提示（Few-ShotPrompting）的陷阱
+
+少样本提示（Few-Shot Prompting）是一种常见的提高大语言模型（LLM）输出质量的技术。但在智能体系统中，它可能以微妙的方式适得其反。
+
+语言模型是非常优秀的模仿者；它们会模仿上下文中行为模式。如果你的上下文中充满了相似的过去“动作-观察”对，模型就会倾向于遵循这种模式，即使它不再是最优的。
+
+这在涉及重复决策或动作的任务中可能很危险。例如，当使用 Manus 协助审核一批 20 份简历时，智能体常常会陷入一种固定的节奏——重复执行类似的操作，仅仅因为它在上下文中看到了这些模式。这会导致偏离、过度泛化，有时甚至产生幻觉。
+
+解决方案是增加多样性。Manus 在动作和观察中引入少量结构化变量——不同的序列化模板、替换措辞、在顺序或格式上添加微小的噪声。这种受控的随机性有助于打破模式，并调整模型的注意力。
+
+换句话说，不要让少样本提示将你引入困境。你的上下文越统一，你的智能体就越脆弱。
+
+##### 总结
+
+上下文工程仍然是一门新兴科学，但对于智能体系统而言，它已经至关重要。模型可能变得越来越强大、越来越快、越来越便宜，但再多的原始能力也无法取代对记忆、环境和反馈的需求。你如何塑造上下文，最终决定了你的智能体如何表现：它运行的速度、恢复的能力以及扩展的程度。
+
+在 Manus，我们通过反复重写、走入死胡同以及在数百万用户真实世界中的测试，汲取了这些经验教训。我们在此分享的并非普遍真理，但这些模式对我们来说是行之有效的。如果它们能帮助你避免哪怕一次痛苦的迭代，那么这篇文章就完成了它的使命。
+
+智能体的未来将通过一次又一次地构建上下文来实现。请精心地进行这些工程。
+
+本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。
+
+原始发表：2025-07-22，如有侵权请联系 cloudcommunity@tencent.com删除
+
+前往查看
+
+设计
+
+实践
+
+缓存
+
+工具
+
+模型
+
+本文分享自 作者个人站点/博客 前往查看
+
+如有侵权，请联系 cloudcommunity@tencent.com删除。
+
+本文参与 腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！
+
+设计
+
+实践
+
+缓存
+
+工具
+
+模型
+
+评论
+
+登录后参与评论
+
+0 条评论
+
+热度
+
+最新
+
+登录 后参与评论
+
+推荐阅读
+
+目录
+
+- 围绕 KV-缓存（KV-Cache）进行设计
+
+- 遮蔽，而非移除
+
+- 将文件系统用作上下文
+
+- 通过复述（Recitation）操控注意力
+
+- 将“错误的数据”保留在上下文中
+
+- 警惕少样本提示（Few-ShotPrompting）的陷阱
+
+- 总结
+
+相关产品与服务
+
+NLP技术
+
+NLP 技术（Natural Language Process，NLP）深度整合了腾讯内部的 NLP 技术，提供多项智能文本处理和文本生成能力，包括词法分析、相似词召回、词相似度、句子相似度、文本润色、句子纠错、文本补全、句子生成等。满足各行业的文本智能需求。
+
+产品介绍 产品文档
+
+2026新春采购季
+
+领券
+
+### 社区
+
+- 技术专区
+- 技术百科
+- 学习中心
+- 技术视频
+- 技术沙龙
+- 技术问答
+- 技术文章
+
+### 活动
+
+- 技术竞赛
+- 自荐上首页
+- 邀请作者入驻
+- 自媒体同步曝光计划
+
+### 圈层
+
+- 腾讯云TDP
+- 腾讯云创作之星
+- 腾讯云架构师技术同盟
+- 腾讯云最具价值专家
+
+### 关于
+
+- MCP广场开源版权声明
+- 友情链接
+- 联系我们
+- 免责声明
+- 社区规范
+
+### 腾讯云开发者
+
+扫码关注腾讯云开发者
+
+领取腾讯云代金券
+
+### 热门产品
+
+- 视频直播
+- 云存储
+- 域名解析
+- 云数据库
+- 网络加速
+- 消息队列
+- 区块链服务
+- 云服务器
+- 域名注册
+
+### 热门推荐
+
+- 语音识别
+- SSL 证书
+- MySQL 数据库
+- 图像分析
+- 视频通话
+- CDN加速
+- 企业云
+- 腾讯会议
+- 人脸识别
+
+### 更多推荐
+
+- 数据迁移
+- 网站监控
+- 小程序开发
+- 大数据
+- 云点播
+- 文字识别
+- 短信
+- 负载均衡
+- 数据安全
+
+Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
+
+深圳市腾讯计算机系统有限公司 ICP备案/许可证号： 粤B2-20090059 粤公网安备44030502008569号
+
+腾讯云计算（北京）有限责任公司京ICP证150476号 | 京ICP备11018762号
+
+问题归档 专栏文章 快讯文章归档 关键词归档 开发者手册归档 开发者手册 Section 归档
+
+Copyright © 2013 - 2026 Tencent Cloud.
+
+All Rights Reserved. 腾讯云 版权所有
+
+登录 后参与评论
+
+000
+
+推荐