AI-ассистент: Гриша

Модель

• Тип: API (через OpenRouter)
• Базовая модель: qwen/qwen3.5-397b-a17b (OpenAI-совместимый endpoint https://openrouter.ai/api/v1)
• Среднее время ответа: около 5 секунд

Персона

Гриша — завуч-куратор по учёбе. Сухой, спокойный, цепкий, чуть саркастичный. Не пытается быть «помощником», работает как тренер: не сюсюкает, не отпускает, но и не давит. Чёрный список фраз (Чем могу помочь, Я — языковая модель и прочая стандартная вода) прошит в SOUL.md — он эти конструкции не использует ни при каких условиях. На «ты», без эмодзи, без преамбул.

Скилл — «Планировщик учёбы»

• Что делает: ведёт список учебных дедлайнов, фиксирует выполненные/просроченные/перенесённые, ведёт журнал учебных сессий (минуты по курсам), раз в день шлёт утренний дайджест (что сегодня + просрочки) и вечерний пинг (что закрыл), раз в неделю — статистику и обзор недели.
• Какие tools использует: exec (вызов deadlines.py и progress_log.py), read_file, append_file, edit_file, cron (три повторяющихся задания), message, web (по запросу). Состояние — в workspace/study/deadlines.json (атомарная запись) и workspace/study/progress.md (append-only лог).
• Как это работает (flow):
  1. Пользователь пишет в Telegram → сообщение прилетает в gateway → triggerит turn агента.
  2. Гриша по AGENT.md определяет, что делать: добавить дедлайн / закрыть / показать список / залогировать сессию.
  3. Вызывает exec python3 ~/.picoclaw/workspace/scripts/deadlines.py <cmd> — скрипт атомарно меняет JSON и возвращает структурированный ответ.
  4. Дописывает строку в progress.md через append_file.
  5. Формулирует ответ человеку, опираясь на actual JSON-ответ скрипта, а не на «представление» о состоянии.
  6. Параллельно: cron (PicoClaw'овский) три раза в день/неделю триггерит дополнительный turn с заданным сообщением — Гриша читает state и сам формулирует дайджест, не шаблонной строкой.

Что было непросто

• Настройка PicoClaw. На старте была путаница с конфигами (структура model_list, разнесение секретов в .security.yml, формат channel_list.telegram), но всё поправилось довольно быстро. Главный вывод: лучше один раз вдумчиво почитать документацию и поправить руками, чем просить агента угадывать — экономит время.
• Изначально планировал YandexGPT, но PicoClaw нативно его не поддерживает, а через openai-совместимый прокси возникала возня с заголовками и форматом model. В итоге переключился на OpenRouter + qwen3.5-397b-a17b — настройка элементарная, заголовки стандартные, никаких прокси.
• Формат ответов в Telegram. Хочется аккуратно отрисовывать таблицы и markdown (особенно для утреннего дайджеста и недельной статистики), но небольшой ресёрч не дал готового рецепта — use_markdown_v2 помогает частично, таблицы всё равно ломаются. Открытый пункт на будущее.
• Расход токенов. По мониторингу видно, что модель жрёт очень много — на дебаг и подготовку демо-диалогов ушло ~600k токенов, хотя задачи и tool calls тривиальные. Подозреваю thinking-режим / большие system-промпты из workspace. Стоит: отключить thinking по умолчанию, попробовать модели поменьше для рутинных turn'ов, или резать контекст агрессивнее.
• Дисциплина персоны. Гриша в текущем состоянии не всегда держится своей роли — может ввязаться в сторонние темы, хотя по AGENT.md должен быть только планировщиком. Нужно либо ужесточать SOUL.md / AGENT.md явными запретами, либо добавлять hook-перехватчик, который заворачивает off-topic обратно к скиллу.
• Инвариант state. На первых прогонах модель пыталась редактировать deadlines.json напрямую через write_file — короче, ей удобнее. Пришлось явно в AGENT.md запретить и оставить единственный путь через deadlines.py, иначе ломается схема и next_id.

Вывод

В целом — полезно. Агент реально снимает часть когнитивной нагрузки: дедлайны не нужно держать в голове, а утренний/вечерний пинг помогает не упускать просрочки. Автоматизация небесполезная, пользоваться буду.

Что добавил бы:

1. Больше каналов для автоматического сбора дедлайнов — почта и общие телеграм-группы курсов. Парсить их в фоне и предлагать «нашёл дедлайн, добавить?». Трудозатраты низкие.
2. Интеграция со SmartLMS — технически сложнее, скорее всего придётся писать собственный MCP-сервер с авторизацией. Это убрало бы ручной ввод почти полностью, однако, из всех моих курсов там отсутствует какая либо информация.
3. Телеметрия использования модели — какие turn'ы / какие tools жрут больше всего токенов. Без этого непонятно где экономить.
4. Превращение в сервис на нескольких пользователей — тогда нужны полноценная авторизация и разграничение workspace'ов. Это уже не ДЗ, а отдельный продукт, но идея ровно сюда же ложится.

Примеры диалогов

1. Добавление + просмотр + закрытие дедлайна (полный цикл tool calls; после команд deadlines.json и progress.md реально изменились).
2. Утренний дайджест от cron (TBD).
3. Лог сессии + недельная статистика.
4. web search

---

Бонусы (что я делал сверх базы)

• Cron-автоматизация — три повторяющихся задания (утро, вечер, воскресенье).
• State между сессиями через файлы — deadlines.json (атомарно, через tmp + rename) + progress.md (append-only), переживают рестарт PicoClaw.
• Документация дизайн-решений — см. HSE_INTEGRATION_IDEAS.md (карта направлений: расписание ruz.hse.ru, SmartLMS через MCP, аналитика по логу).
• Heartbeat-задача — мягкое напоминание по high-priority дедлайнам за ≤6 часов, без спама (rate-limit по progress.md).