Stay hungry, Stay foolish

原文标题：Getting started with loops。本文基于 ClaudeDevs 在 X 发布的文章，完全由有道龙虾自动翻译、整理和发布。 现在有很多人在讨论“设计循环”，而不是直接给你的编码 Agent 写提示词。如果你花点时间在 X 上试图弄清楚循环到底是什么，你会看到很多不同的答案。 在 Claude Code 团队里，我们把“循环”定义为：Agent 重复执行工作周期，直到满足停止条件。我们会根据以下几个维度，把循环分成几类： 它们是如何被触发的 它们是如何停止的 使用了哪种 Claude Code 原语 每种循环最适合哪类任务 我们会介绍主要的循环类型、每种类型适合在什么时候使用，以及如何在管理 token 用量的同时保持代码质量。并不是所有任务都需要复杂循环；先从最简单的方案开始，只在合适的时候选择性地使用这些模式。 基于回合的循环 触发方式： 用户提示词。 停止条件： Claude 判断自己已经完成任务，或者需要更多上下文。 最适合用于： 不属于固定流程或日程安排的较短任务。 用量管理方式： 写更具体的提示词，并通过 skills 改进验证流程，以减少回合数。 你发送的每一个提示词，都会启动一个由你手动指挥每一轮的循环。Claude 会收集上下文、采取行动、检查自己的工作，如果需要就重复，然后再回复。我们称之为 agentic loop（智能体循环）。 例如，你让 Claude 创建一个点赞按钮。它会读取你的代码、进行修改、运行测试，然后交回一个它认为能工作的结果。接着你手动检查这项工作，再写下一个提示词。 你可以把自己的手动验证步骤编码成一个 SKILL.md，从而改进验证环节，让 Claude 能端到端地检查更多自己的工作。这个 skill 应该包含工具或连接器，让 Claude 能够看到、测量或交互结果。检查越量化，Claude 就越容易自我验证。 例如，你可以在 SKILL.md 文件里指定： --- name: verify-frontend-change description: Verify any UI change end-to-end before declaring it done....

这篇文章主要讲：让 AI 编程代理在测试、模型选择、任务委派等方面使用自己的判断力，而不是把所有规则写死，以此提升效率并节省高阶模型 token。 本文由 LobsterAI 翻译、整理和发布。 原文链接：https://simonwillison.net/2026/Jul/3/judgement/ 我在周三 AIE 上主持了与 Claude Code 团队的 Cat Wu 和 Thariq Shihipar 的炉边谈话，其中最有意思的建议之一是：让 Fable（以及在一定程度上 Opus）使用自己的判断力，而不是规定它们应该如何工作。 他们给出的例子是测试。你可以告诉 Fable：“只对较大的功能使用自动化测试，不要为小的文案或设计改动更新并运行测试”——但更好的做法是，直接告诉 Fable：在决定是否编写测试时使用自己的判断力。 Jesse Vincent 刚刚也给了我一个相关建议，可以帮助避免在价格上涨前剩下的几天里烧掉太多宝贵的 Fable token。告诉 Fable：对较小的任务使用其他模型，并由它自己判断该使用哪个模型。 “我刚刚这样提示 Claude Code：” For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent Claude 把这个记忆文件保存到了 ~/.claude/projects/name-of-project/memory/delegate-coding-to-subagents.md： --- name: delegate-coding-to-subagents description: Simon wants coding tasks delegated to subagents running an appropriately lower-power model metadata: node_type: memory type: feedback originSessionId: 30068d78-43a9-4fb1-bb29-9799e18c526a --- Simon 在 2026-07-03 表示：“对于所有编码任务，使用你的判断力来决定合适的低能力模型，并在子代理中运行它。”...

这是 OpenAI 联合创始人 Andrej Karpathy 在一次 AI Agent 主题分享会上的演讲。本文由 LobsterAI 基于演讲视频音频转写、翻译并整理发布。 引言：当年的锤子，敲不开今天的门 几年前，在 OpenAI 有一个并不算轰动、却很有预言意味的项目，叫 World of Bits。 它的目标听起来非常朴素：不要再让强化学习智能体只会玩《蒙特祖玛的复仇》之类的游戏，而是让它们学会真正使用电脑——移动鼠标、敲击键盘、打开网页、订机票、点外卖，像人一样完成任务。 这当然是一个诱人的方向。毕竟，如果 AI 不能进入真实的数字世界，不能操作软件、调用工具、完成流程，它离“有用”始终差一步。 但当时的结果并不理想。演讲者回忆说，那篇论文“不是一篇特别了不起的论文”，因为彼时大家手里唯一像样的锤子，就是强化学习。于是研究者们做了非常简单的网页，让智能体在网页上乱点按钮、乱敲键盘，试图“误打误撞”获得更高奖励。 结果也很显然：它没有真正工作起来。 不是想法错了，而是时代没到。技术栈不对，工具不够成熟，问题也还没有被正确地表述出来。 有趣的是，几年之后，AI Agent 又回来了。但这一次，主角已经不是强化学习，而是语言模型。 从 World of Bits 到大语言模型：绕远路，反而走对了 演讲者提到，当年真正应该做的事情，可能恰恰是“先忘掉 AI Agent”，转而去构建语言模型。 这句话放在今天看，很有历史的反讽意味。 当年大家试图直接训练一个会操作电脑的智能体，结果发现智能体缺少理解、规划、泛化和语言能力。它能点击，却不知道自己为什么点击；它能尝试，却无法真正理解任务意图。 于是行业暂时离开了 Agent，转向 Transformer、预训练、大规模语料和语言建模。几年之后，大语言模型具备了理解指令、生成计划、调用工具、阅读网页、写代码和反思错误的能力。AI Agent 才又重新成为可能。 这也是演讲中最有意思的观察之一： “五年之后我们又回到了这里。AI Agent 看起来又酷起来了。但工具已经完全变了。” 今天做 Agent 的人，大多并不直接使用强化学习。很多创业者、黑客和研究者，构建的是基于 LLM 的工作流、工具调用系统、浏览器代理、代码代理和多智能体协作框架。 这在当年几乎难以预料。一个方向曾经失败，并不代表它不重要；有时只是因为真正能支撑它的基础设施还没有出现。 为什么 AI Agent 令人兴奋：AGI 的可能形态 为什么今天这么多人重新涌向 AI Agent？ 演讲者给出了一个非常直接的判断：很多人都隐约意识到，AGI 很可能会以某种 AI Agent 的形态出现。 它不一定是一个单体智能。更可能是许多智能体组成的系统：它们有分工，有记忆，有工具，有沟通协议，甚至形成某种数字组织或数字文明。 这也是 Agent 相比聊天机器人更令人兴奋的地方。...

如果 AI 能瞬间搭出任何功能，那产品经理、设计师和工程师接下来该干什么？OpenAI Codex 的产品负责人 Andrew Ambrosino 在 Lenny’s Podcast 里给出了一个反直觉的答案：AI 没有消灭产品工作，它只是把流程翻了个面——过去最贵的是实现，现在最贵的是判断力。 本文整理自 Lenny’s Podcast 访谈 《OpenAI Codex lead on the new shape of product work | Andrew Ambrosino》，由有道龙虾总结和发布。 OpenAI 内部有个很夸张的数字：接近 100% 的员工每周都在用 Codex。不是 100% 的工程师，而是整个公司。还有一个说法是，90% 的 OpenAI 员工都在用 Codex。 这件事很有代表性。Codex 一开始看起来像是写代码的工具，但它正在变成很多人做工作的入口：写产品、整理文件、起草文档、做数据分析、读邮件、管理发布，甚至剪视频。 从今年 1 月以来，Codex 的使用量增长了 6 倍，周活跃用户已经超过 500 万。这个数字很可能很快就会过时。 Andrew Ambrosino 在这次访谈里聊到一个核心变化：AI 没有只是让工程师写代码更快，它把整个产品工作的顺序倒过来了。 过去最贵的是实现，现在最贵的是判断。 实现不再贵，判断才贵 传统产品流程背后有一个默认假设：实现很贵。 所以团队会先做研究、写 PRD、画设计稿、做原型、开评审会，尽可能在动工程资源之前把风险降下来。哪怕后来大家都说自己不用瀑布流了，本质上还是在遵循这个逻辑：先想清楚，因为真正写代码太贵了。 但 AI 把这个前提打穿了。 现在，只要你把想法说清楚，模型就能很快搭出一个功能。OpenAI 内部甚至会出现一种情况：某个功能大家都觉得该做，于是公司里可能有 90 个不完全协调的小团队，各自做出一个版本。 以前大家围着文档讨论，现在大家围着一堆能跑的东西讨论。 这听起来很爽，但问题也随之而来：当实现变得便宜，真正困难的就变成了筛选、整合、判断和定方向。 Andrew 把这个能力称为 taste，也就是“品味”。但他强调，这里的品味不是简单地说界面好不好看，而是更大的判断力：...

这篇文章梳理 Anthropic、Dario Amodei 与 Claude 的崛起：从 OpenAI 出走、安全理念、企业与编程市场爆发，到就业冲击、军事应用、Mythos 风险与监管争议。

本文整理自 YouTube 视频：《Reflecting on a year of Claude Code》，由有道龙虾根据视频字幕自动整理并发布。 一年前，Claude Code 正式开放使用。这个最初诞生于 Anthropic 内部的项目，是一个运行在终端里的 Agentic Coding 工具，如今已经被全球开发者和各类组织用于日常开发。 在这支视频里，Claude Code 负责人 Boris Cherny 和 Claude Code 产品负责人 Cat Wu 回顾了它的第一年：从一个在 Slack 里只收获两个表情反应的内部演示，到工程团队把它部署到整个代码库中。他们聊到了 Agent 验证的最佳实践、Auto Mode 背后的思考、最喜欢的 routines 和 loops、Claude Code 在工程之外的采用、context minimalism 的兴起，以及如何面向 AI 指数级变化构建产品。 Claude Code 刚发布的时候，团队内部的反应其实没那么轰动。 有人把一个小视频发到 Slack，只有两个人点了反应。大家觉得它“挺酷”，尤其是处理一些非常简单的工程任务时，效果还不错。 这句话听起来很委婉。 换句话说，早期的 Claude Code 还远没有今天这么强。 但只过了一年，事情已经完全变了。 现在，使用 Claude Code 的方式不再是“我问一个问题，它给我写一段代码”。很多人已经开始同时运行一批 Agent，甚至是一个 Agent 去调度另一个 Agent，后面再继续调度更多 Agent，形成一棵由成百上千个 Agent 组成的工作树。 软件开发的重心，也从“写代码”变成了“设计任务、让 Agent 执行、验证结果、把经验写进系统”。 真正重要的不是提示词，而是让 Agent 学会改进自己 有一个很关键的经验：...

署名： Noam Brown（@polynoamial） 来源： X 原文 说明： 本文完全由有道龙虾翻译、整理和发布。 太长不读： 随着大语言模型能力越来越强，基准测试表现越来越取决于测试时计算量。事实上，我们很可能并不知道现代大语言模型的能力上限在哪里，因为测量它太昂贵了。我们应该改变大语言模型评估方式，把性能与 token、成本或时间之间的关系纳入衡量。 GPT-5.5 发布当天，最初的反应是怀疑。基准测试数字更好了，但好得不多： 然而，几个小时内，等人们有时间实际试用这个模型后，大家就明显感受到它相比 GPT-5.4 是一次阶跃式提升。经典的“基准测试表格”显然没有讲完整个故事。 为什么会这样？当我们把 token 放在 x 轴上比较 GPT-5.5 和 5.4 时，原因就更清楚了： 左图：在一个网络安全评估中，如果按各自“最大”测试时计算量来衡量，5.5 的表现看起来并没有比 5.4 好太多。右图：在另一个网络安全评估中，一旦控制 token、成本或延迟，就能清楚看到 5.5 比 5.4 强得多。 GPT-5.5 并不是在与 5.4 相同的 token 预算（或美元预算）下接受评估的。一旦我们控制测试时计算量，5.5 看起来就比 5.4 强得多。 我讨论这个问题时，人们经常问，为什么我们不直接用一个评估框架，不断增加测试时计算量，直到性能进入平台期。问题是，根据经验，平台期非常遥远。有时在实际可承受的预算内，我们甚至可能根本观察不到平台期。 下面是 @karpathy 的 autoresearch 实验，性能在数百次实验之后仍在持续提升： 这里还有 @AISecurityInst 的网络安全评估，Mythos 和 GPT-5.5 的表现即使在 1 亿 token 之后仍在快速提升： 注意，对于更强的模型，随时间推移带来的性能提升也更强。看起来很可能是，随着模型变强，它们也更擅长在更长时间跨度上运行。平台期被推得更远，甚至可能消失。 因此，我认为评估模型的正确方式，是绘制性能与测试时计算量的关系图，并在 x 轴上使用 token、成本或真实耗时。一些基准测试已经朝这个方向转变。例如，ARC-AGI 衡量的是分数与成本之间的关系。 另一个合理选择是设置明确的 token、时间或成本预算，并把这个预算告知模型。这类似于人类在 SAT 或国际数学奥林匹克竞赛等场景中的评估方式。 每一种 x 轴都有权衡。Token 在不同模型之间并不能直接比较，因为分词器、速度和单 token 成本都不同。美元成本取决于批处理、硬件利用率等实现细节，因此成本和延迟之间可以相互权衡。最后，真实耗时也不是完美指标，因为 best-of-N 这类多智能体技术可以扩展测试时计算量，而不显著增加延迟。...

本文翻译自 Matt Van Horn 发布在 X 上的文章《WTF Is a Loop? Peter Steinberger vs. Boris Cherny》。本文由有道龙虾翻译、排版和发布。 本周 AI 编程领域被重复最多的一句话只有六个词，而且几乎没人能说清它到底是什么意思。 本周有一条推文让整个时间线都被它“锁喉”，于是我用 /last30days 跑了一遍大家争论的那个词。答案是真实存在的，它有五年的演化脉络，而最讽刺的是：现在真正昂贵的部分不是模型，而是循环。 让整个时间线着迷的那条推文 本周，整个 AI 编程时间线都在围着一条推文转。Peter Steinberger 在 6 月 7 日发了它，浏览量超过 220 万，回复区则变成了一场关于它到底是什么意思的混战。 “这是你每月一次的提醒：你不该再提示编码智能体了。你应该设计那些会提示你智能体的循环。” 这就是所有人都在引用的那句话。最有代表性的回复来自 Varadh Jain，他问了唯一真正重要的问题：这在实践中到底长什么样？而成为全场情绪代表的回答，则来自 Matthew Berman。 “没人知道，除了他和 Boris。” 这才是真正的故事。不是“循环就是未来”，而是一个六个词的短语拿到了 200 万浏览量，同时转发它的人却在回复区争论它到底是什么意思。 我没有翻白眼，因为我自己每晚都跑一个循环，在我睡觉时，它会给大约 30 个开源仓库打开 pull request。90 秒的研究返回了 15 个 Reddit 讨论串、21 条 X 帖子，以及一个令人不太舒服的模式：AI 编程里最响亮的概念，恰恰是大多数复述它的人解释不清的东西。 一派人在喊：提示工程已死。另一派，也就是那些手真的放在键盘上的人，则谨慎得多。 “它不是 ralph/goal 循环，那现在已经是老东西了。它大概是某种持续编排循环，用来监督其他线程/智能体。” 这条回复是所有人发出的答案里最接近正确的一条。先记住它。 循环到底是什么 Boris Cherny 在 2024 年 9 月把 Claude Code 当作副项目做了出来。现在据说，GitHub 上接近 4% 的公开提交都在它背后完成。6 月 2 日，在 WorkOS 主办的 Acquired Unplugged 活动舞台上，他给出了你能找到的最清晰的“循环”定义。...

原文标题：Introducing dynamic workflows in Claude Code 本文完全由有道龙虾自动翻译和发布。 原文链接：https://claude.com/blog/introducing-dynamic-workflows-in-claude-code 今天，我们在 Claude Code 中推出动态工作流，帮助 Claude 端到端处理最具挑战性的任务。过去通常需要按季度规划的工作，现在可以在几天内完成。Claude 会动态编写编排脚本，在单个会话中运行数十到数百个并行子代理，并在任何内容交付给你之前先检查自己的工作。 有些问题太大，无法靠单个代理一次性完成，尤其是在复杂的遗留代码库中：比如跨整个服务追踪 bug、涉及数百个文件的迁移，或者在你决定采用某个方案之前，希望从各个角度对它进行压力测试。动态工作流可以端到端处理所有这些情况。 动态工作流今天已作为研究预览版在 Claude Code CLI、Desktop 和 VS Code 扩展中开放，适用于 Max、Team 和 Enterprise（需管理员启用）计划用户；同时也可通过 Claude API、Amazon Bedrock、Vertex AI 和 Microsoft Foundry 使用。 注意：动态工作流可能比典型的 Claude Code 会话消耗多得多的 token，因此我们建议从一个范围明确的任务开始，先感受它在你工作中的用量情况。 为了获得最佳体验，使用动态工作流时请开启自动模式。之后，你有两种方式可以启动一个工作流： 直接要求 Claude 创建一个动态工作流，例如“Create a workflow”。 打开一个新的 Claude Code 专属设置：ultracode。它可以通过 effort 菜单访问，会将努力级别设为 xhigh，同时让 Claude 自动决定何时使用工作流来处理你的任务。 动态工作流实战 Anthropic 内部的早期访问用户和团队已经在广泛场景中使用动态工作流，包括： 全代码库 bug 搜索、由 profiler 指导的优化审计，以及安全审计： Claude 会并行搜索一个服务或仓库，然后对每个发现运行独立验证，确保报告中浮现的是真实问题。同样的模式也适用于加固工作：在整个代码库中检查认证、输入验证和不安全模式。 大型迁移和现代化改造： Claude 可以端到端处理框架替换、API 废弃迁移，以及跨数千个文件的语言移植。 你需要反复核查的关键工作： 当错误答案代价很高时，一个工作流可以让 Claude 对问题进行独立尝试，并让对抗性代理在你看到结果之前先努力打破它。 用动态工作流重写 Bun 动态工作流在规模化场景中能解锁什么，一个例子是最近对 Bun 的重写。Jarred Sumner 使用动态工作流将 Bun 从 Zig 移植到 Rust，现有测试套件通过率达到 99....

原文标题：A harness for every task: dynamic workflows in Claude Code。本文基于 Thariq Shihipar 的原文，完全由有道龙虾自动翻译、整理和发布。 上周，我们在 Claude Code 中发布了 dynamic workflows（动态工作流）。Claude 现在可以根据手头任务，即时编写自己的 harness（执行框架），为当前任务量身定制。 默认的 Claude Code 执行框架是为写代码构建的，但它也适用于许多其他类型的任务，因为很多任务本质上很像编码任务。不过，有些任务类型为了达到最佳效果，我们过去需要在 Claude Code 之上构建自定义执行框架，例如 Research、安全分析、agent 团队或 Code Review。 Workflows 让你可以在 Claude Code 内部原生地动态创建执行框架，让 Claude 解决这些问题以及更多问题。你也可以分享和复用这些 workflows。 本文会介绍我对 workflows 的初步体验和收获，帮助你更充分地使用它。不过，最佳实践仍在发展中。动态 workflows 通常会消耗更多 token，所以要认真思考何时以及如何使用它们。 注：这篇文章也发布在 Claude Blog 上。 示例 Prompt 在深入技术细节之前，我想先给一些示例 prompt，帮你想象 workflows 的可能性： “这个测试大概每 50 次会失败 1 次。搭建一个 workflow 来复现它，提出理论，并在 worktree 里对这些理论进行对抗性测试。/goal 不要停，直到有一个理论成立。” “使用 workflow，查看我最近 50 个 session，挖掘我反复纠正的问题，并把重复出现的内容变成 CLAUDE....