Mission Control для Coding Agents: Единый опыт в VS Code

Emiliano Montesdeoca — Fri, 07 Aug 2026 00:00:00 +0000

Этот пост был автоматически переведен. Чтобы посмотреть оригинальную версию, нажмите здесь.

Mission Control для Coding Agents: Единый опыт в VS Code

Один coding assistant легко понять. Несколько agents, работающих в разных местах — это уже не так.

Один agent работает локально в VS Code. Другой работает над GitHub issue в облаке. CLI agent живет в терминале. Сторонний coding agent может иметь другую модель сессии и другие ограничения. Без единого представления разработчики тратят больше времени на отслеживание работы, чем на ее надзор.

Единый agent experience в VS Code решает эту проблему координации с помощью Agent Sessions: одно место для запуска agents, просмотра их статуса, открытия их диалогов и вмешательства, когда план меняется.

Это скорее не о добавлении еще одного agent, а о том, чтобы сделать несколько agents управляемыми.

Один вид для разных видов работы

Исходная статья описывает четырех участников: локальный GitHub Copilot, Copilot Coding Agent в облаке, GitHub Copilot CLI и OpenAI Codex для участников Copilot.

У каждого есть свои преимущества:

Локальный agent может проверить текущее рабочее пространство и быстро внести изменения.
Cloud coding agent может работать асинхронно над issue и открыть pull request.
CLI agent подходит для workflows, основанных на терминале, и операционных команд.
Другой поставщик может предложить другую модель или стиль рассуждений.

Agent Sessions придает этим задачам общий дом. Вы можете увидеть, что работает, что оно делает и где продолжить диалог.

Эта видимость важна, потому что автономная работа не устраняет координацию. Она делает координацию первоклассной инженерной задачей.

Прерывания — часть workflow

Исходный материал делает простое наблюдение: «Обычно вы отправляете prompt и понимаете, что забыли что-то важное». Раньше выбор часто стоял между ожиданием или отменой. С chat editors вы можете открыть активную сессию и добавить информацию, пока agent работает.

Это больше похоже на реальное сотрудничество. Требования меняются. Тест выявляет предположение. Рецензент замечает, что API должен оставаться обратно совместимым. Полезный agent — это не тот, который никогда не нуждается в исправлении; это тот, который может усвоить исправление, не теряя всю задачу.

Для .NET-работы прерывание может быть простым:

Keep the existing public route unchanged. Add the new behavior behind the application service,
use the existing ProblemDetails convention, and add a test for the old response shape.

Инструкция краткая, потому что репозиторий уже несет в себе более крупный контекст. Сессия — это место для корректировки направления, а не для повторения всей системы.

Пользовательские Agents превращают командные привычки в роли

VS Code также представляет специализированные agents, такие как Plan. Вместо немедленной реализации agent-планировщик задает вопросы об объеме, компонентах, библиотеках и ограничениях перед созданием спецификации реализации.

Этот паттерн полезен за пределами встроенного agent. Команда может определить сосредоточенные роли:

Research собирает доказательства и пишет короткую запись решения.
Review проверяет изменение в соответствии с соглашениями репозитория.
Testing выявляет отсутствующие случаи и предлагает план тестирования.
Architecture сравнивает варианты без изменения файлов.

Определение небольшого пользовательского agent может выглядеть так:

type: agent
name: plan
description: "Refines vague requests into clear implementation specs"
prompt: |
 Ask about scope, constraints, existing patterns, and edge cases.
 Produce a concise specification before any implementation begins.

Полезная часть — это не YAML. Это явное разделение ответственности. Planning agent не должен тихо редактировать production code. Review agent не должен переписывать дизайн, который он должен оценивать.

Subagents снижают столкновения контекста

Длинные диалоги накапливают посторонний контекст. Subagents предоставляют изолированное рабочее пространство для ограниченной исследовательской задачи, затем возвращают результат в основную сессию.

Это хороший вариант для вопросов типа:

Analyze the API project and recommend an authentication strategy.
Return trade-offs and a decision record. Do not edit files.

Основной agent остается сосредоточенным на реализации, в то время как research agent занимается более узким вопросом. Тот же принцип применяется к командам: четкое делегирование дает лучшие результаты, чем запуск нескольких agents с перекрывающейся компетенцией.

Оговорка: больше Agents означает больше координации

Agent Sessions может показать активность, но не может решить конфликтующее владение. Два agents, редактирующих одну область, все еще могут создать проблему merge. Cloud agent и локальный agent могут делать несовместимые предположения. Пользовательский agent может дать рекомендацию, которую другой agent игнорирует.

Установите границы:

Один agent владеет реализацией для данной ветки.
Research agents возвращают артефакты, а не отслеживаемые правки.
Pull requests остаются границей для проверки.
Имена agent и prompts указывают, что они могут изменять.
Выходные данные сессии сохраняются, когда они объясняют важное решение.

Мое мнение

Будущее с несколькими agents — это не очередь окон chat. Это небольшая команда с ролями, передачей и ответственностью.

Agent Sessions ценны, потому что они признают эту реальность. Они предоставляют разработчикам поверхность управления для работы, которая уже происходит в редакторе, терминале и облаке. Следующий прирост производительности будет обусловлен не наличием большего количества agents, а тем, что их границы будут более ясными.

Для .NET-команды я бы начал с одного agent-планировщика и одного agent-реализатора. Используйте выходные данные planning как спецификацию issue или pull request, затем позвольте agent реализации работать в этой границе. Измеряйте переделку перед добавлением новых ролей.

Лучший mission control — это тот, который делает владение очевидным.

Codex | The .NET Blog

Mission Control для Coding Agents: Единый опыт в VS Code

Mission Control для Coding Agents: Единый опыт в VS Code

Один вид для разных видов работы

Прерывания — часть workflow

Пользовательские Agents превращают командные привычки в роли

Subagents снижают столкновения контекста

Оговорка: больше Agents означает больше координации

Мое мнение