AI News｜2026-09-17 — Charles Cheng

今日目录

Levie：模型能力和企业 workflow 之间存在一道大缝，这层应用机会填不完
Garry Tan 实测 Capy + GStack：同样前沿模型，fix wave 时间砍半
Thariq：MCP 现在比 CLI 更适合大多数集成
Dan Shipper：我们几乎不测新基座模型，但这个跑了整周测试
Salesforce 进 Claude：37 个预制销售 skill 的对话内 CRM
Rauch：未来是多模型的，把选择藏起来反而伤害客户
Amjad 反问：输出域已知，为什么不直接训 enum logprobs 模型
Gemini Notebook 加学生功能：课堂材料语音问答和录音笔记
Vercel Labs 亮相：把公开实验和失败的尝试一起放出来

今日判断

今天最值得记的其实是两件互相印证的事。一件是 Aaron Levie 说的那个 gap：模型能力和企业真正要自动化的 workflow 之间还隔着巨大一道缝，填缝的工作包括重做流程、聚合上下文、设计 human in the loop、做领域 eval、管数据权限，而且模型越强这层越重要，不是越弱。另一件是 Garry Tan 用 Capy 在真实 fix wave 上跑了一遍，同样的 frontier model，时间砍到大概一半。这两件事拼起来就是我这段时间的体感：决定成败的已经不是模型本身，是你怎么把模型接到任务上，用什么外壳、什么循环、什么上下文组织方式。

另一个让我停下来想的是 Thariq 那句 MCP 现在比 CLI 更适合大多数集成，理由是模型 tool calling 变强了、MCP 变成无状态了。这跟 Dan Shipper 测的那个新模型是一回事的两面——输出不再是文字而是概率，可以当便宜的 judge，还快很多。当模型把结构化调用和打分这两件事做稳，工具层的设计空间就整个变了，原来需要写一堆胶水逻辑的地方，现在交给模型判断反而更省。Amjad 那句反问也值一提：如果输出域事先已知，为什么还要用自由生成，直接训一个在 enum 上出 logprobs 的模型不就行了。这是很 builder 的一句吐槽。

我看下来今天的判断是：基础设施的竞争重心正在从模型能力转到 workflow 组织能力和工具协议设计上。对一线 builder 来说，现在值得花时间的不是等下一个更强的模型，而是把自己的任务拆清楚、把上下文聚合和 eval 做扎实、把工具接口按无状态 MCP 的思路重新设计一遍。模型每强一代，只会让这件事的收益更大，不会让它变得不重要。

快讯

1. Levie：模型能力和企业 workflow 之间存在一道大缝，这层应用机会填不完

查看原文 · 来源：Aaron Levie (@levie)

Levie 说模型能力和企业最终想自动化的 workflow 之间有一道巨大的鸿沟，这层由 applied AI 来填。填缝的具体活儿包括：把智能接到流程上、经常要重做流程、聚合正确的上下文和数据、设计 human in the loop、做 change management、跑领域特定 eval、管数据和流程的安全合规。他的关键判断是，就算模型以惊人速度变强，这层不但不会消失，反而可能更重要——更强的能力意味着更复杂的任务被啃，如果你这层没做好，问题会被放大。我看下来这是今天最该转给做企业 AI 的人的一句话：模型不是你的护城河，把它接进真实流程的那套工程才是。

2. Garry Tan 实测 Capy + GStack：同样前沿模型，fix wave 时间砍半

查看原文 · 来源：Garry Tan (@garrytan)

Garry Tan 说他开始用 capydotai 配合 GStack/GBrain 处理积压的 issue 和 PR，同样的前沿模型，原来用裸 Codex 或 Claude Code 要干一天的量，现在大约半天完成。他用的词是 amazed。这件事重要的地方在于，模型没变，改变的是任务组织方式、上下文注入和循环结构，性能提升来自外壳而不是权重。我的判断是，这印证了 Levie 那条 gap 里的逻辑——coding tool 的差异化正在从模型走向工作流设计，谁把 issue 到 PR 这条链路组织得更顺，谁就拿到这半天。做 coding agent 的人应该去拆解 Capy 这类工具在上下文和循环上到底做了什么。

3. Thariq：MCP 现在比 CLI 更适合大多数集成

查看原文 · 来源：Thariq (@trq212)

Thariq 说他本来没料到，但现在认为对大多数集成而言 MCP 比 CLI 更好用。理由有三点：模型在 tool calling 上已经强了很多；工具可以延迟加载；MCP 现在是无状态的。他还给了个具体做法——如果你需要在数据上做组合或过滤，就在 MCP 工具上加 query 这类参数。这条对正在设计 agent 工具层的人很直接：CLI 曾经的优势是简单和可组合，但当模型能可靠调用结构化工具、且协议不再有状态负担时，MCP 的接入成本和可扩展性开始占优。我的判断是，工具层的默认选择正在从命令行切换到无状态协议，值得尽快在自己的项目上做一次对比测试。

4. Dan Shipper：我们几乎不测新基座模型，但这个跑了整周测试

查看原文 · 来源：Dan Shipper (@danshipper)

Dan Shipper 说他们几乎从不测试新的基座模型，但这个在 Every 内部测了大约一周，反馈是 wild。关键差异在于它不产出文字，而产出概率，因此在需要 Fable 级模型当 judge 的场景里可以顶上，而测试中速度约快 25 倍、价格约低 600 倍。这条重要是因为它展示了模型用法的一个转向：不是所有环节都需要生成文本，很多 agent 里的判断、路由、筛选环节只需要打分。这个价格和延迟差距足以改变 agent 架构——原来因为成本只能塞一次大模型调用的地方，现在可以频繁调用小模型做中间判断。做 agent 的人该重新算一遍自己流程里哪些环节其实只需要概率输出。

5. Salesforce 进 Claude：37 个预制销售 skill 的对话内 CRM

查看原文 · 来源：Claude (@claudeai)

Claude 宣布 Salesforce in Claude 进入 beta，把账户、商机和 pipeline 数据带进对话，附带 37 个预制销售 skill。用法包括通话准备、审 deal、生成 pipeline 看板、发 forecast，全程不用离开对话。这件事的意义不在于又一个集成，而在于预制 skill 这个形态——它把领域工作流封装成模型可直接调用的单元，用户不需要自己 prompt，而是调用别人定义好的工作模式。对做垂直 agent 的人，这是值得盯的产品化路径：与其让用户从零搭，不如把最佳实践固化成可组合的技能包。我看下来，这会成为企业 AI 落地的一个标准打法。

6. Rauch：未来是多模型的，把选择藏起来反而伤害客户

查看原文 · 来源：Guillermo Rauch (@rauchg)

Rauch 表态说未来是多模型的，试图隐藏模型选择会让人困惑并伤害客户，因为用户既没法参与这场最激动人心的市场竞争带来的好处，也没法为具体任务选出最合适的工具。这条的背景是很多 AI 产品为了体验统一把底层模型藏起来，但他认为这是错的。我的判断是，这个立场对工具类产品尤其成立：开发者愿意看到并切换模型，因为不同任务的最优解确实不同，把选择权交出去反而建立信任。值得做 AI 产品的人重新想一遍，你到底是在帮用户省心，还是在替他们做他们本可以自己做的决定。

7. Amjad 反问：输出域已知，为什么不直接训 enum logprobs 模型

查看原文 · 来源：Amjad Masad (@amasad)

Amjad Masad 在一个演示下评论说，这很酷，但如果输出域事先就知道，为什么不直接训一个在 enum 上出 logprobs 的模型。这是一个很 builder 的提问，指向一个常被忽略的设计分叉：当任务输出是有限枚举时，用自由生成再加解析是浪费，直接出概率分布更稳更省。它和 Dan Shipper 测的那个概率输出模型是同一个方向的两面——把模型的输出空间约束到任务真正需要的形式。我看下来，这提醒做 agent 的人先问清楚每个环节的输出域到底是有界的还是开放的，有界的就别让模型写自然语言。

8. Gemini Notebook 加学生功能：课堂材料语音问答和录音笔记

查看原文 · 来源：Josh Woodward (@joshwoodward)

Josh Woodward 公布 Gemini Notebook 面向学生的更新，他个人最看重两点：一是能就课堂材料做实时语音问答，覆盖约 100 种语言；二是可以在路上录讲座和笔记，音频笔记自动存进指定的 notebook。另外学生身份在 140 多个国家可继续免费领 Google AI Plan，拿到更高额度和更多产品。这件事值得看的是语音问答加自动归档这两个动作——它们把学习场景里最费劲的整理环节自动化了。对做教育或知识管理产品的人，这是一个明确的信号：输入和归档的摩擦正在被吃干，差异化要往理解和输出上走。

9. Vercel Labs 亮相：把公开实验和失败的尝试一起放出来