跳至主要內容

[基石2]上下文工程(Context Engineering)

whoway2026/2/1大约 4 分钟

[基石2]上下文工程(Context Engineering)

背景：从国外冷门研究→国内manus刻意炒作→国外cursor异军突起→好像真正的上下文工程是1个指的关注的领域

  • 最开始的不解：
    • 因为manus太刻意炒作了：2025年3月6日【一款名为Manus的“全球首款通用AI智能体”横空出世】亮点在于任务自动化和工具使用能力，然而，这并非独创，在这个时间之前：Devin、Cursor等海外产品早有类似理念
      当时的评价：专家指出，Mannus并非技术类破型产品，而是基于现有大模型（如Anthropic的Claude）整合而成，manus 属于“套壳“模式，它将多智能体协同优化为用户体验，但核心技术依赖他人。护城河薄弱

我的评价：那位专家确实指出来了核心还是依赖于基础模型，但是这个专家小看了：这种工程设计本身也是比较难的，后续我们发现cursor和claude code的区别就能发现！
特别是claude code打败国内一众的code agent，就展示了这种上下文工程设计能力还是有一定门槛，但是确实门槛可以靠挖人解决！

争议与短板：炒作嫌疑。上线未满3天

Open Manus等平替产品已开源复刻，技术壁垒低得惊人

用户体验：少数内测用户反馈

Manus常出错，如循环任务、漏信息，甚至订炸鸡三明治都失败

- 市场反应：海外波澜不惊、国内却炒得火热，资本推手痕迹明显

真正的笔记：Manus创始人：深度干货！上下文工程的最佳实践

提示工程是在ChatGPT之后开始受到关注的， 那是在2022年12月

image.png
image.png
  • 2025年05月出现的，上下文工程
  • 这与“代理之年”的理念有些吻合。
image.png
image.png
image.png
image.png

chroma：Performance drops as context grows

观察结果很简单：随着上下文的增长，性能会下降。

上下文工程设计的技巧

技巧1.上下文卸载

第一个想法是上下文卸载【太常用了，所以才有向量数据库】【最开始就有很多人做，只是manus可能在这个上面尝试了很多次时机？或者强调这个？
比如，把消息存在chroma里面去
可以被检索

image.png
image.png

技巧2.第二个想法是減少上下文【最开始claude做的

和上1个方法不同的是：
他只是在总结或压缩信息。
总结工具调用输出是实现这一目标的一种直观方式。
比如claude的做法，封了个SDK
当你达到整体业下文窗回的某介百分比时，它的压缩功能就会启动。
image.png

image.png
image.png

技巧3.检索上下文

image.png
image.png
  • 如今.这可能是你在X或TWitter，上看到激烈争论的经典话题之一：检索上下文的正确方法
  • Cursor的Lee Robinson刚刚做了一个非常精彩的演讲。
    • 他还在OpenAl演示日做了一个非常精彩的演讲，
    • 谈到Cursor例如，它使用索引和语义搜索，以及更简单的基于文件的搜索工具，如glob和grep。

上下文检索对于构建高效代理至关重要。

技巧4.上下文隔离

上下文隔离是我们看到相当多的另一个主要主题,特别是在多代理之间分割上下文。
那么这里的重点是什么？ 每个子代理都有自己的上下文窗口。子代理允许关注点分离。
Manus的wide agents提至可这一点。
image.png

技巧5.上下文缓存

image.png
image.png

关于这些的总结，不同研究的使用情况

image.png
image.png

manus的演讲【11分43秒】

Context Engineering for Al Agents

代理之年：所以七月基本上是上一个阶段了。

•当然，在这次会议之前，我又回去读了一遍。我认为我在那篇博客中写的大部分内容至今仍然适用
但我不想通过重复博客中已有的内容来浪费大家的时间。

  • 我想深入探讨一些我之前没有深入研究过；
    我们将重点关注兰斯之前幻灯片中不鼓励的那栏【也就是下面2个圈圈】
image.png
image.png

因为我个人认为， 探索那些非共识的想法往往能带来最大的启发。
image.png

参考资料