AI Agent

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

本文翻译自 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 活动舞台上，他给出了你能找到的最清晰的“循环”定义。...

原文标题：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....

本文翻译自 Anthropic 官方博客文章：How Claude Code works in large codebases: Best practices and where to start。本文完全由有道龙虾翻译和发布。 Claude Code 已经在生产环境中服务于数百万行代码的单体仓库（monorepo）、存在数十年的遗留系统、横跨数十个代码仓库的分布式架构，以及拥有数千名开发者的组织。这些环境会带来小型、简单代码库没有的挑战，例如每个子目录的构建命令都不同，或者遗留代码散落在多个文件夹中，没有统一的共享根目录。 本文总结了我们观察到的一些模式，这些模式帮助团队成功地在规模化环境中采用 Claude Code。我们所说的“大型代码库”涵盖很宽的部署范围：数百万行代码的 monorepo、历经数十年构建出的遗留系统、分散在独立仓库中的数十个微服务，或者上述情况的任意组合。这也包括使用某些团队不一定会与 AI 编程工具联系在一起的语言的代码库，例如 C、C++、C#、Java、PHP。（尤其是在近期模型发布之后，Claude Code 在这些场景中的表现通常比多数团队预期得更好。）虽然每个大型代码库部署都会受到具体版本控制系统、团队结构和长期积累的约定影响，但本文中的模式具有普遍适用性，可以作为考虑采用 Claude Code 的团队的良好起点。 Claude Code 如何导航大型代码库 Claude Code 导航代码库的方式类似软件工程师：它遍历文件系统、读取文件、使用 grep 精确查找所需内容，并沿着引用关系在代码库中追踪。它在开发者本机上本地运行，不需要构建、维护代码库索引，也不需要把索引上传到服务器。 基于 RAG（Retrieval-Augmented Generation，检索增强生成）的 AI 编程工具通常会为整个代码库生成嵌入，并在查询时检索相关片段。在大规模环境下，这类系统可能失效，因为嵌入流水线跟不上活跃工程团队的提交速度。等开发者查询索引时，索引反映的可能是数周、数天，甚至数小时前的代码库状态。检索结果可能返回一个团队两周前已经重命名的函数，或者引用上个迭代已经删除的模块，而且没有任何迹象表明这些结果已经过时。 智能体式搜索（agentic search）可以避开这些失效模式。它不需要随着成千上万名工程师不断提交新代码而维护嵌入流水线或集中式索引。每个开发者的实例都直接基于实时的本地代码库工作。 但这种方法也有取舍：只有当 Claude 拥有足够的起始上下文、知道该从哪里开始查找时，它的效果才最好。这意味着 Claude 的导航质量取决于代码库本身的准备程度，包括如何用 CLAUDE.md 文件和技能（skills）分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例，它可能在真正开始工作之前就碰到上下文窗口限制。愿意投入代码库准备工作的团队，会得到更好的结果。 运行框架与模型同样重要 关于 Claude Code，最常见的误解之一是认为它的能力完全由所使用的模型决定。团队往往关注模型基准测试，以及模型在测试任务上的表现。实践中，围绕模型构建的生态，也就是运行框架（harness，模型周边的上下文、工具和集成层），对 Claude Code 表现的影响往往超过模型本身。 这个运行框架由五类扩展点构成：CLAUDE.md 文件、hooks（钩子）、skills（技能）、plugins（插件）和 MCP servers（MCP 服务器）。它们各自承担不同功能。团队构建它们的顺序也很重要，因为每一层都会建立在前一层之上。另外还有两项能力补齐整体配置：LSP 集成和子智能体（subagents）。下面我们说明这些组件和能力分别做什么。 CLAUDE.md 文件应该最先建立。这些是 Claude 在每个会话开始时自动读取的上下文文件：根目录文件提供整体图景，子目录文件提供局部约定。它们为 Claude 提供完成任何任务所需的代码库知识。由于这些文件会在每个会话中加载，无论任务是什么，因此应只保留广泛适用的内容，避免它们拖慢性能。...

本文整理自 YouTube 视频《Alex from Anthropic on Claude, AI agents, memory and product management》，由有道龙虾总结和发布。 AI 公司到底怎么“做”一个模型？ 不是简单地把更多数据扔进去，也不是只盯着榜单分数往上刷。至少在 Anthropic 内部，Claude 更像一个正在被不断打磨的产品：它有目标用户，有核心能力，有缺陷清单，有反馈渠道，也有越来越重要的“性格”。 Alex 曾是 Anthropic 的开发者关系负责人，现在是研究团队的产品经理。他在访谈里聊到一个很有意思的视角：模型本身就是产品。 这句话背后，其实藏着现在 AI 产品管理最核心的变化。 模型不是“训练完就发布”，而是从第一天就被产品化 传统产品经理做产品，大概是理解用户问题、定义解决方案、推动团队把东西做出来。 研究团队里的 PM 也差不多，只是他们面对的“产品”不是一个按钮、一套流程或者一个 App，而是模型本身。 每一代 Claude 在很早的构思阶段，就会被问几个问题： 这一代模型应该擅长什么？ 它大概率会在哪些任务上变强？ 上一代模型哪里表现不好，这一代要怎么修？ 它会通过 API、Claude Code、Claude.ai、Co-work 等不同产品界面被怎样使用？ 这和普通产品开发最大的区别在于：软件功能通常是“造出来”的，而模型更像是“长出来”的。 团队可以根据训练方式、架构选择、数据和技术路线去预测它可能擅长什么，但直到训练过程真正发生，没人能百分百知道它最后会变成什么样。 所以研究 PM 的工作，就是从模型的 ideation 阶段一路跟到训练、评测、发布，再把来自用户、内部团队、产品界面的反馈重新带回下一轮模型开发。 Claude 要变强，不只是“会写代码” 过去一两年，编码能力当然是模型竞争的核心战场。 但 Alex 提到，Claude 的能力目标远不止写代码。知识工作、表格处理、Excel、文档分析、复杂产品任务，也都变成了重要方向。 尤其是随着 Claude 被嵌入越来越多产品界面，模型能力不再是孤立存在的。 同一个模型，在 Claude.ai 里、在 Claude Code 里、在 API 里、在 Co-work 里，用户体验可能完全不同。因为每个产品界面都有自己的提示词、工具、上下文和使用场景。 这就让模型 PM 的工作变得很复杂。...

本文整理自 OpenAI Forum 发布的分享视频，由有道龙虾总结和发布。 “Codex"这个词听起来像是给程序员准备的。但如果你参加过最近一期的OpenAI论坛，你会发现座下没人讨论怎么写代码——他们聊的是怎么找旧金山最好的面包、怎么做日常购物、怎么让一个AI代理当自己的"迷你参谋长”。 Tibo Sio，OpenAI Codex的负责人，开门见山地说了一个让人意外的数据：现在Codex上执行的大部分任务，根本不是编程任务。 从云端代码助手到桌面万能代理 Codex的故事其实走过一段弯路。 大约两年前，OpenAI团队开始追逐一个"宏大的挑战"：让AI达到顶级软件工程师的编程水平。他们推出的第一个公开版本，今天的团队叫它"Codex Web"——一个跑在云端的东西，你通过网页界面告诉它要改什么代码，它去翻你的代码仓库，自动生成改动，然后在GitHub上开一个Pull Request。 听起来很酷。但问题是：摩擦太大了。 你得把自己电脑上那一整套开发环境在云端重新搭一遍，而模型当时也没聪明到次次都靠谱。团队很快意识到：与其让人适配工具，不如让工具适配人。 “我们决定让它在每个人自己的机器上本地跑。“Tibo说。 转折点：连程序员的大部分时间都不在写代码 Codex最初是给工程师用的。但做着做着他们发现了一个有意思的事实：软件工程师每天真正写代码的时间，大概也就20%到30%。 剩下的时间呢？翻工单、排优先级、讨论架构方案、查Bug、处理线上事故、做值班……大量工作其实是信息搜集、沟通协调、上下文梳理。这些事跟写代码没半毛钱关系。 于是技术团队自己开始"吃自己的狗粮”——用Codex处理那些非编码的杂活。结果效果之好，让他们意识到：手里拿着的根本不是"代码工具”，而是一个通用得多的东西。 Tibo讲了一个让他印象深刻的瞬间：产品负责人Alexander在Codex发布前夕，同时跑着多个Codex代理——一个在搜集用户反馈，一个在跟开发者确认状态，一个在实时更新项目计划文档——而他自己正坐在会议室里跟Tibo讨论。 “我从来没见过一个人这么高效，“Tibo说，“那一刻我就觉得，我们在改变的不只是软件工程。” 这就是那个"原来这东西是给所有人用"的觉醒时刻。 面包、咖啡和"属于你一个人的软件” 为了让观点落地，Tibo在现场做了个演示。 他住在旧金山，对当地面包的离谱价格很不满，于是对Codex说了一句话：“帮我在旧金山找最好的面包，列个表格，标明价格和购买地点。” 五分钟之后，一张完整的电子表格出现了：烘焙店名、面包种类、描述、价格，一清二楚。 然后他随口又说了一句：“把同样的东西做成网页，放地图上。” 四分钟后，一个带交互地图的网页生成了——每家店的位置、面包信息、价格，全在地图上可视化呈现。他甚至可以说"对咖啡也做同样的分析”，八分钟后旧金山咖啡地图也做好了。 整个过程，Tibo连键盘都没碰——全程语音操作。 “这不是我花一整个周末才能做出来的东西，“他说，“在以前，这根本就不会发生。它不是从’几周变几秒’，是从’永远不可能’变成了’几分钟的事’。” 这就是Tibo反复强调的"个人软件"时代：每个人都有能力为自己量身打造小工具，而不用求人。设计师可以在代码库里直接改UI细节，不用跟工程师排期；市场人员可以做深度竞争分析，不用等数据团队排期。 首席参谋、自动化日报和一个"不用看邮件"的未来 Tibo自己怎么用Codex？他打开侧边栏——一天之内已经派发了上百个任务给Codex代理： 整理桌面文件 管理计算资源集群 帮我看值班轮转情况 检查即将上线的发布计划，标出有风险的项目 每天早上9点扫描我的Gmail、Notion和日历，给我一份当日摘要，标出需要注意的事项 “它就像我的小参谋长，“他说，“帮我花精力在最重要的事情上。” 他甚至做了一个"个人新闻简报”——根据他自己的偏好筛选信息，每天早上推送。以前，这种事要么不存在，要么得雇个人专门做。 更激进的想象是：未来你甚至不用看邮件了。一个全天候运行的代理读你的收件箱，只在真正重要的时候提醒你。“你只管设定目标，剩下的它帮你搞定。” 从10分钟到好几周：/goal模式的底气 对话的后半段，Tibo透露了一个正在铺开的新功能：slash goal。 普通模式下，你给Codex一个具体任务，它干完了汇报。但在goal模式下，你给它一个长期目标——比如"解决一个非常难的数学问题”——它就会像着了魔一样持续攻坚，干几个小时、几天、甚至几周，直到自己认为目标达成。 目前已经有人用它把整个程序从一种语言翻译成另一种，有人在物理和数学问题上用它突破瓶颈。 “几个月前我们还在激动它能连续工作10分钟，“Tibo说，“现在我们在讨论连续工作几周。有时候，天才不过就是能对同一件事持续思考更久。” 给非技术用户的三个行动建议 论坛上有观众问了一个很实操的问题：非开发人员到底怎么做，才能用好Codex？ Tibo给了三条： 1. 加入社群，看别人怎么用。 他自己都会被一些神奇的用法规避惊艳到。OpenAI论坛就是这样一个互相学习的地方。 2. 给它精确的指令，别模糊。 把它当成一个刚入职的新同事——没有上下文，不知道你的偏好。你得说清楚"成功长什么样"和"什么样算搞砸了”。比如要一份PPT，就明确说"我要10页，前两页放背景信息，中间六页做技术拆解，最后两页放开放问题和Q&A”。越具体，成功的概率越高。 3. 尽量连接更多信息源。 Codex现在有超过100个插件——日历、Notion、各类工具都可以接进来。接入的信息源越多，它能帮的忙就越大。 但有一条重要的提醒：别把所有事情都交给它。Tibo特别指出他见过最大的错误就是"过度委托”——把包括自己对问题的理解都一并外包出去。真正用好Codex的人，是在用它提升自己的认知，而不是替代自己的思考。它可以用图像和图表帮你理解复杂概念，但做笔记、主动回想、验证理解，永远是你自己的事。 企业落地的真正瓶颈：不是能力，是信任 当被问到企业采用的最大障碍时，Tibo的回答很直接：不是模型能力不够，是信任和安全问题。 “如果有代理在你公司里到处乱跑，不小心删了敏感文件，或者把不该发出去的信息外泄——没人敢用。” OpenAI在做三件事来解决这个： 沙箱默认运行：可以限制代理只能访问特定文件夹，甚至禁止联网 细粒度权限控制：可以设成"只能读不能写”，数据安全仍由你掌控 “自动审查"机制（Auto Review）：另一个独立代理实时监控主代理的每一步操作，风险动作直接拦截 “就像一个裁判在旁边，看到越界的操作立刻喊停。”...

本文翻译自 Thariq 在 X 上发布的文章：Using Claude Code: The Unreasonable Effectiveness of HTML。本文完全由有道龙虾翻译和发布。 Markdown 已经成为智能体与我们沟通时最主流的文件格式。它简单、可移植，有一定的富文本能力，也很容易让你编辑。Claude 甚至已经非常擅长在 Markdown 文件里用 ASCII 画图。 但随着智能体变得越来越强，我开始觉得 Markdown 变成了一种限制性格式。超过一百行的 Markdown 文件对我来说就很难读。我想要更丰富的可视化、颜色和图表，而且希望它们能轻松分享。 我也越来越少亲自编辑这些文件，而是把它们当作规格说明、参考文件、头脑风暴结果等来使用。即便我确实要修改，通常也是让 Claude 去改，这就削弱了 Markdown 最大的优势之一。 我已经开始更偏好用 HTML 作为输出格式，而不是 Markdown。我也越来越常看到 Claude Code 团队的其他人这么做。下面是原因。 如果你想先看一些例子，可以看这里：html-effectiveness，但记得回来继续读为什么。 为什么是 HTML？ 信息密度 相比 Markdown，HTML 能传达丰富得多的信息。它当然可以表达简单的文档结构，比如标题和格式，但它还可以表示各种其它信息，例如： 用表格表示表格数据 用 CSS 表示设计数据 用 SVG 表示插图 用 script 标签表示代码片段 用 HTML 元素、JavaScript 和 CSS 表示交互 用 SVG 和 HTML 表示工作流 用绝对定位和 canvas 表示空间数据 用 image 标签表示图片 我甚至会说，几乎没有 Claude 能读懂、但你无法用 HTML 相对高效表达的信息集合。这让 HTML 成为模型向你传达深度信息、并让你审阅这些信息的一种非常高效的方式。...

本文整理自 GPT-5 发布后，A16Z 对 OpenAI 研究员 Isa Fulford 和 Christina Kim 的专访，以下为原视频精华。 就在 OpenAI 最新一代模型（视频中称为 GPT-5）发布的当天，我们有幸与两位身处风暴中心的关键人物——Christina 和 Issa 聊了聊。她们分别负责核心模型的后训练（Post-training）和 ChatGPT Agent 团队的深度研究。 这场对话没有官方辞令，更像是一次坦诚的幕后分享。她们不仅揭示了新模型在编码、写作等方面实现巨大飞跃的秘密，也分享了 OpenAI 独特的工作哲学、对 AI 未来的思考，以及那些不为人知的开发故事。 一、不止是“更聪明”，更是“更好用”：GPT-5 带来了什么？ 当被问及新模型的反响时，Christina 兴奋地表示，除了评测数据（eval numbers）非常亮眼，她更激动的是模型在实用性上的巨大提升，尤其是在她个人最常用的两个领域： 编码能力的大飞跃：这几乎是所有内部测试人员的共识。新模型被誉出口的“市场最佳编码模型”，尤其在前端开发上，简直是“完全提升了一个档次”。发布会上的演示，几分钟就生成一个功能完善、设计美观的前端应用，而这样的工作量，对一个开发者来说可能需要一周。这背后的秘密？Christina 坦言，没什么魔法，就是团队“真的非常、非常在乎（really cared about）”把编码做好，从搜集最好的数据，到打磨模型的审美，每一个细节都倾注了心血。 触动人心的写作能力：Issa 形容新模型的写作能力“非常温柔和感人（very tender and touching）”。它不再是那个只会堆砌华丽辞藻的“过分热情”的助手，而是能理解并表达细腻情感的伙伴。Christina 在直播中演示用它来起草一篇悼词，这种需要深度情感共鸣的任务，模型也能出色完成。对于像她这样自认不擅长写作的人来说，这无疑是一个强大的工具，无论是写一封重要的邮件，还是一条简单的 Slack 消息。 这个新模型，似乎正在把“点子大王”（the ideas guy）的时代变为现实。你不必再受限于技术实现能力，只要有好想法，通过简单的提示词，一个功能齐全的应用就能诞生。这无疑为独立开发者和初创公司打开了全新的想象空间。 二、后训练的“艺术”：我们如何塑造模型的“品味”与行为？ 一个强大的模型不仅仅是聪明，它的“性格”和行为方式同样重要。过去模型出现的“阿谀奉承”（sycophancy）等问题，在新模型的开发中得到了重点关注。 Christina 将后训练形容为“一门艺术”。团队需要在一系列目标之间做出权衡和取舍，就像一位艺术家在调色盘上寻找完美的平衡。 “你希望AI助手非常乐于助人、引人入胜，但如果‘太’引人入胜，就可能变得过于谄媚。这就像一个平衡木，你要想清楚，我们到底希望这个模型给人什么样的感觉。” 减少“胡说八道”的秘诀 对于幻觉（hallucinations）和欺骗（deception）问题，团队发现，这往往源于模型“急于表现”的心态。之前的模型为了“乐于助人”，有时会不假思索地“脱口而出”一个答案。 而新模型的改进，很大程度上归功于**“思考”能力的引入**。当模型能够进行“一步一步的思考”（step-by-step thinking）时，它就像有了一个暂停和反思的机会，而不是急着给出答案。这种机制显著降低了产生幻觉的概率。 有趣的是，当内部员工测试新模型时，有时反而会感到一丝“被冒犯”，因为他们提出的难题，模型可能只“思考”了两秒钟就轻松解决了。 三、数据、数据、还是数据：推动AI进步的核心燃料 当被问及模型能力的提升主要来自架构、数据还是规模时，Christina 毫不犹豫地回答：“我坚定地站在‘数据派’（data-pilled）这边。” 她认为，高质量的数据是决定模型上限的关键。尤其是在强化学习（Reinforcement Learning）的框架下，好的数据能让模型以极高的效率学会新能力。 这个观点也解释了 OpenAI 内部的协作模式： 从能力倒推，创造评测标准：团队会先定义希望模型拥有的能力（比如制作幻灯片、编辑电子表格），如果现有的评测标准（evals）无法衡量，他们就会自己创造新的、能代表用户真实需求的评测标准。 用评测“引诱”大家：Christina 开玩笑说，在 OpenAI 内部，如果你想“引诱”同事来解决一个难题，最好的办法就是创建一个好的评测标准。大家看到明确的目标后，就会兴致勃勃地去“爬山”（hill climb），不断优化。 产品探索反哺核心模型：Issa 的团队在探索 Agent 能力（如深度研究 Deep Research）时，会创建专门的数据集。这些经过验证的、高质量的数据集随后会被贡献给核心模型团队，从而让下一代基础模型直接继承这些新能力，形成一个良性的自增强循环。 四、从 WebGPT 到 AI Agent：未来已来，只是分布尚不均匀 回顾历史，Christina 参与的 WebGPT 项目可以说是 ChatGPT 的前身。最初的目标很简单：让语言模型通过浏览工具来获取事实信息，解决幻觉问题。但他们很快意识到，人们问完一个问题后，通常还会有下一个。这个洞察，最终催生了对话形式的 ChatGPT。...

本文来自于 Anthropic 组织的线下分享会，从时间上看应该是 5 月前组织的线下分享会，里面不仅有 Claude 工程和算法团队的分享，还包括 Google、Amazon、Manus 甚至是创业者和学生的分享，特别值得观看，这里把其中我认为比较优质的视频内容整理出来分享给大家。本篇文章来自于视频 Prompting for Agents，以下为原视频精华。 你可能已经习惯了和AI聊天，让它帮你写邮件、总结文章。但你有没有想过，如何指挥一个AI去独立完成一项复杂任务？比如，只给它一份设计文档，就让它自己写代码、测试、然后提交一个PR（Pull Request）？ 这就是AI智能体（AI Agent）的魔力。它不再是被动的一问一答，而是一个能自主规划、使用工具、并循环往复直到达成目标的“行动派”。 来自Anthropic应用AI团队的专家Hannah和Jeremy，通过一场深入的分享，揭示了如何为这些强大的智能体编写指令（Prompting）。这和我们平时在聊天框里输入问题可大不一样，它更像是在用自然语言进行“编程”。 什么是AI智能体，我什么时候该用它？ 在我们深入探讨Prompt技巧之前，得先搞清楚一个基本问题：到底什么是智能体？ Anthropic给出的定义非常简洁：智能体就是“在循环中持续使用工具的模型”。 想象一下，你给它一个任务，它会： 思考：分析任务，规划步骤。 行动：调用它能使用的工具（比如搜索、读写文件、访问API）。 观察：分析工具返回的结果。 循环：根据新的信息，更新决策，继续思考、行动、观察，直到任务完成。 听起来很酷，但千万别滥用。智能体是为“复杂且有价值”的任务而生的，把它用在所有地方只会事倍功半。那么，什么时候才是智能体大显身手的最佳时机呢？ 你可以用下面这四个问题来判断： 任务足够复杂吗？ 如果你能清晰地列出完成任务的每一步，那你可能只需要一个自动化的工作流，而不是智能体。智能体的用武之地在于那些“你知道目的地，却不清楚具体路线”的场景。比如数据分析，你知道你想要获得某些洞察，但数据本身可能有错误、格式不一，需要智能体在探索中动态调整分析策略。 任务价值够高吗？ 智能体的运行会消耗更多资源。如果任务本身价值不高，用智能体就有点“杀鸡用牛刀”了。相反，如果一个任务能为你创造显著价值（比如直接产生收入，或将工程师从繁琐的编码中解放出来），那智能体就是你的不二之选。 任务的子步骤可行吗？ 智能体需要工具来与世界互动。如果你无法为智能体提供完成任务所需的工具（比如访问特定数据库的API、读写文件的权限），那它也无能为力。在设计任务时，要确保你能为它提供必要的“武器”。 犯错的成本高吗？ 如果一个错误很难被发现，或者一旦出错就造成无法挽回的损失，那么让智能体完全自主工作可能不是个好主意，或许需要加入“人类审核”环节。但如果错误是可恢复的（比如网页搜索结果不佳，再搜一次就行），或者成本很低，那就可以放心地让智能体独立工作。 简单来说，编码、复杂研究、数据分析、需要和电脑桌面交互的任务，都是智能体的绝佳应用场景。 智能体Prompting的核心秘诀 好了，现在我们知道什么时候该用智能体了。接下来，Jeremy分享了他们在构建claude-code（一个在终端里写代码的智能体）和claude.ai高级研究功能时总结出的宝贵经验。这些技巧，才是让智能体从“能用”到“好用”的关键。 1. 像智能体一样思考 这是最重要的原则。你必须设身处地地站在智能体的角度，去理解它的“世界”——也就是它拥有的工具和它能从工具那里得到的回应。如果换作是你，面对同样的工具和信息，你会不会感到困惑？如果一个任务的说明连人都看不懂，AI更不可能明白。 2. 给予合理的“启发式原则” (Heuristics) Prompt工程远不止于文字游戏，它是一种“概念工程”。你需要为智能体灌输一些核心的行为准则。 举个例子：“不可逆性” 在claude-code中，他们教会了模型一个概念叫“不可逆性”，即不要执行任何可能对用户环境造成永久性损害的操作。这个概念需要被清晰地定义，否则一个“过于热情”的智能体可能会误解你的意图，做出超出预期的行为。 另一个例子：设置“预算” 在研究任务中，他们发现模型有时会没完没了地进行网页搜索，即便已经找到了答案。后来，他们在Prompt里加入了一条原则：“当你找到答案后，就可以停止搜索了”，并且给它设定了工具调用次数的“预算”——简单问题用少于5次工具调用，复杂问题可以用10到15次。 把智能体想象成一个刚毕业的实习生，你需要非常清晰地告诉他工作的原则和边界，而不是期望他什么都懂。 3. 工具选择是关键 最新的模型（如 Claude 3.5 Sonnet 和 Opus）可以同时处理上百个工具，但它并不知道在你的特定场景下，哪个工具是首选。你需要在Prompt里明确地指导它。 “在A公司，如果你要找内部信息，应该优先搜索Slack，而不是Google Drive。” 这样的具体指导，远比给一堆工具让模型自己猜要有效得多。另外，尽量避免给模型一堆名字和描述都非常相似的工具，这会把它搞糊涂。最好是将相似的工具合并成一个。 4. 引导它的“思考过程” 不要只是打开模型的“思考”开关（thinking block/chain-of-thought）就完事了。你可以更进一步，引导它如何思考。 规划在前：在执行任务前，让智能体在第一个“思考块”里就规划好整个流程：“这个任务有多复杂？我大概需要调用几次工具？我该去哪里找信息？我怎么判断任务成功了？” 事后反思：模型从工具（比如网页搜索）拿到信息后，默认会认为这些信息都是真的。你可以引导它进行“交错式思考”（interleaved thinking），在两次工具调用之间停下来反思一下：“这个搜索结果可靠吗？我需要交叉验证一下吗？或者我应该在最终报告里加个免责声明？” 5. 预料之外的“副作用” 智能体是自主循环的，所以你对Prompt的任何一个微小改动，都可能带来意想不到的连锁反应。比如，你告诉它“一定要找到最高质量的信源”，结果这个“完美信源”根本不存在，智能体就可能会陷入无限搜索的循环，直到耗尽上下文窗口。因此，你还需要告诉它：“如果几次尝试后找不到完美信源，那也没关系，可以停下来。”...

本文是 Manus 首席科学家 季逸超 ‘Peak’ 在 2025 年 7 月 19 日发表的博客，主要介绍了 Manus 在构建 AI 代理过程中的一些经验教训，深入探讨了“上下文工程”的核心理念与方法。作者认为，对于现代 AI 代理而言，精心设计和管理上下文，比微调模型本身更为关键，它直接决定了代理的性能、成本和可扩展性。 主要观点 上下文工程优于模型微调：在产品快速迭代的背景下，依赖前沿大语言模型的上下文学习能力，通过“上下文工程”来构建 AI 代理，比耗时数周的模型微调更具优势。这使得产品能快速迭代，并与底层模型的进步保持同步。 上下文是代理行为的核心：代理的效率（速度和成本）、鲁棒性（错误恢复能力）和扩展性，最终都取决于上下文的构建方式。如何塑造记忆、环境和反馈，是决定代理智能水平的关键。 构建过程是实验科学：不存在一劳永逸的完美框架。构建高效的代理需要通过不断的实验、试错和迭代（作者称之为“随机研究生下降”），逐步找到最优的上下文管理策略。 关键细节 1. 围绕 KV 缓存进行设计 核心指标：KV-cache 命中率是影响代理延迟和成本的最重要指标。由于代理任务中输入与输出的 token 比例极高（Manus 中约为 100:1），有效利用缓存能带来巨大收益（成本可降低 10 倍）。 实践方法： 保持提示前缀稳定：避免在系统提示的开头加入时间戳等易变内容。 上下文只追加：避免修改历史记录，并确保 JSON 等格式的序列化顺序是确定的。 明确标记缓存断点：在必要时手动插入缓存标记，以优化缓存策略。 2. 工具管理：遮蔽而非移除 问题：在迭代过程中动态增删工具定义，会使 KV-cache 失效，并可能让模型对不再存在的工具感到困惑。 解决方案：使用“遮蔽”策略。通过上下文感知的状态机，在解码时约束模型的输出（logits），阻止或强制其选择特定工具，而不是从上下文中移除工具定义。例如，通过预填充回复来强制模型调用某个或某类工具。 3. 将文件系统作为外部上下文 挑战：即使有 128K 的上下文窗口，在处理网页、文档等大型观测数据时，也容易超出限制、导致性能下降且成本高昂。 解决方案：将文件系统视为一种无限大、可持久化的“终极上下文”。训练代理按需读写文件，将长期记忆和大型数据外部化存储。这种压缩是可恢复的（例如，保留 URL 而非网页全文），既能缩短上下文长度，又不会永久丢失信息。 4. 通过复述操控注意力 问题：在执行包含数十个步骤的复杂任务时，代理容易偏离最初目标（即“迷失在中间”问题）。 解决方案：通过刻意操控注意力来解决。Manus 会创建一个 todo.md 文件，并在任务过程中不断更新它。这种“复述”行为将全局计划推到上下文的末尾，使其处于模型近期注意力的焦点，从而保持任务目标的一致性。 5. 保留错误以促进学习 错误观念：许多开发者倾向于隐藏或擦除代理犯下的错误。 正确做法：将失败的尝试、错误信息和堆栈跟踪保留在上下文中。这为模型提供了宝贵的学习证据，使其能够隐式地更新内部认知，从而避免重复犯错。错误恢复是衡量真正代理能力的关键指标。 6. 避免少样本提示的陷阱 风险：如果上下文中充满了相似的成功案例（少样本示例），模型会倾向于模仿这些模式，即使当前情况已不适用，导致行为僵化或出错。 解决方案：在上下文中引入受控的多样性。通过在行动和观察的序列化模板、措辞或格式上引入微小变化，打破单一模式，帮助模型更好地泛化和适应。 原文： AI代理的上下文工程：构建Manus的经验教训 2025/7/18 – Yichao ‘Peak’ Ji...