本地部署的Agent框架该选哪个？LangChain还是自研？

我们情况差不多，当时也卡在这几个框架上纠结了好久。LangChain确实是越用越觉得重，尤其是排查问题的时候，那个调用链绕得人头疼。后来索性用FastAPI自己搭了个轻量编排层，只留了必要的工具调用和状态管理，配合现成的向量库做RAG，反而顺很多。你们团队小的话，真不如按业务场景自己封装几个核心组件，别被框架绑架了。另外可以看看Dify，它带可视化编排，但底层不锁死，适合先用它验证流程，跑通了再决定要不要替换。

说实话我们团队也踩过一模一样的坑，LangChain那套抽象层看着方便，真排查起问题来恨不得把每个call都打上断点。特别是升级版本的时候，昨天还能跑的chain今天突然报错，查半天发现是内部改了默认参数，这种隐性成本在小团队里特别伤。

后来我们干脆用最朴素的思路自己搭了层薄薄的调度逻辑，核心就两个东西：一个把工具调用和LLM请求串起来的异步队列，加上一个支持人工回退的简易状态机。文档问答这种场景真不需要多复杂的图结构，反而直接调prompt模板加本地向量库检索，逻辑清晰又好维护。

不过自研也有个坑，就是容易被业务方临时加的需求带跑偏，所以最好提前约定好接口边界，比如统一用OpenAI兼容的function calling格式来暴露工具。你们如果主要做内部系统集成，我甚至觉得直接用FastAPI包几个独立service都比硬套框架强，每个agent做成独立微服务，互相用HTTP通信，出问题也好定位。

我们之前也踩过差不多的坑，LangChain那套抽象层确实有点重，出问题的时候翻源码要翻半天。后来干脆用OpenAI的function calling加个简单的调度器自己撸，代码量其实没想象中多，两三个人完全hold住。文档问答那块可以看看LlamaIndex，比LangChain轻不少，至少升级不会天天炸。工作流自动化如果逻辑不复杂，真没必要上LangGraph那套状态机。

两个人维护确实别碰LangChain，我后来直接拿OpenAI SDK自己撸了个循环，反而清爽多了。