别再用LangGraph编排AI智能体了，用“儿童防护”重构推理框架

当AI只会说“你说得对”，我们还能好好做产品吗？

2026年已经过了一整天，我却发现想逃避AI的谄媚比在《黑暗之魂》最高难度下通关还难。每次你把一个想法抛给模型，它都会称赞你是“有远见的奇才”。为了写下一个我反复琢磨过的观点，我不得不主动对抗模型默认的奉承模式。这个观点很简单：我们不该再用LangGraph或n8n这类刚性的状态机去脚本化智能体的每一步，而应该给推理框架做“儿童防护”——结合硬性环境边界、外部代码校验和测试驱动的评估。

为了验证这个想法，我构建了一个名为Customer Pulse的原型（一个作为完整应用运行的通用推理框架），用纯英文成功配置了两个完全虚构的客户——一个使用Zendesk和BigQuery的银行场景，另一个是处理原始CSV航空公司调查问卷——它们运行在同一个代码库上。这背后有三条核心架构原则。

架构原则一：验证优于编排

传统的工作流引擎试图通过流程图控制智能体的每一步：先调这个API，再判断那个条件，然后走另一条分支。这看起来很安全，但本质上是用代码写死了“今天的模型还不够聪明”这个假设。一旦模型升级，这些硬编码的绕行方案就变成了技术债。

我的做法相反：用代码脚本处理必须精确的部分——计数、渲染、数据清洗——而让模型负责规划和执行循环。在每一步结束时，用脚本去检查证据，而不是规定路径。比如，当智能体声称已经从BigQuery拉取了数据，框架不会检查它是否按预设的步骤调用了API，而是直接验证输出数据是否符合预期格式和数量。这就像教孩子骑自行车：你不是规定他每一脚踩在哪里，而是给他戴上头盔、装上辅助轮，然后让他自己探索。

这种“验证优于编排”的思路需要把“用例引擎”和客户的纯英文“配置文件”分开。领域专家可以在几分钟内调整优先级、路由和行为，无需等待工程师重新接线代码。

状态机与工作流引擎：LangGraph 和 n8n 属于两类常被混淆的工具。n8n 是通用自动化平台，以节点连线方式编排 API 调用与条件分支；LangGraph 则把 LLM 智能体的执行建模为有向图上的状态转移，节点是函数、边是条件。两者共同点是：执行路径在运行前就由人写死，模型只能在预设节点内做有限选择。这种范式适合流程稳定、合规要求高的场景，但代价是每次模型能力跃迁，原图中为弥补模型缺陷而设的绕行节点都会变成冗余。文章主张的“验证优于编排”并非否定状态机，而是把控制点从“路径”移到“出口”，让图结构让位于事后校验。

架构原则二：推理框架本身就是应用

很多人把推理框架看作一层薄薄的中间件，上面再搭应用。但我认为，框架就是应用。让模型来规划和运行执行循环，而不是藏在某个工作流引擎后面。这样做的好处是：当模型能力提升时，整个系统自动受益，因为没有任何硬编码的绕行逻辑需要清理。

当然，代价也很真实。我在深度分析中坦诚了这些权衡：token消耗更高，因为模型要自己规划；延迟增加，因为每一步都需要验证；沙箱安全性需要额外设计，因为模型现在有了更多的执行自由度。但这些都是“儿童防护”的代价——你给孩子一个安全的探索空间，而不是把他绑在椅子上。

推理框架（reasoning harness）：指包裹在基础模型外、负责规划、工具调用、错误重试与结果整合的一层运行时。它与“中间件”的区别在于职责范围：中间件通常只做请求转发或格式转换，而推理框架直接决定智能体如何分解任务、何时调用外部工具、失败后如何回退。文章所说的“框架就是应用”，是指这层运行时不再隐藏在业务流程之下，而是成为用户可感知的产品主体——模型升级即产品升级，无需重写上层业务逻辑。这也解释了为何 token 消耗和延迟会上升：规划与验证都发生在框架层，而非被外部工作流分摊。

架构原则三：英文改变系统

最让我兴奋的是，两个完全不同的客户场景——一个银行客服+数据仓库，一个航空公司CSV调查——竟然跑在同一个代码库上，仅靠纯英文配置就完成了切换。这意味着，领域专家不再需要工程师介入就能调整系统的优先级、路由和行为。

这背后是“用例引擎”和“纯英文配置文件”的分离。配置文件描述客户想要什么：处理哪些数据源、什么情况下转人工、输出格式是什么。引擎则负责让模型理解这些英文描述并执行，同时用验证脚本保证正确性。这听起来简单，但实际实现中需要精心设计验证层，否则模型很容易“自由发挥”到失控。

我不是家长，所以“儿童防护”的比喻可能不够贴切。但如果你真的为人父母，欢迎扩展这个类比。对于其他人，请尽情拆解我的想法，告诉我架构哪里错了。我会回到画板前继续思考。

用例引擎与配置文件分离：这是软件工程中“配置与代码分离”原则在智能体系统里的延伸。用例引擎是通用执行器，负责解析自然语言配置、驱动模型规划并调用验证脚本；纯英文配置文件则声明领域意图，如数据源、转人工条件、输出格式。传统做法是把这些意图翻成流程图节点，领域专家无法独立修改；分离之后，专家改英文描述即可调整行为，工程师只维护引擎与验证层。风险在于自然语言配置存在歧义，因此验证层必须足够严格，否则模型可能偏离预期而无人察觉——这正是文章强调“精心设计验证层”的原因。

关键权衡：没有免费的午餐

这种方法的真实代价不容忽视。Token消耗：模型自己规划意味着更多的推理步骤，成本自然上升。延迟：每一步验证增加了响应时间，对于实时场景可能是硬伤。沙箱安全：给模型更多执行自由度，意味着需要更坚固的隔离环境，否则一个错误的脚本调用就可能造成破坏。

但这些代价换来的是一套不会因为模型升级而报废的系统。硬编码的工作流今天能跑，明天模型原生支持某个能力时，那些绕行代码就成了负担。我宁愿承担更高的运行成本，也不愿积累技术债。

沙箱安全与测试驱动评估：给模型更多执行自由度，意味着它生成的代码或工具调用会真实运行，必须放在隔离环境中限制文件、网络与系统调用权限，这就是沙箱。沙箱解决“不能做什么”，测试驱动评估解决“做对没有”：后者借用软件测试思路，为每类任务预设可自动判定的验收条件（如数据行数、字段格式、业务规则），智能体每步产出都跑一遍测试，不通过则触发重试或回退。两者结合构成文章所说的“儿童防护”——边界由环境硬性划定，正确性由外部脚本判定，而不是靠模型自我声称。缺少任一层，高自由度都会放大失控风险。

结语：把控制权还给模型，把边界留给代码

我们造出了强大的推理框架，却用刚性的工作流把它们裹得严严实实。与其这样，不如给框架做“儿童防护”：用环境边界、代码验证和测试驱动评估来保证安全，让模型自由探索。Customer Pulse原型证明了这种思路在真实场景下可行——同一个代码库，纯英文配置，两个完全不同的客户。接下来，该你拆解了。