LangGraph 还是 Claude Code：AI 开发流程该如何选型？

一个真实团队的选型困惑

一家正在推进研发流程 AI 化的公司，最近尝试用 LangGraph 来搭建 Web 功能与日常维护（BAU）的开发工作流。他们的目标很明确：让每位开发者都接入预定义的 LangGraph 流程来完成开发任务。

但在实际调研后，这位提问者发现了一个耐人寻味的现象——尽管 LangGraph 能把工作流编排得井井有条，真正在一线主导开发的，仍然是搭配了大量「脚手架」（harness）的 Claude Code 和 Codex。这引出了一个值得所有工程团队思考的问题：为什么确定性更强的 LangGraph 工作流，反而没能成为本地开发的主流？

reddit 讨论原帖

两种范式的本质区别

要回答这个问题，先要理清两条路线各自的定位。

LangGraph：确定性的编排引擎

LangGraph 的核心优势在于流程的确定性。它把开发步骤抽象成图（graph）中的节点与边，明确规定「先做什么、后做什么、什么条件下分支」。这种方式对于以下场景非常契合：

面向客户的 LLM 功能（customer-facing features），需要稳定、可预测的行为
BAU 与维护级别的重复性工作，流程标准化、变化少
需要审计、可复现的构建管线（build pipeline）

换句话说，LangGraph 擅长的是「把已知的、可重复的流程固化下来」。当任务边界清晰、步骤明确时，它能保证每次执行都走在同一条轨道上。

LangGraph 是 LangChain 生态下的一个编排框架，基于有向图（Directed Graph）模型，将 LLM 调用、工具调用和条件判断抽象为节点（Node）与边（Edge）。与传统的线性 Chain 不同，它原生支持循环（loop）和条件分支，使得「重试」「反思」「多智能体协作」等模式得以在受控框架内实现。其持久化（persistence）机制可以在任意节点保存和恢复状态，便于实现人机协同（human-in-the-loop）审批节点——这也是它在合规要求较高的企业构建管线中受到青睐的重要原因。理解这一底层设计有助于判断它的边界：越是结构明确、分支有限的流程，LangGraph 的优势越突出；反之，分支无法穷举时，维护图结构的成本会迅速超过收益。

Claude Code / Codex + Harness：非确定性的智能代理

另一条路线则完全相反。开发者使用 Claude Code 或 Codex，配合项目级的脚手架——静态分析、规则文档（rules）、指南（guides）、以及用于简化任务的 skills——让 AI 代理在一个受约束但灵活的空间内自主决策。

这里的关键词是非确定性（indeterministic）。skills 定义的是「能力」和「边界」，而不是「固定的执行顺序」。AI 会根据当前上下文，动态决定采用哪些能力、以什么顺序推进。这恰恰是提问者观察到的主流做法。

这里的「harness（脚手架）」在 AI 辅助开发语境中，指的是一套围绕 AI 代理构建的外部约束与能力扩展体系，而非测试领域的测试桩。典型组成包括：静态分析工具（如 ESLint、Pyright）在代码生成后自动校验质量；rules/guides 文档以自然语言形式向 AI 传达团队规范、架构约定和禁止操作；skills（也常见于 Claude Code 中称为「slash commands」或「custom commands」）将常用的多步操作封装为可复用指令，供 AI 按需调用。这套组合的本质是「软约束」：它不规定执行顺序，而是划定行为边界，让 AI 代理在边界内自主规划路径。harness 质量的高低，直接决定了代理产出的稳定性，因此精心维护 rules 和 skills 是该路线工程化落地的关键投入。

为什么刚性流程难以主导功能开发

提问者的核心疑问是：既然预定义步骤听起来更规范，为什么 LangGraph 没能在本地开发中普及？答案很可能藏在「刚性」二字里。

功能开发本质上是探索性工作

真实的功能开发很少能被提前完整建模。需求会变、边界情况层出不穷、重构与调试穿插进行。这类工作更像是一场持续的探索，而非流水线作业。把探索性任务强行塞进固定的图结构中，往往会遇到两个问题：

覆盖成本高：每一个未预料到的分支，都需要在图里新增节点和条件判断，维护负担快速膨胀。
灵活性受限：当现实偏离预设路径时，刚性流程要么中断，要么产出不符合预期的结果。

而 Claude Code 这类代理式方案，天然适合处理这种模糊、多变的场景——它不需要你预先穷举所有路径，只需给出好的约束和上下文。

Harness 提供了「软约束」

值得展开的一点是：Claude Code + harness 并非完全放任自流。静态分析会拦截低质量代码，规则和指南会引导 AI 的行为，skills 会封装常用操作。这套组合本质上是在用软约束替代硬编排——既保留了灵活性，又不至于失控。

这可能正是它比 LangGraph 更受一线欢迎的根本原因：在确定性与灵活性之间，找到了更适合日常研发的平衡点。

各自的取舍：一张对照表

维度	LangGraph 工作流	Claude Code/Codex + Harness
执行方式	确定性、可复现	非确定性、上下文驱动
适用场景	BAU、维护、面向用户的 LLM 功能	功能开发、探索性任务
灵活性	低，路径固定	高，动态决策
维护成本	随分支增加而上升	依赖 harness 质量
可控性	强，流程可审计	中，靠软约束保证

给团队的实用建议

从这场讨论中，可以提炼出一条并非「二选一」的思路：两种范式各有主场，混合使用往往更明智。

对于标准化、重复性高、需要强可控性的构建与维护管线，LangGraph 的确定性编排是加分项。而对于需求多变、以探索为主的功能开发，Claude Code/Codex 配合精心设计的 harness 更能发挥效率。

如果一定要在本地开发中引入 LangGraph，关键不在于「用不用」，而在于「用在哪个环节」。把它放在最标准化的那部分流程上，而把探索空间留给代理式工具，或许才是当下更务实的答案。

需要说明的是，本文基于一则 Reddit 讨论帖整理，反映的是社区实践者的观察与思考，而非严格的量化对比。不同团队的技术栈与工作习惯不同，最终选型仍需结合自身情况验证。