Инженерное лидерство

В multi-agent системе нужно определить, кто: ставит задачи; определяет приоритет; разрешает конфликты; принимает результат; управляет зависимостями; перераспределяет ресурсы; прекращает работу.

Каждое решение расходует: tokens; API calls; search; compute; wall-clock time; человеческое внимание. Появляется понятие: Cost of autonomy Например: Task value:

Очень часто ответ: никогда. Если один агент может выполнить задачу, создавать семь персонажей: Researcher; Planner; Critic; Manager; Writer; Supervisor; Supreme

Пример разделения ролей: Research Agent ↓ Evidence ↓ Analysis Agent ↓ Hypothesis ↓ Verification Agent Разделение имеет смысл, если существуют

Когда агент должен позвать человека? Не «если не уверен» — это слишком примитивно. А когда дальнейшее решение требует полномочий, которых

Агент должен различать хотя бы: Execution failure Инструмент сломался. Knowledge failure Не хватает информации. Planning failure Выбран неправильный путь. Requirement

Распространённая ловушка: Agent creates answer ↓ Agent asks LLM: "Is this answer correct?" ↓ LLM: "Yes." 🎩🐇 Это не контроль.

Очень важное различение: conversation ≠ state Состояние может выглядеть так: { "goal": "…", "status": "researching", "completed": [], "blocked": [], "risks":

Главный вопрос: Как узнать, что агент хороший? Не «мне понравился результат», а создать набор ситуаций. Например, 100 кейсов. Для каждого: