早期 Agent 框架为什么会走向 LangGraph我们先不要急着批评 LangGraph。早期显式 Agent 框架的出现是合理的。在大语言模型能力还不稳定的时候企业级应用最怕的不是模型不够聪明而是模型不够听话。它可能不按格式输出可能跳过步骤可能忘记系统提示可能随便编工具参数可能在应该调用工具的时候直接胡说可能在应该等待人工确认的时候擅自执行。那时候如果你只是写一大段 promptYou 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 graph5. 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 Toolread_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。
