智能体评测：为什么步骤比方法名更重要？

如果你最近在关注智能体评测，大概率会碰到一种表述：ASI-Bench 认为，步骤比方法名更决定智能体表现。我第一次看到这个判断时，第一反应是把它当成一句常识——搞智能体开发的人都知道，写提示词别太迷信方法名。可再往下想，这件事其实值得细拆：方法名是什么？步骤又是什么？为什么一个评测基准会把“步骤比方法名更重要”写成核心结论？这背后不只是提示词技巧，而是整个智能体开发、调试和评测方式的问题。

过去一年里，智能体领域最热闹的词汇基本都是“方法名”：ReAct、Plan-and-Execute、Reflexion、Toolformer……每出现一个新名字，社区就会跟风把它写进 system prompt，好像只要在提示词里声明“我是使用 ReAct 方法的智能体”，模型就会自动表现出对应能力。ASI-Bench 这个方向提出了一种相反的研究视角：决定智能体表现的，不是你在提示词里写了什么方法名，而是你实际让模型执行的步骤序列。方法名是标签，步骤是行为。

1. 先承认一个现实：方法名是压缩后的“叙事”

1.1 为什么智能体社区特别吃“方法名”这套叙事

你可以观察一个很普遍的现象：两个开发者讨论智能体时，几乎不会说“我的智能体每一步干什么”，而是会说“我的智能体用了 ReAct”。一个方案如果被归纳成某个方法名，它传播起来就特别快。原因很简单，方法名是压缩符号，把一个复杂流程浓缩成几个字，沟通成本低。

但这也带来一个副作用：方法名被当成“性能来源”。很多人觉得，只要在提示词里加上某个方法名，模型就会按那个方法去推理。实际上，大语言模型看到“ReAct”这个词，确实可能会联想到训练语料中与 ReAct 相关的推理模式，但这种联想非常模糊，而且容易受到其他 prompt 内容和上下文干扰。方法名本身不携带执行逻辑，它只是触发某种行为倾向的词。

我最早做智能体相关实验时，也有过类似误解。当时我把一个 agent 的 system prompt 从“You are an agent”改成“You are an agent using Plan-and-Execute”，发现效果确实好了一些，就误以为是 Plan-and-Execute 这个名字起了作用。后来把 prompt 里的方法名删掉，只保留“先拆计划，再逐步执行”的步骤说明，效果几乎没变。再后来，我把步骤顺序打乱，效果立刻下滑。那一刻我才意识到，真正起作用的是步骤，不是名称。

这种个人直觉不一定能代表所有场景，但它和 ASI-Bench 标题透露的方向一致：方法名是结果，步骤才是原因。把智能体性能归因于方法名，就像把一道菜的成功归因于菜名，而忽略了下锅顺序、火候和调味时机。菜名可以让你记住这道菜，但真正决定味道的是操作过程。

1.2 ASI-Bench 想拆开的，正是“标签”和“行为”

从 ASI-Bench 的标题看，这个基准想做的不是再比较几个方法名谁强谁弱，而是把“方法名”和“步骤”分开来做控制变量。合理推测，它会设计一组任务，让智能体在相同方法名下使用不同步骤，或在相同步骤下换不同方法名，然后看最终表现。

这种设计的价值在于，它迫使评测者不再用名称概括一个智能体的全部。以前我们比较 ReAct 和 Plan-and-Execute，可能把差异全归因于“方法不同”。但如果按 ASI-Bench 的思路，差异可能来自流程中的步骤顺序、中间验证、重试策略。方法名只是这些细节的标签，真正的因果发生在步骤层面。

换个角度看，方法名是一个封装好的“默认流程”。ReAct 之所以好用，不是因为它叫 ReAct，而是因为它定义了“思考—行动—观察”的循环。Plan-and-Execute 之所以好用，也不是因为名字里有 Plan，而是因为它把任务拆成规划阶段和执行阶段，并在执行阶段允许逐步调整。这些内容的真正承载者，是步骤。方法名只是把步骤包起来之后贴上的便签。

ASI-Bench 真正让人兴奋的地方，是它可能提供了一个更干净的归因基准。如果所有智能体都贴上相同的方法名，但步骤定义不同，最终表现有差异，那么说明评测不能只看方法名；如果所有智能体步骤相同，只改方法名，最终表现差异很小，那么说明方法名的作用被高估了。这种“拆变量”的方式，比单纯比较两个框架的最终得分更有解释力。

2. 为什么步骤比方法名更容易成为“决定项”

2.1 步骤决定了模型每一步能看到什么

一个智能体每走一步，模型实际上都在做一件事：根据“到目前为止的完整轨迹 + 当前指令 + 可选动作”决定下一个动作。这个完整轨迹就是步骤带来的。如果你用 ReAct 方法名，但没有把上一步工具返回的结果塞给下一步，模型就像蒙着眼睛在房间里找钥匙，方法名再响亮也没用。

反过来，哪怕你不提任何方法名，只要每一步的输入都包含足够信息、动作空间清楚，模型也能表现出很强的规划能力。步骤在这里的核心作用是“信息漏斗”：它决定了每一步应该收集什么信息、过滤什么信息、把什么传给下一步。

举个很常见的例子。一个任务需要先搜索资料，再总结观点，最后核对来源。如果步骤顺序是“先搜索、再总结、再核对”，每一步的信息依赖都很明确。但如果你把顺序调成“先总结、再搜索、再核对”，模型在没有资料的情况下，只能凭借训练时的记忆先写一个结论，后面的搜索阶段很容易变成“为结论找证据”，而不是“根据证据得出结论”。这种偏差，不是方法名能纠正的。

2.2 步骤决定了错误恢复能否真正发生

方法名通常暗示一种行为：ReAct 暗示推理和行动交替，Reflexion 暗示自我反思，Plan-and-Execute 暗示先规划再执行。但“暗示”不等于“发生”。模型不会因为你在 prompt 里写了“反思”就自动知道该怎么反思。反思的对象是什么？判断标准是什么？反思后重跑哪个步骤？这些都要靠具体步骤定义。

如果在步骤设计中加入一个“验证节点”，比如“生成答案后，先检查是否包含所有必需字段，再返回”，模型才算真正有机会修正错误。如果不加这个节点，Reflexion 方法名只是一句空话。这也是 ASI-Bench 这类评测会关注步骤设计的原因——步骤才是触发智能体行为的可操作单元。

从工程经验看，一个常见的失败模式是：智能体在第一步调用搜索工具后返回了一堆内容，但第二步的 prompt 没有明确说“请基于上一步的搜索摘要回答”，模型可能直接忽略上一步内容，自由发挥。这时候你无论把方法名改成什么，结果都差不多。只有把“基于上一步输出”写进步骤定义，模型才会把注意力放在工具返回结果上。

2.3 步骤决定了成本、稳定性和终止条件

方法名本身不会告诉系统什么时候停下来。一个智能体如果只有“思考后行动”的方法名，没有具体终止条件，它可能在一个错误循环里反复调用工具，消耗 token，直到超时。步骤设计中如果写清楚“如果重试两次仍失败，返回当前最优结果并标记未完成”，成本预期就变得可控。

从生产角度看，步骤设计还决定了可观测性。每一步有名字、有输入输出，就能记录日志、分析失败。方法名只是一行字符串，无法用来定位问题。要定位问题，只能看步骤。

我发现很多团队在评测智能体时，只看最终分数，不看中间轨迹。结果就是：模型用了 20 次工具调用，绕了很多弯，最后蒙对了一个答案；另一个模型只用了 3 次调用，路径清晰，答案也正确。只看最终分数，两者一样；看步骤，后者明显更稳定。ASI-Bench 如果是一个步骤敏感的基准，它大概率会把这种过程差异纳入衡量范围。

注意：如果你发现一个智能体改了方法名之后效果变化不大，但调整步骤顺序后差异明显，说明真正起作用的是步骤，不是名字。

3. 从 ASI-Bench 的视角，沉淀一个步骤质量评估框架

看一个智能体设计得好不好，不能只看它用了哪个方法名。我把日常会用到的检查点整理成一套“四看”框架：看完整性、看顺序、看粒度、看反馈与终止。这个框架不是 ASI-Bench 的官方定义，而是从“步骤比方法名更重要”这个判断出发，落到实际开发时最值得检查的地方。

3.1 步骤完整性：每一步有没有明确的目标和出口

一个步骤如果只有一个含糊的指令，比如“请完成这个任务”，模型就不知道边界在哪里。一个健康的步骤，至少要回答四个问题：

很多时候，智能体表现不稳定，不是因为模型不够强，而是因为步骤缺少出口。比如第一步让模型“搜索资料”，但没有说明搜索后要把摘要写入哪里，第二步就不知道上一步结果放在哪。这种问题，在调试日志里一眼就能看出来，但如果不拆步骤，只看 prompt，很容易被忽略。

3.2 步骤顺序：信息依赖是否先于信息使用

顺序是步骤设计里最容易被低估的维度。ASI-Bench 如果要比较步骤差异，大概率会做顺序扰动实验：同一组步骤，交换先后顺序，看结果变化。核心原则很简单：必须先有数据，再让模型基于数据做决策。

举个例子。任务要求“总结文档，并判断文档观点是否可靠”。步骤顺序应该是先分段阅读、再总结、再判断；如果先让模型判断可靠性，它没有足够信息，只能凭空“发挥”。更隐蔽的问题是，很多 prompt 里虽然写了“先搜索再总结”，但模型生成时仍然会提前输出结论。要解决这个问题，不能只靠一句“请先搜索”，最好把搜索步骤的最终输出定义为“只允许输出资料摘要，不允许输出结论”，从步骤层面隔离模型的自由发挥空间。

3.3 步骤粒度：拆到多少步最合适

步骤太粗，模型容易遗漏细节，工具调用失败后难以重试。比如“写一份市场分析报告”作为一步，模型大概率会直接生成一篇文本，中间没有信息收集、数据核对、结构检查。步骤太细，每步只做一个小动作，上下文积累长，容易偏离，token 成本高。经验是：把“需要调用不同工具”或“需要阶段性验证”的地方拆成独立步骤，其余可以合并。

实际开发里，我一般会先按“从一个状态到另一个状态”来定义步骤。如果这一步前后，智能体拥有的信息发生了质变，就值得单独成步。比如“从资料中提取关键事实”是一个步骤，“基于关键事实生成结论”是另一个步骤。两个步骤之间有一个可检查的中间产物，后面出了任何问题，都能定位到具体是哪一步丢了信息。

3.4 步骤反馈与终止：失败后能不能看见、能不能止损

步骤设计不能只规划正常流程，还要规划失败流程。工具调用返回空，是重试、换关键词，还是停止？模型连续三次输出相同错误计划，是改方案，还是按原计划继续？这些都应该写成步骤规则，而不是寄望于方法名自己完成“反思”。

这里有一个容易被忽略的点：反馈不是简单地把工具结果塞给模型。反馈信息要足够结构化，让模型知道这次调用是否成功、哪里失败、下一步可选范围是什么。例如，搜索没有结果时，反馈信息应该写成“搜索无结果，建议更换关键词或跳过此步骤”，而不是“搜索完成”。前者包含判断，后者只是状态描述。

这套框架后来被我用于所有智能体配置评审。看一个智能体设计健不健康，不是看它有没有用某个流行方法名，而是把步骤列出来，依次检查完整、顺序、粒度、反馈与终止。ASI-Bench 的价值，就是提醒我们把评测焦点从“方法名”移到这些步骤属性上。

4. 做一次“方法名不变，步骤变”的对照实验

如果你还是不太确定，建议亲自做一次很小的实验。这个实验不需要复杂框架，只需要一个支持多步工具调用的智能体开发环境，加上一点耐心。

4.1 为什么单次跑通不算结果，先讲实验设计

很多人调智能体，习惯是“换一个方法名，跑一遍，看结果变好还是变坏”。这种对比其实是混淆的，因为你同时改了词、改了行为预期、甚至改了步骤。ASI-Bench 的方向启发我们做一个更干净的对照实验：固定模型、固定方法名、固定任务，只修改步骤定义。这样如果表现差异，才能归因于步骤。

推荐按下面的流程走：

1. 选一个需要至少两次工具调用的任务，比如“搜索某个技术主题，并写一段带有信息出处的总结”。
2. 写两版步骤定义：A 版按“先搜集信息，再分析”的顺序；B 版故意打乱顺序或改变粒度。
3. 两版 system prompt 都保留同一个方法名，比如都写“You are an AI assistant that uses Plan-and-Execute.”
4. 各运行几次，记录成功率、耗时、token 消耗、失败类型。
5. 交换方向：同一套步骤，两版 prompt 一个写方法名一个不写，再对比一次。

如果出现“方法名相同、步骤不同，结果差异明显”，那就验证了 ASI-Bench 标题里的核心判断。如果反过来“方法名不同、步骤相同，结果几乎没差异”，那更说明方法名的作用被高估了。

4.2 用伪代码描述两版步骤

下面是一个概念示例，不是可直接运行的代码，只是为了说明“同一方法名”下如何用不同步骤定义做对照。

# 概念示例：同一个方法名，两种步骤定义 system_prompt = "You are an AI assistant that uses Plan-and-Execute." steps_v1 = [ {"name": "search", "action": "根据问题关键词调用搜索工具，得到资料列表"}, {"name": "extract", "action": "从资料中摘出与问题相关的关键事实"}, {"name": "compose", "action": "基于关键事实写出最终答案"}, ] steps_v2 = [ {"name": "compose", "action": "先凭已有知识写出一个答案"}, {"name": "search", "action": "搜索资料来证明这个答案"}, {"name": "extract", "action": "只保留支持答案的资料，忽略反面资料"}, ]

在真实工程里，steps 可能是 agent 框架中的节点配置、工作流画布上的节点，或者是一段更结构化的 JSON。关键是：两版步骤对应的工具和能力都相同，只是顺序和粒度不同。如果 v2 的成功率显著低于 v1，说明步骤顺序确实是决定因素。

4.3 用什么指标看结果

不要只看“最终答案正确率”。建议至少记录这些内容：

• 每一步工具调用是否符合预期；
• 哪一步开始偏离；
• 错误发生后，后续步骤有没有修正能力；
• 相同方法名下的步骤版本差异有多大；
• 从开始到结束一共调用了多少次工具，消耗了多少 token。

有一个很常见的结果：两个版本最终答案质量差不多，但步骤设计更合理的那版，工具调用次数更少，稳定性更高。这种情况下，只看最终分数会得出“两版差不多”的错误结论，但看步骤指标，高下立判。

先不要急着跑 100 条样本。用 5 条样本把 trace 看明白，再扩大实验，否则你只会拿到一堆无法解释的平均分。

5. 从实验到生产：排查步骤问题时走哪条链路

5.1 按“现象→输入→环境→参数→步骤”的顺序排查

智能体出了问题，很多人的第一反应是“换 prompt”。如果换完有效，就以为是 prompt 里的方法名选对了。但这个方法太粗，因为 prompt 里有太多可能影响结果的因素。更稳妥的做法是按下述链路排查。

第一步看现象：是最终结果错误，还是中间中断，还是结果一致但很慢？第二步看输入：每一步是不是拿到上一步的真实输出，有没有字段丢失、被截断。第三步看环境：模型版本、工具接口、上下文窗口、依赖库版本是否匹配。第四步看参数：temperature 是否过高导致步骤漂移，max_tokens 是否截断了长输出，重试次数是否合理。第五步再看步骤：顺序是否违背信息依赖，粒度是否合适，终止条件是否缺失。

这个顺序背后的逻辑是：先确定问题出现在哪个层级，再决定修哪里。很多时候，步骤定义没问题，是上游工具返回的数据格式变了，导致下一步拿不到字段。这种问题如果一上来就改步骤，反而会把原来健康的流程改坏。

5.2 一张智能体步骤问题排查表

这张表适合作为日常调试的起点。如果一个智能体频繁出现“反复调用同一个工具”的问题，第一步不是去改方法名，而是去检查终止条件。反过来，如果答案是“缺少依据”，优先怀疑的应该是步骤顺序，而不是换一个更花哨的方法名。

5.3 边界：ASI-Bench 的结论不是万能钥匙

这套“步骤优先”思路，更适合多步工具调用、信息搜集和任务规划场景。如果任务本身是单轮问答、不需要外部工具，步骤和方法名的差异可能很小。如果模型本身推理能力很强，即使步骤顺序有一点问题，它也可能在单次生成里自我修正。所以不要得出“方法名永远没用”的结论。

ASI-Bench 作为一个评测基准，它的价值是提供了一种更严谨的归因视角：在可控条件下比较步骤与方法名。真实环境里，两者经常纠缠在一起，需要做对照实验才能拆开。如果用这个视角去审视自己的智能体，你会发现很多原来“说不清楚”的效果提升，其实都来自步骤改动，而不是方法名变化。

排查步骤问题时，不要一上来就怀疑 prompt “方法名写错了”，先确认每一步的输入输出有没有真正接上。

6. 智能体评测该记录什么，才不会被方法名误导

6.1 方法名是压缩符号，步骤才是可执行资产

一个智能体项目如果只写到“用了 ReAct/Plan-and-Execute”，别人无法复现。真正可复用的是工具定义、状态机、步骤序列、验证规则、终止条件。方法名可以当作目录，但不能当作实现。

这也解释了为什么很多论文和开源项目在换了一个方法名之后，社区复现时效果不一致。不是方法本身有问题，而是每个复现者对步骤的理解不同。有人把规划阶段拆成三步，有人把规划阶段合并成一步；有人加了中间校验，有人没有。这些差异在最终效果上的影响，可能远远大于方法名字面上的差别。

ASI-Bench 如果能把“步骤”变成评测框架中的显式变量，它带来的不只是一个新的 benchmark，还会改变智能体社区讨论问题的方式。以后大家不再问“你用哪个方法”，而是问“你每一步怎么定义、怎么连接、怎么终止”。这个问题更接近工程本质。

6.2 对三类人的建议

对于开发者，建议搭 agent 时先画步骤图，再起名字；评测时要保存 action trace，不能只留一个最终答案。下次判断效果好坏，先看步骤，再看分数。

对于框架设计者，建议把“步骤”变成一等公民。给步骤加上名称、输入、输出、验证字段，让开发者能可视化每一步的状态。现在很多框架仍然把步骤藏在代码堆里，调试时只能靠打印日志，这会让人误以为“方法名”很重要，因为步骤不可见。

对于评测者，建议在 benchmark 报告里至少做一组“同步骤不同名”“同名不同步骤”的对照。只有把方法名和步骤解耦，才能知道一个智能体的强项到底来自哪里。否则，所有方法名对比都可能是鸡同鸭讲。

ASI-Bench 这个方向真正值得长期关注的，不是某个方法名是否更先进，而是它把智能体性能的归因从“名字”拉回“行为”。下次再看到有人宣称“我的智能体用了 XX 方法所以很强”，可以先问一句：它的每一步到底是怎么定义的？哪个步骤负责收集信息，哪个步骤负责验证，哪个步骤决定停止？如果这些问题能答清楚，方法名反而没那么重要。