AI Agent开发痛点与Context Engineering需求 - AI Agent开发面临海量工具调用和长程推理(long horizon reasoning)产生的长上下文(long context)问题，严重制约Agent性能和成本，甚至导致模型能力下降[4] - 典型任务通常需要约50次工具调用，生产级Agent运行时可能需要多达数百次工具调用[11] - 单次运行可能消耗50万个token，成本达到1-2美元[11] Context Engineering核心概念 - Context Engineering定义为"在大语言模型的上下文窗口中放入正好适合它执行下一步所需的信息"[8] - 本质上是AI Engineering的子集，包含内循环(即时筛选所需context)和外循环(长期优化context window)[10][13] - 随着context长度增加，模型注意力会分散，推理能力下降，这种现象称为context衰减(context decay)[15] 五大Context Engineering策略 Offload(转移) - 将完整工具调用context转移到文件系统等外部存储，仅返回摘要或URL标识[21][26] - 使用文件系统记录笔记、跟踪进度、存储长期记忆[23] - 必须生成有效摘要描述文件信息，prompt engineering在其中起重要作用[28] Reduce(压缩) - 通过摘要(summarization)和剪裁(pruning)减少context内容[21][35] - Claude Code在95% context window占满时自动触发reduce机制[35] - 存在信息丢失风险，Manus选择先offload确保原始数据不丢失再进行reduce[37] Retrieve(检索) - 从外部资源检索与当前任务相关信息加入context window[21][46] - 包括经典向量检索、文件工具检索和context填充等方法[47] - 测试表明基于文本文件和简单文件加载工具的检索方法效果最佳[48] Isolate(隔离) - 在multi-agent架构中拆分context，避免不同类型信息相互干扰[21][59] - 不同角色agent各自压缩管理不同内容，避免单一agent承担全部context负担[59] - Cognition认为sub-agent获得足够context极其困难，需要大量精力在context摘要与压缩上[61] Cache(缓存) - 缓存已计算结果，降低延迟和成本[21][67] - 使用Claude Sonnet时缓存输入token成本为0.30美元/百万token，未缓存为3美元/百万token，相差10倍[69] - 只能优化延迟和成本问题，无法解决long context根本问题[70] The Bitter Lesson启示与实践经验 - 计算能力每五年增长十倍，scaling趋势是推动AI进步的关键因素[71] - 随着模型能力提升，早期添加的结构化假设可能成为发展瓶颈[74][81] - AI-native产品应在模型能力足够时从零构建，而非受限于现有流程[82] - Claude Code设计保持简单通用，为用户提供广泛模型访问权限[81] 记忆系统与检索关系 - Agent记忆分为情景记忆、语义记忆、程序记忆和背景记忆四类[50] - 大规模记忆读取本质上就是检索操作，复杂记忆系统就是复杂RAG系统[54] - Claude Code采用极简模式，启动时自动加载用户GitHub仓库，效果出奇地好[53][54] 框架选择与架构设计 - 应区分agent抽象(高级封装)和底层编排框架(精细控制)[77][78] - 开发者需要警惕agent抽象，但不排斥透明可自由组合的底层编排框架[79] - 大型组织推动标准化框架是为了解决实际协作问题，而非框架本身[80]

Context Engineering 核心概念 - Context engineering 是由 Andrej Karpathy 提出的概念，指在正确时间为 agent 提供正确信息的方法论，覆盖并超越了 prompt engineering 和 RAG，成为 agent 开发的核心胜负手 [2] - 概念定义为"在大语言模型的上下文窗口中放入正好适合它执行下一步所需的信息"，核心痛点在于 agent 实际运行中由海量工具调用和长程推理产生的冗长上下文成为性能和成本的巨大瓶颈 [2][4] - Chroma 联合创始人 Jeff Huber 认为 context engineering 是 AI engineering 的子集，包含内循环（即时筛选当前所需 context）和外循环（长期优化确保 context window 只包含相关信息）两个循环 [5] Context Engineering 的必要性 - 典型 agent 任务需要约50次工具调用，生产级 agent 甚至可能需要数百次工具调用，每次调用都会消耗大量 token [7] - 开源 AI 研究助手 Open Deep Research 单次运行可能消耗50万个 token，成本达到1-2美元 [7] - Chroma 报告显示随着 context 长度增加，模型注意力分散，推理能力下降，这种现象称为 context 衰减（context decay） [9] Offload（转移）策略 - 将工具调用的完整 context 转移到外部存储如文件系统，仅返回摘要或 URL 作为标识，显著优化资源利用率 [15][18] - Manus 将文件系统视为终极上下文：大小不受限制，天然持久化，代理可直接操作 [29] - Open Deep Research 通过精心设计的 prompt 生成详尽要点摘要，实现内容压缩的同时保持信息准确还原 [20] Reduce（压缩）策略 - 通过摘要和剪裁减少 context 内容，典型场景是当 Claude Code 95% context window 被占满时自动触发 reduce 机制 [24][26] - Manus 采用可恢复的压缩策略，保留 URL 或文档路径确保信息不永久丢失，避免不可逆压缩导致的信息丢失风险 [28][29] - 关于是否保留错误路径存在争议：Gemini 案例显示幻觉会污染后续决策，但保留错误信息可能让 agent 从失败中学习 [33][36] Retrieve（检索）策略 - 从外部资源检索相关信息加入 context，传统方法包括向量检索、语义检索和 grep 搜索 [40] - Lance Martin 基准测试显示，基于文件工具和简单搜索的检索方法效果优于经典向量检索和 context stuffing（直接输入300万 token 文档） [41][42] - 记忆检索可视为特定 context 下的检索，分为情景记忆、语义记忆、程序记忆和背景记忆四类 [43] Isolate（隔离）策略 - 在 multi-agent 架构中将 context 拆分，避免不同类型信息相互干扰，不同角色 agent 各自管理不同内容 [46][47] - Cognition 认为 multi-agent 架构下 sub-agent 获得足够 context 极其困难，投入大量精力在 context 摘要与压缩上 [49] - Anthropic 与 Cognition 存在分歧：Anthropic 认为 multi-agent 有用，Cognition 认为不要使用 multi-agent，尤其避免用于需要高度协同的 coding 场景 [50] Cache（缓存）策略 - 利用键值缓存机制提高 AI agent 多步骤任务效率和成本效益，Manus 中平均输入与输出 token 比例约为100:1 [55][56] - 使用 Claude Sonnet 时，缓存输入 token 成本为0.30美元/百万 token，未缓存成本为3美元/百万 token，相差10倍 [57] - 缓存只能优化延迟和成本，无法解决 long context 根本问题，当 context 达到十万 token 时模型性能衰减问题依然存在 [57] The Bitter Lesson 的启示 - 计算能力每五年增长十倍，scaling 趋势是推动 AI 进步的关键因素，依赖大量数据和计算的算法比手工特征设计表现更好 [59] - 随着模型能力提升，早期添加的结构化假设可能成为发展瓶颈，应转向更少结构化的通用方法 [60][70] - AI-native 产品如 Cursor 和 Windsurf 从零开始构建，相比将 AI 嵌入现有流程的改造方式更具优势 [70] 实践经验与框架选择 - Lance Martin 从高度结构化流程转向 agent 架构，验证了随着模型能力提升，减少结构化假设的重要性 [69] - 应区分 agent 抽象（高级封装）和底层编排框架（精细控制），后者提供透明可组合节点具有实用价值 [63][67] - 企业客户初期自行搭建，但随着代码管理问题出现，标准化框架如 MCP 为解决协作问题变得必要 [68]