TaoCoder 3.0.1 и 3.1.0: от автономных агентов к вероятностным решениям

AI-агенты для кодинга перешли из разряда «автодополнение» в разряд «автономные работники». Но автономность без контроля — это хаос. В версиях 3.0.1 и 3.1.0 мы в THINKING•OS AI Lab решили две фундаментальные проблемы: как агент работает по расписанию без участия человека и как он принимает решения в условиях неопределённости. Результат — 1000+ шагов без потери контекста, вероятностная модель принятия решений JEV и компактная архитектура промптов.

Проблема: агент живёт только в чате и не умеет принимать решения

Большинство AI-агентов для разработки (Cursor, Copilot, Claude Code в базовом режиме) работают в синхронном режиме: ты пишешь промпт → агент отвечает → ты закрываешь чат. Это удобно для разовых задач, но не работает для системных.

Две ключевые проблемы:

1. Агент исчезает, когда закрываешь IDE. Для разовых задач нормально. Для системных — неприемлемо. Примеры задач, которые требуют автономности:

   • Ежечасная проверка состояния продакшен-сервера
   • Ежедневный аудит качества кода в репозитории
   • Автоматическое устранение найденных проблем
   • Регулярная публикация статей в блоге и социальных сетях
   • Еженедельный сбор новостей отрасли и подготовка дайджеста

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

Для таких задач нужен агент, который:

1. Работает по расписанию (cron)
2. Переключается между специализированными модами
3. Выстраивает цепочки задач (handoff)
4. Принимает вероятностные решения на основе контекста
5. Работает автономно, без участия человека

Версия 3.0.1: автономность и глубокое запоминание

Версия 3.0.1 (2026-10-11) сфокусирована на автономной работе агента и решении проблемы контекста.

TAO·MODES: декларативная конфигурация агента

TAO·MODES — это механизм кастомных модов платформы TaoCoder. Границы, инструменты, стадии и критерии выхода описаны в JSON-файлах. Агент не «угадывает», что делать — он следует формальной спецификации.

Ключевой принцип: мод — это универсальный конструктор под любую задачу. Вы создаёте мод под свой конкретный сценарий: от узкой задачи (проверка одного эндпоинта) до широкой (полный цикл разработки фичи).

Структура кастомного мода:

.taocoder/modes/<mode_id>/
├── mode.json              # Конфигурация мода
└── stages/
    └── <stage_id>.json    # Конфигурация стадии

mode.json определяет:

• id — уникальный идентификатор мода
• name — название для интерфейса
• description — описание для пользователя
• system_prompt — системный промпт агента
• stages[] — список стадий
• extends — наследование от другого мода

stage.json определяет:

• id — идентификатор стадии
• stage_prompt — промпт для этой стадии
• allowed_tools[] — какие инструменты доступны
• forbidden_tools[] — какие инструменты заблокированы
• default_exit_criteria[] — критерии перехода на следующую стадию
• hooks[] — хуки для бизнес-логики

Пример: мод для мониторинга сервера

{
  "id": "server_monitor",
  "name": "Server Monitor",
  "description": "Ежечасовая проверка состояния продакшен-сервера",
  "system_prompt": "Ты — ops-агент. Проверяй состояние сервера и логируй проблемы.",
  "stages": [
    {
      "id": "check_health",
      "stage_prompt": "Проверь CPU, RAM, disk usage. Если что-то выше 80% — создай таск.",
      "allowed_tools": ["execute_command", "read_file", "write_to_file"],
      "default_exit_criteria": [
        {
          "checkType": "all_metrics_below_threshold",
          "threshold": 80
        }
      ]
    }
  ]
}

Агент в этом моде:

• Имеет доступ только к execute_command, read_file, write_to_file
• Не может писать код или менять конфигурацию (нет apply_patch)
• Не может общаться с пользователем (нет ask_followup_question)
• Работает автономно, если запущен по расписанию

Стадии не обязаны быть линейными. Агент может:

• Возвращаться к предыдущей стадии — если на стадии тестирования обнаружил проблему
• Циклически выполнять стадии — например, «написать тест → запустить → исправить → запустить снова»
• Пропускать стадии — если критерии выхода уже выполнены

Система планирования: агент по расписанию

TaoCoder имеет встроенный локальный планировщик, который работает в VS Code extension host. Это не серверный механизм — планировщик работает локально, без зависимости от облака.

Хранение расписаний:

.taocoder/schedules.json

Каждое рабочее пространство имеет свой schedules.json. Расписания не синхронизируются между проектами.

Модель расписания:

interface Schedule {
  schedule_id: string              // UUID
  task_template: {
    mode_id: string                // встроенный или кастомный мод
    role_mode: string              // developer, architect, ops, debug
    spec: string                   // спецификация задачи
    constraints: string[]          // ограничения
  }
  recurrence: RecurrencePattern
  next_run: string                 // ISO 8601 UTC
  last_run?: string                // ISO 8601 UTC
  status: "active" | "paused" | "completed" | "cancelled"
  timezone: string                 // часовой пояс IANA
}

interface RecurrencePattern {
  type: "simple" | "cron" | "custom"
  pattern: string | { interval_ms: number } | { cron: string }
}

Механизм запуска:

1. setInterval с проверкой каждую минуту (60 000 мс)
2. Если next_run <= now → триггер выполнения
3. Создаётся новый task_id (не переиспользуется существующий)
4. Шаблон задачи клонируется в новый контекст
5. После выполнения вычисляется следующий next_run

Ключевой принцип: каждое запланированное выполнение создаёт новую задачу. Это означает:

• Контекст задачи не раздувается от предыдущих запусков
• Каждая задача изолирована — если одна упала, другие не пострадают
• История запусков сохраняется в .taocoder/scheduled_runs/

Автономный режим: работа без участия человека

Когда задача запускается по расписанию, агент получает системное сообщение:

You are running autonomously. Solve the task without user feedback.
If you encounter an issue, attempt to resolve it independently.
Do not ask the user for clarification — proceed with best-effort solution.

Анализатор сбоев: что если агент застрял

Если агент пытается спросить пользователя (использует ask_followup_question), система перехватывает:

1. Автономный ответ: «Продолжай с лучшим решением на основе доступной информации»
2. Агент продолжает выполнение без обратной связи
3. Если агент не продвигается N шагов → эскалация (отмена задачи + уведомление пользователя)

Обнаружение пропущенных запусков

При старте VS Code планировщик проверяет пропущенные запуски:

1. Загружается schedules.json
2. Для каждого status === "active":
   • Если next_run <now → обнаружен пропущенный запуск
3. Пользователю показывается диалог:

Расписание "Blog Writer" пропустило запуск в 2026-10-10T08:00:00Z.
[Запустить сейчас] [Пропустить] [Перенести]

Deep memory architecture: 1000+ шагов без потери контекста

Одна из фундаментальных проблем AI-агентов — неограниченный рост контекста. Когда агент работает долго (сотни шагов), контекст раздувается, токены растут, модель начинает галлюцинировать.

Решение в версии 3.0.1: архитектура глубокой памяти (deep memory architecture), которая позволяет агенту работать 1000+ шагов без потери контекста.

Как это работает:

1. Bounded context — история не накапливается в диалоге, а сжимается во внешний Task Context. Контекст остаётся постоянного размера, токены не растут.
2. Update cycle — каждые N шагов система извлекает ключевую информацию из истории и записывает её в Task Context. История очищается, но знания сохраняются.
3. Knowledge migration — при создании новой задачи знания из предыдущих задач мигрируют в новый контекст. Агент не начинает с нуля.

Результат: агент может работать часами, выполняя сотни шагов, без деградации качества. Контекст остаётся компактным, токены не растут.

Оптимизация под квантованные модели

Версия 3.0.1 добавила поддержку квантованных моделей Qwen 3.6 (35B) и Qwen 3.8 (37B). Это позволяет запускать агента на локальных моделях с минимальными требованиями к железу.

Преимущества квантованных моделей:

• Работают на потребительском железе (16-32 GB RAM)
• Не требуют интернет-соединения
• Нулевая стоимость токенов
• Полная приватность данных

Ограничения:

• Ниже качество по сравнению с frontier-моделями (Claude, GPT-4)
• Медленнее генерация
• Требуют тщательной настройки промптов

Решение: TaoCoder автоматически подбирает модель под задачу. Простые задачи (рефакторинг, тесты) — квантованные модели. Сложные задачи (архитектурный дизайн, code review) — frontier-модели.

Версия 3.1.0: вероятностные решения и безопасность

Версия 3.1.0 (2026-10-19) сфокусирована на контроле действий агента через быстрые вероятностные модели и защите секретов из конфигурационных файлов.

JEV: быстрый «судья» для действий AI-агента

Автономный AI-агент в IDE — это не только «напиши код». Он выполняет команды в терминале, переходит между стадиями задачи, объявляет задачу завершённой. Каждое такое действие хочется проверить до того, как оно что-то сломает:

• rm -rf в терминале — необратим
• Переход на следующую стадию — преждевременен, если критерии не выполнены
• attempt_completion — подозрителен, если тесты не проходили

Очевидное решение — спросить другую большую LLM («LLM-as-a-judge»). Но у него три недостатка: медленно (секунды на каждый запрос), дорого (каждая проверка жжёт токены как полноценный запрос) и недетерминированно (свободный текст ответа приходится парсить и интерпретировать).

В TAO·CODER для этого появился JEV — отдельный класс моделей, созданный специально для быстрых структурированных решений.

JEV — decision-модель класса «System One» от компании TypeSafe AI. Название отсылает к «системе 1» Канемана: быстрая интуитивная оценка — в противовес «системе 2», медленному рассуждению большой LLM.

Ключевые свойства JEV:

Свойство	Значение
Генерация текста	Нет. Модель не пишет ни слова — только структурированные ответы
Что возвращает	Вероятности по типизированным вопросам
Латентность	70–500 мс (на порядки быстрее LLM-судьи)
Контекст	32k токенов
Цена	Только входные токены (≈ $0.042/млн), выход бесплатный
Формат ответов	Детерминированный, удобен для машинной обработки

Три примитива вопросов:

Примитив	Что делает	Ответ
Choice	Выбор из 2–255 вариантов	Вероятность каждого варианта + confidence выбора
Noul	Вероятность истинности утверждения	Число 0–1
Score	Позиция на упорядоченной шкале из 2–10 уровней	Вероятности по уровням + confidence

Механизмы TAO·CODER, построенные на JEV

В TAO·CODER JEV подключён в четырёх точках. Общая философия всех интеграций: JEV даёт вероятности, но никогда не принимает окончательное решение за систему и не блокирует работу при недоступности провайдера.

1. Terminal Guard — надзор за командами терминала

Самая «боевая» интеграция. Каждая команда перед выполнением проходит двухступенчатую классификацию:

1. Локальная политика (бесплатно). Команду классифицирует classifyCommand() — вайтлист безопасных команд (типа ls, npm test) и паттерны опасных. Большая часть команд решается здесь, без единого запроса к модели.
2. JEV — только для unknown. Если локальная политика не распознала команду, она уходит в JEV как noul-вопрос «безопасно ли выполнить эту команду в dev-окружении?».

Дальше — сравнение вероятности с порогом:

• probability ≥ threshold → вердикт safe: команда выполняется
• Вероятность ниже порога → вердикт requires_approval: к запросу апрува пользователю добавляется пояснение с вероятностью и порогом

Дизайн-решение: вайтлист не отправляется в модель — JEV видит только неизвестные команды. Это резко сокращает число запросов и стоимость.

2. taocoder_jev_validate — инструмент самопроверки агента

Агент может сам задать JEV структурированный вопрос через встроенный тул:

• Параметры: question_type (choice | noul | score), instructions, опционально options и state
• В ответ агент получает сырые вероятности без интерпретации — решение, что с ними делать, принимает сам агент

Примеры использования агентом: «выполнились ли критерии выхода стадии?», «какой из трёх вариантов рефакторинга соответствует спецификации?», «уверен ли я, что этот тест покрывает крайний случай?».

3. Хук jev_validate — контроль переходов стадий и завершения задачи

TAO·CODER работает по стадиям. В конфигурации стадии можно объявить хуки, и одно из действий — jev_validate. Хук срабатывает:

• На stage_exit при переходах между стадиями
• При завершении задачи через attempt_completion

Действия хука:

• pass → переход продолжается
• message → сообщение агенту
• ask_human → запрос подтверждения у человека
• cancel → переход стадии блокируется

Пороговая логика: если max(probabilities) <threshold, применяется действие on_below_threshold (по умолчанию ask_human). Это позволяет настроить автоматический запрос подтверждения при низкой уверенности JEV.

4. Fail-open на всех уровнях

Если провайдер недоступен, истёк таймаут или ответ не распарсился — проверка пропускается с логированием. Агент никогда не блокируется из-за внешнего сервиса: «лучше без судьи, чем стоящий агент».

REST API Server: встроенные подключения без MCP

Версия 3.1.0 добавила встроенный REST API Server, который позволяет агенту подключаться к внешним API без использования MCP (Model Context Protocol).

Как это работает:

1. Пользователь создаёт конфигурацию REST API подключения:

{
  "id": "github_api",
  "name": "GitHub API",
  "base_url": "https://api.github.com",
  "auth": {
    "type": "bearer",
    "token_env": "GITHUB_TOKEN"
  },
  "endpoints": [
    {
      "name": "list_repos",
      "method": "GET",
      "path": "/user/repos",
      "params": {
        "per_page": 100
      }
    }
  ]
}

2. Агент использует инструмент rest_api_call для вызова API:

const repos = await rest_api_call({
  connection_id: "github_api",
  endpoint: "list_repos"
});

3. TaoCoder автоматически добавляет заголовки авторизации, обрабатывает ошибки и возвращает результат.

Преимущества REST API Server:

• Не требует MCP — агент работает с API напрямую
• Централизованное управление подключениями
• Автоматическая авторизация через environment variables
• Поддержка любых REST API

Ограничения:

• Только REST API (не GraphQL, не WebSocket)
• Требует предварительной настройки подключений

Автоматическое извлечение секретов из MCP и REST API конфигов

AI-кодовые агенты работают с внешними сервисами через конфигурационные файлы — MCP-серверы и REST API подключения. В этих файлах хранятся API-ключи, токены и другие секреты — в plaintext.

Масштаб проблемы (данные GitGuardian, 2026):

• 29 млн hardcoded секретов в публичных GitHub-коммитах за 2025 год
• ~24 000 секретов найдено в MCP-конфигурационных файлах на публичном GitHub
• Коммиты с AI-ассистентами утекают в 2 раза чаще, чем обычные

Когда разработчик настраивает MCP-сервер или REST API подключение, он вписывает API-ключ прямо в конфиг:

// MCP-сервер (mcp_settings.json)
{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "@my/mcp-server"],
      "env": {
        "API_KEY": "sk-ant-api07-very-secret-key-here"
      }
    }
  }
}

Эти файлы могут попасть в Git, быть прочитаны другим расширением, или просто лежать на диске в открытом виде.

Решение TaoCoder: SecretExtractor

Мы реализовали автоматическое извлечение секретов — первый в индустрии встроенный механизм защиты конфигов на уровне IDE. Механизм работает единообразно для обоих типов подключений: MCP-серверов и REST API.

Как это работает:

Пользователь вводит API-ключ в конфиг (plaintext)
    ↓
SecretExtractor автоматически извлекает значение
    ↓
Ключ сохраняется в VS Code SecretStorage (шифрование на уровне ОС)
    ↓
В конфиге остаётся плейсхолдер: {{SECRET:my-server_env_0}}
    ↓
UI показывает маску: [🔒 my-server_env_0]
    ↓
При выполнении запроса — runtime resolver автоматически подставляет реальное значение
    ↓
Сервер получает реальный ключ и работает нормально

Ключевые свойства:

1. Автоматичность — пользователю не нужно ничего делать. Ввёл ключ → он уже защищён
2. Единый механизм — работает для MCP (env vars) и REST API (headers)
3. Дедупликация — если такое же значение уже сохранено, переиспользуется существующий ключ
4. Безопасное хранение — VS Code SecretStorage использует ОС-уровневое шифрование (Keychain на macOS, DPAPI на Windows)
5. UI-маска — в JSON-редакторе видно [🔒 key_name] вместо реального значения
6. Runtime resolver — при выполнении запроса плейсхолдеры автоматически заменяются на реальные значения
7. Обратная совместимость — существующие plaintext-конфиги автоматически мигрируются при первом подключении
8. Логирование без утечек — в логи попадают только счётчики и имена серверов, никогда — значения секретов

OAuth 2.0 для REST API: безопасная аутентификация без хранения паролей

Помимо API-ключей, TaoCoder поддерживает OAuth 2.0 с PKCE для REST API подключений — современный стандарт аутентификации, который не требует хранить пароль пользователя.

Как работает OAuth в TaoCoder:

Пользователь настраивает REST API с OAuth конфигом
    ↓
TaoCoder генерирует PKCE code_verifier + code_challenge (S256)
    ↓
Открывает браузер с authorization URL + state + code_challenge
    ↓
Пользователь авторизуется на сайте провайдера
    ↓
Провайдер редиректит на callback с authorization code
    ↓
TaoCoder обменивает code + code_verifier на access_token
    ↓
Токены сохраняются в SecretStorage (ОС-шифрование)
    ↓
При каждом запросе — токен автоматически подставляется в Authorization header
    ↓
При истечении — автоматический refresh через refresh_token

Ключевые свойства OAuth реализации:

1. PKCE (Proof Key for Code Exchange) — защита от interception attacks. Генерируется криптографический code_verifier (32 байта), его SHA-256 хеш отправляется как code_challenge
2. State parameter — защита от CSRF. Случайный 32-байтовый state проверяется при callback
3. Автоматический refresh — при истечении access_token система автоматически использует refresh_token для получения нового
4. Безопасное хранение — все токены хранятся в SecretStorage, никогда не попадают в конфиг или логи
5. Изоляция по серверу — каждый REST API сервер имеет свой набор токенов, идентифицируемый по SHA-256 хешу имени+URL

Архитектура промптов: компактный kernel prompt

Версия 3.1.0 оптимизировала архитектуру промптов. TaoCoder использует компактный kernel prompt — системный промпт сжат до минимального размера без потери смысла.

Как это работает:

1. Промпт разбивается на части:

   • Системный промпт (не меняется)
   • Task Context (меняется редко)
   • История (меняется часто)

2. TaoCoder оптимизирует порядок частей:

   • Системный промпт — всегда в начале
   • Task Context — после системного промпта
   • История — в конце

3. Kernel prompt сжат до минимального размера — только необходимая информация, без воды.

Результат:

• Промпт сам по себе маленький и остаётся маленьким
• Снижение стоимости токенов за счёт компактности
• Ускорение генерации

Технические детали:

interface PromptArchitecture {
  system_prompt: string;      // Компактный kernel prompt
  task_context: string;       // Task Context (bounded)
  history: string[];          // История
  current_request: string;    // Текущий запрос
}

Новый дизайн чата: боковая панель

Версия 3.1.0 представила новый дизайн чата в виде sidebar panel. Теперь агент работает в боковой панели, а не в отдельном окне.

Преимущества:

• Агент всегда виден при работе с кодом
• Не нужно переключаться между окнами
• Удобно для многозадачности

Пользовательские заметки к задачам

Версия 3.1.0 добавила возможность добавлять пользовательские заметки к задачам. Заметки сохраняются в Task Context и доступны пользователю для самого себя — агент их не видит.

Как это работает:

1. Пользователь добавляет заметку через UI
2. Заметка сохраняется в Task Context задачи
3. Пользователь может вернуться к заметке позже, посмотреть историю своих мыслей

Преимущества:

• Пользователь может фиксировать свои мысли и решения
• Заметки сохраняются между сессиями
• Удобно для ведения логов работы над задачей

Оптимизация памяти: 10+ параллельных сессий

Версия 3.1.0 оптимизировала управление памятью, что позволяет запускать 10+ concurrent sessions без деградации производительности.

Как это работает:

1. Каждая сессия изолирована — имеет свой Task Context
2. Сессии не делят память — каждая сессия использует свою память
3. TaoCoder автоматически управляет памятью:
   • Выгружает неактивные сессии
   • Загружает активные сессии по требованию
   • Оптимизирует использование RAM

Результат:

• 10+ concurrent sessions без деградации
• Автоматическое управление памятью
• Изоляция сессий — если одна сессия упала, другие не пострадали

Сравнение версий: что изменилось

Механизм	Версия 3.0.1	Версия 3.1.0
TAO·MODES	✅ Кастомные моды	✅ Улучшена документация
Scheduled Execution	✅ Cron-based scheduling	✅ Улучшена обработка пропущенных запусков
Deep Memory	✅ 1000+ steps	✅ Оптимизирована
Quantized Models	✅ Qwen 3.6/3.8	✅ Добавлена поддержка новых моделей
JEV Decision Model	❌	✅ Быстрый «судья» для действий агента
REST API Server	❌	✅ Встроенные подключения
SecretExtractor	❌	✅ Автоматическое извлечение секретов
OAuth 2.0	❌	✅ Безопасная аутентификация
Prompt Architecture	❌	✅ Компактный kernel prompt
New Chat Design	❌	✅ Sidebar panel
User Notes	❌	✅ Пользовательские заметки
Memory Optimization	❌	✅ 10+ concurrent sessions

Тренды индустрии 2026: как TaoCoder попадает в мейнстрим

Версии 3.0.1 и 3.1.0 TaoCoder попадают во все ключевые тренды AI coding agents 2026:

1. Persistent project context — агенты хранят долгосрочную память проекта. TaoCoder решает это через Task Context и deep memory architecture.

2. Multi-agent architectures — оркестрация специализированных агентов. TaoCoder реализует это через TAO·MODES и handoff между модами.

3. Autonomous execution — агенты работают минутами/часами как background jobs. TaoCoder обеспечивает это через scheduled execution и автономный режим.

4. MCP как стандарт подключения — TaoCoder поддерживает MCP, а также добавляет REST API Server для работы без MCP.

5. IDE+CLI+cloud трёхслойный стек — TaoCoder работает в VS Code (IDE), поддерживает CLI-команды и может интегрироваться с облачными сервисами.

6. Tool definitions consume context — проблема стоимости и латентности. TaoCoder решает это через role modes (−30–50% токенов) и компактную архитектуру промптов.

Дифференциаторы TaoCoder vs конкуренты

Ось	TaoCoder	Конкуренты (Cline, Kilo, Continue, Cursor)
Память	Structured external memory (Task Context Kernel)	Растущий chat history
Контроль	Role modes с stage-gated execution	Write access по умолчанию
Стоимость	Оптимизация под flash models (10-30x дешевле)	Frontier models (дорого)
Долгие задачи	1000+ steps без потери контекста	Деградация после 100-200 steps
Параллелизм	Parallel task execution с per-task isolation	Одиночные сессии
Миграция знаний	Knowledge migration между задачами	Нет миграции
Кастомизация	Custom role modes для non-coding workflows	Только для кода

Что дальше

Мы продолжаем развивать TaoCoder. В планах:

• Серверное планирование — для платных функций, cron-выдача токенов запуска
• Оркестрация множества агентов — координация нескольких агентов
• Самоисцеляющийся CI/CD — автономные агенты для автоматического исправления ошибок в конвейере
• Расширение экосистемы модов — готовые моды для типовых задач
• Интеграция с облачными LLM — поддержка новых провайдеров

Заключение

Версии 3.0.1 и 3.1.0 TaoCoder — это не просто обновления. Это фундаментальные изменения в том, как AI-агент работает с задачами, принимает решения и управляет контекстом.

Ключевые результаты:

• Агент работает по расписанию и выстраивает цепочки задач
• Агент принимает вероятностные решения на основе контекста
• Агент работает 1000+ шагов без потери контекста
• Стоимость enterprise-проекта: $30–50 на flash-моделях
• 1 разработчик с TaoCoder = команда из 3–5 при 1/10 стоимости

Если вам нужны AI-агенты, которые работают автономно, принимают решения и масштабируются — напишите нам. Мы поможем настроить систему под ваши задачи.

---

Ссылки:

• Кастомные моды и планировщик: как AI-агент работает по расписанию
• Bounded Task Context: как AI-агент работает в пределах задачи
• Гайд по TaoCoder: платформа для автономной разработки
• Экономика TaoCoder: сколько стоит AI-разработка

Контакты:

• Telegram: @thinkingos
• Email: info@thinkingos.tech
• Телефон: +7 (906) 950-66-95