🧵 Anthropic показали, как заставить агента реально работать неделями над одним проектом, а не притворяться
Anthropic выкатили очень практичный ресёрч-пост про harness для long-running агентов — как сделать так, чтобы Claude не терял нить между сессиями и уверенно допиливал большой проект до продакшена.
Проблема:
Даже Opus 4.5 в цикле на Agent SDK, если просто сказать «сделай клон claude.ai», ведёт себя по-человечески плохо:
• пытается с одного раза сделать всё приложение → забивается контекст → остаётся полусломанная фича без описания;
• позже другой запуск видит «что-то уже работает» и объявляет победу, хотя половины функционала нет.
Решение Anthropic — двухагентный harness:
1. 🧱 Initializer-агент (первый запуск)
Он один раз готовит среду:
• пишет feature_list / tests.json c подробным списком фич (в примере — 200+ штук), все с passes: false;
• создаёт init.sh, который поднимает dev-сервер и гоняет базовые тесты;
• заводит claude-progress.txt и первый git-коммит как точку отсчёта.
2. 🔁 Coding-агент (все последующие сессии)
Каждый заход живёт по строгому протоколу:
• pwd → читает claude-progress.txt, feature_list.json, свежий git log;
• запускает ./init.sh, чинит, если всё падает;
• выбирает одну непроходящую фичу из списка;
• реализует её и проверяет end-to-end (для веба — через Puppeteer MCP, как реальный пользователь);
• только после этого ставит passes: true, дописывает прогресс и делает чистый git-коммит.
Тесты запрещено ослаблять или удалять — только фиксить код.
Ключевая мысль: долгоживущий агент = не “бесконечный контекст”, а правильно спроектированный диск и протокол смены:
• JSON-файл фич/тестов как контракт,
• claude-progress.txt + git как память между окнами,
• init.sh как единая точка входа,
• жёсткое правило «одна фича за сессию и чистое состояние на выходе».
Для нас это по сути готовый blueprint: такой harness можно повторить в Claude Code, Claude Agent SDK или любой своей multi-agent системе, даже без сложной оркестрации — просто через структуру репо и инструкции к агенту.
🔗 Оригинальная статья:
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
🔗 Обновленный гайд по промптингу:
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices#multi-context-window-workflows
Anthropic выкатили очень практичный ресёрч-пост про harness для long-running агентов — как сделать так, чтобы Claude не терял нить между сессиями и уверенно допиливал большой проект до продакшена.
Проблема:
Даже Opus 4.5 в цикле на Agent SDK, если просто сказать «сделай клон claude.ai», ведёт себя по-человечески плохо:
• пытается с одного раза сделать всё приложение → забивается контекст → остаётся полусломанная фича без описания;
• позже другой запуск видит «что-то уже работает» и объявляет победу, хотя половины функционала нет.
Решение Anthropic — двухагентный harness:
1. 🧱 Initializer-агент (первый запуск)
Он один раз готовит среду:
• пишет feature_list / tests.json c подробным списком фич (в примере — 200+ штук), все с passes: false;
• создаёт init.sh, который поднимает dev-сервер и гоняет базовые тесты;
• заводит claude-progress.txt и первый git-коммит как точку отсчёта.
2. 🔁 Coding-агент (все последующие сессии)
Каждый заход живёт по строгому протоколу:
• pwd → читает claude-progress.txt, feature_list.json, свежий git log;
• запускает ./init.sh, чинит, если всё падает;
• выбирает одну непроходящую фичу из списка;
• реализует её и проверяет end-to-end (для веба — через Puppeteer MCP, как реальный пользователь);
• только после этого ставит passes: true, дописывает прогресс и делает чистый git-коммит.
Тесты запрещено ослаблять или удалять — только фиксить код.
Ключевая мысль: долгоживущий агент = не “бесконечный контекст”, а правильно спроектированный диск и протокол смены:
• JSON-файл фич/тестов как контракт,
• claude-progress.txt + git как память между окнами,
• init.sh как единая точка входа,
• жёсткое правило «одна фича за сессию и чистое состояние на выходе».
Для нас это по сути готовый blueprint: такой harness можно повторить в Claude Code, Claude Agent SDK или любой своей multi-agent системе, даже без сложной оркестрации — просто через структуру репо и инструкции к агенту.
🔗 Оригинальная статья:
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
🔗 Обновленный гайд по промптингу:
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices#multi-context-window-workflows
Anthropic
Effective harnesses for long-running agents
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
👍6🔥3😁1
🧵 Beads — память и тудушка для ваших код-агентов от Steve Yegge
Steve Yegge (ex-Amazon, ex-Google, сейчас Sourcegraph) выкатил Beads — минималистичную систему памяти и задач специально для код-агентов. Автор называет это «cognitive upgrade for your coding agent». Я раньше зачитывался его заметками о культуре Google, это был 2008 год…
Что это такое
Beads — это:
• 🧠 память для агентов на базе issue-трекера
• 🪢 граф задач: эпики, подзадачи и зависимости связываются “как бусины на нитке”
• 📁 один JSONL-файл в .beads/, версионируемый вместе с кодом в git
• 🤖 заточено под LLM-агентов (Claude Code, Amp, свои воркеры и т.п.), а не под людей
Идея: агент больше не пишет километры гниющих markdown-планов, а ведёт живой issue-трекер с зависимостями и “ready”-очередью.
⸻
Зачем это нужно
Классическая проблема агентов:
• план раздувается → контекст кончается
• часть задач теряется
• при следующем запуске агент “ничего не помнит” и заново переизобретает TODO.
С Beads агент:
• сам заводит задачи по ходу работы (“нашёл сломанные тесты — открыл issue”)
• строит цепочки зависимостей и эпиков
• в любой момент может ответить:
“какие у нас сейчас top-N готовых ready задач?”
Плюс: в последних версиях ввели hash-ID задач (вместо bd-1, bd-2…), чтобы несколько агентов и веток могли спокойно создавать задачи без конфликтов при merge. Это критично для multi-agent / multi-branch воркфлоу.
⸻
Как это выглядит в работе
1. Вы ставите CLI:
curl -fsSL https://raw.githubusercontent.com/steveyegge/beads/main/noscripts/install.sh | bash
2. В своём CLAUDE.md / AGENTS.md пишете что-то вроде:
“Для трекинга задач используй bd (Beads), а не markdown-файлы.
Если ещё не инициализировано — запусти bd quickstart.”
3. Дальше агенты сами:
• создают, обновляют, линкуют задачи
• на старте смотрят bd ready и выбирают, что делать
• по пути дописывают новые issues и связи
Для вас это выглядит как общая база знаний о работе, лежащая прямо в репо.
⸻
Почему это интересно
• ✨ Сделано под vibe-coding/agentic воркфлоу как first-class citizen, а не адаптация Jira/Linear.
• 🧬 Прозрачный текстовый формат (JSONL + git) → легко анализировать, бэкапить, кормить в RAG.
• 🐜 Уже используется самим Yegge в его “колонии агентов” VC (AI-оркестратор для Amp/Claude Code и др.).
⸻
Ссылка
🔗 GitHub: https://github.com/steveyegge/beads
(в README есть быстрый старт, сравнение с классическими трекерами и детали про hash-ID, protected branches и т.д.)
Если вы уже строите свои пайплайны с Claude Code / Agents SDK / multi-agent системами — Beads выглядит как очень удачный кандидат на “единый мозг задач” для всех агентов в репозитории.
Steve Yegge (ex-Amazon, ex-Google, сейчас Sourcegraph) выкатил Beads — минималистичную систему памяти и задач специально для код-агентов. Автор называет это «cognitive upgrade for your coding agent». Я раньше зачитывался его заметками о культуре Google, это был 2008 год…
Что это такое
Beads — это:
• 🧠 память для агентов на базе issue-трекера
• 🪢 граф задач: эпики, подзадачи и зависимости связываются “как бусины на нитке”
• 📁 один JSONL-файл в .beads/, версионируемый вместе с кодом в git
• 🤖 заточено под LLM-агентов (Claude Code, Amp, свои воркеры и т.п.), а не под людей
Идея: агент больше не пишет километры гниющих markdown-планов, а ведёт живой issue-трекер с зависимостями и “ready”-очередью.
⸻
Зачем это нужно
Классическая проблема агентов:
• план раздувается → контекст кончается
• часть задач теряется
• при следующем запуске агент “ничего не помнит” и заново переизобретает TODO.
С Beads агент:
• сам заводит задачи по ходу работы (“нашёл сломанные тесты — открыл issue”)
• строит цепочки зависимостей и эпиков
• в любой момент может ответить:
“какие у нас сейчас top-N готовых ready задач?”
Плюс: в последних версиях ввели hash-ID задач (вместо bd-1, bd-2…), чтобы несколько агентов и веток могли спокойно создавать задачи без конфликтов при merge. Это критично для multi-agent / multi-branch воркфлоу.
⸻
Как это выглядит в работе
1. Вы ставите CLI:
curl -fsSL https://raw.githubusercontent.com/steveyegge/beads/main/noscripts/install.sh | bash
2. В своём CLAUDE.md / AGENTS.md пишете что-то вроде:
“Для трекинга задач используй bd (Beads), а не markdown-файлы.
Если ещё не инициализировано — запусти bd quickstart.”
3. Дальше агенты сами:
• создают, обновляют, линкуют задачи
• на старте смотрят bd ready и выбирают, что делать
• по пути дописывают новые issues и связи
Для вас это выглядит как общая база знаний о работе, лежащая прямо в репо.
⸻
Почему это интересно
• ✨ Сделано под vibe-coding/agentic воркфлоу как first-class citizen, а не адаптация Jira/Linear.
• 🧬 Прозрачный текстовый формат (JSONL + git) → легко анализировать, бэкапить, кормить в RAG.
• 🐜 Уже используется самим Yegge в его “колонии агентов” VC (AI-оркестратор для Amp/Claude Code и др.).
⸻
Ссылка
🔗 GitHub: https://github.com/steveyegge/beads
(в README есть быстрый старт, сравнение с классическими трекерами и детали про hash-ID, protected branches и т.д.)
Если вы уже строите свои пайплайны с Claude Code / Agents SDK / multi-agent системами — Beads выглядит как очень удачный кандидат на “единый мозг задач” для всех агентов в репозитории.
👍3🤔2
🛠 Claude Agent Toolkit — удобная обёртка для claude-code-sdk
Появился интересный проект — Claude Agent Toolkit (Python-фреймворк), который упрощает работу с
⚙️ Что он даёт
• Декоратор-API для инструментов:
• Автоматический запуск MCP-сервера — меньше инфраструктурной рутины.
• Выполнение инструментов в Docker-контейнерах, а не на хосте → изоляция и безопасность по умолчанию.
• Поддержка параллельного выполнения, таймаутов, контроля ресурсов.
🧠 Идея
Claude Code используется как «движок рассуждений», а Toolkit — как слой оркестрации:
инструменты, среда, sandbox, безопасность. Что-то вроде «LangGraph, но вокруг Claude Code».
🎯 Кому это может быть полезно
• Тем, кто строит агентов с доступом к файлам, БД, внешним API.
• Тем, кто хочет не просто скрипт, а стабильного продакшн-агента.
• Тем, кто не хочет руками поднимать и настраивать MCP-серверы.
📎 Репозиторий:
Есть ещё лёгкий вариант:
Появился интересный проект — Claude Agent Toolkit (Python-фреймворк), который упрощает работу с
claude-code-sdk и делает агентов более продакшн-готовыми.⚙️ Что он даёт
• Декоратор-API для инструментов:
@tool вместо ручного описания MCP-инструментов и серверов.• Автоматический запуск MCP-сервера — меньше инфраструктурной рутины.
• Выполнение инструментов в Docker-контейнерах, а не на хосте → изоляция и безопасность по умолчанию.
• Поддержка параллельного выполнения, таймаутов, контроля ресурсов.
🧠 Идея
Claude Code используется как «движок рассуждений», а Toolkit — как слой оркестрации:
инструменты, среда, sandbox, безопасность. Что-то вроде «LangGraph, но вокруг Claude Code».
🎯 Кому это может быть полезно
• Тем, кто строит агентов с доступом к файлам, БД, внешним API.
• Тем, кто хочет не просто скрипт, а стабильного продакшн-агента.
• Тем, кто не хочет руками поднимать и настраивать MCP-серверы.
📎 Репозиторий:
https://github.com/cheolwanpark/claude-agent-toolkitЕсть ещё лёгкий вариант:
cheolwanpark/claude-adk — тот же подход, но попроще.👍2
🍏 Apple прокачал LLM на MacBook Pro M5: MLX + новые нейроускорители (или почему
Apple показали, как новые MacBook Pro на M5 гоняют большие модели прямо на ноуте с помощью фреймворка MLX и новых Neural Accelerators в GPU. Это уже не «маркетинг про ИИ», а реальные цифры по Qwen, GPT-OSS и FLUX.
⸻
🔧 Что такое MLX
MLX — open-source фреймворк от Apple под Apple Silicon:
• работает на всех M-чипах
• использует единую (unified) память — CPU и GPU видят одни и те же массивы
• API напоминает NumPy
• есть модули для нейросетей, оптимизаторов, автодиффа и граф-оптимизаций
• есть фронтенды для Python и Swift
Установка:
⸻
🤖 MLX LM: запуск LLM на Mac
Сверху MLX есть отдельный слой — MLX LM:
• поддерживает большинство LLM с Hugging Face
• умеет квантовку (4-бит и т.п.)
• позволяет запускать модели буквально из терминала (mlx_lm.chat)
Пример квантовки Mistral 7B в 4-бит:
mlx_lm.convert \
--hf-path mistralai/Mistral-7B-Instruct-v0.3 \
-q \
--upload-repo mlx-community/Mistral-7B-Instruct-v0.3-4bit
⸻
🚀 Что нового в M5
Главный апдейт — Neural Accelerators в GPU M5:
• отдельные блоки под матричные операции для ML
• MLX использует Tensor Operations + Metal Performance Primitives (Metal 4)
• всё это требует свежий macOS 26.2+
⸻
📊 Бенчмарки: M5 vs M4
Тесты на MacBook Pro M5 24GB против схожего M4:
Модели:
• Qwen 1.7B и Qwen 8B в BF16
• Qwen 8B и Qwen 14B в 4-битной квантовке
• Qwen 30B (MoE, 3B активных параметров, 4-бит)
• GPT OSS 20B в формате MXFP4
1️⃣ Time To First Token (TTFT)
• первый токен — чистый compute-bound
• для плотной 14B TTFT на M5 падает до < ~10 сек
• для 30B MoE — < ~3 сек
• максимум — до ~4× ускорения TTFT относительно M4
2️⃣ Скорость генерации дальше
• дальше всё упирается в память
• M5 даёт +19–27% скорости за счёт более широкой шины:
• M4: 120 GB/s
• M5: 153 GB/s (~+28% по bandwidth)
3️⃣ Какого размера модели влезают
На MacBook Pro 24GB нормально живут:
• Qwen 8B BF16
• Qwen 30B MoE 4-бит
и при этом модель + кэш укладываются примерно до 18 GB.
⸻
🖼 Не только текст: FLUX-dev
Для генерации картинок тоже профит:
• модель FLUX-dev-4bit (12B)
• генерация 1024×1024 на M5
• примерно 3.8× быстрее, чем на M4
⸻
🧑💻 Что это значит для нас
Комбо M5 + MLX даёт:
• нормальный запуск LLM 8B BF16 и MoE 30B 4-бит прямо на ноуте
• адекватный TTFT, так что локальный ассистент на Mac становится реально юзабельным
• удобную конвертацию и квантовку моделей (Qwen, GPT-OSS и др.)
• полноценный стек для локальных LLM/ML-экспериментов без облака для тех, кто живёт в экосистеме Apple
⸻
🏁 Как быстро попробовать
1. Установить MLX:
2. Установить MLX LM:
3. Выбрать модель на Hugging Face (Qwen 1.7B / 8B / 14B, GPT-OSS, варианты под MLX).
4. При необходимости — сделать 4-бит квантовку через mlx_lm.convert и залить в свой репозиторий.
5. Запустить чат с моделью через mlx_lm.chat и посмотреть, как едет на вашем Mac.
Apple показали, как новые MacBook Pro на M5 гоняют большие модели прямо на ноуте с помощью фреймворка MLX и новых Neural Accelerators в GPU. Это уже не «маркетинг про ИИ», а реальные цифры по Qwen, GPT-OSS и FLUX.
⸻
🔧 Что такое MLX
MLX — open-source фреймворк от Apple под Apple Silicon:
• работает на всех M-чипах
• использует единую (unified) память — CPU и GPU видят одни и те же массивы
• API напоминает NumPy
• есть модули для нейросетей, оптимизаторов, автодиффа и граф-оптимизаций
• есть фронтенды для Python и Swift
Установка:
pip install mlx⸻
🤖 MLX LM: запуск LLM на Mac
Сверху MLX есть отдельный слой — MLX LM:
• поддерживает большинство LLM с Hugging Face
• умеет квантовку (4-бит и т.п.)
• позволяет запускать модели буквально из терминала (mlx_lm.chat)
Пример квантовки Mistral 7B в 4-бит:
mlx_lm.convert \
--hf-path mistralai/Mistral-7B-Instruct-v0.3 \
-q \
--upload-repo mlx-community/Mistral-7B-Instruct-v0.3-4bit
⸻
🚀 Что нового в M5
Главный апдейт — Neural Accelerators в GPU M5:
• отдельные блоки под матричные операции для ML
• MLX использует Tensor Operations + Metal Performance Primitives (Metal 4)
• всё это требует свежий macOS 26.2+
⸻
📊 Бенчмарки: M5 vs M4
Тесты на MacBook Pro M5 24GB против схожего M4:
Модели:
• Qwen 1.7B и Qwen 8B в BF16
• Qwen 8B и Qwen 14B в 4-битной квантовке
• Qwen 30B (MoE, 3B активных параметров, 4-бит)
• GPT OSS 20B в формате MXFP4
1️⃣ Time To First Token (TTFT)
• первый токен — чистый compute-bound
• для плотной 14B TTFT на M5 падает до < ~10 сек
• для 30B MoE — < ~3 сек
• максимум — до ~4× ускорения TTFT относительно M4
2️⃣ Скорость генерации дальше
• дальше всё упирается в память
• M5 даёт +19–27% скорости за счёт более широкой шины:
• M4: 120 GB/s
• M5: 153 GB/s (~+28% по bandwidth)
3️⃣ Какого размера модели влезают
На MacBook Pro 24GB нормально живут:
• Qwen 8B BF16
• Qwen 30B MoE 4-бит
и при этом модель + кэш укладываются примерно до 18 GB.
⸻
🖼 Не только текст: FLUX-dev
Для генерации картинок тоже профит:
• модель FLUX-dev-4bit (12B)
• генерация 1024×1024 на M5
• примерно 3.8× быстрее, чем на M4
⸻
🧑💻 Что это значит для нас
Комбо M5 + MLX даёт:
• нормальный запуск LLM 8B BF16 и MoE 30B 4-бит прямо на ноуте
• адекватный TTFT, так что локальный ассистент на Mac становится реально юзабельным
• удобную конвертацию и квантовку моделей (Qwen, GPT-OSS и др.)
• полноценный стек для локальных LLM/ML-экспериментов без облака для тех, кто живёт в экосистеме Apple
⸻
🏁 Как быстро попробовать
1. Установить MLX:
pip install mlx2. Установить MLX LM:
pip install mlx-lm3. Выбрать модель на Hugging Face (Qwen 1.7B / 8B / 14B, GPT-OSS, варианты под MLX).
4. При необходимости — сделать 4-бит квантовку через mlx_lm.convert и залить в свой репозиторий.
5. Запустить чат с моделью через mlx_lm.chat и посмотреть, как едет на вашем Mac.
💾🧠 Калькулятор VRAM для LLM: сколько реально потянет ваша видеокарта?
Если вы гоняете LLM-ы локально или проектируете продовый inference, вот удобный инструмент: LLM Inference: VRAM & Performance Calculator от ApX
👉 https://apxml.com/tools/vram-calculator
Он помогает ответить на вечный вопрос:
“А мой 12/16/24 GB GPU вообще вытянет эту модель с таким контекстом и нагрузкой?”
⸻
🧩 Что умеет калькулятор
По сути это интерактивный планировщик ресурса для LLM-ов:
• Выбор модели (включая MoE-архитектуры и большие модели >100B параметров).
• Режимы Inference / Fine-tuning.
• Квантование весов (FP16, 8-бит, 4-бит и т.п.) и отдельное квантование KV-кэша — сразу видно, как это экономит VRAM на длинных промптах.
• Железо: выбор GPU (включая NVIDIA и Apple Silicon) или кастомный объём VRAM.
• Batch size, sequence length и число одновременных пользователей — инструмент показывает, как растёт память и падает TPS при нагрузке.
• Опция offload’а на CPU/RAM или NVMe для тяжёлых конфигураций.
На выходе вы получаете:
• Оценку занятой VRAM / из доступной.
• Приблизительную скорость генерации (TPS) и Time to First Token (TTFT) — важно для UX и SLA.
⸻
📊 Как он считает
ApX явно пишет, что это теоретическая оценка, а не “до гигабайта в nvidia-smi”:
• Формулы учитывают архитектуру модели (параметры, слои, скрытые размерности, активные эксперты в MoE и т.д.), квантование, длину контекста, batch и распределённый режим.
• TPS считается по эмпирическим бенчмаркам и масштабируется под разные GPU.
• Значения немного завышены, т.к. не учитывают все трюки конкретных фреймворков по экономии памяти.
Отдельно в FAQ развеивают миф про MoE:
MoE-модели не “магически” экономят VRAM — экспертов всё равно нужно держать в памяти, экономия больше про вычисления, а не про память.
⸻
🛠 Практическое применение
Для чего это полезно:
• Планирование железа: понять, хватит ли одной 24GB карты или нужна пара 48GB / кластер.
• Дизайн продукта: подобрать такой контекст, batch и квантование, чтобы уложиться в бюджет по VRAM и задержкам.
• Выбор режима deploy’а: локально, on-prem, облако или микс с offload’ом на NVMe/CPU.
• Прикидка нагрузки: сколько одновременных пользователей вы реально выдержите на выбранной конфигурации.
⸻
🚀 Лейтмотив
Это не очередной “калькулятор ради калькулятора”, а рабочий инструмент для тех, кто делает LLM-сервисы и агентов в проде — помогает быстро прикинуть, какая модель на каком железе реально поедет и сколько пользователей вы на ней повесите, прежде чем покупать лишние GPU или падать по OOM.
🔗 Инструмент здесь: https://apxml.com/tools/vram-calculator
Если вы гоняете LLM-ы локально или проектируете продовый inference, вот удобный инструмент: LLM Inference: VRAM & Performance Calculator от ApX
👉 https://apxml.com/tools/vram-calculator
Он помогает ответить на вечный вопрос:
“А мой 12/16/24 GB GPU вообще вытянет эту модель с таким контекстом и нагрузкой?”
⸻
🧩 Что умеет калькулятор
По сути это интерактивный планировщик ресурса для LLM-ов:
• Выбор модели (включая MoE-архитектуры и большие модели >100B параметров).
• Режимы Inference / Fine-tuning.
• Квантование весов (FP16, 8-бит, 4-бит и т.п.) и отдельное квантование KV-кэша — сразу видно, как это экономит VRAM на длинных промптах.
• Железо: выбор GPU (включая NVIDIA и Apple Silicon) или кастомный объём VRAM.
• Batch size, sequence length и число одновременных пользователей — инструмент показывает, как растёт память и падает TPS при нагрузке.
• Опция offload’а на CPU/RAM или NVMe для тяжёлых конфигураций.
На выходе вы получаете:
• Оценку занятой VRAM / из доступной.
• Приблизительную скорость генерации (TPS) и Time to First Token (TTFT) — важно для UX и SLA.
⸻
📊 Как он считает
ApX явно пишет, что это теоретическая оценка, а не “до гигабайта в nvidia-smi”:
• Формулы учитывают архитектуру модели (параметры, слои, скрытые размерности, активные эксперты в MoE и т.д.), квантование, длину контекста, batch и распределённый режим.
• TPS считается по эмпирическим бенчмаркам и масштабируется под разные GPU.
• Значения немного завышены, т.к. не учитывают все трюки конкретных фреймворков по экономии памяти.
Отдельно в FAQ развеивают миф про MoE:
MoE-модели не “магически” экономят VRAM — экспертов всё равно нужно держать в памяти, экономия больше про вычисления, а не про память.
⸻
🛠 Практическое применение
Для чего это полезно:
• Планирование железа: понять, хватит ли одной 24GB карты или нужна пара 48GB / кластер.
• Дизайн продукта: подобрать такой контекст, batch и квантование, чтобы уложиться в бюджет по VRAM и задержкам.
• Выбор режима deploy’а: локально, on-prem, облако или микс с offload’ом на NVMe/CPU.
• Прикидка нагрузки: сколько одновременных пользователей вы реально выдержите на выбранной конфигурации.
⸻
🚀 Лейтмотив
Это не очередной “калькулятор ради калькулятора”, а рабочий инструмент для тех, кто делает LLM-сервисы и агентов в проде — помогает быстро прикинуть, какая модель на каком железе реально поедет и сколько пользователей вы на ней повесите, прежде чем покупать лишние GPU или падать по OOM.
🔗 Инструмент здесь: https://apxml.com/tools/vram-calculator
Apxml
Can You Run This LLM? VRAM Calculator (Nvidia GPU and Apple Silicon)
Calculate the VRAM required to run any large language model.
🔥3
🚀 XcodeBuildMCP: когда ИИ реально управляет Xcode
XcodeBuildMCP — это MCP-сервер от Cameron Cooke, который превращает Xcode и симуляторы в набор инструментов для ИИ-агентов. Ассистент может сам собрать проект, прогнать тесты, пофиксить билд-ошибки, запустить приложение на симуляторе или девайсе и даже прогнать UI-автотесты — всё по обычным текстовым командам.
По сравнению с ios-simulator и всякими похожими это вообще ракета.
Что умеет 🔧
• 🧱 Полный цикл разработки
От создания проекта до деплоя на устройство: сборка, тесты, управление схемами, чистка билдов, логирование.
• 📱 Симуляторы и реальные устройства
Список устройств, бут симов, установка/запуск приложения, остановка, сбор логов, работа по USB и Wi-Fi.
• 🤖 Автономный агент-разработчик
Модель сама валидирует свои изменения: собирает проект, анализирует ошибки, итеративно чинит код без ручного дергания xcodebuild.
• 🧪 UI-автоматизация
Работа с элементами интерфейса в симуляторе, клики, сценарии, скриншоты — можно строить полноценные агентные UI-тесты.
• 🧩 Много клиентов
Работает с Cursor, Claude Desktop, VS Code, Windsurf и любым MCP-совместимым клиентом.
• 🆓 Открытый исходник
MIT, open source, активная разработка, ≈1.9k⭐ на GitHub.
Зачем это живым iOS-разработчикам 👇
До этого ИИ в iOS-разработке упирался в стену: он мог писать код, но не умел надежно управлять Xcode. Команды к xcodebuild и simctl часто галлюцинировались, флаги устаревали, а вы всё равно шли в Xcode руками.
XcodeBuildMCP делает другое:
ИИ не «угадывает» команды — он вызывает готовые, стабильно работающие инструменты MCP, которые знают, как правильно собрать проект, запустить тесты или симулятор. Это уже не просто «чат с подсказками кода», а полноценный агентный пайплайн под iOS/macOS.
Как попробовать 🧑💻
1. Нужны: macOS, Xcode 16+ и Node.js.
2. В конфиг MCP-клиента (Cursor / Claude Desktop / VS Code и т.п.) добавить сервер, например так:
3. Открыть папку с iOS-проектом и дальше уже говорить ассистенту в духе:
«Собери проект, запусти тесты и стартани приложение в симуляторе через XcodeBuildMCP»
— и смотреть, как ИИ реально крутит ваш Xcode.
🔗 Сайт: https://www.xcodebuildmcp.com/
🔗 GitHub: https://github.com/cameroncooke/XcodeBuildMCP
XcodeBuildMCP — это MCP-сервер от Cameron Cooke, который превращает Xcode и симуляторы в набор инструментов для ИИ-агентов. Ассистент может сам собрать проект, прогнать тесты, пофиксить билд-ошибки, запустить приложение на симуляторе или девайсе и даже прогнать UI-автотесты — всё по обычным текстовым командам.
По сравнению с ios-simulator и всякими похожими это вообще ракета.
Что умеет 🔧
• 🧱 Полный цикл разработки
От создания проекта до деплоя на устройство: сборка, тесты, управление схемами, чистка билдов, логирование.
• 📱 Симуляторы и реальные устройства
Список устройств, бут симов, установка/запуск приложения, остановка, сбор логов, работа по USB и Wi-Fi.
• 🤖 Автономный агент-разработчик
Модель сама валидирует свои изменения: собирает проект, анализирует ошибки, итеративно чинит код без ручного дергания xcodebuild.
• 🧪 UI-автоматизация
Работа с элементами интерфейса в симуляторе, клики, сценарии, скриншоты — можно строить полноценные агентные UI-тесты.
• 🧩 Много клиентов
Работает с Cursor, Claude Desktop, VS Code, Windsurf и любым MCP-совместимым клиентом.
• 🆓 Открытый исходник
MIT, open source, активная разработка, ≈1.9k⭐ на GitHub.
Зачем это живым iOS-разработчикам 👇
До этого ИИ в iOS-разработке упирался в стену: он мог писать код, но не умел надежно управлять Xcode. Команды к xcodebuild и simctl часто галлюцинировались, флаги устаревали, а вы всё равно шли в Xcode руками.
XcodeBuildMCP делает другое:
ИИ не «угадывает» команды — он вызывает готовые, стабильно работающие инструменты MCP, которые знают, как правильно собрать проект, запустить тесты или симулятор. Это уже не просто «чат с подсказками кода», а полноценный агентный пайплайн под iOS/macOS.
Как попробовать 🧑💻
1. Нужны: macOS, Xcode 16+ и Node.js.
2. В конфиг MCP-клиента (Cursor / Claude Desktop / VS Code и т.п.) добавить сервер, например так:
{
"mcpServers": {
"XcodeBuildMCP": {
"command": "npx",
"args": ["-y", "xcodebuildmcp@latest"]
}
}
}
3. Открыть папку с iOS-проектом и дальше уже говорить ассистенту в духе:
«Собери проект, запусти тесты и стартани приложение в симуляторе через XcodeBuildMCP»
— и смотреть, как ИИ реально крутит ваш Xcode.
🔗 Сайт: https://www.xcodebuildmcp.com/
🔗 GitHub: https://github.com/cameroncooke/XcodeBuildMCP
Xcodebuildmcp
XcodeBuildMCP - AI-Powered Xcode Automation
Let AI assistants build, test, and debug your iOS apps autonomously. XcodeBuildMCP bridges the gap between AI agents and Xcode.
👍2
🔥 LangGraph vs Claude Agent SDK
Полный конспект для архитекторов и разработчиков
Сегодня разбираем два ключевых подхода к построению AI-систем: графовые workflow и агентные архитектуры.
Это не маркетинговый обзор — это взгляд инженера, который строит реальные системы.
⸻
🧠 1. Две архитектурные философии
🔷 LangGraph — оркестратор процессов
Основная идея — жёстко определённый, детерминированный поток исполнения.
Работает как граф: узлы → переходы → состояние → условия.
Свойства:
• Явные nodes/edges
• Детерминированный flow
• Хорош для формальных бизнес-процессов
• Максимальный контроль и предсказуемость
⸻
🔶 Claude Agent SDK — умный агент с инструментами
Основная идея — агент сам выбирает стратегию и шаг.
Свойства:
• Агент принимает решения в реальном времени
• Поддержка tools, skills, RAG
• Идеален для ассистентов, интеграций, автоматизации
• Гибкость и модульность
⸻
⚙️ 2. Архитектурные примитивы и модель исполнения
🔷 Основная абстракция
LangGraph: граф (nodes, edges, conditions).
Claude SDK: агент + tools / skills + контекст / runtime.
⸻
🔷 Управление состоянием
LangGraph: единый глобальный state, полностью stateful.
Claude SDK: контекст + memory + внешние БД; state распределён.
⸻
🔷 Поток / Control Flow
LangGraph: явные переходы, условия, циклы, строгий контроль.
Claude SDK: решения агента + tools + переключение skills формируют flow.
⸻
🔷 Долговечность / Long-running
LangGraph: отлично подходит для долгоживущих процессов и оркестрации.
Claude SDK: агенты тоже могут быть long-running при правильной архитектуре.
⸻
🔷 Инструменты (Tools)
LangGraph: интеграция чаще требует обёрток.
Claude SDK: нативные инструменты (код, FS, API, внешние сервисы).
⸻
🔷 Модульность
LangGraph: подграфы внутри графовой модели.
Claude SDK: skills/tools — идеальная доменная декомпозиция.
⸻
🔷 Гибкость vs Контроль
LangGraph:
✔ максимальный контроль
✔ детерминированность
✔ воспроизводимость
Claude SDK:
✔ максимальная гибкость
✔ минимум boilerplate
✔ адаптивная модель принятия решений
⸻
🧩 3. Память, RAG и инструменты
🧠 Память
LangGraph:
ручная реализация (БД, VectorStore, кеши).
Claude SDK:
session state + внешние хранилища + multi-layer memory.
⸻
🔎 RAG
LangGraph:
RAG — отдельные узлы / цепочки внутри графа.
Claude SDK:
RAG = tool/skill, агент сам решает, когда вызывать retrieval.
⸻
🛠 Инструменты
LangGraph:
требуют интеграций / LangChain-обёрток.
Claude SDK:
нативная функция SDK — работа с кодом, API, FS, сторонними сервисами.
⸻
🧱 4. Когда что выбирать
✔ Выбирайте LangGraph, если:
• нужен строгий workflow;
• важен audit trail;
• процесс детерминирован;
• есть сложные ветвления и циклы;
• ближе к BPMN и формальным процедурам.
⸻
✔ Выбирайте Claude Agent SDK, если:
• строите агента, а не pipeline;
• много инструментов, API и внешних систем;
• нужна адаптивность в реальном времени;
• важна быстрая разработка и модульность.
⸻
🔄 5. Гибридный подход (часто лучший)
Оптимальная архитектура в реальных продуктах:
• Ядро бизнес-логики + жёсткий workflow → LangGraph
• “Умные” шаги, инструменты, RAG, работа с API → Claude Agent SDK
Комбинация даёт:
• контроль там, где нужен контроль;
• гибкость там, где нужна гибкость;
• масштабируемость и модульность.
⸻
🎯 Итог
LangGraph = строгость и контроль процесса.
Claude Agent SDK = интеллект и гибкость исполнения.
Правильный выбор зависит от характера задачи, а не от того, какой фреймворк моднее.
Полный конспект для архитекторов и разработчиков
Сегодня разбираем два ключевых подхода к построению AI-систем: графовые workflow и агентные архитектуры.
Это не маркетинговый обзор — это взгляд инженера, который строит реальные системы.
⸻
🧠 1. Две архитектурные философии
🔷 LangGraph — оркестратор процессов
Основная идея — жёстко определённый, детерминированный поток исполнения.
Работает как граф: узлы → переходы → состояние → условия.
Свойства:
• Явные nodes/edges
• Детерминированный flow
• Хорош для формальных бизнес-процессов
• Максимальный контроль и предсказуемость
⸻
🔶 Claude Agent SDK — умный агент с инструментами
Основная идея — агент сам выбирает стратегию и шаг.
Свойства:
• Агент принимает решения в реальном времени
• Поддержка tools, skills, RAG
• Идеален для ассистентов, интеграций, автоматизации
• Гибкость и модульность
⸻
⚙️ 2. Архитектурные примитивы и модель исполнения
🔷 Основная абстракция
LangGraph: граф (nodes, edges, conditions).
Claude SDK: агент + tools / skills + контекст / runtime.
⸻
🔷 Управление состоянием
LangGraph: единый глобальный state, полностью stateful.
Claude SDK: контекст + memory + внешние БД; state распределён.
⸻
🔷 Поток / Control Flow
LangGraph: явные переходы, условия, циклы, строгий контроль.
Claude SDK: решения агента + tools + переключение skills формируют flow.
⸻
🔷 Долговечность / Long-running
LangGraph: отлично подходит для долгоживущих процессов и оркестрации.
Claude SDK: агенты тоже могут быть long-running при правильной архитектуре.
⸻
🔷 Инструменты (Tools)
LangGraph: интеграция чаще требует обёрток.
Claude SDK: нативные инструменты (код, FS, API, внешние сервисы).
⸻
🔷 Модульность
LangGraph: подграфы внутри графовой модели.
Claude SDK: skills/tools — идеальная доменная декомпозиция.
⸻
🔷 Гибкость vs Контроль
LangGraph:
✔ максимальный контроль
✔ детерминированность
✔ воспроизводимость
Claude SDK:
✔ максимальная гибкость
✔ минимум boilerplate
✔ адаптивная модель принятия решений
⸻
🧩 3. Память, RAG и инструменты
🧠 Память
LangGraph:
ручная реализация (БД, VectorStore, кеши).
Claude SDK:
session state + внешние хранилища + multi-layer memory.
⸻
🔎 RAG
LangGraph:
RAG — отдельные узлы / цепочки внутри графа.
Claude SDK:
RAG = tool/skill, агент сам решает, когда вызывать retrieval.
⸻
🛠 Инструменты
LangGraph:
требуют интеграций / LangChain-обёрток.
Claude SDK:
нативная функция SDK — работа с кодом, API, FS, сторонними сервисами.
⸻
🧱 4. Когда что выбирать
✔ Выбирайте LangGraph, если:
• нужен строгий workflow;
• важен audit trail;
• процесс детерминирован;
• есть сложные ветвления и циклы;
• ближе к BPMN и формальным процедурам.
⸻
✔ Выбирайте Claude Agent SDK, если:
• строите агента, а не pipeline;
• много инструментов, API и внешних систем;
• нужна адаптивность в реальном времени;
• важна быстрая разработка и модульность.
⸻
🔄 5. Гибридный подход (часто лучший)
Оптимальная архитектура в реальных продуктах:
• Ядро бизнес-логики + жёсткий workflow → LangGraph
• “Умные” шаги, инструменты, RAG, работа с API → Claude Agent SDK
Комбинация даёт:
• контроль там, где нужен контроль;
• гибкость там, где нужна гибкость;
• масштабируемость и модульность.
⸻
🎯 Итог
LangGraph = строгость и контроль процесса.
Claude Agent SDK = интеллект и гибкость исполнения.
Правильный выбор зависит от характера задачи, а не от того, какой фреймворк моднее.
👍4🔥1
🤖 TeleClaude — Claude Code в твоём Telegram
TeleClaude — это Telegram-бот, который подключается к Claude Code и даёт его агентные возможности прямо в мессенджере.
Пишете боту в Telegram — под капотом работает Claude, умеющий писать код, править файлы, запускать команды и вести сессии как в нормальном IDE.
⸻
✨ Что умеет TeleClaude
⚡ Стриминг ответов
Ответы приходят «живым текстом» с обновлением сообщения, а не кусками по 4k символов — чувствуется как чат с живым ассистентом.
🧠 Сессии как в IDE
• /new [project] — создаёте новую сессию
• /sessions — список активных сессий
• /switch — переключение между задачами
• Состояние хранится в ~/.teleclaude/sessions/*.yaml, сессии легко возобновлять и анализировать историю работы.
💸 Учёт стоимости по сессиям
Bot считает, сколько токенов и денег ушло на конкретную задачу. Удобно, когда нужно понимать цену экспериментов и длительных разработок.
🛡 Approval для опасных действий
Команды, которые могут что-то поломать (rm, деплой, тяжёлые bash-шаги), идут через понятный approval-механизм, а не исполняются вслепую.
🗂 Работа с проектами и файлами
• В config.yaml настраиваются projects: myproject: /path/to/your/project
• Доступны привычные команды: /cd, /ls, /pwd, /git
• Всё это идёт через Claude Code CLI, но управлять можно прямо из Telegram.
🔌 MCP прямо из Telegram
TeleClaude умеет работать с Model Context Protocol (MCP) — можно цеплять внешние MCP-серверы (filesystem, git, HTTP и т.п.) и использовать их как инструменты агента.
Конфиг ищется в ~/.teleclaude/.mcp.json и/или общем ~/.mcp.json.
📝 Понятные аннотации действий
Форматтер красиво подписывает действия агента:
• [ path ] — чтение файла
• [ path +add/-del ] — изменения
• [⚡ command ] — исполнение bash
Легко глазами просканировать, что именно делал агент в рамках сессии.
И всё это написано на Python, поверх Claude Agents Python SDK — живой пример того, как собрать своего «оркестратора» вокруг Claude Code.
⸻
🚀 Как запустить
Дальше открываете бота в Telegram, жмёте /start, затем /new — и у вас в телефоне полноценный Claude Code: сессии, учёт стоимости, MCP, git и файловые операции.
Проект в стадии разработки и автор ждет ваши pull-requests)
🔗 Репозиторий: https://github.com/dpolishuk/teleclaude/
TeleClaude — это Telegram-бот, который подключается к Claude Code и даёт его агентные возможности прямо в мессенджере.
Пишете боту в Telegram — под капотом работает Claude, умеющий писать код, править файлы, запускать команды и вести сессии как в нормальном IDE.
⸻
✨ Что умеет TeleClaude
⚡ Стриминг ответов
Ответы приходят «живым текстом» с обновлением сообщения, а не кусками по 4k символов — чувствуется как чат с живым ассистентом.
🧠 Сессии как в IDE
• /new [project] — создаёте новую сессию
• /sessions — список активных сессий
• /switch — переключение между задачами
• Состояние хранится в ~/.teleclaude/sessions/*.yaml, сессии легко возобновлять и анализировать историю работы.
💸 Учёт стоимости по сессиям
Bot считает, сколько токенов и денег ушло на конкретную задачу. Удобно, когда нужно понимать цену экспериментов и длительных разработок.
🛡 Approval для опасных действий
Команды, которые могут что-то поломать (rm, деплой, тяжёлые bash-шаги), идут через понятный approval-механизм, а не исполняются вслепую.
🗂 Работа с проектами и файлами
• В config.yaml настраиваются projects: myproject: /path/to/your/project
• Доступны привычные команды: /cd, /ls, /pwd, /git
• Всё это идёт через Claude Code CLI, но управлять можно прямо из Telegram.
🔌 MCP прямо из Telegram
TeleClaude умеет работать с Model Context Protocol (MCP) — можно цеплять внешние MCP-серверы (filesystem, git, HTTP и т.п.) и использовать их как инструменты агента.
Конфиг ищется в ~/.teleclaude/.mcp.json и/или общем ~/.mcp.json.
📝 Понятные аннотации действий
Форматтер красиво подписывает действия агента:
• [ path ] — чтение файла
• [ path +add/-del ] — изменения
• [⚡ command ] — исполнение bash
Легко глазами просканировать, что именно делал агент в рамках сессии.
И всё это написано на Python, поверх Claude Agents Python SDK — живой пример того, как собрать своего «оркестратора» вокруг Claude Code.
⸻
🚀 Как запустить
git clone https://github.com/dpolishuk/teleclaude.git
cd teleclaude
pip install -r requirements.txt
mkdir -p ~/.teleclaude
cp config.example.yaml ~/.teleclaude/config.yaml
# правим allowed_users и projects
export TELEGRAM_BOT_TOKEN="твой_токен_бота"
python -m src.mainДальше открываете бота в Telegram, жмёте /start, затем /new — и у вас в телефоне полноценный Claude Code: сессии, учёт стоимости, MCP, git и файловые операции.
Проект в стадии разработки и автор ждет ваши pull-requests)
🔗 Репозиторий: https://github.com/dpolishuk/teleclaude/
GitHub
GitHub - dpolishuk/teleclaude
Contribute to dpolishuk/teleclaude development by creating an account on GitHub.
❤9🔥4
🔥 TeleClaude: агент в Telegram, который должен освободить вас от монитора
Для меня TeleClaude — это не просто «Claude в Telegram».
Идея в том, чтобы личный агент жил прямо в мессенджере, у вас в кармане, а не только в IDE или отдельном приложении.
⸻
🧠 Не бот, а прототип агента
Я смотрю на TeleClaude как на прототип правильного агента:
• он живёт там, где вы и так проводите время — в Telegram
• умеет работать с кодом и проектами, а не только болтать
• должен снижать время созерцания кода, а не увеличивать его
Сейчас TeleClaude работает через текст.
Но изначально он задумывается так, чтобы в будущем:
• можно было общаться с ним голосом
• диктовать задачи и правки
• получать от него отчёты и статусы
🎙 Голосовые — в планах, архитектура и идея проекта уже смотрят в эту сторону.
⸻
📱 Почему это не просто ещё один Cursor Mobile / vibe-code
Формально конкуренты понятны:
Cursor Mobile, разные мобильные IDE, vibe-code и т.п.
Но у TeleClaude другая философия:
• вы поднимаете свой сервер
• со своим проектом, своим репозиторием и своим контекстом
• агент работает с реальными большими проектами, а не демками
• Telegram — это всего лишь удобный интерфейс к этой инфраструктуре
То есть это не ещё один закрытый клиент, а шаг к тому, чтобы у вас была своя связка “сервер + агент + мессенджер”, полностью под вашим контролем.
⸻
🧵 Зачем вообще агент?
Ключевая мысль:
Агент нужен не для того, чтобы вы 16 часов в день смотрели на код.
Агент нужен, чтобы он делал работу, а вы с ним общались.
В идеальном сценарии, куда всё это целится:
• вы кидаете в TeleClaude задачу (сейчас текстом, позже — голосом)
• агент на сервере:
• правит код
• пишет тесты
• запускает команды
• ведёт сессию работы над проектом
• вы не приклеены к IDE, а управляете разработкой как диалогом
⸻
💬 Агенты могут жить в мессенджерах
TeleClaude — это по сути proof of concept подхода:
• терминальные / кодовые агенты могут жить не только в CLI или IDE
• они могут жить в мессенджерах, рядом с живыми людьми и рабочими чатами
• мессенджер становится основным интерфейсом к вашей dev-инфраструктуре
Хочется довести до состояния, где:
• IDE — это просто инструмент
• а центр управления — ваш агент в Telegram,
который знает ваш проект, ваш стек и ваш контекст
⸻
⚠️ Важно про безопасность
Сейчас TeleClaude — это именно POC:
• проект в активной разработке
• архитектура и подходы ещё обкатываются
• полноценный security-аудит не проводился
Поэтому:
🛡 Используйте TeleClaude на свой страх и риск
Не доверяйте ему критичные доступы и прод-окружения,
пока вы сами не посмотрели код и не оценили риски под свои задачи.
⸻
Если коротко:
TeleClaude — это шаг к тому, чтобы вашим главным рабочим инструментом был не редактор кода, а умный собеседник в Telegram, который пишет и правит код за вас. Всё остальное — вопрос итераций. 🚀
Для меня TeleClaude — это не просто «Claude в Telegram».
Идея в том, чтобы личный агент жил прямо в мессенджере, у вас в кармане, а не только в IDE или отдельном приложении.
⸻
🧠 Не бот, а прототип агента
Я смотрю на TeleClaude как на прототип правильного агента:
• он живёт там, где вы и так проводите время — в Telegram
• умеет работать с кодом и проектами, а не только болтать
• должен снижать время созерцания кода, а не увеличивать его
Сейчас TeleClaude работает через текст.
Но изначально он задумывается так, чтобы в будущем:
• можно было общаться с ним голосом
• диктовать задачи и правки
• получать от него отчёты и статусы
🎙 Голосовые — в планах, архитектура и идея проекта уже смотрят в эту сторону.
⸻
📱 Почему это не просто ещё один Cursor Mobile / vibe-code
Формально конкуренты понятны:
Cursor Mobile, разные мобильные IDE, vibe-code и т.п.
Но у TeleClaude другая философия:
• вы поднимаете свой сервер
• со своим проектом, своим репозиторием и своим контекстом
• агент работает с реальными большими проектами, а не демками
• Telegram — это всего лишь удобный интерфейс к этой инфраструктуре
То есть это не ещё один закрытый клиент, а шаг к тому, чтобы у вас была своя связка “сервер + агент + мессенджер”, полностью под вашим контролем.
⸻
🧵 Зачем вообще агент?
Ключевая мысль:
Агент нужен не для того, чтобы вы 16 часов в день смотрели на код.
Агент нужен, чтобы он делал работу, а вы с ним общались.
В идеальном сценарии, куда всё это целится:
• вы кидаете в TeleClaude задачу (сейчас текстом, позже — голосом)
• агент на сервере:
• правит код
• пишет тесты
• запускает команды
• ведёт сессию работы над проектом
• вы не приклеены к IDE, а управляете разработкой как диалогом
⸻
💬 Агенты могут жить в мессенджерах
TeleClaude — это по сути proof of concept подхода:
• терминальные / кодовые агенты могут жить не только в CLI или IDE
• они могут жить в мессенджерах, рядом с живыми людьми и рабочими чатами
• мессенджер становится основным интерфейсом к вашей dev-инфраструктуре
Хочется довести до состояния, где:
• IDE — это просто инструмент
• а центр управления — ваш агент в Telegram,
который знает ваш проект, ваш стек и ваш контекст
⸻
⚠️ Важно про безопасность
Сейчас TeleClaude — это именно POC:
• проект в активной разработке
• архитектура и подходы ещё обкатываются
• полноценный security-аудит не проводился
Поэтому:
🛡 Используйте TeleClaude на свой страх и риск
Не доверяйте ему критичные доступы и прод-окружения,
пока вы сами не посмотрели код и не оценили риски под свои задачи.
⸻
Если коротко:
TeleClaude — это шаг к тому, чтобы вашим главным рабочим инструментом был не редактор кода, а умный собеседник в Telegram, который пишет и правит код за вас. Всё остальное — вопрос итераций. 🚀
🔥1
🤖 DeepCode — open-source агентный кодер из HKU
Ребята из Data Intelligence Lab @ HKU выкатили DeepCode — многоагентную платформу, которая обещает превращать текст и научные статьи в продакшн-код: от алгоритмов до full-stack приложений.
🔗 GitHub: https://github.com/HKUDS/DeepCode
Что умеет
• 📄 Paper2Code — берет research-пейперы (PDF, DOC, ссылки) и пытается собрать из них рабочую реализацию алгоритма с сохранением структуры и асимптотики.
• 🌐 Text2Web — генерирует фронтенд по текстовому описанию: верстка, компоненты, интерфейс.
• ⚙️ Text2Backend — поднимает бэкенд из промпта: роуты, схемы БД, API, бизнес-логика.
• 🧪 Автоматически добавляет тесты, документацию и прогоняет статический анализ.
Почему это интересно
По их бенчмаркам на OpenAI PaperBench DeepCode:
• 🔹 обходит топовых ML-PhD по воспроизведению кода из статей,
• 🔹 сильно обгоняет коммерческие код-агенты вроде Cursor / Claude Code / Codex по качеству воспроизведения решений.
Главная фишка — не «еще один LLM», а агентная архитектура:
• центральный оркестратор,
• отдельные агенты под разбор требований, генерацию кода, отладку,
• свой CodeRAG по большому корпусу кода, чтобы подтягивать паттерны и библиотеки.
Как посмотреть
• Есть CLI для терминальных маньяков и CI/CD.
• Есть web-интерфейс с дашбордом и прогресс-баром задач.
• Лицензия MIT, так что можно встраивать в свои пайплайны и экспериментировать как с полноценным open-source конкурентом привычных AI-IDE.
Если вы уже играете с Claude Code / Cursor и любите многоагентные пайплайны, DeepCode — хороший кандидат, чтобы посмотреть, как «бумага → код → прототип» может выглядеть в полностью open-source варианте.
Ребята из Data Intelligence Lab @ HKU выкатили DeepCode — многоагентную платформу, которая обещает превращать текст и научные статьи в продакшн-код: от алгоритмов до full-stack приложений.
🔗 GitHub: https://github.com/HKUDS/DeepCode
Что умеет
• 📄 Paper2Code — берет research-пейперы (PDF, DOC, ссылки) и пытается собрать из них рабочую реализацию алгоритма с сохранением структуры и асимптотики.
• 🌐 Text2Web — генерирует фронтенд по текстовому описанию: верстка, компоненты, интерфейс.
• ⚙️ Text2Backend — поднимает бэкенд из промпта: роуты, схемы БД, API, бизнес-логика.
• 🧪 Автоматически добавляет тесты, документацию и прогоняет статический анализ.
Почему это интересно
По их бенчмаркам на OpenAI PaperBench DeepCode:
• 🔹 обходит топовых ML-PhD по воспроизведению кода из статей,
• 🔹 сильно обгоняет коммерческие код-агенты вроде Cursor / Claude Code / Codex по качеству воспроизведения решений.
Главная фишка — не «еще один LLM», а агентная архитектура:
• центральный оркестратор,
• отдельные агенты под разбор требований, генерацию кода, отладку,
• свой CodeRAG по большому корпусу кода, чтобы подтягивать паттерны и библиотеки.
Как посмотреть
• Есть CLI для терминальных маньяков и CI/CD.
• Есть web-интерфейс с дашбордом и прогресс-баром задач.
• Лицензия MIT, так что можно встраивать в свои пайплайны и экспериментировать как с полноценным open-source конкурентом привычных AI-IDE.
Если вы уже играете с Claude Code / Cursor и любите многоагентные пайплайны, DeepCode — хороший кандидат, чтобы посмотреть, как «бумага → код → прототип» может выглядеть в полностью open-source варианте.
GitHub
GitHub - HKUDS/DeepCode: "DeepCode: Open Agentic Coding (Paper2Code & Text2Web & Text2Backend)"
"DeepCode: Open Agentic Coding (Paper2Code & Text2Web & Text2Backend)" - HKUDS/DeepCode
🔥6
Все носятся с MCP, плагинами и “AI-SDK для всего”, а про самое простое часто забывают:
агенты уже офигенно умеют работать с обычными CLI-утилитами — если у них есть нормальный --help и внятные описания команд. 🧰
По сути, любой CLI с хорошим help-текстом = готовый “инструмент” для агента:
• gh (GitHub CLI)
• aws (AWS CLI)
• yc (Yandex Cloud CLI)
• gcloud, kubectl, docker, terraform и т.д.
Модели умеют:
• читать ... --help
• выбирать нужную команду
• подставлять аргументы
• запускать её
• смотреть вывод и на основе этого вызывать следующую команду
То есть ровно то, что вы вручную делаете в терминале, только без вашего участия.
⸻
Что нужно от вас на самом деле
Никакой магии, всё упирается в три вещи:
1. Дать агенту доступ к shell
В агент-рантайме/IDE нужно включить “command line” / “terminal” / “shell” tool.
Это может быть:
• встроенный tool типа “execute_command”
• или ваш прокси-скрипт, который запускает CLI в нужном окружении.
2. Правильно “накормить” его токенами 🔑
Всё как у людей:
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
• GITHUB_TOKEN
• YC_TOKEN, YC_CLOUD_ID, YC_FOLDER_ID
• любые другие env-переменные/конфиги для вашего CLI
Агенту не нужно “знать” токен — ему нужен уже настроенный CLI, который просто работает:
Если это в вашем терминале уже работает — значит, агенту достаточно дать тот же самый контекст.
3. Минимальные рамки безопасности 🧱
• Ограничить рабочую директорию (чтоб не полез во всё подряд).
• Выдать минимально необходимый набор прав для токенов.
• По возможности сначала гонять всё это в sandbox / staging.
⸻
Что агент может делать за вас (грязная работа) 🧽
После этого агент может сам:
• создавать и настраивать инфраструктуру через CLI
(сети, бакеты, функции, контейнеры, кластера)
• деплоить обновления, прогонять миграции, проверять статус сервисов
• читать логи, искать ошибки, фильтровать по времени/запросам
• разруливать рутину с GitHub:
• создавать репозитории
• открывать PR’ы
• вешать лейблы
• мёрджить по правилам
• гонять скрипты обслуживания: бэкапы, ротация, массовые операции
Проще говоря, всё, что вы уже умеете делать через CLI, может делать агент — последовательно, без усталости и с оглядкой на --help.
⸻
Главная мысль
Прежде чем придумывать сложные кастомные интеграции, MCP-серверы и специальные API, просто спросите себя:
“А у этой штуки есть нормальный CLI с хорошим --help?”
Если да — то у вас уже есть полноценный интерфейс для агента.
Добавили токены → включили shell-tool → описали в системном промпте рамки →
и он спокойно делает за вас всю грязную терминальную работу. 💻🤖
агенты уже офигенно умеют работать с обычными CLI-утилитами — если у них есть нормальный --help и внятные описания команд. 🧰
По сути, любой CLI с хорошим help-текстом = готовый “инструмент” для агента:
• gh (GitHub CLI)
• aws (AWS CLI)
• yc (Yandex Cloud CLI)
• gcloud, kubectl, docker, terraform и т.д.
Модели умеют:
• читать ... --help
• выбирать нужную команду
• подставлять аргументы
• запускать её
• смотреть вывод и на основе этого вызывать следующую команду
То есть ровно то, что вы вручную делаете в терминале, только без вашего участия.
⸻
Что нужно от вас на самом деле
Никакой магии, всё упирается в три вещи:
1. Дать агенту доступ к shell
В агент-рантайме/IDE нужно включить “command line” / “terminal” / “shell” tool.
Это может быть:
• встроенный tool типа “execute_command”
• или ваш прокси-скрипт, который запускает CLI в нужном окружении.
2. Правильно “накормить” его токенами 🔑
Всё как у людей:
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
• GITHUB_TOKEN
• YC_TOKEN, YC_CLOUD_ID, YC_FOLDER_ID
• любые другие env-переменные/конфиги для вашего CLI
Агенту не нужно “знать” токен — ему нужен уже настроенный CLI, который просто работает:
aws s3 ls
gh repo list
yc vm listЕсли это в вашем терминале уже работает — значит, агенту достаточно дать тот же самый контекст.
3. Минимальные рамки безопасности 🧱
• Ограничить рабочую директорию (чтоб не полез во всё подряд).
• Выдать минимально необходимый набор прав для токенов.
• По возможности сначала гонять всё это в sandbox / staging.
⸻
Что агент может делать за вас (грязная работа) 🧽
После этого агент может сам:
• создавать и настраивать инфраструктуру через CLI
(сети, бакеты, функции, контейнеры, кластера)
• деплоить обновления, прогонять миграции, проверять статус сервисов
• читать логи, искать ошибки, фильтровать по времени/запросам
• разруливать рутину с GitHub:
• создавать репозитории
• открывать PR’ы
• вешать лейблы
• мёрджить по правилам
• гонять скрипты обслуживания: бэкапы, ротация, массовые операции
Проще говоря, всё, что вы уже умеете делать через CLI, может делать агент — последовательно, без усталости и с оглядкой на --help.
⸻
Главная мысль
Прежде чем придумывать сложные кастомные интеграции, MCP-серверы и специальные API, просто спросите себя:
“А у этой штуки есть нормальный CLI с хорошим --help?”
Если да — то у вас уже есть полноценный интерфейс для агента.
Добавили токены → включили shell-tool → описали в системном промпте рамки →
и он спокойно делает за вас всю грязную терминальную работу. 💻🤖
👍4🤔1
🛠 Coding Tool Helper: быстрый буст для GLM Coding Plan + Claude Code
Z.AI тихо завезли очень полезную штуку для vibecoding-стека — Coding Tool Helper. Это CLI-ассистент, который одним мастером настраивает вам GLM Coding Plan в Claude Code и при этом помогает управлять MCP-серверами и конфигурацией, вместо того чтобы руками прописывать env’ы и ковырять конфиги.
Что это такое
• CLI-помощник для код-инструментов (в первую очередь Claude Code).
• Умеет подтянуть GLM Coding Plan, прописать ключ, подхватить/поставить нужные тулзы и настроить MCP.
• Работает через npm-пакет @z_ai/coding-helper, нужен Node.js ≥ 18.
🧩 Что он делает за вас
• Показывает интерактивный wizard в терминале: выбираете язык интерфейса, план, вводите API-ключ, отмечаете какие coding tools хотите менеджить.
• Может автоматически установить и сконфигурировать Claude Code, если он ещё не стоит.
• Настраивает MCP-сервисы (Vision/Web/Search и т.п.) и сохраняет конфиг локально.
• Поддерживает несколько языков интерфейса (i18n) — удобно, если команда разноязычная.
🚀 Как попробовать
Самый простой старт — без глобальной установки:
npx @z_ai/coding-helper
Дальше просто кликаете стрелочками по мастеру, и на выходе получаете: GLM-4.6/4.5 уже прописан в Claude Code, ключ подхвачен, MCP-серверы подключены — можно сразу идти писать код.
🔗 Документация:
https://docs.z.ai/devpack/tool/coding-tool-helper
Z.AI тихо завезли очень полезную штуку для vibecoding-стека — Coding Tool Helper. Это CLI-ассистент, который одним мастером настраивает вам GLM Coding Plan в Claude Code и при этом помогает управлять MCP-серверами и конфигурацией, вместо того чтобы руками прописывать env’ы и ковырять конфиги.
Что это такое
• CLI-помощник для код-инструментов (в первую очередь Claude Code).
• Умеет подтянуть GLM Coding Plan, прописать ключ, подхватить/поставить нужные тулзы и настроить MCP.
• Работает через npm-пакет @z_ai/coding-helper, нужен Node.js ≥ 18.
🧩 Что он делает за вас
• Показывает интерактивный wizard в терминале: выбираете язык интерфейса, план, вводите API-ключ, отмечаете какие coding tools хотите менеджить.
• Может автоматически установить и сконфигурировать Claude Code, если он ещё не стоит.
• Настраивает MCP-сервисы (Vision/Web/Search и т.п.) и сохраняет конфиг локально.
• Поддерживает несколько языков интерфейса (i18n) — удобно, если команда разноязычная.
🚀 Как попробовать
Самый простой старт — без глобальной установки:
npx @z_ai/coding-helper
Дальше просто кликаете стрелочками по мастеру, и на выходе получаете: GLM-4.6/4.5 уже прописан в Claude Code, ключ подхвачен, MCP-серверы подключены — можно сразу идти писать код.
🔗 Документация:
https://docs.z.ai/devpack/tool/coding-tool-helper
👍2🔥2
🤝 Open Agent Protocol (OAP) и AGNTCY — кирпичики “Интернета агентов”
С мультиагентными системами сейчас та же история, что когда-то с вебом: каждый варится в своём фреймворке, а экосистема тонет в зоопарке протоколов. OAP и AGNTCY — попытка навести порядок и собрать общий “Интернет агентов”.
⸻
🧩 OAP — “HTTP” для агентов
Open Agent Protocol (OAP) — открытый комьюнити-драйв стандарт для общения агентов между собой и с инструментами, независимо от фреймворка. Идея простая: дать универсальный API, чтобы агент мог:
• передать задачу другому агенту,
• получить статус выполнения и логи,
• забрать результаты в стандартном формате,
• объявить вовне свои возможности и схему (что умеет, какие входы/выходы).
Если упрощать — OAP хочет быть тем же, чем стал HTTP для сайтов: общим языком для любых “агентных сервисов”, поверх которого вы уже строите свои графы, рантаймы и оркестраторы.
Подробнее: сайт OAP Foundation
⸻
🏗 AGNTCY — инфраструктура “Интернета агентов”
AGNTCY — это уже не один протокол, а open-source стек инфраструктуры для “Internet of Agents”: discovery, identity, messaging и observability между агентами разных вендоров и фреймворков (LangGraph, LangChain, CrewAI, LlamaIndex и т.д.).
Его двигают Cisco, LangChain, Galileo и ко под зонтиком Linux Foundation как открытый стандарт для мультиагентных систем.
Технический фундамент AGNTCY:
• OASF (Open Agent Schema Framework) — как OpenAPI, но для агентов:
описывает capabilities, входы/выходы, эндпоинты, метрики. Поддерживает A2A-агентов, MCP-серверы и может расширяться под другие форматы.
• ACP (Agent Connect Protocol) — безопасный протокол подключения и общения:
как подключиться к агенту, запустить ран, подписаться на события, мониторить выполнение.
AGNTCY, по сути, строит “городскую инфраструктуру” для агентов: есть правила регистрации (OASF), линии связи и протоколы (ACP), единые механизмы мониторинга и управления.
Подробнее:
• сайт: agntcy.org
• дока/спеки: docs.agntcy.org
⸻
🧠 Зачем это практику
Если вы строите своих агентов / ассистентов / MCP-инструменты, OAP + AGNTCY дают:
• интероперабельность — агенты и инструменты в разных фреймворках могут общаться по единому API, без жёсткого vendor lock-in;
• единый слой discovery и описаний (OASF) — агент становится “ресурсом сети”, который можно найти, оценить и подключить;
• готовую инфраструктуру для продакшена: трассировка, метрики, безопасность и управление multi-agent workflow’ами на уровне экосистемы, а не только вашего кода.
Короче, это шаг к тому, чтобы агенты стали не локальными игрушками внутри одного рантайма, а полноценными участниками распределённого “Интернета агентов”.
С мультиагентными системами сейчас та же история, что когда-то с вебом: каждый варится в своём фреймворке, а экосистема тонет в зоопарке протоколов. OAP и AGNTCY — попытка навести порядок и собрать общий “Интернет агентов”.
⸻
🧩 OAP — “HTTP” для агентов
Open Agent Protocol (OAP) — открытый комьюнити-драйв стандарт для общения агентов между собой и с инструментами, независимо от фреймворка. Идея простая: дать универсальный API, чтобы агент мог:
• передать задачу другому агенту,
• получить статус выполнения и логи,
• забрать результаты в стандартном формате,
• объявить вовне свои возможности и схему (что умеет, какие входы/выходы).
Если упрощать — OAP хочет быть тем же, чем стал HTTP для сайтов: общим языком для любых “агентных сервисов”, поверх которого вы уже строите свои графы, рантаймы и оркестраторы.
Подробнее: сайт OAP Foundation
⸻
🏗 AGNTCY — инфраструктура “Интернета агентов”
AGNTCY — это уже не один протокол, а open-source стек инфраструктуры для “Internet of Agents”: discovery, identity, messaging и observability между агентами разных вендоров и фреймворков (LangGraph, LangChain, CrewAI, LlamaIndex и т.д.).
Его двигают Cisco, LangChain, Galileo и ко под зонтиком Linux Foundation как открытый стандарт для мультиагентных систем.
Технический фундамент AGNTCY:
• OASF (Open Agent Schema Framework) — как OpenAPI, но для агентов:
описывает capabilities, входы/выходы, эндпоинты, метрики. Поддерживает A2A-агентов, MCP-серверы и может расширяться под другие форматы.
• ACP (Agent Connect Protocol) — безопасный протокол подключения и общения:
как подключиться к агенту, запустить ран, подписаться на события, мониторить выполнение.
AGNTCY, по сути, строит “городскую инфраструктуру” для агентов: есть правила регистрации (OASF), линии связи и протоколы (ACP), единые механизмы мониторинга и управления.
Подробнее:
• сайт: agntcy.org
• дока/спеки: docs.agntcy.org
⸻
🧠 Зачем это практику
Если вы строите своих агентов / ассистентов / MCP-инструменты, OAP + AGNTCY дают:
• интероперабельность — агенты и инструменты в разных фреймворках могут общаться по единому API, без жёсткого vendor lock-in;
• единый слой discovery и описаний (OASF) — агент становится “ресурсом сети”, который можно найти, оценить и подключить;
• готовую инфраструктуру для продакшена: трассировка, метрики, безопасность и управление multi-agent workflow’ами на уровне экосистемы, а не только вашего кода.
Короче, это шаг к тому, чтобы агенты стали не локальными игрушками внутри одного рантайма, а полноценными участниками распределённого “Интернета агентов”.
👍2🤪1
PSI как базовая «шина приватных данных» для AI-агентов
Когда начинаешь связывать несколько AI-агентов между собой, быстро упираешься в вопрос:
как обмениваться инсайтами, не раскрывая сырые данные?
Здесь в игру вступает PSI (Private Set Intersection) и MPC-фреймворки.
⸻
PSI по сути
PSI позволяет нескольким сторонам узнать пересечение их множеств (например, общих пользователей)
без раскрытия остальной части списков.
В мультиагентных системах это выглядит так:
• каждый агент хранит свою базу (пользователи, сделки, события);
• через PSI они узнают только, кто у них общий;
• сырые данные за пределами пересечения никто не видит.
Фактически PSI становится приватной шиной сопоставления идентификаторов между агентами.
⸻
Дальше — Secure MPC: вычисления поверх зашифрованных данных
PSI решает «кто пересекается?».
Но обычно нужно ещё и что-то посчитать поверх пересечения: скоринг, агрегаты, фичи для моделей и т.д.
Это делает Secure Multi-Party Computation (MPC) — совместные вычисления функции f(x₁, x₂,…)
так, чтобы участники не раскрывали друг другу свои входные данные.
Ключевые фреймворки:
• MP-SPDZ
• Поддерживает 34+ вариантов MPC-протоколов под разные модели безопасности.
• Даёт единый high-level интерфейс, позволяя выбирать протокол под задачу (скорость / угрозы / инфраструктура).
• ABY Framework
• Комбинирует три представления:
• Arithmetic sharing — удобно для матриц и ML,
• Boolean sharing — удобно для логики и сравнений,
• Yao’s garbled circuits — универсальный вариант.
• Важное свойство — дешёвые конверсии между представлениями, что позволяет оптимизировать вычисления.
⸻
Circuit-PSI: когда пересечение — это только начало
Circuit-PSI идёт дальше:
• стороны выполняют PSI,
• но пересечение сразу остаётся в виде secret-shared представления,
• и поверх него тут же запускается MPC-вычисление нужной функции.
То есть агенты никогда не видят сами элементы пересечения, только итоговый результат вычислений
(скоринг, агрегаты, метрики и т.д.).
⸻
Как это встраивается в архитектуру AI-агентов
Базовый паттерн для приватных мультиагентных / федеративных сценариев:
1. PSI / Circuit-PSI
• агенты приватно синхронизируют пересечение по user_id / device_id / merchant_id и т.п.
2. MPC (MP-SPDZ / ABY)
• поверх этого пересечения считаются скоринги, статистика, обучаются/обновляются модели.
• выбирается протокол под требования регуляции и производительности.
3. Агентный оркестратор
• один агент отвечает за выбор протоколов и запуск криптопайплайна,
• предметные агенты (риск, маркетинг, рекомендации) получают только безопасный агрегированный результат,
• сырые данные сторон по-прежнему изолированы.
⸻
Итог:
PSI + MPC (MP-SPDZ, ABY, Circuit-PSI) — это слой, который позволяет AI-агентам сотрудничать на данных
в духе «федеративной аналитики», не превращая систему в ещё один централизованный «пылесос данных».
Когда начинаешь связывать несколько AI-агентов между собой, быстро упираешься в вопрос:
как обмениваться инсайтами, не раскрывая сырые данные?
Здесь в игру вступает PSI (Private Set Intersection) и MPC-фреймворки.
⸻
PSI по сути
PSI позволяет нескольким сторонам узнать пересечение их множеств (например, общих пользователей)
без раскрытия остальной части списков.
В мультиагентных системах это выглядит так:
• каждый агент хранит свою базу (пользователи, сделки, события);
• через PSI они узнают только, кто у них общий;
• сырые данные за пределами пересечения никто не видит.
Фактически PSI становится приватной шиной сопоставления идентификаторов между агентами.
⸻
Дальше — Secure MPC: вычисления поверх зашифрованных данных
PSI решает «кто пересекается?».
Но обычно нужно ещё и что-то посчитать поверх пересечения: скоринг, агрегаты, фичи для моделей и т.д.
Это делает Secure Multi-Party Computation (MPC) — совместные вычисления функции f(x₁, x₂,…)
так, чтобы участники не раскрывали друг другу свои входные данные.
Ключевые фреймворки:
• MP-SPDZ
• Поддерживает 34+ вариантов MPC-протоколов под разные модели безопасности.
• Даёт единый high-level интерфейс, позволяя выбирать протокол под задачу (скорость / угрозы / инфраструктура).
• ABY Framework
• Комбинирует три представления:
• Arithmetic sharing — удобно для матриц и ML,
• Boolean sharing — удобно для логики и сравнений,
• Yao’s garbled circuits — универсальный вариант.
• Важное свойство — дешёвые конверсии между представлениями, что позволяет оптимизировать вычисления.
⸻
Circuit-PSI: когда пересечение — это только начало
Circuit-PSI идёт дальше:
• стороны выполняют PSI,
• но пересечение сразу остаётся в виде secret-shared представления,
• и поверх него тут же запускается MPC-вычисление нужной функции.
То есть агенты никогда не видят сами элементы пересечения, только итоговый результат вычислений
(скоринг, агрегаты, метрики и т.д.).
⸻
Как это встраивается в архитектуру AI-агентов
Базовый паттерн для приватных мультиагентных / федеративных сценариев:
1. PSI / Circuit-PSI
• агенты приватно синхронизируют пересечение по user_id / device_id / merchant_id и т.п.
2. MPC (MP-SPDZ / ABY)
• поверх этого пересечения считаются скоринги, статистика, обучаются/обновляются модели.
• выбирается протокол под требования регуляции и производительности.
3. Агентный оркестратор
• один агент отвечает за выбор протоколов и запуск криптопайплайна,
• предметные агенты (риск, маркетинг, рекомендации) получают только безопасный агрегированный результат,
• сырые данные сторон по-прежнему изолированы.
⸻
Итог:
PSI + MPC (MP-SPDZ, ABY, Circuit-PSI) — это слой, который позволяет AI-агентам сотрудничать на данных
в духе «федеративной аналитики», не превращая систему в ещё один централизованный «пылесос данных».
👍2🔥1
🧩 Axiom — боевые Claude Code-агенты для iOS/xOS
Если вы пишете под iOS / iPadOS / watchOS / tvOS и уже пользуетесь Claude Code, обязательно посмотрите Axiom от Charles Wiltgen. Это не просто «примерчики», а целая сборка агентов и skills, обкатанных на реальных прод-кейсах: дедлайны App Store, утечки памяти у живых пользователей, миграции баз с сотнями тысяч юзеров.
Что внутри 👇
• 🧠 Apple Intelligence / Foundation Models
Готовые паттерны под on-device AI: structured output через @Generable, стриминг, tool calling, обвязка вокруг всех ключевых примеров WWDC 2025.
• 🎨 Современный UI и SwiftUI
Liquid Glass, новые фичи SwiftUI 26, профилирование производительности, разбор «почему этот вью тормозит», устойчивые UI-тесты (меньше флейков).
• ♿ Доступность
Скиллы, которые помогают ловить проблемы с VoiceOver, Dynamic Type, WCAG и тем, что может завалить ревью в App Store.
• 🐞 Отладка и перф
BUILD FAILED, зависший симулятор, зомби-процессы, гонки данных в Swift 6 concurrency, профилирование через Instruments — под всё это есть отдельные skills.
• 💾 Хранилища и миграции
Core Data, SwiftData, SQLiteData, GRDB, миграции без потери данных, переезд с Realm и SwiftData на другие стеки, CloudKit-синхронизация.
• 🌐 Сеть и аудио
Networking (включая UDP/TCP, Network.framework), AVFoundation/пространственное аудио, бит-перфектный вывод.
Методология тоже интересная: автор жёстко завязан на TDD + “red/green/refactor”, каждый skill — это дисциплинирующий workflow, а не «магическая подсказка». Много готовых checklists и куски кода в формате «что работает / что ломает прод».
⚠️ Сейчас это preview-релиз под MIT-лицензией, автор просит фидбек — хороший момент зайти пораньше и построить свой iOS-стек вокруг Axiom + Claude Code.
🔗 Сайт: https://charleswiltgen.github.io/Axiom/
Если вы пишете под iOS / iPadOS / watchOS / tvOS и уже пользуетесь Claude Code, обязательно посмотрите Axiom от Charles Wiltgen. Это не просто «примерчики», а целая сборка агентов и skills, обкатанных на реальных прод-кейсах: дедлайны App Store, утечки памяти у живых пользователей, миграции баз с сотнями тысяч юзеров.
Что внутри 👇
• 🧠 Apple Intelligence / Foundation Models
Готовые паттерны под on-device AI: structured output через @Generable, стриминг, tool calling, обвязка вокруг всех ключевых примеров WWDC 2025.
• 🎨 Современный UI и SwiftUI
Liquid Glass, новые фичи SwiftUI 26, профилирование производительности, разбор «почему этот вью тормозит», устойчивые UI-тесты (меньше флейков).
• ♿ Доступность
Скиллы, которые помогают ловить проблемы с VoiceOver, Dynamic Type, WCAG и тем, что может завалить ревью в App Store.
• 🐞 Отладка и перф
BUILD FAILED, зависший симулятор, зомби-процессы, гонки данных в Swift 6 concurrency, профилирование через Instruments — под всё это есть отдельные skills.
• 💾 Хранилища и миграции
Core Data, SwiftData, SQLiteData, GRDB, миграции без потери данных, переезд с Realm и SwiftData на другие стеки, CloudKit-синхронизация.
• 🌐 Сеть и аудио
Networking (включая UDP/TCP, Network.framework), AVFoundation/пространственное аудио, бит-перфектный вывод.
Методология тоже интересная: автор жёстко завязан на TDD + “red/green/refactor”, каждый skill — это дисциплинирующий workflow, а не «магическая подсказка». Много готовых checklists и куски кода в формате «что работает / что ломает прод».
⚠️ Сейчас это preview-релиз под MIT-лицензией, автор просит фидбек — хороший момент зайти пораньше и построить свой iOS-стек вокруг Axiom + Claude Code.
🔗 Сайт: https://charleswiltgen.github.io/Axiom/
charleswiltgen.github.io
Axiom
Battle-tested Claude Code skills, commands, and references for Apple platform development
🔥3
🚀 GLM-4.6V вышел: “глаза” для агентов и кодеров + как завести его в Claude Code
Z.ai выкатили GLM-4.6V — новую линейку open-source VLM-моделей (Vision-Language), заточенную под агентов и frontend-автоматизацию, а не просто “ответить по картинке”.
Ключевые фишки:
• 🧠 Две версии:
• GLM-4.6V (≈106B) — тяжёлый флагман под кластер.
• GLM-4.6V-Flash (9B) — облегчённый вариант под локальные / дешёвые деплои.
• 📚 128K контекст для мультимодальных задач: длинные документы как картинки/PDF, сложные UI-макеты, цепочки тулов без обрезки мыслей.
• 🛠 Нативный function calling по картинкам и видео — скриншот/фрейм сразу идёт в tool, без лишнего “картинка → текст → prompt”.
• 🎨 Фокус на frontend replication & visual interaction: “скрин → код”, понимание диаграмм, UI-diff, анализ графиков и дашбордов.
Отдельно: Z.ai официально позиционирует GLM-4.6V как базовый визуальный движок для агентных workflows (vision + tools).
Z.ai выкатили GLM-4.6V — новую линейку open-source VLM-моделей (Vision-Language), заточенную под агентов и frontend-автоматизацию, а не просто “ответить по картинке”.
Ключевые фишки:
• 🧠 Две версии:
• GLM-4.6V (≈106B) — тяжёлый флагман под кластер.
• GLM-4.6V-Flash (9B) — облегчённый вариант под локальные / дешёвые деплои.
• 📚 128K контекст для мультимодальных задач: длинные документы как картинки/PDF, сложные UI-макеты, цепочки тулов без обрезки мыслей.
• 🛠 Нативный function calling по картинкам и видео — скриншот/фрейм сразу идёт в tool, без лишнего “картинка → текст → prompt”.
• 🎨 Фокус на frontend replication & visual interaction: “скрин → код”, понимание диаграмм, UI-diff, анализ графиков и дашбордов.
Отдельно: Z.ai официально позиционирует GLM-4.6V как базовый визуальный движок для агентных workflows (vision + tools).
👍2🔥1
Как запускать GLM-4.6V в связке с Claude Code
Важно: в кодинге рулит GLM-4.6 (текст), а GLM-4.6V едет “под капотом” Vision MCP-сервера. То есть в Claude Code ты используешь GLM-4.6 как основного “кодера”, а все визуальные задачи отдаёшь Vision MCP, который уже ходит в GLM-4.6V.
1️⃣ Подключить GLM-4.6 к Claude Code
1. Оформляешь GLM Coding Plan (Lite от ~$3/мес, заточен под Claude Code / Cline / OpenCode).
2. Берёшь API-ключ в кабинете Z.ai.
3. Ставишь Claude Code (если ещё нет): npm install -g @anthropic-ai/claude-code
4. Запускаешь офиц. скрипт Z.ai, который сам пропатчит
2️⃣ Включить GLM-4.6V через Vision MCP Server
Теперь добавляем глаза — Vision MCP Server, который уже использует GLM-4.6V под капотом.
1. Node.js ≥ 22 локально.
2. Одной командой регистрируем MCP-сервер в Claude Code:
Vision MCP даёт набор тулов поверх GLM-4.6V:
-
-
-
-
-
-
-
---
3️⃣ Как этим пользоваться в Claude Code на практике
После того как Coding Plan и Vision MCP заведены:
1. В корне проекта кладёшь, например,
2. Открываешь Claude Code:
3. В диалоге пишешь что-то в духе:
• UI → код:
Преврати ui-dashboard.png в адаптивную React + Tailwind страницу с теми же блоками и сеткой. Используй MCP-инструмент ui_to_artifact.
• Анализ диаграммы:
Разбери архитектуру на system-arch.png как understand_technical_diagram, выпиши сервисы, очереди и БД, а потом предложи план миграции на микросервисы.
• Разбор графиков / метрик:
Проанализируй metrics.png через analyze_data_visualization и опиши, что происходит с латентностью и ошибками за последнюю неделю.
Claude Code сам дернет Vision MCP, а тот — GLM-4.6V. Ты при этом остаёшься в привычном flow: запрос → tools → коммиты/патчи в репо.
⸻
4️⃣ А можно прямым API вместо MCP?
Если вдруг хочешь чистый GLM-4.6V как модель (например, для своего сервиса/агента), есть варианты:
• Z.ai / BigModel — родной API (Vision endpoint).
• Novita AI, OpenRouter — дают GLM-4.6V по OpenAI-совместимому API с роутингом/биллингом.
В теории можно завернуть такой endpoint в свой “Anthropic-совместимый” прокси и подложить его Claude Code через ANTHROPIC_BASE_URL + модель glm-4.6v. Но официально для Claude Code сейчас рекомендуемый путь именно через GLM Coding Plan + Vision MCP, потому что там уже готово:
• нормальные лимиты,
• стабильный MCP-сервер,
• и гарантированно правильное использование GLM-4.6V (vision) + GLM-4.6 (code).
Важно: в кодинге рулит GLM-4.6 (текст), а GLM-4.6V едет “под капотом” Vision MCP-сервера. То есть в Claude Code ты используешь GLM-4.6 как основного “кодера”, а все визуальные задачи отдаёшь Vision MCP, который уже ходит в GLM-4.6V.
1️⃣ Подключить GLM-4.6 к Claude Code
1. Оформляешь GLM Coding Plan (Lite от ~$3/мес, заточен под Claude Code / Cline / OpenCode).
2. Берёшь API-ключ в кабинете Z.ai.
3. Ставишь Claude Code (если ещё нет): npm install -g @anthropic-ai/claude-code
4. Запускаешь офиц. скрипт Z.ai, который сам пропатчит
~/.claude/settings.json:curl -O "https://cdn.bigmodel.cn/install/claude_code_zai_env.sh" && bash ./claude_code_zai_env.sh2️⃣ Включить GLM-4.6V через Vision MCP Server
Теперь добавляем глаза — Vision MCP Server, который уже использует GLM-4.6V под капотом.
1. Node.js ≥ 22 локально.
2. Одной командой регистрируем MCP-сервер в Claude Code:
claude mcp add -s user zai-mcp-server \
--env Z_AI_API_KEY=your_api_key Z_AI_MODE=ZAI \
-- npx -y "@z_ai/mcp-server"Vision MCP даёт набор тулов поверх GLM-4.6V:
-
ui_to_artifact — скрин → код/спека/описание (идеально под frontend-генерацию). -
extract_text_from_screenshot — OCR любых скринов (код, логи, ошибки, документация). -
diagnose_error_screenshot — анализ скринов с ошибками/стектрейсами. -
understand_technical_diagram — архитектуры, UML, ER и т.п. -
analyze_data_visualization — чтение чартов и дашбордов. -
ui_diff_check — сравнение двух UI-скринов. -
image_analysis / video_analysis — общие визуальные задачи и короткие видео. ---
3️⃣ Как этим пользоваться в Claude Code на практике
После того как Coding Plan и Vision MCP заведены:
1. В корне проекта кладёшь, например,
ui-dashboard.png. 2. Открываешь Claude Code:
cd /your/project
claude3. В диалоге пишешь что-то в духе:
• UI → код:
Преврати ui-dashboard.png в адаптивную React + Tailwind страницу с теми же блоками и сеткой. Используй MCP-инструмент ui_to_artifact.
• Анализ диаграммы:
Разбери архитектуру на system-arch.png как understand_technical_diagram, выпиши сервисы, очереди и БД, а потом предложи план миграции на микросервисы.
• Разбор графиков / метрик:
Проанализируй metrics.png через analyze_data_visualization и опиши, что происходит с латентностью и ошибками за последнюю неделю.
Claude Code сам дернет Vision MCP, а тот — GLM-4.6V. Ты при этом остаёшься в привычном flow: запрос → tools → коммиты/патчи в репо.
⸻
4️⃣ А можно прямым API вместо MCP?
Если вдруг хочешь чистый GLM-4.6V как модель (например, для своего сервиса/агента), есть варианты:
• Z.ai / BigModel — родной API (Vision endpoint).
• Novita AI, OpenRouter — дают GLM-4.6V по OpenAI-совместимому API с роутингом/биллингом.
В теории можно завернуть такой endpoint в свой “Anthropic-совместимый” прокси и подложить его Claude Code через ANTHROPIC_BASE_URL + модель glm-4.6v. Но официально для Claude Code сейчас рекомендуемый путь именно через GLM Coding Plan + Vision MCP, потому что там уже готово:
• нормальные лимиты,
• стабильный MCP-сервер,
• и гарантированно правильное использование GLM-4.6V (vision) + GLM-4.6 (code).
Z.AI DEVELOPER DOCUMENT
Claude Code - Z.AI DEVELOPER DOCUMENT
Methods for integrating the latest GLM-4.5 series models from Z.AI with Claude Code
🤔2🔥1
🧩 Don’t build agents, build skills
У Anthropic вышел очень классный доклад Barry Zhang & Mahesh Murag — мысль простая, но переворачивает подход к агентам:
не надо сразу строить “суперагента на все случаи жизни”, нужно строить библиотеку скиллов.
Что такое skill в их понимании:
• это оформленный сценарий работы: инструкция + примеры + (опционально) код;
• он решает одну конкретную задачу: написать отчёт по шаблону, разобрать выгрузку, оформить предложение клиенту;
• модель сама подбирает нужный skill и подгружает только релевантные куски (progressive disclosure), а не тащит в контекст всю вселенную как это происходит с mcp.
Почему это важнее, чем “один большой агент”:
• 🔍 Контроль — легко тестировать и дебажить отдельный навык, а не разбираться, почему “агент сошёл с ума”.
• 🧱 Композиция — разные skills можно комбинировать под запрос, не переписывая архитектуру.
• 🧪 Эволюция — можно версионировать и чинить конкретный skill, не ломая всё остальное.
• 👥 Орг-знание — skills становятся способом упаковать процессы компании так, чтобы ИИ работал “как ваша команда”, а не как абстрактный ассистент.
Примеры того, что логично оформлять в skills, а не “учить агента на лету”:
• оформление коммерческих предложений именно в вашем стиле;
• подготовка отчётов/презентаций по внутреннему шаблону;
• разбор логов/метрик по вашей методике;
• чек-листы ревью кода и релизов.
Если вы играете с Claude, Agents SDK, LangGraph, MCP и прочими штуками — стоит начинать проектирование именно со скиллов, а не с “агента-генерала”. Сначала описываем повторяемые процедуры, потом даём модели оркестрировать их под задачу.
Видео: “Don’t Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag (Anthropic)” — очень рекомендую к просмотру, особенно тем, кто сейчас проектирует свою агентную платформу или ИИ-помощника под команду.
Ссылка: https://www.youtube.com/watch?v=CEvIs9y1uog
У Anthropic вышел очень классный доклад Barry Zhang & Mahesh Murag — мысль простая, но переворачивает подход к агентам:
не надо сразу строить “суперагента на все случаи жизни”, нужно строить библиотеку скиллов.
Что такое skill в их понимании:
• это оформленный сценарий работы: инструкция + примеры + (опционально) код;
• он решает одну конкретную задачу: написать отчёт по шаблону, разобрать выгрузку, оформить предложение клиенту;
• модель сама подбирает нужный skill и подгружает только релевантные куски (progressive disclosure), а не тащит в контекст всю вселенную как это происходит с mcp.
Почему это важнее, чем “один большой агент”:
• 🔍 Контроль — легко тестировать и дебажить отдельный навык, а не разбираться, почему “агент сошёл с ума”.
• 🧱 Композиция — разные skills можно комбинировать под запрос, не переписывая архитектуру.
• 🧪 Эволюция — можно версионировать и чинить конкретный skill, не ломая всё остальное.
• 👥 Орг-знание — skills становятся способом упаковать процессы компании так, чтобы ИИ работал “как ваша команда”, а не как абстрактный ассистент.
Примеры того, что логично оформлять в skills, а не “учить агента на лету”:
• оформление коммерческих предложений именно в вашем стиле;
• подготовка отчётов/презентаций по внутреннему шаблону;
• разбор логов/метрик по вашей методике;
• чек-листы ревью кода и релизов.
Если вы играете с Claude, Agents SDK, LangGraph, MCP и прочими штуками — стоит начинать проектирование именно со скиллов, а не с “агента-генерала”. Сначала описываем повторяемые процедуры, потом даём модели оркестрировать их под задачу.
Видео: “Don’t Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag (Anthropic)” — очень рекомендую к просмотру, особенно тем, кто сейчас проектирует свою агентную платформу или ИИ-помощника под команду.
Ссылка: https://www.youtube.com/watch?v=CEvIs9y1uog
YouTube
Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic
In the past year, we've seen rapid advancement of model intelligence and convergence on agent scaffolding. But there's still a gap: agents often lack the domain expertise and specialized knowledge needed for real-world work. We think Skills are the solution—a…
🔥4👍1
🚀 Anthropic “отпускает” MCP в open-source и запускает Agentic AI Foundation
Anthropic объявила, что передаёт Model Context Protocol (MCP) под крыло Linux Foundation — в новый фонд Agentic AI Foundation (AAIF), который они сделали вместе с Block и OpenAI при поддержке Google, Microsoft, AWS, Cloudflare и Bloomberg.
Что важно про MCP прямо сейчас:
• Уже 10 000+ публичных MCP-серверов — от дев-тулов до форчунов.
• MCP поддерживают ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code и другие продукты.
• Есть enterprise-инфра: деплой через AWS, Cloudflare, Google Cloud, Azure.
За год MCP сильно эволюционировал:
• Появился официальный Registry MCP-серверов.
• В релизе спеки от 25 ноября добавили асинхронные операции, stateless-режим, идентичность сервера и extensibility.
• Вышли официальные SDK на основных языках, уже 97M+ скачиваний в месяц (Python + TypeScript).
🧱 Agentic AI Foundation (AAIF) — это directed fund внутри Linux Foundation для всего, что связано с агентными AI-системами и открытыми стандартами. MCP становится одним из базовых проектов фонда, рядом с goose (Block) и AGENTS.md (OpenAI).
Ключевой смысл:
• MCP закрепляют как открытый, вендор-нейтральный стандарт под управлением Linux Foundation.
• Говернанс MCP остаётся community-driven, мейнтейнеры продолжают рулить развитием вместе с сообществом.
Для нас, кто строит агентов и инфраструктуру вокруг них, это сигнал, что MCP — уже не “формат Anthropic”, а общий инфраструктурный слой для экосистемы агентного AI.
Anthropic объявила, что передаёт Model Context Protocol (MCP) под крыло Linux Foundation — в новый фонд Agentic AI Foundation (AAIF), который они сделали вместе с Block и OpenAI при поддержке Google, Microsoft, AWS, Cloudflare и Bloomberg.
Что важно про MCP прямо сейчас:
• Уже 10 000+ публичных MCP-серверов — от дев-тулов до форчунов.
• MCP поддерживают ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code и другие продукты.
• Есть enterprise-инфра: деплой через AWS, Cloudflare, Google Cloud, Azure.
За год MCP сильно эволюционировал:
• Появился официальный Registry MCP-серверов.
• В релизе спеки от 25 ноября добавили асинхронные операции, stateless-режим, идентичность сервера и extensibility.
• Вышли официальные SDK на основных языках, уже 97M+ скачиваний в месяц (Python + TypeScript).
🧱 Agentic AI Foundation (AAIF) — это directed fund внутри Linux Foundation для всего, что связано с агентными AI-системами и открытыми стандартами. MCP становится одним из базовых проектов фонда, рядом с goose (Block) и AGENTS.md (OpenAI).
Ключевой смысл:
• MCP закрепляют как открытый, вендор-нейтральный стандарт под управлением Linux Foundation.
• Говернанс MCP остаётся community-driven, мейнтейнеры продолжают рулить развитием вместе с сообществом.
Для нас, кто строит агентов и инфраструктуру вокруг них, это сигнал, что MCP — уже не “формат Anthropic”, а общий инфраструктурный слой для экосистемы агентного AI.
1👍7
⚙️ Devstral 2: инференс дешевеет на глазах
Mistral выкатила Devstral 2 — кодовую модель 123B с 256K контекстом, которая берёт 72.2% на SWE-Bench Verified и при этом до 7 раз дешевле Claude Sonnet на реальных задачах, по их же бенчмаркам.
Младшая Devstral Small 2 (24B) даёт 68% на SWE-Bench Verified, держится на уровне/выше многих 70B-моделей и может работать локально, в том числе через GGUF/Unsloth и MLX на макбуках.
Тренд понятен:
• параметры падают,
• качество растёт,
• цена инференса летит вниз — от бесплатного API-окна сейчас до очень дешёвых локальных запусков завтра.
Если так продолжится, к концу следующего года нас ждёт очень интересный мир, где “сильный код-агент” — это не сервис по подписке, а просто ещё один бинарь рядом с git и docker. Учитывая еще достижения в области квантовых вычислений.
claude code на devstral 2 на mlx coming soon… )
https://mistral.ai/news/devstral-2-vibe-cli
Mistral выкатила Devstral 2 — кодовую модель 123B с 256K контекстом, которая берёт 72.2% на SWE-Bench Verified и при этом до 7 раз дешевле Claude Sonnet на реальных задачах, по их же бенчмаркам.
Младшая Devstral Small 2 (24B) даёт 68% на SWE-Bench Verified, держится на уровне/выше многих 70B-моделей и может работать локально, в том числе через GGUF/Unsloth и MLX на макбуках.
Тренд понятен:
• параметры падают,
• качество растёт,
• цена инференса летит вниз — от бесплатного API-окна сейчас до очень дешёвых локальных запусков завтра.
Если так продолжится, к концу следующего года нас ждёт очень интересный мир, где “сильный код-агент” — это не сервис по подписке, а просто ещё один бинарь рядом с git и docker. Учитывая еще достижения в области квантовых вычислений.
claude code на devstral 2 на mlx coming soon… )
https://mistral.ai/news/devstral-2-vibe-cli
👍3🥴1