Cole Medin · 15:52 · 发布 2026-03-26 · 2.6万次观看(截至抓取) · 观看原视频
主旨
针对”框架已死、RAG 已死,以后 agent 都直接建在 Claude Agent SDK 上”的流行说法,Cole 给出更有分寸的判断:batteries-included 的编码 SDK 确实让搭 agent 变得极简,但只对”单人使用、能容忍延迟、不需扩展”的场景成立;要速度、要规模、要控成本的生产 agent 仍应用 Pydantic AI 这类框架从底层搭,选型只需回答”谁用、对速度/规模/成本的容忍度”两个问题。
核心论点
- 建 agent 的旧范式(选框架→定工具→自建 RAG→自管状态)大量场景仍适用,只是正在被 batteries-included SDK 分流,不是被取代。(→ 详解1、2)
- SDK 把 prompting、工具、会话管理、skills、MCP、文件检索全内置,几十行就能搭出比旧 agent 功能更全的 agent,代价是更慢、更烧 token、可控性更差。(→ 详解2、3)
- 多用户生产是 SDK 的成本红线:订阅只允许你本人用,多人用必须换 API key、付离谱费用——这才是”生产 agent 多数仍用框架”的真正原因。(→ 详解4)
- 选型只问两个问题:谁在用、对速度/规模/成本的容忍度;单人+可容忍延迟+不扩展→SDK,多人+生产+要快要扩→框架,先上最简实现、需要扩再迁。(→ 详解5)
- “RAG 已死”是误读:小知识库文件检索确实胜过语义检索,但大知识库语义检索仍更准更便宜,当下共识是 agentic RAG——两种检索都给 agent。(→ 详解6)
知识点详解
1. 旧范式:框架 → 工具 → RAG → agent loop 01:42
2024–2025 年几乎每个 agent 都按同一套流程搭:先挑一个框架(LangChain、n8n、Pydantic AI、OpenAI agents SDK 里选你/团队最顺手的),再定义 agent 的工具(搜文件系统、读收件箱这类能力)。
然后是 RAG:自己设计 chunking、embedding、retrieval 策略,让 agent 能检索知识库——那时几乎每个 agent 都带 RAG。最后接上 agent loop,即 state 与 memory 管理(短期记忆、把对话全部存进数据库)。
Cole 强调这套至今仍常常必要,但要命的是你得亲手写大量 glue code 来搭 agent 基础设施:文档、chunks、messages、sessions 全在自己的数据库里管,复杂度很高。正是这份复杂度把人推向了下一节的 SDK。
2. 新地基:batteries-included 的编码 SDK 03:43
越来越多人改用 Batteries-Included SDK(Claude Agent SDK、Codex SDK),即把非编码 agent 直接建在编码 agent 的地基上。好处是大量 prompting 和工具已内置,会话历史也帮你管好——连”存对话”这步都省了。
它自带 skills 与 MCP servers 支持(给 agent 加能力的两种较新方式),还能配 sub-agents、hooks、权限、自定义 system prompt。Cole 展示整个 agent 就是一个 TypeScript 文件:直接调进 Claude Code、声明允许用的工具即可,代码比旧 agent 更少、功能却更多。
多数这类 agent 甚至不需要 RAG pipeline——直接用 SDK 内置的文件检索;真要用 RAG,也能通过 skills / MCP 补进来。Cole 自己的 second brain(第二大脑)心跳系统就整套建在 Claude Agent SDK 上,能长期积累记忆、每日反思。
3. SDK 的三个硬伤:慢、烧 token、不确定 07:12
batteries-included 也意味着”出厂即臃肿”。第一,SDK 明显比框架慢:内置东西太多带来大量 reasoning overhead——那个 Pydantic AI 版天气查询秒回,同样的事走 SDK 至少要 10 秒。
第二,更烧 token,和”慢”是同一枚硬币的两面——臃肿的内置内容天然吃更多 token。第三,更非确定(non-deterministic):太多东西被替你管好,你没法像框架那样精确定义 agent 怎么运作。
所以凡是对速度、成本或极致灵活性要求高的场景,就该用框架从底层搭——sub-second 响应、连会话历史都自己控。这正与 Harness 那套”你能控制的那层才是价值所在”呼应:SDK 是拿来即用的现成 harness,框架是你自己从零搭的 harness。
4. 成本红线:订阅 TOS 与”框架也能装 skills” 09:01
除速度外,生产 agent 多用框架还有一个更硬的理由:成本。SDK 很烧 token,平时你多半用订阅(Anthropic/OpenAI 订阅)扛——但订阅只在”agent 只有你一个人用”时才合规,多人用即违反平台 TOS。
一旦生产环境多用户,你必须换成 API key、付一笔离谱的 API 费用。所以要规模化又不想烧掉数百万 token,框架更划算。
那”框架是不是缺 skills”?Cole 现身说法:他给一个 Pydantic AI agent 手动加了 skills 支持——同样放 skill.md 目录、用动态 system prompt 告诉 agent”你有哪些 skill 可按需加载”,效果和 Claude Code 一样,却更快更省 token。结论:skills、MCP 这些现代技巧,框架也都能装,只是要多花点搭建功夫。
5. 决策框架:两个问题定生死 12:10
选 SDK 还是 Agent 框架,归结为两问:谁会用你的 agent?你对速度和规模的容忍度是多少?
若只有你自己用、能接受一点延迟、不需要扩展,就用 Claude Agent SDK / Codex SDK——开箱即得大量能力,少操心基础设施。若很多人用、要部署到生产、要能扩要够快,仍走 Pydantic AI / LangGraph 这类框架的经典路子。
原则是先上最简实现。方向通常一开始就很明显;偶尔会先用 SDK 快速验证 skills/MCP 的工具链,等需要扩展时再迁到 Pydantic AI agent——两边都试也行,但用例往往一开始就替你把答案定好了。
6. RAG 没死,只是分化成三态 13:09
2024 年没人质疑 RAG,几乎每个 agent 都靠语义检索取外部信息。2025 年风向变了:大家更依赖文件检索,编码 agent 弃用向量库改用 grep(SDK 把这能力直接内置),Llama Index 的研究也显示小知识库下文件检索胜过 RAG——于是有了”RAG 已死”的说法。
但这里有被忽略的分寸:对上千文档的大知识库,语义检索仍更准、且便宜得多 14:12。企业级 AI 编码、以及多数需要访问知识库的 agent,文件检索并不够用。
2026 年落到一个折中——Agentic RAG 14:17:同时给 agent 语义检索和 grep/关键词检索等多种手段;超大代码库/多代码库项目还流行 Graph RAG。一句话收尾:按用例匹配工具——文件检索是好起点,大库仍得靠语义检索,Cole 的 second brain 就是内置文件检索 + 自建语义检索 RAG 两者并用。
可执行步骤
- 给手上要建的 agent 先答两个问题:谁用、能否容忍延迟/是否需要扩展——单人可容忍且不扩展就先上 SDK,多人生产要快要扩就上框架。
- 若不确定,先用 Claude Agent SDK / Codex SDK 搭最简版本快速验证工具链(skills/MCP),等确实要扩展时再迁到 Pydantic AI / LangGraph。
- 上线前核对成本合规:只要 agent 不止你一个人用,就别再用个人订阅跑,换 API key 并把 API 成本纳入预算。
- 选检索方案按知识库规模定:几十上百文档先用文件检索(grep/关键词),上千文档再上语义检索;两者都要就做 agentic RAG,别默认”必须上向量库”也别默认”RAG 已死”。
关联
- 补充/深化:Harness为王的能动工程大师课 说 Harness 占效果的 90% 且要你自己搭;本片(同为 Cole)补上另一半——batteries-included SDK 其实是一份现成 harness,只有当速度/规模/成本成为约束时才值得自己从零搭框架。
- 印证:Harness为王的能动工程大师课 主张”一个通才 agent + 按需加载 skills”、skills/MCP 是加能力的现代方式;本片进一步指出这套现代技巧在 SDK 和框架里都能用,不是 SDK 专属。
术语
- SDK(Software Development Kit,软件开发工具包;此处特指 Claude Agent SDK、Codex SDK 这类编码 agent 的开发套件)
- Batteries included(电池已含,借喻开箱即用、无需自行组装底层依赖)
- RAG(Retrieval-Augmented Generation,检索增强生成)
- 语义检索 / semantic search(基于向量 embedding 相似度的检索)
- 文件检索 / file search(靠 grep、关键词直接翻文件,而非查向量库)
- MCP(Model Context Protocol,跨厂商的工具/服务接入标准)
- Non-deterministic(非确定性,同样输入不保证同样的运作流程与产出)
- glue code(胶水代码,为把各组件拼起来而写的样板衔接代码)
金句
“For these, everything you thought about building AI agents needs to be thrown out of the window. But then for other use cases, this isn’t true at all.” → 标题的”全错了”只对部分场景成立;真正的答案是分场景选型,而不是一刀切地全押 SDK。
立场与利益
Cole 在片中(约 [09:31] 前后)推销自家 Dynamous 社群的 4 小时”用 Claude Agent SDK 搭 second brain”付费 workshop(4 月 3 日),属社群导流。
不过他反复自陈”我现在还一直在用 Pydantic AI、还在用 Neon Postgres 试各种 RAG 策略”,对 SDK 与框架两边都有一线实操,论述相对中立、不偏袒单一工具。Claude Agent SDK / Codex SDK / Pydantic AI / LangGraph 均为第三方产品,片中未见对它们的独立赞助绑定。
价值定位
面向正在或将要构建 AI agent、想纠正常见误区的人:
- 适合谁:纠结”该用 Claude Agent SDK 这类 SDK 还是 Pydantic AI 这类框架”、且被”框架已死/RAG 已死”说法带偏的人。
- 解决什么:给出一个”两问”决策框架,把选型从跟风改成按”谁用 + 速度/规模/成本容忍度”来判断,并顺带澄清 RAG 现状。
- 认知 vs 实操:以认知框架为主(选型心智 + RAG 三态澄清),落地抓手是那两个问题和”先上最简实现、需要扩再迁”。
- 与 Harness为王的能动工程大师课 重叠(同一博主、都谈 harness 与 skills),但本片独有 SDK-vs-框架的成本/TOS 红线,以及 RAG 三态(文件检索 / 语义检索 / agentic RAG)的澄清。
自检问题
- Cole 说”该用 SDK 还是框架”只需回答哪两个问题? 答案:谁会用你的 agent、你对速度和规模的容忍度是多少;单人+可容忍延迟+不需扩展→SDK,多人+生产+要快要扩→框架。见”知识点详解”第5节。 12:10
- batteries-included SDK 带来极简的同时,有哪三个硬伤? 答案:更慢(reasoning overhead 大)、更烧 token、更非确定(可控性差)。见”知识点详解”第3节。 07:12
- 为什么生产环境多用户时,SDK 会变得不划算? 答案:SDK 很烧 token,平时靠订阅扛,但订阅只在”只有你一人用”时合规;多用户就必须换 API key、付离谱 API 费用。见”知识点详解”第4节。 09:01
- “RAG 已死”错在哪?当下的折中方案是什么? 答案:只有小知识库下文件检索胜过语义检索;上千文档的大库语义检索仍更准更便宜。折中是 agentic RAG——同时给 agent 语义检索和 grep/关键词检索。见”知识点详解”第6节。 14:17
- 若一时拿不准该用 SDK 还是框架,Cole 建议怎么起步? 答案:先上最简实现——常常先用 SDK 快速验证 skills/MCP 工具链,等确实需要扩展时再迁到 Pydantic AI agent。见”知识点详解”第5节。 12:10
💬 热门评论 top-13 主 + 7 回(抓取 2026-07-07)
[2] @pvdyckful:从硬编码工具转向技能，这部分正在改变我的思考方式。以前构建一个代理意味着要自己写所有的胶水代码。现在有趣的问题更多在于如何组合哪些技能以及如何分发它们。框架仍然重要，但在我看来，真正的价值正在转移到它们之上的那一层。 👍 11 [4] @UnchainedSky:关于RAG被质疑的部分很有意思——好奇你觉得它会怎么发展。现在很多代理都有实时浏览功能，所以是把知识内置还是按需获取，这个问题似乎会改变整个架构。 👍 1 [8] @user-uk9ls:像Langchain这样的框架本来就是个混乱的噩梦。不稳定的发布、混乱的核心和社区版本、兼容性问题。像Qwen、OpenCode这样的编码代理为每个人提供了廉价的AI能力。 [11] @chihebdkhil6779:视频整体很棒！不过我会质疑传统代理框架中的确定性行为。 👍 1 ↪ @ColeMedin(UP):谢谢！你能解释一下你的意思吗？ ——其他 8 条:感谢/夸赞([3]@YakWhisper、[5]@nathanielblairofkew1082、[6]@radekberan7674、[7]@dcoderjr、[9]@maxonthetrack、[10]@patrickm9953、[12]@PSmidi、[13]@QuinnFavo);1 条 spam 已略
英文原文
[1] @ColeMedin(UP):If you're interested in building your own AI second brain to save yourself hours every week, check out the Dynamous community and upcoming 4 hour second brain workshop: https://dynamous.ai 👍 6
[2] @pvdyckful:the shift from hardcoded tools to skills is the part thats changing how i think about things. building an agent used to mean writing all the glue code yourself. now the interesting problem is more about which skills to compose together and how to distribute them. frameworks still matter but the layer above them is where the real value is moving imo 👍 11
[3] @YakWhisper:This makes me excited to try out these new agent foundations 👍 1
[4] @UnchainedSky:the part about RAG being questioned is interesting — curious where you see that going. a lot of agents now have live browsing so the question of whether to bake knowledge in vs fetch it fresh on demand seems like it changes the whole architecture 👍 1
[5] @nathanielblairofkew1082:This video was very useful. Thanks! 👍 1
↪ @ColeMedin(UP):I appreciate it, you bet! 👍 1
[6] @radekberan7674:Thank you Cole for this really fitting overview. 👍 1
[7] @dcoderjr:Thanks for adding chapters for reference!!! 👍 3
↪ @ColeMedin(UP):You bet!
[8] @user-uk9ls:Frameworks likeLangchain were a messy nightmare anyway. Instable releases, confusing core and community versions, compatibility problems. Coding agents like Qwen, OpenCode and others offer cheap AI power to everyone.
[9] @maxonthetrack:I finally pulled the trigger and joined dynamous ai, i’m so excited! 👍 1
↪ @ColeMedin(UP):Amazing Max, welcome to Dynamous my friend!
[10] @patrickm9953:Great Video, this was Very Helpful ! 👍 1
↪ @ColeMedin(UP):I appreciate it!
[11] @chihebdkhil6779:Great video overall! However I would question the deterministic behaviour in traditional agentic frameworks 👍 1
↪ @ColeMedin(UP):Thank you! Could you clarify what you mean here?
[12] @PSmidi:Very helpful 🙏🏽👍🏽 👍 1
↪ @ColeMedin(UP):Glad you think so! 👍 1
[13] @QuinnFavo:Subscribed, thanks for making this 👍 1
↪ @ColeMedin(UP):I appreciate it, you bet! 👍 1