你们听说过那个段子吗？
有个程序员参加AI比赛，评委问他用的什么框架。
他说。
评委点点头。
又问另一个，他说我手撸的循环。
全场哄堂大笑。
第三个站起来，叹了口气。
“我用了半年才发现，根本用不上这些框架。”
这事就发生在我身上。前两个是编的，第三个是我自己。
三月中旬，我盯着电脑，整整浪费了两个月。
具有的那个被称作“经理”的角色，在运行一次简单查询时，竟然强硬地调用了三次大模型。
测试的时候，我的Token费用在三天内翻了一倍。
一开始我以为是代码的问题。
我把提示词改了八遍。
没用。
翻開底層源碼，是往後的事了，才察覺它的和角色之間，多出了一道驗證機制。
不是我的问题，是框架的设计导致的。
那一刻我关掉终端，开始怀疑这三个月我到底在做什么。
为什么我不该信的“图式编排”
吹的有多狠大家都知道吧。
百分之八十七的任务成功率，状态机，机制，崩溃恢复，听起来好似无所不能的。
确实，它的源码里引擎的实现逻辑很漂亮。
但你们知道更讽刺的是什么吗？
它的那些官方文档，我去翻看了一下，这才发觉呀，所谓的“崩溃恢复”，说的是Agent会话出现了崩溃的情况，可不是你服务器出现了崩溃这种状况哟。
什么意思呢？
就是说你那栋楼的电力断了，该丢的数据照样丢。
我有客户，此客户制作了一个采购审批智能体，里面步骤长达35步，此采购审批智能体运转了三周时间，在最后两天时，因半夜内存出现溢出情况，于是所有中间状态全都消失在漆黑的不那么明亮的黑暗之中了。
切实达成了其所具备能力可达成之事，即跨越Graph会话的状态恢复。
但它没告诉你，你的基础设施出问题的时候，这些功能毫无意义。
“持久化”这个词，在LLM应用里，和我以为的意思不太一样。
源码不会骗你，但宣传语会
还有件事让我彻底改观了。
年初的时候，有那么一个公众号，其标题是《大模型对应的应用开发必定得看：没有相关基础而进入Agent框架的入门内容》。
点进去一看，全是Dify和Coze的低代码教程。
这个思路不是很滑稽吗？你教一个AI开发工程师用低代码平台？
后来我发现，一个框架的核心竞争力，从来都并非是它所吹嘘的那些功能。
看源码。永远先看源码。
即使仅仅是瞧一瞧它的以及核心模块的type定义，相较去读十篇框架对比文章而言，都要显得更为实在些。
这般项目之中，极具典型性，其在上拥有二十八万星标，此情形，无人未曾见过。
不过呢，当你切实将它运行起来之后，切实去研读它在上面的核心代码之时，才能够发觉它具备的核心竞争力并非是什么“数字员工”。
它的编排层加MCP工具抽象，才是真正的杀手锏。
别的框架要求你自己给每个API写。
它不用。
只需要调配一个JSON，告知程序存在一个MCP服务在那个地方，其余的连接的活计、鉴权的这些繁杂辛苦的事务，底层全部包揽了。
这就是看源码的魔力。
吹得天花乱坠，不如踏踏实实跑一遍。
从到，我交的学费超过二十万
在这半年期间，我针对十二种各异的Agent框架展开了调研，其中有六个是切实被投入到项目中运行过的。
，这货是微软研究出品。
代码的质量实在是非常高呀，然而呢，它的源码之中清清楚楚地写着“-”。
几个智能体将不间断地彼此进行确认，一直持续到你以手动方式终止其无尽循环为止。
有一个用于邮件自动回复的 Agent，处于测试环境当中，它为自身生成了 872 条对话记录。
我半夜被报警吵醒的时候，看着这个数字，不知道该哭还是该笑。
更离谱。
“模拟人类团队分工”是官方宣传语，然而在企业的生产环境当中，当进行质量审核时，也就是你身为Agent经理要针对Agent员工的产出展开此项工作之际——。
好家伙。
每次审核都是一次大模型调用，大模型调用就是钱，就是时间。
史上最为极端的一回测试之中，一位任务主管的验证流程运行了足足一小时，于第二十七次时方才卡住进而退出。
我们可能不需要那么复杂的框架
那几个月之后，我问了自己一个问题：
我真的需要这些框架吗？
半年后回头再看这个想法，确实有点天真。
但在那个当下，我的心态是，或许我可以简化它。
更让人困惑的是，还有一种声音说，你可以不用任何框架。
那个被泄露的51.2万行源码，引得众多人在上围观。
然后一些人开始觉得，要不我也手搓一个Agent吧。
兄弟，你清醒一点。
你家里有开源的米，不代表你要自己种水稻。
对ReAct循环进行手工实现, 对工具调用予以手工实现, 针对管理展开手工实现, 进一步将错误恢复纳入考量范围, 对观测实施相关考虑, 对成本控制进行思考判断, 如此这般一个原型完成的时候可能就会有三个月的时间流逝过去, 之后会发觉根本没办法应用到生产当中去。
我尝试过一个数据查询方面极为简单的Agent，亲手书写代码进行循环操作，历经两个月的时间，才发觉它竟然没有内置的失败后重新尝试执行的机制。
于是又要从头写。
框架的真正价值是什么？
不是让你多快上手，而是让你别重复造那些已经踩平的坑。
的引擎这部分源码，确实是有着含金量的，它的机制，以及状态机逻辑，是那种你自己写完会流泪的。
你用不上。
MCP才是最大的惊喜
看完Craft 的源码之后，我把自己先前写的 Agent 平台代码，删去了一多半组成部分。
它对我影响最大的不是UI，是工具管理方式。
于Craft 当中，整批的外部连接均一致经由MCP协议而行进。
属MCP ，为MCP ，你本地的文件系统同样是MCP 。
AI不需要关心自己在调REST API还是本地文件。
在它眼里，看到的是一堆高度标准化的Tool。
这就像给AI插了一个USB接口。
插上就能用。
这才是2026年应该有的开发体验。
不要在工具调用上消耗精力，把精力留给业务逻辑和领域模型。
怎么选？看框架源码里的这些模块
在我当下针对技术展开调研的这个时候，我会径直去开启框架的仓库，着重去看一看几个模块。
观看tools/目录是否存在，若不存在亦是徒有其表只作装饰那就径直舍弃。
针对模块的实现情况，去查看其运用了何种数据结构。要是单纯凭借一个list进行线性存储，那么对于稍微复杂了一些的场景而言，这种框架根本无法承受。
目录叫做。要知晓某个框架的代码质量，得通过查看其单测情况来判断。那些覆盖率高的，相对而言文档会更具可信度一些。
存放检查点的底层存储的逻辑，要写到什么地方去，采用什么样怎样的序列化协议，这决定了这个框架能否应用于生产环境。
最关键的是去查看，core/agent.py里，默认的实现情况。
如果一个框架的死循环处理机制就是用粗暴中断，同时没有任何智能的重试策略。
那我劝你慎重。
鉴于你自身的应用场景相较于hello world更为复杂，早晚都会碰到相同的循环状况。
AI框架的幻觉，远比你想象的严重
我花费了六个月的时间，才终于意识到，那些被分享出来的框架的数据，其中的大多数，实际上都是幻觉罢了，是真真切切的幻觉啊。
宣称自身任务成功率达87%，此数字源自何方，来自其在自身测试集上获得的结果啊。倘若更换一个数据集，或者变换一种场景，那么成功率没准会骤降一半呢。
宣称自身延迟平均为1.8秒，然而，一旦你查看了它的源码，你就会明白，这个所谓的“1.8秒”大概率是处于不进行任何复杂工具调用，并且是拥有最少步骤的理想场景。
我本人的所做的生产应用当中，有一项任务平均开展7至15回的验证循环，花费时间为6至10秒。
这才是真实数据。
所有的开源对比评测文章都值得怀疑。
之所以公众号写手无需在凌晨三点起身去修复一个陷入无限循环的Agent，是因为。
他们仅仅只要将不一样框架在上的进行一番重新排列组合那么一回，从而凑成就一篇有着热度的文章。
如果让我重来一次
我每天半夜三点，还持续处于正在修改Agent配置的状态之时，常常会对这个问题展开反思求解。
先定场景，再选框架。
不是反过来。
倘若你所从事的工作是致力于开展跨部门的长链路审批，那么的状态机的确能够发挥作用。
要是你属于RAG检索增强范畴，那么的源码当中那些查询优化举措，相较于自行从头去撰写，可要科学得多得多。
假如你仅仅只需一个客服机器人，那么Dify的可视化工作流便已足够，不要再亲自去编写了。
很多开发者（包括以前的我）都喜欢玩酷的。
就听到所说的拥有的角色扮演，那听起来可真的是极其炫酷无比呀，随后把它放置到项目之中，然而令人意想不到的是，仅仅过了半个月的时间，居然就全部给删除掉了，然后转而使用直连API了。
框架不是勋章。
它是工具。
做选择之前，先看三份东西
在架构设计方面，你不但得去查看文档，而且你绝对势必要看过源码，起码也得看过它的代码结构以及贡献者指南。
关于社区活跃度而言，的issue响应时间，以及PR合并频率，相比于star的数量，是更为真实的。不存在作者已失联的那种高质量的Agent框架。
最后要学会放弃完美主义。
我发觉好多人纠结至死，在与之间徘徊，可结果是哪个都迟迟无法产出成果。
进行挑选，就算选得不对了，最糟糕的情形中也将是于实际操作时见识到了框架的工作运行原理。并没有人要求你在最初版本就推出具备完美特性的Agent。
我删掉自己写的Agent平台代码的那个凌晨，想通了这件事：
选框架，其实是在选一种你觉得更自然的管理复杂系统的方式。
不是选最流行的，也不是选最高的。
是选那个让你能睡个好觉的。
