最近这一周我朋友圈和几个技术社群里最热闹的话题不是哪个新模型又刷新了榜单而是 Claude Code 的底层内容被泄露这件事。具体传播过程各种版本都有比较确定的是它的系统提示词和内部工具定义被完整扒了出来等于把 Anthropic 做“编程 Agent”时想的所有心思都摊开在了大家面前。紧随其后的问题几乎一模一样AI Agent 框架的格局是不是要重新洗牌了这篇东西就是我对这个问题的完整梳理会聊泄露内容里到底有什么值得研究的东西、LangChain/Dify/CrewAI 这类框架在新格局里还剩多少分量、以及普通开发者接下来该怎么调整自己的技术路线。适合那些已经在用 Claude Code、正在搭建自己的 Agent或者正在纠结该选哪个 Agent 框架的人。我想先说一个结论这次泄露对框架层面的冲击比很多自媒体写的“提示词曝光”要严重得多。因为它暴露的不只是几句话而是 Anthropic 对“Agent 到底该长什么样”的整套判断。这套判断一旦公开任何团队都能照着搭出七成像的替代品很多靠“封装 Agent 概念”吃饭的框架护城河就变浅了。但反过来看这对整个生态又是一件好事——大家终于能站在同一份“作业答案”上去做更实际的工程优化而不是靠猜。1. 泄露的不是代码而是一份 Agent 行为手册1.1 系统提示词才是真正的“产品规格”在 Claude Code 出现之前行业里主流的 Agent 框架讲的是“编排”。LangChain 教你用 Chain、Graph 把模型、工具、记忆串起来Dify 让你拖拽节点CrewAI 让你定义角色。大家都在默认一个前提Agent 的智能来自“框架的架构设计”。但 Claude Code 用实际效果证明了另一件事一个几万 token 的系统提示词加上十几个定义良好的工具再加一个朴素的循环就能干掉绝大多数“精心编排”的方案。这次泄露把这份提示词公开了等于把“智能的核心其实在行为约束”这个反直觉的结论摆在了所有人面前。我当时拿到第一批公开内容后通读了两遍里面有几类东西印象非常深。第一类是身份与边界声明它明确告诉模型自己是 Claude Code是终端里的编程助手不允许冒充其他产品也不允许在用户没有要求时做超出范围的事情。第二类是工作方法论比如先探索再动手、小步修改、频繁验证、出了问题要自己定位并修复。第三类是工具使用偏好强调精确查找优先于整文件读取能用 grep 和 glob 就不去读全文。第四类是安全与权限规则涉及破坏性操作时要停下来向用户说明风险、等待确认。第五类是上下文压缩策略长对话达到一定长度后如何总结和丢弃旧内容。这些内容放在以前只能靠“黑盒逆向”去猜现在直接变成公开教材了。任何一个想写 Agent 的人都可以把这份提示词当 Blueprint 来读。我甚至看到不少团队直接把它分段喂给新模型做“行为蒸馏”——讨论归讨论实际做产品我还是建议用官方许可的方式去学习比如看 Anthropic 的公开文档和官方发布的行为准则那份泄露内容用来理解设计思路就够了不要直接抄成自己的产品提示词风险和争议都很大。1.2 Agent 循环的真身一次调用、一个回合、一条反馈很多人的误解是写 Agent 就是调 API然后等着大模型吐一段漂亮答案。这次泄露把这种想法彻底推翻了。Claude Code 的核心不是一个模型而是一套运行在真实环境里的循环。我把它拆成五步理解任务把用户需求转成计划先把仓库结构摸清楚。选择工具根据当前状态决定用 bash、glob、grep、read 还是 edit。观察结果读取命令输出、报错信息、测试结果判断是否偏离目标。修正策略发现不对就换一种方式继续不硬着头皮往下走。整理上下文把长对话压缩成摘要避免把上下文窗口撑爆。泄露内容里对每个环节都有对应的行为约束和工具说明。工具本身看着普通——shell、文件读写、搜索真正值钱的是“循环里的决策规则”什么时候该读文件、什么时候该跑测试、看到报错之后下一步干什么。这才是 Agent 工程的核心也是很多框架一直没做好的一层。框架给你一百个抽象类不如给你一个高质量的工具反馈回路。1.3 为什么这一次泄露比以往更快改变格局之前大家也在抄。OpenAI 的 Codex、Google 的 Jules、各种开源编程 Agent都是“成品演示”你看到的是结果看不到内部决定。这次不一样——泄露直接给出了配方。结果就是一大批兼容实现和复刻项目会在几个月内冒出来把 Claude Code 的行为模式搬到其他模型上。这也是为什么最近“用 DeepSeek、Qwen、GLM 跑 Agent”的话题突然这么热大家终于知道该模仿什么了。这直接改写了评估框架的标准。以前比的是“支持多少模型、多少工具插件”以后比的是“你的循环是否够稳、权限治理是否精细、上下文预算是够省”。我举个具体例子我本地复刻过一个极简循环模型加终端工具加文件编辑工具不到 200 行就实现了“让模型自己发现编译错误并修复”的效果。而同样的事情用某主流框架搭得先学三十多个抽象类调试时还要一层层剥包装。这不是说大框架完全没用而是说“该以谁为核心”这个问题已经变了。2. 框架竞争的底层逻辑从“串 API”转向“接管环境”2.1 抽象层不是越多越好LangChain 式困境旧框架的卖点是抽象把模型、向量库、工具、记忆统一成一套接口你写一套代码就能切到任意模型和数据库。听起来很美实际用起来有三宗罪。第一调试难报错会被层层包装一个问题要翻三个抽象层才能定位。第二链路长每个抽象层都在往提示词里塞东西token 消耗肉眼可见地涨。第三模型被“提示词包装”绑架框架自己加的模板有时候比你的业务指令还强势模型行为很难调。Claude Code 给模型的是操作系统级别的权限而不是抽象 API。模型可以直接跑 shell、编辑文件、看测试结果像人一样干活。这次泄露公开的内容恰恰证明了一件事Agent 框架的本质是“运行时”不是“库”。运行时关心的是进程管理、权限、回滚、上下文管理库关心的是复用。这两个定位完全不同你不能指望一个做“库”的框架同时把“运行时”做好因为它们的优化目标是冲突的。2.2 主流的 Agent 架构这次被重新排序了结合泄露内容再看 AI Agent 的主流架构路线图清晰了很多。目前主流大致分三类单 Agent 循环也就是大家常说的 ReAct 风格、规划执行式Plan-and-Execute、多 Agent 协作式CrewAI 那种。Claude Code 属于第一类但它把执行环境做得极其扎实于是效果就把后两类远远甩开了。这次泄露之后社区里形成的一个新共识是绝大多数真实任务用“单 Agent 强工具”就够了。多 Agent 协作不是银弹反而是你前三五个 Agent 之间同步状态、来回传递信息既慢又费 token最后结果还不一定收敛。Claude Code 的配方恰恰支持这个判断把一个 Agent 的工具集和权限体系做扎实比让它和三五个 Agent 开聊天会有用得多。规划执行式在超长任务里还有价值但前提是单 Agent 的反馈循环先做到位否则规划本身也是空中楼阁。2.3 新格局下的四个硬指标我自己的评估方法是看四个维度不看你宣传了多少功能工具协议是否支持 MCP 这类开放协议还是只有自家闭门造车的工具体系。协议开放意味着生态闭门意味着你被绑定。权限治理危险操作是否需要确认、能否按目录、按命令粒度授权。这是 Agent 能不能上生产的关键。上下文预算长会话是否自动压缩、能否控制工具输出的大小、允不允许“不读全文只 grep”。省钱全靠这一项。可观测性日志够不够细能不能回溯每一次工具调用和 token 消耗。出问题的时候你就知道它多重要了。这四个指标决定一个 Agent 能不能在一个项目里长期稳定跑下去。相比之下“支持多少个模型”反而是最容易解决的——只要模型接口兼容一个环境变量就换掉了后面第四节专门讲这个。2.4 “接管环境”才是新的护城河以前我们说的 Agent大多是调用一堆外部 API查天气、发消息、搜网页。这种“API 胶水式”的 Agent 价值低因为 API 谁都能接你做的东西别人三天就能复制。Claude Code 打开了一个完全不同的方向直接操作开发者的日常工作环境——文件系统、终端、Git、测试框架比如 pytest、IDE。泄露内容清晰地展示了这套工具集该怎么设计于是“环境适配层”成了新战场。谁能把终端执行、文件编辑、IDE 插件、CI 集成做得又稳又安全谁就掌握主动权。纯靠“提示词模板库”起家的框架会慢慢边缘化因为模板谁都会写但环境适配是真功夫。另外也提一句被问到的 SpringBoot、若依、Nuxt 这类业务框架并不会被 Agent 框架取代——它们是业务承载层Agent 框架是编排与执行层两者在工程栈上处于不同层面是配合关系不是替代关系。3. 站在今天重新选型LangChain、Dify、CrewAI 到底还香不香3.1 LangChain不会消失但不再是默认答案LangChain 的生态还是最全的云厂商集成多适合 RAG、数据管道、企业系统对接这类场景。但它的学习曲线陡、API 经常变、很多时候是把简单事情复杂化。新格局下它的定位更像“胶水层”把内部系统接进来把数据流串起来。你要让它写那种“自己改代码”的 Agent一半时间在跟框架搏斗。我的实测感受是用 LangChain 写带 RAG 的知识库问答仍然顺手因为它处理文本切分、向量检索、重排序这些杂活确实成熟但用它写一个自主编程 Agent体验就很不舒服抽象层太多模型的每次工具调用都被包装成复杂的链式结构出错之后定位非常痛苦。所以我的判断是LangChain 不会被淘汰但它会退到“企业集成层”不再是 Agent 开发默认答案。3.2 Dify低代码工作流的定位反而更清晰了Dify 的优势一直很明确可视化编排、内置知识库、模型管理和日志非技术同事也能上手。在 Claude Code 带起“终端原生 Agent”风潮之后Dify 这类平台化产品的定位反而更清楚了——它是“产品平台”不是“Agent 内核”。Claude Code 是给开发者自己用的工具Dify 是给业务团队搭聊天机器人、客服、分析助手这类应用的。这次泄露对 Dify 这类平台的冲击在于社区对“自主 Agent”的期望变高了。如果 Dify 还只是停留在“拖拽一个工作流、每一步人点一下”的阶段很容易被更轻的方案分流。我看到不少团队开始给 Dify 类平台补“自主 Agent 模式”和“工具权限管理”我觉得这是正确方向。但它解决的是业务需求不是写代码的需求别拿它跟 Claude Code 放在同一维度里比。3.3 CrewAI多角色协作这个方向没有被推翻但优先级得往后排CrewAI 的优点是真轻量上手快角色、任务、流程的定义很直观。适合研究型任务拆分研究员角色负责收集资料分析师角色负责整理报告员角色负责输出各司其职。但它的局限也很明显多 Agent 之间的通信和状态同步开销很大很多任务其实一个强 Agent 就能完成。泄露内容反而强化了“单 Agent 能力大于多 Agent 编排”的判断。你把一个 Agent 的工具和权限做扎实比让它和三五个 Agent 开聊天会有用得多。所以我对 CrewAI 的态度是可以学用来理解多角色协作的思路但别一上来就把所有任务都拆成多 Agent——先试试单 Agent 能不能解决通常都能。3.4 一张表把定位说清楚框架核心定位上手成本最擅长的场景在编程 Agent 格局中的位置LangChain通用 LLM 集成框架中高RAG、企业系统对接、数据管道胶水层非核心Dify低代码 LLM 应用平台低业务应用、客服、知识库产品层非内核CrewAI多角色编排中多步研究、角色模拟锦上添花非必要Claude Code终端原生编程 Agent低写代码、改代码、跑测试当前标杆选型建议说直白点如果目标只有一个“让模型帮我把代码改对”别绕路直接上 Claude Code 或者它的开源同类如果公司要做对外客服机器人选 Dify 这类平台如果论文或调研团队想模拟多角色工作流CrewAI 够用如果已经深度绑定 AWS、Azure 生态要把 Agent 塞进现有业务系统LangChain 仍然有它的位置。4. 实操把 Claude Code 当“模型无关的 Agent 引擎”来用4.1 安装与基础使用npm 一行命令跨平台都能跑Claude Code 的安装已经很简单了。前提是机器上有 Node.js版本 18 以上然后执行npm install -g anthropic-ai/claude-code装完在终端里敲claude就能进交互界面。mac 上直接用终端跑没问题Ubuntu 上如果没装 Node.js建议先用 nvm 装一个长期支持版本再用 npm 安装注意别用系统自带的过老版本Windows 下我更推荐在 WSL 里跑这样终端、文件系统和 Git 的行为跟 Linux 一致Agent 执行命令时少踩很多坑。VS Code 用户可以直接装官方插件在编辑器里开面板对话效果和终端版互补。桌面版现在也在迭代中功能上和终端版不是替代关系而是给你多一个入口。升级也方便claude update可以检查并更新到最新版本或者直接用 npm 重新全局安装一遍。我刚开始用的时候总觉得工具不够聪明后来发现是版本太老很多能力是靠持续升级补上来的所以建议保持习惯每个版本发布说明都扫一眼。4.2 为什么能接第三方模型Anthropic 兼容 API 是关键Claude Code 内部是走 Anthropic Messages API 的格式和模型交互它只关心请求格式对不对不关心对面是什么模型。只要服务方把请求翻译成自家模型的调用你就能用别的模型来驱动整个 Agent 循环。这个“协议兼容”的设计是这次泄露后大家最关注的落地点。它带来的直接好处是模型选择不再跟框架绑死。你可以用官方 Claude 跑复杂项目在省钱场景切到 DeepSeek、Qwen、GLM 这类云 API也可以接公司自建的统一网关。供应商可以是模型厂商的官方云平台也可以是你公司内部搭的兼容服务甚至是本地起的开源模型服务。判定能不能接标准只有一个它提供的接口是不是 Anthropic 兼容的。4.3 用 CC Switch 这类工具切换供应商省心很多手动改环境变量太容易出错所以社区里出现了 cc-switch 这类配置管理工具。它的本质是一个本地 GUI把不同的供应商配置基础地址、密钥、模型名存起来一键切换改完重启 Claude Code 就能生效。操作步骤大致如下下载安装 cc-switch它是社区开源项目直接按项目名搜。添加供应商填入你申请到的 API 地址通常是 Anthropic 兼容端点、密钥和模型名。设一个默认配置避免每次启动都手动选。重启 Claude Code输入/status确认当前生效的模型。如果调用报 404 或者 400先检查 base_url 是不是拼错了再到对应服务商的文档里核对模型名。这些操作全都在本地完成不涉及上传会话内容但密钥还是要妥善保管别不小心提交到 Git 仓库里。我的习惯是每个供应商单独建一个配置注明用途和模型版本换供应商时一条命令搞定不会留下一堆散落的环境变量。4.4 手动配置不装工具也能改如果你不想依赖第三方工具直接配置环境变量也一样。全局配置放在~/.claude/settings.json项目级配置放在项目目录下的.claude/settings.json后者优先级更高。一个典型的配置是这样{ env: { ANTHROPIC_BASE_URL: https://api.example.com/v1, ANTHROPIC_AUTH_TOKEN: sk-xxxxxxxx, ANTHROPIC_MODEL: deepseek-v4, ANTHROPIC_SMALL_FAST_MODEL: deepseek-v4-lite } }逐项解释一下。ANTHROPIC_BASE_URL是接口端点必须指向一个 Anthropic 兼容的服务ANTHROPIC_AUTH_TOKEN是认证密钥不同服务商给的形式可能不一样有的是“Bearer Token”有的是 API Key按服务商文档填就行ANTHROPIC_MODEL是主模型名换成你从服务商拿到的真实模型名ANTHROPIC_SMALL_FAST_MODEL是小模型Claude Code 会把标题生成、简短分类这类轻任务丢给它配好这一项能在不影响主流程的情况下明显省钱。改完之后重启 Claude Code输入/status看到当前模型正确就说明配好了。如果你是直连官方服务也可以用ANTHROPIC_API_KEY这个环境变量更简单但灵活度不如上面的方案。4.5 Token 到底怎么烧的“agent token”是什么意思、怎么省“agent token”这个问题最近被问得特别多。说白了token 就是模型计费的最小单位中英文一个词或一个汉字都可能对应一到多个 token。Agent 场景下的大头是输入 token因为每次循环都要把系统提示词、历史会话、工具输出重新发一遍给模型。我用一个项目实测一次真正复杂的修复会话来回跑了十几轮轻松烧掉几十万 token费用就是这么上去的。省 token 我总结了五个实在的办法。第一好好配置ANTHROPIC_SMALL_FAST_MODEL轻任务别用大哥模型。第二让 Agent 多用 grep、glob 精确查找少做整文件读取读一个上千行的文件比你搜十次还费。第三权限收窄一些限制它能跑的命令减少因瞎尝试导致的失败重试——一次失败的尝试也是要烧 token 的。第四长会话定期开新会话把关键结论带过去继续不要一个会话跑到底上下文越长越贵且越容易跑偏。第五日常任务接便宜的模型疑难杂症再切回强模型。价格差异在不同服务商之间很大量级差几倍到十几倍都很常见以服务商计费页为准。5. 被点燃的另一条路线Rust 重写与轻量 Agent5.1 为什么“基于 Rust 的 AI Agent”成了热词先说一个容易混淆的概念有人搜“pytorch 基础框架”其实想找的是 Agent 框架方向就错了。PyTorch 是模型训练层的工具Agent 框架是推理侧的编排层两者隔着整整一层。你要搭 Agent重点在编排层不在模型怎么训练。Claude Code 泄露带来的复制浪潮让大家意识到 Agent 需要的不是“跑在某个大框架里”而是“到处能跑的单个程序”。于是基于 Rust 的 AI Agent 就成了热词。Rust 的好处正好踩在 Agent 的需求上单二进制分发不用装 Python 环境冷启动快内存占用低并发安全多个工具调用不容易出竞态问题。对 Agent 这种要长期驻留、反复调用工具、跟文件系统与终端打交道的进程来说这些特性确实很配。我了解到的 Rig、Goose 这类以 Rust 为核心的 Agent 项目和框架走的都是这个路线。5.2 Rust 不是要取代 Python而是接管“运行时”很多人看到 Rust 火就焦虑想转语言我觉得大可不必。Python 生态在数据科学、模型训练、快速原型上仍然是无可替代的绝大多数 Agent 的策略逻辑和评估脚本也是 Python 写的。Rust 真正要接管的是“运行时”这一层CLI 壳、工具执行、权限沙箱、网络层。业务逻辑可以继续用 Python 或 TypeScript但底座换成 Rust 之后Agent 的启动速度和分发体验会好一个量级。MCP 这个协议正好说明了这个趋势它跟实现语言无关Rust 可以写 MCP ServerPython 也可以大家按同一个协议对接。这恰恰预示着框架的下一代形态是“协议加运行时”而不是“某个语言的库”。我的建议是不要因为 Rust 火就立刻转语言先把 Agent 的理解搞对再决定哪一层值得用 Rust 重写。对大多数团队来说用现成的 Rust 工具链比自己造轮子靠谱得多。5.3 轻量化的反面安全与自动化成熟度不可忽视轻量 Agent 的诱惑很大一个二进制丢到服务器上就能跑但自主执行也意味着风险成倍放大。没有权限治理的 Agent等于把服务器钥匙交给一个会犯错的程序。Claude Code 泄露内容里最值得抄的部分其实是它的安全规则——通过系统提示词和工具层的双重约束把“什么能做什么不能做”写死危险操作必须停下来问用户。我实践下来的做法是即便用轻量框架也至少要保留三层防护。第一确认模式写文件和删文件这类操作默认等待用户同意。第二沙箱Agent 只能访问项目目录不能碰系统目录。第三审计日志每一次工具调用都留痕出了问题能回放。没有这三层跑得再快我也不敢让它上生产。6. 格局变化之后普通开发者的学习路线该怎么调6.1 先抄作业再谈框架一条更短的学习路线很多人的学习路线是反着来的一上来就学框架结果被框架的抽象绕晕。我建议按这个顺序走先装好 Claude Code用两周每天拿真实任务练搞清楚“好 Agent”长什么样。手写一个一百行的最小 Agent 循环模型调用加工具执行加循环判断理解核心机制。学 MCP理解工具接入标准知道怎么给 Agent 加新能力。读公开的提示词和官方文档理解系统约束怎么写为什么这么写。最后才去比较 LangChain、Dify、CrewAI 这些框架按场景选。为什么这个顺序有效因为框架是“别人对 Agent 工程的一种封装”你不理解底层循环就不知道它在解决什么问题也谈不上用得好不好。先抄作业抄明白了再去理解抽象事半功倍。第一次接触 Agent 的人最重要的是建立“反馈闭环”的心智模型这个模型一旦建立后面看什么框架都快。命令行里跑通一个最小的 Agent 循环并不难核心代码其实很短。这里我放一个简化的骨架用的是 Anthropic 兼容接口环境变量配置好就能跑import os import requests def call_model(messages): resp requests.post( os.environ[ANTHROPIC_BASE_URL], headers{ x-api-key: os.environ[ANTHROPIC_AUTH_TOKEN], anthropic-version: 2023-06-01, content-type: application/json, }, json{ model: os.environ[ANTHROPIC_MODEL], max_tokens: 1024, messages: messages, }, timeout60, ) resp.raise_for_status() return resp.json()[content][0][text] def run_agent(task, max_rounds5): messages [{role: user, content: task}] for _ in range(max_rounds): reply call_model(messages) # 真正的工程量大头在这两行中间 # 解析模型要调用的工具 - 在受限环境里执行 - 把输出作为新消息放回上下文 messages.append({role: assistant, content: reply}) messages.append({role: user, content: 工具执行结果}) return messages[-1][content] if __name__ __main__: print(run_agent(统计当前目录下有多少个 Python 文件))这个骨架看起来简单但理解它的结构之后你就知道框架到底帮你做了什么解析工具调用、管理消息历史、处理长上下文、加权限控制。这些才是框架的价值所在。我建议每个人都亲手把中间那块补全一遍哪怕只做支撑 grep 和读文件两个工具你对 Agent 的理解会超过一大半只会拖拽节点的人。6.2 哪些框架会被边缘化哪些会活下来基于这次泄露我大胆做个判断。会被边缘化的是三类纯“提示词库”式的框架它们只提供模板不提供运行时能力绑定单一厂商的工具链你换模型就得换框架只做控制台 Demo、没有权限体系和可观测性的玩具框架。活下来的也有三类协议先行的框架支持 MCP 和 Anthropic 兼容 API权限体系成熟的框架能按目录、按命令粒度授权跟 IDE、CI 深度集成的框架能无缝嵌入开发者工作流。平台化产品像 Dify 这类会继续分化一部分往企业 LLMOps 走强化知识库、权限、审计这些企业关心的东西另一部分补强自主 Agent 能力否则容易被更轻的解决方案分掉流量。框架大战还没打完但“框架等于运行时加权限协议加上下文管理”这个定义基本已经定下来了。6.3 我自己的几点实操体会最后分享几个踩过坑之后的真实感受排序分先后。第一不要把一个 Agent 当函数调用脚本。它最核心的价值是闭环反馈改完代码一定要跑测试测试跑通了才算完。我见过太多“模型改得很开心、项目根本编译不过”的情况根因就是 Agent 没有跟真实环境产生足够强的反馈。第二权限配置永远排第一。先把危险命令禁掉再慢慢放开能力比反过来容易得多。有一次我图省事给 Agent 完全放开 shell 权限它在重构时顺手把整个目录的历史文件都删了虽然 Git 还能救回来但那一下的冷汗我至今记得。第三成本管理要从第一天开始。接入第三方模型时先小规模试跑一周做一个固定任务记录它消耗多少 token换算成钱好过月底收到账单再头疼。上下文预算和省钱策略不是优化项是必做项。第四多看失败日志少看成功演示。一个 Agent 遇到报错之后的行为才是它的真实水平。框架文档里展示的都是顺利路径真实生产里的脚本错误、权限问题、网络抖动、模型抽风才是考验工程功底的时候。泄露事件本身会慢慢过去但它留下的这份“配方”会长期影响 Agent 框架的设计方向。这个领域现在最大的红利是早一点把别人的作业消化成自己的工程能力。想清楚 Agent 的本质是一个运行在真实环境里的闭环你会发现选框架、接模型、调成本这些问题答案都变得很简单了。