导语： 海外开发者圈正在打一场没有裁判的仗：Agent 到底该一个顶到底，还是组团分工作战？这场争论已经从 X 打到 Hacker News，再打到各家官方工程博客——Cognition 写文章劝你别搞多 Agent，Anthropic 晒出自家多 Agent 系统的成绩单，LangChain 则在框架争议里反复自证。三条战线吵了大半年还没分胜负，但每一方都掏出了可复用的实战结论。今天这篇把三方论点、落地判断标准和避坑清单一次给你，看完你至少能省掉一次架构返工。
这是三条战线里火药味最浓的一条。
事情的起因：Agent 圈去年流行一种「主脑 + 打工仔」架构——一个主 Agent 拆任务，若干子 Agent 并行干活，最后汇总。听起来很美，像把微服务架构搬进了 AI。
反对派的重炮来自 Cognition（做 Devin 那家公司）。据其发布的《Don't Build Multi-Agents》一文，核心论点只有一句话：两个没有共享完整上下文的 Agent，等于两个互相看不见对方工作的同事——他们的决策必然冲突。你让子 Agent A 改方案、子 Agent B 写代码，A 改完 B 重写，最后你在 merge conflict 里过夜。他们给出的原则是「先共享上下文，再行动」：如果做不到让所有执行者看到同样的信息，就老老实实单线程，用压缩（compaction）和结构化笔记（note-taking）来对抗上下文变长，而不是靠加人手。
支持派的回击来自 Anthropic 官方工程博客。据其《How we built our multi-agent research system》一文，他们的研究系统就是 orchestrator-worker 多 Agent 架构：主 Agent 负责拆解和规划，子 Agent 各自带独立上下文窗口并行搜索。他们自己也承认这套东西贵——token 消耗大约是普通对话模式的十几倍——但在「宽搜索、多线索」类研究任务上明显好于单 Agent。关键不是多 Agent 万能，而是任务要选对：适合的场景是并行子任务互不依赖、结果可以机械合并（比如「调研这五个竞品的定价」），不适合的场景是环环相扣的编辑决策（比如「把这个模块重构了」）。
中间派（也是 HN 高赞评论的主流声音）总结得很朴素：多 Agent 先慢后乱。原型阶段一个人写循环最快，等你发现上下文窗口真装不下了、或者任务天然可并行可验收了，再拆不迟。
对中国开发者的实用转化——把「要不要拆多 Agent」压缩成三个门槛问题，三个全过才拆：
flowchart TD
A["任务要拆多Agent吗"] -->|子任务互不依赖| C{"上下文装得下吗"}
A -->|环环相扣| B["单Agent加压缩"]
C -->|装得下| B
C -->|装不下| D["子任务可独立验收吗"]
D -->|可以| E["并行子Agent"]
D -->|不可以| F["顺序流水线"]
E --> G["机械规则合并结果"]
F --> G
G --> H["全程留痕可回放"]
B --> H
反过来记更省事：只要有一个答案是「不行」，就留在单 Agent。这条清单能帮你挡掉九成跟风上多 Agent 的冲动——省的是真金白银的 token 和返工时间。
第二条战线更老、更持久：做 Agent 该用 LangChain 这类框架，还是直接裸写 API 调用？
反框架派的阵地在 Hacker News。隔一阵子就会出现一篇「LangChain 的抽象比它解决的问题还多」的帖子，评论区高赞理由通常三条：抽象泄漏严重，出了 bug 要钻进框架源码调试；API 迭代太快，升级即返工；很多场景就是「调一次接口、跑一个循环」，引一个重依赖纯属给自己埋雷。不少团队的真实路径是：原型期用框架，生产期把框架一层层剥掉，只留直连 SDK 加自写胶水代码。
撑框架派（包括 LangChain 官方博客的多次回应）的反驳也成体系：原型速度就是钱；几百个文档加载器和向量库集成是白送的；生产级 Agent 真正难的不是调 API，而是状态管理、流式输出、人工介入后的断点恢复——这些恰恰是 LangGraph 这类图编排框架的积累所在。他们的观点是：反框架的人只是没做到需要框架的复杂度。
官方风向标值得单独说。据 Anthropic 的《Building effective agents》一文，官方示范全程强调「从简单可组合模式起步」：提示链、路由、并行化、orchestrator-workers、评估者-优化者，五个模式能用一个循环加几个工具调用实现的，就别上框架。有意思的是，这篇被反框架派奉为圣经，但 LangChain 团队也公开表示认同——双方争的根本不是「框架有没有用」，而是「什么时候才需要它」。
实用转化，三步判断法：
第三条战线是话语权之争，但背后是真金白银的工程方法转移。
据社区广泛转述，Andrej Karpathy 去年在 X 上提出：对 Agent 时代来说，「context engineering（上下文工程）」比「prompt engineering（提示工程）」描述更准确——你的模型每一轮真正吃进去的，是一整包东西：系统提示、工具定义、检索片段、记忆文件、子 Agent 的返回摘要。工程重点从「怎么问」变成了「每一轮该往窗口里装什么」。
支持方认为这不是造词，是工作重心的真实迁移：系统提示瘦身、工具描述写精确（一个含糊的工具描述会让 Agent 整场跑偏）、检索分块策略、把事实外置成文件按需读取、上下文快满时的压缩策略——这些占了 Agent 工程八成的工作量，而它们都不是传统意义上的「写 prompt」。
反对方在 HN 上嘲讽这是「2017 年的老活儿起了个新名字」，本质还是把对的 token 喂给对的模型，换词只是为了让咨询费显得更贵。
中立而实用的立场：叫什么不重要，操作清单是一致的——
| 你以为的 | 别人已经在做的 |
|---|---|
| 多 Agent = 高级 = 强 | 拆错场景的多 Agent 更慢、更贵、更乱，官方博客都劝退 |
| 用框架才显得专业 | 各家官方示范全部从裸写循环起步，框架是特定痛点的药 |
| Prompt 工程已经过时 | 它改名「上下文工程」并且更卷了，重心变成窗口管理 |
| 架构之争是玄学 | 三条战线都有可执行的判断清单，十分钟给自己项目做体检 |
anthropic.com/engineering，精读《Building effective agents》和《How we built our multi-agent research system》两篇，一边读一边对照自己的项目画架构图；hn.algolia.com 用 multi-agent、context engineering 等关键词按时间排序搜热帖，这条战线每月都有新弹药，比追营销号快得多。本文由「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 等场景全覆盖。