w568w

我第一次看它的文档，有类似的感觉，因为我看了一个下午都没看懂文档在说什么，而且我自己还是专门做 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 的水准吗？不好说。

@f1ynnv2 > vchat 刚看了一下原来是指这类
是的

> 原来 app 的自动测试框架已经这么强了可以直接操作 app 而且还是系统层面的
因为要无障碍适配必然要支持系统的无障碍接口（ Windows 上是 UI Automation ，macOS 上是 Accessibility API ，Android 上是 Accessibility Service ，等等），所以大部分平台都可以读取甚至操作应用控件。

macOS 应该好办吧，直接读通知就可以收消息了

发消息比较困难，建议搞个 UI 自动测试框架来做

有点意思，和早年 Intel 、华硕、联想出过的电脑棒差不多

没点进来，我还以为有什么灾难性的经历要分享呢。

哦，原来就 [一个特定型号] 的 [特定国产系统] 的 [相册 App] 的 [特定功能] 在 [特定极端（ 400GB 图片）情况下] 不好用。这就是你说的「对国产安卓彻底失望」？

那我看也别选了。这种文章我一天能写十篇：「买了 macBook 发现 Finder 没法直接读 NTFS ，问了客服也不回复我，只会打太极，对所有苹果产品彻底失望了」。

最后 101 块收。你们多多买多多骂，骂名我来背

@mikeluckybiy https://blogs.oracle.com/linux/how-fragmented-is-my-xfs-filesystem

#2 @Livid 全篇不加修改复制 AI 回复。且对问题解决没有什么帮助。

---
可以先到这里确认一下账号地区是不是真是美区（虽然确认了也没什么用）： https://policies.google.com/terms 。「 Country Version 」就是你的账号所在国家。

最主要的原因就是号太新了，我 21 年注册的美区账号，一直挂梯子，照样报这个错。不嫌麻烦就去买个老号吧。

> 目前使用的是 NAT

你看看 NAT 的 gateway 是什么呢。只要流量经过主机，就应该会被代理。桥接反而是简单问题复杂化