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

同感，LangChain那套依赖链确实让人头大。我们最后用LangGraph做编排，核心逻辑自己写，反而更可控。

小团队自研别贪全，把文档解析和工具调用打磨好就够了，框架越薄越省心。

我们组之前也踩过LangChain的坑，后来干脆用FastAPI自己包了一层，核心就留了检索和工具调用，其他全砍掉。其实内部文档问答这种场景，LangChain最值钱的也就是个RAG流程模板，自研反而能逼你把数据管道和权限搞清楚。不过如果你们后面要接复杂多步agent，LangGraph还是值得再试试，但一定得锁版本。

我们团队之前也遇到一模一样的坑，LangChain那套链式调用看着灵活，真排起错来能把人绕晕。后来干脆自己封装了核心的检索和工具调用逻辑，只留了最基础的LLM接口，反而清爽很多。你们要处理的主要是内部文档，建议先画清楚流程图，自研一个轻量状态机就够用，MetaGPT那种确实杀鸡用牛刀了。不过自研前最好想清楚后续要接什么外部工具，别把接口写死。

我们内部跑了一圈下来，最后选了自研+RAG这种轻量组合，LangChain那种抽象层对2人团队确实太重了，光是追踪回调就够呛。自研的话建议把工具调用和状态机拆开，文档问答用现成向量库，工作流用简单DAG就够了。你们有考虑过直接用Dify或FastGPT这类开源产品做底座吗？虽然也重，但至少社区维护比自研省心。另外LangChain的LCEL写复杂链时排查问题真的很痛苦，不如直接裸写Python逻辑。

我们最后用LangGraph做编排，但只挑了几个稳定模块，其余全自研，这样调试总算能接受了。

同感，LangChain升级确实头疼。我们后来直接用FastAPI套LLM自己写了，几十行代码搞定，反而更顺手。

我们情况差不多，最后选了自研，只留了必要的工具调用和状态机，大概几百行核心代码。LangChain那套抽象确实香，但出了问题排查成本太高，团队小根本耗不起。自研的话建议先定义清楚“文档问答”和“工作流自动化”的边界，别一上来就想做通用平台，能跑通一个场景再扩展。另外可以看看n8n或者Dify这类轻量方案，有些编排能力能省不少事。

我们之前也踩过LangChain的坑，后来干脆用纯Python+FastAPI自己搭了个轻量agent，只留了工具调用和记忆管理两个核心模块，反而跑得很稳。你们如果只是内部文档问答，其实不需要上完整框架，把RAG流程和几个工作流节点写清楚就够了。另外想问问，你们对多轮对话的状态管理有硬性要求吗？这个往往才是自研时最花时间的部分。

我们也是两人团队，最后用LangChain但只取核心模块，其余全自己写，够用就行。