早期 Agent 框架为什么会走向 LangGraph？

我们先不要急着批评 LangGraph。

早期显式 Agent 框架的出现是合理的。

在大语言模型能力还不稳定的时候，企业级应用最怕的不是模型不够聪明，而是模型不够听话。

它可能不按格式输出，可能跳过步骤，可能忘记系统提示，可能随便编工具参数，可能在应该调用工具的时候直接胡说，可能在应该等待人工确认的时候擅自执行。

那时候，如果你只是写一大段 prompt：

You are a helpful enterprise assistant. Please follow these rules... Step 1... Step 2... Step 3... Never do X... Always do Y...

结果很可能是：今天能用，明天崩；简单任务能用，复杂任务崩；demo 能用，生产环境崩。

于是工程师自然会想：

既然模型不可靠，那就不要让它决定流程。我们把流程写死。

这就是 LangGraph 这类框架的土壤。

它们本质上是在用传统软件工程的方式约束 LLM：

分类节点 -> 路由节点 -> 工具节点 -> 审批节点 -> 总结节点 -> 输出节点

每一步都有明确状态，每条边都有条件，每个节点都可以独立测试。

从企业工程视角看，这很诱人。因为它看起来可控、可观测、可审计、可恢复。

所以早期 Agent 框架不是错的。它们是在特定历史阶段，对“不可靠模型”的一种工程补丁。

2. 但问题来了：Prompt 爆炸被转移成了 Graph 爆炸

早期大家抱怨 prompt 爆炸。

所有规则都塞进 system prompt，最后 prompt 越来越长，越来越难维护。不同业务逻辑、工具说明、安全策略、输出格式、异常处理，全都混在一起。

于是我们引入了 graph，希望把逻辑拆开。

但拆着拆着，新的问题出现了：

Prompt 爆炸没有消失，只是变成了 Graph 爆炸。

原来一个自然语言很容易表达的规则：

当用户要求发邮件时，如果意图明确且收件人明确，可以发送； 如果用户只是让你帮忙写一封邮件，就只创建草稿； 如果内容敏感，需要人工确认。

如果写成图，就可能变成：

intent_detection_node recipient_validation_node sensitivity_check_node draft_or_send_router human_approval_node send_email_node final_response_node

然后你还要定义 state schema、edge condition、error branch、retry branch、fallback branch。

这时候系统看起来很工程化，但也开始变得僵硬。

更讽刺的是，很多这种规则，本来正是 LLM 最擅长理解的东西。我们却用一堆代码节点把它提前硬编码了。

这就引出一个核心问题：

你到底是在利用 LLM 的智能，还是在努力绕开 LLM 的智能？

3. 严格代码流程的泛化能力，很多时候不如 LLM

传统软件工程有一个默认假设：明确流程优于模糊推理。

这在普通业务系统里当然成立。银行转账、库存扣减、权限校验、订单状态机，都应该由确定性代码控制。

但 Agent 面对的问题不完全一样。

Agent 经常处理的是半结构化任务：

帮我整理这批邮件 看一下这个项目有没有风险 帮我分析这些日志 根据这几份文档写个回复 检查这段代码哪里可能有问题

这类任务的难点不在于“流程不够确定”，而在于“情况太多，无法提前枚举”。

如果你用 graph 强行拆流程，就会遇到一个问题：

你写下的每一条边，都是对未来场景的一次假设。

假设越多，系统越脆。

而 LLM 的优势恰恰是能在没有完全枚举规则的情况下，根据上下文做出合理判断。

所以对于大量通用 Agent 场景，严格工作流并不会让系统更聪明，只会让系统更像一个复杂但笨重的表单流程。

这就是为什么很多看起来很漂亮的多 Agent / LangGraph demo，真实落地时会变得很尴尬：

图很复杂，效果一般。 节点很多，泛化很差。 架构很漂亮，维护很痛苦。

4. Skill 的出现，是一个关键转折

我认为 Skill 概念的出现非常重要。

因为它解决的是早期 Agent 框架真正想解决的问题：如何让模型稳定地执行某类任务。

但 Skill 的解决方式和 Graph 不一样。

Graph 的思路是：

你不可靠，所以我用代码管住你。

Skill 的思路是：

你已经足够聪明，所以我给你一份可执行的行为说明书。

这两者差别很大。

一个 Skill 可以包含：

任务目标 操作步骤 注意事项 工具使用规则 输入输出格式 常见错误 示例 边界条件

它不是简单 prompt，也不是硬编码流程。它更像一个“可加载的专业操作手册”。

关键是：模型现在越来越能读懂并遵守这种手册。

早期模型可能看完 Skill 也乱来，所以工程师必须写 graph。

但如果模型已经能比较稳定地遵循 Skill，那么大量显式 graph 就不再必要。

此时更好的结构是：

Model + Tools + Skills + Memory + Policy

而不是：

Model hidden inside a giant workflow graph

5. LangChain 的 Middleware，其实暴露了这个趋势

LangChain 现在引入 middleware，是一个很有意思的信号。

表面上看，这是为了增强create_agent。

但从架构角度看，它说明了一件事：

官方也意识到，不应该让用户为了扩展一个标准 Agent，就去手写完整 LangGraph。

create_agent本质上是一个固定的标准 Agent loop。

大概就是：

model -> tool -> model -> tool -> ... -> final answer

而 middleware 负责处理横切逻辑：

before_model after_model wrap_model_call wrap_tool_call human-in-the-loop PII detection summarization retry fallback logging

这其实很像 Web 框架。

在 Web 开发里，我们不会为了加日志、鉴权、限流、压缩、异常处理，就重新设计 HTTP 请求流程。我们会用 middleware、filter、interceptor。

Agent 也是一样。

如果标准Model <> Toolloop 已经足够通用，那么大部分扩展都不应该改变图结构，而应该作为 middleware 插入运行时。

所以我甚至觉得 LangChain 现在的架构是在“去 LangGraph 化”：

LangGraph 仍然是底层运行时， 但普通用户不应该直接面对它。

这不是说 LangGraph 没用。

而是说：

LangGraph 不应该成为普通 Agent 扩展的默认接口。

6. “Email Agent” 是一个典型的抽象膨胀

LangChain 文档里有一类示例，会把 email 做成一个独立 agent，然后再放进 LangGraph workflow。

技术上当然可以。

但从抽象建模看，这很值得怀疑。

email 到底是什么？

如果只是发邮件、读邮件、搜索邮件，那它显然是 Tool 或 MCP Tool：

read_email search_email send_email create_draft

如果是“如何写一封专业邮件”“如何回复客户投诉”“如何按照公司语气写邮件”，那更像 Skill。

只有当任务变成：

帮我处理今天所有邮件，判断哪些要回复，哪些要归档，哪些要提醒我。

这时候 email 才值得成为一个 Agent。

因为它有自己的目标、循环、判断、工具集合和中间状态。

所以问题不是“email agent 能不能做”。当然能。

问题是：

我们是不是太容易把一个能力域包装成 Agent 了？

这几年 Agent 框架里有一种抽象膨胀：

File Agent Email Agent Calendar Agent Browser Agent GitHub Agent Database Agent CRM Agent

听起来很高级。

但很多时候，它们只是工具集合外面套了一层 LLM。

真正的判断标准应该是：

这个东西是否需要独立的目标驱动循环？

如果不需要，它就是 Tool。

如果需要专业说明，它是 Skill。

如果需要连接外部系统，它是 MCP。

如果需要自治循环，它才是 Agent。