Блог • AI / Agent
AI Coding Agent — это уже не только автодополнение: за что соревнуются Codex, Claude Code, OpenCode и DeepSeek Harness?
Два года назад «ИИ пишет код» чаще всего означало подсказку следующей строки в редакторе. В 2026 в терминале крутится другой класс продуктов: Codex, Claude Code, OpenCode, DeepSeek Harness — они правят файлы, гоняют тесты, вызывают MCP и могут запускать Subagents для параллельного разбора.
Снаружи все четверо продают один и тот же набор: LLM + инструменты + Agent loop. Настоящее поле битвы — не чеклист функций, а архитектурный центр: кто усиливает Agent, кто держит границы исполнения, кто ставит на независимость от модели, кто делает сам runtime заменяемой деталью.
В этой статье разберём:
- Что именно Coding Agent добавляет сверх автодополнения
- Какую ключевую проблему оптимизирует каждый из четырёх
- Архитектурные различия Claude Code / Codex / OpenCode / DeepSeek Harness
- Карту контроля: что решают модель, runtime, политика и человек
- Почему JSON Schema и контракты инструментов всё ещё общий фундамент и как проверять их локально в JSONNote
Одной фразой:Выполнить задачу ≈ модель × Harness × задача. Четверо сравнивают не «у кого больше тумблеров», а где лежит контроль — Claude Code усиливает единого Agent, Codex держит песочницу и одобрения, OpenCode ставит на смену моделей, DeepSeek Harness делает loop и возможности плагинами.
За что на самом деле идёт борьба
Автодополнение отвечает на «что написать в следующей строке». Coding Agent отвечает на «как довести эту цель до конца в реальном репозитории»: прочитать контекст, выбрать инструменты, править код, запускать команды, смотреть результат, снова решать.
Нижний цикл почти одинаков:
User goal
→ Agent loop
→ LLM decides next action
→ Tool / environment executes
→ Result returns to context
→ Agent decides againМодель отвечает за рассуждение и следующий шаг; harness решает, что она видит, какие инструменты доступны, что инструменты реально делают, как сохраняется состояние, какие действия требуют одобрения и что считать завершением задачи. Даже сильная модель падает, если контекст дырявый, контракт инструментов слабый, права слишком широки или сбои невосстановимы.
Поэтому конкуренция 2026 — уже не только «у кого выше бенчмарк», а «кто яснее организует интеллект, исполнение, политику, инструменты и контроль человека». Сборку из четырёх слоёв см.:
Стек AI Agent 2026: LLM, MCP, Function Calling, JSON Schema
Четыре архитектурных центра
Сначала границы. Чеклисты функций будут всё больше похожи, но центральный вопрос разный:
| Продукт | Архитектурный центр | Ключевой вопрос |
|---|---|---|
| Claude Code | Claude Agent | Как сделать главного Agent сильнее и удобнее? |
| Codex | Agent + runtime исполнения | Как Agent автономно действует на реальной машине и при этом не выходит из-под контроля? |
| OpenCode | Harness, независимый от модели | Как дать пользователю свободно менять модели и провайдеров без вендор-лока? |
| DeepSeek Harness | Компонуемый runtime | Можно ли модели, инструменты, loop и песочницу заменять и пересобирать как плагины? |
Последняя строка — не рейтинг, а продуктовая граница: вы покупаете «более сильного помощника», «более контролируемую среду исполнения» или «расширяемую платформу Agent».
Claude Code: центр на Agent
Claude Code лучше понимать как продукт вокруг главного Agent. Skills, MCP, Subagents, Hooks, права — всё это делает того же Claude Agent эффективнее, а не распиливает сам Agent loop на заменяемое ядро.
Типичные точки расширения:
- CLAUDE.md: контекст и договорённости на уровне проекта
- Skills: переиспользуемые пакеты опыта и workflow
- MCP: подключение внешних систем
- Subagents: изоляция специализированных подзадач и их контекста
- Hooks / Permissions: детерминированные правила на жизненном цикле
Инженерный компромисс ясен: вероятностный Agent + детерминированные Hooks. Запуск тестов после правок, перехват опасных команд, предварительное одобрение защищённых путей — на это нельзя рассчитывать, что модель «каждый раз вспомнит».
Подходит: ясным workflow, командам, которым важны опыт и качество контекста, расширяющим главный цикл через Skills и Subagents.
Codex: центр на исполнении
Codex (включая Codex CLI) сдвигает вопрос на слой исполнения: как только Agent может править файлы, запускать shell, ставить зависимости, трогать сеть и credentials, нужно ответить на два разных вопроса — границы возможностей и текущее разрешение.
Два механизма, разные роли:
| Механизм | На какой вопрос отвечает |
|---|---|
| Sandbox | К чему технически можно получить доступ / что изменить? |
| Approval / Policy | Разрешено ли делать это сейчас? |
Принцип — минимизация возможностей: не давать сначала полный доступ и просить «быть осторожнее», а сначала сузить среду и расширять по необходимости. CLI на Rust, дефолт у endpoints OpenAI и сильный нарратив песочницы — всё это в линии «Agent должен работать на реальном компьютере».
Подходит: высокорисковые побочные эффекты, аудируемые трассы исполнения, сценарии, где одобрение и изоляция — граждане первого класса. Open-source репозиторий:
OpenCode: независимость от модели
Дифференциация OpenCode не в «ещё одном синтаксисе Skills», а в дефолтной позиции: модель заменяема. MIT open source, terminal-first, поддержка множества провайдеров и локальных моделей (например Ollama / LM Studio). Гибкость в основном на слое конфигурации — providers, models, permissions, themes — а не в разборе ядра harness на шину плагинов.
Отсюда практичный продуктовый вывод: если вы не доверяете вендор-локу или в одной сессии нужно переключаться между моделями разных поставщиков, центральный вопрос OpenCode — «как не быть привязанным к поставщику модели».
Обычно выигрывает в:
- Мультимодели / мультипровайдеры как дефолтная возможность
- Open-source лицензия и сообщество
- «Сменить модель» как операция первого класса, а не бонус вендора
Цена: границы исполнения и глубина плагинов не обязательно аргумент №1. Вы покупаете harness со сменяемыми моделями, а не самый тяжёлый sandbox-продукт и не платформенное ядро «Everything is a plugin».
DeepSeek Harness: центр на runtime
DeepSeek Harness (dsh) двигает вопрос ещё глубже: а если сам Agent Loop не должен быть вечным ядром? Слоган публичного превью — Everything is a plugin: модели, инструменты, skills, сессии, песочница, хранилище, loop, планировщик, UI — всё заменяемо.
Это не «стабильное ядро + периферийные точки расширения». Граница сдвигается внутрь: механизм, который ведёт Agent, тоже можно пересобрать. Capability seam заставляет потребителей опираться на контракт, а не на одну реализацию: локальный shell и контейнерный shell, удалённая модель и локальный инференс, ReAct loop и workflow loop — провайдера можно сменить, не переписывая все инструменты.
Поэтому это ближе к платформе:
- Coding Agent: цикл ReAct
- Workflow Agent: workflow + Agent
- Долгие задачи: цель + планировщик + Job
- Гетерогенные Subagents: вплоть до бэкендов других продуктов
Компонуемость стоит дороже: поверхность понятий Plugin / Service / Provider / Effect / Session шире. Конечному пользователю терминала, которому «просто нужно, чтобы репозиторий поправили», кривая обучения может быть выше, чем у Claude Code или Codex; команде, строящей расширяемую платформу Agent, это как раз продающий аргумент.
Если вас больше интересуют API моделей DeepSeek и JSON-вывод, начните с:
DeepSeek V4-Pro: полный разбор
Карта контроля
Полезнее галочек функций — спросить, кому принадлежит каждое решение. Таблица ниже сжимает стили контроля четырёх (OpenCode и dsh близки по «заменяемости», но разной глубины):
| Измерение | Центр на Agent | Центр на исполнении | Заменяемость |
|---|---|---|---|
| Представитель | Claude Code | Codex | dsh / OpenCode |
| Главная оптимизация | Возможности и опыт | Безопасное автономное исполнение | Смена модели / возможностей |
| Agent loop | Явный центр | Явный центр | Заменяемая конфигурация / заменяемые плагины |
| Средства безопасности | Hooks + права | Песочница + одобрение + политика | Политика конфигурации / runtime-политика и события |
| Лучшее соответствие | Специализированный продукт Agent | Agent, работающий с реальными системами | Мультимодельные пользователи / расширяемая платформа |
Ещё на слой ниже: понимание задачи и генерация плана ближе к модели; проверка параметров, оценка прав, исполнение инструментов, остановка выполнения — ближе к программам и политикам; высокорисковые действия всё ещё требуют человека. Все четверо покрывают эти слова, но кладут вес на разные клетки.
JSON-контракт всё ещё общий фундамент
Какой harness вы ни выберете, вызов инструмента в итоге сводится к машиночитаемой структуре: имя функции + параметры JSON. MCP inputSchema / outputSchema, parameters у Function Calling, response_format у Structured Output — нижний язык всё ещё JSON Schema.
Где появляется контракт:
| Этап | Типичная форма | Что ограничивает |
|---|---|---|
| Модель выбирает инструмент | Function Calling / tools | JSON Schema |
| Протокол внешних инструментов | MCP / Apps | inputSchema / outputSchema |
| Проверка перед исполнением | Runtime validate | Недостающие поля, неверные типы, грязные параметры |
| Траектория и аудит | tool call / result JSON | Структурированные события для разбора |
Классический сбой: parameters на стороне модели и MCP inputSchema написаны отдельно, поля или enum разъезжаются — кажется, что «модель вечно плохо вызывает инструмент». Исправление: один контракт, два места монтирования. Фон:
Зачем ИИ нужен JSON Schema и JSON Schema для AI Agent: полный разбор.
{
"name": "run_tests",
"description": "Run the project test suite and return a structured summary.",
"parameters": {
"type": "object",
"properties": {
"suite": { "type": "string", "enum": ["unit", "integration", "e2e"] },
"path": { "type": "string", "minLength": 1 }
},
"required": ["suite"],
"additionalProperties": false
}
}Отлаживая этот путь, всё можно сделать локально в браузере, без загрузки данных:
-
1
Отформатировать arguments
Вставьте строку arguments от модели в Формат JSON, сначала убедитесь, что это валидный JSON.
-
2
Сверить со Schema
Через JSON Schema проверьте required, enum, additionalProperties.
-
3
Сравнить дрейф
parameters на стороне модели и MCP inputSchema через JSON Diff — совпадают ли поля.
Как выбирать
Выбирайте по ограничениям, а не по хайпу:
- Ясный workflow, сильный опыт и Skills: скорее Claude Code
- Большие побочные эффекты на реальной машине, нужны песочница и одобрения: скорее Codex
- Мультимодели, антилок-ин, приоритет open source: скорее OpenCode
- Строить расширяемую платформу Agent, сменяемый loop: скорее DeepSeek Harness
Можно комбинировать: например OpenCode / dsh для мультимодельных экспериментов, прод-побочные эффекты — за границами в духе Codex; или главный цикл на Claude Code, внешние системы через MCP. Главное — не делать «оценку модели» единственным критерием закупки.
Частые вопросы
В чём принципиальная разница между AI Coding Agent и автодополнением кода?
Автодополнение предлагает только следующую строку; Coding Agent читает репозиторий, правит файлы, запускает команды, вызывает инструменты и в цикле продолжает решения по результатам. Конкуренция смещается с «качества генерации» на «границы исполнения и контроль runtime».
Кто лучше — Codex, Claude Code, OpenCode или DeepSeek Harness?
Единого чемпиона нет. Смотрите, что оптимизируете: опыт и Skills — Claude Code; песочница и одобрения — Codex; мультимодели и антилок-ин — OpenCode; заменяемый runtime и платформа — DeepSeek Harness.
DeepSeek Harness и OpenCode оба open source — в чём разница?
Гибкость OpenCode в основном в конфигурации моделей и провайдеров; DeepSeek Harness (dsh) делает модели, инструменты, loop, песочницу, сессии и т.д. заменяемыми плагинами — ближе к компонуемой платформе Agent runtime.
Зачем всё ещё говорить про JSON Schema?
Параметры инструментов, MCP inputSchema/outputSchema, Structured Output в основе — это JSON Schema. Каким бы сильным ни был harness, грязные параметры на слое исполнения всё равно ломают систему — проверка контракта остаётся обязанностью Runtime.
На какой слой смотреть в первую очередь при выборе Agent?
Смотрите на контроль: кто выбирает инструменты, кто валидирует параметры, кто одобряет высокорисковые действия, кто завершает задачу. Оценка модели — лишь один вход; harness решает, можно ли безопасно довести задачу до конца.
Итог
Codex, Claude Code, OpenCode и DeepSeek Harness делят один словарь: LLM, инструменты, loop, контекст, Skills, Subagents, права, песочница. Это уже не «лучшее автодополнение» — они спорят о точке контроля.
Claude Code усиливает одного Agent; Codex даёт Agent контролируемо действовать в реальной среде; OpenCode ставит на смену моделей; DeepSeek Harness делает runtime и возможности компонуемой платформой.
Важный вопрос уже не «как вызвать модель», а «как организовать интеллект, исполнение, политику, инструменты, контекст и контроль человека». JSON на слое контракта инструментов — по-прежнему тот слой, который можно сверить локально.
Отладить JSON инструментов Agent? Локально в браузере.