过去一年，海外AI圈吵得最凶、但对动手党最有价值的，不是哪个新模型又刷了榜，而是一场关于上下文（context）的连环论战。Devin的母公司Cognition发文叫大家别造多Agent，Anthropic甩出90.2%的实测数据说多Agent真香，Chroma拿18个模型把“超大窗口”的营销神话测了个底朝天，最后反而是华人团队Manus写出了被引用最多的一篇工程总结。国内不少从业者还停留在“提示词技巧”层面，而海外已经把这整套东西正式命名为context engineering（上下文工程），并且吵出了路线之争。这篇文章把三场论战一次拆完：谁支持、谁反对、数据说了什么、你该抄哪几招。
2025年6月底，OpenAI前联合创始人Andrej Karpathy转发Shopify CEO Tobi Lütke聊“怎么给Agent喂上下文”的推文时补了一句：“+1 for context engineering over prompt engineering”——给上下文工程投票，它比提示词工程更准。这条推文基本算是给这门“新学科”正名了。
HN上立刻分成两派。反对派说这是旧酒新瓶：提示词工程从第一天起就包括组织上下文，换个词纯属制造焦虑。支持派（以一线Agent开发者为主）反驳：这两个词指的东西早就分家了——提示词工程管“怎么措辞一句话”，上下文工程管“在有限的窗口预算里，放什么、不放什么、什么时候放”。措辞是修辞，调度是架构。
2025年9月底，Anthropic在官方工程博客发布《Effective context engineering for AI agents》，等于官方盖章。这篇文章里最有传播力的一个比喻是：上下文是注意力预算。和人一样，模型处理长上下文时会“失焦”——窗口大不等于都认真看，目标是“找到最小的高信号token集合（smallest set of high-signal tokens）”，而不是往窗口里疯狂塞料。
对国内读者的启示很直接：这不是名词游戏。当你在写Agent系统、调RAG、做企业知识库时，真正要优化的是“窗口里有什么”，而不仅仅是“这句话怎么写”。海外招聘里context engineering已经成了独立技能关键词，国内JD里还没普遍出现——这就是时间差。
这是整场战争最精彩的一仗，双方都是头部公司，观点正面相撞。
2025年6月，Cognition（Devin的开发商）发布《Don't Build Multi-Agents》，作者Walden Yan，核心主张只有两条原则：
按这个逻辑，多Agent系统天生有病：上下文割裂导致目标漂移、重复劳动、相互矛盾的决策。Cognition的结论很极端：他们连“上下文工程”这个词都嫌多余，因为上下文工程就是全部，而多Agent恰恰把上下文工程做得最差。
同一个月，Anthropic发布《How we built our multi-agent research system》，拿数据打对台。据Anthropic实测：在内部研究评测集上，多Agent系统（Claude Opus 4当主编排、Sonnet当子Agent并行搜索）的成绩比单Agent Opus高出90.2%；token用量能解释性能差异的约80%；多Agent的token消耗约是普通聊天的15倍（普通Agent式对话约是聊天4倍）。
但注意，Anthropic自己划了边界：多Agent只适合宽任务——开放式的调研、并行izable、答案分散在海量来源里；而写代码这种紧耦合任务（子任务之间要频繁看彼此的草稿），恰恰是Cognition说的那类，不适合开分身。也就是说，两家吵的是“默认架构选哪个”，不是教条。
第三方Manus给出了最实用的中间路线。2025年7月，Manus团队发布《Context Engineering for AI Agents: Lessons from Building Manus》，直言他们不用多Agent，但把单Agent做到了极致，几条经验被反复引用：
顺带说一句：Manus是国内团队做的产品（后迁至新加坡），这篇被海外工程师引用最多的上下文工程总结，最初就来自一支华人团队——这点很多人不知道。
给你的决策图如下：
flowchart TD
A["接到一个Agent任务"] --> B{"一句话能说清目标吗"}
B -->|能| C["单Agent直做<br/>全程共享上下文"]
B -->|不能| D{"子任务要互看<br/>中间结果吗"}
D -->|要| E["仍用单Agent<br/>中间产物写进文件"]
D -->|不要| F["开子Agent并行跑<br/>只回传结论"]
C --> G["省token<br/>不易跑偏"]
E --> G
F --> H["费token但覆盖广<br/>适合调研搜索类"]
第三个战场围绕窗口军备竞赛。厂商拼命卷数字——百万级token窗口已成旗舰标配，营销话术是“整本书、整个代码库直接扔进来”。
2025年9月，向量数据库公司Chroma发布研究报告《Context Rot》，给这波营销泼了冷水。他们测了18个模型（覆盖GPT、Claude、Gemini、Qwen等主流系列），结论是：随着输入token变长，模型性能普遍衰减——连“大海捞针”这种专门为长窗口设计的简单任务都躲不掉；而且文档结构、信息重复程度、任务表述方式都会显著影响衰减程度。
社区反应立刻两极。r/LocalLLaMA和HN上，“窗口数字是营销”派拿到了实证弹药；另一派反驳说新模型一代比一代抗衰减，且该研究的任务是合成任务，真实复杂场景的表现仍有分歧——这一点各家都还没有定论，别把任何一边当成绝对真理。
工程界的应对倒是很一致，三家做Agent产品的给出了同一套答案：
/compact。但压缩必丢细节——所以关键结论要主动写进CLAUDE.md或笔记文件，别指望窗口替你记。最后提醒一点，别把这场仗和之前社区里吵的“Agent记忆之争”（文件党vs向量党）搞混：记忆管的是跨会话的持久化，上下文管的是单次会话内的窗口调度——两套问题，两套工具。
flowchart TD
A["一次Agent运行的<br/>上下文预算"] --> B["系统提示与工具定义<br/>常驻大头"]
A --> C["历史对话<br/>越滚越长"]
A --> D["检索来的资料<br/>即取即用"]
C --> E["接近上限<br/>自动压缩续命"]
E --> F["压缩丢细节<br/>关键结论落盘"]
D --> G["只留高信号<br/>宁少勿多"]
| 大多数人以为 | 圈内已经吵明白的 |
|---|---|
| 提示词写好就行 | 上下文是注意力预算，优化对象是整个窗口的调度 |
| 窗口越大越强 | 18个模型实测：变长必衰减，必须用自己的任务实测 |
| 多Agent=先进架构 | 默认单Agent；只有宽任务才值得15倍token开分身 |
| 自动压缩是免费续命 | 压缩必丢细节，关键结论要主动落盘成文件 |
| context engineering是新词营销 | Anthropic已发官方指南，海外JD已当独立技能招聘 |
/context，直接看到系统提示、工具定义、历史对话各吃掉多少token。很多人看完才发现工具定义占了小一半。CLAUDE.md或NOTES.md），再压缩、再继续。本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。