AI News｜2026-09-18

今日目录

• Claude 把 Cowork 和 chat 合并，Boris 解释为什么是模型来路由
• Cat Wu 讲合并后的 Claude 如何决定回答还是动手
• Thariq：别再拿文件系统骗模型，工具该按真实语义给
• 把老项目迁到 Claude Managed Agents 的实测反馈
• Nikunj 的家庭 Home agent：控制粒度才是能跑起来的原因
• Rauch：f x 默认自动模式的 safety reviewer 让 p95 快 18 倍
• Peter Yang 用 8 个 skill 跑完整档播客流程
• Levie：便宜快速高能力的模型会卡在企业工作流的判断节点上
• Cowork 迁移不丢上下文：chats、projects、artifacts 原地保留

今日判断

今天最值得看的一件事是 Claude 把 Cowork 和 chat 合并成一个入口，同时把 Docs、Slides、Design 直接塞进对话里。Boris 说的方向我认同：不是让用户选产品，而是让模型自己路由——简单问题快答，复杂任务走 agentic 链路。这个改动对做产品的人真正的信号是：多产品线靠 tab 切换的时代在被模型能力吃掉，产品边界开始由模型的路由能力决定，而不是由导航栏决定。我自己更在意的是他们承认在慢速灰度，说明这个路由逻辑还不够稳，前期别急着照抄。

第二条线是 agent 的工具设计。Thariq 说 bash 不再是唯一答案，数据库就该给数据库的 API，而不是拿文件系统绕一层；沙箱 + bash 仍然适合要生成并执行代码的活。这跟我最近看到的实践一致：工具形状越贴近真实语义，模型越少乱猜。Nikunj 那个 Home agent 也是同一类证据，能在只读某些邮件、把附件转结构化数据这种粒度上做控制，才让一个家庭级 agent 真跑起来。

第三个我盯的是 Rauch 的 f x safety reviewer，跑在 GPT Luna 上，p95 快了 18 倍还更准，默认自动模式要进 Vercel AI Gateway。这说明安全审查不必是拖慢主流程的旁路，它可以变成默认路径的一部分。我的判断是：接下来做 agent 产品的团队，与其纠结用哪个模型，不如先想清楚哪些环节该默认自动、哪些必须人工兜底，这个默认值才是产品差异。

快讯

1. Claude 把 Cowork 和 chat 合并，Boris 解释为什么是模型来路由

查看原文 · 来源：Boris Cherny (@bcherny)

Boris Cherny 说 Claude Code 证明了 AI 能做真实工作而不是只回答问题，Cowork 证明了知识工作者也能这样交付文件，今天两者开始合并成一个 Claude。他的核心说法是：一个 Claude 跨所有工作内容携带上下文，用户不用再选产品，模型根据 prompt 决定快答还是做更深的 agentic 工作。这对一线 builder 的意义是产品边界在被路由能力重写：过去靠多产品线加 tab 切换覆盖场景，现在一个入口加模型判断就可能覆盖。我的判断是这个方向对，但慢速灰度说明路由还不够稳，短期别急着把自家产品也压成单入口。

2. Cat Wu 讲合并后的 Claude 如何决定回答还是动手

查看原文 · 来源：Cat Wu (@_catwu)

Cat Wu 说用户反馈不想选哪个 Claude 产品来做任务，模型变强后可以自己路由：根据 prompt 决定快答还是深度 agentic 工作，以及输出什么形式。她强调用户全程可控，能停、能改方向、能对投入程度做更细控制。同时 Claude Design 被并进来，做一个 Slide、Design 或 Doc 不用切 tab。对 builder 来说关键信息是路由权交给模型后，可控性变成了产品设计问题，而不是简单开关。我的判断是这类混合入口会倒逼很多 SaaS 重估自己的导航结构，但前提是你的路由误判成本足够低。

3. Thariq：别再拿文件系统骗模型，工具该按真实语义给

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

Thariq 说他现在倾向直接给 Claude 想要的工具形状，而不是套一层间接抽象。例子很具体：要存数据，你到底该给文件系统，还是直接给一个数据库 API。他说这是自己相对去年的更新。这条对做 agent 工具层的人有用，因为工具形状越贴近真实语义，模型越少靠猜去绕路，链路也更容易调试。我的判断是这跟沙箱加 bash 仍然是两件事，代码生成和执行场景还是需要沙箱，但纯可靠工具调用没必要硬塞进 bash。

4. 把老项目迁到 Claude Managed Agents 的实测反馈

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

Thariq 说 Claude Managed Agents 的平衡点找得不错：沙箱是可选的，可以独立于 agent loop 启动。他最近把一个基于 bash tool calling 的老项目迁到 CMA，跑得挺好。这条的价值在于它验证了沙箱和 agent 主循环解耦这个设计，对正在搭 agent 运行时的人是一个具体参照：不是所有 agent 都需要沙箱常驻，需要的时候再单独拉起。我的判断是这种可插拔沙箱会成为 agent infra 的默认形态，但迁 mobile 时要注意工具描述和权限边界要重新写一遍。

5. Nikunj 的家庭 Home agent：控制粒度才是能跑起来的原因

查看原文 · 来源：Nikunj Kothari (@nikunj)

Nikunj 说自己用 NousResearch 的 agent 做了几个月的家庭 Home bot，现在和妻子日常都会用，这是他们第一个群组 bot，失败的场景也带来有趣的观察。他提到关键差异是控制粒度：只读某些邮件、把内联附件转成结构化数据、使用已登录的浏览器会话，用 Grok Bot 之类的复刻不出这个程度。这条对做 agent 产品的人的意义在于，真实工作流要的不是能力上限，而是可配置的边界。我的判断是家庭和个人 agent 的竞争点会集中在这些细粒度约束上，而不是模型多聪明。

6. Rauch：f x 默认自动模式的 safety reviewer 让 p95 快 18 倍

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

Rauch 说 f x 的默认模式现在是自动，每条命令都过一个 safety reviewer，reviewer 跑在 GPT Luna 上。结果是 Jev p95 快了 18 倍而且更准，接下来会进 Vercel AI Gateway 并很可能成为新默认。这条对做 agent 产品的启示是安全审查不必是拖慢主流程的旁路，它可以被设计成默认路径的一部分，前提是审查模型本身够快够准。我的判断是默认自动会变成基础设施的竞争点：你给用户设的默认阈值，会直接决定他们觉得你的 agent 是快还是怂。

7. Peter Yang 用 8 个 skill 跑完整档播客流程

查看原文 · 来源：Peter Yang (@petergyang)

Peter Yang 说他用 8 个 AI skill 完成整个播客制作，同时保留自己的品味和判断：podcast-prep 做嘉宾研究并生成访谈提纲，podcast-edit 审原始转写并和他一起挑引言和要剪的片段，podcast-production 编排 5 个 skill 把完整一集变成 6 个不同资产。他特别回应了一种观点：模型再强也没让 skill 变多余，因为要把自己的剪辑和浏览器使用指令稳定执行，skill 仍不可替代。我的判断是 skill 的价值不在知识，而在于把个人工作流固化成可重复触发的步骤。

8. Levie：便宜快速高能力的模型会卡在企业工作流的判断节点上

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

Levie 说还有大量 AI 创新方向不在多数人雷达上，快速低成本处理信息对很多企业任务是大事：数据分类、工作流内路由决策、给一个领域问题做判断、安全和安保的快速判断，这些都是大量流程的闸口。他认为这类模型和方法在企业的 agentic workflow 里会很有用。这条对做企业 agent 的人有用的点在于它指出了插入位置：别一上来做全流程自动化，先去替那些高频、低风险、又要判断力的关卡节点。我的判断是这类场景的评估成本比生成场景低，更容易先跑通 ROI。

9. Cowork 迁移不丢上下文：chats、projects、artifacts 原地保留

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

Claude 官方说在 Cowork 里工作过的内容都还在原位：chats、projects、artifacts、connectors 和 skills，可以接着用。Claude Design、Claude Slides、Claude Docs 在所有付费计划上处于 beta。这条没有太多技术细节，但迁移策略本身是信息：合并产品最难的是上下文和历史资产搬迁，他们选择了原地保留而不是新建空间。我的判断是这是对的做法，对正在做产品合并的团队来说，资产迁移连续性比新功能更能决定用户是否留下来。