Graph Engineering:Python + LangGraph + Claude Code
从 Prompt 到 Graph AI 驱动开发大致走过几条主线:Prompt Engineering 解决「怎么说清楚」;Context Engineering(含 RAG)解决「给模型看什么」;Loop Engineering 解决「让 Agent 自我修正」——给一个任务,改代码、跑测试,失败了再继续修。 复杂业务里,单 Agent 的 Prompt Loop 很快会顶到天花板。Graph Engineering(图工程)把流程拆成有向图:节点专职分工,边负责确定性控制流,AI 只承担局部推理与代码生成。下面按「为什么需要 → 怎么划职责 → 怎么落地」写一版可落地的骨架。 不想额外起 Python 主控、只在 Claude Code 里管多阶段任务时,见 Graph Engineering:纯 Claude Code 实现。 为什么需要 Graph Engineering Loop Engineering 在「单任务、短轮次」时很好用。一旦任务变长、角色变多,常见会撞上三类问题。 上下文污染(Context Pollution) 循环次数上去后,会话里堆满历史报错、半成品 diff、无效尝试。模型要在噪声里找有效信号,表现会越来越差:重复改同一处、忽略刚写过的约束、或「修 A 弄坏 B」。根因往往不是模型突然变笨,而是上下文被污染了。 缺乏确定性控制(Nondeterminism) 若下一步完全由 LLM 在 Context 里自行决定,容易陷入死循环:同一失败路径反复尝试,或越改越散。控制流(何时重试、何时换策略、何时中止)若也交给模型,系统就缺少可预期的停机条件。 职责模糊 让同一个 Agent 同时做架构规划、写前后端、跑单测、做 Code Review,等于把多种能力边界揉进一次长会话。结果常常是:规划被实现细节冲淡,实现被 review 口径扯偏,测试结论又被前序噪声干扰。 Graph Engineering 的应对方式很直接:用有向图把复杂流程解耦为专职节点(Nodes);把控制流交还给确定性的代码(Edges);只把局部推理与代码生成交给 AI。 Graph Engineering 在说什么 可以把它看成三层分工: ...