其他语言本文也可以用俄语阅读：神的毁灭。这是一项实验的详细报告。我从一个真实的LangGraph代理中提取了一个神节点，并让我5个美国模型和6个中国模型首先提出如何解开它的想法，然后评估彼此的提议。之后，我尝试三种不同的方法来确定应该信任哪一个。内容概述原始问题神节点是什么，为什么它是危险的计划节点实际做了什么从柠檬中榨出柠檬水为什么要做这些，以及实验是如何设置的阶段一：模型生成提议提议表每个提议更多信息阶段二：模型评估提议评审表每个评审更多信息阶段三：湿泳衣比赛决定谁擅长什么方法一：分数是否一致？选择最佳提议方法二：通过论文比较评审选择最佳分析师方法三：意见中心和中位数再次选择最佳分析师机器神明。最后一次选择最佳分析师收获应选择哪个模型作为生成器，哪个作为评估者，以及你的心将找到平静的地方。原始问题知道怎么回事吗：你正在和大家一起建立一个实践AI代理，参加Data Sanity的课程，在快速逐渐增加特性的色彩旋涡中，你突然注意到该项目的一个内部代理有一个状态图（LangGraph）看起来是这样的：流量图 TD planner_start([开始]) --> plan[计划] plan -->|搜索| search[搜索] plan -->|ask_user| ask_user[ask_user / 中断] plan -->|反思| reflect[反思] plan -->|计算| calculate[计算] plan -->|完成| finish[完成] search -->|last_observation| observe[观察] search -->|无命中/后端故障| plan observe --> plan calculate --> plan ask_user --> observe_user[观察用户] observe_user --> plan reflect --> plan finish --> planner_end([结束]) 乍一看这只是一个可爱的章鱼——没什么好担心的。但一旦你知道这个章鱼在它那谦逊的八条腿的脑袋中需要承载多少逻辑时，立刻就会清楚我们面对的是一种反模式。在这种情况下，我们称之为神节点。计划节点隐藏了大约350行逻辑，包括迭代检查、关于区域和货币的引导问题、模式准备、获取任务路由、LLM调用、随后决策的修正等等。问题不仅仅在于函数的大小。当重要的协调隐藏在一个节点内时，图形不再是系统的表达。解释更加困难、调试更加困难、测试更加困难、修改更加危险。因此，显而易见的任务不仅仅是“把一个大函数切成小块”，而是将隐藏的控制逻辑提升到图形层面，使得结果架构变得更加清晰，更易于进一步开发。计划节点实际做了什么 ¶ 该图表旨在描述的代理，大致上是收集各种参数以进行下游计算的业务。其中一些参数它聪明地在互联网上搜索；有些它则询问用户。它所做的一切都通过一个非完全确定性的算法来进行，因为根据特定对话的上下文，获取同一参数的正确方法可能有很大不同。以下是打包到计划节点中的真实功能集：责任 隐藏在计划内的逻辑 迭代循环 增加迭代，进入新的规划步骤，检查状态 == "中止" 和 max_iters 区域引导问题 _needs_region_question() 检查和强制过渡到 ask_user 的核心.region 货币引导问题 _needs_currency_question() 检查和强制过渡到 ask_user 的核心.currency 主动分解 为需要分解成组件的字段生成 dynamic_decompositions 组装获取配方 调用 build_dynamic_recipes() 并为后续的字段采集准备任务结构 模式准备 调用 compose_ready_fields()，将准备好的组件字段合并为聚合，并更新模式 计算器限制 检查计算器尝试限制、成功或当前计算以及其他停止条件 被阻塞计算后的恢复 处理阻塞计算器场景，找到下一个数据采集任务，并在需要时为问题字段提供回退分解 一般数据采集路由 在没有LLM的情况下选择下一个数据采集任务，包括对已经打开和组件任务的快速通行 自动完成逻辑 检查所有源数据是否已被收集，是否还有任何字段需要处理，以及循环能否在没有额外步骤的情况下完成 LLM规划 收集提示上下文，调用 _llm().structured(...)，并获取 PlannerDecision Post-LLM 分解 为 m 生成附加分解。