隐形编排器：低成本路由 + 高成本推理 于多代理应用

I’m happy to translate the article for you, but I need the full text of the post in order to do so. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide a Simplified‑Chinese version while preserving the original formatting and the source line at the top.

问题概述

我们构建了 SamiWISE，一款 GMAT 备考导师，使用四个专职 AI 代理：

每个代理都有自己的系统提示、专属 Pinecone 命名空间以及独特的推理风格。
挑战在于：在不增加明显延迟的情况下，将每条用户消息路由到正确的专员。

将每条消息都通过 GPT‑4o 来决定路由会导致 800–1,200 ms 的延迟，首个 token 出现前的等待时间过长——这在响应体验至关重要的辅导应用中是不可接受的。

初始路由尝试

// First attempt — routing via GPT‑4o
const routingResponse = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    {
      role: "system",
      content: `You are a routing agent. Given a user message, return ONLY a JSON object:
{"agent": "quant" | "verbal" | "data_insights" | "strategy"}
No explanation. No other text.`,
    },
    { role: "user", content: userMessage },
  ],
  response_format: { type: "json_object" },
});

const { agent } = JSON.parse(routingResponse.choices[0].message.content!);
// then call the specialist...

问题

1. 延迟 – GPT‑4o 仅返回一个微小的 JSON 负载就需要 400–1,200 毫秒。
2. 成本 – 每条用户消息都会产生两次 LLM 调用（路由器 + 专家），使每条消息的 AI 成本增加约 35%。
3. 过度设计 – 路由器只需输出四个标记中的一个；前沿推理能力是多余的。

切换到更快的模型

我们将 GPT‑4o 路由器替换为运行 llama-3.3-70b-versatile 的 Groq。提示词和 JSON 输出格式保持不变，但中位路由延迟从 ≈850 ms 降至 ≈55 ms。

// lib/openai/client.ts
import Groq from "groq-sdk";

export const groq = new Groq({
  apiKey: process.env.GROQ_API_KEY,
});

路由实现

// agents/gmat/orchestrator.ts — routing call
async function routeToAgent(
  userMessage: string,
  conversationContext: string
): Promise<string> {
  const response = await groq.chat.completions.create({
    model: "llama-3.3-70b-versatile",
    messages: [
      {
        role: "system",
        content: `Route the user message to one specialist agent.
Return ONLY valid JSON: {"agent": "quant" | "verbal" | "data_insights" | "strategy"}

Routing rules:
- quant: arithmetic, algebra, geometry, word problems, number properties
- verbal: reading comprehension, critical reasoning, sentence correction  
- data_insights: table analysis, multi-source reasoning, two-part analysis
- strategy: timing, test-taking approach, score targets, study plan questions

Context (last 2 messages):
${conversationContext}`,
      },
      { role: "user", content: userMessage },
    ],
    response_format: { type: "json_object" },
    temperature: 0,      // deterministic routing
    max_tokens: 20,      // safeguard against extra text
  });

  const result = JSON.parse(response.choices[0].message.content!);

  // Validate result; fall back to "quant" if unexpected
  const valid = ["quant", "verbal", "data_insights", "strategy"] as const;
  return valid.includes(result.agent) ? result.agent : "quant";
}

专科代理仍然使用带完整流式输出的 GPT‑4o。由于路由调用在约 55 ms 内完成，用户在收到第一个流式 token 之前不会感知到任何间隙。

编排流程

// agents/gmat/orchestrator.ts — simplified main flow
export async function handleMessage(
  userMessage: string,
  userId: string,
  stream: ReadableStreamDefaultController
) {
  // 1. Build routing context from last 2 messages (~5 ms, local)
  const context = await getRecentContext(userId);

  // 2. Route via Groq — fast, cheap, deterministic (~55 ms)
  const agentType = await routeToAgent(userMessage, context);

  // 3. Load specialist config and RAG context in parallel
  const [agentConfig, ragContext] = await Promise.all([
    getAgentConfig(agentType),
    fetchRAGContext(userMessage, agentType), // hits the right Pinecone namespace
  ]);

  // 4. Stream response from GPT‑4o specialist
  await streamSpecialistResponse(
    userMessage,
    agentConfig,
    ragContext,
    userId,
    stream
  );
}

步骤 3 和 4 与路由调用的处理时间重叠，因此从用户提交到可见字符的 实际首 token 延迟 大约为 ≈900 ms。

关键参数

结果与观察

• 错误率 – Groq 的 llama 模型仅在边缘案例中误路由 3 %，而 GPT‑4o‑mini 为 8 %。
• 速度 – 中位路由延迟为 55 ms，而使用 GPT‑4o 为 850 ms。
• 成本 – 使用 Groq 进行路由每次调用成本显著更低，降低了整体每条消息的 AI 成本。
• 确定性 – 温度设为 0 被证明是必需的；即使稍微提升到 0.2，也会随时间出现路由漂移。

路由/推理的划分是一种 模式，而非 hack。它可以在任何先进行廉价、快速分类、随后进行昂贵生成响应的场景中复用（例如意图检测、表单字段提取）。

接下来

• 置信度评分 – 返回置信度指标，并在不确定时回退到澄清问题。
• 上下文感知路由 – 在多轮对话中更重视最近的话题。
• 路由分析 – 跟踪用户重新提问或纠正错误路由的响应，以随时间改进路由提示。

讨论问题

• 在多代理系统中，你如何处理路由？是使用单独的模型，还是通过函数调用依赖主 LLM？
• 有没有人对其他快速推理提供商（Cerebras、Together、Fireworks）与 Groq 在结构化路由任务上的基准进行比较？
• 当路由置信度较低时，你是让用户澄清，还是进行最佳猜测并在错误时让他们重新指引？