做AI情报站这一年，我发现一个规律：**新工具每天都有，但真正影响你钱包的，是那些吵了好几个月还没结论的话题**——因为吵架的地方，就是认知差最大、也最值钱的地方。 今天不报新货，拆三场海外社区吵了很久、国内几乎没人系统讲过的话题：①METR那篇“资深程序员用AI反而慢19%”引发的大论战；②context engineering（上下文工程）上位后，Cognition和Anthropic两家关于“该不该上多Agent”的公开翻脸；③MCP到底是“AI界的USB-C”还是“多套一层壳的API”。每场都给你正反两派的完整观点，以及能直接抄的应对动作。 --- ## 话题一：用AI反而慢了19%？体感与现实的巨大裂缝 ### 事情经过 2025年7月，AI评测机构METR发布了一篇preprint研究（[官方博客](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)），实验设计很扎实：召集16名资深开源开发者，这些人是自己维护多年的成熟项目的主力贡献者。给他们246个真实issue，随机决定每个任务用不用AI辅助（Cursor、Claude Code等当时主流工具）。 结果反直觉：**用AI的那组，实际完成速度慢了19%**。 更狠的是感知差：这些开发者事前自估用AI能快24%，**干完活之后依然自估快了20%**。也就是说，他们一边被数据证明变慢，一边真心觉得自己变快了。 这篇研究在HN和r/LocalLLaMA上刷了几千条评论，是2025年下半年讨论度最高的AI实证研究之一。 ### 三派观点 **反方（质疑派）**：样本只有16人，全是“对自己代码库烂熟于心”的资深维护者——这恰恰是AI最不占优势的场景。任务多是维护性杂活，换成新项目、新语言、新代码库，结论很可能反转。而且用的是2025年初的模型，按模型迭代速度，数据已经偏旧。 **正方（感知差派）**：样本小不假，但“感觉更快、实际更慢”这个结构性现象，被后续大量从业者的自发对照普遍印证。HN上高赞评论说得刻薄但准确：“这是第一份量化了‘AI生产力幻觉’的研究。”哪怕具体数字换成-5%或+5%，感知差的存在本身才是重点。 **中立派（主流走向）**：METR自己也发了后续分析，承认AI能力在快速进步、预测滞后是普遍现象。到2026年，社区基本收敛成一个共识：**别管哪篇研究对，AI提效必须盲测，不能靠体感**。 ### 对中国用户的启示 这一条对国内团队的杀伤力其实更大。你要写周报、要向老板证明“上了AI工具有用”，体感天然被汇报文化放大。海外吵了几个月沉淀下来的方法可以直接抄： - **上AI工具前做一次盲测**：同一批真实任务，随机分组，量交付时长和返工率，半天就能搭起来； - **ROI别按“省了多少小时”算**（那是自估数据），按PR合并周期、bug回归率这些客观指标算； - 越是对自己业务烂熟的人，AI越可能帮倒忙——**新人友好、老手坑爹**，这是被反复观察到的模式。 --- ## 话题二：prompt engineering已死？多Agent之辩正面开撕 ### 事情经过 2025年年中，Karpathy在X上发帖，大意是：现在真正该研究的是context engineering（上下文工程），而不是prompt engineering——提示词只是一次性输入，上下文是持续管理的系统工程。这个说法迅速成为共识，“context engineering”从此取代前者成为招聘JD上的新词。 真正的好戏是两大厂公开分歧： - **2025年6月，Anthropic**发布[《How we built our multi-agent research system》](https://www.anthropic.com/engineering/built-multi-agent-research-system)，宣布他们的多Agent系统在内部研究评测中，产出比单Agent版Opus提升了90.2%（数据出自其官方博客）。同时承认代价：Agent场景token消耗约为普通聊天的4倍，多Agent编排可达15倍。 - **几乎同一时间，Devin背后的公司Cognition**发布[《Don't Build Multi-Agents》](https://cognition.ai/blog/dont-build-multi-agents)，正面开怼：别做并行多Agent。核心论点是**上下文才是关键资源**，并行子Agent把上下文切碎，每个子Agent都没有全局视角，容易出现两个Agent给出互相矛盾的方案还互不知情。Devin自己就是单线程架构做出来的。 - **2025年9月，Anthropic**又发[《Effective context engineering for AI agents》](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)，把上下文比作“注意力预算”——有趣的是，这篇的调性和Cognition其实已经接近：上下文是稀缺资源，要精打细算。 ### 两派观点拆解 **Anthropic派**：研究型任务是发散的——比如“调研某个领域”，可以拆成N个独立子问题，让子Agent各自带着干净的上下文去跑，主Agent汇总。并行度高、不怕某个子Agent污染全局。 **Cognition派**：写代码是强状态耦合的——改同一个文件的两个人（或两个Agent）必然打架。子Agent读不到完整决策链，做出的方案在细节处互相冲突，合并时全是灾难。 **中立派（现在的主流认知）**：这场架其实没吵输赢，吵出来的是**分界线**——探索型、可并行的任务（检索、调研、扫描）适合多Agent；强状态、强耦合的任务（写代码、改同一批文件）适合单线程。Anthropic自己的工程实践也印证了这点：他们的多Agent系统用于研究，而Claude Code主体仍是单线程。 用一张图把社区吵出来的决策逻辑画给你： ```mermaid flowchart TD A["拿到一个AI自动化需求"] --> B{"任务能否由单个会话在短时间内完成？"} B -->|能| C["单Agent加精简上下文"] B -->|不能| D{"子任务间需要频繁共享状态吗？"} D -->|需要| E["单线程多步Agent"] D -->|不需要| F["并行子Agent分头跑"] C --> G["用METR式盲测验收"] E --> G F --> G G --> H{"实测产出比不用AI更快吗？"} H -->|是| I["固化进日常工作流"] H -->|否| J["砍掉或降级为局部补全工具"] ``` ### 对中国用户的启示 国内圈子里“多Agent编排”的调门一直很高，很多人一上来就搭分布式Agent平台，抄的其实是2015年微服务那套思维。而海外吵了几个月得出的认知是：**多Agent是token放大器（约15倍开销）和一致性风险源，默认单Agent，出现明确发散需求再拆**。这个“默认单Agent”的结论，在国内的内容生态里几乎听不到。 --- ## 话题三：MCP是AI界的USB-C，还是多套一层壳？ ### 事情经过 MCP（Model Context Protocol）2024年11月由Anthropic开源（官网 [modelcontextprotocol.io](https://modelcontextprotocol.io)）。2025年3月，OpenAI宣布在Agents SDK和产品中支持MCP；2025年4月，Google DeepMind也宣布Gemini支持。**三大厂全部入局，MCP成为Agent连接外部工具的事实标准**，这一点争议不大。 争议在于：这层协议到底值不值得用？ ### 三派观点 **正方（标准派）**：写一次MCP server，Claude、Cursor、Gemini全都能用，接口层成本一次性摊平。2025年6月版规范加入Streamable HTTP和OAuth 2.1之后，企业级鉴权问题也解决了。官方注册表（registry）上线预览后，server的发现和安装也规范了。生态数据上看，各平台可用的server数量已经从百级涨到千级。 **反方（套壳派）**：HN上流传已久的毒舌总结——“MCP server就是一个套了JSON-RPC壳的函数调用”。你的客户端只有一个、工具只有五六个的时候，直接函数调用就行，包一层协议纯粹多一层bug。更实际的问题是token浪费：每个MCP工具的完整定义都要塞进上下文，工具一多，注意力预算（还记得话题二吗）直接爆掉。 **中间派（演进派）**：最有意思的是，Anthropic自己2025年11月发了[《Code execution with MCP》](https://www.anthropic.com/engineering/code-execution-with-mcp)，等于侧面承认了反方的token批评——他们给的解法是：不再把几百个工具定义全塞进上下文，而是让Agent直接写代码调API，只在需要时加载工具定义。据其博客数据，这种方式能大幅压缩token消耗。 ### 对中国用户的启示 判断标准很简单，两分钟做完： 1. **工具少于10个、只有一个客户端用** → 直接函数调用，别包MCP； 2. **要跨Claude/Cursor/Gemini多个客户端复用同一套能力** → 值得包一层MCP； 3. **已经用了MCP且工具很多** → 参考Anthropic的代码执行模式改造，别让工具定义吃光你的上下文。 另外提醒国内做集成的开发者：**别把MCP server做成微服务**。社区里被喷得最惨的都是那种带独立数据库、独立缓存、五个中间件的“重型MCP项目”——协议是轻量的，做重了就背离初衷。 --- ## 信息差总结 | 话题 | 你可能知道的 | 海外社区吵出来的真相 | |------|-------------|---------------------| | AI提效 | 体感快了，写进周报 | METR实测资深者慢19%，且当事人毫无察觉；提效必须盲测验收 | | 多Agent | 多Agent更强大，应该编排 | 默认单Agent；多Agent是15倍token开销+一致性风险，只适合发散型任务 | | MCP | 三大厂都支持，必须上 | 工具少就函数调用；工具多就学Anthropic改代码执行模式，协议不是银弹 | 三场吵架的共同底部逻辑只有一句话：**2026年AI工程的核心矛盾，从“模型不够强”变成了“上下文不够用”**——感知差吵的是注意力错配，多Agent吵的是注意力预算，MCP吵的还是注意力预算。谁先建立“上下文是稀缺资源”的直觉，谁就在用同样的模型价格跑出更高的产出。 ## 行动指南 1. **本周**：挑5个本周做过的真实任务，让团队随机分组复刻METR盲测，量一次真实的提效率（成本：半天）； 2. **本周**：读Cognition和Anthropic那两篇多Agent原文（正文给了链接），对照自己项目的任务形态，把架构里“为了炫技而拆”的子Agent砍掉； 3. **本月**：审计你喂给模型的上下文——大文档换成按需检索，工具定义超过20个就评估代码执行模式； 4. **本月**：如果你在做AI集成，用上面的“两分钟判断法”决定要不要包MCP； 5. **长期**：在HN和r/LocalLLaMA上设"METR"“context engineering”“MCP"三个关键词的关注，这三场架还没吵完，后续结论值得持续跟踪。 ## 参考来源 1. [METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 2. [Anthropic: How we built our multi-agent research system](https://www.anthropic.com/engineering/built-multi-agent-research-system) 3. [Cognition: Don't Build Multi-Agents](https://cognition.ai/blog/dont-build-multi-agents) 4. [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) 5. [Anthropic: Code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp) --- > 本文由「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 等场景全覆盖。