Агенты наконец-то получают нормальную память

agentmemory - это локальный слой памяти для AI coding agents, который решает одну из самых раздражающих проблем: каждый новый сеанс агент снова «забывает» архитектуру проекта, ваши правки, договорённости, баги и стиль работы.

Вместо того чтобы каждый раз заново объяснять Claude Code, Cursor, Codex или другому агенту, как устроен проект, agentmemory тихо сохраняет полезный контекст, сжимает его в searchable memory и подставляет нужные куски в следующих сессиях.

Что важно:

- работает с Claude Code, Cursor, Codex CLI, Gemini CLI, Windsurf, Roo Code, Cline, Aider и другими агентами
- поддерживает MCP, hooks и REST API
- один общий memory server для разных инструментов
- память шарится между агентами, а не живёт внутри одного клиента
- можно поднимать локально, без завязки на внешний сервис
- помогает не раздувать CLAUDE.md, .cursorrules и другие ручные файлы контекста

Идея простая: агент должен не просто выполнять задачу, а накапливать опыт по проекту.

https://github.com/rohitg00/agentmemory

Ночью сервер сломался, конфиг «никто не трогал», а деплой «точно не виноват»?

Есть простая команда:

find /etc -mtime -1 -type f

Она покажет все файлы в /etc, которые менялись за последние 24 часа.

Нужно проверить сайт - меняешь /etc на /var/www.

Когда все говорят «это не я», find быстро показывает, что реально трогали.

PaddleOCR-VL 1.6 официально вышел

PaddlePaddle выпустили PaddleOCR-VL 1.6 - новую версию модели для распознавания документов.

Результат: 96.33% на OmniDocBench. Это новый SOTA, причём модель обошла как open-source, так и закрытые решения в распознавании текста, формул и таблиц.

Что улучшили:

- первое место на OmniDocBench v1.5 и Real5-OmniDocBench
- заметно лучше распознаёт таблицы, обычный текст и редкие символы
- улучшено распознавание печатей, отдельных фрагментов и графиков
- полная совместимость с архитектурой v1.5
- миграция не нужна - можно подключать как plug-and-play

Где это полезно:

- финансовые контракты
- юридические документы
- исследовательские отчёты
- исторические архивы
- RAG-пайплайны
- подготовка качественных данных для LLM

https://github.com/PaddlePaddle/PaddleOCR

#PaddlePaddle #PaddleOCR #AI #ComputerVision

🚀 Мощный мультимодальный ИИ: Step 3.7 Flash

Step 3.7 Flash — это 198B-параметрическая модель, объединяющая языковую и визуальную обработку для высокопроизводительных задач. Она активирует около 11B параметров на токен, обеспечивая скорость до 400 токенов в секунду и поддерживая контекст до 256k. Идеально подходит для сложных рабочих процессов, таких как анализ финансовых отчетов и взаимодействие с API.

🚀 Основные моменты:
- Высокая производительность в визуальном восприятии и обработке.
- Поддержка многопараметрических задач с высокой точностью.
- Гибкость развертывания в облаке и локально.
- Интеграция с популярными инструментами и платформами.

📌 GitHub: https://github.com/stepfun-ai/Step-3.7-Flash

#python

Python не медленный. Медленным его часто делает ваш код.

У Python есть странная репутация: стоит программе начать тормозить, виноват сразу язык. Но в реальности большая часть быстрых сценариев в Python работает не потому, что интерпретатор внезапно стал магическим, а потому что тяжёлая работа уходит ниже - в C, C++ или Rust.

CPython написан на C. Многие встроенные операции тоже выполняются в C:

- len()
- list.append()
- dict.get()
- sum()
- сортировка
- операции со строками
- часть работы со списками и словарями

Когда вы вызываете list.append(), Python не крутит всю логику добавления элемента на уровне байткода. Он платит небольшой overhead за вызов, а дальше попадает в C-функцию внутри CPython.

Медленный путь начинается там, где мы вручную гоняем данные по одному элементу:

total = 0

for x in data:
    total += x

На каждой итерации интерпретатор должен выполнить байткод, достать объект, проверить типы, сделать операцию, обновить значение и перейти к следующему элементу. Для маленьких списков это незаметно. Для миллионов элементов это уже цена, которую вы платите за каждую итерацию.

Быстрый путь выглядит иначе:

total = sum(data)

Здесь цикл проталкивается внутрь реализации. Python остаётся удобной оболочкой, а основная работа выполняется ближе к нативному коду.

С NumPy та же идея, только ещё жёстче:

total = np.sum(data)

Внутренний цикл почти не возвращается в Python. Массив обрабатывается внутри оптимизированного нативного кода, а обратно приходит уже готовый результат.

Поэтому фраза «Python медленный» слишком грубая.

Точнее так:

Python-циклы дорогие
C-циклы дешёвые
built-in функции часто быстрее ручного кода
NumPy быстрый не из-за синтаксиса, а потому что не гоняет каждый элемент через интерпретатор
хороший Python-код старается как можно дольше оставаться внутри готовых операций и библиотек

Оптимизация Python часто начинается не с переписывания проекта на Go или Rust, а с простого вопроса:

можно ли убрать ручной цикл и отдать работу тому коду, который уже написан на C, C++ или Rust?

Python хорош не как самый быстрый исполнитель каждой операции.

Он хорош как удобный слой управления над быстрыми нативными кусками.

Когда-то в Python файлы открывали вот так:

f_obj = open(path, 'w')
f_obj.write(some_data)
f_obj.close()

Код короткий, выглядит понятно, но есть проблема: если между open() и close() что-то упадёт, файл может остаться незакрытым.

Поэтому приходилось руками оборачивать всё в try / finally, следить за закрытием ресурса и не забывать cleanup на ошибках.

Потом в Python появился with, и этот бытовой ад стал намного чище:

with open(path, 'w') as f_obj:
f_obj.write(some_data)

Теперь файл закроется автоматически, даже если внутри блока случится исключение.

Это одна из тех фич Python, которые выглядят мелко, но сильно меняют стиль кода. with убирает ручное управление ресурсами и делает намерение очевидным: вот ресурс, вот область, где он нужен, после выхода из блока его надо корректно закрыть.

Используется не только для файлов:

- соединения с базой
- lock'и
- временные файлы
- сетевые подключения
- транзакции
- любые объекты с контекстным менеджером

Хороший Python-код часто начинается с простого правила: если ресурс надо открыть и потом закрыть, почти всегда нужен with.

#python

38 лет считалось, что для разреженных графов алгоритм Дейкстры почти упёрся в потолок.

Логика выглядела железно:

- Дейкстра упорядочивает вершины по расстоянию
- сортировка имеет нижнюю границу O(n log n)
- значит, кратчайшие пути быстрее искать нельзя

Но группа из 5 исследователей показала, что это ограничение можно обойти.

Идея в том, чтобы не просто «ускорить очередь с приоритетами», а смешать подход Дейкстры с динамическим программированием в стиле Беллмана-Форда. Алгоритм делит множество вершин, сжимает frontier и не тратит время на полную сортировку там, где она не нужна.

Результат:

O(m log^(2/3) n)

Это первое улучшение для направленных разреженных графов со времён Fibonacci heap в 1987 году.

Tsinghua, Stanford, Max Planck. 17 страниц, которые ломают старое интуитивное объяснение про «Дейкстру быстрее нельзя».

В Python есть ловушка, на которой легко ошибиться.

Смотрим код: t равен кортежу из трёх элементов: один, два и список три, четыре.

То есть внутри tuple лежит обычный список.

Дальше выполняется строка: к элементу t с индексом два прибавить список с числом пять.

Проще говоря, Python берёт третий элемент кортежа и добавляет к нему пять.

Третий элемент — это список три, четыре.

Для списка операция плюс равно меняет объект на месте. Поэтому список сразу становится: три, четыре, пять.

Но потом Python пытается записать результат обратно в t с индексом два, то есть обратно в третий элемент tuple.

А tuple неизменяемый. Его элементы нельзя перезаписывать по индексу.

Поэтому возникает TypeError.

И вот тут главный подвох: ошибка произошла, но список уже успел измениться.

Финальный результат: t равен кортежу: один, два, список три, четыре, пять.

Вывод: tuple не даёт менять свою структуру, но не делает вложенные объекты неизменяемыми.

Python Совет: как добавить watermark на график Matplotlib

В Matplotlib водяной знак можно добавить прямо через fig.text().

Пример:

import matplotlib.pyplot as plt

fig = plt.figure(figsize=(5, 8))

fig.text(
    1, 0.15,
    "Mouse vs Python",
    fontsize=45,
    color="blue",
    ha="right",
    va="bottom",
    alpha=0.4,
    rotation=25
)

plt.show()

Что здесь важно:

* fig.text() добавляет текст на всю фигуру, а не внутрь конкретной оси
* alpha=0.4 делает watermark полупрозрачным
* rotation=25 поворачивает надпись
* ha и va управляют привязкой текста по горизонтали и вертикали

Полезно для отчётов, графиков в блогах, внутренних дашбордов и картинок, которые могут разойтись без контекста.

🐍 Python Парсинг: Большой продвинутый бесплатный курс

Полное практическое руководство по веб-скрейпингу на Python — от основ HTTP до production-grade пауков, обхода антибот-защит, асинхронности и проектирования надёжных пайплайнов. Каждый раздел содержит рабочие примеры, типовые ошибки и продвинутые практики.

https://github.com/justxor/Pythonparsing-/tree/main

Скажи мне 5 главных слов: на GitVerse появилось зеркало PyPI! 😎

Все нужные Python‑пакеты живут на российской платформе для разработчиков GitVerse — вы не потеряете доступ к ним, даже если основной PyPI решит «повиснуть».

А ещё такое зеркало — плюс к скорости: меньше сетевых прыжков — быстрее загрузка.

Ставьте его как основной источник или держите как резерв. Тут рассказали, как подключить зеркало!

Разберем математику бесконечности Сатору Годжо, которая работает не как обычный щит.

Он не просто останавливает удар в последний момент. Идея в том, что пространство между атакой и Годжо как будто делится на всё более маленькие отрезки.

Сначала объект проходит половину расстояния. Потом половину оставшегося. Потом ещё половину. И так снова и снова.

Математически это похоже на бесконечную сумму: одна вторая, одна четвёртая, одна восьмая, одна шестнадцатая.

Объект всё ближе, но до контакта так и не доходит.

На практике атака как будто замедляется почти до нуля. Чем ближе она к Годжо, тем сильнее падает её эффективная скорость.

Поэтому Бесконечность — это не просто барьер. Это контроль пространства, где противник застревает в бесконечном приближении.

Один из главных мифов вокруг ИИ-кодинга: достаточно найти правильный промпт — и модель начнет писать хороший код

Но на практике два разработчика могут отправить одинаковый запрос: «создай API для пользователей» — и получить совершенно разный результат. Один получит аккуратный FastAPI-сервис с типами, тестами и обработкой ошибок. Другой — код, который придется переписывать после первого изменения.

Причина часто не в модели.

LLM (большие языковые модели) не знает, как устроен ваш проект: какие архитектурные решения приняты, какие стандарты действуют и что команда считает качественным результатом.

Поэтому стоит выстраивать вокруг ИИ тот же инженерный слой, который уже есть в обычной разработке: правила проекта, чек-листы, автоматические проверки и понятные критерии качества.

На бесплатном вебинаре karpovꓸcourses «ИИ-агенты и профессиональная разработка на Python» Алексей Жиряков покажет вживую, почему ИИ-код ломается в реальных проектах и как это исправлять.

Алексей — исполнительный директор в Сбере, занимается развитием генеративного ИИ, а до этого более 15 лет работал в backend-разработке и руководил инженерными командами.

Будет живое демо поверх готового репозитория: как настроить процесс, получить более чистый типизированный код и использовать продакшен-подход вроде связки «дешевая модель пишет — дорогая ревьюит», которая помогает снижать стоимость генерации.

Присоединяйтесь по ссылке, а после регистрации вы получите гайд «Почему ваш ИИ пишет не то: LLM против ИИ-агента»: https://clc.to/erid_2W5zFHfubtm

Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFHfubtm

Основы Git и GitHub за 30 секунд: настройка, коммиты, ветки, Pull Request

GitHub пугает новичков не сложностью, а количеством команд, в которых легко утонуть в первый же день. Эта шпаргалка собирает весь базовый путь от пустого терминала до открытого Pull Request, чтобы не держать всё в голове и не гуглить каждый шаг.
Сначала первая настройка: задаёшь имя и email, иначе коммиты уходят непонятно от кого. Дальше старт работы: клонируешь репозиторий, заходишь в папку и сразу создаёшь свою ветку под задачу. Потом ежедневный цикл, который повторяется каждый день: status, pull, add, commit, push. Проверил, обновил, добавил, закоммитил, отправил. Отдельно блок полезных команд на каждый день: log с графом, diff, stash, branch и переключение на main.

tracesage добавляет локальный tracing без инфраструктуры для LangChain/LangGraph-агентов всего в две строки.

Он записывает каждый chain, tool call и LLM call в SQLite, а затем показывает запуск в браузере как live graph и timeline.

Open source, установка через pip install, лицензия MIT.

https://github.com/kjgpta/tracesage