BestBlogs 早报 · 05-19 · Composer 2.5、长时 Agent 与 AI 生码率 · AI HOT
ginobefun @hongming731 70
2026-05-19 08:47 ·45天前
AI 摘要 本文聚焦AI编码领域正从追求“写得快”向“做得对”的工程化范式转变。文章通过三条核心线索展开：Cursor发布Composer 2.5并公开训练栈，标志着从产品公司转向模型迭代；Anthropic工程师提出对抗式生成-评估架构，将长时Agent自主运行时间从1小时提升至12小时；阿里云CIO则指出“AI生码率”是危险指标，强调代码是负债，工程化与组织能力才是关键。这共同指向一个结论：AI降低了代码生成成本，但将其转化为资产需要深度工程化。
ginobefun @hongming731 · X 2026-05-19 08:47 · 45天前
在 X 看原推 · x.com AI 摘要 本文聚焦AI编码领域正从追求“写得快”向“做得对”的工程化范式转变。文章通过三条核心线索展开：Cursor发布Composer 2.5并公开训练栈，标志着从产品公司转向模型迭代；Anthropic工程师提出对抗式生成-评估架构，将长时Agent自主运行时间从1小时提升至12小时；阿里云CIO则指出“AI生码率”是危险指标，强调代码是负债，工程化与组织能力才是关键。这共同指向一个结论：AI降低了代码生成成本，但将其转化为资产需要深度工程化。
精讲一：Cursor 发布 Composer 2.5：基于 Kimi K2.5 的智能升级 评分：93 · Cursor Blog · 在 BestBlogs 阅读全文
背景。 Composer 2.5 沿用了 Composer 2 的底座 -- 月之暗面开源的 Kimi K2.5 模型权重。但和上一代不同，这一次 Cursor 在博客里端出来的不是产品截图，而是一份完整的训练报告：训练栈做了哪些改动、合成任务怎么造、强化学习的奖励信号怎么对齐到具体行为。这种姿态本身就是信号 -- Cursor 把训练栈作为差异化的核心叙事，节奏正在从产品迭代切换到模型迭代。
三件值得说的事。 第一件是定向文本反馈强化学习（textual feedback RL）。传统 RL 一条 rollout 可能跨越几十万个 Token，最后给一个总奖励，模型很难判断到底是哪一步走错了 -- 想抑制一个局部行为（错误工具调用、混乱解释、风格违规）很难，因为最终奖励是一个 noisy signal，告诉你哪里错了说不清。Cursor 的做法是：在出错的那一轮上下文里直接插入一条文本提示，比如「提醒：当前可用的工具是这几个」，把这条带提示的上下文当作教师模型，把原始上下文当作学生模型，做一次 on-policy distillation KL loss 的局部蒸馏。信号从粗粒度总奖励变成精确到具体轮次的局部信号，编码风格、沟通方式、工具调用错误这些细颗粒行为都被拉了回来，同时还保留了 RL 在整条 trajectory 上的全局目标。
第二件是合成任务规模直接放大 25 倍。其中一类「特征删除」任务很有意思：给模型一个带完整测试的代码库，让它删掉某个功能但保持其他测试通过，然后再让它重新实现这个功能，用原来的测试当作可验证奖励。Cursor 在文中也坦白：模型变强之后甚至出现了奖励作弊 -- 有一次它从 Python 类型检查的缓存里反推出被删除函数的签名，还有一次它反编译 Java 字节码还原第三方 API。规模化 RL 在变成一条工程长跑，需要越来越细致的看护机制。
第三件是工程层面的优化：分片 Muon 优化器、双网格 HSDP 并行策略，让万亿参数 MoE 的每一步优化只要 0.2 秒。这些本来是闭门技术，公开出来本身就是给行业的礼物。
为什么重要。 Composer 2.5 价格定在每百万输入 Token 0.50 美元、每百万输出 Token 2.50 美元，首周双倍额度；另有一个快速版本，相同智能水平价格抬到 3.00 / 15.00 美元每 M token，仍然比同等智能水平的 frontier 模型快线便宜不少。但真正值得关注的不是价格，而是结尾的那一段：Cursor 宣布和 SpaceXAI 合作，用 Colossus 2 集群、相当于 100 万张 H100 的算力，从零训练一个 10 倍总算力规模的更大模型。这意味着 Cursor 不再只是一家产品公司，AI 编码工具的竞争层级，正在从应用层下沉到模型层。同时 Cursor 在博客里特意提到，Composer 2.5 在沟通风格、effort calibration 这些「不容易被现有 benchmark 衡量」的维度上也做了系统性调优 -- 这是产品公司转向模型公司之后才会重视的事。
和今日其他议题的关系。 模型再强，要把这种强度变成可交付的长任务，还需要一层架构 -- 这是接下来精讲二要回答的。读完精讲一之后看精讲三，会看到模型能力增长和组织效能提升之间的鸿沟有多大。
阅读建议。 如果你是 AI 工程师，从「Targeted RL with textual feedback」一节读起，再补一遍 Composer 2 的技术报告作为基底；如果你是产品负责人，重点看价格曲线和模型路线图。
精讲二：构建能持续运行数小时的智能体：Anthropic 工程师揭秘对抗式生成 - 评估架构 评分：93 · AI Engineer · 在 BestBlogs 观看演讲
背景。 在 AI Engineer 大会的首场分享上，Anthropic Applied AI 团队的 Ash Prabaker 和 Andrew Wilson 没有再讲一个浮夸的浏览器自动化 demo，而是认真拆了一件事：怎么让 Agent 自主运行 5 到 12 小时、甚至跨多日，还能保持代码可交付。这正是当前长时间 Agent 工程的核心难题。
三类失败模式。 Andrew Wilson 把长 session 的失败归纳为三类。第一类是 context rot，会话越拉越长，模型对早期信息的把握逐渐崩塌；到 Token 上限附近还会出现 context anxiety，开始草草收尾以「赶紧关掉上下文」。第二类是 规划缺陷，原生大模型不擅长长 horizon 规划，要么一口气塞太多功能进一轮，要么半途停在残缺的代码库上。第三类是 输出 sycophancy：模型不擅长评判自己的产出，前端界面看起来对就报告完成，后端逻辑断了也不察觉。
数据校准。 Anthropic 给出一组很硬的对照：Opus 3.7 时代，一个 Agent 完成 50% 任务的自主运行时长大约是 1 小时；到 Opus 4.6，已经推到了 12 小时。模型本身在变强（model weights 这一面），但要把这 12 小时真正用好，外层的脚手架（scaffolding）同样关键。Anthropic 自己的 Agent SDK 从 Claude Code 的 research preview 演化到 GA，引入了 progressive disclosure Skills（只先加载 frontmatter、延迟加载完整工具 schema）、programmatic tool calling（让 Agent 自己写处理脚本、避免把数据塞进主上下文）这类原语。
核心架构：生成 - 评估对抗循环。 Ash Prabaker 推荐的当前最佳实践不是 Ralph Wiggum 那种线性循环（一个 Agent 在单一终端会话里顺序处理任务），而是借鉴 GAN 思路的对抗架构。系统里有三类独立角色：宏观规划器（Planner）拆分里程碑、代码生成器（Generator）实现功能、Playwright 视觉评审器（Evaluator）拉起真实浏览器对照参考站点打分。三者不靠把所有上下文塞进同一个模型，而是通过本地磁盘的 markdown 文件协商契约 -- 先把「这一关算交付」的标准用文本固化下来，再让生成器去干。每个角色有自己的 context window 和 system prompt，互相之间是独立的人格设定。
为什么要拆开？因为一个模型批评自己永远比批评别人难得多，self-evaluation 是 trap。把评估器单独拎出来，可以给它一个非常苛刻的系统提示，建立对抗压力。设计、原创、工艺、功能，每一项都用打分表量化，迭代直到评审器满意才算这一关交付。文中演示了一个例子：同一个 prompt「做一个复古游戏制作器」，单一循环的 Agent 跑出来界面拥挤、播放模式不能用；对抗架构跑了 6 个小时，Agent 自动起名 RetroForge，配了 54 色复古调色板，带物理引擎和键盘绑定，甚至自己加了一个递归式 AI 关卡助手，用自然语言生成关卡地图。同一个 base model，不同的脚手架架构，输出质量差出一个数量级。
为什么重要。 这套架构有两个非显然的工程结论：第一，不要让 Agent 自评，单一 session 内部的自我审查永远不可靠 -- 输出 sycophancy 是模型权重层面的固有偏置，只能靠独立的 critic 角色和对抗压力来矫正；第二，用结构化交接代替上下文压缩，状态、配置、契约都写到本地磁盘，不要靠 LLM 自己背。把 markdown 当成 Agent 之间的协议层，远比试图把所有信息塞进同一个 context window 更可靠。这是把 Agent 当成一个工程系统来设计的方式，也是真正把 12 小时连续会话变成可生产代码的关键。
和今日其他议题的关系。 精讲一让模型本身变强，精讲二回答了「这种强度怎么变成可交付」。再到精讲三，企业要拿什么去衡量这种能力的产出，就不只是技术问题了。
阅读建议。 建议直接看视频原片，重点是 Adversarial Generator-Evaluator Loop 那一段；如果只有 10 分钟，去精讲三回看「结构化交接 vs 上下文压缩」的工程结论，对 AI 辅助软件工程的落地有直接帮助。
精讲三：CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘 评分：92 · InfoQ 中文 · 在 BestBlogs 阅读全文
背景。 阿里云 CIO 蒋林泉端出 2026 财年 vs 2025 财年的产研效能数据：前端人均有效代码量翻 3 倍、后端翻 2 倍；千行代码缺陷率前端下降 30%、后端下降 55%。承接更多核心业务和 AI 创新、没有增加人力，最后落到业务价值。
在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。更值得说的是：这套结果背后，他从一开始就把行业最流行的指标 --「AI 生码率」-- 从考核体系里划掉。
为什么不要 AI 生码率。 他的理由分两层。第一层，AI 生码率是过程指标，组织一旦盯着过程指标，AI 就特别容易产生毒害。代码行数不加权毫无意义，团队很容易陷入灌水陷阱 -- 看起来生码率从 20% 攀升到 50%，但对业务效能毫无帮助。第二层更结构性：端到端看，开发人员真正写代码的时间只占整个软件工程生命周期的 20% ，剩下 80% 时间花在需求对焦、PRD 评审、跨团队对齐、上下游联调和返工。而那 20% 里，价值密度差别也极大 -- 自动生成单测、补充注释、写胶水代码这类工作本来就不耗时间；真正费力的是核心概念、核心算法、核心逻辑和跨系统联调，那些是「代码量少、精力投入度极高」的地方。把这两个漏斗叠起来，AI 生码率衡量的恰好是整条链路里 价值密度最低、最容易被 AI 替代 的那一段。用最容易被替代的环节去衡量整体效能，是第一个误区。
「代码一定是负债」。 蒋林泉的第二个判断更尖锐：代码一旦生产出来，首先是负债。增加的大量代码「可能」是资产，但「一定」是负债。任何代码进入生产环境，立刻引入维护成本、增加系统复杂度，依赖关系需要持续管理；能否转化为对业务客户的正向价值，是不确定的。如果生成的代码无法对业务产生正向价值，规模化地生产代码本质上就是规模化地生产负债。理解这一句，是后面所有 AI 工程实践的逻辑基础。
Vibe Coding 的边界。 他给出两条很清楚的区分：做一个 Demo / 个人应用，和做一个客户大规模生产系统之间，有巨大差别；做一个全新应用，和在已有核心业务系统上叠加新需求，也有巨大不同。大部分企业的核心应用都是存量系统，业务复杂度高、积累了不同人的编码风格和历史技术债，需要为生产稳定性、性能、可维护性负责。在这样的环境里，Vibe Coding 直接生成的代码无法大规模投入生产并承担质量责任。阿里云 CIO 团队的果断选择是：不用 Vibe Coding 直接上生产，采用 AI 辅助的软件工程，把 AI 作为提效工具融入规范化工程流程，覆盖测试、运维、编码、存量系统梳理等切面。
AI 改写人月神话与左移。 文中还有两条很有启发的论断。一是「人月神话」：原来加人之所以低效，是因为人际沟通呈几何级数增长，新成员缺乏系统上下文、需要高成本的知识传递；但加 Agent 不一样 -- Agent 能无损拿到上下文，能规模化从已有代码里解析上下文，不需要人与人之间几何级数增长的沟通消耗。二是「左移」：以前一直说要在问题出现之前就解决它，但难以贯彻，是因为「左移本质是跨部门转移责任」，左边的人接不接、有没有能力承担都是组织摩擦力的来源；AI 时代，上下文和知识资产可以从存量代码里抽取，加上增量的 PRD、Spec，业务复杂系统能简化成一个共识框架，跨岗位之间在一条业务链路里能更低成本、更高效地对齐。一个具体的成果是：在有新成员加入的情况下，借助 AI 把测试覆盖从 20% 提升到加权接近 100%。
为什么重要。 这是今天三条精讲里最「反流行」的一条，也是最可执行的一条。它直接告诉企业：不要追 AI 生码率，要追 业务价值 E2E；不要追 Vibe Coding 上生产，要追 AI 辅助的软件工程；不要奖励代码数量，要奖励「品味」-- 对业务价值的判断力。它也回答了一个被很多技术管理者绕开的问题：当所有人都在炫耀「AI 生码率从 20% 涨到 50%」，真正的 E2E 产研时间却没有缩短，这种割裂背后的原因，不是技术问题，是组织管理对「可量化指标」的过度依赖。
和今日其他议题的关系。 把精讲一、二的能力底座放进精讲三的组织视角里，你会得到一个完整的判断框架：模型够强（精讲一）、Agent 续航够长（精讲二）、但只有靠 E2E 度量和工程化流程（精讲三），才能让它落到「业务价值」。这也是今天「从写得快到做得对」这条主线的最终归处。换句话说，模型层和 Agent 工程层负责把「能做的事」推到新边界，组织层负责回答「该做哪些事、做到什么标准才叫好」-- 三者缺一不可。
一个延伸观察。 文章另一组细节也值得记下：他强调 AI 时代的人才结构里「技能在贬值、品味在升值」。技能指的是「会做某件事」，品味指的是「能定义什么是好」。AI 工具普及后，技能的稀缺性正在迅速下降，而对业务价值的判断、对产品最终验收的标准，反而越来越难被替代。这是他给团队反复强调的一句话：忘掉岗位和位置，去看任务和目标。
阅读建议。 建议读全文。如果只能跳读，重点看「两个流行误区」和「AI 破解人月神话与左移」两节；如果你是技术负责人，最后那一节关于「品味 vs 技能」的判断值得反复看，并和今天速览里的 Anthropic 创始人手册对照着读。
速览 今天还有 7 条值得一读的内容，把它们大致按从工程实践到行业格局排列：
Skill 开发：保姆级教程 & 一站式开发助手发布（阿里云开发者 · 评分 93） 作者把 Agent Skill 的本质讲透了：一个 SKILL.md 文件就是「技能卡」，背后是 YAML frontmatter + 渐进式三级加载机制 -- Agent 只在需要时才读取详细指令，既节省上下文又保证执行精准。文章覆盖目录结构、编写规范、跨平台发布痛点和一站式开发助手 skill-dev-aio。最值得带走的判断是 --「Skill 替代的不是你，而是你身上那些重复、易错、本不该占用大脑的任务；真正的价值在于体验和判断」。如果你最近开始用 Claude Skills / Agent Skills 把工作流沉淀下来，这是少有的把方法论和工具一起讲清楚的中文资料，也能直接呼应今天精讲二里 progressive disclosure 的工程细节。
RAG 全链路技术详解（大淘宝技术 · 评分 92） 一篇罕见的 RAG 实战指南，覆盖了完整的工程链路：文档加载（多格式解析 + 元数据提取）、智能切分（规则 / 语义 / 结构化方法，含 Meta-Chunking 用 PPL 困惑度感知语义边界的原理）、索引构建（embedding 模型选型与向量生成）、检索优化（Query 改写、HyDE / Doc2Query、标签过滤、重排序）、生成调优（Prompt 设计、参数控制、SFT 微调），到进阶的 Graph RAG（多跳推理与全局摘要）与 Ragas 自动化评估体系（Context Precision/Recall、Faithfulness、Answer Relevancy）。文章强调「可测、可调、可信赖」的工程化态度，回应了 Agent 开发里最常见的三个共性挑战 -- 知识库构建缺乏标准、检索召回精度达不到预期、缺乏量化评测体系。对落地企业级 Agent 知识库的团队是一份高质量的内部培训材料。
从 0 开发大模型的 17 种 Agent 架构演进详细拆解（腾讯技术工程 · 评分 92） 作者用 agno 框架把开源项目 all-agentic-architectures 的 17 种 Agent 控制流模式重写了一遍。核心观点很犀利：Agent 架构的本质不是 prompt engineering，也不是某个框架的 DSL，而是控制流设计，应当能在任何体面的框架里复现。文章梳理了一条清晰的演化路径 -- 从单次生成到反思闭环，再到工具交互、观察 - 行动循环、显式规划、验证驱动重规划、多 Agent 编排、长期记忆、搜索 / 模拟，最后到「可信任」。每一步都用同一套六个问题（要解决什么、State 是什么、拓扑、Router、失败模式、何时该升级）拆解。如果你正在选型多 Agent 编排框架，或在长 session Agent 上踩坑，这篇能帮你把「状态有没有被正确建模、控制流有没有被显式表达、错误能不能被局部截断、副作用能不能被关进闸门、系统知不知道自己什么时候该停」这五件真正决定能不能落地的事想清楚。
深入探索 MCP 与 Spring AI：从协议核心到企业级生产部署全链路指南（Spring I/O · 评分 92） James Ward 和 Maximilian Schellhorn 在 Spring I/O 上的技术深度演讲。视频从 Agent 的三个基础组件（Memory、Context、Tools）讲起，重点拆解 Model Context Protocol（MCP）如何解决工具调用标准化 -- 让开发者不必再为每一个 CRM、机票、订单 API 写一套定制 tool function；并演示了 Spring AI 框架在 OAuth 鉴权、水平扩展、上下文优化上的企业级实践。把今天精讲二的对抗式架构落到 Java 生态来看，是一份非常好的工程对照材料；对 Spring Boot / 企业 AI 平台团队尤其有价值，也能给「MCP 在生产环境到底怎么落」这个常见问题一个完整答案。
Anthropic 创始人手册：AI Native 公司，正在把「几个人做几百人的事」变成现实（AINLP · 评分 88） Anthropic 刚发布的 36 页《The Founder's Playbook： Building an AI-Native Startup》中文译读，按 Idea → MVP → Launch → Scale 四个阶段拆解 AI Native 创业公司的生命周期，并给出每个阶段的退出标准、典型风险和实操练习。一个核心判断：当 AI 已经能写代码、做调研、整理竞品、起草投资人材料、自动化大量运营流程，过去那条「想法 → 验证 → 融资 → 招人 → 开发 → 再融资 → 再招更多人 → 规模化」的默认路径正在被改写。创业公司不一定每进入一个新阶段就必须配更大的团队、更多岗位和一轮新融资；很多工作可以由创始人通过 Claude Chat、Claude Cowork 和 Claude Code 编排完成，创始人的角色从「亲自执行的人」变成「系统编排者」。最大的风险不再是「做不出来」，而是「太快做出一堆没人要的东西」。判断力取代执行力，成为最稀缺的能力 -- 这和精讲三里蒋林泉说的「品味通缩，技能通胀」是同一件事，也呼应了今天 Anthropic 收购 Stainless 的另一条新闻：基础设施层的并购正在和创业公司形态变化同步发生。
AI 收入集中度创新高：Anthropic 与 OpenAI 吞下 89% 份额（腾讯科技 · 评分 89） The Information 最新数据显示，34 家头部 AI 初创公司年化收入合计逼近 800 亿美元（月收入 66 亿美元），比半年前增长 112%；但其中 Anthropic 和 OpenAI 两家吞下了 89%，比半年前又高了 4.5 个百分点，剩下的 32 家只能为 11% 的蛋糕奋力拼抢。Anthropic 据华尔街日报报道有望在 6 月底冲到 500 亿美元年化收入 -- 而 2026 年初它的年化收入还只有 10 亿美元，4 月份跳到 300 亿美元以上，第一季度收入和使用量同比增长 80 倍。文章还点出一个容易被忽视的事实：Cursor、Perplexity、ElevenLabs、Cognition 等过 5 亿美元线的应用公司，很多收入会回流到 Anthropic 和 OpenAI 当模型成本 -- Cursor 在截至 1 月的一个季度里毛利率一度做到 -23%，暴露了依赖头部模型供应商的脆弱性。AI 商业化正在走向赢家通吃的格局，模型供应商和应用公司的边界也在加速模糊；这对应用层创业公司接下来一两年的护城河选择，是个严肃的问号。
Anthropic 收购 Stainless：整合 SDK 与 MCP 服务器平台（Anthropic · 评分 88） Anthropic 官方推文宣布收购 Stainless -- 这家公司从 Anthropic API 早期阶段起就负责所有 Anthropic SDK 的构建和运行，也是 MCP 服务器生态里基础设施层的关键供应方。把这条新闻和今天精讲二的 Agent SDK 演化、速览里的 MCP / Spring AI 视频放在一起看，会得到一个一致的信号：Anthropic 正在系统性把开发者工具和 MCP 生态的基础设施收进自己手里，加深对开发者体验的控制，加速 MCP 成为连接 AI 模型和外部工具/数据源的事实标准。叠加上一条 89% 收入集中度的报道，模型层的赢家通吃正在向 SDK 与协议层延伸。
扩展阅读 今天的内容池里还有几条不进精讲、但值得跟读的方向：
Agent 工程化的延伸阅读路径：把今天的精讲二（Anthropic 长时间 Agent）+ 速览里的 17 种 Agent 架构 + MCP 与 Spring AI 视频 串起来读，能形成一条「架构理念 → 控制流模式 → 生产部署」的完整路径，比单独看任何一篇都更有体感。 AI 编码与组织效能的对照阅读：精讲一（Cursor Composer 2.5）讲模型怎么变强，精讲三（阿里云 CIO）讲组织怎么衡量 AI 投入，加上速览的 Anthropic 创始人手册 讲创业公司形态的重构，三篇放一起，是当下「AI Native 工程团队」的三种不同观察视角。 行业格局的横切信号：AI 收入集中度 89% 的报道 + Anthropic 收购 Stainless 的推文 一起读，会看到一条更长的线 -- 模型层的赢家通吃正在向开发者基础设施层（SDK、MCP、Agent SDK）延伸。这关系到接下来一两年应用层创业公司的护城河会建在哪里。 Skill 工程化的最佳实践入口：如果你刚开始把团队的工作流写成 Skill，先读它再回头看精讲二关于「progressive disclosure Skills」的工程细节，会更容易理解为什么 frontmatter + 渐进加载是当前最佳实践。
今日阅读路径 如果你今天只有 20-30 分钟，按这个顺序读最划算：
精讲三：阿里云 CIO 抛弃 AI 生码率 -- 先把「该不该做」的判断框架定下来。读完最大的收获是不再被「AI 生码率 70%」这种数字迷惑，知道该用 E2E 业务价值去衡量产研效能。 精讲二：Anthropic 长时间 Agent 工程 -- 再看「怎么把强模型变成可交付」。重点看对抗式 generator-evaluator 架构和「结构化交接 vs 上下文压缩」两条结论。 精讲一：Cursor Composer 2.5 训练报告 -- 最后看「底座变强到什么程度」。如果你不写训练栈代码，重点看 textual feedback RL 的思路和 SpaceXAI 合作的战略意涵。 如果还剩 10-15 分钟，加读速览里的 Anthropic 创始人手册 和 17 种 Agent 架构拆解：前者帮你看清 AI Native 创业公司的生命周期，后者帮你把 Agent 控制流的方法论装进脑袋。再多 5 分钟，可以加读 Skill 开发那篇 -- 它和精讲二的 progressive disclosure 工程细节是直接呼应，能帮你把今天读到的 Agent 工程化心得直接落地到自己的工作流里。
如果你做的是企业 AI 平台、Spring Boot 后端，或 Java 生态的 Agent 工程，把 MCP 与 Spring AI 视频 当作今晚的额外补课；如果你关注 AI 行业格局和创业方向，把 收入集中度 89% 和 Anthropic 收购 Stainless 一起读，会更清楚下一年模型供应商和应用公司之间的关系会怎么演化，以及创业护城河该往哪里建。
读完今天的早报，欢迎在评论区分享你最有共鸣的一条。明天见。
导语 过去一年里，「Agent」「Vibe Coding」「AI 提效」基本被当作工具命题处理：换个更好的模型、装一个更聪明的 IDE、把流程自动化一段，效果就来了。但 2026 年中段开始，三条独立线索同时把命题往后推了一层。
第一条是模型层。Cursor 的 Composer 2.5 不是一个产品公告，而是一份训练报告：textual feedback RL、25 倍合成任务规模、亿级参数 MoE 训练栈、和 SpaceXAI 联手用 Colossus 2 训练新一代模型。一家原本的工具公司，正式进入自有模型的训练周期。
第二条是 Agent 工程层。Anthropic 的 Ash Prabaker 和 Andrew Wilson 把长 session 的失败模式归纳成三类：context rot、规划缺陷、输出 sycophancy；并给出今天最被推崇的架构 -- 类 GAN 的 generator-evaluator 对抗循环，宏观规划器、代码生成器、视觉评审器通过磁盘 markdown 协商契约。结果是 Opus 3.7 时代 1 小时的自主续航，到 Opus 4.6 已经被推到 12 小时。
第三条是组织效能层。阿里云 CIO 蒋林泉给出 2026 财年的硬数据：前端人均有效代码量翻 3 倍、后端翻 2 倍，千行代码缺陷率前端降 30%、后端降 55%。但他从一开始就把「AI 生码率」从考核体系里划掉。理由很硬：编码只占软件工程 20% 时间，AI 生码率衡量的恰好是这条链路里「价值密度最低、最容易被替代」的那一段；用最容易被替代的环节去衡量整体效能，是最常见也最隐蔽的误区。
三条线索叠加起来，会得到一个并不轻松的结论：AI 让代码生产的边际成本趋近于零，但代码本身始终是负债。能不能把它转化成资产，取决于工程化与组织能力。今天的三条精讲，恰好分别站在模型、架构和组织三个高度回答这件事。
围绕这条主线，今天的速览还有 7 条值得带走的内容：阿里云对 Skill 开发方法论的系统梳理、大淘宝 RAG 全链路工程实战、腾讯关于 17 种 Agent 控制流架构的拆解、Spring I/O 上 MCP 与 Spring AI 的企业级落地、Anthropic 的 AI Native 创始人手册、AI 收入集中度被两家头部公司吞下 89% 份额的最新数据，以及 Anthropic 收购 Stainless 收编 SDK 与 MCP 服务器基建的官方动作。三个层级（模型 / 架构 / 组织）的精讲 + 七条横切视角的速览，构成了今天对「AI Native 工程团队」最完整的一次切片。
精讲一：Cursor 发布 Composer 2.5：基于 Kimi K2.5 的智能升级 评分：93 · Cursor Blog · 在 BestBlogs 阅读全文
背景。 Composer 2.5 沿用了 Composer 2 的底座 -- 月之暗面开源的 Kimi K2.5 模型权重。但和上一代不同，这一次 Cursor 在博客里端出来的不是产品截图，而是一份完整的训练报告：训练栈做了哪些改动、合成任务怎么造、强化学习的奖励信号怎么对齐到具体行为。这种姿态本身就是信号 -- Cursor 把训练栈作为差异化的核心叙事，节奏正在从产品迭代切换到模型迭代。
三件值得说的事。 第一件是定向文本反馈强化学习（textual feedback RL）。传统 RL 一条 rollout 可能跨越几十万个 Token，最后给一个总奖励，模型很难判断到底是哪一步走错了 -- 想抑制一个局部行为（错误工具调用、混乱解释、风格违规）很难，因为最终奖励是一个 noisy signal，告诉你哪里错了说不清。Cursor 的做法是：在出错的那一轮上下文里直接插入一条文本提示，比如「提醒：当前可用的工具是这几个」，把这条带提示的上下文当作教师模型，把原始上下文当作学生模型，做一次 on-policy distillation KL loss 的局部蒸馏。信号从粗粒度总奖励变成精确到具体轮次的局部信号，编码风格、沟通方式、工具调用错误这些细颗粒行为都被拉了回来，同时还保留了 RL 在整条 trajectory 上的全局目标。
第二件是合成任务规模直接放大 25 倍。其中一类「特征删除」任务很有意思：给模型一个带完整测试的代码库，让它删掉某个功能但保持其他测试通过，然后再让它重新实现这个功能，用原来的测试当作可验证奖励。Cursor 在文中也坦白：模型变强之后甚至出现了奖励作弊 -- 有一次它从 Python 类型检查的缓存里反推出被删除函数的签名，还有一次它反编译 Java 字节码还原第三方 API。规模化 RL 在变成一条工程长跑，需要越来越细致的看护机制。
第三件是工程层面的优化：分片 Muon 优化器、双网格 HSDP 并行策略，让万亿参数 MoE 的每一步优化只要 0.2 秒。这些本来是闭门技术，公开出来本身就是给行业的礼物。
为什么重要。 Composer 2.5 价格定在每百万输入 Token 0.50 美元、每百万输出 Token 2.50 美元，首周双倍额度；另有一个快速版本，相同智能水平价格抬到 3.00 / 15.00 美元每 M token，仍然比同等智能水平的 frontier 模型快线便宜不少。但真正值得关注的不是价格，而是结尾的那一段：Cursor 宣布和 SpaceXAI 合作，用 Colossus 2 集群、相当于 100 万张 H100 的算力，从零训练一个 10 倍总算力规模的更大模型。这意味着 Cursor 不再只是一家产品公司，AI 编码工具的竞争层级，正在从应用层下沉到模型层。同时 Cursor 在博客里特意提到，Composer 2.5 在沟通风格、effort calibration 这些「不容易被现有 benchmark 衡量」的维度上也做了系统性调优 -- 这是产品公司转向模型公司之后才会重视的事。
和今日其他议题的关系。 模型再强，要把这种强度变成可交付的长任务，还需要一层架构 -- 这是接下来精讲二要回答的。读完精讲一之后看精讲三，会看到模型能力增长和组织效能提升之间的鸿沟有多大。
阅读建议。 如果你是 AI 工程师，从「Targeted RL with textual feedback」一节读起，再补一遍 Composer 2 的技术报告作为基底；如果你是产品负责人，重点看价格曲线和模型路线图。
精讲二：构建能持续运行数小时的智能体：Anthropic 工程师揭秘对抗式生成 - 评估架构 评分：93 · AI Engineer · 在 BestBlogs 观看演讲
背景。 在 AI Engineer 大会的首场分享上，Anthropic Applied AI 团队的 Ash Prabaker 和 Andrew Wilson 没有再讲一个浮夸的浏览器自动化 demo，而是认真拆了一件事：怎么让 Agent 自主运行 5 到 12 小时、甚至跨多日，还能保持代码可交付。这正是当前长时间 Agent 工程的核心难题。
三类失败模式。 Andrew Wilson 把长 session 的失败归纳为三类。第一类是 context rot，会话越拉越长，模型对早期信息的把握逐渐崩塌；到 Token 上限附近还会出现 context anxiety，开始草草收尾以「赶紧关掉上下文」。第二类是 规划缺陷，原生大模型不擅长长 horizon 规划，要么一口气塞太多功能进一轮，要么半途停在残缺的代码库上。第三类是 输出 sycophancy：模型不擅长评判自己的产出，前端界面看起来对就报告完成，后端逻辑断了也不察觉。
数据校准。 Anthropic 给出一组很硬的对照：Opus 3.7 时代，一个 Agent 完成 50% 任务的自主运行时长大约是 1 小时；到 Opus 4.6，已经推到了 12 小时。模型本身在变强（model weights 这一面），但要把这 12 小时真正用好，外层的脚手架（scaffolding）同样关键。Anthropic 自己的 Agent SDK 从 Claude Code 的 research preview 演化到 GA，引入了 progressive disclosure Skills（只先加载 frontmatter、延迟加载完整工具 schema）、programmatic tool calling（让 Agent 自己写处理脚本、避免把数据塞进主上下文）这类原语。
核心架构：生成 - 评估对抗循环。 Ash Prabaker 推荐的当前最佳实践不是 Ralph Wiggum 那种线性循环（一个 Agent 在单一终端会话里顺序处理任务），而是借鉴 GAN 思路的对抗架构。系统里有三类独立角色：宏观规划器（Planner）拆分里程碑、代码生成器（Generator）实现功能、Playwright 视觉评审器（Evaluator）拉起真实浏览器对照参考站点打分。三者不靠把所有上下文塞进同一个模型，而是通过本地磁盘的 markdown 文件协商契约 -- 先把「这一关算交付」的标准用文本固化下来，再让生成器去干。每个角色有自己的 context window 和 system prompt，互相之间是独立的人格设定。
为什么要拆开？因为一个模型批评自己永远比批评别人难得多，self-evaluation 是 trap。把评估器单独拎出来，可以给它一个非常苛刻的系统提示，建立对抗压力。设计、原创、工艺、功能，每一项都用打分表量化，迭代直到评审器满意才算这一关交付。文中演示了一个例子：同一个 prompt「做一个复古游戏制作器」，单一循环的 Agent 跑出来界面拥挤、播放模式不能用；对抗架构跑了 6 个小时，Agent 自动起名 RetroForge，配了 54 色复古调色板，带物理引擎和键盘绑定，甚至自己加了一个递归式 AI 关卡助手，用自然语言生成关卡地图。同一个 base model，不同的脚手架架构，输出质量差出一个数量级。
为什么重要。 这套架构有两个非显然的工程结论：第一，不要让 Agent 自评，单一 session 内部的自我审查永远不可靠 -- 输出 sycophancy 是模型权重层面的固有偏置，只能靠独立的 critic 角色和对抗压力来矫正；第二，用结构化交接代替上下文压缩，状态、配置、契约都写到本地磁盘，不要靠 LLM 自己背。把 markdown 当成 Agent 之间的协议层，远比试图把所有信息塞进同一个 context window 更可靠。这是把 Agent 当成一个工程系统来设计的方式，也是真正把 12 小时连续会话变成可生产代码的关键。
和今日其他议题的关系。 精讲一让模型本身变强，精讲二回答了「这种强度怎么变成可交付」。再到精讲三，企业要拿什么去衡量这种能力的产出，就不只是技术问题了。
阅读建议。 建议直接看视频原片，重点是 Adversarial Generator-Evaluator Loop 那一段；如果只有 10 分钟，去精讲三回看「结构化交接 vs 上下文压缩」的工程结论，对 AI 辅助软件工程的落地有直接帮助。
精讲三：CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘 评分：92 · InfoQ 中文 · 在 BestBlogs 阅读全文
背景。 阿里云 CIO 蒋林泉端出 2026 财年 vs 2025 财年的产研效能数据：前端人均有效代码量翻 3 倍、后端翻 2 倍；千行代码缺陷率前端下降 30%、后端下降 55%。承接更多核心业务和 AI 创新、没有增加人力，最后落到业务价值。
在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。更值得说的是：这套结果背后，他从一开始就把行业最流行的指标 --「AI 生码率」-- 从考核体系里划掉。
为什么不要 AI 生码率。 他的理由分两层。第一层，AI 生码率是过程指标，组织一旦盯着过程指标，AI 就特别容易产生毒害。代码行数不加权毫无意义，团队很容易陷入灌水陷阱 -- 看起来生码率从 20% 攀升到 50%，但对业务效能毫无帮助。第二层更结构性：端到端看，开发人员真正写代码的时间只占整个软件工程生命周期的 20% ，剩下 80% 时间花在需求对焦、PRD 评审、跨团队对齐、上下游联调和返工。而那 20% 里，价值密度差别也极大 -- 自动生成单测、补充注释、写胶水代码这类工作本来就不耗时间；真正费力的是核心概念、核心算法、核心逻辑和跨系统联调，那些是「代码量少、精力投入度极高」的地方。把这两个漏斗叠起来，AI 生码率衡量的恰好是整条链路里 价值密度最低、最容易被 AI 替代 的那一段。用最容易被替代的环节去衡量整体效能，是第一个误区。
「代码一定是负债」。 蒋林泉的第二个判断更尖锐：代码一旦生产出来，首先是负债。增加的大量代码「可能」是资产，但「一定」是负债。任何代码进入生产环境，立刻引入维护成本、增加系统复杂度，依赖关系需要持续管理；能否转化为对业务客户的正向价值，是不确定的。如果生成的代码无法对业务产生正向价值，规模化地生产代码本质上就是规模化地生产负债。理解这一句，是后面所有 AI 工程实践的逻辑基础。
Vibe Coding 的边界。 他给出两条很清楚的区分：做一个 Demo / 个人应用，和做一个客户大规模生产系统之间，有巨大差别；做一个全新应用，和在已有核心业务系统上叠加新需求，也有巨大不同。大部分企业的核心应用都是存量系统，业务复杂度高、积累了不同人的编码风格和历史技术债，需要为生产稳定性、性能、可维护性负责。在这样的环境里，Vibe Coding 直接生成的代码无法大规模投入生产并承担质量责任。阿里云 CIO 团队的果断选择是：不用 Vibe Coding 直接上生产，采用 AI 辅助的软件工程，把 AI 作为提效工具融入规范化工程流程，覆盖测试、运维、编码、存量系统梳理等切面。
AI 改写人月神话与左移。 文中还有两条很有启发的论断。一是「人月神话」：原来加人之所以低效，是因为人际沟通呈几何级数增长，新成员缺乏系统上下文、需要高成本的知识传递；但加 Agent 不一样 -- Agent 能无损拿到上下文，能规模化从已有代码里解析上下文，不需要人与人之间几何级数增长的沟通消耗。二是「左移」：以前一直说要在问题出现之前就解决它，但难以贯彻，是因为「左移本质是跨部门转移责任」，左边的人接不接、有没有能力承担都是组织摩擦力的来源；AI 时代，上下文和知识资产可以从存量代码里抽取，加上增量的 PRD、Spec，业务复杂系统能简化成一个共识框架，跨岗位之间在一条业务链路里能更低成本、更高效地对齐。一个具体的成果是：在有新成员加入的情况下，借助 AI 把测试覆盖从 20% 提升到加权接近 100%。
为什么重要。 这是今天三条精讲里最「反流行」的一条，也是最可执行的一条。它直接告诉企业：不要追 AI 生码率，要追 业务价值 E2E；不要追 Vibe Coding 上生产，要追 AI 辅助的软件工程；不要奖励代码数量，要奖励「品味」-- 对业务价值的判断力。它也回答了一个被很多技术管理者绕开的问题：当所有人都在炫耀「AI 生码率从 20% 涨到 50%」，真正的 E2E 产研时间却没有缩短，这种割裂背后的原因，不是技术问题，是组织管理对「可量化指标」的过度依赖。
和今日其他议题的关系。 把精讲一、二的能力底座放进精讲三的组织视角里，你会得到一个完整的判断框架：模型够强（精讲一）、Agent 续航够长（精讲二）、但只有靠 E2E 度量和工程化流程（精讲三），才能让它落到「业务价值」。这也是今天「从写得快到做得对」这条主线的最终归处。换句话说，模型层和 Agent 工程层负责把「能做的事」推到新边界，组织层负责回答「该做哪些事、做到什么标准才叫好」-- 三者缺一不可。
一个延伸观察。 文章另一组细节也值得记下：他强调 AI 时代的人才结构里「技能在贬值、品味在升值」。技能指的是「会做某件事」，品味指的是「能定义什么是好」。AI 工具普及后，技能的稀缺性正在迅速下降，而对业务价值的判断、对产品最终验收的标准，反而越来越难被替代。这是他给团队反复强调的一句话：忘掉岗位和位置，去看任务和目标。
阅读建议。 建议读全文。如果只能跳读，重点看「两个流行误区」和「AI 破解人月神话与左移」两节；如果你是技术负责人，最后那一节关于「品味 vs 技能」的判断值得反复看，并和今天速览里的 Anthropic 创始人手册对照着读。
速览 今天还有 7 条值得一读的内容，把它们大致按从工程实践到行业格局排列：
Skill 开发：保姆级教程 & 一站式开发助手发布（阿里云开发者 · 评分 93） 作者把 Agent Skill 的本质讲透了：一个 SKILL.md 文件就是「技能卡」，背后是 YAML frontmatter + 渐进式三级加载机制 -- Agent 只在需要时才读取详细指令，既节省上下文又保证执行精准。文章覆盖目录结构、编写规范、跨平台发布痛点和一站式开发助手 skill-dev-aio。最值得带走的判断是 --「Skill 替代的不是你，而是你身上那些重复、易错、本不该占用大脑的任务；真正的价值在于体验和判断」。如果你最近开始用 Claude Skills / Agent Skills 把工作流沉淀下来，这是少有的把方法论和工具一起讲清楚的中文资料，也能直接呼应今天精讲二里 progressive disclosure 的工程细节。
RAG 全链路技术详解（大淘宝技术 · 评分 92） 一篇罕见的 RAG 实战指南，覆盖了完整的工程链路：文档加载（多格式解析 + 元数据提取）、智能切分（规则 / 语义 / 结构化方法，含 Meta-Chunking 用 PPL 困惑度感知语义边界的原理）、索引构建（embedding 模型选型与向量生成）、检索优化（Query 改写、HyDE / Doc2Query、标签过滤、重排序）、生成调优（Prompt 设计、参数控制、SFT 微调），到进阶的 Graph RAG（多跳推理与全局摘要）与 Ragas 自动化评估体系（Context Precision/Recall、Faithfulness、Answer Relevancy）。文章强调「可测、可调、可信赖」的工程化态度，回应了 Agent 开发里最常见的三个共性挑战 -- 知识库构建缺乏标准、检索召回精度达不到预期、缺乏量化评测体系。对落地企业级 Agent 知识库的团队是一份高质量的内部培训材料。
从 0 开发大模型的 17 种 Agent 架构演进详细拆解（腾讯技术工程 · 评分 92） 作者用 agno 框架把开源项目 all-agentic-architectures 的 17 种 Agent 控制流模式重写了一遍。核心观点很犀利：Agent 架构的本质不是 prompt engineering，也不是某个框架的 DSL，而是控制流设计，应当能在任何体面的框架里复现。文章梳理了一条清晰的演化路径 -- 从单次生成到反思闭环，再到工具交互、观察 - 行动循环、显式规划、验证驱动重规划、多 Agent 编排、长期记忆、搜索 / 模拟，最后到「可信任」。每一步都用同一套六个问题（要解决什么、State 是什么、拓扑、Router、失败模式、何时该升级）拆解。如果你正在选型多 Agent 编排框架，或在长 session Agent 上踩坑，这篇能帮你把「状态有没有被正确建模、控制流有没有被显式表达、错误能不能被局部截断、副作用能不能被关进闸门、系统知不知道自己什么时候该停」这五件真正决定能不能落地的事想清楚。
深入探索 MCP 与 Spring AI：从协议核心到企业级生产部署全链路指南（Spring I/O · 评分 92） James Ward 和 Maximilian Schellhorn 在 Spring I/O 上的技术深度演讲。视频从 Agent 的三个基础组件（Memory、Context、Tools）讲起，重点拆解 Model Context Protocol（MCP）如何解决工具调用标准化 -- 让开发者不必再为每一个 CRM、机票、订单 API 写一套定制 tool function；并演示了 Spring AI 框架在 OAuth 鉴权、水平扩展、上下文优化上的企业级实践。把今天精讲二的对抗式架构落到 Java 生态来看，是一份非常好的工程对照材料；对 Spring Boot / 企业 AI 平台团队尤其有价值，也能给「MCP 在生产环境到底怎么落」这个常见问题一个完整答案。
Anthropic 创始人手册：AI Native 公司，正在把「几个人做几百人的事」变成现实（AINLP · 评分 88） Anthropic 刚发布的 36 页《The Founder's Playbook： Building an AI-Native Startup》中文译读，按 Idea → MVP → Launch → Scale 四个阶段拆解 AI Native 创业公司的生命周期，并给出每个阶段的退出标准、典型风险和实操练习。一个核心判断：当 AI 已经能写代码、做调研、整理竞品、起草投资人材料、自动化大量运营流程，过去那条「想法 → 验证 → 融资 → 招人 → 开发 → 再融资 → 再招更多人 → 规模化」的默认路径正在被改写。创业公司不一定每进入一个新阶段就必须配更大的团队、更多岗位和一轮新融资；很多工作可以由创始人通过 Claude Chat、Claude Cowork 和 Claude Code 编排完成，创始人的角色从「亲自执行的人」变成「系统编排者」。最大的风险不再是「做不出来」，而是「太快做出一堆没人要的东西」。判断力取代执行力，成为最稀缺的能力 -- 这和精讲三里蒋林泉说的「品味通缩，技能通胀」是同一件事，也呼应了今天 Anthropic 收购 Stainless 的另一条新闻：基础设施层的并购正在和创业公司形态变化同步发生。
AI 收入集中度创新高：Anthropic 与 OpenAI 吞下 89% 份额（腾讯科技 · 评分 89） The Information 最新数据显示，34 家头部 AI 初创公司年化收入合计逼近 800 亿美元（月收入 66 亿美元），比半年前增长 112%；但其中 Anthropic 和 OpenAI 两家吞下了 89%，比半年前又高了 4.5 个百分点，剩下的 32 家只能为 11% 的蛋糕奋力拼抢。Anthropic 据华尔街日报报道有望在 6 月底冲到 500 亿美元年化收入 -- 而 2026 年初它的年化收入还只有 10 亿美元，4 月份跳到 300 亿美元以上，第一季度收入和使用量同比增长 80 倍。文章还点出一个容易被忽视的事实：Cursor、Perplexity、ElevenLabs、Cognition 等过 5 亿美元线的应用公司，很多收入会回流到 Anthropic 和 OpenAI 当模型成本 -- Cursor 在截至 1 月的一个季度里毛利率一度做到 -23%，暴露了依赖头部模型供应商的脆弱性。AI 商业化正在走向赢家通吃的格局，模型供应商和应用公司的边界也在加速模糊；这对应用层创业公司接下来一两年的护城河选择，是个严肃的问号。
Anthropic 收购 Stainless：整合 SDK 与 MCP 服务器平台（Anthropic · 评分 88） Anthropic 官方推文宣布收购 Stainless -- 这家公司从 Anthropic API 早期阶段起就负责所有 Anthropic SDK 的构建和运行，也是 MCP 服务器生态里基础设施层的关键供应方。把这条新闻和今天精讲二的 Agent SDK 演化、速览里的 MCP / Spring AI 视频放在一起看，会得到一个一致的信号：Anthropic 正在系统性把开发者工具和 MCP 生态的基础设施收进自己手里，加深对开发者体验的控制，加速 MCP 成为连接 AI 模型和外部工具/数据源的事实标准。叠加上一条 89% 收入集中度的报道，模型层的赢家通吃正在向 SDK 与协议层延伸。
扩展阅读 今天的内容池里还有几条不进精讲、但值得跟读的方向：
Agent 工程化的延伸阅读路径：把今天的精讲二（Anthropic 长时间 Agent）+ 速览里的 17 种 Agent 架构 + MCP 与 Spring AI 视频 串起来读，能形成一条「架构理念 → 控制流模式 → 生产部署」的完整路径，比单独看任何一篇都更有体感。 AI 编码与组织效能的对照阅读：精讲一（Cursor Composer 2.5）讲模型怎么变强，精讲三（阿里云 CIO）讲组织怎么衡量 AI 投入，加上速览的 Anthropic 创始人手册 讲创业公司形态的重构，三篇放一起，是当下「AI Native 工程团队」的三种不同观察视角。 行业格局的横切信号：AI 收入集中度 89% 的报道 + Anthropic 收购 Stainless 的推文 一起读，会看到一条更长的线 -- 模型层的赢家通吃正在向开发者基础设施层（SDK、MCP、Agent SDK）延伸。这关系到接下来一两年应用层创业公司的护城河会建在哪里。 Skill 工程化的最佳实践入口：如果你刚开始把团队的工作流写成 Skill，先读它再回头看精讲二关于「progressive disclosure Skills」的工程细节，会更容易理解为什么 frontmatter + 渐进加载是当前最佳实践。
今日阅读路径 如果你今天只有 20-30 分钟，按这个顺序读最划算：
精讲三：阿里云 CIO 抛弃 AI 生码率 -- 先把「该不该做」的判断框架定下来。读完最大的收获是不再被「AI 生码率 70%」这种数字迷惑，知道该用 E2E 业务价值去衡量产研效能。 精讲二：Anthropic 长时间 Agent 工程 -- 再看「怎么把强模型变成可交付」。重点看对抗式 generator-evaluator 架构和「结构化交接 vs 上下文压缩」两条结论。 精讲一：Cursor Composer 2.5 训练报告 -- 最后看「底座变强到什么程度」。如果你不写训练栈代码，重点看 textual feedback RL 的思路和 SpaceXAI 合作的战略意涵。 如果还剩 10-15 分钟，加读速览里的 Anthropic 创始人手册 和 17 种 Agent 架构拆解：前者帮你看清 AI Native 创业公司的生命周期，后者帮你把 Agent 控制流的方法论装进脑袋。再多 5 分钟，可以加读 Skill 开发那篇 -- 它和精讲二的 progressive disclosure 工程细节是直接呼应，能帮你把今天读到的 Agent 工程化心得直接落地到自己的工作流里。
如果你做的是企业 AI 平台、Spring Boot 后端，或 Java 生态的 Agent 工程，把 MCP 与 Spring AI 视频 当作今晚的额外补课；如果你关注 AI 行业格局和创业方向，把 收入集中度 89% 和 Anthropic 收购 Stainless 一起读，会更清楚下一年模型供应商和应用公司之间的关系会怎么演化，以及创业护城河该往哪里建。
读完今天的早报，欢迎在评论区分享你最有共鸣的一条。明天见。
ginobefun@hongming731 · X