Claude Agent SDK 上手指南:用 Python/TypeScript 构建真正能干活的 AI Agent
最近 Anthropic 悄悄放出了 Claude Agent SDK,我花了一天时间折腾了一下,发现这玩意儿跟我之前用过的 LangChain、CrewAI 完全不是一回事。简单说,它把 Claude Code 的核心能力——读文件、跑命令、编辑代码、搜索网页——全部打包成了一个可编程的库。你不用自己实现工具调用的逻辑,SDK 帮你搞定了。
这篇文章记录一下我的上手过程、踩过的坑,以及跟其他 Agent 框架的对比。如果你正在考虑用 Claude 构建自动化 Agent,这篇应该能帮你少走一些弯路。
Claude Agent SDK 是什么东西
先说清楚它不是什么。它不是另一个 LangChain,不是另一个 CrewAI,也不是另一个 AutoGen。
Claude Agent SDK 的定位很明确:把 Claude Code 的能力以库的形式暴露出来。Claude Code 本身是一个终端里的 AI 编程助手,能读代码、改代码、跑测试、搜索网页。Agent SDK 就是把这些能力用 Python 或 TypeScript 包装了一下,让你可以在自己的程序里调用。
核心区别在哪?LangChain 这类框架需要你自己定义工具(tool),然后让 LLM 决定调用哪个。Agent SDK 不一样——它内置了工具。Read、Write、Edit、Bash、Glob、Grep、WebSearch、WebFetch,全都有了。你不需要写 def read_file(path): ... 这种东西,直接就能用。
这意味着什么?意味着你写一个能自动修 bug 的 Agent,核心代码可能就 20 行。
安装和快速上手
安装很简单。Python 版需要 3.10+,TypeScript 版需要 Node.js 18+。
Python 的装法:
| 1 | |
或者用 uv(推荐,速度快):
| 1 | |
TypeScript 的:
| 1 | |
装好之后,你需要一个 Anthropic 的 API Key。去 platform.claude.com 注册就行。
我第一次跑的时候犯了个低级错误——没设置环境变量,直接报了个认证失败。记得先 export:
| 1 | |
最小可运行示例
创建一个有 bug 的 Python 文件 utils.py:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
这两个函数都有问题:calculate_average([]) 会除零报错,get_user_name(None) 会 TypeError。
然后写 Agent 代码 agent.py:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
跑一下:
| 1 | |
你会看到 Agent 自动读取 utils.py,分析代码逻辑,然后直接编辑文件加上错误处理。整个过程不需要你手动干预。
跑完之后再看 utils.py,已经变成这样了:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
说实话,第一次看到这个效果的时候我有点震惊。不是因为 Claude 能修 bug——这谁都能做到。而是因为它自己决定了要读哪个文件、要改哪些地方、要怎么改。整个 tool loop 是 SDK 在背后编排的,你只管给一个 prompt。
内置工具详解
Agent SDK 内置的工具是它最大的卖点。不用自己实现,开箱即用:
- Read:读取工作目录下的任意文件
- Write:创建新文件
- Edit:精确编辑已有文件(不是全文重写,是 targeted edit)
- Bash:跑终端命令、脚本、git 操作
- Monitor:监控后台脚本的输出,每一行都作为一个事件触发
- Glob:按模式查找文件(比如
**/*.ts、src/**/*.py) - Grep:正则搜索文件内容
- WebSearch:搜索网页获取最新信息
- WebFetch:抓取并解析网页内容
- AskUserQuestion:向用户提问,支持多选
这些工具不是摆设。举个实际例子,我让 Agent 帮我找项目里所有的 TODO 注释:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
Agent 会先用 Grep 搜索 TODO,然后用 Read 打开每个文件确认上下文。整个流程完全自动。
工具组合的威力
单独用某个工具没啥意思,组合起来才有威力。比如这个场景:我要给一个 Python 项目加类型注解。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
Agent 会按这个流程一步步执行:先找文件,再读文件,再加类型注解,再跑 mypy,再修错误。如果 mypy 报了新的错误,它会自动迭代修复。这个循环是 Agent SDK 自己管理的,不需要你写 while loop。
权限控制:别让 Agent 把你的服务器搞炸
这是我觉得最需要认真对待的部分。Agent 有 Bash 工具,意味着它能跑任意命令。如果不加控制,它可能会执行 rm -rf / 这种操作(虽然概率很低,但不是零)。
Agent SDK 提供了几种权限模式:
- acceptEdits:自动批准文件编辑和常见的文件系统命令,其他操作需要确认。适合本地开发。
- dontAsk:不在
allowed_tools里的全部拒绝。适合无头 Agent。 - auto(仅 TypeScript):用一个模型分类器自动判断每个工具调用是否安全。有安全护栏的自主 Agent。
- bypassPermissions:全部放行。只在沙盒环境或完全信任的场景下用。
- default:需要你提供
canUseTool回调来处理审批。自定义审批流程。
我一开始用的是 bypassPermissions,图省事。后来发现 Agent 在跑 Bash 命令的时候执行了一些我不期望的操作(比如它自己决定要 pip install 一个包),赶紧换成了 acceptEdits。
建议:本地开发用 acceptEdits,CI/CD 里用 bypassPermissions(前提是你的 CI 环境是隔离的),生产环境用 default + 自定义回调。
allowed_tools 精细控制
除了权限模式,你还可以用 allowed_tools 精确控制 Agent 能用哪些工具:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
我个人的习惯是:最小权限原则。能只给 Read 就不要给 Bash。需要跑测试的时候再加 Bash,但同时加上 Hooks 做审计(下面会讲)。
Hooks:Agent 的生命周期钩子
Hooks 是 Agent SDK 的另一个杀手级特性。它让你可以在 Agent 执行的关键节点插入自己的代码。
可用的 Hook 事件:
- PreToolUse:工具调用之前。可以拦截、修改参数、或者直接拒绝。
- PostToolUse:工具执行之后。可以记录日志、修改返回结果。
- Stop:Agent 停止执行时。可以保存状态。
- SubagentStart / SubagentStop:子 Agent 的生命周期。
- Notification:Agent 状态消息。可以转发到 Slack 或者其他通知系统。
实战:用 Hook 阻止危险操作
我写了一个 Hook 来阻止 Agent 编辑 .env 文件(防止泄露密钥):
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
| 19 | |
| 20 | |
这样 Agent 尝试编辑 .env 文件时会被直接拦截,同时返回一个友好的拒绝理由。
实战:用 Hook 记录所有文件修改
审计需求很常见——你想知道 Agent 到底改了哪些文件:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
这个 Hook 会把每次文件修改都记录到 audit.log,包括工具名、文件路径和调用 ID。出了问题可以回溯。
Subagents:让 Agent 自己派活
Subagents 是 Agent SDK 的高阶特性。主 Agent 可以生成子 Agent 来处理子任务,子 Agent 完成后把结果汇报给主 Agent。
这个概念跟 Hermes Agent 的 delegate_task 很像。主 Agent 负责拆解任务和汇总结果,子 Agent 负责具体执行。
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
| 19 | |
| 20 | |
| 21 | |
| 22 | |
| 23 | |
| 24 | |
| 25 | |
| 26 | |
| 27 | |
主 Agent 会先派 code-reviewer 去审查代码,拿到审查结果后再派 test-writer 去写测试。整个过程自动编排。
Subagents 的注意事项
踩过一个坑:子 Agent 的 allowed_tools 一定要单独配置。我一开始忘了给子 Agent 加 Bash,结果 test-writer 写了测试但跑不了。子 Agent 不会继承主 Agent 的工具列表,必须显式指定。
另一个注意点:子 Agent 的消息里会带 parent_tool_use_id 字段,你可以用这个来追踪哪个子 Agent 在做什么。调试的时候很有用。
Sessions:跨对话保持上下文
默认情况下,每次调用 query() 都是一个全新的对话。但有些场景需要跨多次调用保持上下文——比如一个长时间运行的任务,中间可能需要暂停和恢复。
Agent SDK 的 Sessions 功能解决了这个问题:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
第二次调用时,Agent 记得之前分析过什么,不需要重新读文件。Session 数据以 JSONL 格式存在本地文件系统上。
这个功能在构建多轮对话 Agent 时特别有用。比如你做一个代码助手,用户可能分多次提问:"帮我看看这个文件" → "把那个函数改一下" → "跑一下测试"。每次都要保持上下文。
MCP 集成:连接外部系统
如果你用过 MCP(Model Context Protocol),应该知道它能让 AI 连接各种外部工具和数据源。Agent SDK 原生支持 MCP:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
这样 Agent 就能使用 MCP 服务器提供的额外工具。比如 memory 服务器提供了持久化记忆能力,filesystem 服务器提供了安全的文件系统访问。
我试了一下接一个 PostgreSQL 的 MCP 服务器,让 Agent 直接查数据库然后生成报告。效果不错,但有个坑:MCP 工具的名字格式是 mcp__<server>__<action>,在 Hooks 里匹配的时候要用正则 ^mcp__ 而不是精确匹配。
跟其他 Agent 框架的对比
用了一段时间之后,我整理了一下 Agent SDK 跟主流框架的区别:
Agent SDK vs LangChain
LangChain 是一个通用的 Agent 框架,你需要自己定义工具、自己写 prompt template、自己管理 memory。它的优势是灵活,支持几乎所有 LLM。劣势是太灵活了——配置项多到让人头大。
Agent SDK 是 Claude 专属的。你不需要定义工具(内置了),不需要写 prompt template(Claude 自己知道怎么用工具),不需要管理 memory(Sessions 帮你搞定)。劣势是绑死了 Claude,不能换成 GPT 或 Gemini。
选择建议:如果你用 Claude 作为主力模型,Agent SDK 的开发效率远高于 LangChain。如果你需要多模型切换,LangChain 更合适。
Agent SDK vs CrewAI
CrewAI 是多 Agent 协作框架,核心概念是"角色"和"任务"。你定义多个 Agent 角色(比如"研究员"、"写手"、"编辑"),然后分配任务让它们协作。
Agent SDK 也有 Subagents,但思路不同。CrewAI 的 Agent 是对等协作,Agent SDK 的是主从关系——主 Agent 分配任务,子 Agent 执行并汇报。
选择建议:需要复杂的多角色协作流程,选 CrewAI。需要一个主 Agent 带几个工具人,选 Agent SDK。
Agent SDK vs OpenAI Agents SDK
OpenAI 也出了自己的 Agent SDK(从 Swarm 演化而来)。两者设计理念很像——都是内置工具、都是流式输出、都支持 handoff(把任务交给另一个 Agent)。
区别在于:Agent SDK 有 Claude Code 的全套工具(文件操作、代码编辑、Bash),OpenAI Agents SDK 更偏向 API 调用和函数执行。Agent SDK 有 Hooks 和 Sessions,OpenAI 的更轻量。
选择建议:做代码相关的 Agent(自动修 bug、代码审查、自动化测试),Agent SDK 更强。做 API 编排和业务流程自动化,OpenAI Agents SDK 更简洁。
实际使用场景
折腾了一天之后,我觉得 Agent SDK 最适合这几个场景:
1. CI/CD 里的自动化代码审查
在 GitHub Actions 里跑一个 Agent,PR 提交时自动审查代码:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
2. 自动化测试生成
给定一个源代码文件,自动生成对应的测试文件:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
3. 代码库文档生成
让 Agent 遍历整个项目,自动生成 README 和 API 文档:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
4. 数据处理 Pipeline
Agent 不只是能写代码,还能跑代码。你可以让它做数据处理:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
踩坑记录
坑 1:API 版本兼容
Claude Opus 4.7 把 thinking.type.enabled 改成了 thinking.type.adaptive。旧版 SDK 用 Opus 4.7 会报错:
| 1 | |
解决办法:升级到 Agent SDK v0.2.111+。
坑 2:Python SDK 和 TypeScript SDK 功能不对等
有些 Hook 事件只有 TypeScript 版有,Python 版没有。比如 SessionStart、SessionEnd、MessageDisplay、PostToolBatch 这些,Python 版目前不支持。
如果你需要这些高级 Hook 特性,可能得用 TypeScript 版。或者等 Python 版追上来。
坑 3:权限模式的默认行为
不指定 permission_mode 的时候,SDK 用的是 default 模式,这时候你需要提供 canUseTool 回调。如果不提供,Agent 会在每次工具调用时卡住。我第一次跑的时候就是遇到了这个问题——Agent 读了文件之后就不动了,等了半天才发现是在等权限回调。
坑 4:子 Agent 的工具继承
前面提过了,子 Agent 不继承主 Agent 的 allowed_tools,必须单独配置。
坑 5:Session 文件清理
Session 数据存在本地文件系统上,时间长了会积累大量 JSONL 文件。记得定期清理,或者用 SessionEnd Hook 自动清理。
部署到生产环境
本地玩玩当然可以,但真正的价值在于部署到生产环境。Agent SDK 支持多种部署方式:
Docker 部署
最简单的方式是打包成 Docker 镜像:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
注意:Docker 容器里的 Agent 只能访问容器内的文件系统。如果你需要访问宿主机的文件,要挂载 volume。
CI/CD 集成
在 GitHub Actions 里用 Agent SDK:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
跟 Managed Agents 的关系
Anthropic 还提供了 Managed Agents——一个托管的 REST API,Anthropic 帮你运行 Agent 和沙盒。Agent SDK 是在你自己的进程里跑,Managed Agents 是在 Anthropic 的基础设施上跑。
官方建议的路径是:本地用 Agent SDK 原型验证,生产用 Managed Agents。这样你不用自己管基础设施。
总结一下
Claude Agent SDK 不是万能的,但在它的适用范围内——构建基于 Claude 的自动化 Agent——它是我用过的最省心的方案。内置工具省去了大量样板代码,Hooks 提供了足够的控制能力,Sessions 解决了上下文保持的问题。
跟 LangChain 比,它不灵活,但开发效率高得多。跟 CrewAI 比,它不适合复杂的多角色协作,但单 Agent + 子 Agent 的模式足够覆盖大多数场景。
如果你已经在用 Claude Code,Agent SDK 几乎没有学习成本——它们共享同一套工具和概念。如果你没用过 Claude Code,Agent SDK 是一个很好的入口。
后面我打算用 Agent SDK 搭一个自动化的代码审查机器人,接入 GitHub PR webhook,到时候再写一篇实战记录。有啥问题评论区聊。
- 本文写于 2026 年 6 月,基于 Claude Agent SDK 最新版。SDK 更新很快,建议以 官方文档 为准。*