Глава 8

Используйте router для ограниченной классификации

Router выбирает подходящего исполнителя, но не обязан становиться долговременным собеседником или универсальным supervisor. Он хорошо работает, когда категории различимы: billing, technical support, fraud; frontend, backend, infrastructure; public docs, internal knowledge, repository search. И самый дешёвый надёжный classifier должен стоять первым: exact rule, metadata, small model, и только затем более дорогой fallback.

TypeScript
import type { AgentId, TaskKind, WorkItem } from "./types.js";

const ROUTES: Readonly<Record<TaskKind, AgentId>> = {
  plan: "planner",
  test: "tester",
  security: "security",
  docs: "docs",
  review: "reviewer"
};

export function routeTask(task: WorkItem): AgentId {
  return ROUTES[task.kind];
}

export function explainRoute(task: WorkItem): string {
  return `${task.kind} -> ${routeTask(task)} by deterministic policy`;
}

Варианты router и их главный риск удобно держать перед глазами.

Вариант · Когда подходит · Главный риск

  • Rule-based - Категория уже есть в input или определяется точным условием; Правила разрастаются без owner
  • Model classifier - Нужна смысловая классификация короткого input; Нестабильный route без confidence policy
  • Fan-out router - Один запрос содержит независимые домены; Дублирование context и лишние workers

LangChain документирует router как отдельный dispatch step, который может вызвать несколько agents параллельно, а затем синтезировать outputs. В отличие от supervisor, router обычно не поддерживает долгую историю и не решает многократно, что делать дальше.

Не доверяйте confidence как разрешению. Самооценка модели не является security boundary. Низкая уверенность может отправить задачу на human triage, но высокая уверенность не должна расширять права выбранного worker.

Router распределил вход. Когда же одному владельцу нужно собрать нескольких экспертов и отвечать за итог - финальный ответ оставляют у manager.

Ссылки