Claude Agent SDK 与 Claude Code CLI
Contents
核心发现:SDK 其实是个"中间商"
我大概看了看 Claude Agent SDK 的源代码后,发现了一个有趣的事实:Agent SDK 本质上就是原来的 Claude Code SDK,而它的工作方式出人意料地简单——它只是帮你"翻译"指令,然后启动 CLI 来干活。
用更具体的比喻来说:
- CLI(命令行工具) 就像直接拨号——简单直接,立刻接通
- Agent SDK 则像通过App拨号——你先要启动App,App再帮你拨号,多了一层转手
它是怎么工作的?
当你调用 Agent SDK 时,背后发生了这样的事情:
- 寻找工具: SDK 首先在你的系统中找到 CLI 程序(那个真正干活的"技工")
- 启动子进程: 把 CLI 作为一个子进程启动起来
- 翻译指令: 通过一个叫
_build_command的方法,把你的高级命令翻译成 CLI 能理解的命令行参数 - 管道通信: 通过标准输入输出(stdin/stdout)这种"管道",让 SDK 和 CLI 之间能够对话
说白了,它们用的是同一套底层技术,只是包装方式不同。
那到底该用哪个?
如果你的任务很简单…
比如你要解析一份招标文件——这是个"一次性交易",给它文件,它给你结果,结束。
在这种场景下:
- 直接用 CLI (
claude -p命令) 更快——就像直接拨号 - 用 Agent SDK 的
query()方法会多一个"初始化开销"——就像你要先打开App,等它加载,然后才能让它帮你拨号
这额外的步骤在简单任务中就是纯粹的绕弯子。
如果你的需求更复杂…
但如果你的项目涉及:
- 多个工具协作(需要内部启动 MCP 服务)
- 多角色配合(定义多个 subagent,像搭建团队一样)
- 持续对话(不是一问一答,而是需要多轮交互)
这时候 Agent SDK 就显出优势了。它提供的 ClaudeSDKClient 类就像一个完整的"通讯录管理系统",虽然启动慢一点点,但能让你更方便地管理复杂的通话流程、群组通话、转接等功能。
资源消耗呢?
对于大多数普通任务,两者的资源消耗差别不大。但 SDK 确实会多一个 Python 运行时的开销——毕竟你要先启动那个"APP"。不过在复杂场景下,这点开销换来的便利性是值得的。
所以呢?
这个发现的真正价值在于:它让我们明白了工具的本质。
SDK 不是什么神秘的黑科技,它只是一层更友好的"包装"。如果你的需求简单直接,别被华丽的包装迷惑,直接用最简单的方式往往是最高效的。但当你需要构建复杂系统时,这层包装提供的便利就很重要了。
选择工具的智慧,不在于追逐最新最复杂的,而在于根据实际需求,选择最合适的。有时候,直接拨号就够了;有时候,你确实需要那个功能丰富的通讯录App。