上下文工程(Context Engineering)
搜索文档
「上下文工程」 已经30岁了,而你可能刚知道它
36氪· 2025-11-03 11:02
AI时代,人不再只是「社会关系的总和」,而是由无数数据、记录和互动的上下文构成的。 这不是科幻。这是正在发生的现实。 而这一切的起点,是一个被严重误解的领域——Context Engineering(上下文工程)。 来自于上海创智学院刘鹏飞老师团队,提出上下文工程2.0,剖析上下文工程的:本质、历史与未来。 一个被遗忘的真相 2025年,当你第一次向ChatGPT输入一段精心设计的prompt,你可能以为自己在做一件前所未有的事情——用自然语言「编程」,让AI理解你的意图。 但如果告诉你,早在2000年,佐治亚理工大学的研究者就在做同样的事情呢? 那时还没有GPT,甚至连智能手机都还没有。 但Anind Dey和他的团队已经在思考一个核心问题:如何让机器理解人类所处的「上下文」(context),从而提供更智能的服务? 他们开发了Context Toolkit——一个帮助开发者构建「上下文感知应用」的框架。 当你走进办公室,系统会自动:检测你的位置(通过红外传感器)、识别你的身份(通过ID卡)、推断你的活动(会议 vs 个人工作)、调整环境(灯 光、温度、通知模式)。 这个过程需要什么?需要工程师精心设计传感 ...
超越 Prompt 和 RAG,「上下文工程」成了 Agent 核心胜负手
海外独角兽· 2025-09-17 20:08
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]
Manus披露预测性年度收入为9000万美元
36氪· 2025-08-20 18:16
沉寂一段时间后,在年初掀起一轮AI Agent热潮的Manus终于又有新动向。 现在,无论看起来是否仍有"不够ambitious"的成分,Manus的确需要适时输出一些信息,为自己建立一 定的坐标轴,以支撑公司更长期的目标。 作为一家定位全球化市场的中国AI初创企业,Manus的出海之路一度备受质疑。7月9日,有媒体报道 Manus已将全球总部从北京迁至新加坡,这背后有国际化加速、应对跨境合规等多方面考量。结合此前 Manus所受到Benchmark投资等新闻,一些声音认为其正在背离中国市场。 8月20日消息,在一场由Stripe于新加坡举办的活动上,Manus首席科学家季逸超(Peak)表示,"公司收 入运行率(RRR/Revenue Run Rate)为9000万美元"。 收入运行率(RRR)是一种财务指标,通常被初创或处于快速增长阶段的公司用来预测年度收入。计算 RRR的方法取决于可用的收入数据类型,一种常见的方式是根据已有月度收入数据,将一个月的总收入 乘以12来得到预测性年度收入。 | Manus's Computer | | | | | | --- | --- | --- | --- | --- ...
Manus“跑路”后的4个启示
混沌学园· 2025-08-18 20:05
Manus的战略选择 - 公司放弃自研底层模型,选择基于前沿模型的上下文学习能力构建智能体,以验证产品与市场契合度(PMF) [4][5] - 决策源于自研模型效率低(每次微调需数周)且面临技术锁定风险(新模型迁移成本高) [5] - 战略聚焦单点突破,集中资源实现阈值效应[6] 上下文工程的技术定位 - 该技术是LLM应用领域继提示词工程后的新热点,通过系统化输入文本引导模型生成预期输出[8] - 本质是为LLM构建包含数据/环境的完整运行系统,类比职业场景中的多维度信息整合[8][9] - 解决大模型从通用助手到行业专家的落地问题,推动技术向生产力跃迁[9] Manus的六大技术优化原则 1. KV-cache设计:稳定提示前缀/追加上下文/明确缓存断点以降低成本[14] 2. 工具遮蔽机制:通过logits屏蔽控制模型可见工具,避免动态修改导致混乱[14] 3. 外部化记忆系统:虚拟文件系统实现长期记忆按需读写[14] 4. 动态注意力管理:复述更新todo.md文件防止任务偏离[14] 5. 错误记录保留:从失败尝试中调整学习提升长期表现[14] 6. 打破少样本模式:引入格式变化避免模型行为僵化[11][14] 退出中国市场的商业考量 - 直接原因可能涉及投资安排与双市场研发资源不足[16] - 国内付费转化率不佳:定价偏高且与本土产品差异化不足[16] - 中美市场差异:国内C端创新领先但B端企业软件付费成熟度低于北美[16] - 基础模型厂商入局加剧竞争,迫使纯Agent公司寻求更高商业回报区域[17] 行业启示 - AI Agent商业化早期阶段的核心壁垒不在模型本身,而在于构建支持系统[18] - 行业趋势显示通用大模型需结合专业工作流系统才能形成竞争力[19] - 垂直Agent创业潮印证需在正确时间提供正确信息支撑模型推理决策[19]
晚点播客丨IMO 金牌、Kimi 翻盘、抢人大战,与真格戴雨森复盘 2025 AI 中场战事
晚点LatePost· 2025-07-31 13:37
AI模型能力突破 - OpenAI通用大语言模型首次达到IMO金牌水准,六道题做对五道,未针对数学优化且未联网[7][8] - Google DeepMind的Gemini DeepThink模型同样取得IMO金牌,使用纯自然语言解题[14] - 数学证明题属于"hard to produce, hard to verify"任务,突破意义大于编程和围棋[16][18] - 模型推理能力提升验证inference scaling law,优化空间来自post-training而非底层架构[9][10] 技术演进趋势 - 解锁AI生产力的三大主线:推理(reasoning)、编程(coding)、工具使用(tool use)[56][68] - 模型架构仍处Transformer范式内演进,但能力从1到10提升显著[57] - 工具使用呈现两条路径:API接口调用和视觉模拟操作现有软件[68] - 上下文工程(Context Engineering)成为关键,分通用信息、组织层面、个性化记忆三层[26][61] 应用层发展 - Agent产品进入Early Adopter阶段,Manus/Genspark等完成模糊目标到任务执行的闭环[34] - 应用价值被低估,优秀产品设计能形成护城河,如Kimi长文本技术方向的前瞻布局[49][51] - 生产力场景token消耗呈10-100倍增长,远超聊天场景,如分析师可同时覆盖50家财报[83] - 订阅制商业模式验证成功,高端用户月均AI产品支出达1000美元[79] 行业竞争格局 - 中美模型差距缩小,Kimi K2开源模型在coding/Agent工作流等表现优于Claude[40][41] - Google强势回归,Gemini 2.5在多模态和云服务表现突出,TPU优势明显[58][59] - 人才争夺白热化,硅谷出现百万美元年薪挖角,创业公司面临人才保留压力[86][89] - 资源分配策略分化:字节全栈布局vs DeepSeek选择性突破[46][47] 团队与创新 - 稳定团队+技术前瞻性是突破关键,如Kimi核心成员合作超10年[48][49] - 优秀团队价值被低估,实际创新能力常超市场预期,如Kimi逆风翻盘[40][41] - 早期采用者(Early Adopter)社区生态活跃,开源项目获得积极反馈[5][53] - 产品设计需为未来模型预留空间,如Cursor等待Claude 3.5实现完整愿景[41][98]
忘掉《Her》吧,《记忆碎片》才是 LLM Agent 的必修课
Founder Park· 2025-07-29 16:05
行业趋势演变 - AI行业叙事从Chatbot(聊天机器人)转向Agent(智能体)成为主流 讨论焦点从"意图识别"和"多轮对话"变为"任务分解"、"工具调用"和"自主规划" 行业热度堪比2016年移动互联网爆发期 [4] - 电影《Her》定义了Chatbot范式的终极形态 而《记忆碎片》的主角莱纳德被视为Agent的完美隐喻 展示系统如何在信息不完整环境下为目标思考与行动 [5] Agent系统架构 - 上下文工程是围绕LLM有限注意力窗口设计的信息管理技术栈 目标是为每个决策点提供恰到好处的信息 决定Agent成败 [5] - 莱纳德的记忆系统对应LLM三大特征:长期记忆如同训练数据(静态知识库) 短期记忆如同上下文窗口(15分钟记忆限制) 行动驱动类似Agent任务导向 [9] 上下文工程三大支柱 外部知识管理 - 拍立得照片系统对应RAG技术 实现知识管理闭环:选择性记录任务关键信息 而非存储所有数据 避免检索时信息过载 [17][20] - 完整流程包括信息采集固化(拍照)、上下文标注(背面笔记)、按需调用(匹配检索) 体现RAG核心价值 [23] 上下文提炼结构化 - 将信息从照片升级到纹身 代表信息提炼压缩过程 只保留经过验证的核心断言(如"事实5") 并物理结构化确保读取优先级 [22][29] - Agent需成为信息炼金术士 对冗长信息进行压缩总结 在有限Token预算内最大化信息密度 避免"大海捞针"困境 [25] 分层记忆管理 - 三层架构:核心任务层(不可变纹身)、情景工作层(可读写照片)、瞬时处理层(易失性大脑记忆) 实现高效记忆调度 [30] - 需明确定义信息层级 区分宪法级指令、任务日志和临时缓存 防止Agent迷失在海量操作日志中 [28] Agent系统风险 - 上下文投毒风险:外部恶意输入可能导致Agent将错误信息当作真理输出 呈现"垃圾进真理出"现象 [32] - 自我强化认知牢笼:Agent在多步任务中可能将前序错误结论当作事实 缺乏独立审查机制导致偏差放大 [33][34] 系统优化方向 - 缺失反思模块是当前Agent核心缺陷 需建立验证机制比对行动结果与预期差距 生成误差报告指导后续行动 [35] - 构建可靠行动系统比单纯追求自主性更重要 需防止创造高效但永不怀疑的"莱纳德军队" [36]
季逸超亲述 Manus 构建之谜,一文读懂 AI 智能体的上下文工程
AI科技大本营· 2025-07-21 18:08
上下文工程的核心观点 - Manus团队选择基于上下文工程而非端到端训练构建AI Agent,将产品迭代周期从数周缩短至几小时,保持与底层模型发展的正交性[2][3] - 上下文工程是实验科学,团队通过四次重构Agent框架总结出"随机研究生下降"方法论,即通过手动调试提示词和经验猜测寻找局部最优解[3] - KV缓存命中率是生产级AI Agent最关键指标,直接影响延迟和成本,优化后可使Claude Sonnet模型输入token成本从3美元/百万降至0.3美元/百万[5][8] KV缓存优化策略 - 保持提示词前缀稳定性,避免在系统提示开头插入时间戳等可变元素导致后续缓存失效[13] - 采用只增不减的上下文管理策略,确保序列化过程确定性,避免JSON键顺序变化破坏缓存[13] - 明确标记缓存断点,在系统提示后设置断点以适配不支持自动增量缓存的推理框架[13] 操作空间管理 - 避免动态增删工具定义,工具变更会导致后续所有动作和观察结果的KV缓存失效[12] - 采用感知上下文的状态机进行logits掩码,而非直接移除工具,防止模型产生格式错误输出[15] - 设计统一工具名前缀(如browser_/shell_),便于在特定状态下强制选择某类工具[18] 外部上下文设计 - 将文件系统作为无限容量的外部记忆,训练模型按需读写文件实现结构化存储[23] - 采用可恢复的压缩策略,保留URL或文件路径等关键信息而非永久删除内容[26] - 状态空间模型若掌握基于文件的记忆能力,可能催生新型高效Agent架构[26] 注意力与错误管理 - 通过复述机制(如todo.md文件)将核心目标持续写入上下文末端,防止50次工具调用链中的目标漂移[27][31] - 保留失败尝试和错误信息在上下文中,使模型能隐式更新内部认知降低重复错误概率[35] - 错误恢复能力是衡量Agent智能的关键指标,但被多数基准测试低估[35] 少样本提示优化 - 少样本提示可能导致行为定式,如在简历审查任务中机械重复相似操作[36] - 通过引入序列化模板变体、调整措辞等增加多样性打破思维定式[37] - 上下文同质化会加剧Agent脆弱性,需保持受控随机性激活模型注意力[38]