1. 项目概述当大模型开始自我进化最近在跟几个做模型推理和部署的朋友聊天大家普遍有个感觉大模型LLMs上线后的表现跟离线评测时总有点“货不对板”。你精心调教好的模型在真实用户五花八门、充满长尾问题的请求面前偶尔还是会“掉链子”。传统的解决方案无非是堆资源、堆模型搞个庞大的模型库或者用复杂的规则路由。但这就像开一家餐厅为了应对所有顾客你雇了川菜、粤菜、法餐、日料所有厨师成本高不说顾客点个“微辣加糖醋口”的菜还得靠前台经理路由规则猜该派给谁效率低还容易猜错。“LLMs Improving LLMs: Agentic Discovery for Test-Time Scaling”这个标题指向的正是解决这个痛点的一种新范式。它不再是静态地部署一堆模型而是让大模型在服务期间Test-Time动态地、智能地Agentic去发现和调用更适合当前任务的其他模型或能力从而实现性能的弹性扩展Scaling。简单说就是让模型自己学会“摇人”。当它遇到自己不擅长或不确定的问题时能主动、智能地找到更合适的“专家模型”来协作完成整个过程在推理时动态发生。这背后的核心驱动力是当前大模型生态的两个现实第一模型能力日益分化且专业化有的擅长代码有的精通数学有的对话流畅第二用户请求的复杂度和多样性远超单一模型的训练数据覆盖范围。而“Agentic Discovery”正是连接这两端的桥梁。结合最近热门的“chimera_ latency- and performance-aware multi-agent serving for heterogeneous llms”概念我们可以更清晰地看到未来的服务架构不再是简单的模型并列而是一个由多个异构heterogeneous模型智能体Agent组成的、同时兼顾延迟latency和性能performance的协同网络。每个请求进来系统都会在毫秒级内智能地组建一个临时的、最优的“模型小队”来完成任务。这篇文章我就结合自己的理解和一些前沿的实践思路来拆解一下“Agentic Discovery for Test-Time Scaling”到底是怎么一回事它的核心设计思路、关键技术挑战以及我们如何着手去构建这样一个系统。无论你是算法工程师、架构师还是对LLM应用落地方向感兴趣的朋友相信都能从中获得一些启发。2. 核心理念与架构设计拆解2.1 从静态服务到动态智能体协作传统的LLM服务架构我们称之为“静态服务”或“模型池”模式。你预先部署好若干个模型实例比如GPT-4、Claude、CodeLlama等前端通过一个负载均衡器或者一个基于规则的Router例如根据问题是否包含代码关键字决定路由来分配请求。这种模式的瓶颈非常明显规则僵化规则系统难以覆盖所有复杂、隐含的意图。用户问“如何用Python实现一个快速排序并解释其时间复杂度”这条请求同时涉及代码和数学理论规则路由很难完美处理。信息孤岛每个模型独立处理请求彼此之间没有信息交换和能力互补。一个模型回答错了系统也无法知道另一个模型可能答得更好。资源浪费为了应对峰值和多样性往往需要冗余部署多个大容量通用模型成本高昂。而“Agentic Discovery”倡导的是一种动态、智能的协作模式。在这个模式下每一个用户请求首先被一个**调度智能体Orchestrator Agent**接收。这个调度者本身也是一个LLM它的核心任务不是直接生成答案而是进行“任务分解与能力发现”。它的工作流可以这样理解意图理解与任务规划调度智能体分析用户请求将其拆解成多个可能的子任务或能力维度。例如对于上述的“Python快速排序”问题它可能识别出需要“代码生成”、“算法解释”、“复杂度分析”等能力。能力发现与路由决策调度智能体基于一个实时更新的“能力目录”去寻找哪些可用的模型智能体Worker Agent最适合处理这些子任务。这个决策不是随机的而是基于对历史协作效果、当前负载、预期延迟和成本的多目标优化。协同执行与结果合成调度智能体将子任务分发给选中的专家模型智能体收集它们的输出最后可能还需要一个“合成智能体”来整合、校验并生成最终给用户的回复。整个过程中“Discovery”发现是关键。它不是基于固定规则而是基于对请求内容的深度理解动态地在模型生态中寻找最佳组合。这就像一位经验丰富的项目经理接到一个复杂项目后迅速在人才库中识别并组建最合适的专家团队。2.2 核心组件构建智能体协作网络要实现上述流程我们需要设计几个核心组件它们共同构成了一个智能体协作网络。1. 调度智能体Orchestrator Agent这是系统的大脑。通常由一个中等规模、但擅长规划和工具调用的LLM担任例如GPT-4、Claude-3 Haiku或专门微调的模型。它的提示词Prompt工程至关重要需要明确赋予其以下能力任务分解将复杂、模糊的用户查询转化为清晰、可执行的任务列表。工具使用它需要调用“模型发现服务”来查询能力目录。决策逻辑基于性能、延迟、成本等约束进行多目标权衡。例如可以设计这样的提示词框架“你是一个智能调度员。请分析用户问题将其分解为关键能力需求。然后根据实时能力目录如下为每个子任务选择最合适、且综合响应时间最短的模型。能力目录中包含了每个模型的描述、擅长领域、平均响应时间和当前状态...”2. 模型智能体Worker Agent与能力目录Capability Registry每个可被调用的模型如GPT-4-Turbo、Claude-3-Sonnet、DeepSeek-Coder、MathGLM都被封装成一个统一的智能体接口。它们向一个中心化的“能力目录”注册自己的元信息功能描述自然语言描述如“擅长Python和JavaScript代码生成与调试”。性能指标在不同任务类型上的历史准确率、平均响应延迟。资源状态当前负载、可用性。调用成本每次调用的计算/API成本。这个目录需要实时或近实时更新是调度智能体进行“发现”的依据。它可以通过模型自描述、离线评估、在线A/B测试反馈等方式来构建和更新。3. 通信与协调层智能体之间需要高效的通信机制。通常采用基于API的标准化请求-响应模式。但为了降低延迟协调层需要精心设计异步并行调用对于可并行的子任务调度智能体应同时发起多个调用。流式中间结果处理对于长文本生成任务可以考虑流式返回和初步合成减少用户等待时间。超时与降级策略设定每个子任务的超时时间一旦超时立即启用备选模型或降级方案。4. 评估与反馈回路这是系统能够持续“Improving”的关键。每次请求处理完成后系统应收集多方面的反馈用户显式反馈如点赞/点踩。隐式反馈如交互轮次、是否中途放弃。合成质量评估使用一个轻量级评估模型或基于规则对最终答案进行评分。 这些反馈数据被用于更新能力目录中模型的历史性能数据甚至可以用于微调调度智能体的决策策略形成一个闭环的学习系统。注意这个架构听起来复杂但在初期MVP最小可行产品阶段可以从最简单的“双模型路由”开始。例如用一个轻量模型如Haiku做调度器在“代码问题”和“通用问题”两个专家模型间做选择同时记录选择结果和最终效果逐步迭代出能力目录和更精细的调度策略。3. 关键技术挑战与实现要点3.1 延迟与性能的权衡Chimera系统的启示“chimera_ latency- and performance-aware multi-agent serving” 这个概念精准地命中了Agentic Discovery系统最核心的挑战如何在智能体协作引入的额外延迟调度、多次模型调用、结果合成与最终获得的性能提升答案质量之间取得最佳平衡。想象一下用户问一个问题如果直接问最强的通用模型如GPT-4可能2秒得到90分的答案。而采用智能体发现调度思考需要0.5秒调用一个专用模型需要1秒合成需要0.3秒总耗时1.8秒但得到了95分的答案。这是值得的。但如果调度过程很复杂调用链条很长总耗时变成了5秒即使答案质量提高到97分对于很多实时交互场景来说用户体验可能反而下降了。因此系统的设计必须是“Latency-aware”和“Performance-aware”的。实现要点1分层调度与快速路径不能对所有请求都进行复杂的任务分解和发现。系统需要设置一个“快速路径”。例如第一层轻量级意图分类器。用一个极快的小模型或甚至基于嵌入向量的相似度匹配对请求进行粗粒度分类。如果判断为极其简单或高度通用的请求直接路由到默认的通用模型跳过复杂的调度智能体。第二层智能体调度。只有被判定为复杂、专业或模糊的请求才会进入完整的Agentic Discovery流程。 这种方式可以确保大部分简单请求的延迟不受影响。实现要点2预测性延迟预算调度智能体在做决策时必须将延迟作为一个核心约束条件。能力目录中需要提供每个模型智能体在不同输入长度下的延迟预估可以是历史P95延迟。调度智能体在规划时会为整个任务分配一个“总延迟预算”例如根据请求类型设定为2秒或5秒。它的任务分解和模型选择必须在预算内寻求性能最优解。实现要点3并行化与流水线仔细分析任务依赖关系。无依赖的子任务坚决并行调用。对于有依赖的任务例如子任务B需要子任务A的输出作为输入考虑流水线设计让A开始流式输出时B就可以开始处理而不是等A完全结束。实操心得在初期不要过度追求复杂的优化。可以先实现一个简单的、串行的Agentic Discovery流程并全面埋点记录每个环节的耗时调度思考时间、每个模型调用时间、合成时间。用真实流量跑一段时间后分析延迟分布找到瓶颈点。通常最大的瓶颈不是模型调用本身而是调度智能体的思考时间LLM生成规划文本的时间和多个网络调用带来的往返延迟RTT。针对性地优化这两个点如用更小的调度模型、优化提示词减少输出长度、将模型部署在同一区域网络内效果立竿见影。3.2 能力目录的构建与动态更新能力目录是智能体发现的“地图”。一张不准或过时的地图会导致调度系统做出错误决策。构建目录的几种方式模型自描述让每个模型智能体用一段自然语言描述自己。优点是简单但可能不客观、不全面。离线基准评估在一套涵盖各领域的标准测试集如MMLU、HumanEval、GSM8K上运行所有模型用得分来量化其在不同维度的能力。这是最可靠的方式但需要大量计算资源。在线影子测试在生产环境中将少量流量同时发送给多个候选模型收集它们的输出但只将其中一个的结果返回给用户。通过后续的反馈或人工评估来比较模型间的相对性能。这种方式数据更贴近真实分布。动态更新的挑战模型的表现可能随着时间、数据分布漂移Data Drift而发生变化。能力目录需要更新。定期重评估每周或每月用最新的测试集或抽样请求进行重评估。实时反馈集成将每次请求的用户反馈显式/隐式以某种形式如滑动平均得分反馈到对应模型的性能记录中。但要注意对抗噪声和恶意反馈。目录的数据结构设计它不应该只是一个静态表格。可以考虑设计成向量数据库将模型的能力描述和任务类型编码成向量。当调度智能体分析出任务需求后也可以将需求编码成向量通过向量相似度搜索快速找到潜在匹配的模型再进行精细筛选。这能加速“发现”过程。3.3 调度智能体的提示词工程与稳定性调度智能体的决策质量直接决定系统成败。而它的“智商”和“稳定性”很大程度上由提示词Prompt决定。提示词设计核心要素明确的角色与目标“你是一个旨在为用户提供最高质量答案的智能调度系统。你的目标是以最小的总响应时间协调最合适的专家模型来解决用户问题。”结构化输出要求必须强制要求调度智能体以指定的、易于解析的格式如JSON输出其规划。例如{ decomposed_tasks: [ {task_id: 1, description: 生成Python快速排序代码, required_capability: code_generation.python.algorithm}, {task_id: 2, description: 解释快速排序的算法原理, required_capability: algorithm_explanation}, {task_id: 3, description: 分析算法的时间与空间复杂度, required_capability: complexity_analysis} ], model_assignments: [ {task_id: 1, model_id: deepseek-coder-33b, reason: 在代码生成基准HumanEval上得分高}, {task_id: 2, model_id: claude-3-sonnet, reason: 擅长清晰、细致的解释}, {task_id: 3, model_id: gpt-4, reason: 在数学和逻辑推理上综合能力强} ], execution_plan: parallel // 或 sequential }提供上下文与约束在提示词中嵌入当前的能力目录摘要、各模型的预估延迟、成本权重等信息。并明确总延迟预算。示例教学Few-shot Learning提供几个从用户问题到成功任务分解和模型分配的完整示例让模型更好地理解你的期望。稳定性保障LLM作为调度器可能存在输出格式不稳定、偶尔“胡言乱语”的情况。输出格式校验与重试对调度器的输出进行严格的JSON解析和模式校验。如果失败则让调度器重试或在提示词中要求其“只输出JSON不输出任何其他文字”。后备规则当调度器连续失败或超时时系统应能回退到基于规则的简单路由策略保证服务可用性。版本控制与回滚对调度智能体的提示词进行版本化管理。任何更改都需经过A/B测试确认效果提升后方可全量并准备好快速回滚方案。4. 从零搭建一个简易原型系统理论说了这么多我们来动手设计一个最小可行性的原型验证核心想法。这个原型的目标是处理用户输入的学术/技术问题并尝试通过调用不同的开源模型来获得更好的答案。4.1 技术栈选择与环境准备我们选择Python作为主要语言因为它有最丰富的AI库和框架支持。核心组件选型调度智能体使用Ollama本地运行Llama 3.1 8B或Qwen 2.5 7B这类中等尺寸、推理速度较快的模型。它们足以胜任任务规划和工具调用。选择本地运行是为了避免API调用延迟和成本。专家模型智能体同样使用Ollama部署多个不同专长的开源模型。通用对话/解释Qwen 2.5 7B(通用能力强)代码生成DeepSeek Coder 6.7B(专精代码)数学推理MetaMath 7B(专精数学)能力目录用一个简单的Python字典或SQLite数据库在内存中维护。协调框架使用FastAPI构建轻量级API服务方便各个智能体之间通过HTTP调用。使用asyncio实现异步并发调用。评估反馈初期简化仅记录每次调用的模型组合和最终输出后续可加入人工评估或轻量级自动评估。环境搭建步骤安装Ollama前往Ollama官网下载并安装。拉取所需模型ollama pull llama3.1:8b ollama pull qwen2.5:7b ollama pull deepseek-coder:6.7b ollama pull metamath:7b创建项目目录安装Python依赖pip install fastapi uvicorn httpx pydantic初始化一个简单的能力目录registry.py# registry.py capability_registry { qwen2.5:7b: { description: 通用对话与解释知识面广逻辑清晰。, strengths: [general_qa, explanation, translation], avg_latency_ms: 1200, endpoint: http://localhost:11434/api/generate # Ollama默认API }, deepseek-coder:6.7b: { description: 专精多种编程语言的代码生成、补全与调试。, strengths: [code_generation, code_debug, algorithm], avg_latency_ms: 1500, endpoint: http://localhost:11434/api/generate }, metamath:7b: { description: 专注于数学问题求解与推理。, strengths: [math_reasoning, logic_puzzle], avg_latency_ms: 1800, endpoint: http://localhost:11434/api/generate } }4.2 调度智能体与任务执行引擎实现第一步构建调度智能体Orchestrator我们创建一个orchestrator.py它包含一个核心函数plan_and_dispatch。# orchestrator.py import httpx import json from registry import capability_registry import asyncio # 调度智能体的提示词模板 SCHEDULER_PROMPT_TEMPLATE 你是一个智能任务调度器。请分析下面的用户问题将其分解为关键子任务并为每个子任务从能力目录中选择最合适的模型。 请严格按照以下JSON格式输出不要输出任何其他内容。 能力目录摘要 {capability_summary} 用户问题{user_query} 请输出JSON {{ decomposed_tasks: [ {{task_id: 1, description: 子任务1描述, required_capability: 所需能力关键词}}, ... ], model_assignments: [ {{task_id: 1, model_id: 选择的模型ID, reason: 选择理由}}, ... ], execution_plan: parallel // 或 sequential基于任务依赖关系 }} async def call_llm(prompt, modelllama3.1:8b, endpointhttp://localhost:11434/api/generate): 调用Ollama模型的通用函数 async with httpx.AsyncClient(timeout30.0) as client: payload { model: model, prompt: prompt, stream: False, options: {temperature: 0.1} # 低温度保证输出稳定 } try: resp await client.post(endpoint, jsonpayload) resp.raise_for_status() result resp.json() return result[response].strip() except Exception as e: print(f调用模型 {model} 失败: {e}) return None async def plan_and_dispatch(user_query: str): 核心调度函数 # 1. 准备能力目录摘要 capability_summary \n.join([f- {mid}: {info[description]} 擅长 {, .join(info[strengths])} for mid, info in capability_registry.items()]) # 2. 构建调度提示词 prompt SCHEDULER_PROMPT_TEMPLATE.format( capability_summarycapability_summary, user_queryuser_query ) # 3. 调用调度模型获取规划 print(调度智能体思考中...) plan_json_str await call_llm(prompt, modelllama3.1:8b) if not plan_json_str: return {error: 调度失败} # 4. 解析规划 try: plan json.loads(plan_json_str) except json.JSONDecodeError: # 如果输出不是合法JSON尝试简单修复或使用后备规则 print(f调度器输出非标准JSON: {plan_json_str}) # 后备方案直接使用通用模型处理 return await fallback_to_general_model(user_query) # 5. 根据执行计划并发或串行调用专家模型 tasks_output {} if plan.get(execution_plan) parallel: # 并行执行 async_tasks [] for assignment in plan[model_assignments]: task_id assignment[task_id] model_id assignment[model_id] # 找到对应的任务描述作为给专家模型的输入 task_desc next((t[description] for t in plan[decomposed_tasks] if t[task_id] task_id), user_query) expert_prompt f请完成以下子任务{task_desc}\n上下文问题{user_query}\n请提供清晰、准确的回答。 async_tasks.append(call_expert_model(expert_prompt, model_id, task_id)) results await asyncio.gather(*async_tasks, return_exceptionsTrue) for task_id, result in results: if isinstance(result, Exception): tasks_output[task_id] f模型调用异常: {result} else: tasks_output[task_id] result else: # 串行执行简化处理实际可能需要处理依赖 for assignment in plan[model_assignments]: task_id assignment[task_id] model_id assignment[model_id] task_desc next((t[description] for t in plan[decomposed_tasks] if t[task_id] task_id), user_query) expert_prompt f请完成以下子任务{task_desc}\n上下文问题{user_query}\n请提供清晰、准确的回答。 output await call_expert_model(expert_prompt, model_id, task_id) tasks_output[task_id] output # 6. 结果合成此处简化直接拼接 final_answer \n\n.join([f【子任务{task_id}】\n{output} for task_id, output in sorted(tasks_output.items())]) return {plan: plan, subtask_outputs: tasks_output, final_answer: final_answer} async def call_expert_model(prompt, model_id, task_id): 调用指定的专家模型 if model_id not in capability_registry: return f错误未找到模型 {model_id} endpoint capability_registry[model_id][endpoint] response await call_llm(prompt, modelmodel_id, endpointendpoint) return response if response else f模型 {model_id} 无响应 async def fallback_to_general_model(query): 后备方案直接使用通用模型 print(启用后备方案使用通用模型...) answer await call_llm(f请回答以下问题{query}, modelqwen2.5:7b) return {plan: fallback, final_answer: answer}第二步创建FastAPI主服务创建main.py来提供Web API。# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from orchestrator import plan_and_dispatch import asyncio app FastAPI(titleAgentic Discovery 原型系统) class QueryRequest(BaseModel): question: str app.post(/ask) async def ask_question(request: QueryRequest): 接收用户问题触发智能体发现流程 try: result await plan_and_dispatch(request.question) return result except Exception as e: raise HTTPException(status_code500, detailf处理请求时出错: {str(e)}) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)4.3 运行测试与效果观察启动服务在终端运行python main.py。发送测试请求使用curl或Postman等工具。curl -X POST http://localhost:8000/ask \ -H Content-Type: application/json \ -d {question: 请用Python实现一个快速排序算法并解释其原理和时间复杂度。}观察输出你会收到一个JSON响应其中包含了调度智能体生成的plan分解的任务和分配的模型、每个子任务的输出subtask_outputs以及拼接而成的final_answer。初期你可能会遇到以下典型情况调度器输出格式错误提示词需要调整增加更严格的格式指令和示例。模型调用超时检查Ollama服务是否正常运行或调整httpx的超时设置。任务分解不合理调度模型可能过度分解或分解不足。需要在提示词中提供更明确的任务分解示例例如“一个任务应聚焦于一个独立的、可执行的能力点”。延迟过高串行调用导致总耗时很长。优化execution_plan的逻辑让无依赖任务并行化。尽管这个原型非常简陋但它已经实现了Agentic Discovery的核心闭环动态分析问题、发现并调用专家模型、整合结果。你可以在此基础上逐步完善能力目录的更新机制、增加更智能的结果合成器而不是简单拼接、集成反馈系统并向chimera系统所倡导的“延迟-性能感知”方向优化。5. 生产级考量与未来演进方向将一个原型系统升级为能够承载生产流量的服务需要解决一系列工程化和算法上的挑战。5.1 性能、成本与可靠性的三角平衡在生产环境中Agentic Discovery系统必须在质量Performance、延迟/吞吐量Latency/Throughput和成本Cost之间做出精细的权衡。1. 成本控制每次用户查询可能触发多次模型调用成本可能显著高于单一模型。控制策略包括精细化计费与预算为每个用户或每类请求设置“计算预算”。调度智能体在选择模型时需要将API调用成本或推理算力成本纳入目标函数。缓存策略对于常见或重复的问题经过向量化相似度匹配可以直接返回缓存的结果避免重复调用模型。对于子任务的结果也可以进行缓存。模型层级化并非所有子任务都需要最强模型。能力目录中应包含不同规模和成本的模型如小型、中型、大型。调度器可以根据子任务的难度和重要性选择“性价比”最高的模型。2. 可靠性保障智能体熔断与降级监控每个模型智能体的健康状态错误率、延迟。当某个模型连续失败或响应过慢时将其从能力目录中暂时标记为不可用熔断并采用备用模型或降级方案。请求幂等性与重试对于可能因网络问题失败的模型调用设计幂等的重试机制但需设置重试上限和退避策略避免雪崩。最终一致性合成如果某个专家模型调用失败合成器应能基于已有部分结果和调度器的原始规划尝试生成一个仍可接受的答案或明确告知用户部分信息缺失。3. 性能监控与可观测性系统必须提供全面的监控指标包括调度层面调度耗时、任务分解数量、模型选择分布。模型调用层面每个模型的P50/P95/P99延迟、调用成功率、输出token数。业务层面端到端响应延迟、答案质量评分可通过轻量级评估模型或抽样人工评估。 使用这些指标来驱动优化例如发现某个模型对某类任务延迟很高但质量提升有限就可以在调度策略中降低其权重。5.2 模型智能体的进阶形态工具使用与自我评估当前的架构中模型智能体只是被动接收问题并生成文本。更高级的形态是赋予它们使用工具Tools和进行自我评估Self-Evaluation的能力。工具使用Tool Use一个模型智能体不仅可以生成文本还可以调用外部API、查询数据库、执行代码等。例如一个回答“今天纽约天气如何”的智能体可以调用天气API获取实时数据。一个处理“分析我上个月消费数据”的智能体在获得用户授权后可以调用数据库查询接口。 调度智能体在任务分解时可以将“需要调用XX工具”作为一项子任务需求。能力目录中也需要注册模型智能体所支持的工具列表。自我评估与置信度Self-Evaluation Confidence让模型智能体在输出答案的同时给出一个置信度分数例如0到1。这对于调度智能体的决策和最终结果的合成非常有价值。如果某个专家模型对其答案置信度很低调度器可以将其结果权重降低或触发另一个模型进行验证。在结果合成阶段可以基于置信度对多个答案进行加权融合而不是简单拼接。 实现自我评估可以通过在提示词中要求模型输出“Confidence: X%”或者训练一个额外的轻量级“验证器”模型来评估输出质量。5.3 系统的持续进化从发现到创造“LLMs Improving LLMs”的终极愿景可能不仅仅是动态发现现有模型而是能够创造新的解决方案。1. 基于反馈的在线学习系统收集的用户反馈和交互数据不仅可以用于更新模型的能力评分还可以用于微调调度策略将每次请求的上下文用户问题、调度决策、最终结果质量作为训练数据用来微调调度智能体如果它是一个可微调的模型或者训练一个独立的“策略网络”使其决策越来越准。发现模型盲区持续分析那些被所有现有模型都处理不好低置信度、负反馈的问题类型。这些数据可以指导我们收集特定数据去训练或微调新的专家模型从而扩充能力目录。2. 智能体组合的自动化探索当前调度智能体的“发现”是基于预定义的能力目录。未来系统可以自动探索模型智能体之间的组合模式。例如通过强化学习让调度器尝试不同的模型组合顺序和交互方式如让模型A的输出作为模型B的提示词的一部分并评估最终效果从而发现人类未曾想到的高效协作模式。3. 走向真正的“Test-Time Scaling”最终的理想状态是系统在推理时Test-Time不仅能横向扩展调用更多模型还能纵向扩展动态调整单个模型的推理深度或方法。例如对于一个难题系统可以决定让某个模型进行“Chain-of-Thought”式深度推理而对于简单问题则使用快速生成模式。这需要更细粒度的模型能力控制和更灵活的调度机制。构建这样一个系统绝非一日之功它需要算法、工程、产品三方面的紧密合作。从今天的一个简单原型开始逐步迭代解决一个个具体的挑战我们就能向着让大模型在服务中自我进化、越用越聪明的目标稳步前进。这条路充满挑战但也正是其魅力所在。 大模型服务新范式：Agentic Discovery实现推理时动态协同与性能扩展
1. 项目概述当大模型开始自我进化最近在跟几个做模型推理和部署的朋友聊天大家普遍有个感觉大模型LLMs上线后的表现跟离线评测时总有点“货不对板”。你精心调教好的模型在真实用户五花八门、充满长尾问题的请求面前偶尔还是会“掉链子”。传统的解决方案无非是堆资源、堆模型搞个庞大的模型库或者用复杂的规则路由。但这就像开一家餐厅为了应对所有顾客你雇了川菜、粤菜、法餐、日料所有厨师成本高不说顾客点个“微辣加糖醋口”的菜还得靠前台经理路由规则猜该派给谁效率低还容易猜错。“LLMs Improving LLMs: Agentic Discovery for Test-Time Scaling”这个标题指向的正是解决这个痛点的一种新范式。它不再是静态地部署一堆模型而是让大模型在服务期间Test-Time动态地、智能地Agentic去发现和调用更适合当前任务的其他模型或能力从而实现性能的弹性扩展Scaling。简单说就是让模型自己学会“摇人”。当它遇到自己不擅长或不确定的问题时能主动、智能地找到更合适的“专家模型”来协作完成整个过程在推理时动态发生。这背后的核心驱动力是当前大模型生态的两个现实第一模型能力日益分化且专业化有的擅长代码有的精通数学有的对话流畅第二用户请求的复杂度和多样性远超单一模型的训练数据覆盖范围。而“Agentic Discovery”正是连接这两端的桥梁。结合最近热门的“chimera_ latency- and performance-aware multi-agent serving for heterogeneous llms”概念我们可以更清晰地看到未来的服务架构不再是简单的模型并列而是一个由多个异构heterogeneous模型智能体Agent组成的、同时兼顾延迟latency和性能performance的协同网络。每个请求进来系统都会在毫秒级内智能地组建一个临时的、最优的“模型小队”来完成任务。这篇文章我就结合自己的理解和一些前沿的实践思路来拆解一下“Agentic Discovery for Test-Time Scaling”到底是怎么一回事它的核心设计思路、关键技术挑战以及我们如何着手去构建这样一个系统。无论你是算法工程师、架构师还是对LLM应用落地方向感兴趣的朋友相信都能从中获得一些启发。2. 核心理念与架构设计拆解2.1 从静态服务到动态智能体协作传统的LLM服务架构我们称之为“静态服务”或“模型池”模式。你预先部署好若干个模型实例比如GPT-4、Claude、CodeLlama等前端通过一个负载均衡器或者一个基于规则的Router例如根据问题是否包含代码关键字决定路由来分配请求。这种模式的瓶颈非常明显规则僵化规则系统难以覆盖所有复杂、隐含的意图。用户问“如何用Python实现一个快速排序并解释其时间复杂度”这条请求同时涉及代码和数学理论规则路由很难完美处理。信息孤岛每个模型独立处理请求彼此之间没有信息交换和能力互补。一个模型回答错了系统也无法知道另一个模型可能答得更好。资源浪费为了应对峰值和多样性往往需要冗余部署多个大容量通用模型成本高昂。而“Agentic Discovery”倡导的是一种动态、智能的协作模式。在这个模式下每一个用户请求首先被一个**调度智能体Orchestrator Agent**接收。这个调度者本身也是一个LLM它的核心任务不是直接生成答案而是进行“任务分解与能力发现”。它的工作流可以这样理解意图理解与任务规划调度智能体分析用户请求将其拆解成多个可能的子任务或能力维度。例如对于上述的“Python快速排序”问题它可能识别出需要“代码生成”、“算法解释”、“复杂度分析”等能力。能力发现与路由决策调度智能体基于一个实时更新的“能力目录”去寻找哪些可用的模型智能体Worker Agent最适合处理这些子任务。这个决策不是随机的而是基于对历史协作效果、当前负载、预期延迟和成本的多目标优化。协同执行与结果合成调度智能体将子任务分发给选中的专家模型智能体收集它们的输出最后可能还需要一个“合成智能体”来整合、校验并生成最终给用户的回复。整个过程中“Discovery”发现是关键。它不是基于固定规则而是基于对请求内容的深度理解动态地在模型生态中寻找最佳组合。这就像一位经验丰富的项目经理接到一个复杂项目后迅速在人才库中识别并组建最合适的专家团队。2.2 核心组件构建智能体协作网络要实现上述流程我们需要设计几个核心组件它们共同构成了一个智能体协作网络。1. 调度智能体Orchestrator Agent这是系统的大脑。通常由一个中等规模、但擅长规划和工具调用的LLM担任例如GPT-4、Claude-3 Haiku或专门微调的模型。它的提示词Prompt工程至关重要需要明确赋予其以下能力任务分解将复杂、模糊的用户查询转化为清晰、可执行的任务列表。工具使用它需要调用“模型发现服务”来查询能力目录。决策逻辑基于性能、延迟、成本等约束进行多目标权衡。例如可以设计这样的提示词框架“你是一个智能调度员。请分析用户问题将其分解为关键能力需求。然后根据实时能力目录如下为每个子任务选择最合适、且综合响应时间最短的模型。能力目录中包含了每个模型的描述、擅长领域、平均响应时间和当前状态...”2. 模型智能体Worker Agent与能力目录Capability Registry每个可被调用的模型如GPT-4-Turbo、Claude-3-Sonnet、DeepSeek-Coder、MathGLM都被封装成一个统一的智能体接口。它们向一个中心化的“能力目录”注册自己的元信息功能描述自然语言描述如“擅长Python和JavaScript代码生成与调试”。性能指标在不同任务类型上的历史准确率、平均响应延迟。资源状态当前负载、可用性。调用成本每次调用的计算/API成本。这个目录需要实时或近实时更新是调度智能体进行“发现”的依据。它可以通过模型自描述、离线评估、在线A/B测试反馈等方式来构建和更新。3. 通信与协调层智能体之间需要高效的通信机制。通常采用基于API的标准化请求-响应模式。但为了降低延迟协调层需要精心设计异步并行调用对于可并行的子任务调度智能体应同时发起多个调用。流式中间结果处理对于长文本生成任务可以考虑流式返回和初步合成减少用户等待时间。超时与降级策略设定每个子任务的超时时间一旦超时立即启用备选模型或降级方案。4. 评估与反馈回路这是系统能够持续“Improving”的关键。每次请求处理完成后系统应收集多方面的反馈用户显式反馈如点赞/点踩。隐式反馈如交互轮次、是否中途放弃。合成质量评估使用一个轻量级评估模型或基于规则对最终答案进行评分。 这些反馈数据被用于更新能力目录中模型的历史性能数据甚至可以用于微调调度智能体的决策策略形成一个闭环的学习系统。注意这个架构听起来复杂但在初期MVP最小可行产品阶段可以从最简单的“双模型路由”开始。例如用一个轻量模型如Haiku做调度器在“代码问题”和“通用问题”两个专家模型间做选择同时记录选择结果和最终效果逐步迭代出能力目录和更精细的调度策略。3. 关键技术挑战与实现要点3.1 延迟与性能的权衡Chimera系统的启示“chimera_ latency- and performance-aware multi-agent serving” 这个概念精准地命中了Agentic Discovery系统最核心的挑战如何在智能体协作引入的额外延迟调度、多次模型调用、结果合成与最终获得的性能提升答案质量之间取得最佳平衡。想象一下用户问一个问题如果直接问最强的通用模型如GPT-4可能2秒得到90分的答案。而采用智能体发现调度思考需要0.5秒调用一个专用模型需要1秒合成需要0.3秒总耗时1.8秒但得到了95分的答案。这是值得的。但如果调度过程很复杂调用链条很长总耗时变成了5秒即使答案质量提高到97分对于很多实时交互场景来说用户体验可能反而下降了。因此系统的设计必须是“Latency-aware”和“Performance-aware”的。实现要点1分层调度与快速路径不能对所有请求都进行复杂的任务分解和发现。系统需要设置一个“快速路径”。例如第一层轻量级意图分类器。用一个极快的小模型或甚至基于嵌入向量的相似度匹配对请求进行粗粒度分类。如果判断为极其简单或高度通用的请求直接路由到默认的通用模型跳过复杂的调度智能体。第二层智能体调度。只有被判定为复杂、专业或模糊的请求才会进入完整的Agentic Discovery流程。 这种方式可以确保大部分简单请求的延迟不受影响。实现要点2预测性延迟预算调度智能体在做决策时必须将延迟作为一个核心约束条件。能力目录中需要提供每个模型智能体在不同输入长度下的延迟预估可以是历史P95延迟。调度智能体在规划时会为整个任务分配一个“总延迟预算”例如根据请求类型设定为2秒或5秒。它的任务分解和模型选择必须在预算内寻求性能最优解。实现要点3并行化与流水线仔细分析任务依赖关系。无依赖的子任务坚决并行调用。对于有依赖的任务例如子任务B需要子任务A的输出作为输入考虑流水线设计让A开始流式输出时B就可以开始处理而不是等A完全结束。实操心得在初期不要过度追求复杂的优化。可以先实现一个简单的、串行的Agentic Discovery流程并全面埋点记录每个环节的耗时调度思考时间、每个模型调用时间、合成时间。用真实流量跑一段时间后分析延迟分布找到瓶颈点。通常最大的瓶颈不是模型调用本身而是调度智能体的思考时间LLM生成规划文本的时间和多个网络调用带来的往返延迟RTT。针对性地优化这两个点如用更小的调度模型、优化提示词减少输出长度、将模型部署在同一区域网络内效果立竿见影。3.2 能力目录的构建与动态更新能力目录是智能体发现的“地图”。一张不准或过时的地图会导致调度系统做出错误决策。构建目录的几种方式模型自描述让每个模型智能体用一段自然语言描述自己。优点是简单但可能不客观、不全面。离线基准评估在一套涵盖各领域的标准测试集如MMLU、HumanEval、GSM8K上运行所有模型用得分来量化其在不同维度的能力。这是最可靠的方式但需要大量计算资源。在线影子测试在生产环境中将少量流量同时发送给多个候选模型收集它们的输出但只将其中一个的结果返回给用户。通过后续的反馈或人工评估来比较模型间的相对性能。这种方式数据更贴近真实分布。动态更新的挑战模型的表现可能随着时间、数据分布漂移Data Drift而发生变化。能力目录需要更新。定期重评估每周或每月用最新的测试集或抽样请求进行重评估。实时反馈集成将每次请求的用户反馈显式/隐式以某种形式如滑动平均得分反馈到对应模型的性能记录中。但要注意对抗噪声和恶意反馈。目录的数据结构设计它不应该只是一个静态表格。可以考虑设计成向量数据库将模型的能力描述和任务类型编码成向量。当调度智能体分析出任务需求后也可以将需求编码成向量通过向量相似度搜索快速找到潜在匹配的模型再进行精细筛选。这能加速“发现”过程。3.3 调度智能体的提示词工程与稳定性调度智能体的决策质量直接决定系统成败。而它的“智商”和“稳定性”很大程度上由提示词Prompt决定。提示词设计核心要素明确的角色与目标“你是一个旨在为用户提供最高质量答案的智能调度系统。你的目标是以最小的总响应时间协调最合适的专家模型来解决用户问题。”结构化输出要求必须强制要求调度智能体以指定的、易于解析的格式如JSON输出其规划。例如{ decomposed_tasks: [ {task_id: 1, description: 生成Python快速排序代码, required_capability: code_generation.python.algorithm}, {task_id: 2, description: 解释快速排序的算法原理, required_capability: algorithm_explanation}, {task_id: 3, description: 分析算法的时间与空间复杂度, required_capability: complexity_analysis} ], model_assignments: [ {task_id: 1, model_id: deepseek-coder-33b, reason: 在代码生成基准HumanEval上得分高}, {task_id: 2, model_id: claude-3-sonnet, reason: 擅长清晰、细致的解释}, {task_id: 3, model_id: gpt-4, reason: 在数学和逻辑推理上综合能力强} ], execution_plan: parallel // 或 sequential }提供上下文与约束在提示词中嵌入当前的能力目录摘要、各模型的预估延迟、成本权重等信息。并明确总延迟预算。示例教学Few-shot Learning提供几个从用户问题到成功任务分解和模型分配的完整示例让模型更好地理解你的期望。稳定性保障LLM作为调度器可能存在输出格式不稳定、偶尔“胡言乱语”的情况。输出格式校验与重试对调度器的输出进行严格的JSON解析和模式校验。如果失败则让调度器重试或在提示词中要求其“只输出JSON不输出任何其他文字”。后备规则当调度器连续失败或超时时系统应能回退到基于规则的简单路由策略保证服务可用性。版本控制与回滚对调度智能体的提示词进行版本化管理。任何更改都需经过A/B测试确认效果提升后方可全量并准备好快速回滚方案。4. 从零搭建一个简易原型系统理论说了这么多我们来动手设计一个最小可行性的原型验证核心想法。这个原型的目标是处理用户输入的学术/技术问题并尝试通过调用不同的开源模型来获得更好的答案。4.1 技术栈选择与环境准备我们选择Python作为主要语言因为它有最丰富的AI库和框架支持。核心组件选型调度智能体使用Ollama本地运行Llama 3.1 8B或Qwen 2.5 7B这类中等尺寸、推理速度较快的模型。它们足以胜任任务规划和工具调用。选择本地运行是为了避免API调用延迟和成本。专家模型智能体同样使用Ollama部署多个不同专长的开源模型。通用对话/解释Qwen 2.5 7B(通用能力强)代码生成DeepSeek Coder 6.7B(专精代码)数学推理MetaMath 7B(专精数学)能力目录用一个简单的Python字典或SQLite数据库在内存中维护。协调框架使用FastAPI构建轻量级API服务方便各个智能体之间通过HTTP调用。使用asyncio实现异步并发调用。评估反馈初期简化仅记录每次调用的模型组合和最终输出后续可加入人工评估或轻量级自动评估。环境搭建步骤安装Ollama前往Ollama官网下载并安装。拉取所需模型ollama pull llama3.1:8b ollama pull qwen2.5:7b ollama pull deepseek-coder:6.7b ollama pull metamath:7b创建项目目录安装Python依赖pip install fastapi uvicorn httpx pydantic初始化一个简单的能力目录registry.py# registry.py capability_registry { qwen2.5:7b: { description: 通用对话与解释知识面广逻辑清晰。, strengths: [general_qa, explanation, translation], avg_latency_ms: 1200, endpoint: http://localhost:11434/api/generate # Ollama默认API }, deepseek-coder:6.7b: { description: 专精多种编程语言的代码生成、补全与调试。, strengths: [code_generation, code_debug, algorithm], avg_latency_ms: 1500, endpoint: http://localhost:11434/api/generate }, metamath:7b: { description: 专注于数学问题求解与推理。, strengths: [math_reasoning, logic_puzzle], avg_latency_ms: 1800, endpoint: http://localhost:11434/api/generate } }4.2 调度智能体与任务执行引擎实现第一步构建调度智能体Orchestrator我们创建一个orchestrator.py它包含一个核心函数plan_and_dispatch。# orchestrator.py import httpx import json from registry import capability_registry import asyncio # 调度智能体的提示词模板 SCHEDULER_PROMPT_TEMPLATE 你是一个智能任务调度器。请分析下面的用户问题将其分解为关键子任务并为每个子任务从能力目录中选择最合适的模型。 请严格按照以下JSON格式输出不要输出任何其他内容。 能力目录摘要 {capability_summary} 用户问题{user_query} 请输出JSON {{ decomposed_tasks: [ {{task_id: 1, description: 子任务1描述, required_capability: 所需能力关键词}}, ... ], model_assignments: [ {{task_id: 1, model_id: 选择的模型ID, reason: 选择理由}}, ... ], execution_plan: parallel // 或 sequential基于任务依赖关系 }} async def call_llm(prompt, modelllama3.1:8b, endpointhttp://localhost:11434/api/generate): 调用Ollama模型的通用函数 async with httpx.AsyncClient(timeout30.0) as client: payload { model: model, prompt: prompt, stream: False, options: {temperature: 0.1} # 低温度保证输出稳定 } try: resp await client.post(endpoint, jsonpayload) resp.raise_for_status() result resp.json() return result[response].strip() except Exception as e: print(f调用模型 {model} 失败: {e}) return None async def plan_and_dispatch(user_query: str): 核心调度函数 # 1. 准备能力目录摘要 capability_summary \n.join([f- {mid}: {info[description]} 擅长 {, .join(info[strengths])} for mid, info in capability_registry.items()]) # 2. 构建调度提示词 prompt SCHEDULER_PROMPT_TEMPLATE.format( capability_summarycapability_summary, user_queryuser_query ) # 3. 调用调度模型获取规划 print(调度智能体思考中...) plan_json_str await call_llm(prompt, modelllama3.1:8b) if not plan_json_str: return {error: 调度失败} # 4. 解析规划 try: plan json.loads(plan_json_str) except json.JSONDecodeError: # 如果输出不是合法JSON尝试简单修复或使用后备规则 print(f调度器输出非标准JSON: {plan_json_str}) # 后备方案直接使用通用模型处理 return await fallback_to_general_model(user_query) # 5. 根据执行计划并发或串行调用专家模型 tasks_output {} if plan.get(execution_plan) parallel: # 并行执行 async_tasks [] for assignment in plan[model_assignments]: task_id assignment[task_id] model_id assignment[model_id] # 找到对应的任务描述作为给专家模型的输入 task_desc next((t[description] for t in plan[decomposed_tasks] if t[task_id] task_id), user_query) expert_prompt f请完成以下子任务{task_desc}\n上下文问题{user_query}\n请提供清晰、准确的回答。 async_tasks.append(call_expert_model(expert_prompt, model_id, task_id)) results await asyncio.gather(*async_tasks, return_exceptionsTrue) for task_id, result in results: if isinstance(result, Exception): tasks_output[task_id] f模型调用异常: {result} else: tasks_output[task_id] result else: # 串行执行简化处理实际可能需要处理依赖 for assignment in plan[model_assignments]: task_id assignment[task_id] model_id assignment[model_id] task_desc next((t[description] for t in plan[decomposed_tasks] if t[task_id] task_id), user_query) expert_prompt f请完成以下子任务{task_desc}\n上下文问题{user_query}\n请提供清晰、准确的回答。 output await call_expert_model(expert_prompt, model_id, task_id) tasks_output[task_id] output # 6. 结果合成此处简化直接拼接 final_answer \n\n.join([f【子任务{task_id}】\n{output} for task_id, output in sorted(tasks_output.items())]) return {plan: plan, subtask_outputs: tasks_output, final_answer: final_answer} async def call_expert_model(prompt, model_id, task_id): 调用指定的专家模型 if model_id not in capability_registry: return f错误未找到模型 {model_id} endpoint capability_registry[model_id][endpoint] response await call_llm(prompt, modelmodel_id, endpointendpoint) return response if response else f模型 {model_id} 无响应 async def fallback_to_general_model(query): 后备方案直接使用通用模型 print(启用后备方案使用通用模型...) answer await call_llm(f请回答以下问题{query}, modelqwen2.5:7b) return {plan: fallback, final_answer: answer}第二步创建FastAPI主服务创建main.py来提供Web API。# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from orchestrator import plan_and_dispatch import asyncio app FastAPI(titleAgentic Discovery 原型系统) class QueryRequest(BaseModel): question: str app.post(/ask) async def ask_question(request: QueryRequest): 接收用户问题触发智能体发现流程 try: result await plan_and_dispatch(request.question) return result except Exception as e: raise HTTPException(status_code500, detailf处理请求时出错: {str(e)}) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)4.3 运行测试与效果观察启动服务在终端运行python main.py。发送测试请求使用curl或Postman等工具。curl -X POST http://localhost:8000/ask \ -H Content-Type: application/json \ -d {question: 请用Python实现一个快速排序算法并解释其原理和时间复杂度。}观察输出你会收到一个JSON响应其中包含了调度智能体生成的plan分解的任务和分配的模型、每个子任务的输出subtask_outputs以及拼接而成的final_answer。初期你可能会遇到以下典型情况调度器输出格式错误提示词需要调整增加更严格的格式指令和示例。模型调用超时检查Ollama服务是否正常运行或调整httpx的超时设置。任务分解不合理调度模型可能过度分解或分解不足。需要在提示词中提供更明确的任务分解示例例如“一个任务应聚焦于一个独立的、可执行的能力点”。延迟过高串行调用导致总耗时很长。优化execution_plan的逻辑让无依赖任务并行化。尽管这个原型非常简陋但它已经实现了Agentic Discovery的核心闭环动态分析问题、发现并调用专家模型、整合结果。你可以在此基础上逐步完善能力目录的更新机制、增加更智能的结果合成器而不是简单拼接、集成反馈系统并向chimera系统所倡导的“延迟-性能感知”方向优化。5. 生产级考量与未来演进方向将一个原型系统升级为能够承载生产流量的服务需要解决一系列工程化和算法上的挑战。5.1 性能、成本与可靠性的三角平衡在生产环境中Agentic Discovery系统必须在质量Performance、延迟/吞吐量Latency/Throughput和成本Cost之间做出精细的权衡。1. 成本控制每次用户查询可能触发多次模型调用成本可能显著高于单一模型。控制策略包括精细化计费与预算为每个用户或每类请求设置“计算预算”。调度智能体在选择模型时需要将API调用成本或推理算力成本纳入目标函数。缓存策略对于常见或重复的问题经过向量化相似度匹配可以直接返回缓存的结果避免重复调用模型。对于子任务的结果也可以进行缓存。模型层级化并非所有子任务都需要最强模型。能力目录中应包含不同规模和成本的模型如小型、中型、大型。调度器可以根据子任务的难度和重要性选择“性价比”最高的模型。2. 可靠性保障智能体熔断与降级监控每个模型智能体的健康状态错误率、延迟。当某个模型连续失败或响应过慢时将其从能力目录中暂时标记为不可用熔断并采用备用模型或降级方案。请求幂等性与重试对于可能因网络问题失败的模型调用设计幂等的重试机制但需设置重试上限和退避策略避免雪崩。最终一致性合成如果某个专家模型调用失败合成器应能基于已有部分结果和调度器的原始规划尝试生成一个仍可接受的答案或明确告知用户部分信息缺失。3. 性能监控与可观测性系统必须提供全面的监控指标包括调度层面调度耗时、任务分解数量、模型选择分布。模型调用层面每个模型的P50/P95/P99延迟、调用成功率、输出token数。业务层面端到端响应延迟、答案质量评分可通过轻量级评估模型或抽样人工评估。 使用这些指标来驱动优化例如发现某个模型对某类任务延迟很高但质量提升有限就可以在调度策略中降低其权重。5.2 模型智能体的进阶形态工具使用与自我评估当前的架构中模型智能体只是被动接收问题并生成文本。更高级的形态是赋予它们使用工具Tools和进行自我评估Self-Evaluation的能力。工具使用Tool Use一个模型智能体不仅可以生成文本还可以调用外部API、查询数据库、执行代码等。例如一个回答“今天纽约天气如何”的智能体可以调用天气API获取实时数据。一个处理“分析我上个月消费数据”的智能体在获得用户授权后可以调用数据库查询接口。 调度智能体在任务分解时可以将“需要调用XX工具”作为一项子任务需求。能力目录中也需要注册模型智能体所支持的工具列表。自我评估与置信度Self-Evaluation Confidence让模型智能体在输出答案的同时给出一个置信度分数例如0到1。这对于调度智能体的决策和最终结果的合成非常有价值。如果某个专家模型对其答案置信度很低调度器可以将其结果权重降低或触发另一个模型进行验证。在结果合成阶段可以基于置信度对多个答案进行加权融合而不是简单拼接。 实现自我评估可以通过在提示词中要求模型输出“Confidence: X%”或者训练一个额外的轻量级“验证器”模型来评估输出质量。5.3 系统的持续进化从发现到创造“LLMs Improving LLMs”的终极愿景可能不仅仅是动态发现现有模型而是能够创造新的解决方案。1. 基于反馈的在线学习系统收集的用户反馈和交互数据不仅可以用于更新模型的能力评分还可以用于微调调度策略将每次请求的上下文用户问题、调度决策、最终结果质量作为训练数据用来微调调度智能体如果它是一个可微调的模型或者训练一个独立的“策略网络”使其决策越来越准。发现模型盲区持续分析那些被所有现有模型都处理不好低置信度、负反馈的问题类型。这些数据可以指导我们收集特定数据去训练或微调新的专家模型从而扩充能力目录。2. 智能体组合的自动化探索当前调度智能体的“发现”是基于预定义的能力目录。未来系统可以自动探索模型智能体之间的组合模式。例如通过强化学习让调度器尝试不同的模型组合顺序和交互方式如让模型A的输出作为模型B的提示词的一部分并评估最终效果从而发现人类未曾想到的高效协作模式。3. 走向真正的“Test-Time Scaling”最终的理想状态是系统在推理时Test-Time不仅能横向扩展调用更多模型还能纵向扩展动态调整单个模型的推理深度或方法。例如对于一个难题系统可以决定让某个模型进行“Chain-of-Thought”式深度推理而对于简单问题则使用快速生成模式。这需要更细粒度的模型能力控制和更灵活的调度机制。构建这样一个系统绝非一日之功它需要算法、工程、产品三方面的紧密合作。从今天的一个简单原型开始逐步迭代解决一个个具体的挑战我们就能向着让大模型在服务中自我进化、越用越聪明的目标稳步前进。这条路充满挑战但也正是其魅力所在。