https://github.com/ailiujiarui/MineAI，锐评这个项目 说出架构问题和其他问题

回复 群友 6814： 看了代码，直说：这不是一个“只套模型 API”的项目，但目前更像“靠不断修补执行细节跑通的自动化系统”，还没形成边界稳定的 Agent 执行架构。 这次审查基于 GitHub API 返回的 e4fa1e2 提交，读了控制器、目标执行器的部分源码和任务靶场文档，没有实际运行。下面区分代码里能直接看到的问题和需要验证的风险。 一、最严重的问题：子动作能越权结束父目标 GoalExecutor 里，tickTravel 到达目的地会直接 advance，推进整个程序的步骤。 但 tickMine 和 tickObtainItem 又把 tickTravel 当作内部的“走过去”动作调用。 这意味着：父目标要求“挖到并拿到材料”，内部移动却可能因为“走到了”就把父目标推进掉。 例如挖矿后发现掉落物没进背包，调用移动逻辑去捡；移动逻辑发现已经到达坐标，直接推进步骤，并没有再次确认材料到账。 这不是重试次数不够，是完成语义串层了。 子动作应该只报告“移动成功/失败/进行中”，只有父目标自己验证条件后，才有权宣布父目标完成。否则你写了再多验收，也可能被旁路绕过去。 二、错误处理把真正失败伪装成成功 tickAction 里，只要 extract_item 返回失败，就直接 advance。 注释想表达的是“空槽提取视为无操作”，但代码实际放过的是所有提取失败，并没有区分空槽、背包满、容器失效或者其他错误。 结果就是：上游失败被吞掉，下游再因为缺料报错。你看到的是 craft 失败，真正断点却在更早的取料。 另外，tickVerifyItem 遇到无法识别的物品也直接推进。验收器无法理解目标，不应该等同于验收通过。 这两处比“模型不聪明”更值得先怀疑。 三、所谓闭环，实际还没有统一的验收协议 部分目标会读真实世界确认结果，这是对的。 但通用动作路径里，队列返回 SUCCESS 就推进；同步工具返回成功也直接推进。也就是说，上层仍依赖各个工具自行保证“成功”的含义。 问题不是每层都必须重复检查，而是必须明确： 成功究竟指动作已提交、动作已执行，还是目标后置条件已成立？ 目前这些含义在同一个执行器里混用。某个工具稍微改变返回语义，就可能让上层误判。 你之前“两套库存”的问题，本质上也属于这一类：不同模块对“已经完成”没有共同定义。 四、控制器已经承担太多职责 AgentController 在该提交里约 86 KB，GoalExecutor 约 47 KB。体积本身不是罪，职责混在一起才是。 可见代码中，控制器同时处理规划、反思、模型请求、技能选择、编译执行、目标验收、休眠、失败恢复和多套预算。 状态又由枚举加 planning、reflecting、parked 等多个布尔量共同表达，很难一眼判断哪些组合合法。 已经能看到一个具体不一致：tick 会处理 RUNNING_SKILL，但 isRunning 只承认 THINKING 和 AWAITING_ACTION。 如果外部调用方用 isRunning 判断是否结束，就可能把正在执行技能的 NPC 当成空闲。是否已经影响靶场，需要继续检查调用方；但接口语义本身已经不一致。 锐评就是：现在添加一个功能容易，证明它不会破坏另外三个功能很难。 五、Skill 复用还像文本匹配，不像能力契约 tryObjectiveSkill 根据“技能名称＋描述是否包含目标物品名”挑选技能，然后尝试执行。 这可以做候选召回，但不足以决定复用。 名称里出现 iron_ingot，不代表这个技能能生产铁锭，也可能是消耗铁锭；同一种产物，不同数量、工具条件和工作站要求，也不能直接视为同一种可执行能力。 后续入口可能还有校验，我没完整读到，不能断言完全没有保护。但当前选择层已经暴露问题：技能的产出和前置条件，应该是结构化数据，而不是靠描述猜。 六、L1–L8 全通，证明范围比你想象的小 靶场文档明确写了：固定布置、地表矿脉、和平环境，主动排除了探索和生存难度。 这种测试设计本身合理，能隔离合成物流问题。但通过它，只能证明受控条件下这条任务链跑通，不能直接证明开放世界能力。 更重要的是，该文档记录的验收限制包括“不校验数量与来源”，报告只保留最近一次运行。如果当前实现仍如此，“需要四个原木但只有一个”就存在被误判通过的风险。 文档还把“通过但超时”的任务计入通过数，完成率和限时通过率混在一起，不利于版本比较。 这些可能已经改过，所以我把它们标为文档暴露、需要核对实现的问题，不当作当前测试脚本的已确认缺陷。 七、你需要分清：测的是模型，还是确定性执行器 控制器遇到明确的可验收目标时，会优先尝试技能与确定性编译，不一定先让模型规划。 这是很好的工程选择，不是缺点。 但因此 L1–L8 的成绩更可能说明“目标编译＋执行恢复”有效，不能直接归因为模型规划能力提升。 项目介绍如果强调模型理解与自主规划，就需要交代模型在哪些环节真正参与。否则实际亮点明明是执行系统，却包装成了模型智能。 八、公开材料存在版本对不上的问题 这次仓库首页抓取介绍的是 Node、Mineflayer 和 Forge Bridge，而 API 返回的 HEAD 是 Java Forge 项目结构。 可能是抓取缓存或版本切换，我不能直接认定当前 README 写错了。但两份材料不能混着拿来评价；上面的代码结论只针对 e4fa1e2。 同样，旧靶场文档的成绩不能替代你今天说的全通结果。公开展示需要让代码版本、测试条件和结果能对应起来。 最后一句评价： 你的问题不是“缺少更多 Agent 功能”，而是“同一个目标到底由谁负责完成”还没统一。 最危险的不是失败，而是子动作越权推进、错误被吞掉，让系统以为自己成功了。把这两个问题解决，比再加反思、多 Agent 或长期记忆更能提升这个项目的含金量。 本轮代码依据： https://github.com/ailiujiarui/MineAI/tree/e4fa1e230ee37aa2baeae099e723b10c0e5e72ff