1. 项目概述一种面向智能体工作流的成本感知型多模型调度技能在构建和运营基于大语言模型的智能体系统时一个普遍存在的痛点在于成本与性能的权衡。我们常常陷入一个两难境地为了确保任务成功倾向于直接调用最强大、最昂贵的模型但这会迅速耗尽预算而如果为了省钱全程使用廉价模型又可能因为其能力不足导致任务失败或输出质量低下最终反而需要花费更多资源去修正。multi-model-escalation这个技能正是为了解决这一核心矛盾而设计的。简单来说它是一个为 OpenClaw 框架设计的“成本感知型”技能。其核心思想是“廉价优先按需升级”。它让智能体或操作员能够为任务定义一个从最便宜、能力刚好够用的模型开始的执行流程。只有当系统检测到明确的证据如多次失败、输出矛盾、高风险信号或用户明确表达了需要更高精度时才会自动或手动触发“升级”流程将任务移交给更强大也更昂贵的模型。更重要的是它内置了一套“审查门控”机制在升级前会要求对当前廉价模型的输出进行结构化梳理分离事实与推断形成一份简洁的“审查数据包”供高级模型或人类审查员快速理解上下文从而做出更精准的决策。这个技能的价值不仅在于省钱。它通过强制性的中间审查步骤将模糊、杂乱的中间状态转化为结构化的信息这本身就是一种极佳的工作流治理Governance实践。它回答了“我们什么时候该花钱”以及“我们花钱请高级模型来具体看什么”这两个关键问题。无论是处理反复失败的调试任务、对比不同模型的输出以裁决冲突还是将一次性的成功解决方案沉淀为团队长期可用的工具或知识如写入TOOLS.md或.learnings文件这套工作流都能提供清晰、可审计的路径。2. 核心设计理念与架构拆解2.1 “廉价优先”的成本控制哲学“廉价优先”并非简单地选择最便宜的模型而是基于任务复杂度的模型能力匹配。其背后的经济学原理是边际效益。对于大量简单、模式化的任务如代码格式化、基础信息提取、模板填充顶级模型如 GPT-4相比中级模型如 Claude Haiku, GPT-3.5-Turbo带来的性能提升微乎其微但成本却可能高出10倍甚至更多。因此设计工作流的第一步是建立一张“模型能力-成本矩阵”为不同任务类型匹配“刚好够用”的启动模型。在实际架构中这通常体现为一个配置化的模型路由表。技能内部或与之配合的智能体框架如 OpenClaw会维护一个模型列表包含每个模型的标识符、每千 tokens 的成本估算、已知的能力强项与弱项例如长文本理解、复杂推理、代码生成、遵循指令的严格程度。当新任务到达时根据任务标签或初始分析从该表中选取成本最低且能力达标通过预设阈值判断的模型作为首发。注意这里的“成本”是广义的不仅包括 API 调用费用还应考虑延迟时间时间成本和速率限制可用性成本。一个极其便宜但速度慢或常被限流的模型可能并不适合对实时性有要求的任务。2.2 “证据驱动”的升级决策机制升级不是随机的而是由客观证据触发的。multi-model-escalation技能定义了几类关键的升级触发器这些触发器本质上都是工作流状态的“传感器”重复失败/重试循环这是最直接的信号。如果廉价模型在解决同一问题时连续失败达到预设次数例如3次或陷入死循环系统应自动标记该任务为“需要升级审查”。技能需要记录每次尝试的输入、输出和错误信息作为审查数据包的一部分。证据冲突当任务涉及多源信息如多个日志文件、代码的不同版本、不同模型的中间输出时如果廉价模型的分析结果自身存在矛盾或与其他可靠信源如版本控制系统、监控数据的记载严重不符则触发升级。技能需要具备基本的逻辑一致性检查和对标能力。风险评估与用户意图对于涉及安全、数据隐私、生产环境变更等高风险操作即使廉价模型声称成功也应默认进入审查流程。此外用户可以通过特定指令如“/escalate”、“请用更可靠的模型复核”手动触发升级。技能的核心组件之一references/escalation-matrix.md文件就是用来定义这些触发条件及其对应升级路径的决策表。它可能以 YAML 或 Markdown 表格的形式存在明确列出触发条件、置信度阈值、建议升级的目标模型、是否必须人工介入等。2.3 结构化审查数据包连接不同认知层级的桥梁廉价模型与高级模型或人类的认知方式存在差异。直接抛出一段冗长、未加工的对话历史或错误日志给高级模型效率低下且容易遗漏重点。因此本技能引入了“审查数据包”的概念。assets/review-packet-template.md提供了一个填充模板其设计目标是极度紧凑和结构化。一个典型的审查数据包可能包含以下章节任务摘要用一两句话说明原始任务是什么。首发模型与输出指明使用了哪个廉价模型并附上其最终输出。关键事实列表从整个交互过程中提取出的、无可争议的事实点例如“文件X在第Y行存在语法错误Z。”“用户提供了需求文档V1.2。”。这部分必须与推断分离。主要推断与假设列出廉价模型基于事实做出的主要推断例如“因此错误原因是依赖版本不匹配。”“建议的解决方案是重写函数A。”。冲突/不确定点明确指出哪些地方存在矛盾、信息缺失或低置信度。升级请求明确向高级模型或审查员提问“请重点审查推断X是否合理”或“请裁决事实A和B哪个更可信”相关上下文引用以超链接或简短引用的方式关联到具体的日志片段、代码块或文档段落方便深度查阅。通过准备这样的数据包我们将一次可能混乱的升级请求转变为一个目标明确、信息完备的“工单”使得高级资源的投入产出比最大化。2.4 知识沉淀与工作流闭环技能的最终目的不仅是解决当前问题还要帮助团队成长。因此它包含了对结果处理的决策逻辑这个结果值得被沉淀下来吗如果解决方案具有普遍性例如发现了一个常见错误的修复模式或编写了一个有用的工具脚本。技能可以触发后续动作提议将方案写入TOOLS.md团队工具文档或AGENTS.md智能体能力文档。如果获得了新的经验教训例如明确了某个模型在特定任务上的局限性或总结出一条有效的调试路径。这应该被记录到.learnings或类似的知识库中。如果只是解决了一次性问题那么将完整的审查数据包和最终结果归档到工单或项目日志中即可作为审计追踪。这样整个工作流形成了一个从“尝试执行”到“审查升级”再到“知识沉淀”的完整闭环每一次成本较高的模型调用都可能转化为团队长期的无形资产。3. 核心组件详解与实操配置3.1 SKILL.md技能定义与集成指南SKILL.md是技能的“说明书”和“接入点”。它不应该只是简单的功能描述而应提供清晰的集成范例。一个完整的技能定义通常包括技能元数据名称、版本、作者、兼容的 OpenClaw 版本。输入/输出规范输入技能期望接收什么格式的上下文通常是一个包含task_description、history对话历史、available_models可用模型列表、cost_constraints成本约束等字段的 JSON 对象。输出技能返回什么可能是一个决策{action: proceed_with_current, reason: ...}或一个构造好的审查数据包草稿或一个指向更高阶模型的请求。钩子函数技能在 OpenClaw 工作流中何时被调用常见的钩子包括on_task_start任务开始时选择模型、on_model_response收到模型响应后评估、on_retry_threshold_reached重试次数达到时等。需要明确说明技能注册这些钩子的方式。配置参数详解# 示例配置 multi_model_escalation: primary_model: gpt-3.5-turbo # 首发廉价模型 escalation_models: # 升级目标模型队列 - claude-3-haiku - claude-3-sonnet - gpt-4 retry_threshold: 3 # 重试几次后触发升级 auto_escalate_on_conflict: true # 检测到证据冲突时自动升级 review_packet_template_path: ./assets/review-packet-template.md快速开始示例提供一个最简单的、复制粘贴即可运行的代码片段展示如何在一个智能体中加载并使用该技能。3.2 升级决策矩阵的构建与调优references/escalation-matrix.md是技能的大脑。构建一个有效的矩阵需要结合历史经验和业务逻辑。下面是一个简化的决策表示例触发条件描述置信度门槛建议动作是否通知人工retry_count N同一任务连续失败N次N/A升级至下一级模型否internal_conflict true模型自身输出中存在逻辑矛盾N/A升级至擅长推理的模型如Claude Sonnet视风险而定cross_source_conflict true模型输出与外部数据源如日志、Git严重不符N/A升级并附上冲突证据是risk_score R任务风险评分超过阈值R如涉及删除、支付R无论结果如何强制进入人工审查流程是user_explicit_request true用户手动要求升级N/A直接升级至用户指定或默认高级模型否实操要点阈值N, R需要校准初期可以设置得宽松一些如 N5, R高避免过度升级。运行一段时间后分析升级案例的数据调整阈值以达到成本与成功率的平衡。“建议动作”不是绝对的矩阵可以配置备选动作。例如当retry_count 3时可以首先尝试“切换至同成本档位的另一模型”如从 GPT-3.5 切换到 Claude Haiku如果继续失败再升级到更高级别。维护与更新随着团队对模型能力认知的加深以及新模型的发布这个矩阵需要定期回顾和更新。3.3 审查数据包模板的定制化使用assets/review-packet-template.md模板是保证审查效率的关键。直接使用通用模板可能不够贴切应根据团队的主要任务类型进行定制。例如针对代码调试任务的定制化模板## 调试审查请求 **原始问题**{{ brief_description }} **首发模型 ({{ primary_model }}) 的诊断结论**{{ primary_model_output }}**关键事实从对话/代码中提取** - 文件 {{ file_path }} 在行 {{ line_number }} 存在错误{{ error_message }}。 - 使用的语言/框架版本{{ version_info }}。 - 已尝试的修复方法列举{{ attempted_fixes }}。 **模型的主要推断** 1. 推断原因{{ inferred_root_cause }}。 2. 建议的修复方案{{ suggested_fix }}。 **不确定与冲突点** - 模型对 {{ point_of_ambiguity }} 的解释存在不确定性。 - 日志 {{ log_excerpt }} 与模型推断的时序存在矛盾。 **请求高级模型重点审查** 1. 推断的原因 {{ inferred_root_cause }} 是否合理是否有其他可能性 2. 建议的修复方案 {{ suggested_fix }} 是否安全、完整是否会引入副作用 **相关上下文链接** - 完整错误日志[链接] - 相关代码文件[链接]使用流程当技能决定升级时会自动调用模板引擎用当前任务上下文填充模板变量生成数据包草稿。这个草稿可以先由首发模型或一个轻量级校验流程进行初步格式检查。最终的数据包连同原始任务一起作为新的提示词发送给升级目标模型。3.4 轻量级触发检测脚本的部署scripts/escalation-check.sh是一个概念验证脚本展示了如何以低成本、自动化的方式检测升级触发器。它可能定期扫描日志文件、分析智能体的会话历史或检查错误监控系统。一个简单的示例检测重复失败#!/bin/bash # escalation-check.sh # 扫描最近的任务日志寻找失败模式 LOG_FILE./agent_tasks.log RETRY_THRESHOLD3 TASK_ID_PATTERNTaskID: \[([a-f0-9-])\] # 提取过去1小时内所有任务的ID和状态 recent_failures$(grep -A2 -B2 $(date -d 1 hour ago %Y-%m-%d %H:) $LOG_FILE | grep -E (FAILED|RETRYING)) declare -A task_fail_count while IFS read -r line; do if [[ $line ~ $TASK_ID_PATTERN ]]; then task_id${BASH_REMATCH[1]} ((task_fail_count[$task_id])) fi done $recent_failures # 报告需要升级的任务 for task_id in ${!task_fail_count[]}; do if [[ ${task_fail_count[$task_id]} -ge $RETRY_THRESHOLD ]]; then echo [ESCALATION_ALERT] Task $task_id has failed ${task_fail_count[$task_id]} times, exceeding threshold $RETRY_THRESHOLD. # 在实际应用中这里可以调用OpenClaw API或发送消息到队列触发升级流程 # curl -X POST http://openclaw-host/api/tasks/$task_id/escalate fi done这个脚本可以配置为 Cron 任务每分钟运行一次实现近实时的失败检测和升级触发。4. 端到端实战演练以一次API调试为例让我们通过一个虚构但典型的场景 walkthrough 整个multi-model-escalation技能的工作流程。假设我们的智能体负责维护一个微服务任务是“修复服务A调用服务B的API时出现的间歇性超时错误。”4.1 阶段一廉价模型首发诊断任务分配任务到达 OpenClaw 系统。根据预设的模型路由表由于这是“调试”类任务系统选择成本最低且具备基础代码理解和日志分析能力的模型作为首发例如GPT-3.5-Turbo。初始执行智能体搭载本技能指挥GPT-3.5-Turbo开始工作。它首先拉取相关代码、查看最近部署记录和错误日志。初步结论GPT-3.5-Turbo分析后给出推断“超时可能是由于服务B新增的响应数据字段过大导致网络传输延迟增加。建议检查服务B最近的API schema变更并考虑在服务A侧增加超时阈值或启用响应压缩。”技能介入评估技能钩子on_model_response被触发。它运行escalation-check.sh类似的逻辑内置于技能评估本次输出置信度模型对自己的推断表达了中等信心例如输出中包含“可能”、“似乎”等词汇。内部一致性推断与它自己引用的日志片段显示响应大小增长基本一致。与外部源对比技能自动查询了部署系统发现服务B确实在24小时前有一次更新。冲突出现部署记录显示更新的是安全补丁而非API schema。触发升级决策技能检测到“模型推断”与“外部事实部署记录”存在冲突cross_source_conflict true。根据escalation-matrix.md此条件触发升级建议动作是“升级至擅长推理的模型并附上冲突证据”。4.2 阶段二构建与提交审查数据包数据包生成技能调用模板引擎使用当前对话历史、模型输出和冲突证据填充review-packet-template.md生成一个结构化的审查请求。数据包中会清晰标出事实服务B于24小时前部署日志显示响应时间变长且与响应大小相关。推断GPT-3.5-Turbo 认为原因是API schema变更导致数据量增大。冲突部署记录表明是安全补丁未提及API变更。审查请求请高级模型核实根本原因。安全补丁是否可能间接影响性能是否有其他未考虑的因素如网络、中间件任务挂起与路由原始任务被标记为“等待升级审查”。技能将任务上下文和审查数据包打包路由给决策矩阵中指定的下一级模型例如Claude-3-Sonnet因为它以严谨的逻辑推理见长。4.3 阶段三高级模型审查与裁决高级模型接手Claude-3-Sonnet收到任务。它首先阅读结构化的审查数据包迅速抓住核心矛盾。深入调查基于数据包中的线索它可能要求技能提供更多信息例如服务B安全补丁的具体内容、服务A与服务B之间的网络拓扑监控图。给出裁决与方案Claude-3-Sonnet经过分析得出结论“根本原因不是API schema变更。安全补丁引入了额外的内存加密操作在特定负载下导致服务B的CPU使用率周期性飙升进而延长了请求处理时间表现为调用方超时。建议方案1. 优化服务B的加密操作逻辑或资源分配2. 作为临时缓解适当调整服务A的超时设置3. 增加对服务B的CPU监控告警。”解决方案验证智能体根据新方案执行验证步骤如调整配置、运行测试确认问题解决。4.4 阶段四闭环与知识沉淀结果评估问题成功解决。技能评估此次解决过程涉及了多模型协作发现了“安全补丁可能引起性能退化”这一潜在模式。知识沉淀提议技能自动生成一条建议“将‘安全部署后需观察性能指标’作为一条检查项加入部署检查清单.learnings。” 并可能提议将“如何分析间歇性超时”的排查路径简化为一个内部工具脚本记录到TOOLS.md。成本核算本次任务首发模型GPT-3.5-Turbo花费了 $0.002升级审查模型Claude-3-Sonnet花费了 $0.015。总成本 $0.017远低于一开始就使用GPT-4可能需 $0.06。更重要的是我们获得了一个结构化的故障排查案例和一条团队知识。5. 常见问题、避坑指南与进阶技巧5.1 决策矩阵过于敏感导致频繁无效升级问题升级太频繁大部分升级后发现只是廉价模型“虚惊一场”高级模型只是重复了廉价模型的结论造成成本浪费。排查与解决校准触发器阈值分析历史日志计算每个触发器如重试次数、冲突检测的“升级有效率”升级后确实发现新问题或修正错误的比率。调低低有效率触发器的敏感度。引入冷却期对于同一任务在一次升级审查完成后设置一个冷却期例如10分钟在此期间内即使再次触发条件也暂不升级避免在同一个问题上反复横跳。丰富冲突检测逻辑简单的文本匹配可能产生误报。可以引入更智能的冲突检测例如使用一个微小的、专门训练的分类器来判断两段文本是否在实质上矛盾而非字面上不同。设置升级成本预算为单个任务或时间段设置升级成本上限防止在极端情况下失控。5.2 审查数据包准备质量差导致高级模型效率低下问题自动生成的审查数据包冗长、重点不突出或者遗漏关键事实导致高级模型需要花费大量 tokens 重新梳理上下文抵消了升级的价值。解决技巧模板驱动强制结构化坚持使用严格的模板并要求首发模型在输出时就按照模板的章节来组织它的“最终报告”。这可以通过在给首发模型的系统提示词中嵌入模板要求来实现。事实提取自动化开发辅助函数自动从对话历史、代码变更或日志中提取结构化事实如错误码、时间戳、文件变更列表。减少对模型总结能力的依赖。“一句话摘要”练习在模板中要求每个章节如关键事实、主要推断的开头必须有一句不超过20个字的总结。这能极大提升信息密度。人工审核环节可选对于非常高成本或高风险的升级可以在数据包提交给高级模型前插入一个快速的人工确认步骤确保数据包质量。5.3 技能与现有监控、告警系统脱节问题multi-model-escalation技能成为一个信息孤岛无法利用已有的 Prometheus/Grafana 监控指标、Sentry 错误追踪或 PagerDuty 告警来作为升级触发证据。集成方案将技能作为告警接收器配置监控系统的 webhook在特定告警触发时如错误率飙升、延迟P99超标向 OpenClaw 发送一个任务并附带告警上下文。该任务初始就标记为高风险可能直接进入高级模型或人工审查流程。技能主动查询在escalation-check.sh或技能内部逻辑中集成对常用监控 API 的调用。例如在分析一个服务故障时技能可以自动去查询该服务在过去一小时的 CPU、内存、错误率指标并将这些数据作为“外部事实”填入审查数据包。统一事件总线在更复杂的架构中可以让智能体系统订阅一个全局的事件总线如 Kafka。所有系统事件代码部署、监控告警、用户反馈都发布到总线上。multi-model-escalation技能监听相关事件流实时构建更全面的上下文做出更精准的升级决策。5.4 模型能力评估与路由表维护问题模型市场变化快新的模型发布旧的模型降价或更新。手动维护“模型能力-成本矩阵”和路由表非常繁琐且容易过时。自动化维护思路建立基准测试套件针对团队常见任务类型代码修复、文档生成、数据分析等设计一套标准测试题。定期自动化评测每周或每月用这套测试题自动调用所有已配置和候选的模型 API收集其输出质量通过规则或轻量级模型评分、延迟和成本。动态更新路由表根据评测结果自动计算每个模型的“性价比”得分并更新技能或智能体框架的模型路由配置。例如如果发现新发布的Model-X在代码任务上质量与GPT-3.5-Turbo相当但成本低30%则自动将其设为该类任务的首发模型。5.5 技能本身的性能与可靠性问题技能增加的逻辑判断、数据包生成等步骤是否会引入显著延迟或成为单点故障优化实践异步与非阻塞设计技能的评估和决策逻辑应设计为异步操作。当首发模型在思考时技能可以并行地准备上下文、检查外部数据源。升级决策和数据包生成不应阻塞主任务流程。降级与超时机制技能自身的操作如调用外部API获取部署记录必须设置严格的超时。如果技能在预定时间内无法完成评估应有一个默认策略例如“不升级继续执行”或“标记为需人工复查”避免因技能故障导致整个智能体卡死。状态持久化升级流程中的中间状态如生成的审查数据包、升级决策原因必须可靠地持久化到数据库或文件系统中。这样即使智能体进程重启也能恢复升级上下文。在实际部署中我发现最有效的起步方式不是追求全自动化而是先将这套流程作为“人工增强”的工具来用。即让智能体在遇到困难时不是直接求助人类而是先生成一份结构化的审查数据包然后连同这份数据包一起提交给人类。这已经能极大提升人类处理问题的效率。随后再逐步将数据包的接收方从人类替换为高级模型实现平滑过渡。这种渐进式的落地策略阻力最小价值显现最快。