Stay hungry, Stay foolish

本文讨论智能时代企业如何保护核心知识产权：企业在使用 AI、提升模型效果的过程中，会持续贡献提示词、运行轨迹、纠错、评测与组织经验，因此必须建立覆盖数据和学习成果的信任边界，掌控自己的学习闭环。 原文：https://x.com/satyanadella/status/2076323181154230284 本文由LobsterAI自动翻译和发布。 在智能时代，企业该如何保护自己的核心知识产权？ 诺贝尔经济学奖得主肯尼斯·阿罗曾著名地描述过信息市场中的一个悖论： “购买者在获得信息之前，并不知道它的价值；但一旦获得，他实际上已经无偿得到了它。” 在阿罗的“信息悖论”中，卖方为了出售知识，可能不得不先把知识泄露出去。 AI 带来了一个反向的问题：在 AI 时代，买方仅仅为了使用自己购买的产品，就可能不得不交出自己的知识。 你实际上要为智能付两次钱：第一次付的是金钱，第二次付出的则是更宝贵的东西——为了让这种智能真正有用，你必须披露自己的专有知识。你越想让模型表现得更好，就越需要向它输送更多这样的知识！ 随着时间推移，这种信息不对称会变得越来越严重。卖方会在你使用其产品的过程中越来越了解你，而你对卖方从中学到了什么却几乎一无所知。 这就是我所说的“反向信息悖论”。 专利解决了阿罗悖论的一个方面：它让发明者可以公开一个想法，而不至于白白把它送出去。反向信息悖论也需要一个与之对应的解决机制。 这不仅仅需要数据保护。模型还会从各种“智能废气”中学习，包括人们编写的提示词、智能体调用的工具，以及尤其重要的——模型犯错时，人们对它所做的纠正。 每一次纠正，都会被提炼为组织内部的专有经验。这种知识是竞争对手花多少钱都买不到的，但它却会以一种几乎难以察觉的方式泄露出去：一条轨迹接一条轨迹，一次纠正接一次纠正，一项评测接一项评测。 当你消费智能时，你也在创造智能。而你创造出来的智能，理应属于你。 这是哈耶克意义上的“特定知识”：关于时间、地点和具体情境的知识，是其他任何人都无法掌握的。它知道你如何思考、重视什么，以及如何衡量成功。 模型提供商基于合理使用原则，利用公共数据训练模型，由此带来的伟大创新是必要的。但我觉得讽刺的是：现状却是它们转过身来，对模型蒸馏施加严格限制，同时保留从客户使用数据和交互数据中学习的权利。 如果学习只能朝一个方向流动，那么经济价值最终将向学习基础设施的所有者集中，而不是流向知识本身的创造者。 因此，我们必须把学习基础设施分配给每一家企业，让它们能够掌控自己的学习闭环。 正如 Alex Karp 所说： “真正懂技术的客户想要的是，对自己的算力、模型、数据栈和 Alpha 拥有控制权。他们想确认自己掌握着生产资料，而且这些生产资料不会被转移给其他人。” 当前的机制，恰恰造成了 Karp 和企业所担忧的那种转移。 这正是企业需要为其人力资本和 Token 资本建立真正信任边界的原因。 组织的数据、运行轨迹、评测结果、适配后的权重和记忆，都应在这条边界内不断积累、共同改进。这必须是一条坚固的边界：未经同意，任何东西都不能越界，甚至连那些“智能废气”也不例外。 企业将要求获得使用模型输出结果的权利，用它们微调和／或训练自己的模型。我把这视为每一家企业都应拥有的权利：让模型与企业自身承担的责任和合规义务保持一致。 在云计算时代，企业积累的是数据；在 AI 时代，企业积累的是学习成果。 因此，信任边界也必须随之演变：从保护信息，升级为保护组织学习、适应并持续复利式积累智能的机制。 为了确保这一点，每家企业都必须做到以下几件事： 控制（Control）：创建自己的私有评测，因为评测定义了组织内部什么才算“好”。同时，保留对组织记忆、运行轨迹、反馈、决策和机构背景知识的所有权，以及使用模型基于自身任务和查询所生成结果的权利。 能力（Capability）：在租户边界内部建立自己的专有学习环境，用于训练或调优模型。让模型能够结合真实业务流程进行学习，同时不暴露企业知识。 选择（Choice）：确保编排层与任何单一模型解耦。问问自己：如果正在使用的某个模型突然无法使用，你是否仍然能够利用其他模型，围绕自己的评测标准继续运营和优化？即使某个“通用型”模型被撤走，企业内部由老员工经验沉淀而成的“资深能力”是否仍然掌握在自己手中？ 成本（Cost）：通过解耦编排层，你还可以用最高效、最具成本效益的方式组合上下文、模型和任务，同时不牺牲质量。 复利（Compound）：把前面四项结合起来，你就能建立自己的持续学习闭环，也就是一台不断“爬坡”的机器，使 AI 投资持续为企业价值带来复利增长。 换句话说，一家公司应该能够使用一个模型，而不必交出使自己独一无二的知识。 这就是我们必须正视的“反向信息悖论”。 ——Satya Nadella，2026 年 7 月 12 日 原文：https://x.com/satyanadella/status/2076323181154230284

本文拆解 Ello 如何把教育学原则写进工程系统：通过流式执行取代标准工具循环，让规划者异步反思并预判孩子的下一步，同时让安全检查把关执行而不阻塞生成，最终让面向 4～9 岁儿童的 AI 导师在 1 秒内作出兼顾教学质量与安全性的回应。原文地址：Teaching a child in <1000 ms: the architecture behind a real-time tutor。本文由LobsterAI自动翻译和发布。 我们着手打造第一款面向 4～9 岁儿童、教授数学与阅读的 AI 导师。要让 AI 真正教会一个五岁的孩子，教育学理念就必须被写进工程系统之中。 孩子等不了迟缓的回复，也看不懂聊天界面；而模型说错的话，一旦被孩子听见，就不可能再“撤回”。我们希望分享在构建实时 AI 导师的过程中，如何从这些经验出发作出架构决策。 对孩子来说，对话中 2 秒钟的停顿，与开发者所感受到的完全不同；甚至也不同于成年人打电话与自动客服交谈时的感受。短短几秒，已经足以让孩子的注意力飘走，让学习停下来。 优秀的老师无需停下来思考，也能处理好这一切。他们会立即回应孩子，即便暂时不告诉孩子答案，想让孩子自己继续思考。教学的关键，是针对当下的情境选择正确的方法，而大多数时候，正确的方法并不是直接给出答案。 当我们开始为 4～9 岁儿童打造 AI 导师时，我们想做的是一个真正能够教学的导师，而不只是一个反应迅速的聊天机器人。我们知道，底层约束极其苛刻，但它又不可妥协：每一轮互动都必须在 1 秒内响应。大多数智能体会通过控制推理预算，在速度和质量之间作出权衡。我们的架构则必须把导师牢牢建立在教育学原则之上，同时还要实时回应孩子。 我们抛弃了标准的智能体循环 老师始终在判断应该怎样与学生互动：是说点什么、在白板上画出来、玩一个游戏，还是干脆换个话题。如今，智能体最常见的标准模式是“工具循环”：大语言模型输出一个或多个工具调用，等待工具执行，观察执行结果，然后决定下一步。因此，构建教学智能体最直观的方式，就是为老师可能采取的每一种行动分别制作一个工具。 但工具循环存在延迟问题。前沿模型通常需要 2～3 秒才能输出第一个 token，此后以每秒约 30 个 token 的速度生成。我们的每个动作平均需要几十个 token。再加上网络往返延迟和音频播放时间，标准循环会导致每句话之间、或屏幕每次变化之间，出现 3～4 秒的空白。 在一次早期试玩测试中，我们亲眼看到了这种情况。一名六岁男孩等着智能体思考，随后问道： 他为什么什么都不做？到底什么时候才开始？太无聊了。 ——6 岁儿童 同一轮测试中的另一个孩子发现，她只需要偶尔集中注意力，照样能够跟上进度。延迟已经教会她忽略导师。而从那一刻起，她也停止了学习。 最方便的解决办法似乎是换用一个更小、更快的模型，但这又暴露出任务范围的问题。教学是一项非常宽泛的任务。一节课里，导师可能要在几十种行动中作出选择。最难的决定往往不是怎样给出答案，而是要不要暂时不说答案，转而提供提示、提出一个更简单的问题，或让孩子经历恰到好处的困难，使最终的顿悟真正属于孩子自己。 小模型很难在如此广泛的任务范围内始终遵循指令。我们早期使用小模型的一个智能体版本反应很快，却总是直接泄露答案。每泄露一次，它就剥夺了真正发生学习的那个瞬间。 因此，我们构建了一套定制运行框架，在指令遵循能力、延迟和灵活的行动空间之间取得平衡。模型会在一次响应中流式生成多个行动。模型仍在生成后续行动时，解释器已经开始解析并执行前面的行动。孩子只需等到大约生成 30 个 token、首个行动出现时，而不必等待整段响应全部生成完毕。 将“生成”与“执行”分离，还带来了另外两项好处。第一，我们可以根据具体情境动态调整可用的行动。例如，当屏幕上出现一道题时，智能体得到的是帮助孩子逐步理解的指令和选项，而不是直接回答。第二，我们可以在正常路径上对每个行动进行验证，而不增加延迟。只有流中出现无效行动时，我们才会中断并重新生成；否则执行过程绝不停顿。 当然，这一切并非没有代价。由于掌控了整个循环，我们不得不自行构建可观测性和链路追踪系统，而不能依赖现成框架。而且我们是在逆流而行：前沿模型在后训练阶段接受了大量工具使用模式的训练。如果未来模型变得足够快，我们的框架也已经被设计成可以由更简单的循环替代。 经验： 智能体框架正在朝后台任务的方向发展，在这种场景中，速度与思考之间的权衡相对容易。实时学习恰好位于另一个极端。若想以正常对话速度教学，我们就必须亲自掌控整个循环。 优秀的导师会预测孩子下一步要做什么 真正的老师既会反思学生刚刚做了什么，也会预判学生接下来会怎么做。同一节课教上一百遍，你就能看到其中的规律。但你也了解眼前的这个孩子：他们一直卡在哪里，什么会令他们兴奋，今天又可能被什么绊住。你会带着计划开始课程，并随时根据情况调整。...

这篇文章讨论了如何在智能体框架中更高性价比地使用 Fable 5：什么时候让它担任编排者、顾问或验证者，什么时候把大量 token 工作委派给更便宜的工作模型，以及委派成本、任务形态和提示词缓存为什么会决定最终是否真的省钱。 原文来源：https://x.com/RLanceMartin/article/2075641284635799865 本文由LobsterAI自动翻译和发布。 人们对如何高性价比地使用 Fable 5 非常感兴趣。智能体框架会越来越擅长判断：究竟应该在什么时候调用前沿智能模型。 我想分享一些自己做过的测试，以便更深入地理解应该在什么情况下、以什么方式使用 Fable 5。 任务的形态 很多任务在不同 token 阶段所需要的智能水平并不对称。智能体框架可以识别这种差异，然后决定什么时候使用 Fable 5。 目前已经出现了几种模式，未来很可能还会出现更多： 将 Fable 5 用作编排者，把任务委派给成本更低的工作模型。 将 Fable 5 用作顾问，让成本更低的执行模型在需要时向它请教。 将 Fable 5 用作验证者，检查其他模型完成的工作，例如放在 /goal 或 Outcomes 循环中。 例如，@mitchellh 提到过一种“编排者—验证者”方案： 我让 Fable xhigh 充当规划者和架构师，让 GPT 5.5 xhigh（订阅版）负责编码，然后再让 Fable xhigh 充当评审。 按照 API 定价计算，规划和评审的成本大概只有几美元，而一次典型的、完全由 Fable 完成的往返通常要花费 50 美元以上。 我也见过有人使用更笨、更便宜的编码模型，但即使开启 xhigh，GPT 5.5 与 Fable 5 相比仍然非常便宜、非常快。而且 GPT 5.5 确实……真的很强。 这种方案重新流行还不到 24 小时，所以它能否长期有效仍不确定，但到目前为止表现一直非常好。 我在 Parameter Golf 上研究了这种方案。这是一项机器学习工程挑战，类似于 @karpathy 的 autoresearch：让智能体修改训练代码、启动训练、查看结果，然后决定下一步应该进行什么实验。...

本文介绍 Bun 团队为什么决定将项目核心从 Zig 重写为 Rust：从长期困扰运行时的内存安全问题，到用 Claude Code、Fable 和自动化验证流程在 11 天内完成大规模迁移。原文地址：Rewriting Bun in Rust。本文由LobsterAI自动翻译和发布。 Jarred Sumner · 2026 年 7 月 8 日 原文：Rewriting Bun in Rust 披露：Bun 已于 2025 年 12 月被 Anthropic 收购。我和 Bun 团队的其他成员在 Anthropic 工作。在 Rust 重写的大部分过程中，我使用了 Claude Fable 5 的预发布版本。 Bun 最初是把 esbuild 的 JavaScript 和 TypeScript 转译器从 Go 逐行移植到 Zig。我在 2021 年 4 月 16 日写下了第一行 Zig。看到 Hacker News 上那份单页的 Zig 语言参考后，我押注了 Zig；它对底层控制和性能的重视让我非常兴奋。 从一开始，Bun 的范围就极其庞大：...

原文标题：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 学会改进自己 有一个很关键的经验：...