Agent 项目现在不缺演示视频缺的是能说明白失败原因的复盘。Rohan Paul 围绕 Atomic Bot 做了一组对比实验把 OpenClaw 2.0 和 Hermes Agent 同时接到 GLM 5.3 上。他得到的最有价值观点不是某个 Agent 全方位胜出而是两者差异主要体现在自检方式。初看这个结论不够刺激真正拆一遍之后会发现它比单纯比较任务成功率更接近 Agent 工程的核心问题。Atomic Bot 这个词拆开看很有代表性。Bot 指自动执行任务的 AgentAtomic 则强调任务被拆到了不能再拆的原子粒度。原子任务意味着每一步都有明确的起始点和可观测结果例如点击一个按钮、提取一个订单号、把一个文件移动到指定目录、在表单里填入一段内容。Agent 必须有能力判断这一步到底有没有生效而判断这一步正是自检机制的职责。Rohan Paul 在这组实验里点名自检方式本质是在说当 GLM 5.3 作为同一个底座提供语言理解和工具调用能力时局部动作是否被正确确认往往比模型是否足够聪明更影响最终表现。所以这篇文章不会只给一个“谁更好用”的结论而是把问题拆成三条线来展开。第一讲清楚自检方式到底是什么以及它为什么会在模型相同时成为两个 Agent 的分水岭。第二给出一个可以复现 Atomic Bot 风格的评测任务集、日志字段和批量流程方便你自己在 OpenClaw 2.0 与 Hermes Agent 上各跑一遍。第三落到 GLM 5.3 的 API 接入、最小请求、性能观察和常见坑上。适合的读者很明确正在做 Agent 落地、模型对比评测、RAG 自动化或者桌面端自动化的工程师。1. Atomic Bot 实验核心能力速览为了防止纯概念文本显得太虚先给一张观察视角表。这张表不是 OpenClaw 2.0 或 Hermes Agent 的官方规格页也不是某个发布方的能力矩阵而是把这组实验评论涉及的组件、环境与高频关注点整理出来。当你自己运行同一组任务时这个表可以直接作为验收清单逐项确认哪些能力被接通、哪些被默认关闭。观察维度说明实验主题以 Atomic Bot 任务为样本对比不同 Agent 运行器的行为差异模型底座GLM 5.3批量任务场景可关注 flash 等轻量接入形态Agent 运行器 AOpenClaw 2.0重点观察执行编排、重试策略与自动判定规则Agent 运行器 BHermes Agent重点观察桌面端操作、外部知识库、导航状态恢复讨论焦点自检方式发现失败、判断成功、决定是否重试的机制外部环境模型 API Key、页面或表单测试环境、文件系统目录、可观测日志目录主要交付物原子任务用例集、自检事件日志、失败纠正路径记录、批量统计报告适合读者Agent 开发者、评测工程师、想把大模型接到自动化流程里的团队从搜索词里也能看到Hermes Agent 的方向讨论很自然地围绕桌面版安装、外挂知识库、回到主页面的命令这些工程操作展开OpenClaw 2.0 与 GLM 5.3 的组合则更容易出现在模型调用、API 接入和自检机制讨论里。这说明两个 Agent 的差异化优势并不在一个平面上一个更贴近 GUI 操作和知识库使用另一个更侧重执行编排。评测时如果只拿“谁跑成功率高”说事很容易忽略真正影响结果的自检方式。这里先做一个提醒。我没有把本文写成一份带着截图和真实数字的实测报告因为输入材料本身并没有提供两台机器的显存占用、任务成功次数或具体 API 返回内容。更稳妥的做法是把这篇作为一个评测脚手架你拿着同样的任务用例去跑两个 Runner把自检日志拉出来用第 6 节和第 7 节的统计方式得出结论。2. 先看结论差异为什么集中在自检方式在拆代码之前先解释一个反直觉的现象。自检在技术文档里有多个名字self-check、verification、reflection、validate、quality gate。名字听起来有点玄但思路很朴素Agent 执行完一个动作后必须回答三个问题——我这个动作真的执行成功了吗如果不成功下一步应该重试、换方法还是停下来找人工确认如果成功这次结果能否被后续动作依赖这个问题之所以在 Rohan Paul 的 Atomic Bot 实验中成为主角是因为模型相同时两个 Agent 拿到语言生成部分的概率分布非常接近。GLM 5.3 在给定相同前缀和工具描述时模型为 OpenClaw 2.0 和 Hermes Agent 生成的下一步动作可能不会出现显著差异。真正让任务结果分叉的是动作执行完成之后的判定循环。OpenClaw 2.0 在执行编排中是否引入了结构化校验步骤Hermes Agent 是否把工具返回结果交给模型再总结一遍这些细节直接决定了任务会不会收敛。用更工程化的语言描述一个 Agent 执行管线往往包含规划动作、执行动作、检查动作三个环节。现状是大多数 Agent 教程把精力放在第一个环节只要模型输出的下一步动作足够像样就停了。Rohan Paul 这组评测的意义在于把镜头对准第三个环节。当模型已经说出类似“文件已移动”这句话时Agent 到底应该相信这句话还是应该用一个 shell 命令检查目标文件是否存在两种选择会产生完全不同的任务可信度。从运行逻辑推导两个 Agent 在同一任务上出现稳定差异最可能出现在以下几种自检细节里。有的 Runner 允许对同一个动作重试 N 次但在重试前不保存环境状态有的 Runner 在失败后会主动把页面导航到一个已知的稳定页面再继续有的 Runner 会把工具返回的原始状态码、文件大小、DOM 节点变化作为成功判据而不是让模型自行猜。这些差异在单个任务里不一定肉眼可见但在 10 个、50 个原子任务里会累积成不同的成功率分布、不同的重试次数和不同的单任务成本。3. 自检方式不是单一功能而是几类技术选型的组合自检不是一个开关而是一组可以独立插拔的技术策略。两个 Agent 在 GLM 5.3 上的差异往往不是“一个自检、一个不自检”而是默认配置下接通了不同深度的自检层。理解这五类技术路线以后再去看 OpenClaw 2.0 和 Hermes Agent 的日志会比较清楚。3.1 方法级结构化约束与输出校验大模型在工具调用模式中通常会输出 JSON 或函数调用
Agent 工程的核心不是模型智商：自检方式才是成败分水岭
Agent 项目现在不缺演示视频缺的是能说明白失败原因的复盘。Rohan Paul 围绕 Atomic Bot 做了一组对比实验把 OpenClaw 2.0 和 Hermes Agent 同时接到 GLM 5.3 上。他得到的最有价值观点不是某个 Agent 全方位胜出而是两者差异主要体现在自检方式。初看这个结论不够刺激真正拆一遍之后会发现它比单纯比较任务成功率更接近 Agent 工程的核心问题。Atomic Bot 这个词拆开看很有代表性。Bot 指自动执行任务的 AgentAtomic 则强调任务被拆到了不能再拆的原子粒度。原子任务意味着每一步都有明确的起始点和可观测结果例如点击一个按钮、提取一个订单号、把一个文件移动到指定目录、在表单里填入一段内容。Agent 必须有能力判断这一步到底有没有生效而判断这一步正是自检机制的职责。Rohan Paul 在这组实验里点名自检方式本质是在说当 GLM 5.3 作为同一个底座提供语言理解和工具调用能力时局部动作是否被正确确认往往比模型是否足够聪明更影响最终表现。所以这篇文章不会只给一个“谁更好用”的结论而是把问题拆成三条线来展开。第一讲清楚自检方式到底是什么以及它为什么会在模型相同时成为两个 Agent 的分水岭。第二给出一个可以复现 Atomic Bot 风格的评测任务集、日志字段和批量流程方便你自己在 OpenClaw 2.0 与 Hermes Agent 上各跑一遍。第三落到 GLM 5.3 的 API 接入、最小请求、性能观察和常见坑上。适合的读者很明确正在做 Agent 落地、模型对比评测、RAG 自动化或者桌面端自动化的工程师。1. Atomic Bot 实验核心能力速览为了防止纯概念文本显得太虚先给一张观察视角表。这张表不是 OpenClaw 2.0 或 Hermes Agent 的官方规格页也不是某个发布方的能力矩阵而是把这组实验评论涉及的组件、环境与高频关注点整理出来。当你自己运行同一组任务时这个表可以直接作为验收清单逐项确认哪些能力被接通、哪些被默认关闭。观察维度说明实验主题以 Atomic Bot 任务为样本对比不同 Agent 运行器的行为差异模型底座GLM 5.3批量任务场景可关注 flash 等轻量接入形态Agent 运行器 AOpenClaw 2.0重点观察执行编排、重试策略与自动判定规则Agent 运行器 BHermes Agent重点观察桌面端操作、外部知识库、导航状态恢复讨论焦点自检方式发现失败、判断成功、决定是否重试的机制外部环境模型 API Key、页面或表单测试环境、文件系统目录、可观测日志目录主要交付物原子任务用例集、自检事件日志、失败纠正路径记录、批量统计报告适合读者Agent 开发者、评测工程师、想把大模型接到自动化流程里的团队从搜索词里也能看到Hermes Agent 的方向讨论很自然地围绕桌面版安装、外挂知识库、回到主页面的命令这些工程操作展开OpenClaw 2.0 与 GLM 5.3 的组合则更容易出现在模型调用、API 接入和自检机制讨论里。这说明两个 Agent 的差异化优势并不在一个平面上一个更贴近 GUI 操作和知识库使用另一个更侧重执行编排。评测时如果只拿“谁跑成功率高”说事很容易忽略真正影响结果的自检方式。这里先做一个提醒。我没有把本文写成一份带着截图和真实数字的实测报告因为输入材料本身并没有提供两台机器的显存占用、任务成功次数或具体 API 返回内容。更稳妥的做法是把这篇作为一个评测脚手架你拿着同样的任务用例去跑两个 Runner把自检日志拉出来用第 6 节和第 7 节的统计方式得出结论。2. 先看结论差异为什么集中在自检方式在拆代码之前先解释一个反直觉的现象。自检在技术文档里有多个名字self-check、verification、reflection、validate、quality gate。名字听起来有点玄但思路很朴素Agent 执行完一个动作后必须回答三个问题——我这个动作真的执行成功了吗如果不成功下一步应该重试、换方法还是停下来找人工确认如果成功这次结果能否被后续动作依赖这个问题之所以在 Rohan Paul 的 Atomic Bot 实验中成为主角是因为模型相同时两个 Agent 拿到语言生成部分的概率分布非常接近。GLM 5.3 在给定相同前缀和工具描述时模型为 OpenClaw 2.0 和 Hermes Agent 生成的下一步动作可能不会出现显著差异。真正让任务结果分叉的是动作执行完成之后的判定循环。OpenClaw 2.0 在执行编排中是否引入了结构化校验步骤Hermes Agent 是否把工具返回结果交给模型再总结一遍这些细节直接决定了任务会不会收敛。用更工程化的语言描述一个 Agent 执行管线往往包含规划动作、执行动作、检查动作三个环节。现状是大多数 Agent 教程把精力放在第一个环节只要模型输出的下一步动作足够像样就停了。Rohan Paul 这组评测的意义在于把镜头对准第三个环节。当模型已经说出类似“文件已移动”这句话时Agent 到底应该相信这句话还是应该用一个 shell 命令检查目标文件是否存在两种选择会产生完全不同的任务可信度。从运行逻辑推导两个 Agent 在同一任务上出现稳定差异最可能出现在以下几种自检细节里。有的 Runner 允许对同一个动作重试 N 次但在重试前不保存环境状态有的 Runner 在失败后会主动把页面导航到一个已知的稳定页面再继续有的 Runner 会把工具返回的原始状态码、文件大小、DOM 节点变化作为成功判据而不是让模型自行猜。这些差异在单个任务里不一定肉眼可见但在 10 个、50 个原子任务里会累积成不同的成功率分布、不同的重试次数和不同的单任务成本。3. 自检方式不是单一功能而是几类技术选型的组合自检不是一个开关而是一组可以独立插拔的技术策略。两个 Agent 在 GLM 5.3 上的差异往往不是“一个自检、一个不自检”而是默认配置下接通了不同深度的自检层。理解这五类技术路线以后再去看 OpenClaw 2.0 和 Hermes Agent 的日志会比较清楚。3.1 方法级结构化约束与输出校验大模型在工具调用模式中通常会输出 JSON 或函数调用
