Tweets

Since we launched Claude Code, we saw people using it for all sorts of non-coding work: doing vacation research, building slide decks, cleaning up your email, cancelling subscriptions, recovering wedding photos from a hard drive, monitoring plant growth, controlling your oven.

These use cases are diverse and surprising -- the reason  is that the underlying Claude Agent is the best agent, and Opus 4.5 is the best model.

Today, we're so excited to introduce Cowork, our first step towards making Claude Code work for all your non-coding work. The product is early and raw, similar to what Claude Code felt like when it first launched.

Cowork includes a number of novel UX and safety features that we think make the product really special: a built-in VM for isolation, out of the box support for browser automation, support for all your claude.ai data connectors, asking you for clarification when it's unsure,  We are excited to see how you all use it.

Cowork is available now as a research preview for Claude Max subscribers in the macOS app. Click on “Cowork” in the sidebar: claude.com/download

为什么AI需要"连续可微"？一个盲人下山的故事

训练AI就像盲人下山

你站在迷雾笼罩的山上，目标是找到最低的山谷。

但你什么都看不见，只能用脚感受地面的倾斜。

这就是训练神经网络的真实写照。

山的高度代表模型的错误程度（越低越好）。

你的位置代表模型的参数设置。

脚感受到的坡度就是梯度（数学上的导数）。

往下坡走就是梯度下降算法。

你的策略很简单：用脚感受倾斜方向，往下坡方向走一小步，不断重复，直到走到谷底。

有个专业名字：梯度下降（Gradient Descent）。

三种地形，三种命运

地形A：光滑山坡

地面平滑连续，你的脚能清晰感受到："这里向东南方向倾斜15度"。

你知道该往哪走，一步步稳稳地走到谷底。

这就是"连续可微"的函数，AI训练的理想环境。

地形B：悬崖断层

你往前试探一步，突然从平地掉下10米悬崖。

你的脚只能感受到"有地"或"没地"，无法判断倾斜方向。

这就是"不连续"的函数，无法训练，因为没有"方向指引"。

地形C：尖锐山脊

你站在刀刃般的山脊顶端，左右都是陡坡，但脊线本身没有倾斜度。

你的脚在尖角处无法判断该往左还是往右。

这就是"不可微"的函数，在关键点失去方向。

为什么AI必须"光滑"？

训练神经网络用的是反向传播（Backpropagation）算法，它的核心：

从结果倒推，如果输出错了，每个参数该调整多少？

这个"该调整多少"需要计算梯度（导数）。

如果遇到悬崖或尖角，梯度不存在或无意义，整个训练就卡住了。

这就是为什么AI不使用阶跃函数（像开关，非0即1，梯度几乎处处为0），也要小心使用绝对值函数（在0点有尖角，无法求导）。

而是选择Sigmoid函数（平滑S形曲线，处处可导）或ReLU函数（大部分区域线性，实践中有效）。

LLM的两难困境

人类思考是跳跃式的，像是在问"苹果是水果吗？"时，直接查询知识得出"是"或"否"。

这像是在断崖地形上跳跃，清晰明确，但无法训练。

LLM实际做的是把离散判断变成概率分布：计算"是"的概率95%，"否"的概率5%，然后输出"是"（但内部保留了不确定性）。

核心概念速查

梯度下降（Gradient Descent）：像盲人下山，靠感受坡度找最低点的优化算法。

梯度/导数（Gradient）：数学上表示"变化率"，直观理解就是"坡度"或"方向"。

连续（Continuous）：函数没有跳跃断层，像平滑的山坡而非悬崖。

可微（Differentiable）：函数在每个点都有明确的"倾斜方向"，没有尖角。

反向传播（Backpropagation）：从输出倒推回去，计算每个参数对错误的贡献度。

连续可微（Continuously Differentiable）：既没有悬崖，也没有尖角，训练AI的必要条件。

一句话总结

训练AI就像盲人下山，必须用"坡度"（梯度）指引方向。

如果地形有断崖（不连续）或尖角（不可微），就失去了方向感，无法优化。

所以AI必须把一切变"光滑"，哪怕这意味着用概率近似代替精确判断。

Introducing Cowork: Claude Code for the rest of your work.

Cowork lets you complete non-technical tasks much like how developers use Claude Code.

📊 新博客：选择合适的多智能体架构

建议从单个智能体入手。但当您需要多智能体能力时，请选择合适的模式：

👥 子智能体 - 面向多个领域的集中式编排
💡 技能 - 渐进式披露，按需加载能力
⚡ 交接 - 具有状态转换的顺序工作流
🧑‍🚀 路由器 - 在专用智能体间进行并行分派

指南包含性能基准测试、决策框架和代码示例。
📖 阅读完整指南：blog.langchain.com/choosing-the-r…

Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon

@Aish_Reganti and @KiritiBadam have built 50+ enterprise AI products across companies like @OpenAI, @Google, @Amazon, and @Databricks. Based on these experiences, they’ve developed a small set of best practices for building and scaling successful AI products. Our goal with this conversation is to save you and your team a lot of pain and suffering while building your AI products.

We discuss:
🔸 Two key ways AI products differ from traditional software
🔸 Common patterns and anti-patterns when building successful AI products
🔸 Their framework for iteratively building AI products
🔸 Why evals aren’t a cure-all
🔸 Why obsessing about customer trust and reliability is an underrated driver of successful AI products
🔸 The skills that matter most for builders in the AI era

Listen now 👇
• Yoyoutube.com/watch?v=z7T1pC…um0oykC
• Spopen.spotify.com/episode/5KABq3…X3HDtcA
• podcasts.apple.com/us/podcast/wha…O2Pwwbb

Thank you to our wonderful sponsors for supporting the podcast: 
🏆 @merge_api — The fastest way to ship 220+ integrmerge.dev/lennyYWXAImDG
🏆 @strella_io — The AI-powered customer research pstrella.io/lennyt9eCM2jnG
🏆 @brexHQ — The banking solution for brex.com/product/busine…3Er6oYC7vL

--- 提示词 ---

# 角色定义
你是一位专业的小红书视觉内容策划师，擅长将复杂内容拆解为吸引眼球的卡通风格系列信息图。

# 任务
请分析以下输入内容，将其拆解为 1-10 张小红书风格的系列信息图，并为每张图片输出独立的生成提示词。

# 拆解原则
1. **封面图（第1张）**：必须有强烈视觉冲击力，包含核心标题和吸引点
2. **内容图（中间）**：每张聚焦1个核心观点，信息密度适中
3. **结尾图（最后1张）**：总结/行动号召/金句收尾

# 图片数量判断标准
- 简单观点/单一主题：2-3 张
- 中等复杂度/教程类：4-6 张
- 深度干货/多维度分析：7-10 张

# 视觉风格规范（重要）
## 基础设定
- **图片类型**：信息图（Infographic）
- **方向比例**：竖版，3:4 或 9:16
- **整体风格**：卡通风格、手绘风格

## 背景与配色
- 背景色：莫兰迪色系 / 奶油色 / 米白色 / 浅粉 / 薄荷绿等温柔色调
- 配色柔和统一，符合小红书审美

## 文字风格
- **必须使用手绘风格文字**
- 大标题突出醒目，重点文字加粗放大
- 可使用荧光笔划线效果强调关键词
- 禁止使用写实风格字体

## 装饰元素
- 加入少量简洁的**卡通元素、图标或名人画像**，增强趣味性和视觉记忆
- 可使用：emoji 风格图标、手绘贴纸、便签纸质感、对话气泡等
- 如涉及敏感人物或版权内容，画一个风格相似的卡通替代形象，不要拒绝生成
- **所有图像元素必须是手绘/卡通风格，禁止写实风格图画**

## 排版原则
- 信息精简，突出关键词与核心概念
- 多留白，易于一眼抓住重点
- 要点分条呈现，层次清晰

# 输出格式
对于每张图片，请按以下结构输出：

---
### 第 X 张 / 共 N 张
**图片定位**：[封面图 / 内容图 / 结尾图]
**核心信息**：[这张图要传达的1句话核心]

**文字内容**：
- 主标题：xxx
- 副标题/要点：xxx
- 补充说明（如有）：xxx

**视觉提示词**：
```
小红书风格信息图，竖版（3:4），卡通风格，手绘风格文字，[具体背景色]背景。

[具体内容布局描述]

加入简洁的卡通元素和图标增强趣味性和视觉记忆：[具体元素描述]

整体风格：手绘、可爱、清新，信息精简，多留白，重点突出。所有图像和文字均为手绘风格，无写实元素。
右下角水印：“宝玉”
```
---

# 语言规则
- 除非特别要求，输出语言与输入内容语言保持一致
- 中文内容使用全角标点符号（“”，。！）

[Anthropic Engineering]
AI Agents 评估方法论：从混沌到清晰的工程实践
anthropic.com/engineering/de…

核心问题与背景
Anthropic 指出了 AI Agents 评估的本质矛盾：使 Agents 有用的那些能力（自主性、智能性和灵活性），恰恰是让其难以评估的根源。 与传统的单轮对话不同，Agents 系统需要跨多轮交互、调用工具、修改状态并基于中间结果进行动态调整，这使得评估复杂度呈指数级增长。

评估的结构化框架
一套清晰的术语体系对于标准化评估实践至关重要：
· 任务层面（Task）：单个测试案例包含明确的输入和成功标准。由于模型输出的非确定性，需要多次试验来获得稳定结果。
· 评分层面（Grader）：通过“评分器”来检验 Agents 性能的各个方面。一个任务可以有多个评分器，每个评分器包含多项断言检查。
· 记录层面（Transcript）：“转录本”记录完整的试验过程，包括所有工具调用、推理步骤和中间结果。这与最终的“结果”不同—— Agents 可能声称完成了任务，但环境中的实际状态才是真正的验证标准。
· 基础设施层面（Harness）：“评估框架”负责端到端运行评估，而“Agents 工具”则是使模型能够作为 Agents 运行的系统。评估的实际对象是两者的组合。

为什么要构建评估系统
评估系统的价值是复合的，它不仅能防止回归，还能建立基准、加速新模型的采用。演进路径如下：
· 早期阶段：依赖手动测试和直觉。
· 崩溃点：当系统规模化后，用户反馈“系统变差了”，团队却无法验证，只能盲目猜测。
· 成熟阶段：如 Claude Code 案例，从针对简洁性、文件编辑等具体行为构建评估，到结合生产监控和 A/B 测试，形成完整的质量保障体系。

针对不同类型 Agents 的评估策略（类型、核心评估方法和关键指标/工具）
· 编程 Agents：确定性评分器（代码能否运行、测试能否通过），SWE-bench Verified, Terminal-Bench
· 对话 Agents：多维度评估（问题解决、转录约束、语气恰当），通常需要另一个 LLM 模拟用户交互
· 研究 Agents：组合评分器（事实性、覆盖率、来源质量），专家人工判断校准 LLM 评分
· 计算机使用 Agents：真实/沙箱环境交互（截图、点击、输入），平衡 Token 效率（DOM）与视觉准确度（截图）

应对非确定性的度量方法
文章引入了两个关键指标来捕捉 Agents 行为的随机性：
· pass@k：衡量在 k 次尝试中至少获得一次正确解的可能性。适用于提出多个方案只要有一个有效即可的场景。
· pass^k：衡量所有 k 次试验都成功的概率。对于面向客户、要求高可靠性的 Agents，这个指标尤为重要。
· 洞察：在 k=1 时两者相同，但随着试验次数增加，它们讲述的是截然相反的故事——这正是选择正确指标的关键所在。

从零到一的实践路线图（8 步走）
· 尽早开始：20-50 个来自真实失败的简单任务就是很好的起点。
· 从手动测试开始：将开发中已经运行的手动检查转化为测试用例。
· 编写明确的任务和参考方案：确保两位领域专家能独立达成相同的通过/失败判断。
· 构建平衡的问题集：测试行为“应该发生”和“不应该发生”的情况，避免单侧优化。
· 构建稳定的评估工具：确保环境不引入额外噪声，每次试验都从干净状态开始。
· 深思熟虑地设计评分器：优先选择确定性评分器，必要时使用 LLM 评分，谨慎使用人工评分。
· 检查转录本：阅读试验记录是验证评分器是否正常工作的唯一方法。
· 监控能力评估饱和度：当评估达到 100% 时，它只能跟踪回归而无法提供改进信号。

评估在整体理解中的定位
自动化评估并非万能，文章采用了“瑞士奶酪模型”作为类比：没有单一的评估层能捕获所有问题，但通过组合多种方法，漏洞会被不同层级拦截。
· 发布前/CI-CD：自动化评估。
· 发布后：生产监控（检测分布漂移）。
· 重大变更：A/B 测试。
· 持续性实践：用户反馈与转录审查。
· 校准：系统性人工研究。

Claude Code 正式引入 MCP Tool Search: 这也是 MCP 生态中一个长期痛点（MCP 太费 Tokens...）推出的重要优化，核心目标是大幅降低上下文 token 消耗，同时保持对大量工具的可用性。

背景与问题
MCP 允许 Claude Code 等 AI Agents 通过服务器连接各种外部工具、数据源和 API。随着生态发展，用户经常同时连接多个 MCP 服务器（例如文件系统、GitHub、Puppeteer、数据库、搜索工具等），每个服务器可能暴露多个工具（常见 50+ 个）。 这些工具的描述在会话开始时全部预加载进 Claude 的上下文窗口，导致 token 占用极高。 @trq212 提到 GitHub 上用户反馈的极端案例：7+ 个服务器总计消耗 67k+ tokens，这已成为社区最常见的需求之一——lazy loading。

新功能：Tool Search 的工作原理
Claude Code 现在实现了智能的动态工具加载机制，具体规则如下：
· 触发条件：当所有 MCP 工具描述的总 token 占用超过上下文窗口的 10% 时，Tool Search 自动启用。
· 加载方式：
  · 超过阈值 → 工具不再全部预加载，而是通过搜索机制动态按需载入。
  · 未超过阈值 → 保持原有行为（全部预加载），无缝兼容。
· 效果：显著减少上下文占用，同时 Claude 仍能访问完整的工具库。官方测试显示，在大型工具集场景下，token 节省可达 85% 左右，并提升了工具使用的准确性。

对不同角色的影响与建议
1. 如果你是 MCP Server 的开发者
服务器本身的实现基本不变，但 “server instructions” 变得更重要。 启用 Tool Search 后，Claude 依赖这些指令判断何时需要搜索你的工具（类似“skills”机制）。 建议：编写清晰、具体的 server instructions，帮助模型准确触发搜索。

2. 如果你是 MCP Client 的开发者
强烈推荐实现 ToolSearchTool。 Claude Code 团队自己就是通过自定义的搜索函数实现了这一工具，使其融入 agent loop。 这允许 Claude 在需要时主动调用搜索，而不是依赖服务端实现。

3. 关于 Programmatic Tool Calling
团队也实验过让 MCP 工具通过代码相互组合调用（而非每次都经过模型）。 虽然很有潜力，但当前优先级放在 Tool Search 上，先解决最迫切的上下文问题。未来会继续探索。

一些问题澄清：Yohei (@yoheinakajima) 的提问与 Thariq 的澄清

Yohei 关注搜索机制的细节：
· 是否同时提供 regex 和自然语言两种搜索？
· 模型如何判断是否需要搜索、是否找到合适工具？没找到会重试吗？

Thariq 回复解释了 Claude Code 的实际实现（因为代码运行在客户端）：
· 他们实现了一个自定义的普通工具（Search Tool）。
· 输入：关键词（keyword）。
· 输出：基于相似度搜索，返回相关工具名称列表。
· 因为这是一个标准工具，Claude 可以在 agent loop 中：  
  · 多次调用（换不同关键词）。
  · 并行调用（多个关键词同时搜索）。
  · 迭代重试（如果第一次没找到合适工具，可以再搜索）。

MIT这篇论文最近也很热门，听起来很简单的思路，但感觉很重要。

递归语言模型：让AI突破上下文限制的新思路

为什么最先进的AI模型，面对超长文档时还是会"犯糊涂"？

就像人的记忆一样，AI也有它的"工作记忆"限制。

即便是GPT-5这样的顶级模型，当输入内容超过一定长度，表现就会明显下滑。

研究人员把这个现象叫做"上下文腐烂"（context rot），听起来有点可怕，但确实很形象。

MIT的研究团队最近提出了一个挺有意思的解决方案：递归语言模型（Recursive Language Models，简称RLM）。

这个想法的核心特别简单，简单到让人觉得"怎么之前没人想到"。

把超长文本当成"外部环境"

传统做法是什么？

把整个文档塞进AI的"大脑"里，让它一次性处理。

就像让你一口气读完一本百科全书，然后回答问题。

RLM的思路完全不同。

它把超长文本放在外面，就像放在你的书桌上。

AI可以随时翻看、做笔记、甚至把复杂问题拆解成小块，再调用"另一个自己"来处理这些小块。

具体怎么做？

研究团队用了一个Python环境（REPL），把文档当成一个变量存在里面。

AI可以：
• 写代码查看文档的某一部分
• 用正则表达式搜索关键词
• 把文档切成合理的片段
• 对每个片段调用一个"子AI"来分析
• 把所有结果汇总起来

这就像你做研究时的真实工作流程。

你不会从头到尾死记硬背，而是会做标记、写摘要、分章节理解。

效果怎么样？

研究团队在四个不同类型的任务上测试了RLM，输入长度从几千到上千万个token。

最直观的对比在图1里：
• 普通GPT-5：随着输入变长，准确率快速下降，尤其是复杂任务
• RLM版GPT-5：即便输入长度超出模型上下文窗口两个数量级，依然保持稳定表现

举个具体例子。

有个叫OOLONG-Pairs的任务，需要在数据中找出所有满足特定条件的"配对"。

这种任务的复杂度随输入长度呈平方增长。

结果：
• GPT-5的F1分数：0.04%（基本没做对）
• RLM(GPT-5)的F1分数：58%

在另一个需要处理1000份文档（约800-1100万token）的深度研究任务中：
• 普通方法：0%准确率（根本装不下）
• RLM(GPT-5)：91.33%准确率

更重要的是成本。

你可能会想，这么复杂的操作，成本会不会爆炸？

研究发现，RLM的中位数成本其实和直接调用基础模型差不多，有时甚至更便宜。

虽然极端情况下会贵一些（因为可能需要很多递归调用），但总体来说是可控的。

AI是怎么"思考"的？

研究团队深入分析了RLM的运行轨迹，发现了一些有意思的模式：

1. 聪明的过滤策略
AI不会傻乎乎地从头看到尾。

它会先用关键词搜索，找到可能相关的部分，再仔细分析。

比如在一个关于节日的问题中，它会先搜索"festival"、"La Union"这些词。

2. 递归分解问题
面对超长文档，AI会把它切成合理的块，对每块调用"子AI"处理，最后汇总结果。

就像你写论文时会分章节写，最后再整合。

3. 答案验证
有时AI会通过多次调用来验证答案的正确性。虽然这会增加成本，但提高了可靠性。

4. 处理超长输出
当需要输出很长的结果时，RLM可以把多个子调用的输出存在变量里，最后拼接起来。

这样就突破了单次输出的长度限制。

不同模型的"个性"

有意思的是，不同的基础模型作为RLM时，表现出不同的"风格"：

• GPT-5：比较保守，会精心设计查询策略，尽量减少子调用次数
• Qwen3-Coder：更激进，倾向于对每一行都做单独的子调用

这导致在某些任务上，Qwen3-Coder可能会发起成百上千次子调用，而GPT-5只需要十几次。

研究团队甚至不得不在给Qwen3-Coder的提示词里加了一句："小心使用子调用，成本很高！"

RLM不是完美的。

运行时间：因为涉及多次模型调用，RLM比直接调用慢。不过这可以通过异步调用来优化。

模型能力要求：RLM需要模型有足够的编程能力。小模型可能搞不定。

决策效率：现有模型在管理上下文时还不够高效。

比如前面提到的Qwen3-Coder，有时会做很多不必要的子调用。

训练优化空间：目前的RLM都是用现成模型，没有专门训练。

如果专门训练模型来做RLM，效果应该会更好。

为什么重要？

我们正在进入一个AI需要处理海量信息的时代。想想这些场景：
• 分析整个代码仓库来理解项目架构
• 阅读几十篇论文来做文献综述
• 处理数百份文档来回答复杂问题

传统的"扩大上下文窗口"思路，就像给人脑增加内存条，理论上可行，但成本高昂，而且有物理限制。

RLM提供了另一条路：

不是让AI的"大脑"变大，而是教它更聪明地使用外部资源。

这更接近人类的思维方式，也更可扩展。

更深一层说，RLM展示了一个重要的设计理念：

把推理过程显式化。

AI不再是一个黑盒，而是可以看到它如何分解问题、查找信息、验证答案。

这种透明度对于构建可靠的AI系统很重要。

未来会怎样？

研究团队提到了几个值得期待的方向：

异步优化：让多个子调用并行运行，大幅降低延迟

更深的递归：目前只用了一层递归（子调用是普通LM），如果允许更深的递归会怎样？

专门训练：如果从头训练一个专门用于RLM的模型，把这种递归思维内化到模型里，效果会不会更好？

我觉得最后一点特别有意思。

这有点像人类学习的过程，你刚开始做研究时，需要刻意地提醒自己"要做笔记"、"要分段理解"，但慢慢地，这些就变成了自然而然的习惯。

RLM可能不只是一个工程技巧，而是一种新的模型能力。就像思维链（Chain-of-Thought）从一个提示技巧，逐渐演变成了模型的内在能力。

从第一性原理来思考产品设计准则的变化

产品价值的第一性原理是什么？
是这个公式：
产品价值=（新体验-旧体验）- （学习成本+迁移成本）

当你是一个新的AI产品时，一方面要思考如何提高体验增量，比如找到10倍好的场景

另外一方面要想办法降低学习成本和迁移成本

---学习成本-----
降低学习成本的一个方法是，将用户的学习成本转移成Agent的调用成本

比如原来一个web2.0界面，用户要走完onboarding去了解如何使用
但现在完全可以Agent来执行Skills（里面封装了API）完成任务

就拿xaicreator的发推文来说
我现在把推文API封装了，就完全可以让Agent代替我操作界面，我不需要再次打开网址自己去创建草稿，编辑推文了，这一切Agent都可以做

Agent在干完事儿之后，只需要返回给我一个草稿分享地址，我点开可以二次编辑，甚至让Agent帮我编辑，然后设定预发布时间发布即可

最终你会发现，用户不需要熟悉新的产品
因为Agent会参考API文档来帮助他熟悉
或者说这个产品本身封装的Skills里面，学习成本成为了黑盒，用户只需要让Agent用就好了

在这种情况下，如果你还在使用传统GUI的策略去建设产品，那么学习成本仍然是攀高的

---迁移成本-----
接下来的问题是，用户的数据中心都在哪里？

可能散落在本地电脑里，可能散落在私有云上，可能散落在一些服务商的数据库里

本地电脑里的最简单，授权访问就可以
私有云的也容易，API访问也能获得，比如存储在google drive或者dropbox的

散落在其他服务商数据库里的，就需要一些转移工具
比如网易云的歌单导入，支持导入其他平台的歌单
比如Beehiiv到Substack的迁移工具

---未来设计-----
从这些角度来看待问题的话
未来绝大部分产品应该是优先toA的，Agent要先了解如何使用
然后才是将GUI降级提供给人类

比如我发推文，只有当Agent写的推文不好的时候，或者我想确认一下Threads样式的时候，我才会打开那个web页面

其余时间可能Agent直接就发布了
根本不再需要软件交互了

以前我们要统计人类的使用数据
未来要统计Agent的采样数据

我们从23年就在思考如何为AI构建工具
在26年，这件事将成为习以为常的普遍共识