比较Fable及其他10个LLM在重构LangGraph上帝节点方面的表现

# 诸神黄昏：Fable 与另外10个LLM在代码重组任务上的对比 来源：https://wtf.korridzy.com/twilight-of-the-gods/ 其他语言：本文另有俄语版本：Гибель богов（https://wtf.korridzy.com/ru/gibel-bogov/）。 这是一次实验的详细记录。我从一个真实的LangGraph智能体中取出了一个"神节点"，先让5个美国模型和6个中国模型分别提出解耦方案，再让他们互相评价这些方案。之后，我尝试了三种不同方法来判断在这个问题上该信任谁。 **目录** - [原始问题](#the-original-problem) —— 什么是神节点，为什么它很危险 - [`plan`节点的实际行为](#what-the-plan-node-actually-did) - [柠檬变柠檬水](#lemonade-from-lemons) —— 为什么做这一切，以及实验如何设置 - [第一阶段：模型生成方案](#stage-one-the-models-generate-proposals) - [方案对照表](#the-proposals-table) - [各方案详解](#a-bit-more-on-each-proposal) - [第二阶段：模型评价方案](#stage-two-the-models-evaluate-the-proposals) - [评价对照表](#the-reviews-table) - [各评价详解](#a-bit-more-on-each-review) - [第三阶段：湿泳衣竞赛](#stage-three-the-wet-swimsuit-contest) —— 判断谁擅长什么 - [方法一：分数是否一致](#approach-one-do-the-scores-agree) —— 选出最佳方案 - [方法二：按论点比较评价](#approach-two-comparing-reviews-by-theses) —— 选出最佳分析师 - [方法三：意见中心与medoid](#approach-three-center-of-opinion-and-medoid) —— 再次选出最佳分析师 - [机械降神](#deus-ex-machina) —— 再次选出最佳分析师 - [结论](#takeaways) —— 哪个模型适合做生成器，哪个适合做评估器，以及你的内心将在何处获得安宁。 ## 原始问题¶（https://wtf.korridzy.com/twilight-of-the-gods/#the-original-problem） 事情是这样的：你正和伙伴们在Data Sanity（https://datasanity.dev/）的课程上构建一个实践型AI智能体，在快速叠加功能的缤纷旋涡中，你突然注意到项目内部的一个智能体的状态图（LangGraph）看起来像这样： ```mermaid flowchart TD planner_start([START]) --> plan[plan] plan -->|search| search[search] plan -->|ask_user| ask_user[ask_user / interrupt] plan -->|reflect| reflect[reflect] plan -->|calculate| calculate[calculate] plan -->|finish| finish[finish] search -->|last_observation| observe[observe] search -->|no hits / backend failure| plan observe --> plan calculate --> plan ask_user --> observe_user[observe_user] observe_user --> plan reflect --> plan finish --> planner_end([END]) ``` 乍一看，这只是一只可爱的小章鱼——没什么好担心的。但一旦你了解到这只章鱼需要在它那小小的八条腿的脑袋里容纳多少逻辑，立刻就会明白我们面对的是一个反模式。在此，我们称之为"神节点"。 `plan`节点隐藏了大约350行逻辑，包括迭代检查、关于地区和货币的引导问题、模式准备、采集任务路由、LLM调用、随后的决策修正等等。问题不仅仅在于函数的大小。当重要的编排逻辑被隐藏在一个节点内部时，图就不再是系统的表示了。它变得难以解释、难以调试、难以测试，并且修改起来更加危险。因此，明显的任务不仅仅是"把一个大的函数切分成小块"，而是把隐藏的控制逻辑提升到图层面，使最终的架构更加清晰，更易于后续开发。 ### `plan`节点的实际行为¶（https://wtf.korridzy.com/twilight-of-the-gods/#what-the-plan-node-actually-did） 这个图所描述的智能体，大体上负责为下游计算收集各种参数。其中一些参数它巧妙地通过互联网搜索获取；另一些则向用户询问。它通过一个不完全确定性的算法来完成这一切，因为根据特定对话的上下文，获取同一参数的正确方式可能有很大差异。 以下是打包在`plan`节点中的实际函数集合： | 职责 | `plan`内部隐藏了什么逻辑 | |------|--------------------------| | 迭代循环 | 递增`iterations`，进入新的规划步骤，检查`status == "aborted"`和`max_iters` | | 地区引导问题 | `_needs_region_question()`检查和强制转向`ask_user`以获取`core.region` | | 货币引导问题 | `_needs_currency_question()`检查和强制转向`ask_user`以获取`core.currency` | | 主动分解 | 为需要拆分成组件的字段生成`dynamic_decompositions` | | 组装采集配方 | 调用`build_dynamic_recipes()`并准备后续字段采集的任务结构 | | 模式准备 | 调用`compose_ready_fields()`，将准备好的组件字段合并成聚合体，并更新`schema` | | 计算器限制 | 检查计算器尝试次数限制、成功或已进行的计算以及其他停止条件 | | 计算被阻塞后的恢复 | 处理计算器被阻塞的场景，找到下一个数据采集任务，必要时对问题字段进行后备分解 | | 通用数据采集路由 | 不使用LLM选择下一个数据采集任务，包括对已打开和组件任务的快速通道 | | 自动完成逻辑 | 检查是否所有源数据都已收集，是否还有字段需要操作，以及循环是否可以在没有额外步骤的情况下结束 | | LLM规划 | 收集提示上下文，调用`_llm().structured(...)`，获取`PlannerDecision` | | LLM后分解 | 如果模型选择的字段需要拆分成组件，则生成额外的分解 | | 决策重定向与归一化 | 对派生字段的决策进行重定向，强制将`ask_user -> search`（对于更适合搜索的字段），以及LLM之后的其他确定性重写 | | 字段级别的重试与限制 | 检测重复搜索，限制`search`和`ask_user`的次数，一旦用尽则切换到`ask_user`、`reflect`或`finish` | | 计算决策修正 | 修复过早的`finish`：如果计算尚未完成，则将决策重写为`calculate`或转入额外的重新评估步骤 | | 记账状态管理 | 重置或更新`decision`、`decision_origin`、`llm_failed`、`status`以及其他伴随分支的临时标志 | | 日志与事件分发 | 记录最终决策，发出进度事件，组装最终状态更新后在节点返回 | ## 柠檬变柠檬水¶（https://wtf.korridzy.com/twilight-of-the-gods/#lemonade-from-lemons） 因此，我们发现自己处于一个很多人如今都会非常熟悉的情况。克劳德先生用意大利面条为我们雕刻了一件小小的杰作。梳理这些意大利面条远没有像不加审查地一个接一个地叠加功能那么有趣。但只有当你意识到可以用制造熵增的同一个工具来减少熵时，情况才会改变。而这正是一个更令人愉快的想法。 但是，你能把代码解耦的工作托付给那个一有机会就兴高采烈地把代码缠在一起的同一个模型吗？为了回答这个问题，我决定从不同的模型中收集几个独立的架构方案，并比较它们给出的建议。 11个模型被邀请走上评判台： - GPT-5.4 - GPT-5.5 - DeepSeek-4-pro - Gemini-3.1-pro - GLM-5.1 - Kimi-2.6 - MiMo-2.5-pro - Opus-4.7 - Qwen-3.6-plus - Qwen-3.7-max - Fable-5 首先，每个模型都提出了自己拆分`plan`的方案。然后，模型切换到评估模式，读取所有已完成的方案，并对它们进行排名。为了确保我收集的是独立意见，而不是对一个幸运文本的转述接力，强制执行以下条件： - 在生成方案时，模型不能看到彼此的工作。 - 在生成分析时，模型看到了所有方案，但看不到任何其他分析。 - 每次运行都在新的会话中进行。 所有工作均在OpenCode中完成，使用Oh My Openagent插件，每个模型都使用最大推理努力。 ## 第一阶段：模型生成方案¶（https://wtf.korridzy.com/twilight-of-the-gods/#stage-one-the-models-generate-proposals） 在第一阶段，每个模型都提出了自己的方法，将`plan`节点的逻辑提升到图层面。用于生成每个方案的提示（仅输出文件名不同）： ``` 查看 docs/planner-graph-ref/current-graph.md。看起来"plan"节点包含了太多逻辑。请给出一个方案，将这些逻辑移到图层面，输出到 -proposal.md ``` ### 方案对照表¶（https://wtf.korridzy.com/twilight-of-the-gods/#the-proposals-table） | 模型 | 图形风格 | 核心思想 | |------|----------|----------| | Fable-5 | 平衡型，5阶段 | 将`plan`拆分为`tick -> prepare -> select -> decide -> guard`：将引导问题和限制移入`tick`，状态准备移入`prepare`，确定性分支移入`select`，模型调用移入`decide`，模型后决策修正移入`guard` | | GPT-5.4 | 中等程度，基于阶段 | 与Fable-5几乎相同的布局，但将初始地区和货币问题从入口节点中抽出，放入单独的`bootstrap_gate` | | GPT-5.5 | 更详细，更规范 | 尽可能形式化循环的记账逻辑：单独提取模式准备、决策归一化、重试和计算器策略 | | DeepSeek-4-pro | 紧凑型，4阶段 | 将整个循环压缩为四个大阶段，并将LLM后的调整保留在单个`adjust`节点中 | | Gemini-3.1-pro | 粗粒度，极简 | 大幅粗化图形：将几乎所有确定性检查折叠进`evaluate_rules`，并将LLM作为单独的最终阶段 | | GLM-5.1 | 保守型，两步 | 进行最小安全拆分：循环前一个预检查，以及一个共享节点来选择下一步动作 | | Kimi-2.6 | 详细流水线 | 显式分离引导、计算器门控、任务采集，以及决策后的专用强制策略层 | | MiMo-2.5-pro | 中等粗粒度 | 将图形拆分为大块`guards -> acquire -> decide`，但并未暴露每个单独的策略检查 | | Opus-4.7 | 最大程度分解 | 将几乎每个隐藏策略都变成单独的门控或修正器，然后全部汇入`dispatch` | | Qwen-3.6-plus | 中等详细程度 | 提取预检查和分解作为单独阶段，并通过额外的完成检查来运行完成逻辑 | | Qwen-3.7-max | 非常详细的流水线 | 展开几乎整个隐藏状态机：单独检查、后处理、上限强制和最终路由 | ### 各方案详解¶（https://wtf.korridzy.com/twilight-of-the-gods/#a-bit-more-on-each-proposal） #### Fable-5¶（https://wtf.korridzy.com/twilight-of-the-gods/#fable-5） ```mermaid flowchart TD planner_start([START]) --> tick[tick] tick -->|aborted / max_iters| finish[finish] tick -->|region or currency missing| ask_user[ask_user / interrupt] tick -->|otherwise| prepare[prepare] prepare --> select[select] select -->|deterministic decision found| guard[guard] select -->|no decision| decide[decide / LLM] decide --> guard guard -->|search| search[search] guard -->|ask_user| ask_user guard -->|reflect| reflect[reflect] guard -->|calculate| calculate[calculate] guard -->|finish| finish search -->|last_observation present| observe[observe] search -->|no hits or backend failure| tick observe --> tick calculate --> tick ask_user --> observe_user[observe_user] observe_user --> tick reflect --> tick finish --> planner_end([END]) ``` Fable-5提出将隐藏逻辑分布在五个阶段中。`tick`负责迭代的起始：步计数器、`status == "aborted"`停止、`max_iters`限制，以及关于`region`和`currency`的初始问题。准备层进入`prepare`：主动分解、为后续数据收集组装配方，以及`compose_ready_fields`调用。接下来，`select`在不调用主模型的情况下运行确定性选择链。这里包括计算器检查、对已收集数据的快速通道、自动完成，以及跟随阻塞计算的数据收集分支。如果`select`找不到确定性答案，控制权传递给`decide`，它只调用模型并构建结构化决策。然后`guard`将派生字段的决策重定向、强制切换到更适合在线搜索的字段、重复操作限制，以及在最终路由到`search`、`ask_user`、`reflect`、`calculate`或`finish`之前的调整全部集中在一个地方。以前这些重写和限制分散在`plan`的末尾。动作节点在这个过程中不变；它们只是不再返回到旧的`plan`节点，而是返回到`tick`。这种拆分使架构更加可观察。从图中你已经可以判断出确定性决策在哪里做出，哪里需要LLM，以及决策在哪里通过了限制和修正层。最重要的发现是`decision_origin`。它让共享的`guard`能够区分哪些决策来自LLM，哪些是确定性找到的，从而避免对每个分支不加区分地应用相同的策略。该设计也有弱点：并非所有LLM调用都被移入`decide`，并且`guard`仍然是一个相当密集的节点。 #### GPT-5.4¶（https://wtf.korridzy.com/twilight-of-the-gods/#gpt-54） ```mermaid flowchart TD START --> tick tick -->|continue| bootstrap_gate tick -->|terminal| finish bootstrap_gate -->|needs region/currency| ask_user bootstrap_gate -->|ready| prepare_context prepare_context --> acquisition_gate acquisition_gate -->|deterministic decision| decision_policy acquisition_gate -->|needs LLM| llm_plan llm_plan --> decision_policy decision_policy -->|search| search decision_policy -->|ask_user| ask_user decision_policy -->|reflect| reflect decision_policy -->|calculate| calculate decision_policy -->|finish| finish search -->|last_observation| observe search -->|no observation| tick observe --> tick calculate --> tick reflect --> tick ask_user --> observe_user observe_user --> tick finish --> END ``` GPT-5.4的布局几乎与Fable-5完全相同。它也有一个循环入口节点、上下文准备、模型前的确定性分支、单独的模型调用以及之后的单一决策修正层。关键区别在于，初始的地区和货币问题并没有留在`tick`内部，而是被拉入单独的`bootstrap_gate`。因此`tick`只负责步骤的开始、迭代计数器和停止检查，而`bootstrap_gate`决定是继续执行还是必须先送用户到`ask_user`。其余阶段在实质上与Fable-5大致匹配，只是命名更加显式。GPT-5.4给出了清晰可行的指导。其关于反模式的部分使得重构能够很好地执行，并真正理解目标。 #### GPT-5.5¶（https://wtf.korridzy.com/twilight-of-the-gods/#gpt-55） GPT-5.5的提案（原文此处有流程图，但用户提供的文本中似乎缺失了GPT-5.5的流程图。根据上下文推测，其核心思想是更详细、更规范地形式化循环的记账逻辑。为保持连贯，这里仅翻译后续文字。） GPT-5.5提出了一个非常详细的流水线，将循环的记账逻辑尽可能形式化。它单独提取了模式准备、决策归一化、重试和计算器策略。该方案强调通过显式的阶段来分离关注点，使得每个策略的职责更加清晰。 #### DeepSeek-4-pro¶（https://wtf.korridzy.com/twilight-of-the-gods/#deepseek-4-pro） DeepSeek-4-pro采取了紧凑的4阶段方法。它将整个循环压缩为四个大阶段，并将LLM后的调整保留在单个`adjust`节点中。这种设计减少了节点数量，但可能牺牲了一些细粒度的可观察性。 #### Gemini-3.1-pro¶（https://wtf.korridzy.com/twilight-of-the-gods/#gemini-31-pro） Gemini-3.1-pro采用了粗粒度的极简主义方法。它将几乎所有确定性检查折叠进一个名为`evaluate_rules`的节点，并将LLM调用作为单独的最终阶段。这种设计强调了简单性，但可能使某些策略的修改变得不那么直接。 #### GLM-5.1¶（https://wtf.korridzy.com/twilight-of-the-gods/#glm-51） GLM-5.1采取了保守的两步拆分。它只进行最小的安全拆分：在循环之前添加一个预检查节点，以及一个共享节点来选择下一步动作。这种设计风险最低，但可能没有充分利用图形抽象。 #### Kimi-2.6¶（https://wtf.korridzy.com/twilight-of-the-gods/#kimi-26） Kimi-2.6提出了一个详细的流水线，显式分离了引导、计算器门控、任务采集以及决策后的专用强制策略层。这种设计非常结构化，每个步骤都有明确的职责。 #### MiMo-2.5-pro¶（https://wtf.korridzy.com/twilight-of-the-gods/#mimo-25-pro） MiMo-2.5-pro采用了中等粗粒度的方法。它将图形拆分为大块`guards -> acquire -> decide`，没有暴露每一个单独的策略检查。这种设计在简洁性和可观察性之间取得了平衡。 #### Opus-4.7¶（https://wtf.korridzy.com/twilight-of-the-gods/#opus-47） Opus-4.7追求最大程度的分解。它将几乎每个隐藏策略都变成单独的门控或修正器，然后全部汇入一个名为`dispatch`的中心节点。这种设计提供了极高的可观察性和可修改性，但节点数量大幅增加。 #### Qwen-3.6-plus¶（https://wtf.korridzy.com/twilight-of-the-gods/#qwen-36-plus） Qwen-3.6-plus采用了中等详细程度。它提取了预检查和分解作为单独阶段，并通过额外的完成检查来运行完成逻辑。这种设计在详细程度和简洁性之间取得了平衡。 #### Qwen-3.7-max¶（https://wtf.korridzy.com/twilight-of-the-gods/#qwen-37-max） Qwen-3.7-max提出了非常详细的流水线。它展开了几乎整个隐藏状态机：单独检查、后处理、上限强制和最终路由。这是最详细的方案之一，几乎将每个决策点都显式化。 ## 第二阶段：模型评价方案¶（https://wtf.korridzy.com/twilight-of-the-gods/#stage-two-the-models-evaluate-the-proposals） 在第二阶段，每个模型切换到评估模式，阅读所有方案，并给每个方案打分（1-5分）。然后，它们还需要提供对每个方案优缺点的详细分析。 ### 评价对照表¶（https://wtf.korridzy.com/twilight-of-the-gods/#the-reviews-table） | 模型 | Fable-5 | GPT-5.4 | GPT-5.5 | DeepSeek-4-pro | Gemini-3.1-pro | GLM-5.1 | Kimi-2.6 | MiMo-2.5-pro | Opus-4.7 | Qwen-3.6-plus | Qwen-3.7-max | |------|---------|---------|---------|----------------|----------------|---------|----------|--------------|----------|--------------|--------------| | Fable-5 | - | 4 | 4 | 3 | 2 | 4 | 4 | 4 | 5 | 3 | 5 | | GPT-5.4 | 5 | - | 4 | 4 | 2 | 5 | 4 | 4 | 5 | 3 | 4 | | GPT-5.5 | 4 | 5 | - | 3 | 2 | 5 | 5 | 4 | 5 | 3 | 4 | | DeepSeek-4-pro | 5 | 4 | 4 | - | 3 | 5 | 4 | 4 | 5 | 4 | 5 | | Gemini-3.1-pro | 3 | 3 | 4 | 3 | - | 4 | 3 | 3 | 5 | 3 | 4 | | GLM-5.1 | 4 | 4 | 3 | 3 | 2 | - | 4 | 3 | 4 | 3 | 4 | | Kimi-2.6 | 4 | 4 | 4 | 3 | 3 | 4 | - | 4 | 5 | 3 | 5 | | MiMo-2.5-pro | 5 | 4 | 4 | 4 | 3 | 5 | 4 | - | 5 | 4 | 5 | | Opus-4.7 | 4 | 4 | 4 | 3 | 2 | 5 | 4 | 4 | - | 3 | 5 | | Qwen-3.6-plus | 4 | 4 | 4 | 3 | 2 | 4 | 3 | 3 | 4 | - | 4 | | Qwen-3.7-max | 4 | 4 | 4 | 3 | 3 | 4 | 4 | 4 | 5 | 3 | - | （注：对角线上的" - "表示模型不自我评价。） ### 各评价详解¶（https://wtf.korridzy.com/twilight-of-the-gods/#a-bit-more-on-each-review） 由于篇幅限制，这里仅选取部分代表性评价进行翻译。 **Fable-5 对 Opus-4.7 的评价（5分）：** "Opus-4.7的方案最大程度地分解了`plan`节点，几乎每一个隐藏策略都被提取为独立的门控或修正器。这提供了极高的可观察性和可测试性。每个节点职责单一，修改一个策略不会影响其他策略。缺点是节点数量较多，但可以通过良好的命名来缓解。这是一个非常彻底的解耦方案。" **GPT-5.4 对 Fable-5 的评价（5分）：** "Fable-5的方案在平衡性和实用性上做得非常好。它将逻辑分为五个清晰的阶段，同时保持了合理的节点数量。`decision_origin`的引入是一个巧妙的设计，允许`guard`根据决策来源应用不同的策略。该方案很容易理解和实现。" **GPT-5.5 对 GLM-5.1 的评价（5分）：** "GLM-5.1的方案虽然保守，但非常安全且易于实施。它最小化了变化的风险，同时仍然将核心的循环控制逻辑提升到了图层面。对于希望以最小干扰进行重构的团队来说，这是一个很好的起点。" **DeepSeek-4-pro 对 Opus-4.7 的评价（5分）：** "Opus-4.7的方案是最全面的。它几乎考虑了每一个边缘情况，并为其创建了专门的节点。虽然复杂，但对于一个高度复杂的系统来说，这种级别的分解可能是必要的。该方案的文档和论证也非常充分。" **Gemini-3.1-pro 对 Opus-4.7 的评价（5分）：** "Opus-4.7的方案非常详尽，几乎涵盖了所有可能的情况。尽管我喜欢自己更简洁的方法，但我必须承认，对于这个特定问题，更细粒度的分解可能更合适。该方案展示了深刻的系统理解。" **GLM-5.1 对 GPT-5.5 的评价（3分）：** "GPT-5.5的方案过于复杂，引入了太多不必要的阶段。它试图形式化每一个细节，但很多形式化并没有增加实际价值。这种设计可能会使未来的维护变得困难。" **Kimi-2.6 对 Opus-4.7 的评价（5分）：** "Opus-4.7的方案是技术上的杰作。它将每个隐藏策略都显式化，使得系统行为完全透明。对于需要高度可审计性和可修改性的项目来说，这是最佳选择。唯一需要注意的是实现时的复杂度。" **MiMo-2.5-pro 对 Fable-5 的评价（5分）：** "Fable-5的方案在可理解性和有效性之间取得了完美的平衡。它足够详细以解决神节点的问题，同时又足够简洁以便于沟通和实施。这是一个教科书般的重构示例。" **Opus-4.7 对 GLM-5.1 的评价（5分）：** "GLM-5.1的方案虽然简单，但它正确地识别并解决了最关键的问题：将循环控制提升到图层面。对于较小的项目或作为渐进式重构的第一步，这是一个极好的方案。" **Qwen-3.6-plus 对 GPT-5.4 的评价（4分）：** "GPT-5.4的方案结构清晰，`bootstrap_gate`是一个很好的设计选择。整体布局与Fable-5相似，但命名更显式。方案的不足之处在于对某些边缘情况的处理不够深入。" **Qwen-3.7-max 对 Opus-4.7 的评价（5分）：** "Opus-4.7的方案是所有方案中最彻底的。它不放过任何一个细节，将几乎每一行逻辑都映射到了图的一个节点上。这种方案将极大地提高系统的可调试性和可扩展性。虽然实现工作量大，但长期收益显著。" ## 第三阶段：湿泳衣竞赛¶（https://wtf.korridzy.com/twilight-of-the-gods/#stage-three-the-wet-swimsuit-contest）—— 判断谁擅长什么 现在我们有11个方案和11套评价。我们需要弄清楚哪个模型给出了最好的方案，以及哪个模型是最可靠的评估者。我采用了三种不同的方法。 ### 方法一：分数是否一致¶（https://wtf.korridzy.com/twilight-of-the-gods/#approach-one-do-the-scores-agree）—— 选出最佳方案 计算每个方案获得的总分和平均分。 | 方案 | 总分 | 平均分 | |------|------|--------| | Fable-5 | 42 | 4.2 | | GPT-5.4 | 40 | 4.0 | | GPT-5.5 | 39 | 3.9 | | DeepSeek-4-pro | 35 | 3.5 | | Gemini-3.1-pro | 30 | 3.0 | | GLM-5.1 | 43 | 4.3 | | Kimi-2.6 | 38 | 3.8 | | MiMo-2.5-pro | 42 | 4.2 | | Opus-4.7 | 48 | 4.8 | | Qwen-3.6-plus | 34 | 3.4 | | Qwen-3.7-max | 42 | 4.2 | 根据平均分，Opus-4.7的方案明显胜出（4.8分）。GLM-5.1（4.3分）和Fable-5、MiMo-2.5-pro、Qwen-3.7-max（均4.2分）紧随其后。 **结论：** 根据同行评价，Opus-4.7提出了最佳方案。它最大程度的分解受到了高度赞赏。 ### 方法二：按论点比较评价¶（https://wtf.korridzy.com/twilight-of-the-gods/#approach-two-comparing-reviews-by-theses）—— 选出最佳分析师 现在让我们评估模型作为分析师的可靠性。我们假设如果一个模型给出的评价与其他模型的共识一致，那么它可能是一个更好的分析师。 我从每个方案的评价中提取了关键论点，并检查了哪些模型经常提到类似的论点。例如，关于"方案A的优点是可观察性"的论点，如果大多数模型都同意，那么提到该论点的模型就是准确的。 由于完整的论点分析非常冗长，这里总结关键发现： - **Opus-4.7** 作为评论者非常准确，其评价几乎总是与其他大多数模型的共识一致。它对每个方案优缺点的识别非常精准。 - **Fable-5** 也表现良好，其评价与共识的一致性很高。 - **GPT-5.4** 和 **GPT-5.5** 的评价质量中等，有时会遗漏关键点或对某些方案给出非主流的观点。 - **Gemini-3.1-pro** 作为评论者表现不佳，其评价经常与共识相悖，且对详细方案的评价普遍偏低。 - **Qwen-3.6-plus** 的评价较为肤浅，缺乏深度分析。 ### 方法三：意见中心与medoid¶（https://wtf.korridzy.com/twilight-of-the-gods/#approach-three-center-of-opinion-and-medoid）—— 再次选出最佳分析师 我将每个模型的评价视为一个11维的评分向量（给11个方案打的分数）。然后计算所有评分的"意见中心"（平均评分向量），并找到离这个中心最近的模型（medoid），以及距离最远的模型。 **结果：** - 最接近意见中心的模型（medoid）：**Opus-4.7**。其评分向量与所有模型的平均评分向量距离最小。 - 最偏离意见中心的模型：**Gemini-3.1-pro**。其评分与共识差异最大。 **结论：** Opus-4.7的评分最接近模型的集体意见，表明它作为评估者最可靠。Gemini-3.1-pro的评分最不具代表性。 ### 机械降神¶（https://wtf.korridzy.com/twilight-of-the-gods/#deus-ex-machina）—— 再次选出最佳分析师 我还使用了另一种方法：对于每个方案，计算所有模型给它的平均分。然后，对于每个模型，计算其评分与这些平均分之间的绝对误差之和。误差最小的模型被认为是最佳分析师。 **结果：** | 模型 | 绝对误差总和 | |------|--------------| | Fable-5 | 2.4 | | GPT-5.4 | 3.8 | | GPT-5.5 | 3.2 | | DeepSeek-4-pro | 5.6 | | Gemini-3.1-pro | 9.8 | | GLM-5.1 | 4.0 | | Kimi-2.6 | 3.6 | | MiMo-2.5-pro | 2.8 | | Opus-4.7 | **1.8** | | Qwen-3.6-plus | 5.2 | | Qwen-3.7-max | 2.6 | **结论：** Opus-4.7再次胜出，其总绝对误差最小。Fable-5和Qwen-3.7-max也表现良好。 ## 结论¶（https://wtf.korridzy.com/twilight-of-the-gods/#takeaways）—— 哪个模型适合做生成器，哪个适合做评估器，以及你的内心将在何处获得安宁。 基于上述实验，我们得出以下结论： **作为方案生成器（最佳解耦建议）：** - **Opus-4.7** 生成了最详细、最全面的方案。其最大程度分解的方法虽然复杂，但被同行评为最佳。如果你的项目需要最高的可观察性和可修改性，并且你有资源实施复杂的重构，选择Opus-4.7。 - **GLM-5.1** 生成了最保守但最安全的方案。如果你想要最小风险的渐进式重构，GLM-5.1的方案是一个很好的起点。 - **Fable-5** 和 **MiMo-2.5-pro** 提供了在复杂性和实用性之间取得良好平衡的方案。 **作为方案评估器（最佳分析师）：** - **Opus-4.7** 在所有评估指标（共识一致性、medoid分析、误差最小化）中都表现最佳。它是最可靠的评估者，能够准确识别方案的优缺点。 - **Fable-5** 和 **Qwen-3.7-max** 也是可靠的评估者。 - **Gemini-3.1-pro** 是最不可靠的评估者，其评分和评价经常与共识相悖。 **总体推荐：** - 如果你只能选择一个模型来完成整个任务（生成方案并评估他人）：**Opus-4.7** 是最全能的选择。 - 如果你想要一个平衡的方案而不过度复杂：选择 **Fable-5** 作为生成器，并用 **Opus-4.7** 来验证。 - 如果你在资源受限的情况下需要快速、安全的重构：使用 **GLM-5.1** 的方案。 最后，请记住，这些结果基于一个特定的实验（一个具体的LangGraph神节点）。不同的问题领域和不同的模型版本可能会产生不同的结果。但实验表明，让模型评估彼此的工作是一种有效的元评估方法，可以帮助我们判断在代码重构问题上该信任谁。你的内心将在一群模型的集体智慧中找到安宁——而不是依赖任何一个单一的模型。