大模型服务新范式：Agentic Discovery实现推理时动态协同与性能扩展-Seo优化-塔城地区网站建设公司

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, model="llama3.1:8b", endpoint="http://localhost:11434/api/generate"): """调用Ollama模型的通用函数""" async with httpx.AsyncClient(timeout=30.0) as client: payload = { "model": model, "prompt": prompt, "stream": False, "options": {"temperature": 0.1} # 低温度保证输出稳定 } try: resp = await client.post(endpoint, json=payload) 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_summary=capability_summary, user_query=user_query ) # 3. 调用调度模型获取规划 print("调度智能体思考中...") plan_json_str = await call_llm(prompt, model="llama3.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_exceptions=True) 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, model=model_id, endpoint=endpoint) return response if response else f"模型 {model_id} 无响应" async def fallback_to_general_model(query): """后备方案：直接使用通用模型""" print("启用后备方案，使用通用模型...") answer = await call_llm(f"请回答以下问题：{query}", model="qwen2.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(title="Agentic 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_code=500, detail=f"处理请求时出错: {str(e)}") if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

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”式深度推理，而对于简单问题则使用快速生成模式。这需要更细粒度的模型能力控制和更灵活的调度机制。

构建这样一个系统绝非一日之功，它需要算法、工程、产品三方面的紧密合作。从今天的一个简单原型开始，逐步迭代，解决一个个具体的挑战，我们就能向着让大模型在服务中自我进化、越用越聪明的目标稳步前进。这条路充满挑战，但也正是其魅力所在。