Anthropic 如何让 Claude 变得更可靠？
身处 AI 前沿，总有一种苦乐参半的感觉。你可能花上几周时间为一个问题鼓捣出一个变通方案，结果一家前沿实验室横空出世，以一种更优雅、更可靠的方式直接替你解决了。
今天的内容里，资深应用 AI 工程师 Nityesh Agarwal 将解释为何 Anthropic 的动态工作流（dynamic workflows）功能，让他精心搭建的 Claude 配置在事后看来显得笨拙可笑；Every 团队将分享他们允许自己忽略 AI 前沿的哪些角落；执行运营经理 Jalaiyah Bolden 则会逐步拆解她是如何将一个 Slack 机器人变成可靠同事的。
微型氛围检查：动态工作流（Dynamic Workflows）
细看 Claude Code 如何协调多个智能体
当资深应用 AI 工程师 Nityesh Agarwal 构建 Every 的 AI 项目经理 Claudie 时，他花了数天时间来琢磨如何绕过模型有限的上下文窗口（context window）问题——也就是一个大语言模型一次性能够处理的文本上限，而这也正是 Claudie 不断丢失关键细节的原因。
他的解决方案是：一个负责协调的智能体将任务委派给成群的子智能体（subagents），这些子智能体负责收集数据、进行更新，并通过本地的 Markdown 文件相互通信。Nityesh 说这个过程“有点土法炼钢的意思”，但它确实有效。
如果他今天再来构建 Claudie，他大可以直接使用 Anthropic 为协调大规模、多智能体 Claude Code 任务而推出的功能——动态工作流。Claude 不再是走一步看一步，而是会写一个可复用的脚本来协调工作。它能向多个子智能体分配任务，并让它们在上报结果前相互检查工作。
在动态工作流出现之前，试图让 Claude 可靠地生成审核智能体一直是个令人头疼的难题。出于对 token 消耗的担忧，模型“有时会试图把所有活儿都合并到一个子智能体里”，Nityesh 说，这拖累了结果的质量。即使用越来越夸张的指令去阻止它这么做，也常常被置若罔闻。现在，如果你告诉 Claude，你想用动态工作流生成三个验证子智能体，Claude 就会写一个脚本，每次都生成三个子智能体。
Nityesh 对这个新功能心怀感激，但眼看着几周的心血被一个版本的发布直接抹平，也着实让人沮丧。“我花了那么多时间构建那个东西，现在它没用了，”他说。
“但这就是身处前沿的代价，”他接着说，“你要走在所有人前面，有时候这就意味着你得扔掉自己过去的工作。”
（图片由 Anthropic 提供。）
一个动态工作流案例研究。 在为写作应用 Spiral 的重新设计中，高级设计师 Daniel Rodrigues 将一份巨大的 Figma 文件发给 Spiral 的总经理 Marcus Moretti。
Marcus 需要将这个文件转换成代码。他在 Claude Code 里跑了一遍，但结果漏洞百出。要是放在动态工作流出现之前，他得一拨拨地向 Claude Code 指出错误让它修复——这是一个重复且令人沮丧的过程。
而现在，Marcus 要求 Claude Code 建立一个动态工作流，逐段审查那份 Figma 文件，提取所有素材和设计细节，将其转为代码，并将结果与原文件进行核对。
这份 Figma 文件有 11 个部分，于是 Claude 启动了 11 个任务，每个任务都有专门的子智能体。在运行了几个小时后，“结果并不完美，”Marcus 说，但“它为我节省了一大把时间。”在动态工作流之前，每一个审核子智能体的角色都得由 Marcus 自己来扮演。
你也可以试试： Marcus 说，对于一些复杂项目，比如代码迁移、更改产品使用的编程语言或重大升级，动态工作流可能是一个不错的解决方案。要启动这个功能，你只需在 Claude Code 会话中输入 “workflow”，或在提示词中包含 “ultracode”。
或者，也可以试试 Nityesh 的提示词，用它来启动一个动态工作流。
允许自己略过
快问快答版
AI 发展的步伐毫不留情。每周都有新模型发布，新的基准测试结果，以及那些后来被证明往往只是渐进式改进的“范式转移”。
在 Every，我们竭尽全力留在前沿——但不管好坏，我们都是人，这意味着我们没法通宵达旦地跑实验。这里，Every 的员工分享了他们允许自己略过哪些东西，以便……你知道的，睡个觉，亲近一下自然，或是跑点别的 AI 实验。【声明：所有这些嘛，自然也是随时可能改变的！】
Mike Taylor，技术咨询主管：“所有不是来自 Anthropic 或 OpenAI 的模型发布。”在让 Fable 5 经历一番严苛测试而筋疲力尽后，Mike 最近拒绝了另一家大科技公司内测模型的机会。“我这么说可能有点傻，但我不指望它能像我们目前测试的模型那么好，”他说。“我可能真的抽不出时间。反之，如果我觉得某个东西真的、真的非常好，那我哪怕错过孩子的生日派对也会去测试它。”
Kieran Klaassen，Cora 的总经理：“开源模型。市面上太多了，而且它们不如最好的那些模型，所以我全部略过。”
Willie Williams，平台主管：那些新奇复杂的开发工作流——复合工程（compound engineering）的出现，治好了他在 X（原 Twitter）上看到它们时的“错失恐惧症（FOMO）”。“我就用复合工程里的 ‘/lfg’ 工作流，”他说。“现在我觉得，‘我只要有它就够了。’”
Daniel Rodrigues，高级设计师：为智能体准备的设计系统（Agent-ready design systems），在这类系统中，你需要将品牌资产和设计决策转换成智能体能够理解的代码。他能看到这种工作方式的价值，尤其是在客户端，但如果有的选，构建这些复杂的系统并不是他愿意花时间去做的事。为什么？“它看起来一点都不好玩，而设计本就该是好玩的，”他说。说得好。
拿走这个工作流
像对待同事一样对待你的 Slack 机器人
Jalaiyah Bolden 是 Every 的执行运营经理：她负责管理 CEO Dan Shipper 的日程、内部活动、运营项目以及客户支持。她规模虽小但战斗力强的团队使用了多个基于 Slack 的智能体——其中最引人注目的是 Viktor——来自动化或辅助处理那些不断丢给他们的繁杂任务。
以下是 Jalaiyah 逐步让智能体接手例行任务的流程，这些任务包括审计工单关闭情况、创建折扣码，或汇编支付争议的证据。
- 挑选一个重复性的工作。从一件低风险但烦人的事情开始。任何不止一次出现在你办公桌上的事都符合条件：它可能是一份模板化但很冗长的周报，一次客户支持审计，或是一个创建优惠码的工作流。不管是什么，确保智能体能访问它查找或核实信息所需的系统，然后描述你想要的最终产出。例如：“审计一下 Fin（客户支持平台，前身为 Intercom）过去 12 小时的工单关闭情况，并标记任何可疑之处。”
- 开启一场对话。把机器人当作一名新员工来对待。Jalaiyah 常用的提示词是：“为了让这项任务可重复且长期保持一致性，你还需要哪些其他信息？”让智能体提出澄清性问题，然后给它规则、示例、边缘情况和关于什么是“好”、什么是“坏”的清晰定义。
- 审阅并修正它返回的结果。让智能体收集信息并起草回应。然后由你亲自审核结果，解释哪些地方需要以不同方式处理，并填补任何信息缺口。下次的结果应该就会有所改善。
本周就试试： 选择一个重复性任务，然后问问你的智能体：“为了让你能每周可靠地运行这项任务，你还需要我提供哪些其他信息？”
最后一件事
Mistral 是啥？
当消息传出，顶尖 AI 公司的负责人将 在七国集团（G-7）峰会上齐聚一堂，讨论技术带来的“机遇与危险”时，与会者阵容和你预期的一样：OpenAI 的 CEO Sam Altman，Anthropic 的 CEO Dario Amodei，Google DeepMind 的 CEO Demis Hassabis，Meta 的首席 AI 官 Alexandr Wang，还有 Mistral 的 CEO Arthur Mensch。
如果你在想 Mistral 是怎么拿到入场券的，那你不是一个人在纳闷。Mistral 是一家法国的开源模型制造商，据《纽约时报》称，它是“欧洲最受推崇的人工智能公司之一”。但在 X 上，这家公司更出名的可能是一只的恶搞全能模型——“胖猫咪（Le Chaton Fat）”，这个梗在网上爆火，起因是 Mistral 宣布将其聊天机器人从 Le Chat 改名为 Vibe，引得网友纷纷发帖，构想出 Le Chat 之后其他以猫为主题的继任者。
（截图由 X 用户 Laura Entis 提供。）
我们仍然不清楚那场 AI 闭门会议到底讨论了什么，但 Mistral 的亮相，不出你所料，引来了更多的梗图。
核心启示：身处 AI 前沿意味着不断追逐更高效的解决方案，即使这意味着亲手淘汰自己过去的成果。Anthropic 的动态工作流功能以更底层、更可靠的方式解决了复杂任务协调问题，直接免去了工程师们那些不得已的“土法炼钢”，生动展示了在技术狂奔中，个人的聪明才智在平台级创新面前的脆弱与渺小。
How Anthropic Makes Claude More Reliable 的发芽报告
材料核心
Anthropic通过“动态工作流”功能解决了Claude在多智能体协作中的可靠性问题——将原本需要工程师花费数周“拼凑”出来的子代理协调逻辑，转化为模型自身可编写、可复用的结构化脚本。这一变化不仅提高了输出质量，也重新定义了人与AI的协作边界：人从“系统组装者”转向“目标定义者”。
发芽 01：深度解读——从“拼凑逻辑”到“可编程可靠性”
种子
Nityesh Agarwal 把之前的手动子代理方案形容为“a little bit hacky”，这个词精准地揭示了前动态工作流时代的核心状态：人类在替AI做本该它自己完成的协调工作。他设计代理之间的通信协议、用本地Markdown文件传递状态、甚至要用越来越夸张的指令阻止Claude“偷懒”把多任务合并到单个子代理——这是一种人迁就机器的协作模式。动态工作流的出现，表面上是技术升级，实际上是一次责任的转移：AI开始真正承担起“如何完成”的设计，而人类只需要声明“完成什么”。
故事主体
1980年，施乐PARC的研究员David Canfield Smith在开发图形用户界面时发现了一个问题：用户需要的不是“程序”，而是“环境”。传统计算机要求人把自己想做的事翻译成机器能理解的步骤序列（程序），而Smith提出的“可编程系统”概念试图反转这个关系——由系统提供基础能力框架，用户只需定义目标和约束。这一思想后来孕育了Macintosh的桌面隐喻，也奠定了现代操作系统中“文件-应用程序”交互模式的基础。
动态工作流在本质上完成了同一种反转。过去，Nityesh写的是“Claude的程序”——明确规定每一步谁和谁通信、谁在什么时候检查谁的结果。现在，他写的是“Claude的环境”——告诉系统“我需要11个部分被审查并转换成代码”，然后Claude自己决定如何分配任务、生成多少验证代理、用何种方式检查一致性。Smith的“可编程系统”花了四十年才从实验室走进消费者的手指尖；AI的“可编程可靠性”只用了不到两年。
这种加速背后有一个关键的结构性变化：Smith的系统中，环境能力是工程师预定义的（文件夹、文件、回收站）；而动态工作流中，环境能力是模型在运行时生成的（它自己写协调脚本）。这意味着“可靠性”不再是一个需要外部架设的框架，而是模型执行逻辑的内建属性。这正是Marcus Moretti体验到的那种质变：不是“更快地修复错误”，而是“在我介入之前，系统已经和它自己建立了质量检查回路”。
Aha 瞬间
“真正的可靠性不是给系统增加护栏，而是让系统有能力搭建自己的护栏。”
发芽 02：横向关联——经验折旧的速度定义了前沿成本
种子
Nityesh的那句“But that's the cost of being at the frontier”被放在括号里轻描淡写，但它实际上触及了这个时代最尖锐的职业焦虑：当单个产品更新就能让你的数周工作变成“useless”，那么我们投入时间的依据是什么？Every团队的“Permission to skip”栏目恰好提供了一个集体应对策略——战略性无知。这不是逃避，而是在承认一个残酷事实后的理性选择：你的经验可能在下个版本发布前过期，但你的判断力不会。
故事主体
2007年1月9日，Steve Jobs发布iPhone时，诺基亚的工程师们正在芬兰埃斯波调试N95的触摸屏驱动。他们没有松懈，也没有在技术上落后——N95支持3G、有GPS、有500万像素摄像头，而第一代iPhone连3G都不支持。但到2012年，诺基亚的市场份额从50%跌至不到5%。这里的关键不是他们“错过了什么”，而是他们累积了太多错误类型的知识：如何优化Symbian系统的内存管理、如何设计适合九宫格键盘的输入法、如何在不同运营商的标准之间做兼容。这些知识每一周都在增长，每一周都在让他们更擅长做一件即将被废弃的事。
AI前沿的开发者处于类似的位置，只是周期被压缩到数周甚至数天。Nityesh积累的是“如何绕过Claude上下文窗口限制”的知识，Anthropic一次更新就让这些经验归零。但这里有一个诺基亚故事的反面：诺基亚的工程师无法把自己的Symbian优化经验迁移到iOS开发，因为那是封闭生态；而Nityesh对Claude行为模式的理解（比如“模型会焦虑token消耗而试图合并代理”）是一种元知识——当动态工作流出现时，他不需要重新理解Claude的“心理”，他只需要把目标从“设计协调逻辑”调整为“设计目标描述”。
这也是为什么Mike Taylor敢说“所有非Anthropic或OpenAI的模型发布我都不看”。表面上是傲慢，实际上是一种经验折旧率管理：他选择把时间投入在模型行为深层模式的累积上（把Fable 5“through its paces”），而不是追逐每一个基准测试数字的波动。前者是有复利效应的知识，后者在下一个版本发布时就清零。
Aha 瞬间
“在前沿领域，真正危险的过时不是工具的过时，而是你对工具的理解方式还停留在上一个时代。”
发芽 03：批判性视角——把AI当同事是一个危险的隐喻
种子
Jalaiyah Bolden把Slack机器人当“new hire”来对待，这个思路直观好用：让它问澄清性问题、给它例子和边界条件、审查它的输出并反馈。这种拟人化策略降低了上手门槛，但也可能掩盖一个本质差异：当你的“新同事”是AI时，它的学习方式与人完全不同，而你建立在“人类同事”这个隐喻上的管理直觉，可能在关键场景下系统性失效。
故事主体
1972年，心理学家Paul Watzlawick在《变化》一书中区分了“一阶变化”和“二阶变化”。一阶变化是在系统内部调整参数：船向左偏了，往右打舵；销售下降了，增加广告预算。二阶变化是改变系统本身的规则：把帆船换成蒸汽船；从产品销售转向订阅服务。
Jalaiyah的方法论是典型的一阶优化：设定规则 → 提供例子 → 审查输出 → 反馈修正。这在“审计工单关闭”这类边界清晰的任务上很有效，因为任务本身的性质决定了AI的偏离是可预测的（忘记检查某个字段、误判某种边缘情况）。但如果把同样的“新同事”管理模式用在二阶任务上——比如让AI“设计一个新的客户留存策略”——会发生什么？
人类新同事在被要求提出策略时，会默认调用一整套隐含的知识结构：对行业常识的理解、对组织政治敏感度的预判、对“这个建议在公司文化里是否行得通”的直觉。AI没有这些，但它会模拟。Jalaiyah的“告诉它什么算好什么算坏”框架在这里会遇到一个致命问题：你怎么定义二阶输出中“好”和“坏”的标准？如果你能精确描述什么是好的客户留存策略，你其实已经完成了大半的策略工作——剩下的只是让AI美化措辞。
在Marcus的Figma转换案例中，这个问题被动态工作流巧妙地规避了，因为审查标准是可操作的（代码是否还原了设计稿）。但当AI的角色从“执行者”转向“设计者”，把“同事”这个隐喻继续沿用下去，可能会导致管理者高估AI的理解深度，忽略它只是在做模式匹配而非真正的判断。
Aha 瞬间
“把AI当同事不是错，错的是忘了它永远不会在半夜醒来，怀疑自己做的决定是否真的对组织有意义。”
你的思考空间
如果你的工作成果可能在下个产品发布时归零，你如何区分哪些是“会过期的经验”，哪些是“可以迁移的元知识”？Mike Taylor选择只看两家公司的模型，这是理性筛选还是另一种形式的盲区？
动态工作流让模型自己写协调脚本，但人类仍然需要定义“什么是好结果”。当任务从“转换设计稿”升级到“设计产品策略”时，定义“好”这件事本身会成为新的瓶颈吗？
既然战略性跳过AI前沿的某些领域是必要的生存策略，那么一个人或一个团队应该基于什么原则决定跳过什么、深入什么？Kieran跳过所有开源模型，但如果开源社区在某个细分领域突然超车，他的“判断力”能帮他多快转向？
Jalaiyah的方法依赖于“告诉AI好与坏的标准”，但如果你管理的任务本身就在探索好坏的定义边界，这个框架还适用吗？还是说，那类任务根本不该交给AI？