Ну так можно в AGENTS.md указать всё что вы выше в комменте описали, типа подожди комментов от coderabbit, субагентов дёрни команду /check-coderabbit-comments итп. У вас всё это съест 1% от контекста, зато без своих агентов...
~400 лидов в месяц, 70% из которых вообще не целевые. И на которые 4 менеджера тратили почти весь рабочий день.
Чего они там обрабатывают такого, что всего 4 лида в день переваривали? Судя по агенту - и человек такие лиды разберет за мгновенье...
70% нецелевых запросов никуда не делись. Только теперь их отсекает агент. Не понятно... Что стоило человеку глянуть на лид и отсечь его за те же 10 секунд?
Попробуйте MTP модели — multi token predictions, в 2-3 раза быстрее скорость генерации ответа. А для мака есть MTP+MLX = MTPLX :D ищите прям в названиях моделей такую строчку.
Спасибо за статью, несколько мыслей по теме — возможно, пригодится читателям, которые захотят копнуть глубже.
Про XML vs JSON
Рекомендации Google и Anthropic по использованию XML-тегов в промптах — это реальность, и статья верно подмечает тренд. Но стоит уточнить контекст: речь идёт именно о структурировании самого промпта (разделение инструкций, контекста, примеров), а не о том, что JSON «плох» для LLM в принципе. На практике они решают разные задачи:
XML/Markdown-теги — для разметки секций промпта. Anthropic прямо пишет: «Structure prompts with XML tags» для сложных составных промптов.
JSON — для машинного обмена: API, structured outputs, схемы валидации. Его место на границе системы.
Неплохой глубокий разбор форматов для промптов есть у MightyBot (Best Structured Prompt Formats for LLMs) — они ставят XML-теги на 4-е место как инструмент разметки секций, а не как универсальный формат данных. Их рекомендация: compact input → JSON output → JSON на границах системы.
Что касается конкретных цифр (15%, 30%, 99.5%) — я не смог найти исходное исследование OpenAI с такими результатами. Было бы здорово, если автор добавит ссылку на первоисточник, чтобы читатели могли оценить методологию самостоятельно. В открытых публикациях, которые я встречал, разрыв между форматами меньше и сильно зависит от модели, задачи и типа данных.
Про семантическую и якорную разметку
Статья называет это «большим открытием», но мне кажется, стоит развести эти понятия, потому что они решают разные задачи и в агентной разработке оба важны.
Семантическая разметка — это когда каждому фрагменту контекста присваивается смысловое описание: что этот блок делает, какую роль играет, как относится к другим блокам. Пример:
<agent_role name="document_validator">
<scope>Проверка PDF на соответствие стандартам IFRS</scope>
<input_format>PDF invoice</input_format>
<output_format>JSON checklist with rule references</output_format>
</agent_role>
Здесь теги не просто разделяют текст — они описывают смысл каждого блока. Модель знает, что перед ней не просто текст, а описание роли, области действия, форматов входа/выхода. Это помогает attention-механизму корректно взвешивать релевантность каждого фрагмента.
Зачем нужно: без семантической разметки модель видит плоский текст и сама должна догадаться, где инструкция, а где данные. С разметкой — она получает явные сигналы о смысле каждого блока, что критично при длинном контексте.
Якорная разметка — это фиксированные точки привязки, которые позволяют агенту точно вернуться к нужному месту, передать ссылку другому агенту или структурировать навигацию. Пример:
Здесь якоря ANCHOR: invoice_header и ANCHOR: payment_terms — это закладки. Агент может сказать: «в секции sec_payment_terms найдено нарушение» — и другой агент (или человек) точно знает, о каком месте речь.
Зачем нужно: при агентной разработке, особенно multi-agent системах, якоря — это «координатная система». Без них агенты не могут точно сослаться на конкретный фрагмент документа или кода, и коммуникация деградирует до «там в середине что-то не так».
Разница в одном предложении: семантическая разметка говорит «что это», якорная — «где это». XML-теги <instructions>, <context>, <examples> из статьи — это одновременно и то, и другое, но в простейшей форме.
Итого
Направление статьи верное — структурирование контекста через разметку действительно один из ключевых навыков при работе с LLM.
Добавлю только три уточнения:
XML vs JSON — не «или-или», а «каждый для своей задачи»
Цифры по точности лучше проверять по первоисточникам
Семантическая и якорная разметка — отдельные инструменты, каждый со своей зоной ответственности
Ну так можно в AGENTS.md указать всё что вы выше в комменте описали, типа подожди комментов от coderabbit, субагентов дёрни команду /check-coderabbit-comments итп. У вас всё это съест 1% от контекста, зато без своих агентов...
а как же AGENTS.md?
TLDR
откатитесь до TLS 1.2 и HTTP/2
Чтоб получить признание — надо чтоб кто-то признавал всё же. А кто будет признавать в вашем чат-боте? Не понятна концепция совсем
гусарам на слово не верим же, а то может скиллами обошлось бы "представь что ты девопс" :]
В новом интерфейсе на код взглянуть можно, но это всё идёт как доп опция, отмирающая, на первом плане уже не код, даже в интерфейсе.
Нажечь токенов много ума не надо, а какой КПД..?
READ выполняется чтоб понять — может файл уже отредачил другой агент или ещё кто... Будто 1 строку читать в данном случае — опасно
~400 лидов в месяц, 70% из которых вообще не целевые. И на которые 4 менеджера тратили почти весь рабочий день.Чего они там обрабатывают такого, что всего 4 лида в день переваривали? Судя по агенту - и человек такие лиды разберет за мгновенье...
70% нецелевых запросов никуда не делись. Только теперь их отсекает агент.Не понятно... Что стоило человеку глянуть на лид и отсечь его за те же 10 секунд?
Не понятно, чем /plan хуже?
Как раз к этому интерфейсу все эволюционируют, как бы показывая, что набирать код — это уже не так востребовано, как писать обвязки и ТЗ :]
Будто чуваки переусложнили всё. Да, выглядит круто... Но будто оверинжиниринг.
Насколько ещё актуальны подобные задачи в 2026? Или уже чем-то другим фильтруются кандидаты?
Не понял чем хуже — отправить документ в привычную нейруху?
chore: regenerate SDK v1.0.0Борьба с билдом первой версии в коммитах позабавила :D
Офигеть сколько автосборка документации экономит человеческого времени...
На момент написания статьи актуальной была версия Claude Code 2.1.100. А поддержка Windows появилась сравнительно недавно — меньше года назадБро! Так сам клод вышел чуть больше года назад :D
За статью лайк.
Попробуйте MTP модели — multi token predictions, в 2-3 раза быстрее скорость генерации ответа. А для мака есть MTP+MLX = MTPLX :D ищите прям в названиях моделей такую строчку.
Спасибо за статью, несколько мыслей по теме — возможно, пригодится читателям, которые захотят копнуть глубже.
Про XML vs JSON
Рекомендации Google и Anthropic по использованию XML-тегов в промптах — это реальность, и статья верно подмечает тренд. Но стоит уточнить контекст: речь идёт именно о структурировании самого промпта (разделение инструкций, контекста, примеров), а не о том, что JSON «плох» для LLM в принципе. На практике они решают разные задачи:
XML/Markdown-теги — для разметки секций промпта. Anthropic прямо пишет: «Structure prompts with XML tags» для сложных составных промптов.
JSON — для машинного обмена: API, structured outputs, схемы валидации. Его место на границе системы.
Неплохой глубокий разбор форматов для промптов есть у MightyBot (Best Structured Prompt Formats for LLMs) — они ставят XML-теги на 4-е место как инструмент разметки секций, а не как универсальный формат данных. Их рекомендация: compact input → JSON output → JSON на границах системы.
Что касается конкретных цифр (15%, 30%, 99.5%) — я не смог найти исходное исследование OpenAI с такими результатами. Было бы здорово, если автор добавит ссылку на первоисточник, чтобы читатели могли оценить методологию самостоятельно. В открытых публикациях, которые я встречал, разрыв между форматами меньше и сильно зависит от модели, задачи и типа данных.
Про семантическую и якорную разметку
Статья называет это «большим открытием», но мне кажется, стоит развести эти понятия, потому что они решают разные задачи и в агентной разработке оба важны.
Семантическая разметка — это когда каждому фрагменту контекста присваивается смысловое описание: что этот блок делает, какую роль играет, как относится к другим блокам. Пример:
Здесь теги не просто разделяют текст — они описывают смысл каждого блока. Модель знает, что перед ней не просто текст, а описание роли, области действия, форматов входа/выхода. Это помогает attention-механизму корректно взвешивать релевантность каждого фрагмента.
Зачем нужно: без семантической разметки модель видит плоский текст и сама должна догадаться, где инструкция, а где данные. С разметкой — она получает явные сигналы о смысле каждого блока, что критично при длинном контексте.
Якорная разметка — это фиксированные точки привязки, которые позволяют агенту точно вернуться к нужному месту, передать ссылку другому агенту или структурировать навигацию. Пример:
Здесь якоря ANCHOR: invoice_header и ANCHOR: payment_terms — это закладки. Агент может сказать: «в секции sec_payment_terms найдено нарушение» — и другой агент (или человек) точно знает, о каком месте речь.
Зачем нужно: при агентной разработке, особенно multi-agent системах, якоря — это «координатная система». Без них агенты не могут точно сослаться на конкретный фрагмент документа или кода, и коммуникация деградирует до «там в середине что-то не так».
Разница в одном предложении: семантическая разметка говорит «что это», якорная — «где это». XML-теги
<instructions>, <context>, <examples>из статьи — это одновременно и то, и другое, но в простейшей форме.Итого
Направление статьи верное — структурирование контекста через разметку действительно один из ключевых навыков при работе с LLM.
Добавлю только три уточнения:
XML vs JSON — не «или-или», а «каждый для своей задачи»
Цифры по точности лучше проверять по первоисточникам
Семантическая и якорная разметка — отдельные инструменты, каждый со своей зоной ответственности
Подробнее по ссылке www.elijahmanor.com/2013/01/the-magic-of-jquery-source-map.html
страничка получилась как на скрине с IE