最近要做一个复杂的 Agent ,输入数据和提供 MCPTools ,让 AI 自主决策路径,循环调用工具,再根据工具结果继续决策,直到使用工具无法获得更多有价值的信息,在整合现有收集到的信息给出结论。 可以理解为一个破案过程。整过过程流程不固定、无法用 Dify 、n8n 这样的工作流预设好。
最初的原型 Demo 我是基于 OpenManus 开发的。MCPTools 使用 FastMCP 自写的 MCP Sever ,提供 SSE 供 OpenManus 调用。目前感觉 OpenManus 效果勉强令人满意,感觉还有提升空间,优化提示词、优化 MCPTools 之后获得了一点点提升。现在就寻思会不会是 OpenManus 不够优秀,或者说有更好的框架适合我们的场景。
于是开始了信的调研。
我从很多渠道调研,都说 LangGraph 是最好的选择,包括 AI 也这么说。
但是详细去了解、学习 LangGraph 。发现 LangGraph 的思维很奇怪,自己也是老 IT 人了,各种开发语言也写了几十个中小小项目了,第一次遇到一个东西研究了好几天,连理念都无法理解.....
1
zhengxiaowai 9 小时 30 分钟前
本质是一个新东西,新概念。当前还是百花齐放的状态,所以肯定混乱,很多传统的概念都不适用
|
2
HannibaI 9 小时 29 分钟前
+1 ,所以我自己撸了
|
3
hex2ocean 9 小时 20 分钟前
LZ 方便分享下在理念方面有哪里不好理解吗?最近这边也在调研相关内容
|
4
qieqie 9 小时 20 分钟前
LangChain, LangGraph 本来就是出名趁早,就成了风口上的猪,作者水平有限。
建议看看 Google ADK, Agno, OpenAI Agents 这些。 |
5
w568w 9 小时 16 分钟前 我第一次看它的文档,有类似的感觉,因为我看了一个下午都没看懂文档在说什么,而且我自己还是专门做 AI 方向的。
和同事讨论了一下之后,LangGraph 最大的一个问题就是:它希望实现一些很 nice 的理论特性,但是忽略了给 dev 过程带来的设计困难。 比如说 LangGraph 顾名思义地把你的整个 Agent 工作流构建成一个有向图 workflow 。但是线性的代码书写方式对于构建有向图是非常 awkward 的。比如说一个循环和分支结构,正常写代码就是: while condition { do A do B update condition } 但写成有向图会变成: # 创建节点 a = create_node(A) b = create_node(B) condition_update = create_node(ConditionUpdate) end = create_node(End) # 添加边 add_edge(a, b) add_edge(b, condition_update) add_edge(condition_update, a, end, cond=lamdba state: state.condition) # 执行图 state = State(condition=True) output = execute(state) 哪一种方式更易读?至少在这种场景下,显然是前者。那为什么 LangGraph 要选择后者呢?主要原因是它等于把控制流委托给 LangGraph 的引擎去做,这样就能自动支持状态存储/恢复、断点续行等特性,也就是说 LangGraph 是以一种设计复杂管线的思维在做 Agent 设计。 但现在的 Agent 果真有这么复杂吗?我的理解是: - 如果在原型设计阶段,这种图模式不合适,因为修改成本高、和状态耦合太深。 - 如果是简单的工作流,根本没必要使用图模式,就像上面的例子。 - 如果是复杂的工作流,这种模式的上限也会制约系统的上限,尤其是关于状态管理和分支处理的部分。比如现在 LangGraph 为了支持错误 Node 重新执行,又搞出了钩子和中间件,系统复杂度被拔得太高了,学习成本也直线上升。那与其用这种框架,不如自己手搓适合业务的实现。这种情况下,LangGraph 也不适用。 所以 LangGraph 在大部分场景下真的是鸡肋,有点 Spring 之于 Java 的感觉。但他的 API 都是搞 AI 的人设计出来的,这帮人的工程能力我不好点评(因为我自己也是),能达到 Spring 的水准吗?不好说。 |
6
ychost 9 小时 12 分钟前
langchain 就是出名早,实际用起来很糟糕,个人觉得 OpenAI 的 openai-agents-python 就刚刚好,简单直接,没那么多弯弯绕绕
|
8
looplj 9 小时 7 分钟前
LangGraph 和 agent 应该不是同一个东西吧,
一个人工固定编排,要给让 llm 自主决策。 |
10
edisonwong 7 小时 46 分钟前
最近也在研究。确实有些东西,官网介绍一眼你看不出它是做啥的,有啥用。然后 docs 里弯弯绕绕,晦涩难懂
|
11
comeondewei 6 小时 24 分钟前 via iPhone
一开始是用 chain ,是因为当时 LLM 被当成文本函数,主要需求是顺序组合 Prompt 和工具;后来发现 Agent 本质是有控制流和有状态的系统,chain 的表达能力不够,才改成 graph
|
12
comeondewei 6 小时 22 分钟前 via iPhone
所以现在 langchain 已经不是当年的字面意思了,是一个品牌(狗头)
|
13
comeondewei 6 小时 19 分钟前 via iPhone
顺便吐槽,langchain 的工程能力确实一般,变全是破坏级更新,很多实现都非常草台,就拿 deepagent 来说,代码质量太差,一团浆糊。官方文档有一部分写得,也是不知所云
|
14
bytesfold 5 小时 56 分钟前 via iPhone
用过 NetworkX 和 GraphDB 的好像不那么难理解
|
15
syncnano 3 小时 55 分钟前
我觉得很好用:当 Agent 的能力越来越庞大的时候 graph 相较于 chain 的表达能力就直线上升了,我在调研过程中层放弃 langgraph 转而手搓各种节点的跳转和组合,后来 node 越来越多又拥抱 graph 了。不过 createnode addedge 这一套确实有点丑,目测工程化是个挑战,但 graph 的方向应该是对的(在真正的 agent 时代来临之前)
|
16
Lemonadeccc 3 小时 28 分钟前
pocketflow 就几百行感觉理解概念还挺好的
|
17
aarontian 3 小时 21 分钟前
我前几天也抽空在调研,感觉一头雾水,提了个需求让 AI 帮我写了套 demo ,也乏善可陈,很多东西直接告诉我该库不支持需要引用其他库/自己实现,没看出来比我自己撸的 workflow 好在哪里。
但因为我确实(短时间内)看不懂文档,一度怀疑是不是我的理解能力下降了 |
18
yplam 2 小时 47 分钟前
不知到其他 Agent SDK 有没有这种功能,但 LangGraph 围绕 State 进行流程图式的编排我觉得是 Agent 开发上的一种质的飞跃
|