AI Agent

本文翻译自 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...

AI Agent（智能体）是一种能够自主为用户完成任务的人工智能系统。与传统软件只能按照程序员预先设定的流程执行步骤不同，AI Agent 可以在较大自主性下替用户完成复杂的工作流。简单来说，如果将大型语言模型（LLM）比作Agent的大脑、各种外部工具比作Agent的手脚、预先设定的指令比作Agent的行为准则，那么AI Agent就是结合了大脑 + 手脚 + 行为准则，可以自主执行一系列操作的智能助手。 一个工作流指为达到用户某个目标需要执行的一系列步骤，例如解决客户服务问题、预订餐厅、提交代码变更或生成报告等。在没有Agent时，这些流程往往需要用户亲自一步步操作，或者由传统软件按照固定规则自动化。而AI Agent的特别之处在于：它能够独立地代表用户完成这些工作流。这意味着Agent可以自己决定执行哪些步骤、何时停止、如何纠正错误，就像一位能够自主行动的数字助理。 **AI Agent ≠ 普通聊天机器人。**需要注意的是，使用LLM并不自动等同于构建了Agent。例如，一个只回答单轮问答的聊天机器人、情感分析器或者简单的信息抽取脚本，并没有让LLM去控制整个任务流程，因此在OpenAI的定义中并不算Agent。相反，真正的AI Agent能够根据用户目标，连续地进行“思考”和行动：调用LLM规划决策，借助工具与外界交互，在多轮循环中逐步逼近目标。这种自主决策与执行能力，正是AI Agent区别于普通自动化或传统软件的关键。 AI Agent 适合解决哪些问题？ 并非所有自动化场景都适合引入AI Agent。一般来说，Agent更擅长处理传统方法难以解决的复杂工作流 。以下几类问题特别适合考虑使用Agent： 复杂决策流程： 当工作流中包含大量需要上下文判断、动态决策的步骤时（例如客服场景中的退款审批，需要根据用户历史、政策细则做细致判断），LLM 驱动的Agent更擅长处理各种意外和边缘情况 。Agent可以根据不同情境做出灵活判断，而不是依赖预先写死的规则。 规则繁多且难维护： 某些系统的业务规则异常复杂且经常变化，用传统编程实现非常繁琐（比如供应商合规审查涉及成百上千条规则）。此时Agent可以通过自然语言理解这些规则描述，减少人工硬编码的负担。当规则修改时，只需调整指令或提供新文档给Agent理解，比改动大量代码更高效。 非结构化任务&多轮交互： 如果流程严重依赖非结构化数据（如自由文本的文件、对话），或者需要与用户进行多轮对话澄清信息，那么Agent的能力会非常有用。例如处理保险理赔时，Agent可以阅读用户提供的说明和证据文件，与用户反复交谈核实细节，这是传统软件难以做到的。 相反，如果你的场景流程清晰、规则简单且稳定，那么传统的确定性方案可能已经足够。没必要为了“Agent”而强行引入复杂性。换言之，AI Agent最能体现价值的是那些高度复杂、多变、需要智能判断的场景，而非任何自动化都要用LLM来大材小用。 构建 AI Agent 的三大组件 要构建一个AI Agent，无论简单还是复杂，都离不开以下三大核心组件：模型、工具和指令 。它们分别对应了Agent的“大脑”、“手脚”和“行为准则”，共同决定了Agent能做什么以及如何行动。 模型 首先是选择合适的**大型语言模型（LLM）**作为Agent的大脑。模型提供了Agent理解上下文、推理决策的智能基础。OpenAI在指南中给出的模型选型策略非常务实：先使用能力最强的模型构建原型，再逐步优化 。 具体做法是：一开始直接用当前最先进的模型（例如GPT-4）来搭建Agent的核心逻辑，以此测试Agent在理想条件下能达到的效果上限 。有了这个“天花板”基准后，再考虑在某些步骤换用更小、更快或更便宜的模型（比如精简版的GPT-4或GPT-3.5等），评估性能是否仍能满足需求。通过这种渐进替换，逐步降低成本和延迟，同时确保关键步骤的智能水平不受影响。在模型选型中，要时刻权衡任务复杂度、响应速度和成本，找到最佳平衡点。 工具 工具是Agent与外部世界交互的桥梁，相当于Agent可以使用的“手”和“脚”。通过工具，Agent才能超越语言输出，真正对外执行动作、获取信息。例如，Agent可以调用外部API查询数据库，读取PDF文件内容，发送邮件，甚至操作用户界面的模拟点击等。没有工具，Agent只能“纸上谈兵”；借助工具，Agent才能影响真实世界的状态。 OpenAI将工具大致分为三类： 数据类工具（Data）： 用于获取执行任务所需的信息和上下文，例如数据库查询、网页搜索、读取文档等。这类工具让Agent能获得知识和数据支撑。 行动类工具（Action）： 用于对外部系统执行具体操作，从而改变外部状态，比如发送通知、下单、更新数据库记录等。Agent通过这些工具实现实际的任务执行。 编排类工具（Orchestration）： 特殊的一类工具，其中一个Agent本身可以被封装成工具，供另一个Agent调用。这为多Agent协作提供了机制（后面会详细介绍），例如一个“主管”Agent可以把特定任务交给封装成工具的“专家”Agent去完成。 在设计工具接口时，指南强调要遵循标准化定义、清晰文档、充分测试和可复用的原则。也就是说，每个工具的功能、输入输出要定义明确，附带良好的使用文档，并经过严格测试。这有助于Agent正确识别和调用工具，也方便团队复用工具避免重复造轮子。此外，尽量赋予工具有限且安全的能力边界——例如只读查询 vs 修改操作要区分——以免Agent滥用工具导致风险。 指令 指令（又称 Prompt 或提示）是赋予Agent行为准则和角色定位的关键。高质量的指令对于Agent的表现至关重要，甚至比普通LLM应用更为重要。指令定义了Agent的目标、步骤和应遵循的规范，相当于对Agent的“工作说明书”。 编写Agent指令的最佳实践包括： 参考现有文档： 充分利用你已有的标准操作流程（SOP）、客服脚本、政策文件等资源，把这些内容转化为LLM可理解的指令。现成的业务文档是极好的素材，可以确保指令专业且符合业务要求。 拆解复杂任务： 将冗长复杂的任务拆分成一系列更小、更明确的步骤。每一步聚焦一个子任务，便于模型逐步执行，也降低出错概率。例如，不要让Agent“一步完成客户投诉处理”，而是拆成“1. 获取用户信息；2. 查找订单记录；3. 根据政策决定补偿措施；4. 回复用户”等等。...

本文围绕 AI agents（人工智能代理） 的定义、发展历程、核心组件、特性及其在现代应用中的价值展开探讨。AI agents 是一种结合人工智能和代理特性，具备环境感知、自主决策、工具使用以及目标导向行为的计算实体。其演化路径从传统基于规则的聊天机器人，到以大语言模型（LLM）为核心的生成式 AI 系统，再到结合检索增强生成（RAG）技术的复杂代理系统。AI agents 的出现标志着现代 AI 应用从简单交互向复杂、多功能系统的转变，并在生产力提升、决策支持和降低技术门槛等方面展现了巨大潜力。 AI agents 的定义与核心特性 定义：AI agents 是一种具备环境感知能力的计算实体，通过感知（输入）、行动（工具使用）和认知（基于 LLM 的推理与规划）实现自主决策和目标导向行为。 核心特性： 自主性：无需外部指令即可根据内部处理结果或外部观察采取行动。 交互性：与人类、其他代理或系统交互，能够根据上下文调整行为。 反应性与主动性：能对环境变化做出动态响应，同时通过推理与规划主动执行任务。 迭代性：通过反馈不断优化执行步骤，适应复杂任务。 AI agents 的发展历程 传统聊天机器人： 基于规则（如“如果…则…”逻辑）和预定义响应。 功能有限，需人工介入完成复杂任务。 LLM 驱动的聊天机器人： 引入生成式预训练变换器（GPT）模型，具备生成类人文本的能力。 克服了传统聊天机器人的局限，但存在个性化不足和“幻觉”（生成错误信息）问题。 RAG（检索增强生成）聊天机器人： 结合外部数据检索与 LLM 的内在知识，生成更准确和上下文相关的响应。 通过提示工程（Prompt Engineering）优化模型输出，如链式思维（CoT）和 ReAct 技术。 AI agents 的出现： 随 LLM 的参数规模增长，出现推理、多步规划和工具调用等能力。 结合工具使用、环境感知和迭代执行，形成具备高度自主性的复杂代理系统。 AI agents 的核心组件 大脑（Brain）： 基于 LLM 提供推理、规划和决策能力。 包括记忆模块（存储历史交互）、角色模块（基于描述模拟特定行为）和知识模块（存储领域相关信息）。 行动（Action）： 通过工具使用或功能调用完成任务。 能分解任务为多个步骤，并动态决定工具的使用时机。 感知（Perception）： 处理环境输入（如文本、图像或语音），为决策提供信息。 AI agents 的价值与影响 生产力提升：通过自动化重复性任务（如审批、文档处理），减少人工干预。 决策支持：基于规则和指导方针辅助企业工作流中的决策。 降低技术门槛：通过自然语言和图像驱动的界面，使非技术用户更容易与系统交互。 多样化应用场景：从代码生成到内容创作，再到企业流程优化，AI agents 展现了广泛的应用潜力。 当前行业努力方向 可靠性：解决 LLM 的“幻觉”问题，确保输出准确性。 可扩展性：优化模型性能以应对不断增长的数据和计算需求。 性能提升：通过更强大的工具和工作流编排提高系统效率。 MongoDB 的支持： 提供长期数据管理（如对话历史存储）、向量数据库功能和可扩展数据存储，为 AI agents 提供基础设施支持。 AI agents 的未来展望 代理性（Agentic）：AI 系统的分类基于其代理特性（如自主性、环境交互能力和目标导向行为）的强弱程度。 灵活性与适应性：AI agents 的发展可能模糊简单 AI 系统与复杂代理系统之间的界限。 行业影响与价值实现 生产力提升：通过自动化简化企业工作流。 用户友好性：降低技术复杂性，赋能普通用户。 企业决策支持：通过规则驱动的 AI 代理简化复杂流程。 MongoDB 的技术支持 长时数据管理：存储和检索对话历史，保持上下文。 向量数据库：支持语义搜索和 AI 工作负载。 可扩展存储：满足不断增长的数据需求。 原文 什么是 AI 智能体 (AI Agent)？...