📖 你可能还感兴趣:本地大模型一个月真实体验：哪些场景真能用，哪些纯粹是伪需求【 · 当本地大模型遇上M系列芯片——Mac上跑大模型的半年真实体验

2026年2月，我满怀信心地开始了我的"AI Agent计划"。三个月后，我删掉了所有框架代码，留下了一个不到100行的脚本。这篇文章不是教你做Agent——而是告诉你，为什么大多数人不需要Agent框架。

故事的开始：一个美丽的幻觉

2026年初，AI Agent概念爆炸式火起来了。

OpenAI发布了Agents SDK，Anthropic推出了MCP协议，LangChain的GitHub star数直奔50万。推特上的AI KOL们都在展示他们的Agent系统：自动写周报、自动管理社交媒体、自动处理邮件、自动研究市场趋势……这些Demo看起来像是未来已经降临。

我被彻底说服了。我接了几个自由项目，发现大量重复工作吞噬了我的时间——整理客户需求、生成报告、写简单的代码片段、抓取网页数据。我的直觉告诉我：我需要一个Agent系统。

于是我做了一个"简单"的决定：用三个月时间，搭建一个能够自动化30%日常工作的AI Agent体系。

这成了我2026年目前为止最后悔的决定。

第一阶段：LangChain——从兴奋到绝望

第一天：我感觉自己是天才

按照LangChain的官方教程，我在一个下午就搭建了一个"研究助手Agent"。它能接收一个话题，然后去搜索、总结、生成报告。虽然输出的内容大概相当于一个初中生写的读书笔记，但它在"自动运行"。

我兴奋地发了条朋友圈："Agent时代来了，以后周报AI写了。"

现在回头看，这条朋友圈是我整个项目里最珍贵的产出。

第一周：裂缝出现

LangChain的问题很快就暴露了。

第一个问题是过度抽象。LangChain试图为每一种可能的AI交互创建统一的接口——Chain、Agent、Tool、Memory、Callback……但当你真正理解后会发现，大部分抽象层解决的是LangChain自身的问题，而不是你的问题。

举个例子，我花了整整两天搞清楚"ConversationalRetrievalChain"和"ConversationalRetrievalChainWithMemory"的区别。最后发现，我只需要把聊天历史拼接成一个字符串传给LLM就够了。LangChain把一件简单的事变成了复杂的事。

第二个问题是不可调试。当一个Agent链调用链达到4-5层时，你根本不知道它在干什么。我在代码里加满print语句，输出全是"Entering LLMChain with input: xxx"，完全不告诉你模型内部在想什么。我甚至一度怀疑是代码本身有问题，直到我把同样的Prompt复制到ChatGPT里，发现表现得一模一样——原来不是代码问题，是我的Agent设计思路就是错的。

第三个问题是版本地狱。LangChain当时处于0.3版本，API每天都在变。我照着YouTube上一个月的教程写代码，import路径已经变了三次。我花了至少10个小时，仅仅是为了让旧代码跑在新的API上。

第一周结束时的反思

一周后，我有了一个能用的Agent，它能做的事情是：搜索三个关键词、整理成Markdown、发送到飞书。输出质量还不如我花5分钟用Claude直接写的。

我当时写了一段笔记给自己的话，现在看依然准确：

"LangChain不是构建工具，是谜题。你花80%的时间在解谜题本身，而不是在解决问题。"

但我没有放弃。我觉得问题可能出在框架选择上。于是我开始研究CrewAI。

第二阶段：CrewAI——多Agent的幻觉

多人协作，听起来很美

CrewAI的理念很吸引人：创建多个Agent，每个Agent有自己的角色、目标、记忆，它们可以像人类团队一样协作完成任务。CEO Agent分配任务，Researcher Agent查资料，Writer Agent写文案，Reviewer Agent审核修改。

听起来像是一个Mini版的公司对吧？我当时就是这么想的。

现实：一个四脚蛇的比喻

CrewAI的实际运行过程，就像你组建了一个团队，里面每个人都是同一个人的不同面孔——它们共享同样的底层LLM，同样的知识上限，同样的偏见。

我在CrewAI里创建了四个Agent：

  • ResearchAgent：负责搜索和整理资料
  • AnalysisAgent：负责分析数据
  • WriteAgent：负责撰写内容
  • ReviewAgent：负责审核修改

我让它们协作写一份行业分析报告。结果是这样的：

  1. ResearchAgent搜索了5个网页，返回了3个有效链接（这是最好的一步）
  2. AnalysisAgent把"数据明显偏少"这类内容当作分析结论
  3. WriteAgent写了一篇内容，其中一段话重复了三遍
  4. ReviewAgent说"这是一篇高质量的分析报告"

你发现了吗？ReviewAgent说它好，是因为它自己写的。

这四个Agent本质上是一个人跟自己开会，然后宣布会议取得了巨大成功。

成本问题

CrewAI还有一个更深层的问题：成本。

按照我当时的设计，一个完整的Agent流程需要调用：
- 每个Agent至少2次LLM调用（思考+输出）
- Agent之间信息传递额外的调用
- 如果出错还要重新调用

算下来，生成一篇2000字的报告，token消耗是直接写Prompt的5-8倍。质量反而更差。

我算过一笔账：同样一篇行业分析报告：
- 直接让Claude写：成本约$0.3，耗时30分钟（自己修改）
- 用CrewAI自动写：成本约$2.1，耗时45分钟（调试排除故障）

多花了7倍的金钱和更多的时间，拿到了更差的结果。

第三阶段：AutoGPT——失控的体验

自主Agent的终极幻想

AutoGPT的理念更进一步：给Agent一个目标，让它自主规划、执行、学习，直到完成任务。

我想测试一个简单的场景：让它帮我整理我所有社交账号的内容，生成一份个人知识图谱。

我把这个任务交给了AutoGPT。然后它开始了：

  1. 它先搜索了我的名字，找到了LinkedIn个人页
  2. 然后它决定要登录我的Twitter账号——但API被锁了
  3. 它尝试了3种不同的方法破解API限制，都失败了
  4. 然后它"决定"放弃Twitter，去抓取我的GitHub页面
  5. 抓取成功后，它生成了一个JSON文件，但内容全是乱码
  6. 它试图修复JSON文件，但不断陷入循环
  7. 最后，它进入了一个无限循环：写JSON -> 验证失败 -> 重写 -> 验证失败……

这个循环持续了27分钟，消耗了大约$4.3的API费用，生成了超过2000行日志。

我手动终止了它。

这次经历让我意识到一个关键问题：当前的大语言模型在自主决策方面存在根本性缺陷。它们没有真正的目标感，没有优先级判断，没有对"合理性"的直觉。它们只是在接续你给的Prompt——当Prompt是"继续尝试"时，它们会真的永远尝试下去。

第四阶段：返璞归真——我最后留下了什么

觉醒时刻

在经历了三个框架的轮番"毒打"后，我坐在电脑前，看着屏幕上那个AutoGPT生成的、高达12MB的日志文件，问了自己一个问题：

"我到底想要什么？"

答案是：我不是要一个Agent系统，我是要自动化我日常工作中的几个重复步骤。

那个脚本

我打开VSCode，开始写一个不到100行的Python脚本。它就做三件事：

  1. 读取输入：从一个特定的飞书文档中读取最新内容
  2. 调用API：把内容发给OpenAI的Chat Completion API，带上精调过的System Prompt
  3. 输出结果：把返回内容写到另一个飞书文档，附带格式化

没了。没有Chain，没有Agent，没有Memory，没有Tool，没有Callback。

Script只做我明确要它做的事，一次一步，永不猜测我的意图。

每一个步骤的输入和输出都是确定的。如果出错了，我知道错在哪一步，改了重新跑就行。

我用这个脚本替代了：
- 每周客户邮件汇总（原来半小时，现在2分钟）
- 技术文档的初稿生成（原来1小时，现在5分钟，但需要我审核修改）
- 每日行业新闻摘要（原来20分钟，现在自动完成）

一个脚本替代了之前三个框架的全部工作。而且运行稳定、成本极低、完全可控。

对比数据

维度 LangChain/CrewAI方案 我的Script方案
代码行数 3000+ 87
外部依赖 15+个包 requests + json
学习成本 2周 10分钟
每次运行成本 $0.5-$2 $0.02-$0.08
故障率 约30% 约5%（主要在API不稳定时）
可调试性 极差 极好
修改难度 改一个行为要动5个文件 改一行代码

为什么大多数人不需要Agent框架

三个月实验结束后，我得出了一个不是那么让人兴奋的结论：

2026年的AI Agent框架，解决的是一个还没有出现的问题。

它们假设你需要复杂的Agent协作，但大多数人的真实需求是：
- "帮我总结这段文字"
- "帮我用Python写一个函数"
- "帮我找出这份数据中的规律"
- "帮我翻译这段内容"

这些事情不需要Agent。你只需要把Prompt写得足够好，然后调用一次API。

Agent框架的本质是在"API调用"之上增加了一层抽象。如果你的任务在"一次API调用"的范围内就能解决，这层抽象就是负资产——它增加了复杂度、成本、出错概率，而没有任何收益。

只有当你的任务需要多个约束条件动态交互时，Agent框架才有价值。比如：
- 复杂的多步骤研究
- 需要外部工具实时交互的任务
- 需要长期记忆和上下文跟踪的对话

但即使在上述场景中，用简单的if-else逻辑 + 良好设计的Prompt链，通常也比现成的Agent框架更稳定、更可控。

给想入坑Agent的人的建议

如果你正在考虑搭建自己的Agent系统，我的建议是：

1. 先确认你真的需要Agent

问自己一个简单的问题：你的任务能不能分成明确的、独立的步骤？如果能，那就写脚本，不要搭Agent。脚本是确定性的，Agent是概率性的。确定性的系统永远比概率性的系统更容易维护。

2. 如果真的要搭，从最底层开始

不要从LangChain开始。先从直接调API开始。只有当你的直接API调用方案已经确定存在瓶颈——比如需要多步决策、需要动态选择工具——再考虑加抽象层。

3. 关注失败模式，不要关注成功模式

Demo永远能跑通。但你要关注的是：当LLM输出格式不对的时候，你的系统会怎样？当API超时的时候呢？当模型返回的内容包含幻觉呢？大多数Agent框架在面对异常情况时的表现，远不如一个带有try-catch的脚本。

4. 预期不要超过实际

2026年的LLM仍然会在简单任务上犯错。如果把关键的决策权交给Agent，你要做好"它随时可能搞砸"的心理准备。我的建议是：Agent的输出永远是草稿，最终的判断永远是人。

最后的讽刺

现在，我唯一在用的"Agent"，就是那个87行的脚本。每天凌晨自动运行，处理得妥妥当当。

而当时我搭建的那些LangChain和CrewAI系统，已经静静地躺在GitHub仓库里，最新的一次提交是2026年3月——我最后一次试图让它们工作。

我花了3个月的时间，几千块的API费用，最后学会了一个道理：

2000年的互联网创业潮，最后赚到钱的是卖铲子的人。2026年的Agent潮也一样：卖Agent框架的人赚得盆满钵满，真正想用Agent的人，还在写脚本。

后记

这篇文章没有结论要让每个人都放弃Agent框架。事实上，在特定的企业级场景中，Agent框架确实有它的价值。但对于绝大多数个人开发者和小团队来说，先从一个简单的脚本开始，比从一个复杂的框架开始，要明智得多。

如果你现在正在纠结要不要学LangChain，我的建议是：先花30分钟写一个能直接调API的脚本。等它不够用了，再学框架也不迟。

大概率你会发现，那个脚本一直够用。