Routine:A Structural Planning Framework for LLM Agent System in Enterprise

这篇论文的核心价值在于，它没有停留在“让大模型自己想”的层面，而是创造性地提供了一个“剧本”，从根本上解决了企业级Agent落地难的痛点。

我们将从问题根源、解决方案（Routine框架）、系统架构、训练方法、实验结果、核心洞见六个维度，层层递进地进行深度剖析。

PS:在附录提供了prompt、routin的格式、多步工具调用的例子

一、 问题根源：为什么企业级Agent总是“掉链子”？

论文开篇就犀利地指出了当前LLM Agent在企业环境中失败的三大根本原因：

  1. “无知” (Lack of Domain-Specific Process Knowledge)：

    • 通用大模型（如GPT-4）是“通才”，但不是“专才”。它不了解企业内部错综复杂的业务流程。
    • 后果：模型在规划时会遗漏关键步骤。论文特别指出，最容易被忽略的是权限验证（permission verification）和模型生成（model generation）这类工具。例如，一个HR查询任务，模型可能直接去查员工薪资，而忘了先验证当前用户是否有权限查看该信息，导致安全漏洞或执行失败。

  2. “工具说明书看不懂” (Insufficient Tool Descriptions)：

    • 企业内部的API或工具文档往往不完善、不标准，甚至存在歧义。
    • 后果：即使模型知道“该做什么”，也不知道“用哪个工具做”以及“怎么填参数”。这直接导致了工具调用的不稳定和高错误率。

  3. “计划书写得乱七八糟” (Lack of Unified, Structured Format)：

    • 当前的规划模块输出的往往是自由格式的自然语言指令，比如：“嗯…先查一下用户信息，然后…哦对，还得看看他的部门，最后生成个报告。”
    • 后果：执行模块需要“猜”模型的意图。这种“猜”的过程充满了不确定性，导致规划与执行严重脱节。执行模块可能误解步骤、跳过步骤、或调用错误的工具。

总结来说，企业级Agent的失败，不是因为模型不够“聪明”，而是因为缺乏一个清晰、稳定、可执行的“操作手册”。

二、 解决方案：Routine——你的AI“操作剧本”

Routine是这篇论文的灵魂。它不是一个算法，而是一个结构化的、人类和AI都能理解的“剧本”格式。

2.1 Routine的精密结构

一个完整的Routine由多个Step（步骤）组成，每个步骤是一个原子化的操作单元。其核心组件如下：

组件 (Component) 作用与意义 为什么重要
Step Number (步骤编号) Step 1, Step 2, Branch 3-1 Step 1 明确执行顺序。让执行模型知道“现在该做第几步”，是线性执行还是进入分支。这是实现“按部就班”的基础。
Step Name (步骤名称) Check User Permission, Fetch Employee Data 功能摘要。让人和AI能快速理解这一步是干什么的，便于调试和维护。
Step Description (步骤描述) “验证当前用户ID是否有权访问目标员工的薪资信息。” 详细指令。告诉执行模型“具体要做什么”，包括执行条件和目标。这是自然语言指令的核心。
Step Tool (步骤工具) verify_user_permission, get_employee_salary 强制指定工具。这是Routine最革命性的设计！它把“选择哪个工具”这个高难度、高错误率的任务，降级为“执行哪个指令”的简单任务，极大降低了执行模型的认知负担。
Input/Output Description (输入/输出描述) (可选) “输入：当前用户ID，目标员工ID；输出：布尔值（True/False）” 参数指南。帮助执行模型理解需要什么参数，以及上一步的输出是什么。对能力较弱的模型是巨大的帮助。 
1
2
3
4
5
6
7
# 例子
<routines>
Step 1. Get announcements: Download the latest employee handbook file from the company’s internal system, use the `fetch_latest_announcements` tool;
Step 2. Download handbook: Obtain the company’s most recent official announcement for consistency check with the employee handbook, use the `download_file` tool;
Step 3. Read PDF content: Use text parsing tools to extract all text content from the employee handbook PDF file, use the `read_pdf` tool;
Step 4. Compare text differences: Compare the relevant content in the employee handbook with the company’s latest announcement word by word, using the `compare_texts` tool, and end the workflow;
</routines>
步骤编号 (Step Number) 步骤名称 (Step Name) 步骤描述 (Step Description) 指定工具 (Step Tool) 输入输出
Step 1 Get announcements 从公司内部系统下载最新的员工手册文件。 fetch_latest_announcements
Step 2 Download handbook 获取公司最新的官方公告，以便与员工手册进行一致性检查。 download_file
Step 3 Read PDF content 使用文本解析工具从员工手册的PDF文件中提取所有文本内容。 read_pdf
Step 4 Compare text differences 逐字比较员工手册中的相关内容与公司最新公告，然后结束工作流。 compare_texts

2.2 支持分支：处理复杂业务逻辑

企业流程往往不是一条直线，而是充满“如果…那么…”的判断。Routine通过精妙的命名规则支持分支逻辑：

  • Step X.<Name>: 主步骤，通常是条件判断。
  • Branch X-n Step i.<Name>: 表示主步骤 X 的第 n 个分支中的第 i 个步骤。

示例：

1
2
3
4
Step 3. Check User Role:
• Branch 3-1 Step 1. If user is 'Manager', fetch team data using `get_team_info`.
• Branch 3-2 Step 1. If user is 'Employee', fetch personal data using `get_personal_info`.
Step 4. Generate Report: Compile data using `generate_report`, and terminate.

这种设计让Routine能够描述几乎任何复杂的业务流程，而执行模型只需根据上一步的结果，找到对应的分支继续执行即可。

2.3 工作流程：从草稿到执行

  1. 生成Routine (Planning Module)：

    • 输入：领域专家提供一个简单的、非结构化的流程草稿（Draft），例如：“先验证权限，再查数据，最后生成报告。”
    • 处理：一个强大的规划模型（如GPT-4o）接收这个草稿和可用的工具列表，根据预设的Prompt模板，将其优化、细化、结构化，输出一个包含所有必要组件的完整Routine。
    • 输出：一个格式清晰、指令明确的“操作剧本”。

  2. 执行Routine (Execution Module)：

    • 输入：将生成的Routine、当前对话历史、变量内存、工具列表等，通过一个标准化的系统提示（System Prompt） 传递给执行模型。
    • 处理：执行模型（可以是小模型）严格遵循Routine的指示，按步骤编号，调用指定的工具，并传递正确的参数。
    • 输出：每一步只输出一个标准的工具调用指令（JSON格式），最终一步调用一个专门的“总结工具”生成面向用户的自然语言回复。

核心思想：将复杂的“开放式推理规划”问题，转化为简单的“封闭式指令跟随”问题。

三、 系统架构：四大模块的协同革命

为了支撑Routine的高效运行，论文对传统Agent架构的四大模块进行了颠覆性的重新设计：

3.1 Planning Module (规划模块)：从“思考者”变为“编剧”

  • 核心任务：生成和优化Routine。
  • 关键创新：利用AI（GPT-4o）将专家草稿转化为高质量的结构化剧本。这大大降低了专家的工作量，使得大规模生成Routine成为可能。
  • 与传统区别：传统规划模块输出的是模糊的自然语言计划；Routine规划模块输出的是精确的、可执行的“代码”。

3.2 Execution Module (执行模块)：从“全能王”变为“执行者”

  • 核心任务：严格按照Routine的指示，一步步调用工具。
  • 关键创新：
    • 模型降级：执行模块不需要强大的推理能力，只需要优秀的“指令跟随”能力。因此，可以使用小规模、低成本的模型（如Qwen3-8B）。
    • 职责分离：执行模型不负责生成最终的自然语言回复，而是调用一个专门的“总结工具”。这避免了在同一个Prompt中混合“工具调用”和“文本生成”两种任务，导致模型混淆。
  • 与传统区别：传统架构中，规划和执行通常由同一个大模型完成，成本高昂。Routine架构实现了“大模型规划，小模型执行”，大幅降低成本。

3.3 Tool Module (工具模块)：标准化与解耦

  • 核心任务：提供稳定、可靠的工具接口。
  • 关键创新：采用 MCP (Model Context Protocol) 服务器。
    • MCP以标准化协议定义每个工具的名称、参数类型和调用约束。
    • 执行模块只需关心“调哪个工具”和“传什么参”，无需了解工具内部实现。
  • 优势：实现了执行逻辑与工具层的彻底解耦。开发者可以轻松添加、修改或替换工具，而不会影响执行模块，系统可扩展性极强。

3.4 Memory Module (记忆模块)：智能的“上下文管理器”

为了解决长上下文带来的成本和错误问题，设计了两种记忆：

  • Procedure Memory (流程记忆)：

    • 作用：存储所有预定义的Routine。
    • 机制：当用户提问时，系统通过语义相似度计算，只检索并加载最相关的1个Routine到上下文中。
    • 为什么：避免将所有Routine都塞进Prompt，造成信息过载和干扰，导致模型分心或选错流程。

  • Variable Memory (变量记忆)：

    • 作用：优化多步调用中的参数传递。
    • 机制：如果某个工具返回的参数值过长（如一段长文本或复杂JSON），系统会将其存入临时变量（如 memory_content），后续步骤只需引用这个变量名。
    • 为什么：
      1. 缓解上下文压力：避免长文本占用大量Token。
      2. 减少语法错误：小模型在传递长文本时容易出错（如引号、括号不匹配），引用变量名则完全规避了这个问题。
      3. 提高效率：变量传递比传递实际值更快、更稳定。

四、 训练方法：让小模型“内化”专家知识

论文不仅提出了框架，还提供了让模型更好地利用Routine的训练方案。

4.1 通用Routine跟随训练 (Common Routine-following Fine-tuning)

  • 目标：让模型学会“读懂”并“遵循”任何结构化的Routine。
  • 方法：
    1. 基于开源数据集（BUTTON），使用GPT-4o为8000个样本生成对应的结构化Routine。
    2. 经过数据清洗和过滤（移除自然语言总结、过滤过长或结构复杂的样本），得到4209条高质量训练数据。
    3. 用这些数据对Qwen等模型进行微调。
  • 效果：显著提升了模型在有Routine引导情况下的表现（Qwen3-14B从83.3% → 88.2%），但对模型自主规划能力帮助不大，甚至略有下降。这证明了模型变得更“听话”，但也更依赖外部指令。

4.2 场景特定知识蒸馏 (Scenario-Specific Knowledge Distillation)

这是论文最惊艳的成果，它让小模型“偷师”大模型，把流程知识“学到骨子里”。

  • 目标：让小模型即使没有Routine引导，也能像专家一样正确执行任务。
  • 方法：
    1. 在目标场景（如HR系统）中，使用GPT-4o（教师模型）配合Routine，为537个真实用户查询生成精确的、多步的工具调用轨迹（即“标准答案”）。
    2. 用这些“标准答案”去训练一个较小的“学生模型”（如Qwen3-14B）。
  • 效果：
    • 无Routine时：学生模型的准确率从32.6% 飙升至90.2%！这表明小模型通过蒸馏，成功将特定场景的流程知识“内化”到了自己的参数中。
    • 有Routine时：准确率进一步提升至95.5%，几乎追平了教师模型GPT-4o（96.3%）。
  • 意义：这提供了一条“降本增效”的黄金路径——用大模型+Routine生成高质量数据，训练小模型，最终用小模型以极低成本实现接近大模型的性能。

五、 实验结果：数据说话，Routine威力惊人

论文在真实的HR场景中进行了严谨评估，数据极具说服力。

5.1 Routine的“神效”

  • GPT-4o：从41.1% → 96.3% （提升55.2个百分点）
  • Qwen3-14B：从32.6% → 83.3% （提升50.7个百分点）

结论：无论模型强弱，引入Routine都能带来质的飞跃。它有效弥补了模型在复杂规划和工具选择上的不足。

5.2 消融实验：Routine的哪些部分最重要？

  • 明确指定工具名是“命脉”：

    • 如果Routine中不告诉模型用哪个工具，而是让它自己从描述中推断，几乎所有模型的准确率都会显著下降5%-15%。
    • 洞见：将“工具选择”这个高难度任务转化为“工具执行”这个低难度任务，是Routine成功的关键。

  • I/O参数描述是“锦上添花”：

    • 为步骤添加输入输出描述，对能力较弱的模型帮助很大（如GPT-3.5从52.7% → 61.1%），能减少参数错误。
    • 对顶级模型（如GPT-4o）提升不明显（96.3% → 97.5%）。

  • AI优化 vs 人工标注：

    • 由AI（GPT-4o）优化的Routine，其效果已经非常接近人工专家标注的Routine。
    • 意义：为大规模、低成本地生成高质量Routine提供了可行路径。

  • 记忆模块的“干扰”：

    • 给执行模型同时提供多个相似的Routine会引入干扰，导致准确率下降（如GPT-4o从96.3% → 76.6%）。
    • 洞见：“流程记忆”模块必须高精度，最好只提供最相关的一个Routine。

5.3 分支逻辑的挑战

  • 带有分支的Routine比线性Routine更难执行。
  • 性能越差的模型，在遇到分支时准确率下降越明显。
  • 建议：对于复杂分支逻辑，应确保执行模型本身具备较强的推理能力，或对分支逻辑进行更细致的拆分和描述。

六、 核心洞见与未来方向

核心洞见总结

  1. “计划先行”优于“边想边做”：为企业级Agent提供一个清晰、结构化的“剧本”（Routine），是提升其稳定性和准确性的最有效手段。
  2. “术业有专攻”：分离规划与执行模块，用大模型做“编剧”，用小模型做“演员”，能实现性能与成本的最佳平衡。
  3. “授人以鱼不如授人以渔”：通过基于Routine的知识蒸馏，可以让小模型“内化”领域知识，摆脱对显式计划的依赖，实现真正的“降本增效”。
  4. “细节决定成败”：在Routine中明确指定工具名是提升准确率的最关键因素。

未来工作

  1. 引入强化学习 (RL)：让规划模型能通过试错自主学习生成更好的Routine，让执行模型能学习更优的工具调用策略，提升系统的自主适应能力。
  2. 构建多智能体框架：用一个高级“协调Agent”通过Routine来管理多个专门的“执行Agent”，以处理更庞大、更复杂的业务流程。
  3. 动态Routine生成：探索如何让系统根据实时数据和用户反馈，动态调整和优化Routine，而不是完全依赖预定义的流程。

终极总结：

《Routine》这篇论文的伟大之处，在于它用一个极其简单却无比精妙的“结构化剧本”思想，一举击穿了阻碍企业级AI Agent落地的核心壁垒。它不追求让AI“更聪明”，而是追求让AI“更听话”、“更稳定”、“更便宜”。通过“大模型生成剧本，小模型严格执行，再用蒸馏让小模型自学成才”的三板斧，Routine框架将Agent的执行准确率从“不堪用”的30-40%，提升到了“可生产”的95%以上，为AI真正融入企业核心业务流程铺平了道路。这不仅是技术上的创新，更是工程思想上的胜利。

QA

1. 真实企业的数据集？

  • 合成数据为主，真实数据为辅。
    • 通用Routine跟随数据集（让执行模型学会“读懂”并“严格遵守”任何结构化的Routine指令，提升其基础的指令跟随能力）
      • 在论文中选用的是开源的数据集->用强大的规划模型去合成Routine->进行数据清洗和过滤，移除步骤过多的样本，移除自然语言总结，只保留user_query, tool_call, observation
    • 场景特定知识蒸馏数据集（让小模型“内化”特定业务场景的流程知识，即使没有显式的Routine引导，也能像专家一样准确执行）：
      • 明确场景与工具：明确agent的业务场景（论文中的HR场景的子场景有7个），梳理并标准化所有的工具列表
      • 专家编写routine草稿：让人工专家为每个子场景编写简单的、非结构化的draft步骤（不需要完美，只需要包含关键步骤）
      • AI优化Routine:AI基于此生成高质量routine。这样优化下来的效果已经非常接近人工专家标注。
      • 设计用户查询模板：
        • 为每个子场景设计5-6个用户查询模板。例如，HR场景下可以是：“帮我查一下[员工姓名]的薪资”或“[部门名称]这个月的考勤情况如何？”
        • 用真实的员工姓名、部门名称等信息填充模板，生成大量多样化的用户查询。
      • 教师模型生成“标准答案”：使用教师模型在有Routine引导下去生成多步调用轨迹（tool_call,observation）
      • 得到一个高质量包含标准答案的数据集
      • 数据增强：
        • 使用LLM对用户查询进行改写，生成语义相同但表述不同的实体，增强模型的鲁棒性和泛化能力。
    • 真实交互数据集（用户评估和迭代，比如RL）
      • 上线测试：将前两种策略训练好的Agent部署到小范围真实业务场景中
      • 收集日志：记录用户的真实提问，agent的每一步调用、工具返回结果、最终回复和用户的反馈
      • 人工审核：对收集到的数据进行人工审核，标注出agent错误的案例及其失败原因
      • 构建评估集：从真实交互数据中筛选出有代表性的样本，构建一个专门的评估数据集（如论文中的200个样本），用于自动化评估（如使用BFCL框架）。
      • 适用场景：主要用于模型性能评估、错误分析和后续的针对性优化，不直接用于大规模训练。

2.这里都是用的SFT去做的，为什么没用RL？

因为在企业级Agent落地的“冷启动”阶段，RL面临数据效率低、训练不稳定、成本高昂等核心挑战。相比之下，基于结构化“剧本”（Routine）的监督式微调（SFT）和知识蒸馏（Knowledge Distillation）是更务实、更高效、风险更低的首选方案。

  • 以下是详细的原因分析：

    1. 冷启动难题：RL需要大量高质量的交互数据

    • RL的运作机制：强化学习需要一个“环境”（Environment）来提供奖励信号（Reward）。在企业Agent场景中，这个“环境”就是真实用户或一个高保真的模拟器。模型通过不断尝试（Trial-and-Error），根据最终任务的成功与否（或中间步骤的奖励）来学习最优策略。
    • 现实困境：
      • 初期Agent能力差：在项目启动时，Agent的自主规划能力非常弱（如论文所示，Qwen3-14B在无引导时准确率仅32.6%）。让它直接与真实用户交互，会产生大量失败、错误甚至有害的响应，严重影响用户体验和企业声誉。
      • 构建模拟器成本高：为复杂的企业流程（如HR、财务、供应链）构建一个能提供精确奖励信号的高保真模拟器，其工程复杂度和成本可能不亚于开发Agent本身。
      • 奖励函数设计难：如何为一个多步骤、涉及权限、数据查询、报告生成的复杂任务设计一个能精确衡量每一步好坏的奖励函数？这本身就是一个巨大的研究难题。

    相比之下，论文的方法优势明显：

    • 数据生成安全高效：利用强大的教师模型（GPT-4o）+ 结构化Routine，可以离线、批量、安全地生成海量高质量的“标准答案”（即正确的工具调用序列），完全规避了与真实用户交互的风险。

    • 数据质量有保障：生成的数据是100%正确的（由教师模型保证），这为监督学习提供了完美的训练信号。

    2. 训练稳定性与可预测性：SFT比RL更可靠

    • RL的不稳定性：RL训练过程 notoriously 不稳定。策略的微小更新可能导致性能的剧烈波动，甚至“灾难性遗忘”。在企业环境中，这种不稳定性是不可接受的，因为系统需要稳定、可预测地运行。
    • SFT的确定性：监督式微调是一个确定性的优化过程。给定一个输入（用户查询+Routine）和一个目标输出（正确的工具调用），模型通过最小化损失函数来学习。这个过程稳定、可复现，更容易调试和部署。

    论文通过Routine框架，将复杂的规划问题转化为简单的指令跟随问题，使得即使是小模型也能通过SFT获得极高的准确率（95.5%），这在RL中是难以想象的。

    3. 成本与效率：SFT是“短平快”的工程胜利

    • RL的计算成本：RL通常需要大量的环境交互和策略迭代，计算成本极高。尤其是在多步骤任务中，探索空间巨大，收敛速度慢。
    • SFT的高效性：论文的方案，特别是“场景特定知识蒸馏”，只需要用教师模型生成一次高质量数据集（537个样本），然后对小模型进行几轮SFT即可。整个过程计算成本低、周期短，非常适合企业快速迭代和部署。

    正如论文摘要所强调的，其目标是提供一个“practical and accessible approach”（实用且易于访问的方法），而RL在现阶段显然不符合这一目标。

    4. 作者的未来展望：RL是下一步，而非第一步

    论文作者并非否定RL的价值，相反，他们在第6节明确将RL列为未来的核心工作方向：

    “To address this challenge, incorporating RL-based agent frameworks into the workflow, including mechanisms for data distillation and reward modeling might be a possible solution. This approach aims to improve the Routine generation capability of the planning model as well as the tool invocation capability of the execution model. The combination of instruction fine-tuning for cold start and reinforcement learning has shown promising potential… and may emerge as a future paradigm…”

    翻译与解读： 作者认为，当前基于SFT和蒸馏的方法，是解决“冷启动”（cold start）问题的最佳方案。它能快速让系统达到一个高准确率、高稳定性的基线水平。在此基础之上，再引入RL，才是更合理的发展路径。

    未来的RL可以用于：

    1. 优化规划模块：让规划模型（Planner）能通过RL自主学习生成更好的Routine，而不是完全依赖专家草稿和AI优化。
    2. 优化执行模块：让执行模型（Executor）能在遵循Routine大框架的前提下，学习更优的工具调用策略或参数填充策略。
    3. 构建奖励模型（Reward Modeling）：利用人类反馈或规则引擎，构建一个能自动评估Agent表现的奖励模型，为RL提供训练信号。

    总结：务实的选择，明智的路径

    论文《Routine》没有选择RL，是经过深思熟虑后的工程最优解。它选择了一条“先立后破”的道路：

    1. 先立：用结构化Routine + SFT/蒸馏，快速构建一个高性能、高稳定、低成本的生产级Agent系统，解决企业最迫切的落地需求。
    2. 后破：在系统稳定运行、积累了真实交互数据后，再引入RL进行精细化优化和自主能力提升，追求更高的智能水平。

    这是一种典型的“MVP（Minimum Viable Product）思维”，先用最简单有效的方法解决核心痛点，再逐步迭代升级。在充满不确定性的企业AI落地场景中，这种务实、稳健的策略，远比追求技术先进性但风险极高的RL方案要明智得多。

但是由于我们这里使我们自己的网站的操作，是不是可以从优化奖励信号这一步去着手？

3. 评测这一步咋做的？

论文《Routine》中的评测设计得非常严谨、系统且具有高度的自动化，其核心目标是精确衡量LLM Agent在企业级多步工具调用（multi-step tool calling）任务中的执行准确率，并深入分析错误来源。评测不是简单地看最终答案对不对，而是像“代码调试”一样，逐层解析模型输出的每一个工具调用指令。

以下是其评测方法的超详细解读：

一、 评测框架：基于BFCL的AST评估

论文选择了开源的 Berkeley Function-Calling Leaderboard (BFCL) 作为核心评测框架，并主要使用其 Function-Calling (FC) 模式 和 抽象语法树 (Abstract Syntax Tree, AST) 评估方法。

为什么选择BFCL？

  • 效率高：不依赖真实工具的响应速度，评测过程快速。
  • 精度高：能对模型输出的工具调用指令进行精确到“括号和逗号”的语法和语义分析。
  • 归因能力强：可以清晰地将错误分类，告诉开发者模型到底是在哪个环节出了问题。

二、 评测流程：分层解析，逐级归因

评测过程是一个层级化的错误检查流程，如论文图7所示。模型的输出会依次经过以下三道“关卡”：

  1. 结构正确性 (Structural Error)

    • 检查内容：模型输出的是否是一个语法正确的JSON对象。
    • 常见错误：
      • 缺少大括号 {} 或方括号 []。
      • 引号 " 不匹配或缺失。
      • 逗号 , 遗漏或多余。
      • 其他任何导致JSON无法被解析的语法错误。
    • 重要性：这是最基础的关卡。如果结构错误，后续的工具和参数检查都无法进行。

  2. 工具选择正确性 (Tool Selection Error)

    • 前提：模型输出的JSON结构必须正确。
    • 检查内容：
      • 模型是否调用了工具，而不是输出了自然语言。
      • 调用的工具数量是否正确（例如，当前步骤只需调用一个工具，但模型调了两个）。
      • 调用的工具名称是否正确，是否是工具列表中定义的工具，是否存在拼写错误或调用了不存在的工具。
    • 重要性：论文发现，这是导致任务失败的最主要错误类型（占所有错误的85%以上）。Routine框架通过明确指定工具名，正是为了解决这个核心痛点。

  3. 参数正确性 (Parameter Error)

    • 前提：模型输出的JSON结构正确，且工具选择正确。
    • 检查内容（分为三个子类）：
      • 参数缺失 (Missing Key Parameters)：必需的参数没有提供。
      • 参数幻觉 (Parameter Hallucination)：提供了工具定义中不存在的参数。
      • 参数值错误 (Incorrect Parameter Values)：参数的数据类型或内容错误。
    • 特殊处理 - 近似匹配 (Approximate Matching)：
      • 对于自由文本参数（free text parameters），论文不采用严格的字符串完全匹配。
      • 原因：在企业场景中，参数值可能是很长的自然语言描述（如用户查询）。模型生成的描述与标准答案在措辞上可能有微小差异（如 “user need: query” vs “user need-query”），但这并不影响语义。
      • 方法：评测系统会检查参数的存在性、类型和关键语义，允许一定的措辞灵活性，避免因吹毛求疵的匹配而低估模型的核心能力。

最终指标：整体准确率 (Overall Accuracy)

一个样本只有在结构、工具、参数三个层面都完全正确，才被计为“正确”。这是最严格、最能反映模型端到端解决问题能力的指标。

三、 评测数据集的构建

为了保证评测的公平性和有效性，论文专门构建了一个高质量的评测数据集。

  1. 数据来源：使用与训练数据相同的“知识蒸馏”方法，由GPT-4o在Routine引导下，为200个用户查询生成精确的、多步的工具调用轨迹（共1,148个独立步骤）。
  2. 数据分解：
    • 将每个完整的多步执行轨迹，分解为多个独立的单步测试样本。
    • 每个测试样本包含：当前步骤之前的所有历史执行记录 + 当前步骤专属的系统提示。
    • 目的：模拟Agent在真实运行时的逐步执行过程，确保评测环境与生产环境完全一致。
  3. 上下文动态性：
    • 由于论文的“变量记忆”（Variable Memory）机制，系统提示会随着执行步骤动态更新（例如，上一步的长输出被替换为 memory_xxx）。
    • 评测系统会完整记录并还原每一步的系统提示状态，确保模型在评测时看到的上下文与其在真实交互中看到的完全相同。
  4. 防作弊设计：
    • 在每个测试样本中，随机打乱工具列表的顺序。
    • 目的：防止模型通过记忆工具在列表中的“位置”来选择工具，强迫模型真正理解工具的功能和名称。

四、 评测场景设置

为了全面评估Routine框架的效果，论文设置了三种不同的评测场景：

  1. 无Routine场景 (No-Routine Scenario / Baseline)：

    • 模型只收到用户查询，必须自主规划并完成所有工具调用。
    • 目的：评估模型的原始能力，作为性能基线。

  2. 有Routine场景（无分支）(Routine-Guided Scenario w/o Branches)：

    • 模型收到一个结构清晰、线性的Routine，其中明确指定了每一步的工具。
    • 目的：评估模型在简单、明确指令下的“指令跟随”能力。

  3. 有Routine场景（有分支）(Routine-Guided Scenario w/ Branches)：

    • 模型收到一个包含条件分支的复杂Routine。
    • 目的：评估模型在面对更复杂、非线性流程时的逻辑判断和执行稳定性。

五、 评测结果分析维度

论文不仅报告了最终的准确率数字，还进行了深入的归因分析和消融实验：

  • 错误分布分析：明确指出在无Routine时，85%的错误来自“工具选择”，证明了Routine通过指定工具名来解决核心痛点的有效性。
  • 模型能力对比：对比了GPT系列、Claude和Qwen系列等不同规模和能力的模型，验证了Routine对小模型的提升尤为显著。
  • 训练策略效果：对比了“通用Routine跟随训练”和**“场景特定知识蒸馏”两种微调策略的效果，证明了后者能让小模型“内化”知识**，在无Routine时也能达到接近GPT-4o的水平。
  • 组件消融实验：
    • Routine组件：测试了“有无工具名”、“有无I/O参数描述”对准确率的影响，证明“明确指定工具名”是最关键的组件。
    • Routine生成方式：对比了“人工标注”、“AI优化”、“用户草稿”的效果，证明AI优化是性价比极高的方案。
    • Routine数量：测试了给模型提供1个、2个、3个或5个Routine时的准确率，证明了“流程记忆”模块需要高精度检索，最好只提供最相关的一个Routine，以避免干扰。

总结：一套工业级的评测标准

论文的评测方法堪称企业级Agent评测的典范：

  • 它不迷信“端到端准确率”，而是通过分层AST解析，精准定位问题。
  • 它不追求“理想化环境”，而是通过动态上下文和随机化工具列表，模拟真实世界的复杂性。
  • 它不仅“评模型”，更“评框架”，通过严谨的消融实验，验证了Routine中每一个设计决策的价值。

这套方法为企业构建和优化自己的Agent系统提供了一套可复用的、科学的评估标准，是论文除Routine框架本身外的另一大宝贵贡献。