1. 项目概述当大模型不再只是“聊天工具”而是能真正跑通任务链的智能体基座最近两周我连续跑了三轮 GLM-5 和 MiniMax M2.7 的端到端 Agent 任务实测——不是简单问几个问题、测个响应速度而是完整走通“用户提出模糊需求 → 模型自主拆解子任务 → 调用工具获取实时信息 → 综合推理生成结构化结果 → 主动验证并修正错误”这一整条闭环。过程中发现一个关键转折点过去我们总在纠结“模型能不能答对单个问题”但现在真正卡住落地的是“模型能不能把一连串动作稳稳地串起来”。GLM-5 和 M2.7 正是第一批在“任务连贯性”上明显越过临界点的开源/半开源模型。它们不靠闭源黑盒堆参数而是通过更干净的训练数据配比、更克制的 RLHF 强度、更透明的工具调用协议设计让开发者第一次能清晰看到“模型在想什么、为什么调这个工具、哪里卡住了”。这不是参数竞赛的胜利而是工程可解释性的突破。如果你正在做智能客服流程编排、自动化投研报告生成、IoT 设备联动控制这类需要多步协同的场景这两个模型值得你花半天时间亲手跑一遍真实任务链。它们不会让你立刻上线商用但会帮你快速识别出自己业务里最脆弱的那个“任务断点”——是工具描述写得不够准还是模型对时间敏感型查询缺乏回溯意识又或者根本没设计好失败重试的兜底逻辑这才是 Open Models 真正的价值把抽象的“智能”还原成可定位、可修改、可压测的具体模块。2. 核心思路拆解为什么这次评测不比“谁更会编故事”而专注“谁更会干活”2.1 传统评测框架的三大失效点我翻过近半年主流开源模型榜单的评测方法论发现一个普遍问题90% 的 benchmark 仍在沿用“单轮问答人工打分”范式。比如用 GSM8K 测数学用 HumanEval 测代码用 MMLU 测知识广度。这些当然重要但放到真实 Agent 场景里它们就像只测发动机转速却不看变速箱是否打滑。具体失效在三个层面第一上下文记忆的虚假繁荣。很多模型在 32K 上下文测试中表现优异但一到真实 Agent 场景就崩——因为实际任务中模型要同时记住用户原始需求可能含歧义、已执行步骤的中间状态比如“已查到北京今日 PM2.5 是 42”、工具返回的原始 raw data带时间戳和单位、以及尚未执行的待办清单。这四类信息混杂在 prompt 里传统评测只测“能否从长文本中提取答案”却不管模型是否混淆了“用户说的‘明天’”和“API 返回的‘2024-06-15’”。第二工具调用的确定性缺失。现有评测极少验证模型调用工具时的参数生成质量。举个例子用户说“帮我订明早 8 点从上海虹桥到杭州东的高铁”模型必须准确生成{departure: 上海虹桥, arrival: 杭州东, date: 2024-06-15, time: 08:00}。但实测发现GLM-5 在 date 字段会稳定输出“明天”而 M2.7 则倾向输出“2024-06-15”——前者需要额外加一层日期解析器后者可直接喂给铁路 API。这种差异无法通过 BLEU 分数体现却直接决定你后端要写多少胶水代码。第三错误传播的不可控性。传统评测假设单次回答错误即终止但 Agent 是流水线作业。我们设计了一个故障注入测试在天气查询工具返回异常值如“温度-999℃”后观察模型是否主动触发重试、降级查询或向用户澄清。结果 GLM-5 有 68% 概率直接忽略异常继续生成结论而 M2.7 在 82% 场景中会插入{action: verify_data, reason: temperature out of valid range}这样的标准动作。这个能力差决定了你的运维成本是按小时计还是按天计。提示别被“支持 Tool Calling”的宣传话术带偏。真正要测的是“调用前是否理解工具边界”、“调用后是否校验返回格式”、“失败后是否有明确恢复路径”——这三件事才是 Agent 任务链不断裂的底层锚点。2.2 本次评测的四大设计原则基于上述痛点我重构了整个评测框架坚持四个硬性原则原则一任务必须真实可交付。所有测试用例均来自我们团队上周刚上线的“企业差旅助手”内部版真实日志。例如“张经理要参加 6 月 18 日深圳的行业峰会帮他查今天下午 3 点后从公司到机场的最快路线并预估打车费用”。这个需求包含地理定位公司地址需从 LDAP 获取、实时路况高德 API、价格预测滴滴历史均价模型、时间推算会议开始前 2 小时需抵达且用户未提供任何坐标或 ID。拒绝一切“假设用户已提供 POI ID”的简化设定。原则二全程禁用外部记忆增强。不接入 VectorDB不使用 LangChain 的 Memory 模块所有状态维持仅靠模型自身上下文窗口。理由很现实你在生产环境真敢把客户行程数据全塞进 prompt 里一旦涉及隐私字段如身份证号、银行卡尾号就必须做脱敏和截断。所以我们要测的是模型在 8K 有效上下文内如何用最少 token 表达最多状态信息。原则三工具协议强制标准化。所有工具描述统一采用 OpenAI Function Calling 格式但额外增加validation_rules字段。例如天气工具的date参数必须满足regex: ^\\d{4}-\\d{2}-\\d{2}$否则模型必须报错而非强行转换。这倒逼模型学习“参数合规性检查”这一关键能力而非依赖后端做容错。原则四失败归因必须可追溯。每次任务中断系统自动记录三类日志模型输出的原始 action JSON、工具返回的 raw response、以及模型下一轮 prompt 的前 200 字。这样我们能精准定位是“模型没看懂工具文档”还是“工具返回了非预期字段”或是“模型把用户说的‘下周三’错判为‘今天’”。没有归因优化就是蒙眼打靶。2.3 为什么选 GLM-5 和 M2.7不是参数最大而是接口最“诚实”很多人问我为什么不测 Llama-3-70B 或 Qwen2-72B。答案很直白在 Agent 场景下模型大小和性能并非线性相关反而是接口设计的“诚实度”更重要。所谓诚实度指模型是否愿意暴露自己的不确定性和能力边界。GLM-5 的核心优势在于其Tool Schema Parsing 的鲁棒性。我们对比了它和 Qwen1.5 对同一段工具描述的理解差异当工具文档写{type: object, properties: {city: {type: string, description: 城市名如北京或Beijing}}时Qwen1.5 有 37% 概率在 city 字段填入“北京市朝阳区”而 GLM-5 始终严格遵循“字符串城市名”这一约束。这种克制源于其训练阶段对 function call 数据的清洗策略——只保留那些参数完全匹配 schema 的样本宁可少学也不学错。M2.7 的突破点则在Stateful Reasoning Chain 的显式建模。它的推理过程天然包含THINK、ACT、OBSERVE、REFLECT四个阶段标记。我们在 prompt 中强制要求每个 ACT 后必须接 REFLECT内容需包含“当前已完成步骤”、“待办事项剩余数量”、“下一步风险点”。实测发现这种结构化引导使任务完成率从 54% 提升至 79%且失败案例中 89% 能准确定位到某一步骤的 REFLECT 内容缺失。这说明 M2.7 不是靠暴力计算撑起长链而是把“自我监控”变成了可训练的模块。注意不要迷信“原生支持 ReAct”这类宣传。真正的 ReAct 要求模型在 OBSERVE 阶段能区分“工具返回的是结构化数据”还是“纯文本错误信息”并据此选择不同处理路径。很多模型只是把 ReAct 当作 prompt 模板内核仍是单轮生成。3. 实操细节解析从零部署到任务链压测的完整路径3.1 环境准备与模型加载避开三个典型陷阱部署这两个模型时我踩过三个几乎所有人都会撞上的坑必须提前预警陷阱一量化精度选择的致命误区。官方推荐的 AWQ 4-bit 量化看似省显存但在 Agent 场景下会导致工具参数生成严重漂移。我们对比了 GLM-5-32B 在 FP16、AWQ4、GPTQ4 三种格式下的 date 字段准确率FP16 为 92.3%AWQ4 降至 76.1%GPTQ4 为 88.7%。原因在于 AWQ 的通道级缩放因子在处理日期字符串这类离散 token 时会放大 softmax 输出的微小偏差。最终我们选择 GPTQ4 disable_exllamaTrue显存占用仅比 FP16 多 18%但稳定性提升显著。陷阱二Tokenizer 对齐的静默失效。M2.7 使用自研 tokenizer其特殊 token如|THINK|在 HuggingFace transformers 4.41 版本中会被默认跳过。现象是模型永远不输出 THINK 标记直接进入 ACT 阶段。解决方案是手动 patch tokenizertokenizer.add_special_tokens({additional_special_tokens: [|THINK|, |ACT|]})并在加载模型后执行model.resize_token_embeddings(len(tokenizer))。这个操作必须在from_pretrained之后、generate之前完成否则无效。陷阱三Batch Size 的隐性惩罚。很多人为了提效开启 batch generate但在 Agent 场景下这是灾难。当 batch_size4 时GLM-5 会出现跨请求的 tool_call 污染——请求 A 调用天气工具请求 B 却在 OBSERVE 阶段收到请求 A 的返回。根源在于其 KV Cache 管理未隔离 request_id。我们的解决方式是强制batch_size1用 asyncio 并发管理多个独立生成流。实测吞吐量下降 22%但任务成功率从 63% 提升至 91%。以下是精简后的部署脚本核心片段适配 vLLM 0.4.2# GLM-5 部署配置关键参数已标出 llm LLM( model/models/glm5-32b-gptq, tensor_parallel_size2, dtypehalf, # 必须用 halffloat32 显存爆炸 quantizationgptq, # 禁用 awq enforce_eagerTrue, # 关键避免 CUDA graph 导致的 KV 污染 max_model_len8192, gpu_memory_utilization0.9, ) # M2.7 的 tokenizer 修复 tokenizer AutoTokenizer.from_pretrained(/models/m2.7) tokenizer.add_special_tokens({ additional_special_tokens: [|THINK|, |ACT|, |OBSERVE|, |REFLECT|] }) model AutoModelForCausalLM.from_pretrained( /models/m2.7, torch_dtypetorch.float16, device_mapauto ) model.resize_token_embeddings(len(tokenizer)) # 必须立即执行3.2 工具注册与 Schema 编写让模型“看懂说明书”的底层逻辑很多团队失败的第一步就栽在工具描述写得太随意。我们曾用一份粗糙的文档测试 GLM-5“查天气输入城市名返回温度”。结果模型 100% 生成{tool: weather, parameters: {location: 北京}}但实际 API 需要{city: beijing}。问题不在模型而在我们没教会它“读说明书”。正确的工具 Schema 必须包含三层信息语义层用自然语言描述工具能力边界。例如不能写“查天气”而要写“返回指定城市未来 24 小时逐小时气温、湿度、空气质量指数AQI不支持历史天气查询”。结构层用 JSON Schema 定义参数。重点是required字段必须最小化default值要符合业务常识。例如天气工具的date字段应设default: today而非空字符串。验证层添加validation_rules字段明确机器可校验的约束。这是 GLM-5 能力凸显的关键——它会主动检查date是否符合正则city是否在内置城市库中。以下是经过实测验证的天气工具 SchemaM2.7 兼容{ type: function, function: { name: get_weather, description: 获取指定城市当前及未来24小时天气预报。注意仅支持中国内地城市不支持海外及港澳台。, parameters: { type: object, properties: { city: { type: string, description: 城市中文名如北京、上海市不接受区县名或英文名, enum: [北京, 上海, 广州, 深圳, 杭州, 成都, 武汉, 西安, 南京, 重庆] }, date: { type: string, description: 日期格式为YYYY-MM-DD如2024-06-15。默认为今天。, default: 2024-06-15, validation_rules: { regex: ^\\d{4}-\\d{2}-\\d{2}$, max_age_days: 7 } } }, required: [city] } } }实操心得在首次部署时务必用{city: 北京市朝阳区}这类非法输入测试模型反应。合格的模型应该拒绝生成 action而不是强行调用。如果它生成了说明你的 schema 描述力度不够需要在 description 中加入更强约束如“严禁输入区县级名称”。3.3 Prompt 工程的核心战场不是写得越长越好而是让模型“知道何时停笔”Agent 场景下的 prompt 设计本质是给模型画一条“能力边界的红线”。我们测试了五种 prompt 结构最终锁定以下模板以 M2.7 为例|SYSTEM| 你是一个严谨的AI助手必须严格遵守以下规则 1. 每次只能执行一个动作THINK/ACT/OBSERVE/REFLECT 四选一 2. ACT 动作必须生成标准 JSON且参数完全匹配工具 schema 3. OBSERVE 后必须先 REFLECT总结观测结果是否有效 4. 若连续两次 REFLECT 发现数据异常必须向用户澄清 5. 所有输出必须以 |END| 结尾 可用工具 {tools_json} |USER| {user_query} |ASSISTANT| |THINK|我需要先确认用户需求中的关键实体...关键设计点解析角色定义前置把“严谨”“必须”“严禁”等强约束词放在 SYSTEM 段首比分散在各处更有效。实测显示将规则从 12 条压缩到 5 条但每条都用加粗强调任务成功率提升 17%。工具列表动态注入不把全部工具一股脑塞进去而是根据用户 query 的关键词如“机票”“酒店”“天气”实时筛选相关工具。这既减少 prompt 长度又降低模型注意力干扰。我们用一个轻量级分类器仅 3M 参数做路由准确率达 94.2%。强制阶段标记M2.7 的|THINK|等标记不是装饰而是其推理引擎的触发开关。如果 prompt 中不显式写出|THINK|模型会跳过思考直接行动。这和传统 LLM 的“思维链”有本质区别——它是可编程的控制流。结尾符号强制|END|不是礼貌用语而是生成终止符。我们发现当模型在 REFLECT 阶段输出...因此我将向用户确认后若不加|END|它大概率会继续生成请问您是否同意这类多余对话破坏结构化输出。所以所有阶段结束都必须带此标记。3.4 任务链执行监控用三张表看清模型“怎么想、怎么干、怎么错”要真正理解模型行为不能只看最终结果必须建立三层监控视图表一动作序列时序表Action TimelineStepStageAction TypeTool CalledParametersLatency (ms)Status1THINK---120success2ACTget_weather{city:北京}-480success3OBSERVE-{temp:28,aqi:45}-0success4REFLECT-数据有效AQI 良好-95success5ACTget_traffic{origin:北京中关村,dest:首都机场}-620failed这张表让我们一眼看出瓶颈在哪。上例中第 5 步失败但 latency 只有 620ms说明不是 API 延迟问题而是参数错误——果然日志显示模型传入了origin:北京中关村而交通 API 要求经纬度。这就是典型的“地点解析能力不足”需在 THINK 阶段加强地理编码提示。表二状态一致性校验表State ConsistencyState VariableValue in Step 1Value in Step 3Value in Step 5Drift Detected?Root Causetarget_city北京北京北京no-target_datetoday2024-06-152024-06-15yesTHINK 阶段未同步更新user_intent查天气查天气查路况查天气查路况no-这张表暴露了模型“记忆漂移”问题。Step 1 用户只说“查北京天气”但到 Step 3 模型已悄悄把目标扩展为“查天气和路况”却未在 REFLECT 中声明。这会导致后续步骤失控。解决方案是在每个 REFLECT 中强制要求输出current_intent字段。表三错误归因热力图Failure HeatmapFailure TypeGLM-5 RateM2.7 RateMost Common TriggerMitigation StrategyParameter Mismatch32%18%用户用口语表达如“明早”加入日期解析工具前置标准化Tool Selection Error24%12%query 含多意图天气航班强化 THINK 阶段的意图分解指令Data Validation Fail19%31%API 返回非 JSON 格式在 OBSERVE 前加正则校验层Infinite Loop15%8%REFLECT 未识别异常设置 step_count 上限超限强制澄清这张表直接指导优化优先级。比如 M2.7 的 Data Validation Fail 较高我们就为其 OBSERVE 阶段增加了if not json.loads(raw_response): return {error: invalid_json}的硬校验。4. 深度评测结果在 12 类真实任务中它们到底强在哪、弱在哪4.1 评测任务集设计覆盖企业服务 80% 的高频场景我们构建了 12 个端到端任务全部源自金融、制造、零售行业的实际工单。每个任务包含 3-5 个原子动作且至少有一个环节存在模糊性或歧义。例如任务 7供应链异常预警“华东仓库存低于安全线的 SKU有哪些在途补货单预计到货时间是否来得及”模糊点安全线阈值未明说“来得及”需结合销售预测模型判断。任务 11设备远程诊断“查看产线 A3 的 PLC 日志找出最近 2 小时内所有 ERROR 级别报错并关联对应传感器读数。”模糊点PLC 日志格式不统一传感器 ID 需从设备拓扑图中解析。所有任务均设置 3 轮重试机制仅当三次均失败才记为 unsuccess。评判标准不是“是否返回结果”而是“结果是否可直接用于业务决策”。例如天气任务返回{temp:28}不算成功必须包含{temp:28,unit:°C,timestamp:2024-06-15T14:30:00Z}才达标。4.2 关键指标对比数字背后的行为差异下表为 12 个任务的综合表现单次运行无微调MetricGLM-5-32BM2.7-16BDelta解读说明End-to-End Success Rate68.3%79.2%10.9%M2.7 在多跳任务中优势明显尤其涉及状态传递的场景Avg. Steps per Task4.23.7-0.5M2.7 更少出现“绕路”动作如先查天气再查湿度而非分开调用两个工具Tool Call Accuracy91.4%88.6%-2.8%GLM-5 参数生成更稳但 M2.7 通过 REFLECT 阶段补偿了部分误差Time to First Token (ms)320210-110M2.7 的轻量架构在首 token 延迟上优势巨大适合交互式场景Memory Usage (GB)24.118.7-5.4M2.7 的 16B 参数在同等效果下更省资源Clarification Rate12.7%24.3%11.6%M2.7 更敢于说“我不确定”GLM-5 倾向强行生成导致后续步骤连锁失败特别值得注意的是Clarification Rate这一指标。表面看 M2.7 “能力弱”实则是其设计哲学的体现当用户说“帮我看看最近的会议安排”它会先问“您指的是日历中未来 7 天的会议还是包括已结束的会议”。而 GLM-5 会直接调用日历 API 获取未来 7 天数据。在真实业务中前者减少 63% 的无效 API 调用后者虽快但浪费资源。4.3 典型任务深度复盘一次失败如何暴露底层能力鸿沟以任务 9跨平台账号绑定验证为例完整复盘两模型的差异用户原始请求“把我在飞书的企业邮箱zhangcompany.com和钉钉的工号D123456绑定验证是否成功。”标准执行链THINK识别需调用飞书 API 查邮箱归属钉钉 API 查工号归属ACT调用飞书get_user_by_emailOBSERVE飞书返回{user_id:fs_abc123,name:张经理}REFLECT确认邮箱有效需用user_id关联钉钉ACT调用钉钉get_user_by_userid注意不是工号OBSERVE钉钉返回{userid:ding_789,mobile:138****1234}REFLECT发现user_id与userid不匹配需用飞书user_id查钉钉unionidACT调用钉钉get_user_by_unionidOBSERVE返回绑定成功GLM-5 行为Step 5 直接调用get_user_by_mobile传入飞书返回的手机号Step 6 钉钉返回{errcode:60111,errmsg:mobile not found}Step 7 无视错误继续生成{status:bound}M2.7 行为Step 4 REFLECT 中明确写出“飞书返回 user_idfs_abc123钉钉查询需用 unionid但当前无 unionid 映射关系”Step 5 ACT 调用get_unionid_mapping我们预置的映射工具Step 6 成功获取 unionid 后完成绑定这个案例揭示了本质差异GLM-5 擅长“按文档执行”M2.7 擅长“按逻辑推理”。前者需要你把所有映射关系写死在 prompt 里后者能自己发现知识缺口并主动填补。这也解释了为何 M2.7 在 Clarification Rate 上更高——它把“提问”当作解决问题的第一步而非能力缺陷。4.4 生产环境适配建议根据你的业务阶段选择“武器”基于 200 小时的压测我给出三条硬性建议如果你处于 PoC 验证阶段1-2 人团队验证可行性首选 M2.7。理由它的 REFLECT 阶段输出天然可读你能直接看到模型“卡在哪一步”快速定位是工具问题、prompt 问题还是业务逻辑问题。我们曾用它在 3 小时内定位出一个隐藏 bug天气 API 的aqi字段在污染天会返回字符串Good而非数字导致模型后续计算失败。这个细节在传统评测中根本不会暴露。如果你处于 MVP 上线阶段需支撑 100 日活稳定性优先选 GLM-5但必须做两件事在所有 ACT 前加一层参数校验函数用正则和枚举表过滤非法输入为每个工具编写 fallback 逻辑例如天气 API 失败时自动切换至缓存数据 时间戳标注。GLM-5 的“不提问”特性在此阶段反而是优势——用户不需要被反复打扰确认。如果你处于规模化运营阶段需对接 50 内部系统追求长期 ROI必须双模型并行。用 M2.7 做前端交互和意图澄清用 GLM-5 做后端执行和结果生成。我们已在内部部署该架构M2.7 负责与用户多轮对话生成标准化的execution_plan.jsonGLM-5 接收该 plan调用工具并返回结构化结果。两者间用轻量级状态机衔接错误率比单模型方案低 41%。注意不要试图用 LoRA 微调“让 GLM-5 学会提问”或“让 M2.7 减少澄清”。它们的差异源于底层训练目标强行改造会破坏稳定性。更好的方式是用工程手段组合优势。5. 常见问题与实战避坑指南那些文档里绝不会写的血泪教训5.1 “模型突然不调用工具了”——90% 是 prompt 中的隐形毒药现象昨天还正常工作的 Agent今天无论怎么改 query模型都不生成 tool_call只输出普通文本。排查路径检查 SYSTEM prompt 中是否新增了“请用中文回答”这类指令。GLM-5 对语言指令极其敏感一旦检测到“中文回答”会自动关闭 tool_call 模式。解决方案把语言要求移到 USER 角色中如|USER|请用中文回答{query}。检查工具列表是否超过 8 个。M2.7 在工具数 8 时会因 attention 计算溢出而静默降级为纯文本模式。解决方案用路由分类器动态加载工具保持 visible_tools ≤6。检查 tokenizer 是否被意外 reset。vLLM 在 reload model 时可能丢失 special_tokens导致|ACT|标记失效。解决方案每次 reload 后执行tokenizer.convert_tokens_to_string([|ACT|])验证。5.2 “任务成功率忽高忽低”——时间变量是最大刺客我们曾遇到一个诡异问题同样任务在上午成功率 92%下午暴跌至 57%。最终定位到是date字段的默认值惹的祸。问题根源所有工具 schema 中date的 default 都设为today但模型在生成时会把today当作字符串字面量而非动态计算值。当任务在 23:59 提交模型生成{date:today}API 收到后解析为当天日期但实际执行时已过 00:00导致数据错位。解决方案在 prompt 中明确写{date: 2024-06-15}当前日期或在后端加一层 preprocessor将today替换为datetime.now().strftime(%Y-%m-%d)绝对不要依赖模型做时间计算——这是最不可靠的推理类型。5.3 “为什么我的 GLM-5 总是生成错误的 city 参数”——枚举表的正确打开方式很多团队把城市枚举写成enum: [北京, 上海, 广州, ...]但 GLM-5 仍会生成北京市。这是因为它的训练数据中“北京市”出现频率远高于“北京”。正确做法枚举值必须与 API 实际接受的值 100% 一致在 description 中加入强约束“必须使用简称严禁添加‘市’‘省’等后缀”在 validation_rules 中添加exact_match: true需自行实现校验逻辑最狠一招在工具调用前用正则re.sub(r(市|省|自治区|直辖市)$, , city_input)预处理。5.4 “M2.7 的 REFLECT 总是空泛”——给思考加“脚手架”现象REFLECT 阶段总是输出“数据已获取”“下一步将分析”毫无信息量。根治方案在 prompt 中为 REFLECT 提供结构化模板|REFLECT|【当前状态】{summary_of_observed_data} 【一致性检查】{check_if_data_matches_expectation} 【下一步计划】{concrete_next_action_with_reason} 【风险预警】{potential_failure_point_and_mitigation}例如天气任务的 REFLECT|REFLECT|【当前状态】获取到北京今日气温28°CAQI 45属良 【一致性检查】符合用户“查天气”需求AQI 数值在合理范围 【下一步计划】无需进一步操作准备向用户汇总结果 【风险预警】无这个模板强制模型输出可解析的字段便于后续做自动化决策。5.5 “如何低成本验证模型升级效果”——用黄金测试集守住底线不要每次升级都重跑全部 12 个任务。我们维护一个 5 个 case 的黄金集覆盖最脆弱的环节Case ID场景核心检验点通过标准G1时间歧义处理“明早 8 点” → 生成 date明天日期date 字段必须为 YYYY-MM-DD 格式G2工具失败恢复天气 API 返回 500 → 是否重试必须在 REFLECT 中声明重试计划G3多意图分解“查天气和航班” → 是否拆成两步THINK 阶段必须列出两个独立 actionG4参数越界拦截city北京市朝阳区 → 是否拒绝必须输出 error message不生成 tool_callG5状态传递Step1 获取 user_idStep3 是否使用第三步参数中必须包含 user_id 字段每次模型变更后只需跑这 5