企业官网建设流程全解析

最近这一周，我朋友圈和几个技术社群里最热闹的话题，不是哪个新模型又刷新了榜单，而是 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 的核心不是一个模型，而是一套运行在真实环境里的循环。我把它拆成五步：

1. 理解任务：把用户需求转成计划，先把仓库结构摸清楚。
2. 选择工具：根据当前状态决定用 bash、glob、grep、read 还是 edit。
3. 观察结果：读取命令输出、报错信息、测试结果，判断是否偏离目标。
4. 修正策略：发现不对就换一种方式继续，不硬着头皮往下走。
5. 整理上下文：把长对话压缩成摘要，避免把上下文窗口撑爆。

泄露内容里，对每个环节都有对应的行为约束和工具说明。工具本身看着普通——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 一张表把定位说清楚

选型建议说直白点：如果目标只有一个“让模型帮我把代码改对”，别绕路，直接上 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 就能生效。操作步骤大致如下：

1. 下载安装 cc-switch，它是社区开源项目，直接按项目名搜。
2. 添加供应商，填入你申请到的 API 地址（通常是 Anthropic 兼容端点）、密钥和模型名。
3. 设一个默认配置，避免每次启动都手动选。
4. 重启 Claude Code，输入/status确认当前生效的模型。
5. 如果调用报 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 重写与轻量 Agent

5.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 Server，Python 也可以，大家按同一个协议对接。这恰恰预示着框架的下一代形态是“协议加运行时”，而不是“某个语言的库”。我的建议是：不要因为 Rust 火就立刻转语言，先把 Agent 的理解搞对，再决定哪一层值得用 Rust 重写。对大多数团队来说，用现成的 Rust 工具链，比自己造轮子靠谱得多。

5.3 轻量化的反面：安全与自动化成熟度不可忽视

轻量 Agent 的诱惑很大，一个二进制丢到服务器上就能跑，但自主执行也意味着风险成倍放大。没有权限治理的 Agent，等于把服务器钥匙交给一个会犯错的程序。Claude Code 泄露内容里最值得抄的部分，其实是它的安全规则——通过系统提示词和工具层的双重约束，把“什么能做什么不能做”写死，危险操作必须停下来问用户。

我实践下来的做法是：即便用轻量框架，也至少要保留三层防护。第一，确认模式，写文件和删文件这类操作默认等待用户同意。第二，沙箱，Agent 只能访问项目目录，不能碰系统目录。第三，审计日志，每一次工具调用都留痕，出了问题能回放。没有这三层，跑得再快我也不敢让它上生产。

6. 格局变化之后，普通开发者的学习路线该怎么调

6.1 先抄作业，再谈框架：一条更短的学习路线

很多人的学习路线是反着来的，一上来就学框架，结果被框架的抽象绕晕。我建议按这个顺序走：

1. 先装好 Claude Code，用两周，每天拿真实任务练，搞清楚“好 Agent”长什么样。
2. 手写一个一百行的最小 Agent 循环，模型调用加工具执行加循环判断，理解核心机制。
3. 学 MCP，理解工具接入标准，知道怎么给 Agent 加新能力。
4. 读公开的提示词和官方文档，理解系统约束怎么写，为什么这么写。
5. 最后才去比较 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, }, timeout=60, ) resp.raise_for_status() return resp.json()["content"][0]["text"] def run_agent(task, max_rounds=5): 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 的本质是一个运行在真实环境里的闭环，你会发现选框架、接模型、调成本这些问题，答案都变得很简单了。