大家现在做Agent是用LangChain还是自己手搓？纠结好几天了

我们也是三人小队，LangChain前期爽后期改起来想骂人，现在直接裸调API加个状态机，够用就行。

记忆这块别想太复杂，短期Redis存会话，长期才丢向量库，能省一大半事。

我们组之前也纠结过这个问题，最后是拿LangChain当参考文档用，实际逻辑自己写了个轻量调度器，只用了它的Tool抽象和回调，其他全砍了。你这需求对接三个系统，建议别硬套框架，把每个API封装成独立函数，自己维护个状态机反而好调试。长期记忆我们直接塞了向量库，但只存对话摘要和关键实体，完整记录放Redis带过期时间，不然上下文一长token开销扛不住。

我们团队之前也卡在这题上，最后选了个折中方案：用LangChain的LCEL做编排，但Tool和Memory全自己写，这样既省了重复造轮子的时间，又不会被它那套抽象绑死。长期记忆我们直接上万字以内的丢Redis，超了才进向量库，因为大多数企业场景根本用不到超长记忆，别一上来就上重武器。你们飞书和Jira的对接其实难点不在框架，反而在API的限流和token刷新，自己写反而更好控。

我们团队之前也卡在这过，最后选的是LangChain的LCEL做轻量串联，但把复杂的Tool逻辑全拆出来自己写，这样既不用硬啃它那套抽象，又能保住灵活性。记忆这块我建议别直接塞向量库，短期用Redis存session，长期摘要再进向量库，不然每次检索都慢得要死。你们内部API多的话，不如自己封装个统一的HTTP工具给Agent调用，LangChain那些现成的Tool反而水土不服。

LangChain前期学起来是烦，但手搓并发坑更多，建议先用它跑通再拆。记忆这块Redis存会话，向量库丢长文，别混着用。

我们团队也是三个人搞这个，最后选了中间路线：核心流程手搓，只把LangChain当工具库用，比如拆文档、调API这种现成功能。别硬套它的Chain和Agent概念，不然调试真要命。长期记忆我们直接扔向量库，Redis只存短期会话状态，反正并发量没到需要复杂缓存的程度，先跑通业务再说。你试试把LangChain当螺丝刀而不是整个工具箱，会轻松很多。

我们之前也是仨人小团队，最后选了折中方案：核心调度自己写，工具调用和LLM接口用LangChain的Tool抽象，但不用它的Agent executor。这样既不用啃那些Chain概念，又能白嫖它的工具生态。长期记忆千万别直接塞向量库，我们踩过坑，检索延迟高还容易召回无关内容，现在是Redis存最近对话摘要，向量库只存沉淀后的关键事实。你们内部API多的话，建议先把工具注册和鉴权抽一层，后面换框架成本低很多。