Идея простая: вместо того чтобы каждый раз вручную копировать задачу в чат с агентом, вы держите обычный список дел, где часть пунктов помечена как «Агенту». Агент (Claude Code, OpenCode или другой клиент с поддержкой MCP) подключается к вашему задачнику через MCP-сервер, забирает подходящие пункты, выполняет их на вашей машине и дописывает отчёт прямо в задачу. Дальше вы утром открываете список и видите не «сделано/не сделано», а что именно произошло: какие файлы изменены, какие команды запущены, где агент остановился.

Это не замена планировщику и не «автономный сотрудник». Это способ убрать ручной перенос контекста. Ценность в том, что задача, её история и результат живут в одном месте, а не расползаются по чатам, терминалам и заметкам.

Из чего состоит схема

Минимальный набор компонентов выглядит так:

  • Задачник — любой инструмент с API или файловым хранилищем, где есть поля: описание, статус, метка, отчёт. Подойдёт даже набор Markdown-файлов в git.
  • MCP-сервер — прослойка, которая даёт агенту ограниченный набор операций: «получить задачи с меткой», «обновить статус», «дописать отчёт».
  • Клиент-агент — Claude Code или OpenCode, запущенный на вашей машине с доступом к нужной директории.
  • Триггер — ручной запуск или расписание (cron, systemd timer, планировщик ОС).

Ключевое решение — не давать агенту прямой доступ к базе задачника. MCP-сервер выступает фильтром: он отдаёт только то, что помечено, и принимает только те поля, которые вы разрешили менять. Это дешевле, чем потом разбираться, почему агент переписал чужие задачи.

Как настроить доступ и запуск

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

Дальше опишите контракт MCP-сервера. Достаточно четырёх инструментов:

  • list_tasks — вернуть задачи с меткой «Агенту» и статусом «готова».
  • claim_task — пометить задачу как «в работе», чтобы два прогона не взяли одно и то же.
  • append_report — дописать текст отчёта, не затирая предыдущий.
  • set_status — перевести в «сделано», «нужна помощь» или «ошибка».

Запуск по расписанию настраивается поверх этого: cron или таймер раз в час вызывает клиент с промптом вроде «возьми одну задачу и выполни её, отчёт запиши в задачу». Ограничьте прогон по времени и по количеству задач за раз — иначе один зависший пункт заблокирует очередь.

Что агенту можно, а что нет

Границы полномочий — самая важная часть. Практичный стартовый набор: агенту разрешено читать и менять файлы только в выделенной директории проекта, запускать команды из белого списка (тесты, линтеры, сборка), создавать ветку git, но не пушить в основную. Всё, что касается денег, публикаций, отправки писем и удаления данных, — только с подтверждением человека.

Типичные ошибки здесь предсказуемы. Первая — дать агенту полный доступ к домашней директории «на время эксперимента». Вторая — разрешить произвольные shell-команды без ограничений. Третья — не разделять задачи на «можно автоматически» и «только вручную». Четвёртая — запускать прогоны без лимита по времени и без лога, из-за чего непонятно, что именно произошло.

Хороший приём — статус «нужна помощь». Если агенту не хватает данных или он упирается в неоднозначность, он не гадает, а пишет в задачу вопрос и останавливается. Вы отвечаете в том же поле, и следующий прогон продолжает с этого места. Это дешевле, чем разбирать полуготовые изменения.

Как выбрать инструмент и не переусложнить

Критерии простые. Смотрите на наличие MCP-поддержки у клиента, на возможность ограничить набор инструментов и на то, где хранится токен. Если задачник умеет API — берите его; если нет, начните с файлов в git: история изменений и diff уже дают аудит. Для расписания хватит системного планировщика, отдельный оркестратор на старте не нужен.

Пример из практики: задача «обновить зависимости в проекте» помечена «Агенту». Прогон запускается ночью, агент создаёт ветку, обновляет пакеты, гоняет тесты и дописывает в задачу отчёт: какие версии изменились, что упало. Утром вы читаете отчёт и решаете, мержить или нет. Задача «позвонить в банк» остаётся без метки — её агент не увидит.

Начните с одной-двух безопасных задач и одного прогона в день. Когда увидите, что отчёты читаемы, а границы соблюдаются, расширяйте список. Схема работает не потому, что агент умный, а потому что очередь, права и отчёты описаны явно.