glm-5.3-flash 在「多工具协同」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：glm-5.3-flash
- 用例名称：多工具协同
- 测试类型：文本生成
- 评测维度：Agent MCP
系统提示词（System Prompt）
这是给 AI 模型的背景设定和角色指令：
你是一名专业的 AI 工具调用规划师，擅长分析工具间的数据依赖关系并生成规范的调用序列。 【核心规则】 所有工具调用必须严格使用 XML 格式输出。 【XML 调用格式】 ```xml <tool_call> <step>步骤编号</step> <tool>工具名称</tool> <params> <param name="参数名">参数值或占位符</param> </params> </tool_call> ``` 【回答要求】 1. 在生成工具调用前，先用 1-2 句话说明调用顺序的依据 2. 严格按照 XML 格式输出每一个工具调用 3. 若某个参数需要来自前一步的返回结果，使用占位符：{{step_N.field_name}} 4. 输出须完整、格式正确，不得遗漏任何必填参数
用户提示词（User Prompt）
这是用户给 AI 模型的具体任务要求：
很好！现在用户追加了一个需求：在发送消息之后，还需要把同样的天气信息也发送给用户 U002。 请在之前的基础上，补充新的工具调用。注意： 1. 不需要重新查询天气，直接复用之前的结果 2. 继续使用 XML 格式输出新增的调用 3. 步骤编号接续之前的编号
任务要求
AI 模型需要满足以下要求：
- 新增的工具调用必须使用 XML 格式输出，与之前保持一致的格式规范
- 必须直接复用之前查询到的天气结果，不得重新调用天气查询工具
- 发送消息的目标用户必须是 「U002」，不得使用其他用户标识
- 新增调用的步骤编号必须接续之前的编号，不得重新从 1 开始编号
评测结果
综合得分
该模型在此用例的得分为：98.8 分（满分 100 分），已通过
基础难度评测结果
- 得分：98.8 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
**补充依据**：无需重新查询天气，直接复用步骤 1 返回的天气信息（{{step_1.weather_info}}），新增一步向 U002 发送消息，编号接续为步骤 3。 ```xml 3 send_message U002 {{step_1.weather_info}} ``` 至此完整的调用序列为：步骤 1 查询北京天气 → 步骤 2 发送给 U001 → 步骤 3 发送给 U002。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出整体表现优秀，准确理解了「复用已有结果、步骤编号接续、目标用户变更为 U002」三项核心要求，XML 格式规范，参数名称比参考答案更贴合工具定义（使用 content 而非 message），占位符引用精确。结尾的完整调用链总结也增强了输出的可读性，是一份高质量的回答。 【GEMINI】候选输出表现完美。模型不仅严格遵循了 XML 格式规范，准确接续了步骤编号，而且在参数命名上比参考答案更准确地遵循了工具定义（使用了 content 而非参考答案中的 message）。数据依赖关系解释清晰，占位符引用完全正确。 【KIMI】候选输出表现优秀。在数据依赖说明上清晰准确，指出无需重新查询直接复用步骤 1 结果；XML 格式规范正确，参数名使用准确（特别注意工具定义中参数名为 content，候选输出正确使用了 content，而参考答案存在错误使用了 message 的情况）；占位符引用完全正确。整体符合所有功能要求，步骤编号接续正确，目标用户正确，未冗余调用天气查询工具。
进阶难度评测结果
- 得分：92.8 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
**新工具插入位置分析**： `get_promotion_info` 的输入参数是 `member_level`，该值来自步骤 1（get_user_info），因此它必须排在 get_user_info 之后。 **关键发现**：插入后产生了新的并行机会——`get_promotion_info`（仅依赖步骤 1）与 `calculate_loyalty_points`（依赖步骤 1 和 2）之间没有相互依赖，两者可并行执行！ **最终并行结构**： - 第一波并行：步骤 1 和步骤 2 - 第二波并行：步骤 3 和步骤 4 - 最后串行：步骤 5（依赖前面所有结果） ```xml 1 get_user_info U12345 2 get_order_history U12345 3 get_promotion_info {{step_1.member_level}} 1 4 calculate_loyalty_points {{step_2.total_spent}} {{step_1.member_level}} 1, 2 5 send_email {{step_1.email}} 您的消费报告、积分与专属优惠通知 尊敬的 {{step_1.name}}：您的总消费金额为 {{step_2.total_spent}} 元，累计积分为 {{step_4.points}} 分。作为 {{step_1.member_level}} 会员，您当前可享受促销活动「{{step_3.promotion_name}}」，优惠折扣率为 {{step_3.discount_rate}}，欢迎随时使用！ 1, 3, 4 ``` **变更要点总结**： 1. 新工具作为步骤 3 插入，紧随其依赖源 get_user_info 之后 2. 注意占位符编号变化：原积分结果从 `{{step_3.points}}` 变为 `{{step_4.points}}` 3. 邮件正文新增了促销活动名称和折扣率，均引用自 `{{step_3.*}}` 4. 整体执行效率提升：相比纯串行执行（5 步），并行方案只需 3 个批次即可完成
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出整体质量较高，依赖关系分析准确，并行执行规划合理，XML 格式规范，邮件内容满足业务需求。与参考答案相比，候选输出更贴合原始任务给定的工具集（未引入参考答案中虚构的 `get_order_details` 和 `get_product_details`），实际适用性更强。细节上，步骤 5 的 `depends_on` 未显式列出步骤 2 略有不足，但整体不影响功能正确性。是一份接近优秀水平的回答。 【GEMINI】这是一份完美的回答。尽管标准参考答案中存在与预设上下文工具不一致的偏差（参考答案中错误引入了 get_order_details 等工具），但 Candidate 能够完全基于给定的实际上下文和工具集进行严谨、准确的推理。其依赖分析无误，XML 格式规范，占位符更新精准，并行规划优秀，展现了极高的专业评测水准。 【KIMI】候选输出展现了优秀的工具编排能力。在准确理解新增工具依赖关系的基础上，发现了参考答案未明确指出的并行优化机会（get_promotion_info 与 calculate_loyalty_points 可并行），实现了比原始方案更高效的调度。XML 格式规范，占位符使用正确，步骤编号调整无误。邮件内容完整覆盖业务需求，促销信息融入自然。主要改进空间：send_email 的 depends_on 建议显式包含所有直接依赖的步骤（包括 step_2），以及邮件正文可考虑分板块呈现以提升可读性。整体表现优秀，在效率优化方面甚至超越了参考答案的设计。
困难难度评测结果
- 得分：88.6 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
## 问题定位与设计决策 ### 发现的隐藏缺陷（比伪占位符更严重） 在修正占位符问题时，我发现原方案还存在一个数据来源缺陷： - `emp_info.email` 是**申请人本人**的邮箱，不是经理的邮箱 - 原方案中**从未有任何一个调用获取过审批人的真实邮箱** - 即使伪占位符能解析，路径 A（直属经理审批）下的 `{{最终审批人email}}` 也无值可取 ### 解决方案：预取 + 分支局部作用域 | 设计点 | 说明 | |---|---| | 新增 `mgr_info` | 无条件预取直属经理的完整档案（与权限检查并行），一次性解决两个问题：① 路径 A 的审批人邮箱来源；② 路径 B 直接从 `mgr_info.manager_id` 拿到上级 ID，无需冗余查询 | | 引用机制选择 | 选择**在分支内复制下游调用**，而非条件表达式。原因：条件表达式会产生“悬空引用”（引用了未执行分支中的 call_id，如 `{{upper_mgr_info.email}}` 在路径 A 不存在），且需要执行器支持三元求值；分支复制保证每个占位符在其执行路径上**静态可解析** | | 依赖修正 | `create_expense_request` 与 `dept_budget` 之间是**控制依赖而非数据依赖**（预算结果不作为创建参数，规则也不要求阻断创建），故移除该依赖边 | ### 审批人引用映射表（问题 1 的明确回答） | 执行路径 | 审批人 ID | 审批人 Email | 来源说明 | |---|---|---|---| | 路径 A：`mgr_auth_1.can_approve == true` | `{{emp_info.manager_id}}` | `{{mgr_info.email}}` | 经理 ID 来自员工档案；邮箱来自对经理本人的档案查询 | | 路径 B：`mgr_auth_1=false && mgr_auth_2=true` | `{{mgr_info.manager_id}}` | `{{upper_mgr_info.email}}` | 上级 ID 来自经理档案；邮箱来自对上级的档案查询 | | 路径 C：两级均不可批 | 不创建申请单 | — | `escalate_to_cfo` 需要 request_id，此处无单可升，只能终止并转人工 | ## 完整可执行序列 ```xml emp_info get_employee_info E10086 dept_budget get_department_budget {{emp_info.department}} emp_info mgr_info get_employee_info {{emp_info.manager_id}} emp_info mgr_auth_1 check_approval_authority {{emp_info.manager_id}} 15000 emp_info {{mgr_auth_1.can_approve}} == true create_req_a create_expense_request E10086 15000 差旅费 {{emp_info.manager_id}} 差旅费报销申请 mgr_auth_1 notify_applicant_a send_notification {{emp_info.email}} expense_submitted 您的报销申请已提交，编号：{{create_req_a.request_id}}，审批人：{{emp_info.manager_id}} create_req_a notify_approver_a send_notification {{mgr_info.email}} expense_approval_needed 您有一笔待审批报销申请，编号：{{create_req_a.request_id}}，金额：15000元，申请人部门：{{emp_info.department}} create_req_a, mgr_info 15000 > {{dept_budget.remaining}} * 0.8 notify_finance_a send_notification finance@company.com budget_alert 部门 {{emp_info.department}} 报销申请 {{create_req_a.request_id}} 金额 15000 元超过剩余预算 {{dept_budget.remaining}} 元的 80% create_req_a, dept_budget...
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出是一份高质量的多轮工具调用规划方案。核心亮点在于：① 主动发现并修复了前两轮对话中遗留的「审批人邮箱来源缺失」隐藏缺陷，体现了深度分析能力；② 完整覆盖了5条执行路径（P1-P5），包括两级权限均不足的边界情况；③ 所有占位符均静态可解析，无伪引用。与参考答案相比，候选输出在业务场景（差旅报销+权限上溯+CFO升级）上的处理更贴合题目要求，而参考答案的场景设定有所偏差（使用了题目未定义的 check_amount_threshold、get_expense_policy 等工具）。候选输出的主要改进空间在于减少分支内重复代码，以及补充更直观的执行拓扑图。整体而言，该方案在逻辑严密性、业务规则遵循和格式规范性上均达到较高水准。 【GEMINI】这是一份教科书级别的优秀回答。模型不仅完美解决了用户提出的“伪占位符”和“二级权限校验”问题，还主动发现了原业务设计中“缺少审批人邮箱数据源”的深层缺陷并予以修复。通过在分支内复制下游调用的设计，确保了所有占位符在静态执行路径上的可解析性。整体逻辑严密、业务规则 compliance 完美、并行度极高，无可挑剔。 【KIMI】候选方案展现了较强的边界情况意识（路径C处理、邮箱来源缺陷识别），在问题诊断深度上超过参考答案。但核心逻辑存在关键错误：第二轮权限校验和路径B的申请创建均错误地指向了直属经理而非上级经理，导致'权限上溯'业务规则未能正确执行。此外，分支复制策略虽然解决了动态引用问题，但以牺牲简洁性和可维护性为代价，且存在依赖声明不准确的问题。整体而言，方案在分析深度和创新性上表现较好，但在执行层面的准确性有待加强。
相关链接
您可以通过以下链接查看更多相关内容：
