我们的项目里，框架那层已经变成负债
上个月一个客服分流 Agent 出问题。三个月前上线，一直跑得好好的，某天开始大约 200 次里失败 1 次。日志干净得可疑——我们的 prompt 在，工具返回在，报错没有。
两个工程师查了两天。最后是在框架源码里找到的：一个并行分支的默认合并逻辑，把两个分支的返回按顺序拼进同一个消息列表，其中一个分支返回空时，另一个被覆盖掉。全程没有抛出任何异常。
两天。不是两天写代码，是两天读别人的抽象。
这件事之后我把新项目的选型改了：不引编排框架，直接用模型厂商的 SDK，加一个我们自己写的两百行状态机。
厚框架省下的是第一次跑通的时间
我不否认刚上手时的爽感。图结构一画，节点一接，可视化面板一开，demo 半小时能跑起来。这个价值是真实的。
问题在于第二次、第三次、第三十次改需求的时候，账要重新算。
具体说 LangGraph 这类。它的核心抽象是「图 + 共享状态 + reducer」，这个模型本身没毛病，毛病在于它是隐式的。你在节点里返回一个 dict，框架决定这个 dict 怎么合进全局状态、按什么规则合、冲突了怎么办——这些规则写在文档某一页，或者只写在源码里。你写的代码和实际执行的东西之间，隔着一层需要重新学习的东西。
工程师最怕的从来不是复杂，是看不见。
复杂可以拆，看不见只能猜。猜的成本是调试时间，而调试时间是 Agent 项目里最贵的东西。Agent 的失败大多是概率性的、非确定性的，你本来就只有一个模糊信号，框架再糊一层，信号就没了。
现在这个阶段，抽象是提前的
有个判断我一直没改：Agent 这个东西，最好的抽象还没被发明出来。
模型能力半年变一次。昨天必须用图编排才能做的事，今天一次带工具调用的长上下文就做完了。这种时候任何厚框架都在赌，赌自己的抽象比模型进步得快。
我赌它赌不赢。
所以你会看到工程师开始往回走。不是框架不好，是现在这个时间点，直接对着 API 写代码的信息损耗最小。一个 for 循环加一个 while，至少你知道每一步发生了什么。
教学价值我认，生产环境另说
这条我自己也犹豫过。框架在教人这件事上做得挺好——它把「Agent 大概长什么样」可视化了，一个没写过 Agent 的人看图就懂了。这个贡献不该被抹掉。
但教学工具和生产工具是两回事。教学要清晰的概念边界，生产要的是出错时我知道去哪找。
六个月后我可能被打脸。如果哪家框架把可观测性做到跟裸写一样透明，那我今天说的就不成立。我等着。
在那之前，我的标准很简单：能让工程师在凌晨两点看懂自己系统在干什么的方案，就是好方案。别的都次要。