--- source_url: "https://x.com/bcherny/status/2017824286489383315\n\n作为一个被" ingested: 2026-06-26 sha256: 50f088843040c541 --- sha256: d13773c3f1e84f2e --- title: "Claude Code 开发负责人最近又发了一条 X：为何放弃 RAG 而选择 Agentic Search\n\n大意是这样的：早期版本的 Claude Code 也使用 RAG 算法加上本地向量数据库，但我们很快发现，Agentic Search 通常效果更好。它也更简单，并且不存在安全性、隐私性、数据过时性和可靠性方面的问题。\n\n原文：https://x.com/bcherny/status/2017824286489383315\n\n作为一个被 RAG 毒打过的人，我是深有感触的。\n\n数据处理和维护问题、生成结果不可控、复杂问题推理难等一大堆问题。\n\n虽然都有对应的调优方法，我自己也用 RAG 也做了很多不错的实践，但是调优过程太痛苦了。\n\n所以我之前也在尝试用 Agent 来做知识检索，但是只能在定制项目中使用，无法通用化。\n\n所以 Skills 出来之后，我立马就想做做一个专门用于知识库检索的 Skill，于是有了这篇教程：\n\n使用 Agent Skills 做知识库检索，能比传统 RAG 效果更好吗？\n\n但有些信息需也要补充下，我认为这种模式并不能完全替代 RAG，\n\nAgentic Search 在复杂问题（需要推理）上的检索效果确实要更好，\n\n但是在一些简单问题上就要比 RAG 更慢、更消耗 Token。\n\n它只是为大家提供了一种新的可尝试的思路，如果在你的业务场景已经把 RAG 用的非常好，那没必要折腾了，\n\n但是如果你还在经历着痛苦的调优阶段，不妨尝试一下。\n\nAgentic Search（此处指纯本文检索）和 RAG 本身也不是一对矛盾体，\n\n它们也可以结合起来用，也就是 Agentic RAG：\n\n让多个不同领域的 RAG 检索作为 Tools，让 Agent 决定如何检索，以及是否要进行多轮检索，这种方案也可以调出非常不错的效果。\n\n对此大家怎么看呢？投个票？也欢迎在评论区留下你的想法。" source_url: https://mp.weixin.qq.com/s/Bdl84IPR6Nko1jSRyfEzbg source: wechat publish_date: 2026-02-04 tags: [wechat, article, claude, agent, rag] review_value: 7 review_confidence: 7 review_recommendation: neutral ingested: 2026-05-16 sha256: 0eade26bd26fc12fd527954f661a0cc61c658aa242146470f3ac6ecb328f20cd --- # Claude Code 开发负责人最近又发了一条 X：为何放弃 RAG 而选择 Agentic Search\n\n大意是这样的：早期版本的 Claude Code 也使用 RAG 算法加上本地向量数据库，但我们很快发现，Agentic Search 通常效果更好。它也更简单，并且不存在安全性、隐私性、数据过时性和可靠性方面的问题。\n\n原文：https://x.com/bcherny/status/2017824286489383315\n\n作为一个被 RAG 毒打过的人，我是深有感触的。\n\n数据处理和维护问题、生成结果不可控、复杂问题推理难等一大堆问题。\n\n虽然都有对应的调优方法，我自己也用 RAG 也做了很多不错的实践，但是调优过程太痛苦了。\n\n所以我之前也在尝试用 Agent 来做知识检索，但是只能在定制项目中使用，无法通用化。\n\n所以 Skills 出来之后，我立马就想做做一个专门用于知识库检索的 Skill，于是有了这篇教程：\n\n使用 Agent Skills 做知识库检索，能比传统 RAG 效果更好吗？\n\n但有些信息需也要补充下，我认为这种模式并不能完全替代 RAG，\n\nAgentic Search 在复杂问题（需要推理）上的检索效果确实要更好，\n\n但是在一些简单问题上就要比 RAG 更慢、更消耗 Token。\n\n它只是为大家提供了一种新的可尝试的思路，如果在你的业务场景已经把 RAG 用的非常好，那没必要折腾了，\n\n但是如果你还在经历着痛苦的调优阶段，不妨尝试一下。\n\nAgentic Search（此处指纯本文检索）和 RAG 本身也不是一对矛盾体，\n\n它们也可以结合起来用，也就是 Agentic RAG：\n\n让多个不同领域的 RAG 检索作为 Tools，让 Agent 决定如何检索，以及是否要进行多轮检索，这种方案也可以调出非常不错的效果。\n\n对此大家怎么看呢？投个票？也欢迎在评论区留下你的想法。 Claude Code 开发负责人最近又发了一条 X：为何放弃 RAG 而选择 Agentic Search 大意是这样的：早期版本的 Claude Code 也使用 RAG 算法加上本地向量数据库，但我们很快发现，Agentic Search 通常效果更好。它也更简单，并且不存在安全性、隐私性、数据过时性和可靠性方面的问题。 原文：https://x.com/bcherny/status/2017824286489383315 作为一个被 RAG 毒打过的人，我是深有感触的。 数据处理和维护问题、生成结果不可控、复杂问题推理难等一大堆问题。 虽然都有对应的调优方法，我自己也用 RAG 也做了很多不错的实践，但是调优过程太痛苦了。 所以我之前也在尝试用 Agent 来做知识检索，但是只能在定制项目中使用，无法通用化。 所以 Skills 出来之后，我立马就想做做一个专门用于知识库检索的 Skill，于是有了这篇教程： [ 使用 Agent Skills 做知识库检索，能比传统 RAG 效果更好吗？ ]() 但有些信息需也要补充下，我认为这种模式并不能完全替代 RAG， Agentic Search 在复杂问题（需要推理）上的检索效果确实要更好， 但是在一些简单问题上就要比 RAG 更慢、更消耗 Token。 它只是为大家提供了一种新的可尝试的思路，如果在你的业务场景已经把 RAG 用的非常好，那没必要折腾了， 但是如果你还在经历着痛苦的调优阶段，不妨尝试一下。 Agentic Search（此处指纯本文检索）和 RAG 本身也不是一对矛盾体， 它们也可以结合起来用，也就是 Agentic RAG： 让多个不同领域的 RAG 检索作为 Tools，让 Agent 决定如何检索，以及是否要进行多轮检索，这种方案也可以调出非常不错的效果。 对此大家怎么看呢？投个票？也欢迎在评论区留下你的想法。 关闭 __ **** 更多 __ __ __ 名称已清空 **微信扫一扫赞赏作者** 喜欢作者 [ 其它金额 ](<>) __ 赞赏后展示我的头像 作品 暂无作品 喜欢作者 其它金额 ¥ 最低赞赏 ¥0 确定 __ 返回 __ **其它金额** 更多 __ __ __ 赞赏金额 ¥ 最低赞赏 ¥0 1 2 3 4 5 6 7 8 9 0 . __ 北京 , 2026年2月4日 20:43