🔥 Search Hot Tweets

Anthropic 的工程团队又发表了一篇 AI Agent 相关的技术文章《为 AI 智能体打造高效工具》，他们家的 AI Agent 文章我每篇都会看好几遍，时不时会重翻一下，你想学习如何开发 AI Agent，Anthropic 写的是一定要看 ，毕竟现在最好的 Coding Agent Claude Code 就是他们家的，都是一手经验。 虽然现在很多人在吹 Codex，但我觉得就 Coding Agent 能力来说，目前最强还得是 Claude Code，那为什么 Claude Coding 这么强呢？ 主要归功于两点：Agent 能力强的模型 + 合适的工具 当然很多人会说还有编程能力和上下文工程，但我觉得编程能力现在已经是一线模型的基础能力了，不需要单独拿出来说； 而上下文工程这个更多是个概念，你要真看过 Claude Code 的实现，就会发现它没啥上下文工程，就是把所有会话一股脑发给模型，让模型来决定是继续调用啥工具还是输出最终结果，最多用了 SubAgent 分摊一下上下文，本质上还是模型在帮着管理上下文。 先说模型，现在的大语言模型已经不是简单的聊天模型，，主要分为以下几类： 1. 大模型的聊天能力就是语言能力，能看懂你输入的内容，能输出高质量的文字内容，以 GPT-4o 为代表 2. 推理能力就是字面意思的逻辑推理，通常会借助思维链（CoT，Chain of Thought），在输出内容前先反复推理思考，可以解决复杂的数学问题和编程问题，以 o1、DeepSeek R1 为代表 3. Agent 能力就是模型可以自主制定并执行计划，调用外部工具或资源，自动完成复杂任务，比如现在比较火的 Coding Agent、Deep Research，以 Claude 4 系列模型和 GPT-5 为代表，国内的豆包 Seed 1.6、 DeepSeek V3、GLM 4.5、Kimi K2、Qwen-Coder 都不错。 但这些能力是有些冲突的，所以你会看到 Gemini 2.5 Pro 这样代码能力很强、写作也很强，但是 Agent 能力不强，最终 Gemini CLI 就是能力平平。 然后像 GPT-5、Claude 4，在 Agent 能力上很强，而写作能力就不太好，尤其是 GPT-5，写出来的东西真没法看。 当然未来的趋势还是模型越来越通用，一个模型可以都很强，GPT-5 就在探索这个方向，只是还没做好，但 GPT-6 应该就可以了，现在可以预期一下 Gemini 3.0 和 DeepSeek R2，说不定会有惊喜。 为什么说出了模型之外就是工具的能力呢，因为当模型有了不错的 Agent 能力，这时候就得依赖工具去完成各种任务了，比如检索代码库、读取文件、生成更新TODO、更新代码等等。 就好比一个人，有了趁手的工具就能事半功倍，否则空有一身本事也使不上力。 所以你看 Claude Code，即使接入的不是 Claude 的模型，而是国产的有 Agent 能力模型，一样能干的挺好，毕竟它针对 Coding 这个场景设计的十几个工具，组合起来就能高效完成几乎所有的编程任务。 所以回头看《为 AI 智能体打造高效工具》这篇文章，里面特地强调了高效工具的五个核心原则： 1. 谨慎选择工具 工具不是越多越好，Claude Code 的工具数量一直被控制在20个以内，通常在15个左右，这里有两个原因：1). 工具越多，占用上下文空间越大；2). 工具多了 AI 反而不知道该选什么工具 所以你要是看到有人推荐你安装一大堆 MCP 工具或者一大堆 Sub Agent，那多半是不靠谱的 2. 清晰的命名空间 当你的工具多了以后，给工具的名字加上命名空间能够显著降低大模型犯错概率，帮助其准确调用。之前 Manus 有一篇《AI 智能体的上下文工程：构建高效 Agent 的七个宝贵教训》里面也提到类似的技巧，借助统一的前缀为工具分组。 例如，与浏览器相关的工具都以 browser_ 开头，而命令行工具则以 shell_ 开头。 3. 让工具返回更具意义的上下文 工具不应将大量无关信息返回给 Agent，而应只返回高质量、有实际意义的信息。举个例子来说，你让一个工具去根据错误信息帮你 Debug（调试） 代码问题，Debug 过程中检索的搜索结果、读取的文件代码就没必要返回给，只要返回错误信息对应的代码路径和相关代码就好了 4. 优化返回信息的Token效率 上面第 3 条重点说的是工具返回结果的质量，但数量也同样重要。举个 Claude Code 的细节，如果你一个代码文件少于 2000 行（实际可能有出入）， Claude 会直接一次性加载到上下文中，如果超过这个数，那么它就会先调用代码检索工具，从文件中检索出跟上下文相关的一部分代码读取，根据需要可能多次读取，这样就算面对十万行以上的代码文件（我自己测试过），也能正常工作，而不是马上爆掉上下文。 前面提到的 Manus 的那篇文章，也有过类似的分享：将文件系统作为外部上下文，就是把长的内容存到文件系统中，上下文中只保留文件路径，需要的时候再完整读取或者部分读取。 另外还有就是工具在出错时要返回有意义的错误信息，而不是需要额外查询文档的错误代码，简单说就是不止要让模型知道出错了，还要知道错在哪里了，最好是怎么处理错误都一起告诉模型，这样它才能在出错后自己纠错改正。 嗯，Manaus 那篇文章也提到了保留并利用错误信息进行纠错。 5. 通过提示工程提升工具说明的质量 Agent 的所有工具说明和调用参数都会和系统提示词一起发给模型，如果你的工具说明不清晰，那么模型就无法知道工具是用来干嘛的，调用出错的概率会很高，所以工具描述本身也是一种“提示工程”，它决定了大模型如何理解并调用工具。细致明确的工具描述能极大提升大模型对工具调用的准确性。 工具说明的 Prompt 可以让 AI 来帮你写，但你自己还是验证 AI 写的对不对，并且还要反复测试调整。