Claude 实际能做什么。大多数人毫无概念。

今年某个时候，Claude 不再只是一个你可以对话的工具，而变成了一个能代表你执行任务的系统。

这发生在十几次独立的发布中——Fable 5、Opus 5、定时任务、Claude Code、一个现在能同时容纳三十本小说的上下文窗口。每一次都被报道、讨论，然后划过。

与此同时，你的信息流里塞满了一知半解的术语。智能体（Agents）。循环（Loops）。图（Graphs）。你看到过解释，点头同意，然后继续往下刷。今天大多数使用 Claude 的人无法告诉你这些词在实践中到底意味着什么。

读完这篇文章，你会知道到底发生了什么变化，那些术语是什么意思，以及 Claude 今天能做什么： 智能体、循环、图，以及其他所有你信息流里提过一次却从未真正解释清楚的东西。

模型变了

1. Fable 5

六月份发布，因出口限制短暂下架，七月份回归。如果你错过了发布窗口，你可能只听到“新的 Claude 模型”就继续往下刷了。那是个错误。

Fable 5 不是你已知 Claude 的更好版本。之前的模型——Sonnet、Opus——是对指令做出回应。Fable 5 在回应之前会先进行推理。它会规划。它能连续运行任务数小时而不需要中途确认。它能在运行过程中发现并纠正自己的错误。给它一个目的地，它会自己规划路线。给它一条路线，反而会拖慢它。

在旧版 Claude 上有效的习惯——把任务拆分成步骤、要求它展示推理过程、每几条消息就检查一下——对 Fable 5 来说反而是阻碍。这个模型天生就是为了保持主线而设计的。打断它就像在别人说一半时停下来问他是怎么想的。

现在产品线中有四个模型，大多数人用默认的那个。

用错模型，花更多钱，产出更少。

2. Opus 5

Fable 5 获得了大部分关注。Opus 5 才更值得被关注。

如果说 Fable 5 是为了推理速度和智能体任务而生，那么 Opus 5 是为了深度而生。它读得更慢，思考得更久，不会急于给出第一个看似合理的答案。给它一份复杂文档、一个艰难的研究问题、一个涉及二十个变量的决策，Opus 5 会找到第十四页里那个被埋没、却能改变全局的东西。

大多数人从不主动选择它，因为他们不知道它到底有什么不同。在简单任务上，差距并不明显。当工作真正困难时，差距才会显现。

同样的提示词，两个模型：

❌ Sonnet —— “分析这个收购目标，指出任何风险。”

返回一份干净的摘要。市场地位、收入趋势、整合复杂度。都是你早就猜到的东西。没有任何你不知道的。

✅ Opus 5 —— 同样的提示词，同样的文档。

指出第十四页的递延收入确认问题。注意到客户集中度比标题数字所暗示的更高——三个客户占 61% 的收入，而它们都没有明年以后的合同。指出整合时间表假设了技术栈迁移，而没有任何可比交易曾按计划完成过迁移。

它找到了你需要找到的东西。而不是你已知的东西。

Opus 5 比 Sonnet 更慢、更贵。这只有在一种情况下值得：搞砸的代价高于多思考一会儿的代价。

3. 上下文窗口

每次你在粘贴到 Claude 之前先总结一遍文档，你都是在解决一个已经不存在的问题。

大多数人学会了节制地给 Claude 提供信息。只粘贴相关部分，而不是整个文档。总结邮件线程，而不是倾倒全部内容。提取代码库的关键部分，而不是每个文件。这些习惯在 2023 年是有意义的。当时上下文窗口很小，触达上限是一个真实的问题。

现在上下文窗口是 1,000,000 个 token。实际来说：

• 一本 400 页的书能装进去，还有富余
• 你一整年的邮件历史能装进去
• 一个完整的软件代码库能装进去
• 过去六个月的每一次会议记录都能装进去

在把东西交给 Claude 之前编辑删减、总结、挑选“相关部分”的冲动，是人们浪费价值最常见的方式。Claude 不会因为信息更多而困惑。它会变得更准确。你因为看起来不相关而删掉的东西，往往正是 Claude 给你有用答案所需要的东西。

别再删减了。把整个都粘贴进去。让 Claude 去找什么重要。

你与 Claude 协作的方式变了

4. 智能体（Agents）

4.1 智能体到底是什么

聊天是一次性的交换。你问一个问题。Claude 回答。对话结束，或者你再问一次。你始终在循环之中——推动事情向前的是你。

智能体不同。你给 Claude 一个目标，它朝着目标运行。它规划步骤、逐一执行、使用工具、检查自己的工作，然后继续前进，直到任务完成或遇到真正模糊不清的东西。你不在循环之中。你在等待结果。

区别不是某个可以打开的功能。而是你构建请求的方式发生了转变。“给我写一份这份文档的摘要”是聊天。“研究这个领域排名前五的竞争对手，拉取他们的定价，找出差距，给我一份可以直接发给团队的报告”是智能体任务。同一个 Claude。不同的关系。

4.2 在实践中是什么样子

你像给一个你信任的、能自己搞定其余事情的有能力的人布置任务那样给 Claude 下指令。

❌ 聊天方式： “搜索关于 Notion 定价的信息。”

Claude 返回它找到的内容。你阅读。你追问。你再读。你自己拼凑。

✅ 智能体方式： “我需要一份对五大项目管理工具的竞争分析——Notion、Asana、Linear、Monday、ClickUp。对每个：当前定价层级、过去六个月有什么变化、评论里用户抱怨最多的地方，以及他们做得比别人好的一件事。格式化成表格，我要放进演示文稿。”

Claude 规划研究，逐个拉取，交叉引用，格式化输出，交付一个你能直接用的东西。你给了它目的地。它找到了路线。

启用网络搜索后，Claude 可以在一次运行中处理这种多步骤任务。对于更重的智能体工作——运行数小时、写入文件、执行代码的任务——那是 Claude Code 的领域。

4.3 什么时候该用

并非每个任务都需要智能体。快速编辑、简短摘要、需要快速回答的问题——这些是聊天任务，把它们变成智能体运行只会增加摩擦而没有收益。

智能体在以下情况下才值得：

• 任务有多个步骤，且都汇聚到最终输出中
• 你通常需要来回折腾 30 分钟才能完成
• 结果需要可以直接使用，而不是进一步工作的起点
• 步骤足够清晰，Claude 可以在过程中自己做决定

最简单的测试： 如果你发现自己向 Claude 问一件事、阅读答案、然后根据它说的再问下一件事——那就是伪装成对话的智能体任务。把它压缩成一个指令，让 Claude 去跑。

5. 循环（Loops）

5.1 循环是什么

智能体运行一个任务并交付结果。循环则运行一个任务，检查结果是否足够好，如果不够——再运行一次。

结构总是相同的：做工作，对照目标验证，如果不合格就迭代，通过就停止。那个周期就是循环。它会一直持续，直到成功或触达你设定的限制。

这之所以重要，是因为第一次尝试很少是任何事物的最佳版本。经过三轮自我批评和修改的文字，比没有经过这些的文字更好，而循环只是把那个过程自动化了。你定义“足够好”是什么样。Claude 自己算出需要多少遍才能达到。

5.2 验证步骤——让它真正有效的关键

大多数尝试循环的人忽略了这部分，然后奇怪为什么输出一直平庸。

循环的质量取决于做检查的那个东西。如果你让 Claude 做一个任务，然后让同一个 Claude 检查它是否做得好，你得到的是一个给自己作业打分的模型。它几乎每次都会觉得输出可以接受。循环在转，分数很高，任务退出，输出平庸。

验证步骤必须要有牙齿。这意味着三件事之一：

• 一个要么通过要么失败硬性条件。代码能编译或不能编译。字数达到目标或没达到。一个说法有来源或没有。某件二元的事，Claude 无法靠说服绕过。
• 一个带有具体标准的评分标准。不是“这好不好”，而是“开头是否以一个具体例子开始，是否避免使用‘杠杆’这个词，每个段落是否少于四句话”。Claude 可以逐条检查并诚实地打分的标准。
• 一个独立的审查者。第二个 Claude 实例，使用不同的指令集，不是“检查这是否好”，而是“找出这里面所有问题，要具体”。全新的上下文，没有编写它正在审查内容的记忆。这种距离感才是让反馈真实的原因。

没有这三者之一，你就没有循环。你只有 Claude 按计划与自己达成一致。

5.3 什么时候值得构建循环

循环比单次运行更贵。每次迭代都要花 token，验证步骤又在上面加了一层。对于一个只运行一次、不会重复的任务，设置成本很少回本。

循环在以下情况下才值得：

• 质量比速度更重要——你需要最好的版本，而不是第一个版本
• 任务会重复——同样类型的工作每周或每天都会来
• 你对“完成”有清晰的定义——“足够好”是你能描述出来的，而不只是感觉
• 第一遍结果可靠地不够好——第一次尝试总有需要修的东西

最常见的错误是为一次性任务构建循环。第二常见的错误是跳过停止条件。没有退出条件的循环会一直运行，直到预算用完或遇到错误。开始之前设定最大迭代次数，三次通常够了，五次几乎总是太多。

如果一个任务只需要你两分钟手动检查和修复，那它大概不需要循环。如果需要三十分钟，而且你每周都做，那就需要。

6. 图（Graphs）

6.1 图是什么

你现在有了智能体。你知道它可以从头到尾运行一个任务，不需要你每一步都去引导。下一个问题是：当任务比一个智能体能处理的更大，或者其中有些部分可以同时运行而不是依次运行时，会发生什么？

这就是图的用武之地。

图是一张任务与依赖关系的地图。两个构件，没有别的。

节点（node） 是一个工作单元。一个智能体、一个任务、一个输入、一个输出。研究这家公司。审查这个文件。撰写这一部分。

边（edge） 是一个依赖关系。当第二个节点真正需要第一个节点产出的东西时，它连接两个节点。不是“这些按顺序发生”——只有当某个输出是下一个节点的实际输入时才是。

节点做工作。边承载节点之间流动的东西。

这之所以重要，是因为“真正”这个词。大多数工作流拥有的边超过了实际需要。步骤等待其他步骤，不是因为它们相互依赖，而是因为那是某个人输入时的顺序。图迫使你把每个依赖关系明确画出来，当你这样做时，你会发现那些从未真正存在过的依赖。

6.2 菱形（The diamond）

一旦你开始画图，一个模式比任何其他模式都更常出现。它有一个名字：菱形。

顶部一个节点扇出成几个并行节点。这些并行节点都汇入一个最终节点，由它整合所有输出。画出来，形状就像一个菱形。

它之所以重要，是因为时间。在线性工作流中，三个研究任务一个接一个运行，总时间是三者相加。在菱形中，它们同时运行——总时间是最慢的那一个。同样的工作，不同的结构，等待时间只是原来的几分之一。

菱形之所以有效，是因为三个研究节点之间没有依赖。它们都不需要其他节点产出的东西。唯一的真实依赖是底部的综合节点，它需要全部三个。所以你同时运行所有能并行运行的东西，只在不可避免的地方等待。

一旦你看到它，你会在任何地方发现它。任何时候工作流有“从多个地方收集，然后合并”的形状——那就是菱形。研究流程、代码审查、市场分析。收集团队是并行的。合并是汇聚点。

6.3 假边测试（The fake-edge test）

并非工作流中的每条箭头都是真实的。有些步骤看起来是连续的，仅仅因为那是你写下来的顺序。假边测试找出这些箭头并移除它们。

在工作流中的每个连接处，问一个问题：这个步骤是否真的需要前一个步骤的结果？不是“它在它后面”——它是否真的使用了前一个步骤产生的东西？

如果是，边是真实的。如果不是，就没有边。那两个工作可以同时运行。

经典例子：“审查文件 A 的 bug，然后审查文件 B 的 bug。”它读起来像是一个序列。但审查文件 B 从不看文件 A 返回的结果。它们一个接一个运行，只因为那是你输入的顺序。同时运行，整个事情在较慢的那个的用时内完成，而不是两者相加。

五分钟内对任何工作流运行这个测试：

• 把每个步骤写成一个方框
• 在每对连续步骤之间画一条箭头
• 对每条箭头：数据真的在这里穿过吗？
• 如果穿过——保留它。真实依赖
• 如果没有——删掉它。假边
• 所有没有入箭头的步骤可以立即开始

几乎在你画的任何工作流中，你都会发现两三条假边。每一条都是你白白送出去的时间。

Claude 离开了聊天窗口

到目前为止的一切都假设你在对话中。你打开 Claude，给它工作，等待结果。这个假设在很久以前就不再成立了。

7. 定时任务（Scheduled tasks）

Claude 可以在没有你的情况下运行。你设置一次任务——做什么、什么时候做、多久做一次，Claude 按计划执行。不需要打开标签页。不需要你触发。它运行，产生输出，并保存到你的文件夹中。

大多数人不知道这个功能存在。知道的人往往用过一次后，一周之内又建了五个。

最常见的用途是早间简报。Claude 检查你关心的主题的新闻，提取相关内容，去除噪音，在你打开电脑之前就有一份干净的摘要等着你。你那天早上并没有要求它。你设置了一次，它就到了。

这里有一个你直接可以复制粘贴的：

每个工作日上午 7:30，执行以下操作：

1. 搜索过去 24 小时最重要的 AI 和科技新闻
2. 挑选 5 个最重要的故事——关注那些令人惊讶、有真正影响、 或者大多数人错过的事情
3. 对每个故事：标题、两句话摘要、为什么重要
4. 将结果保存为“brief-[date].md”到我的 /briefs 文件夹

语气直接。不要废话。三分钟内能读完。

设置一次。每个工作日上午运行。你再也不用想它。

8. Claude Code

大多数人认为 Claude 是某种住在浏览