Available now! Telegram Research 2025 — the year's key insights 
SQL Portal | Базы Данных
Open in Telegram
Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных Связь: @devmangx РКН: https://clck.ru/3H4Wo3
Show more📈 Analytical overview of Telegram channel SQL Portal | Базы Данных
Channel SQL Portal | Базы Данных (@sqlportal) is an active participant. Currently, the community unites 14 159 subscribers, ranking 9 118 in the Technologies & Applications category and 47 146 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 14 159 subscribers.
According to the latest data from 09 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -141 over the last 30 days and by -5 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 8.91%. Within the first 24 hours after publication, content typically collects 5.22% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 262 views. Within the first day, a publication typically gains 739 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 4.
- Thematic interests: Content is focused on key topics such as строка, sql, индекс, postgres, колонка.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных
Связь: @devmangx
РКН: https://clck.ru/3H4Wo3”
Thanks to the high frequency of updates (latest data received on 10 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
14 159
Subscribers
-524 hours
-237 days
-14130 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
June '26
June '26
+13
in 2 channels
May '26
+45
in 1 channels
Get PRO
April '26
+33
in 0 channels
Get PRO
March '26
+116
in 1 channels
Get PRO
February '26
+77
in 0 channels
Get PRO
January '26
+65
in 0 channels
Get PRO
December '25
+327
in 8 channels
Get PRO
November '25
+1 089
in 318 channels
Get PRO
October '25
+76
in 0 channels
Get PRO
September '25
+76
in 0 channels
Get PRO
August '25
+100
in 0 channels
Get PRO
July '25
+1 881
in 267 channels
Get PRO
June '25
+489
in 1 channels
Get PRO
May '25
+287
in 1 channels
Get PRO
April '25
+939
in 1 channels
Get PRO
March '25
+994
in 0 channels
Get PRO
February '25
+750
in 0 channels
Get PRO
January '25
+1 163
in 0 channels
Get PRO
December '24
+1 753
in 405 channels
Get PRO
November '24
+1 137
in 170 channels
Get PRO
October '24
+1 973
in 286 channels
Get PRO
September '24
+1 504
in 282 channels
Get PRO
August '24
+3 285
in 234 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 10 June | +1 | |||
| 09 June | 0 | |||
| 08 June | +1 | |||
| 07 June | +1 | |||
| 06 June | 0 | |||
| 05 June | +2 | |||
| 04 June | +3 | |||
| 03 June | +1 | |||
| 02 June | +2 | |||
| 01 June | +2 |
Channel Posts
PostgreSQL защищает «горячие» данные от вытеснения во время больших последовательных сканирований с помощью Sequential Scan Ring Buffer.
В этом посте посмотрим, сколько раз можно употребить термин
shared_buffers... поехали.
Без Sequential Scan Ring Buffer один запрос вида SELECT * FROM large_table загрузил бы все страницы большой таблицы в shared_buffers, вытеснив всё, что уже находилось в кеше. Один «холодный» аналитический запрос мог бы полностью разрушить рабочий набор данных всех остальных сессий.
Что такое ring buffer?
Когда PostgreSQL обнаруживает большое последовательное сканирование, он переключается на стратегию ring buffer: временное циклическое окно, выделенное внутри shared_buffers.
По мере выполнения сканирования страницы проходят через этот буфер по кругу и сразу становятся кандидатами на вытеснение после использования. Благодаря этому основной кеш остаётся изолированным.
Размер ring buffer зависит от типа операции:
Большие последовательные сканирования — базовый размер составляет 32 страницы (256 КБ), но в PostgreSQL 17+ может немного увеличиваться для асинхронного ввода-вывода.
VACUUM — по умолчанию 256 страниц (2 МБ), начиная с PostgreSQL 16. Настраивается через vacuum_buffer_usage_limit.
COPY и другие операции массовой записи — 2048 страниц (16 МБ).
Срабатывает при 25% от shared_buffers
Порог рассчитывается как: shared_buffers / 4
Если размер сканируемой таблицы превышает четверть shared_buffers, PostgreSQL использует стратегию ring buffer.
Для операций обслуживания действуют отдельные правила. Размер ring buffer для VACUUM задаётся параметром vacuum_buffer_usage_limit, но PostgreSQL автоматически ограничивает этот буфер значением не более 1/8 от размера shared_buffers.
Что это означает на практике. Данные приложения защищены от вытеснения большими сканированиями. Если рабочий набор помещается в shared_buffers, он останется в кеше даже при запуске крупного последовательного сканирования.
Результаты последовательного сканирования таблиц, размер которых превышает shared_buffers, не будут сохраняться в кеше PostgreSQL. При этом повторные чтения всё ещё могут обслуживаться из page cache операционной системы без обращения к физическому диску.
Каждый параллельный воркер, выполняющий последовательное сканирование, использует собственный ring buffer. Это увеличивает пропускную способность больших сканирований и одновременно защищает основной пул буферов.
Таблицы, размер которых находится чуть ниже порога в 25% от shared_buffers, всё ещё могут вызывать вытеснение данных из кеша.
👉 @SQLPortal| 2 | VIEW (представления)
🧠 Что такое VIEW?
VIEW — это виртуальная таблица, построенная на основе SQL-запроса.
Данные в ней не хранятся
Хранится только запрос
Проще говоря:
VIEW = сохранённый SQL-запрос, который можно использовать как таблицу
Зачем нужны VIEW?
- упрощают сложные запросы
- позволяют переиспользовать логику
- помогают скрывать чувствительные данные
- делают SQL-код понятнее
Создание VIEW
CREATE VIEW high_salary_emp AS
SELECT name, salary
FROM employees
WHERE salary > 50000;
Использование VIEW
SELECT * FROM high_salary_emp;
Работает почти так же, как обычная таблица.
Обновление VIEW
CREATE OR REPLACE VIEW high_salary_emp AS
SELECT name, salary, department
FROM employees
WHERE salary > 50000;
Удаление VIEW
DROP VIEW high_salary_emp;
Практический пример
Создадим представление со средней зарплатой по отделам:
CREATE VIEW dept_avg_salary AS
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;
Использование:
SELECT * FROM dept_avg_salary;
Важные моменты
VIEW не хранит данные
изменения в исходной таблице сразу отражаются в VIEW
VIEW можно использовать в запросах как обычную таблицу
Практика
Создайте VIEW для сотрудников с зарплатой выше 40 000
Создайте VIEW для сотрудников отдела IT
Создайте VIEW со средней зарплатой по отделам
Выполните запросы к созданным VIEW
Удалите одно из представлений
Решения
1. Сотрудники с зарплатой выше 40 000
CREATE VIEW high_salary_emp AS
SELECT *
FROM employees
WHERE salary > 40000;
2. Сотрудники отдела IT
CREATE VIEW it_employees AS
SELECT *
FROM employees
WHERE department = 'IT';
3. Средняя зарплата по отделам
CREATE VIEW dept_avg_salary AS
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;
4. Запросы к представлениям
SELECT * FROM high_salary_emp;
SELECT * FROM it_employees;
SELECT * FROM dept_avg_salary;
5. Удаление представления
DROP VIEW high_salary_emp;
Мини-задача
Создайте VIEW, который показывает 3 сотрудников с самой высокой зарплатой.
Решение
CREATE VIEW top_3_salary AS
SELECT *
FROM employees
ORDER BY salary DESC
LIMIT 3;
Использование:
SELECT * FROM top_3_salary;
Где VIEW используют чаще всего?
- дашборды
- системы отчётности
- аналитические проекты
Потому что представления позволяют скрыть сложную SQL-логику за простым запросом.
Таблица хранит данные.
VIEW хранит запрос.
👉 @SQLPortal | 509 |
| 3 |  +2«Но ведь запрос был быстрым на dev и staging!»
Какие признаки говорят о том, что запрос работает быстро локально, но в production потребует отдельного внимания к производительности?
Есть две точки, после которых простой запрос начинает заметно замедляться:
Сортировка перестаёт помещаться в память.
Сканирование таблицы начинает читать данные с диска.
Примеры ниже показаны на небольших стендах с ограниченными ресурсами. В крупных системах картина будет такой же, только с гораздо большим количеством строк.
Простой запрос:
SELECT user_id, event_type, created_at
FROM events
WHERE user_id = 1
ORDER BY created_at DESC
Без индекса PostgreSQL приходится сканировать всю таблицу, чтобы найти события пользователя, даже если нужных строк совсем немного.
(Небольшая оговорка: если для пользователя нет ни одной строки, PostgreSQL может решить вообще не сканировать таблицу, используя статистику по таблице и колонкам.)
Фаза 1. Всё помещается в память
Таблица содержит 10 000 строк.
Для user_id = 1 найдено 5 000 событий.
work_mem = 1MB.
Что видно ((фото1):
Sort Method: quicksort Memory: 427kB
Все 5 000 строк были отсортированы прямо в RAM.
Rows Removed by Filter: 5000
PostgreSQL всё равно прочитал остальные 5 000 строк и отбросил их.
Buffers: shared hit=74
Все страницы уже находились в памяти (shared_buffers).
Фаза 2. Сортировка начинает писать на диск
Теперь в таблице 200 000 строк.
У пользователя уже 100 000 событий.
work_mem всё ещё равен 1 MB.
Что изменилось (2):
Sort Method: external merge Disk: 3352kB
Сортировка больше не помещается в память и начинает использовать временные файлы.
temp read=836 written=843
PostgreSQL записал 843 временные страницы на диск и затем прочитал их обратно во время merge-фазы.
Rows Removed by Filter: 100000
Ещё 100 тысяч строк были прочитаны только для того, чтобы потом их выбросить.
Фаза 3. Таблица перестаёт помещаться в буферный кеш
Всего уже 600 000 строк.
Из них 100 000 принадлежат нужному пользователю, остальные 500 000 — другим пользователям.
PostgreSQL всё равно вынужден читать их.
Размер таблицы становится больше shared_buffers.
(3 фото)
Планировщик запустил 2 параллельных воркера.
Сканирование и сортировка были распределены между 3 процессами, поэтому каждый сортировал примерно по 33 000 строк вместо 100 000.
Но основные проблемы остались:
shared read=3049
Таблица перестала помещаться в буферный кеш. Более 3 000 страниц пришлось читать с диска.
Rows Removed by Filter: 166667 × 3
Было прочитано и выброшено около 500 тысяч строк.
Все три сортировки всё равно использовали external merge
Параллелизм уменьшил объём работы на каждый процесс, но не убрал запись на диск.
Решение зависит от конкретного приложения.
Самый очевидный вариант:
CREATE INDEX idx_events_user_created_at
ON events (user_id, created_at DESC);
Такой индекс позволяет резко сократить объём сортировки и избежать полного сканирования таблицы.
Но индекс далеко не единственный вариант.
В зависимости от нагрузки могут помочь:
- кэширование на уровне приложения;
- materialized views;
- партиционирование таблиц;
- изменение модели хранения данных.
Главный вывод простой:
Если в EXPLAIN ANALYZE появляются:
external merge
temp read / temp written
большие значения Rows Removed by Filter
shared read
то запрос, который отлично работал на dev-базе с 10 тысячами строк, уже начинает показывать, что будет происходить в production на миллионах записей.
👉 @SQLPortal | 682 |
| 4 |  +1Появился /no-mistakes.
По многочисленным просьбам автор вынес один из самых полезных инструментов своего агентного пайплайна в отдельный skill для Claude Code, Codex и других агентных сред.
После того как агент внёс изменения, достаточно выполнить: /no-mistakes
Дальше инструмент автоматически проверит изменения и поможет найти проблемы до коммита.
По словам автора, код, сгенерированный ИИ, даже лучшими моделями, пока нельзя безоговорочно принимать и мержить без тщательной проверки.
Его собственная статистика:
68% изменений содержали проблемы
эти проблемы могли попасть в основную ветку, если бы их не обнаружил no-mistakes
Раньше инструмент запускался только через:
git push no-mistakes
Теперь доступен и как skill.
Исходный код открыт и распространяется бесплатно: https://github.com/kunchenguid/no-mistakes
Для настройки в репозитории:
no-mistakes init
👉 @SQLPortal | 761 |
| 5 |  Начиная с Oracle 21c, массивы PL/SQL можно инициализировать через конструкторы с циклом FOR.
array := arr_type ( FOR i IN ... )
Такие конструкторы позволяют перебирать:
значения — IN x .. y
результат курсора — IN ( SELECT ... )
Для задания собственных индексов можно использовать необязательное выражение INDEX.
👉 @SQLPortal | 760 |
| 6 | Лето начинается: водные развлечения, гриль на острове и новые маршруты в бутик-отеле «Заонежье»
Для гостей бутик-отеля «Заонежье» к новому сезону подготовлены лесные трассы для первых заездов на новых квадроциклах — они позволяют исследовать дикие уголки карельской тайги и скалистые берега озер. Велопрогулки по дорогам Заонежья стали еще комфортнее благодаря электробайкам, которые этой весной пополнили велопарк отеля.
В мае, в отеле открылся сезон водных развлечений: гостям доступны сапы, каяки и весельные лодки. В этом году пользование ими - комплементарное для всех гостей. Также появились новые маршруты для катеров по заливам Онежского озера.
Ресторан «Руна» представляет летнюю серию гриль-сетов, которые можно приготовить самостоятельно на одном из необитаемых островов или устроить барбекю на лужайке у дома. В меню — овощные и рыбные сеты, а также мясное ассорти.
Бутик-отель «Заонежье» приглашает к активному отдыху среди озер и северной природы Карелии. | 819 |
| 7 | Новый бесплатный курс от Anthropic!
Agent Skills: пошагово и с нуля
✓ Создание навыков (Skills) и лучшие практики
✓ Отличия от Tools и MCP
✓ Для Claude Code и Visual Studio Code
2 часа контента и 10 видеоуроков
→ deeplearning.ai/short-courses/agent-skills-with-anthropic/
👉 @SQLPortal | 901 |
| 8 | Тебе точно понравится:
Этот инструмент, который преобразует запросы на естественном языке в SQL-запросы
То есть пишешь ему, например:
все книги которые взяли студенты 2 курса за последнюю неделю
И он вам выдаёт SELECT * FROM ... и тд.
Очень удобный инструмент для тех, кто не знаком с SQL, но нуждается в работе с базами данных, пользуйтесь 📸
⛓ Ознакомиться: тут
👉 @SQLPortal | 926 |
| 9 |  Чем больше пользуюсь Claude Code, тем сильнее кажется, что главный навык теперь не кодинг.
А управление агентами.
У некоторых workflow выглядит примерно так:
Одна задача автоматически разбивается между несколькими агентами.
• один накидывает идеи
• один пишет технический план
• один кодит
• один делает ревью
• один ищет проблемы и пропущенные кейсы
Всё складывается в markdown, чтобы не потерять контекст.
Да, получается медленнее.
Да, приходится ждать.
Но качество обычно выше, потому что каждый агент делает только одну работу.
А настоящий буст начинается с Git Worktrees.
Вместо одной сессии Claude Code можно держать несколько параллельных.
Одна пилит новую фичу.
Вторая разбирается с багом.
Третья пишет тесты.
Четвёртая занимается рефакторингом.
В итоге начинаешь думать не в стиле «как написать этот код», а в стиле «как распределить работу между агентами и не потерять контроль над результатом».
Похоже, это и есть новый engineering skill.
👉 @SQLPortal | 875 |
| 10 |  Любимый паттерн для “последняя запись на группу” в Postgres — DISTINCT ON.
Да, он Postgres-specific. Нет, он не из SQL Standard. Зато для этой задачи он читается почти идеально.
Есть таблица заказов:
CREATE TABLE orders (
id bigint PRIMARY KEY,
customer_id int,
status text,
created_at timestamptz
);
Старый классический вариант:
SELECT o.*
FROM orders o
INNER JOIN (
SELECT customer_id, MAX(created_at) AS latest
FROM orders
GROUP BY customer_id
) latest ON o.customer_id = latest.customer_id
AND o.created_at = latest.latest;
Работает, но есть нюансы.
Таблица читается два раза: сначала ищем MAX(created_at) по каждому customer_id, потом джойнимся обратно за полной строкой.
И ещё хуже: если у одного клиента два заказа с одинаковым created_at, запрос может вернуть две строки. Нужен tie-breaker.
В Postgres проще так:
SELECT DISTINCT ON (customer_id)
customer_id, status, created_at
FROM orders
ORDER BY customer_id, created_at DESC;
DISTINCT ON (customer_id) оставляет первую строку для каждого клиента после сортировки.
То есть ORDER BY customer_id, created_at DESC сначала кладёт свежий заказ клиента наверх, а DISTINCT ON забирает его.
Чтобы это реально летало, добавляем индекс:
CREATE INDEX ON orders (customer_id, created_at DESC);
Теперь Postgres может идти по уже отсортированному индексу и не делать отдельную сортировку.
На небольшом тесте с 100k строк и 20k customer_id получилось так:
Без индекса:
• MAX + self-join: 32.92ms
• DISTINCT ON: 34.75ms
• ROW_NUMBER(): 38.68ms
С индексом (customer_id, created_at DESC):
• DISTINCT ON: 15.99ms
• ROW_NUMBER(): 25.36ms
• MAX + self-join: 38.01ms
Главный вывод: для “одна последняя строка на группу” в Postgres я первым беру DISTINCT ON.
Если нужно не одну строку, а top N строк на группу, тогда уже ROW_NUMBER():
SELECT customer_id, status, created_at
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY created_at DESC
) AS rn
FROM orders
) ranked
WHERE rn = 1;
DISTINCT ON — для простого “последний на группу”.
Window functions — когда нужна гибкость.
👉 @SQLPortal | 771 |
| 11 | Только начинаете знакомство с Oracle AI Database?
Anders Swanson показывает, с чего начать.
Что входит в руководство:
• запуск бесплатной базы данных в Docker
• установка необходимых инструментов для разработки: расширения SQL Developer для VS Code и CLI-интерфейса SQLcl
• подборка бесплатных материалов для изучения Oracle AI Database и экосистемы Oracle
Подойдёт тем, кто хочет быстро поднять локальное окружение и начать работать с Oracle без лишней настройки.
👉 @SQLPortal | 910 |
| 12 |  У Claude Code довольно элегантная структура проекта: одна папка .claude/, в которой живёт всё, что связано с агентом.
👉 @SQLPortal | 1 009 |
| 13 |  🚀 SudoTeach запустили новый курс — Продвинутый SQL!
SQL — это не только
SELECT * FROM users.
На работе и собеседованиях SQL — это не только простые запросы, а индексы, транзакции, JOIN’ы, оконные функции, CTE и проектирование БД.
В курсе собрали всё, что нужно, чтобы уверенно работать с базами данных в реальных проектах.
Что внутри:
• продвинутая выборка данных;
• JOIN, подзапросы, агрегации и группировки;
• оконные функции, CTE и рекурсия;
• DML, DDL, нормализация и проектирование таблиц;
• индексы, транзакции, VIEW и MATERIALIZED VIEW;
• сравнение PostgreSQL, MySQL и SQLite;
• обзор NoSQL, MongoDB и Redis;
• финальный проект: спроектируете БД с нуля и напишете запросы к ней.
🎓 8 разделов, 24 урока, практические задания, помощь преподавателя и доступ навсегда.
Прямо сейчас можно забрать курс со скидкой 40%:
🔗 https://sudoteach.com/course/sql-pro | 982 |
| 14 | Большинство AI-кодинг-агентов знают SQL.
Намного меньше из них понимают базы данных.
PlanetScale выложили Database Skills. Это набор skills для AI-агентов, которые работают с MySQL, Postgres, Vitess и Neki.
Вместо одного огромного промпта:
→ отдельный skill для MySQL
→ отдельный skill для Postgres
→ отдельный skill для Vitess
→ отдельный skill для Neki
Что умеет:
• проектирование схем
• индексы и оптимизация запросов
• транзакции и блокировки
• MVCC, VACUUM и WAL в Postgres
• шардинг через Vitess
• Online DDL и VReplication
• диагностика медленных запросов
Установка:
npx skills add planetscale/database-skills
или в Cursor:
/add-plugin database-skills
Мне нравится сама идея.
Сейчас многие используют агентов как очень умный автокомплит. А вот заставить агента понимать, почему этот индекс плохой, почему VACUUM отстаёт или почему шардирование сломает запросы через полгода, уже гораздо интереснее.
Open source. MIT License. GitHub доступен всем.
👉 @SQLPortal | 1 022 |
| 15 |  Нормализация БД относится к тем темам, которые изучает почти каждый разработчик.
Но со временем многие забывают разницу между:
✅ 1NF
✅ 2NF
✅ 3NF
✅ BCNF
✅ 4NF
Хорошо нормализованная база данных:
• уменьшает дублирование данных
• повышает целостность данных
• предотвращает аномалии при вставке, обновлении и удалении
• упрощает поддержку и развитие системы
Краткая шпаргалка по нормальным формам: | 1 050 |
| 16 | Supabase и Firebase забрали все ваши деньги?
Butterbase только что открыл исходный код. Полностью open-source бэкенд с нативной поддержкой AI:
- Postgres с RLS
- Auth и OAuth
- Хранилище
- Functions
- AI Gateway
- MCP Server (чтобы ваши агенты могли использовать бэкенд как полноценный набор инструментов)
То есть больше не нужно вручную копировать и вставлять код, чтобы Claude, Cursor или ваши агенты могли взаимодействовать с базой данных.
Всё доступно через инструменты.
Можно развернуть самостоятельно или использовать их managed-версию.
РЕПО ↓
https://github.com/butterbase-ai/butterbase
👉 @SQLPortal | 1 136 |
| 17 |  Устали постоянно получать:
CREATE ...
ORA-01031: insufficient privileges
при создании объектов?
В Oracle AI Database 26ai достаточно выдать одну роль:
GRANT db_developer_role TO ...
После этого пользователь сможет создавать все стандартные объекты базы данных.
👉 @SQLPortal | 1 116 |
| 18 |  Dolt — это SQL-база данных с полноценным Git-подобным контролем версий для данных.
Можно делать ветки, мержить изменения, форкать и клонировать не только код, но и сами данные.
• Подключение через MySQL-протокол, чтение и запись версионируемых данных обычным SQL
• Импорт CSV, коммиты изменений, push, pull и merge через привычные Git-команды
• Публикация баз на DoltHub или самостоятельный хостинг через DoltLab
• Используется как слой памяти для AI-агентов в multi-agent и multi-machine workflow
Если вам когда-нибудь хотелось сделать git checkout, git diff или git merge для базы данных, Dolt решает именно эту задачу.
Посмотреть проект можно здесь: https://github.com/dolthub/dolt
👉 @SQLPortal | 1 267 |
| 19 |  Я сократил расход токенов в Claude Code вдвое с помощью одного файла.
Замерял результат в течение недели.
Секрет прост: научить Claude выбирать модель в зависимости от задачи.
Haiku для массовых механических задач.
Sonnet для исследований и анализа.
Opus только там, где действительно требуется сложное рассуждение.
До этого токены тратились без разбора на любые задачи.
После настройки результат остался тем же, а расход снизился примерно вдвое.
Схема состоит из трёх частей.
1. Блок делегирования задач
Вы задаёте правило, по которому Claude создаёт субагентов и выбирает самую дешёвую подходящую модель:
→ Haiku: рутинные задачи без необходимости принимать решения
→ Sonnet: исследования, изучение кодовой базы, анализ и обобщение информации
→ Opus: только для реального планирования и сложных компромиссов
Два важных ограничения:
• Haiku никогда не создаёт собственных субагентов. Если это понадобилось, задача была плохо декомпозирована.
• Максимальная глубина вложенности — два уровня (родитель → субагент → ещё один уровень).
Если субагенту требуется более сильная модель, он возвращает задачу родителю, а не повышает уровень самостоятельно.
2. Блок предпочтительных инструментов
Вы учите Claude сначала выбирать самые дешёвые инструменты:
→ WebFetch для публичных веб-страниц
→ agent-browser CLI для динамических страниц и сайтов с авторизацией (примерно на 82% меньше токенов по сравнению с инструментами на основе скриншотов)
→ Конвертация PDF в текст вместо использования инструмента Read
Если Claude постоянно повторяет один и тот же шаблон действий, вы просите его оформить этот процесс как переиспользуемый инструмент.
3. Две строки в settings.json
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
Не позволяет загружать огромные контекстные окна, которые часто не нужны.
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"
Запускает автоматическое сжатие контекста при заполнении на 80%, а не после полного заполнения.
Только эти две настройки экономят токены в каждой сессии.
Вся настройка занимает около двух минут.
А экономия начинает накапливаться с каждой следующей задачей.
👉 @SQLPortal | 1 217 |
| 20 | Скиллы AI-агентов представляют собой набор инструкций в Markdown, которые объясняют, как выполнять определённую задачу.
Kris Rice создал библиотеку из более чем 100 скиллов для работы с Oracle AI Database, включающую практические примеры, лучшие практики и распространённые ошибки.
Получить их можно здесь: https://github.com/oracle/skills
👉 @SQLPortal | 1 277 |
