做 AIAgent 开发的人十个里有九个会告诉你真正难的不是让模型开口说话而是让它闭环干活。项目标题里这组关键词——Hermes、Agent Loop、AIAgent、执行流程——放在一起指向的其实是一个非常具体的问题一个智能体从接到任务到交付结果中间那串反复循环的动作到底是怎么跑起来的以及跑起来之后怎么不跑偏。我最初接触 Hermes 是在一个开源智能体技术交流圈里当时它被当作 DeepSeek 系智能体的第三方工作台来传。后来自己动手在 Ubuntu 上装了一遍又接上 Obsidian 试了试知识库联动才算把它的执行循环摸了个大概。这篇文章不做产品测评也不贴一大段官方文档的翻译就用我实际跑过的案例把 Hermes Agent Loop 的四个环节——感知目标、规划拆解、工具执行、反馈收敛——一层层拆开给你看中间穿插安装部署、指定安装目录、桌面版与 Studio 工作台的选择这些实操细节以及我踩过的坑。不管你是打算把一个开源 AIAgent 平台跑起来的老手还是刚入门想搞懂循环到底是什么的新手这篇都能给你一个可以直接对照的坐标系。1. 先从循环说起为什么 Agent 要 Loop1.1 一次问答解决不了的事才轮到 Agent Loop先看一个最简单的对比。普通聊天机器人收到帮我整理这周的项目周报这种请求大概率直接生成一段文字交差你不满意再丢一句周报里要包含数据分析它再生成一段。这就是一次问答Single Turn模型每次只做一件事根据输入生成输出不做任何多余的自我检查。而 AIAgent 面对同样的请求逻辑完全不同它得先拆出整理周报这个目标然后判断需要哪些信息——本周的提交记录、任务看板、讨论记录、数据报表——再决定调用哪些工具去拿这些信息拿到之后汇总、生成、校验最后输出。这个拆目标→选工具→执行→看结果→再调整的循环就是 Agent Loop。为什么非要用循环因为现实中的任务几乎都有两个特点一是信息不齐二是结果不可预知。模型没法在一轮里既知道该调什么工具又知道工具返回什么结果再根据结果修正下一步。它必须走一步看一步这是由任务本身的动态性决定的。就拿写周报来说不先去看一眼任务看板你怎么知道这周有哪些任务完成了不看完成记录你怎么判断哪些数据需要进周报每一步的信息都依赖前一步的实际返回这种依赖关系注定了 Agent 不能像聊天一样一锤子买卖。1.2 Hermes 把循环抽象成了什么Hermes 这个项目给我最直观的感受是它没有把 Agent Loop 藏起来而是把它做成了可以观察、可以干预的东西。在它的执行日志里你能明确看到某一轮循环处于什么阶段是刚收到任务在解析目标还是在候选工具列表里做匹配还是工具调用返回了错误等模型重新决策。我习惯把它理解成一个大脑加手脚的结构。大脑是背后的 LLMHermes 支持切换不同模型比如可以接 DeepSeek 的接口也可以接其他兼容 OpenAI 格式的模型服务手脚是注册进来的工具集合。Loop 做的事情就是让大脑和手脚不停地配合大脑下达指令手脚执行并返回结果大脑看到结果决定下一步。这个抽象和我们平时写程序时的事件循环不太一样。程序的事件循环是确定性的每个事件的处理函数是提前写死的Agent Loop 是动态的每一步下一步做什么由模型根据当前上下文临时决定。所以它灵活但也正因为灵活才容易失控。理解这点很重要你无法用写普通程序的思维去预测 Agent 每一步的行为只能通过设计约束比如工具描述、终止条件、超时机制去引导它。1.3 Loop 和 Chain、Workflow 根本不是一回事很多刚开始接触的人会把 Agent Loop 和 Chain链式调用、Workflow工作流混在一起。我举个容易理解的例子。假设要写一份市场分析报告。Workflow 的做法是先定义好五步第一步取数据第二步清洗第三步分析第四步生成图表第五步输出报告每步之间是固定管道像一个流水线顺序写死中间不能跳。Chain 的做法类似但更强调把多个模型调用串起来前一个的输出是后一个的输入每一步做什么也是预先定义好的。Agent Loop 则完全是另一套逻辑它只知道最终目标是写市场分析报告至于先取数据还是先确认报告模板、中间要不要做数据清洗、做完分析要不要再补充调研全由模型在执行过程中自己判断。有时候它会绕路发现数据不够又回头调了另一个数据源这正是循环存在的价值——在动态环境里动态决策。理解了这个区别你就能明白为什么很多做 Agent 的人反复强调给模型留试错空间。你要是把流程写得太死那就不叫 Agent叫自动化脚本你要是完全放手模型可能在一个错误方向上循环十几次出不来。好的 Agent Loop 设计是在自由和约束之间找平衡点。2. Hermes Agent Loop 四段核心流程拆解2.1 第一段目标接收与任务解析Loop 的起点不是执行而是听懂任务。Hermes 收到用户输入后第一件事是做一个目标解析Goal Parsing把自然语言转成内部的任务描述提取出要做什么Task、有什么约束Constraint、成功标准是什么Done Condition。这一段最容易被忽略但恰恰是整个 Loop 最容易出问题的地方。我跑过一个典型例子用户说帮我看看这周线上有没有异常模型如果只提取到检查异常两个词接下来就会满世界找数据因为没有定义异常的标准——是错误率超过 5% 算异常还是出现了 500 错误算异常我在实际使用中会刻意把目标写完整比如检查这周线上错误率超过 5% 视为异常并给出异常原因分析。模型解析出来的目标就不一样了它知道自己要获取错误率数据→对比阈值→判定是否异常→归因分析。目标解析的质量直接决定了后面几轮循环的效率和收敛路径这一步省了后面全是弯路。Hermes 在解析目标时还会做一个动作识别隐含依赖。比如按部门汇总这句话隐含依赖是需要先拿到部门列表如果列表不在已有数据里就得规划一次数据获取。这也是解析阶段的价值——把显性目标和隐性依赖一起放进任务上下文模型在后面规划时才不会被信息从哪来这个问题卡住。2.2 第二段规划与工具匹配目标解析完成之后模型进入规划阶段。这个阶段模型要做两件事把大目标拆成子步骤以及为每个子步骤匹配可用工具。拆解子步骤这件事本质上是把抽象目标翻译成可执行指令序列。Hermes 里有一个工具注册表Tool Registry维护着所有可用工具的描述、参数格式和调用方式。模型规划的时候会根据工具描述来决定取数据用哪个工具发通知用哪个工具查文档用哪个工具。这里我要多说一句工具描述的重要性。很多 Agent 平台规划不准问题不在模型而在工具描述写得太差。Hermes 的实践是给每个工具写清楚什么时候该用、什么时候不该用、参数长什么样模型才能准确匹配。这就好比招了个实习生你只告诉他会用打印机他当然不知道什么时候该用打印机你改成当需要把电子文档转成纸质版时使用打印机支持双面打印卡纸时先打开左侧盖板他就能在合适的场景想起这个工具了。规划阶段的输出通常是一个候选步骤序列但不是所有 Agent 都会在这一步一次性规划完。Hermes 的默认策略是部分规划Partial Planning就是只规划最近一两步就去执行根据执行结果再往下走。这样做的好处是如果前两步跑出来发现前提不成立后面的规划可以及时调整不用推倒重来。坏处是循环次数会增加上下文消耗变大。如果你运行的任务步骤非常固定完全可以调整配置让它一次规划完整步数减少往返次数。怎么平衡后面我会提到。2.3 第三段工具调用与动作执行规划做得再好最终要落到动手上。工具调用Tool Calling是 Agent Loop 里最需要关注稳定性的环节因为这里是真实世界和模型世界的交界处——模型输出一个 JSON 格式的工具调用指令Hermes 解析它、校验参数、然后真正去执行外部命令或 API 请求。我踩过的第一个坑就是参数校验。模型有时候会输出一个根本不存在于工具定义里的参数比如给文件搜索工具传了fuzzytrue但工具只支持match_type枚举。Hermes 在解析层做了 JSON Schema 校验识别到不合法参数时会返回一条错误信息给模型让模型重新生成调用。这个错误回填机制是 Loop 能自愈的关键但也意味着如果你的工具定义没有准确的参数 Schema模型就三天两头犯错。另一个实操细节是执行超时控制。工具调用如果是同步的一个卡住的命令可能让整个 Loop 停在那不动。我跑数据抓取任务时遇到过 API 接口超时如果不设置超时上限模型会一直等下去。后来我在配置里把工具执行超时调到 60 秒并在超时错误信息里带上可以考虑换一个数据源的提示。模型收到这个提示下一次循环就会改走备选方案Loop 就活了。在 Hermione 的实际实现里工具执行结果会被包成标准格式回填给模型包含三部分本次调用的状态成功/失败/超时、返回数据截断后的摘要、以及一段用于帮助模型判断下一步的提示信息。这个结果摘要值得重点说模型上下文窗口是有限的一个数据库查询可能返回上万行全塞进去既不现实也没必要。截断和摘要的策略直接决定了模型能不能在后面的循环里做出正确判断。我通常会把关键字段完整保留把重复性高的明细缩成统计信息模型既能看到全局又不会被噪音干扰。2.4 第四段结果评估与闭环收敛工具执行完Agent 回到模型这里开始第四段评估结果是否达到目标。这一步的逻辑看起来简单——目标达到了就停没达到就继续——但真正实现的时候有三个关键判断要做。第一是达到的标准。我在 Hermes 里配置过 Done Condition这个条件既可以是显式的比如结果文件中包含 500 行数据且无空值也可以是语义化的模型自行判断输出是否满足用户需求。显式条件适合有明确交付物的任务比如数据导出、报表生成语义化条件适合开放型任务比如写方案、做分析。我建议你优先使用显式条件可验证、可回放、不怕模型自我感觉良好。第二是最大循环次数。这是最容易忽略的保命参数。没有上限的 Agent Loop会无限逼近于一个失控的进程。我给自己的经验值是简单任务 3-5 轮中度任务 8-10 轮复杂分析任务最多 15 轮。超过上限就强制停止并输出当前进展和未完成原因。这既保护了资源也给了用户继续跟进的抓手——至少你知道它卡在哪一步。第三是收敛信号的识别。注意不是每次循环结束都叫收敛。有些任务是假装完成了的——模型生成了看起来合理的答案但实际数据分析根本没跑通。Hermes 的评估模块会综合工具调用的成功记录、关键中间产物是否生成、目标条件是否达成一起来判断。我建议你把关键工具是否全部成功调用作为一个硬信号只要有一次关键工具调用是失败后强行走下去的哪怕模型说已完成也要让它继续循环直到核心链路真正打通。从第二段到第四段一次循环就完成了。真实运行的 Agent Loop 不是走完这一圈就结束而是在第四段判定未达成时回到第二段重新规划形成一个又一个螺旋上升的闭环直到收敛或被截断。Agent Loop 执行流程深拆这句话拆到最后拆的就是这套螺旋结构。3. 从零跑起来Hermes 的安装部署与运行环境3.1 你需要准备哪些东西讲完循环的理论接下来是最容易卡住人的环节环境准备。以我实际部署 Hermes 的经验来看你至少需要准备三样东西一台能跑模型的机器本地或者有远程模型 API 都行、Python 3.10 的运行环境、以及一个模型接口的 API Key比如 DeepSeek 的接口或者其他兼容 OpenAI 格式的接口。机器配置方面模型的推理如果在本地跑显存压力比较大但 Hermes 本身只是个编排框架LLM 可以接远程 API所以本地普通开发机完全够用。我自己的部署环境是 Ubuntu 22.04 加 32G 内存、无独立显卡的机器接的是远程模型 API跑起来没什么压力。还有一个常被忽略的准备工作是确认网络连通性。我指的不是什么特殊网络而是很基础的事你的机器能不能正常访问模型 API 的域名、能不能访问代码仓库如果你打算从源码安装的话。很多人在安装那一步卡半天最后发现是防火墙或者代理环境配置的问题白白浪费两个小时。先ping一下目标域名或者用curl -I探一下响应几秒钟就能排除这一类问题。3.2 Ubuntu 下安装 Hermes 的完整流程Hermes 的安装方式主要有三种官方预编译的安装包、pip 安装、以及源码编译安装。你如果是第一次接触我建议优先选择 pip 安装最省事。# 第一步创建独立的虚拟环境避免污染系统 Python python3 -m venv hermes-env source hermes-env/bin/activate # 第二步升级 pip 并安装 Hermes pip install --upgrade pip pip install hermes-agent # 第三步验证安装是否成功 hermes --version这里有个非常重要的习惯一定要用虚拟环境。我见过太多人图省事直接在系统 Python 里 pip install结果装完之后要么和系统里已有的包版本冲突要么在卸载时把别的依赖一起干掉了。虚拟环境相当于给 Hermes 划了一个独立的房间里面放什么都是它自己的不影响外面。如果你选择源码安装流程大概是git clone https://github.com/your-repo/hermes-agent.git cd hermes-agent pip install -e .源码安装的好处是你能直接看到工具注册、Loop 控制器的源码做二次开发或者调试的时候特别有用。坏处是你需要自行解决项目里所有 Python 依赖的版本兼容问题遇到坑的概率比 pip 方式高不少。如果不是为了改代码我还是推荐先用 pip 把环境跑通再决定要不要换源码方式。3.3 指定安装目录官方文档经常一笔带过热词里有一个并且指定安装目录这个需求看起来冷门实则是真实痛点——很多人不想把工具装到默认的 site-packages 或用户目录想把整个环境放在一个自己管理的位置。用 pip 安装时指定安装目录的标准做法是用--target参数pip install --target /opt/hermes/lib hermes-agent注意用这种方式装完执行hermes命令之前要先把这个目录加进PYTHONPATH或者直接调用该目录下的可执行脚本。如果你只是想把整个虚拟环境放到指定位置那更简单创建虚拟环境时直接指定路径。python3 -m venv /opt/hermes/hermes-env /opt/hermes/hermes-env/bin/pip install hermes-agent源码安装指定目录则需要在 configure 阶段或者 make install 阶段传入 prefix。比如用 Makefile 管理的项目一般支持./configure --prefix/opt/hermes make make install我个人的建议是如果是学习研究用装在哪其实无所谓默认虚拟环境就够如果是生产环境要长期维护把它放在/opt/hermes这种标准路径下目录结构清晰后面升级备份都方便。指定安装目录最大的坑是环境变量路径配错装完之后hermes命令找不到这时候检查一下 PATH 和 PYTHONPATH 就行这两个环境变量看准了基本都能解决。3.4 Hermes 桌面版与 Studio 工作台怎么选热词里同时出现了Hermes Agent、Hermes Studio 下载、桌面版这些说法很多新手会混淆。按我的理解这套东西大致分两个形态命令行的核心执行引擎Agent Core以及提供可视化界面的工作台Studio 或桌面版。命令行版是所有能力的基础Studio 是它的外壳。Studio 的主要价值在于你可以可视化地观察 Agent Loop 每一轮的运行状态——模型当前的规划是什么、正在调用哪个工具、工具返回了什么、模型下一步的判断是什么。这个可观察性对调试来说太重要了。我建议你的学习路径是这样的第一步先用命令行版跑通一个最简单的任务比如让它写一句问候语然后调用一下系统时间工具第二步装上 Studio 或桌面版把前面那个简单任务在界面里跑一遍对照着看每一轮 Loop 的日志第三步再上复杂任务借助可视化界面的执行轨迹来定位问题。跳步直接上复杂任务你会在几十轮循环的日志里迷失方向。4. 把 Loop 用起来Obsidian 接入与第三方工作台场景4.1 Obsidian 接进来知识库就有了手脚热词里有个Hermes Agent Obsidian这个组合是我个人认为最有意思的落地场景。Obsidian 是一个本地笔记库存着你的知识沉淀Hermes 如果能把 Obsidian 当作工具接入Agent Loop 就有了一条直接触达个人知识库的路径。实现方式一般是这样的Hermes 里注册一个Obsidian 搜索工具工具的职责是接收查询关键词解析 Obsidian 的本地存储格式Markdown 文件加索引返回匹配的文件路径和内容摘要。工具注册完之后你跟 Agent 说帮我找出去年关于 Agent Loop 的笔记并提炼出当时的结论模型就会先调用搜索工具去笔记库里检索拿到结果后再基于内容做提炼。这里有一个关键点Obsidian 的笔记是纯本地的 Markdown 文件Hermes 用它作为工具时并没有做任何魔法只是把文件检索能力封装成了一个可被模型调用的函数。真正有价值的不是技术本身而是这个组合带来的工作流变化——你的 Agent 不再是一个没有记忆的问答机器而是能基于你过往积累的知识做判断的助手。我在实际使用中踩过一个坑笔记库文件多了之后工具返回的搜索结果摘要太长把上下文撑爆了。后来我在工具定义里加了一个约束搜索结果默认返回前 5 条每条截断到 200 字以内如果模型觉得不够再通过二次调用获取全文。这个小改动直接让 Obsidian 相关任务的循环稳定了很多。4.2 第三方工作台对接一个工具注册的实战思路除了 ObsidianHermes 还可以对接很多东西——数据库、HTTP API、命令行工具、定时任务。它靠的就是工具注册机制。我以对接一个内部 API 为例讲清楚工具注册的本质。from hermes import tool tool( namequery_sales_report, description查询销售日报数据适合在需要获取当日或历史销售情况时使用, parameters{ date: {type: string, description: 日期格式 YYYY-MM-DD}, region: {type: string, description: 大区如 华北、华东} } ) def query_sales_report(date: str, region: str): # 这里是实际调用内部 API 的逻辑 response internal_api.get_sales(date, region) return response.json()看懂这段代码你就明白工具注册的实质把一段普通函数包装成模型可以理解、可以调用的接口。注册的工具会进入工具注册表模型在规划阶段会看到这些工具的描述并在执行阶段生成调用指令。如果你的内部系统足够规范用这个思路对接十几个工具是很快的事。需要注意一个细节工具描述里我特意写了适合在需要获取销售情况时使用而不是只写查询销售报表。这是刻意为之的。模型判断什么时候用什么工具完全依赖描述里的语义线索。描述写得越贴近真实使用场景模型选对工具的概率越高。对接过程中最容易翻车的环节是工具返回的数据格式不规范。有些内部 API 返回的 JSON 嵌套层级特别深模型在后续循环里解析起来很吃力。我在做对接时通常会加一个数据整形层把深层嵌套压平、把 null 值统一处理、把大的文本字段截断成摘要。模型拿到的数据越规整Loop 的收敛速度越快这是投入产出比非常高的一件事。4.3 一个完整的 Agent Loop 运行案例光讲概念不够我给你一个真实的运行轨迹让你感受一下 Loop 全貌。任务是这样整理一份华东区上周销售异常分析覆盖 7 月 1 日到 7 月 7 日输出 Markdown 报告。第一轮模型解析目标识别到任务约束华东区、上周、销售异常分析、Markdown规划第一步是先拿到销售数据于是调用 query_sales_report 工具参数 date 设定为 7 月 1 日到 7 月 7 日region 设定为华东。工具返回七天的数据。第二轮模型查看数据发现部分日期数据为空判断这可能影响异常分析于是重新规划调用一个数据质量检查工具确认那个日期是系统故障导致的数据缺失并在报告里标注数据缺失说明。第三轮模型基于已有数据做异常判定发现 7 月 4 日销售额骤降调用一个流程追踪工具查那天是否有促销活动或系统问题工具返回当天有支付网关故障记录。第四轮模型综合所有信息生成分析结论对照 Done Condition报告包含数据、异常点、原因分析检查确认满足停止循环输出 Markdown 报告。整个任务跑了四轮循环涉及三次工具调用中间有一次因为数据缺失而绕路。这就是一个健康的 Agent Loop目标清晰、逐步执行、发现问题、回到规划层调整、最终收敛。你如果能在工作台里看到它的执行轨迹会看到一条清晰的路径从目标出发经过规划、执行、反馈每一圈都比上一圈更接近最终结果。5. 常见问题与排查技巧实录5.1 安装环节的那些坑安装 Hermes 时遇到最多的是依赖冲突。我在 Ubuntu 上第一次用 pip 直接装的时候系统提示某个依赖库需要更高版本但那个库是系统 Python 的组成部分不敢乱动。后来改成在虚拟环境里装一切安静了。还有一个高频坑hermes 命令找不到。原因通常是安装目录不在 PATH 里。排查思路很简单先pip show hermes-agent确认装到了哪个路径再看那个路径下的 bin 目录有没有可执行文件最后把路径加进 PATH。记住激活虚拟环境后which hermes如果输出为空多半就是 PATH 或安装路径的问题不是软件本身的问题。源码安装的坑集中在拉取仓库失败。如果你访问代码仓库不稳定可以试试用指定 release 的压缩包下载或者把仓库克隆的传输方式换成更稳的通道。这里没什么高深技巧把连通性问题的排查和安装问题的排查分开一步步来就行。5.2 执行流程卡住不循环了怎么查Agent Loop 卡住有几个典型迹象第一日志里模型连续三轮输出相同的规划没有任何进展第二工具调用一直报同样的错误模型没有换方案第三模型一直在思考但迟迟不调用任何工具。我排查卡循环问题有一个固定套路先看最后三轮循环的日志确认模型重复在做什么。如果是重复同样的规划通常是工具描述给了模型错误暗示让它死磕一个错误方向这时我会检查工具描述有没有误导性表述。如果是一直报同一个工具错误就去工具实现里找问题而不是继续调模型参数。如果是模型空想不调用工具多半是上下文太长导致模型忽略了工具描述这时候把上下文截断策略调紧凑一些效果立竿见影。5.3 工具调用失败的定位思路工具调用失败分两层一层是调用本身失败网络错误、接口 500、参数错误另一层是工具成功了但返回的数据不是模型想要的。后者比前者隐蔽得多因为所有日志看起来都正常。我遇到过最典型的一次工具返回了 200 状态码和一段空数组模型以为没数据实际上是因为参数传错了时间范围查询条件太严格。这种日志里不会有任何报错只有当你把工具返回值和你的查询参数放到一起看才能发现。所以排查工具问题不要只看异常还要看正常返回背后的逻辑是否符合预期。看日志的时候我会同时确认两个信息模型传了什么参数、工具实际执行了什么查询逻辑。两厢对照问题马上就清楚了。5.4 快速排查速查表症状可能原因优先排查动作命令找不到PATH 或虚拟环境未激活which hermes检查安装路径安装时依赖冲突系统 Python 环境被污染改用虚拟环境重新安装模型不调用任何工具工具描述缺失或上下文过长检查工具注册是否成功、调紧上下文截断连续多轮重复规划工具描述误导或 Done Condition 不清精简工具描述明确终止条件工具调用超时外部服务响应慢设置超时上限并让模型尝试其他方案返回空数据但无报错查询参数过严或条件错误联合查看返回值和入参验证数据上下文内容溢出工具返回结果过大对工具返回结果做截断和摘要这张表是我在真实排障过程中总结出来的不敢说覆盖所有场景但至少能帮你把 80% 的常见问题快速定位到正确的方向。比起一个接一个试按这张表直接走省下的时间可不少。6. 我的几个实操心得最后一章不写总结了就分享几条我在跑了大量 Hermes Agent Loop 之后留下的体会算是给正准备动手的你一些贴身提醒。第一工具描述值得你花大力气打磨。我在前面反复提到这一点因为它是影响 Loop 质量最被低估的因素。模型不知道你的工具内部怎么实现它只能通过描述来理解何时该用你。同样一个 SQL 查询工具描述写执行 SQL模型会滥用描述写在需要从业务数据库中按条件查询数据时使用支持聚合和过滤模型就知道该在什么场景想起它。花半小时把工具描述写清楚比花半天调模型参数划算得多。第二不要追求零失误的 Agent Loop要追求可自愈的 Agent Loop。模型在循环里犯错是常态关键是它犯了错之后能不能从错误信息里恢复。Hermes 的错误回填机制给了模型这个能力你要做的是确保每条错误信息都有下一步怎么办的提示。比如工具超时返回服务暂不可用可以尝试备选数据源模型就会去买备选方案如果只返回ERROR模型就只能原地打转。第三观察执行轨迹比看最终结果更能提升你的水平。装上工作台之后我养成了一个习惯每次任务跑完不急着看输出报告先看它的执行轨迹看它在哪一轮做了不同的规划选择哪一个反馈让它改了方向。看得多了你对模型会怎么理解你的工具会有非常直觉的判断下次写工具描述和配置参数的时候准确率高一大截。第四从简单任务开始建立信心。我见过很多人一上来就让 Agent 做一个包含十几个工具调用的复杂业务流程结果到处报错转头就把锅甩给框架。放下键盘想想一个实习生刚入职你也不会直接让他负责全公司的月度报告。先让它跑通查一下当前系统时间再回复我这种单工具任务再逐步增加循环的复杂度每一步都确认 Loop 是健康的再去走下一步。这个节奏虽然慢但比反复推倒重来快得多。