没有稳定的抽象，框架都是假的

做 agent，第一步通常是挑一个框架。LangChain、LangGraph、CrewAI、Dify，名单很长，每一个都说自己解决了 agent 开发的复杂度。但摊开看，它们统一的不是 agent，是流程图。

框架统一的是流程图，不是 agent

框架有用，是因为它把真有共性的东西收拢成一套结构，让人不必每次从头搭。这件事成立有个前提：被收拢的对象已经定型。Spring 那一类框架立得住，是因为“对象、依赖、生命周期”在企业应用里稳定了几十年，结构清楚，边界清楚。框架照着稳定结构去统一，统一到的就是真东西。

agent 当时不具备这个前提。“agent 是什么”还没有答案。框架没有稳定的内部结构可抓，只能去抓表面能观察到的东西——调用按什么顺序发生，于是有了 Chain；调用之间有分支，于是有了 Graph、Node、Edge。这些词来自一次 agent 运行的流程图，不是 agent 本身的零件。

流程图会变，因为业务会变。客服的流程、风控的流程、写代码的流程，没有一张图能套住另一张。最关键的那个决定，agent 什么时候停，更是一场一个样：有的跑一轮就结束，有的要迭代到收敛，有的要等人点头。终止条件落在业务里，不落在框架里。框架给得了画图的笔，给不了图本身。

那些唬人的概念，拆开都是普通代码。记忆是一个列表，检索是调用前查一次，循环是一个 while。每一个单看都不复杂。“框架”这个词带来的分量，多半来自叙事，不来自技术。“做了一个 agent 编排平台”比“封装了几个 API 调用”好讲太多。叙事先把复杂度讲大，框架再来解决自己讲出来的复杂度。

在还没有稳定抽象的地方硬造框架，结果是注定的：能统一的只剩表层套路。那层套路对业务不承重，却要人先学它的概念、再受它的约束，出了问题还得穿过它去定位。代价是真的，收益是叙事。

框架是答案的产物，不是答案本身。一个领域先有稳定的抽象，框架才有东西可以统一；抽象没立起来之前，所有框架都只能在表面打转。

所以 agent 工程的第一个问题，从来不是“用哪个框架”，是“agent 到底是什么”。这个问题当时悬而未决。这本书就从这里出发。