Настройка Claude Platform on AWS для продакшена, локальной разработки и сторонних облаков (часть 3 из 3)

Если разворачиваете такую схему, сразу включите логирование Data Events в AWS CloudTrail для сервиса aws-external-anthropic — это даст полный аудит каждого вызова с фиксацией конкретного IAM-принципала. На уровне воркспейсов повесьте теги отделов и активируйте их как Cost Allocation Tags в биллинге AWS, чтобы через сутки видеть распределение затрат по командам прямо в Cost Explorer.

Источник

Переводы видео, саммари новостей про AI

Битва подписок за $200 и скрытые ловушки нового Codex против Claude

OpenAI в очередной раз перекроила линейку Codex: вернулся тариф за $200, появился тяжелый план за $500, а моделью по умолчанию в CLI стала GPT 6.1 Sol. Главный подвох скрыт в мелком шрифте — новым подписчикам за те же 200 долларов существенно урезали лимиты использования. Если вы прямо сейчас выбираете между максимальными планами OpenAI и Claude, старые сравнения и чужие бенчмарки можно смело выбрасывать.

Ключевые моменты:
• Неравенство пользователей: существующие подписчики Codex сохранят старые увеличенные квоты до 29 октября 2026 года, тогда как новые аккаунты за те же $200 получают урезанный лимит
• GPT 6.1 Sol радикально уронила стоимость генерации: в бенчмарке из трех задач агент на Sol потратил всего 17 центов по расценкам API против 51 цента у Claude Opus 5.5 и 65 центов у прежней Astra
• Введен тариф за $500 с эксклюзивным доступом к Astra UltraFast, но ускорение сжигает лимиты в 8 раз быстрее обычного, а режим Fast — в 2.5 раза
• Разрыв в окупаемости: чтобы «выбрать» $200 стоимости подписки эквивалентными запросами по API, на Sol придется решить 3575 небольших задач, тогда как на дорогом Opus 5.5 окупаемость наступает уже после 1187 задач

В тесте использовались три типовые изолированные задачи на Python: починка логики календаря с пересекающимися слотами (12 проверок), построение детерминированного графа зависимостей с отловом циклов (14 проверок) и рефакторинг модуля аналитических отчетов под CSV и JSON (12 проверок). Все три подопытных — Sol 6.1, Astra и Opus 5.5 — успешно прошли все 38 проверочных тестов. При этом Sol прогнал через себя 236 720 токенов (из них 178 304 пришлись на дешевый кэш), Astra использовала 218 975 токенов, а Opus — 230 553 токена.

За счет обновленного прайсинга OpenAI стоимость кэшированного ввода у Sol упала до минимума. В итоге работа агента на Sol обошлась на 74% дешевле Astra и на 67% дешевле Opus в пересчете на чистые API-токены.

Базовые расценки API для GPT 6.1 Sol зафиксированы на таких отметках:
Обычный ввод: $2.00 / 1M токенов
Кэшированный ввод: $0.10 / 1M токенов
Вывод: $10.00 / 1M токенов

Парадокс в том, что дешевизна Sol ломает логику дорогих подписок. Если вы делаете около 300 типовых задач в месяц (по 15 задач каждый рабочий день), то в API токены Sol обойдутся суммарно всего в $16.79. Платить за это фиксированные $200 в месяц бессмысленно, если только вы не упираетесь в жесткие ограничения базовых тарифов.

По структуре лимитов правила тоже различаются. В тарифе Codex Pro сняли плавающее 5-часовое окно (остались только недельные квоты), тогда как у Claude план Max за $100 дает пятикратный буст сессионного окна от Pro, а за $200 — двадцатикратный. Но недельные лимиты Claude все равно могут внезапно прервать спринт посреди недели. Прежнее утверждение о том, что план Codex за $200 дает вдвое больше объема работы на каждый доллар, для новых покупателей больше не актуально.

Не спешите брать план за $200 вслепую. Если ваш типичный стек задач похож на легкий рефакторинг или точечные фиксы, работа через API на Sol 6.1 или базовый план за $20 сбережет приличную сумму. Апгрейд до верхних тарифов сейчас оправдан только в одном случае: если вы постоянно гоняете тяжелые архитектурные задачи на старших моделях и регулярно упираетесь в блокирующие экраны лимитов.

AISeeKing

Переводы видео, саммари новостей про AI

Shopify запустила Canvas для сборки интернет-магазинов через диалог с нейросетью

Shopify показала новый инструмент под названием Canvas. Главная фишка простая: собрать или переделать витрину интернет-магазина теперь можно прямо через переписку с фирменным ИИ-ассистентом Sidekick. Больше не нужно руками перетаскивать типовые секции в визуальном редакторе или нанимать разработчика для правок шаблонов.

Раньше в платформе уже был базовый no-code конструктор, но у него быстро находился потолок. Продавец выбирал готовую тему, двигал модульные блоки и настраивал цвета. Любая нестандартная идея — поправить сетку товаров, добавить кастомную анимацию или переделать карточку заказа — упиралась в код на Liquid, HTML и CSS. Приходилось либо разбираться в верстке самому, либо платить сторонним специалистам.

Canvas переводит этот процесс в чат. Пользователь пишет ассистенту Sidekick, что именно нужно изменить на странице, а система на лету вносит правки в файлы сайта.

Несколько интересных технических деталей:

• Живой рендеринг вместо картинок. В окне Canvas крутится настоящий рабочий код магазина, а не статичный макет из Figma. В превью можно кликать по кнопкам, проверять анимации, открывать меню и смотреть адаптивность под экраны разной ширины.
• Визуальный контроль через скриншоты. Sidekick в процессе работы сам делает снимки экрана. Нейросеть буквально видит интерфейс глазами пользователя и проверяет, не разъехались ли блоки после генерации.
• Бесконечный холст. Рабочая зона построена как доска: можно отдалиться, чтобы оценить весь магазин целиком со всеми страницами, или приблизить конкретный баннер.
• Ручные правки без запретов. Никто не заставляет общаться только текстом. Если надо подвинуть конкретный заголовок или поменять отступ, можно кликнуть по элементу мышкой и поправить его руками.

Чтобы Sidekick мог безопасно менять код и не ломать логику сайта, инженеры переработали архитектуру тем. Файловую структуру заметно упростили, благодаря чему бот напрямую понимает зависимости между компонентами и точечно переписывает нужные файлы темы без каши в разметке.

По сути, Shopify заходит в ту же нишу вайб-кодинга, где сейчас развиваются Lovable, v0 и Replit, пытаясь потеснить веб-билдеры вроде Webflow или Framer.

При этом на старте у Canvas хватает ограничений, и сервис пока откровенно сырой:

• Работает только в десктопной версии, с планшетов и телефонов доступа нет.
• Поддерживает лишь стандартные темы Shopify. Сторонние темы из каталога подключить пока нельзя.
• Нет поддержки расширений и блоков сторонних приложений (app blocks). Если магазин завязан на плагины отзывов, таймеров или кастомных форм, перенести их в Canvas не выйдет.
• Инструмент пока не умеет работать с Shopify Markets, мультиязычностью, локальными валютами и обновлением тем.

В компании говорят, что эти ограничения временные и функционал будут расширять дальше.

Для малого бизнеса это отличная новость: порог входа снижается, а базовый запуск витрины без бюджета на дизайнеров становится делом пары часов. Разработчикам же стоит готовиться к тому, что простые задачи по верстке типовых секций окончательно уйдут нейросетям, а ценность останется в сложной бизнес-логике, кастомном бэкенде и интеграциях по API.

Источник

Переводы видео, саммари новостей про AI

Как планировать сложные проекты с ИИ-агентами без потери контекста

Разработчики из Anthropic поговаривают об отказе от встроенного режима планирования в Claude Code. Брайан Касл (автор Builder Methods) отказался от него еще раньше, но не от самого планирования: на крупных проектах его агенты планируют больше прежнего. Секрет простой: планы не должны висеть в воздухе промпта или встроенных функциях чата, они обязаны храниться в отдельных файлах, к которым у любой модели есть постоянный доступ.

Ключевые моменты:
• Архитектура мета-репозиториев: под каждый продукт автор создает отдельный репозиторий с суффиксом -meta (например, mimio-meta), полностью изолируя документы и макеты от рабочего кода.
• Папка циклов: любая задача, фича или редизайн оформляется в датированную директорию (2024-03-redesign), внутри которой живет рабочий журнал summary.md.
• Передача состояния: агенты сами обновляют summary.md по ходу выполнения — фиксируют статус, блокеры и следующие шаги, что позволяет безболезненно менять сессии.
• Трехэтапный запуск: разработка разбивается на стратегию, составление дорожной карты и только затем кодинг в основном репозитории.

Главная проблема больших задач при работе с LLM — засорение контекста. Если пихать в рабочий репозиторий старые макеты, черновики текстов, SEO-отчеты и планы архитектуры, агент быстро запутается в версиях и начнет тащить в свежий код устаревшие стили и решения.

Чтобы кодовая база оставалась чистой, автор выносит сопутствующие артефакты в отдельный мета-репозиторий. Структура выглядит так:

mimio/ # Основной код приложения (Ruby on Rails)
mimio-site/ # Маркетинговый сайт
mimio-meta/ # Мета-данные продукта
├── brand/ # Логотипы, шрифты, стили
├── strategy/ # Аналитика, целевая аудитория, воронки
└── cycles/ # Завершенные и текущие циклы работы
└── 2024-03-redesign/
├── summary.md
├── plan.md
└── mockups/ (HTML-прототипы)

Вся работа делится на циклы (cycles) — спринты с понятным началом и концом. Циклом может быть исправление бага, сценарий для ролика или двухнедельный редизайн сайта.

Файл summary.md внутри папки цикла служит главным инструментом передачи эстафеты между сессиями. Он начинается с пары предложений о задаче, а дальше агент дописывает его сам. Когда контекст переполняется или вы запускаете нового агента в облаке (автор использует Amp Orbs на базе ampcode.com), агент первым делом читает этот файл. Человеку даже не нужно вчитываться в эти полотна — это внутренняя память для моделей, избавляющая их от повторного наступания на те же грабли.

Сам процесс реализации крупных задач автор делит на три шага:
1. Стратегия. Агент парсит сайт, задает пачку уточняющих вопросов о целях. Когда решение найдено, автор дает команду «залочь это» (lock it), и агент сбрасывает принятые правила в папку strategy/.
2. Прототипы. До написания продакшен-кода верстаются простые HTML-макеты (v1, v2... v5) прямо внутри папки текущего цикла.
3. План и майлстоуны. Создается поэтапный роадмап. Даже если современные модели способны написать весь код за один прогон, проект сознательно дробят на вехи, чтобы человек мог вмешаться и скорректировать результат до финального деплоя.

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

briancasel

Переводы видео, саммари новостей про AI

Как настроить долговременную память для агентов в NVIDIA NeMo через Amazon S3 Vectors (часть 1 из 3)

Когда агенты работают в связке, им нужно где-то хранить контекст, иначе каждый шаг превращается в повторные запросы к LLM и потерю данных. Связка из NVIDIA NeMo Agent Toolkit (NAT) и Amazon S3 Vectors позволяет собрать масштабируемое векторное хранилище без переплаты за простаивающие сервера баз данных. Ниже разобран процесс создания кастомного плагина памяти, координации нескольких агентов и развертывания решения в кластере Amazon EKS.

Зачем агентам S3 Vectors

NAT из коробки поддерживает Redis, Mem0, MemMachine и Zep. Этого хватает для тестов или простых сценариев, но в production с кучей агентов упираешься в масштабирование и изоляцию.

S3 Vectors решает несколько прикладных задач:
• Строгая согласованность по записи. Агент записал факт, и остальные участники пайплайна видят его в ту же миллисекунду без возни с инвалидацией кэша.
• Метаданные прямо на векторах. Можно фильтровать выборку по тикерам, идентификаторам команд или типам памяти (эпизодическая или семантическая).
• Емкость до 2 миллиардов векторов на индекс без необходимости вручную рассчитывать шардинг.
• Деньги списываются только за фактически занятое место, операции записи и запросы.

Шаг 1. Создание индекса в AWS

Для работы потребуется Python 3.11 или 3.12 и установленный пакет boto3. Первым делом создается векторный бакет и индекс. Для генерации эмбеддингов здесь используется модель Amazon Titan Text Embeddings V2, которая выдает размерность 1024:

import boto3

REGION = "us-west-2"
VECTOR_BUCKET = "amzn-s3-demo-research-agent-memory"
INDEX_NAME = "agent-long-term-memory"

s3vectors = boto3.client("s3vectors", region_name=REGION)

s3vectors.create_vector_bucket(vectorBucketName=VECTOR_BUCKET)

s3vectors.create_index(
    vectorBucketName=VECTOR_BUCKET,
    indexName=INDEX_NAME,
    dataType="float32",
    dimension=1024,
    distanceMetric="cosine",
    metadataConfiguration={"nonFilterableMetadataKeys": ["content"]},
)

Поле content исключено из фильтруемых метаданных, чтобы не расходовать лимиты индекса на длинные текстовые куски.

Шаг 2. Пишем кастомный плагин MemoryEditor для NAT

Архитектура памяти в NeMo Agent Toolkit завязана на абстрактный класс MemoryEditor. Нам нужно реализовать три метода: запись (add_items), векторный поиск (search) и удаление (remove_items).

import boto3
import json
import uuid
from datetime import datetime, timezone
from nat.plugin_api import MemoryBaseConfig, MemoryEditor, MemoryItem, register_memory
from nat.builder.builder import Builder

class S3VectorsMemoryConfig(MemoryBaseConfig, name="s3vectors_memory"):
vector_bucket: str
index_name: str
aws_region: str = "us-west-2"
default_top_k: int = 5

class S3VectorsMemoryEditor(MemoryEditor):
def __init__(self, config: S3VectorsMemoryConfig):
self._vector_bucket = config.vector_bucket
self._index_name = config.index_name
self._default_top_k = config.default_top_k
self._s3vectors = boto3.client('s3vectors', region_name=config.aws_region)
self._bedrock = boto3.client('bedrock-runtime', region_name=config.aws_region)

def _get_embedding(self, text: str) -> list[float]:
response = self._bedrock.invoke_model(
modelId='amazon.titan-embed-text-v2:0',
contentType='application/json',
accept='application/json',
body=json.dumps({'inputText': text, 'dimensions': 1024, 'normalize': True})
)
return json.loads(response['body'].read())['embedding']

Источник

Переводы видео, саммари новостей про AI

Как настроить долговременную память для агентов в NVIDIA NeMo через Amazon S3 Vectors (часть 2 из 3)

async def add_items(self, items: list[MemoryItem], **kwargs) -> None:
vectors = []
for item in items:
text = item.memory or json.dumps(item.conversation)
embedding = self._get_embedding(text)
key = f"mem_{item.user_id}_{uuid.uuid4().hex[:12]}"

# Лимит метаданных требует обрезать контент
content_for_metadata = text[:1024]
mem_metadata = {
'user_id': item.user_id,
'memory_type': item.metadata.get('memory_type', 'episodic'),
'agent_id': item.metadata.get('agent_id', ''),
'team_id': item.metadata.get('team_id', ''),
'created_at_epoch': int(datetime.now(timezone.utc).timestamp()),
'is_shared': item.metadata.get('is_shared', True),
'content': content_for_metadata,
}
if 'ticker' in item.metadata:
mem_metadata['ticker'] = item.metadata['ticker']

vectors.append({'key': key, 'data': {'float32': embedding}, 'metadata': mem_metadata})

self._s3vectors.put_vectors(
vectorBucketName=self._vector_bucket,
indexName=self._index_name,
vectors=vectors
)

async def search(self, query: str, top_k: int = None, **kwargs) -> list[MemoryItem]:
query_embedding = self._get_embedding(query)
effective_top_k = top_k or self._default_top_k

filter_expr = {}
for field in ('agent_id', 'memory_type', 'ticker', 'team_id', 'user_id', 'is_shared'):
if field in kwargs:
filter_expr[field] = {'$eq': kwargs[field]}

response = self._s3vectors.query_vectors(
vectorBucketName=self._vector_bucket,
indexName=self._index_name,
queryVector={'float32': query_embedding},
topK=effective_top_k,
filter=filter_expr if filter_expr else None,
returnMetadata=True
)

return [
MemoryItem(
conversation=[],
tags=[vec['metadata'].get('memory_type', '')],
metadata=vec['metadata'],
user_id=vec['metadata'].get('user_id', ''),
memory=vec['metadata'].get('content', '')
)
for vec in response.get('vectors', [])
]

async def remove_items(self, **kwargs) -> None:
keys = kwargs.get('keys', [])
if keys:
self._s3vectors.delete_vectors(
vectorBucketName=self._vector_bucket,
indexName=self._index_name,
keys=keys
)

@register_memory(config_type=S3VectorsMemoryConfig)
async def build_s3vectors_memory(config: S3VectorsMemoryConfig, builder: Builder):
yield S3VectorsMemoryEditor(config)

Шаг 3. Подключение плагина в конфигурацию NAT

NeMo Agent Toolkit позволяет использовать враппер auto_memory_agent. При его включении модель сама не дергает функции сохранения или чтения, всё происходит автоматически перед каждым обращением к агенту.

Фрагмент config.yml:

memory:
  agent_memory:
    _type: s3vectors_memory
    vector_bucket: "amzn-s3-demo-research-agent-memory"
    index_name: "agent-long-term-memory"
    aws_region: "us-west-2"

workflow:
  _type: auto_memory_agent
  inner_agent_name: research_agent
  memory_name: agent_memory
  llm_name: bedrock_llm
  save_user_messages_to_memory: true
  retrieve_memory_for_every_response: true
  save_ai_messages_to_memory: true

llm:
  bedrock_llm:
    _type: bedrock
    model_id: "anthropic.claude-sonnet-4-20250514"
    temperature: 0.3

Командная работа агентов и сжатие контекста

Как настроить долговременную память для агентов в NVIDIA NeMo через Amazon S3 Vectors (часть 3 из 3)

Если запустить связку из агента-исследователя, аналитика и составителя отчетов, они могут делить базу знаний через флаг team_id и булево поле is_shared. Исследователь заносит факты, а аналитик вытаскивает их без повторных обращений к внешним API.

Со временем эпизодических записей становится слишком много. Чтобы поиск оставался быстрым и точным, запускается фоновый процесс консолидации. Отдельный LLM-промпт собирает сырые фрагменты по теме (например, тикеру акции), вычленяет общие закономерности и сохраняет их как семантическую память с тегом semantic.

Запуск в Kubernetes через Amazon EKS

Агент пакуется в контейнер под управлением команды nat serve:

FROM python:3.12-slim
RUN pip install nvidia-nat[langchain] boto3
COPY config.yml /app/config.yml
COPY s3vectors_memory.py /app/s3vectors_memory.py
WORKDIR /app
CMD ["nat", "serve", "--config_file", "config.yml"]

Авторизация к S3 Vectors настраивается через механизм IAM Roles for Service Accounts (IRSA). Приложению назначается ServiceAccount, привязанный к роли с правами на вызовы:
• s3vectors:PutVectors
• s3vectors:QueryVectors
• s3vectors:GetVectors
• s3vectors:DeleteVectors

В манифесте Deployment достаточно выставить ресурсы и связать его с HorizontalPodAutoscaler по загрузке CPU. Так как состояние вынесено в S3, поды масштабируются горизонтально без рассинхронизации.

Факты и цифры реализации
• Для генерации векторов используется Amazon Titan Text Embeddings V2 с нормализацией и размерностью 1024.
• Поле метаданных в S3 Vectors ограничено по длине, поэтому в коде плагина текст урезается до 1024 символов.
• NeMo Agent Toolkit 1.6 поддерживает Python 3.11 и 3.12.
• В бенчмарках через утилиту nat eval память снижает расход токенов LLM за счет повторного использования фактов, но добавляет небольшую задержку на сам векторный поиск.

Если вы проектируете систему из нескольких автономных агентов на стеке AWS и NeMo, реализация собственного MemoryEditor под S3 Vectors избавляет от необходимости поднимать тяжелые кластеры Milvus или платить фиксированную ставку за Pinecone. Начните со сборки базового Docker-образа и проверки фильтрации метаданных под ваши задачи.

Источник

Переводы видео, саммари новостей про AI

Как перестать тестировать AI-агентов по интуиции

Большинство разработчиков проверяют AI-агентов исключительно «по ощущениям»: поменяли системный промпт, запустили пару запросов в терминале, ответы выглядят правдоподобно — значит, можно катить в прод. Проблема в том, что при передаче проекта коллегам или добавлении нового шага в цепочку агент начинает незаметно деградировать. Чтобы исключить случайные поломки, инженеры из Google и Merge показали процесс настройки автоматической системы оценки (evals) ровно за один час.

Ключевые моменты:
• Разделение OpenTelemetry и OpenInference. Обычный OpenTelemetry собирает сетевые спаны, но бессилен перед разницей в логике фреймворков. LangGraph, CrewAI и Google ADK стримят токены и аргументы по-разному. Стандарт OpenInference нормализует специфичные для LLM данные: вызовы инструментов, промпты и ответы, делая трейсы переносимыми.
• Анализ через Anti-gravity и Gemini. Вместо ручного составления тестовых наборов ассистент разбирает кодовую базу агента, строит интерактивные Mermaid-диаграммы архитектуры прямо по логам и находит сценарии для бенчмарков на основе реальных прогонов.
• Опенсорсный фреймворк agenteval. Утилита от команды Google Cloud избавляет от написания тестовых обвязок с нуля. Она разворачивает каркас тестирования и позволяет замерять качество работы агентов численно, а не на глаз.

Главная сложность тестирования агентов — субъективность. Автор агента интуитивно понимает, какой результат считается хорошим, но внешний контрибьютор или автоматический пайплайн этого контекста лишены. В роли подопытного в видео выступил Docs Hound — агент на LangGraph, который сканирует репозитории на GitHub, сверяет 50 issues и 30 PR с документацией, находит пробелы (например, отсутствие описания аудиостриминга) и сам готовит pull request с правками.

Чтобы протестировать такую систему без субъективщины, пайплайн разделили на четыре четких шага:

Сначала в репозиторий направляют AI-ассистента Anti-gravity. Он вычитывает спаны и логи готового прогона Docs Hound, разбирается в архитектуре хранения данных и формирует граф выполнения.

Далее агент находит базовый успешный сценарий и масштабирует его. Чтобы тест не зависел от одного репозитория, Anti-gravity скармливают другие популярные проекты (вроде T3 Code или PI agent) и просят воспроизвести шаги агента в изолированном виде.

На третьем этапе подключается инструментарий agenteval:

git clone https://github.com/google/agenteval
# Инструмент подключает трейсы OpenInference к метрикам оценки

Изначально инструмент создавался под Google ADK, но благодаря поддержке единого формата телеметрии его легко связать с LangGraph. Тулкит формализует критерии качества: релевантность найденных проблем в документации, точность формулировок и корректность оформления сгенерированного markdown.

В финале запускается модель-судья (LLM-as-a-judge). Она прогоняет агента по подготовленному пулу задач и выдает конкретные баллы по каждому направлению. Если после правок системного промта агент начинает чаще находить фантомные баги в документации или генерировать битые ссылки, метрики сразу проседают в дашборде Google Cloud Agent Platform.

Практический вывод: переведите сбор логов агента на спецификацию OpenInference независимо от используемого стека. Это позволит подключить фреймворки вроде agenteval и проверять каждый пуллреквест объективными цифрами, а не интуитивными тестами вручную.

googlecloudtech

Переводы видео, саммари новостей про AI

Как научить агентов LangChain принимать запросы из iMessage, WhatsApp и внешних CRM

В LangChain появились кастомные HTTP-каналы для managed deep agents, чтобы принимать входящие запросы из сервисов без нативных интеграций. Механизм решает проблему подключения внешних вебхуков от систем вроде HubSpot, Salesforce или платформ отправки сообщений уровня Photon и Twilio (SMS, WhatsApp, iMessage). На примере агента Reflex показан сквозной процесс сборки: от верификации сырых вебхуков до сохранения чеков в долгосрочную память.

Ключевые моменты:
• Архитектура канала держится на трех функциях: верификатор (проверяет безопасность сырых байтов), парсер (разбирает JSON, достает текст или изображения) и post-хук (шлет ответ обратно в сторонний сервис).
• Контекст диалога завязан на thread ID: входящий номер телефона пользователя хешируется в детерминированный UUID, за счет чего сообщения от одного контакта складываются в общую ветку переписки.
• Для сохранения данных между запусками агент использует durable memory в Context Hub, куда записывает структурированную таблицу расходов в Markdown.
• Разделение инструментов: кастомные HTTP-каналы нужны для событий, структуру которых вы не контролируете; для собственных интерфейсов разработчики рекомендуют стандартный LangGraph SDK.

Разбор механики работы HTTP-канала:

Когда внешний сервис отправляет вебхук, среда managed deep agents запускает ран (run). Сервер изначально не знает формата данных внешней платформы, поэтому обработка ложится на пользовательские функции. Сначала в дело вступает верификатор: он принимает необработанные байты (raw bytes) и сверяет подпись запроса, отсекая спам и поддельные вызовы. Следом парсер разбирает входящий payload, обрабатывает ошибки и формирует объект с типом message, понятный модели.

В кодовой базе проекта (показано на TypeScript, но для Python синтаксис аналогичен) подключение выглядит следующим образом:

const channel = new HttpChannel({
verify: verifyPhotonRequest,
parse: parsePhotonEvent,
post: postToPhoton
});

Особый нюанс — управление тредами. Чтобы модель помнила предыдущие сообщения и не дублировала данные (например, если чек отправлен повторно), входящие запросы нужно мапить на единый идентификатор. В демонстрации номер телефона преобразуется через хеш в UUID и передается как thread_id. Эту схему можно гибко менять под свои задачи: сбрасывать тред раз в сутки или очищать сессию по специальной текстовой команде.

Сценарий обработки чека выглядит наглядно. Пользователь отправляет сообщение в iMessage. Провайдер Photon ловит событие и пересылает его вебхуком на развернутый в LangSmith агентский сервер. Агент запрашивает фото чека, принимает файл через парсер, разворачивает песочницу, вытягивает сумму и категорию, после чего делает запись в файл расходов внутри Context Hub. Ответный текст уходит через post-хук обратно в Photon, а сервис доставляет его в переписку пользователю.

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

Практический вывод: используйте HTTP-каналы всякий раз, когда агента нужно подключить к внешнему источнику вебхуков без готового адаптера. Для старта достаточно написать функции валидации байтов и парсинга JSON, а также зафиксировать генерацию thread_id для сохранения контекста.

LangChain

Переводы видео, саммари новостей про AI

Военная модель безопасности полувековой давности против взлома ИИ-агентов (часть 1 из 2)

Автономные агенты выходят из-под контроля: они взламывают базы данных, путают инструкции разработчика с данными из внешнего мира и радостно сливают приватные исходники наружу при банальном промпт-инжекте. Стандартные фильтры и следящие нейросети-няньки дают сбой, пропуская критические утечки в продакшене. Стартап Archestra предложил решение этой проблемы без покупки дорогих чипов, упаковав классическую концепцию секретного документооборота в компактную утилиту OpenAppa.

Ключевые моменты:
• Блок-листы команд бесполезны: агенты легко обходят жесткие запреты, находя альтернативные пути выполнения опасных системных вызовов
• Контролирующие LLM ненадежны: надзорные модели ошибаются примерно в 1% случаев, чего с головой хватает для взлома базы данных или компрометации закрытых репозиториев
• Принцип военных комнат: сессия агента динамически меняет свой уровень секретности сразу после чтения конфиденциального файла
• Детерминированная блокировка: решение о запрете сетевого запроса принимается внешним кодом на основе политик, поэтому любые уговоры и манипуляции внутри промпта просто игнорируются
• Цена безопасности: в тестах агент с защитой справился с 75% поставленных задач против 96% у Claude Code в авто-режиме, попутно сжигая ощутимо больше токенов

В индустрии долго пытались решить проблему разграничения инструкций двумя путями. Первый — черные списки команд. Если заблокировать условному агенту вызов curl, он просто напишет скрипт на Python или соберет пейлоад через сокеты. Второй подход продвигает Anthropic в Claude Code: посадить вторую нейросеть присматривать за первой. Но модель-контролер подвержена точно таким же галлюцинациям и брешам. Даже изоляция контекста наблюдателя дает 99% надежности, что неприемлемо для коммерческой тайны.

Nvidia подошла к вопросу в своем стиле — анонсировала отдельный физический процессор, изолирующий агента на уровне железа. OpenAppa решает ту же задачу программно через файл конфигурации в формате TOML.

Архитектура повторяет модель многоуровневой безопасности, созданную для военных ведомств еще пятьдесят лет назад: документы с грифом секретности не могут покинуть комнату соответствующего уровня допуска. OpenAppa встраивается между Claude Code и набором доступных инструментов. Агент работает как обычно, но если он открывает локальный файл с пометкой private, вся текущая сессия немедленно маркируется приватной.

После присвоения метки срабатывает жесткое правило: никакой экспорт во внешние системы с более низким уровнем доверия невозможен. Даже если вредоносный промпт заставит агента запаковать алгоритм мэтчинга или медицинскую карту и отправить их публичным issue на GitHub, запрос будет срезан на корню. OpenAppa опрашивает API платформы назначения, видит статус публичного репозитория и намертво замораживает операцию до тех пор, пока человек не подтвердит отправку вручную. Промпт-инжект может быть сколь угодно убедительным, но агент физически лишен возможности повлиять на внешний валидатор.

Инструмент устанавливается в систему как отдельный бинарник вместе с плагином для окружения Claude Code, после чего защищенный сеанс стартует через специальный алиас:

clappa

Главный минус решения на текущем этапе — заметная просадка автономности. При строгом контроле агент чаще спотыкается на комплексных пайплайнах, где требуется частый обмен контекстом с внешними сервисами. Кроме того, постоянные промежуточные проверки накладывают накладные расходы на расход токенов.

Как построить контур контроля для автономных агентов (часть 1 из 2)

Большинство современных фреймворков для агентов научились превращать ответы модели в вызовы инструментов. Проблема в том, что валидный JSON и статус ответа HTTP 200 вообще не гарантируют, что действие было разрешено и предназначалось именно для этого пользователя. Разбираемся, как выстроить архитектуру, где модель только предлагает шаги, а система жестко решает, что пойдет в прод.

Обычный цикл агента выглядит примитивно: план → вызов функции → наблюдение → следующий шаг. В игрушечных демо этого хватает. В проде агент видит фразу «отмени подписку на неиспользуемый аккаунт», парсит ID из старого контекста, дергает метод cancel_subscription, получает 200 OK и в итоге гасит учетку чужого клиента.

Главная ошибка тут кроется в смешении понятий: возможность (capability) не равна полномочиям (authority). Модель умеет заполнять параметры функции. Но право на запуск имеет только проверенный субъект при соблюдении политик безопасности.

Архитектуру взрослой системы нужно делить на три независимых слоя:

• Слой планирования (Planning Plane). Здесь живет LLM. Модель анализирует контекст задачи, выбирает инструмент из узкого набора, формирует типизированное предложение (ActionProposal) и объясняет логику. У нее нет прямых ключей от боевых баз и права принимать окончательные решения.
• Контур контроля (Control Plane). Это детерминированный шлюз. Он проверяет подлинность инициатора, права доступа к ресурсу, валидирует схему и запрашивает подтверждение человека, если операция рискованная.
• Слой исполнения и верификации (Execution & Observation Plane). Изолированный воркер получает короткоживущий токен под конкретную операцию, делает вызов с ключом идемпотентности, читает квитанцию от провайдера и пишет событие в неизменяемый журнал аудита.

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

1. Узкие контракты вместо общих инструментов. Забудьте про generic-ручки вроде run_shell, http_request или прямой SQL. Агенту отдаются строгие бизнес-действия: queue_refund_review, create_draft_invoice, revoke_session. В схеме сразу задаются класс сайд-эффекта (read_only, draft, irreversible), требуемые скоупы и уровень риска.

2. Разделение личности агента и пользователя. Нельзя брать токен авторизованного юзера и отдавать его агенту целиком. У агента должна быть собственная атрибутируемая сущность. Логи должны четко отвечать на вопрос: действие выполнил человек, агент по поручению человека или фоновый сервис.

3. Авторизация вне модели. Решение о допуске выносится за пределами нейросети. Модель генерирует черновик действия, шлюз нормализует параметры, а движок политик возвращает вердикт: allow, deny или approval_required.

4. Классификация действий по уровню риска. Не делите агентов на полностью ручных или автономных. Делите сами действия. Чтение документации выполняется автоматически, создание черновика уходит в стейджинг без спроса, а смена прав доступа требует обязательного аппрува старшего инженера. Если сущность была определена моделью неявно или на вход поступили непроверенные внешние данные, уровень риска автоматически повышается.

5. Аппрув привязывается к каноническому хэшу. Человек должен подтверждать не текст «агент хочет вернуть деньги», а точный хэш нормализованных параметров: ID транзакции, сумма, получатель. Если модель на лету поменяет хоть один параметр, выданный аппрув становится недействительным.

Источник

Переводы видео, саммари новостей про AI

Как построить контур контроля для автономных агентов (часть 2 из 2)

6. Защита от косвенных инъекций через карантин. Входящие письма, веб-страницы и спарсенные документы нельзя конкатенировать в системный промпт. Внешний контент изолируется в отдельном компоненте без доступа к инструментам и секретам. Там из него извлекаются сухие факты, и только потом они передаются планировщику.

7. Идемпотентность и компенсации. Сетевой таймаут после списания денег оставляет систему в подвешенном состоянии. Модель не должна додумывать статус. Фиксируйте ключ идемпотентности до отправки запроса:

idempotency_key = hash(tenant_id + action_name + canonical_payload)

Если результат операции неясен, статус помечается как unknown и уходит в очередь сверки, а не объявляется успешным.

8. Специфичный аудит вместо логов переписки. Сохранять всю историю чата накладно и бесполезно для расследований. В журнал пишутся дискретные события: action.proposed, policy.decided, approval.decided, execution.dispatched, effect.verified. Лог защищается от модификации и очистки.

9. Тестирование контрольного контура. Оценивать работу агента метриками вроде «ответ выглядит связно» опасно. Контур проверяется детерминированными тестами на отсечение инъекций, проверку граничных условий схем и реакцию политик на попытку эскалации привилегий.

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

Источник

Переводы видео, саммари новостей про AI

Архитектурные решения для кодинг-агентов без бюрократии и судебных протоколов (часть 1 из 2)

Кодинг-агенты вроде Cursor, Claude Code или Aider часто страдают амнезией: они видят кусок репозитория, но понятия не имеют, почему код написан именно так. В итоге нейросеть либо пытается угадать замысел авторов через бесконечный поиск по коду, либо принимает временный костыль за фундаментальное правило архитектуры. Разработчик Дункан Дэвидсон описал рабочий подход к решению этой проблемы через архитектурные записи решений (ADR) и показал, на какие грабли тут наступают почти все.

Архитектурный рекорд (Architecture Decision Record, ADR) фиксирует выбор технологии, структуру модулей и причины, почему команда пошла именно этим путем. Для агентов это идеальный якорь: вместо того чтобы копаться в закрытых пуллреквестах и старых ишью, бот берет готовый контекст прямо из репозитория. Но как только агент получает доступ к ADR, вылезают две неочевидные проблемы.

Первая проблема — слепое повиновение. Человек понимает, когда правило устарело или когда ситуация требует исключения. Модель так не умеет: если решение помечено как принятое, она будет держаться за него до последнего. Дэвидсон приводит реальный пример из своего проекта: агент реализовывал новую фичу и наткнулся на старый ADR, требующий использовать конкретную абстракцию хранилища. Сама абстракция уже давно изжила себя и для новой задачи не подходила. Вместо того чтобы написать разработчику и спросить, актуально ли это правило, агент просто нагородил еще один слой адаптеров сверху, лишь бы формально удовлетворить старый документ.

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

Чтобы агент не превращал документацию в стенограмму судебного заседания, Дэвидсон зафиксировал правила работы с ADR прямо в файле инструкций проекта (AGENTS.md). Вот фрагмент рабочей конфигурации:

Архитектурные решения (ADR) лежат в виде Markdown в docs/decisions. 
Статус принятых решений (accepted) — обязательный к исполнению. 
Предложенные (proposed) — контекст без обязательств. 
Устаревшие (superseded) — история, на текущую работу не влияют. 

Если задача противоречит принятому ADR, остановись, задай вопрос 
и предложи изменения. Предлагай новые ADR или апдейты существующих, 
когда задача меняет долгосрочные архитектурные договоренности.

Пиши ADR коротко. Документ содержит только актуальный текст. 
История Git — это твой чейнджлог, поэтому не веди списки версий 
в шапке файла. Если меняешь принятый ADR по существу, просто добавь 
или обнови строчку "Updated: YYYY-MM-DD" после даты создания. 
Устаревший документ получает строчку "Superseded-On:" вместо "Updated:", 
которая ссылается на заменивший его ADR. Каждое правило формулируется 
один раз в своем документе, в остальных ставятся ссылки, без дублирования текста.

Этот подход закрывает сразу несколько критических моментов:

• Четкий запрет на додумывание. Если код требует нарушить старый ADR, агент обязан нажать на тормоз и явно спросить человека, что делать: менять задачу или переписывать старое решение.

• Чистый Markdown вместо полотна истории. Модели любят вести внутренние логи изменений прямо в теле файла. Дэвидсон прямо запретил это делать: всю историю правок берет на себя Git, а в самом файле остается только чистый итог.

Источник

Переводы видео, саммари новостей про AI

Архитектурные решения для кодинг-агентов без бюрократии и судебных протоколов (часть 2 из 2)

• Никакого дублирования. Если одно правило описано в первом файле, во втором дается прямая ссылка. Иначе при изменении архитектуры агент обновит один файл, забудет про второй, и контекст рассинхронизируется.

• Градация статусов. Модель четко видит разницу между утвержденным стандартом и черновиком, не пытаясь реализовать идеи, которые команда еще даже не согласовала.

Если вы отдаете агентам сложные задачи в долгоживущих проектах, заведите папку docs/decisions и добавьте правила взаимодействия с ней в системный промпт или файл инструкций. Агенту не нужны протоколы споров на митингах за прошлый год. Ему нужен актуальный свод законов проекта на сегодня и четкое право остановиться, если этот закон перестал работать.

Источник

Переводы видео, саммари новостей про AI

Как сжать промпты и сократить расходы на API нейросетей (часть 1 из 2)

Раздутые системные промпты незаметно сжигают бюджет и ухудшают ответы моделей. Когда вы описываете правила вежливым литературным языком, вы платите за лишние токены в каждом вызове API. Сжатие токенов сводится к простой задаче: передать модели ту же инструкцию, но с минимальным расходом символов. Ниже разобраны пять рабочих приемов, которые срезают лишний контекст и ускоряют генерацию.

1. Замена длинных инструкций на строгие структуры

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

Вместо такого описания:
«Пожалуйста, убедись, что твой ответ оформлен списком с буллетами и не превышает 100 слов. Не добавляй никаких вступительных слов или прощаний в конце.»

Пишем коротко:
Format: bullet points | Max: 100 words | Omit: preamble, sign-off

В первой версии ушло около 36 токенов, во второй получилось всего 14. На тысячах вызовов разница накапливается быстро. Можно использовать разделители через вертикальную черту, синтаксис YAML или кусочки JSON-схем в зависимости от того, с какой моделью вы работаете.

2. Точечные примеры вместо бесконечных списков

Few-shot подход помогает зафиксировать формат выдачи, когда обычных инструкций не хватает. Частая ошибка разработчиков заключается в том, что в промпт пихают слишком много примеров. Исследования Anthropic и тесты на бенчмарках показывают: после трех или пяти примеров точность перестает расти. Дальше вы просто жжете токены и рискуете запутать модель противоречиями.

Рабочий трехшотовый промпт для разметки тональности выглядит так:

system = """Label sentiment. Reply with one word: Positive, Negative, or Neutral.
Examples:
Input: "Shipped on time and well packaged." -> Positive
Input: "Completely broken out of the box." -> Negative
Input: "It arrived." -> Neutral"""

Этих трех строк хватает, чтобы закрепить шаблон. Проверьте свои старые цепочки: замерьте точность на одном, трех и пяти примерах перед тем, как раздувать промпт десятком вариантов.

3. Динамическая обрезка документов через эмбеддинги

Когда в контекст отправляют огромные тексты вроде договоров, регламентов или страниц документации, львиная доля токенов уходит впустую. Если в базе знаний 10 000 токенов, для ответа на конкретный вопрос модели обычно требуется пара абзацев на 800 токенов.

Решить это можно фильтрацией через косинусное сходство предложений:

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

model = SentenceTransformer("all-MiniLM-L6-v2")

def trim_context(query, passages, top_k=3):
    q_emb = model.encode([query])
    p_embs = model.encode(passages)
    scores = cosine_similarity(q_emb, p_embs)
    top_idx = np.argsort(scores)[-top_k:][::-1]
    return [passages[i] for i in top_idx]

Вместо передачи исходного текста целиком прогоняйте его через такой фильтр и отдавайте только top_k совпадений. Это сократит затраты на контекст больше чем на 90%.

4. Кэширование системных префиксов

Во многих сервисах системная часть промпта повторяется от запроса к запросу: описание роли, список доступных функций, правила безопасности. Передавать их заново каждый раз накладно. Провайдеры вроде Anthropic и OpenAI поддерживают кэширование префиксов на своих серверах, снижая цену за повторные токены.

Чтобы кэш работал правильно, структурируйте промпт по слоям от статичного к динамическому:

Источник

Переводы видео, саммари новостей про AI

Как сжать промпты и сократить расходы на API нейросетей (часть 2 из 2)

• Статический системный промпт (800 токенов) — кэшируется после первого вызова.
• Полустатический контекст или куски документации (400 токенов) — кэшируется при частых совпадениях.
• Запрос пользователя (50 токенов) — всегда свежий динамический блок в самом конце.

Перед запуском загляните в документацию вашего провайдера. Например, у Anthropic кэширование активируется только при превышении определенного порога по объему токенов и действует в рамках заданного окна времени.

5. Изоляция цепочек рассуждений в черновик

Пошаговые рассуждения (Chain-of-Thought) повышают качество логических выводов. Но если вся цепочка мыслей возвращается в API-ответе, вы переплачиваете за сотни выходных токенов, хотя пользователю нужен только финал.

Решение: заставить модель разделять черновик и результат с помощью XML-тегов:

prompt = """Solve the problem step by step inside <thinking> tags.
Then provide only your final answer inside <answer> tags.
Problem: A warehouse ships 240 units over 6 days at an uneven rate.
Day 1-3 average: 30/day. What is the Day 4-6 average?"""

Код приложения парсит полученный текст, забирает содержимое <answer> для пользователя, а блок <thinking> просто отбрасывает. Если вы используете специальные режимы рассуждений (например, extended thinking у Claude), эти токены могут рассчитываться по другим тарифам и вообще убираться из ответа.

Полезный стек для оптимизации

• LiteLLM — удобная прослойка для учета расходов и логирования токенов по разным провайдерам в едином формате.
• tiktoken — быстрая библиотека для подсчета токенов OpenAI на стороне клиента перед отправкой запроса.
• Sentence Transformers — компактные модели для поиска релевантных кусков текста перед сборкой промпта.
• LangChain — готовые модули для нарезки документов и сборки RAG-пайплайнов.

Сжатие контекста нужно не ради экономии на спичках, а для точности: модель получает ровно то, что нужно для работы. Не пытайтесь переписать весь проект сразу. Возьмите один рабочий системный промпт, замерьте точный объем через tiktoken, переведите словесные правила в лаконичный формат с разделителями и сравните финальные ответы на тестах. На масштабе в миллионы вызовов даже сокращение на 50 токенов быстро дает заметную экономию на счетах.

Источник

Переводы видео, саммари новостей про AI

AMD выпустила ИИ-ассистента Ross для разработчиков встроенных систем и FPGA

Разработка под FPGA и встроенные системы всегда отличалась высоким порогом входа, тяжеловесными средами разработки и многостраничными спецификациями. AMD решила упростить жизнь инженерам и представила AMD Ross. Это специализированный агентный помощник, созданный для проектирования, оптимизации, отладки и развертывания проектов в фирменном софте компании через обычные текстовые запросы.

Главное отличие Ross от привычных чат-ботов заключается в том, что он умеет напрямую взаимодействовать с рабочими утилитами через открытый протокол Model Context Protocol (MCP). То есть разработчику не нужно вручную копировать простыни кода или логов туда и обратно. Ассистент объединяет базу знаний вендора, готовые примеры проектов и экспертные сценарии работы под конкретные задачи.

Под капотом заявлена поддержка двух ключевых программных комплексов компании:

• Vivado любых версий. Связка работает через выделенный MCP-сервер, который дает агенту возможность управлять средой в режиме реального времени, запускать процессы и анализировать состояние проекта.
• Vitis HLS начиная с релиза 2025.2. Здесь взаимодействие строится на базе консольных утилит и готовых навыков для задач высокоуровневого синтеза.

В основе логики помощника лежат так называемые навыки агента (agent skills). Это структурированные пошаговые инструкции под типовые операции с ПЛИС, например запуск синтеза, трассировка, первичный поиск ошибок в логике или подгонка таймингов. Разработчики могут не ограничиваться шаблонами от вендора: система позволяет дописывать собственные навыки под внутренние процессы конкретной команды или архитектуру кастомной платы.

Для многих аппаратных команд передача исходников во внешние сервисы категорически запрещена политиками безопасности. В AMD это предусмотрели и заложили два варианта развертывания. Базу знаний Ross можно использовать как через облако, так и поднимать полностью локально. Для закрытых контуров без выхода в сеть (air-gapped среды) компания дает инструкции по установке локальной базы данных и подключению локальной языковой модели, способной генерировать ответы автономно.

Работать с Ross можно через популярные консольные интерфейсы, включая Claude Code, Codex CLI и GitHub Copilot CLI. Сам по себе ассистент бесплатен и не требует отдельной платной подписки, но для работы инженеру понадобятся стандартные лицензии на используемые пакеты Vivado или Vitis, а также доступ к выбранной нейросетевой модели. Новые инструменты и сценарии автоматизации компания обещает добавлять каждый месяц.

Конечно, к генерации логики на Verilog, VHDL или SystemC стоит подходить с холодной головой. Ошибки в синтезе или сбитые ограничения по таймингам стоят дорого, и железный дебаг по-прежнему требует контроля человека. Основную пользу Ross на первых порах принесет в рутине: генерация типовых tcl-скриптов, поиск неочевидных параметров в справочниках и быстрый разбор типовых ошибок компилятора.

Что стоит сделать инженерам прямо сейчас:
• Проверить версии рабочего софта на совместимость, если вы планируете тестировать Vitis HLS.
• Развернуть один из поддерживаемых CLI-клиентов и подключить сервер Ross к тестовому проекту.
• Прогнать ассистента на изолированных задачах вроде написания tcl-скриптов сборки или разбора логов синтеза.
• Обязательно вычитывать сгенерированный HDL-код и проверять отчеты таймингов перед прошивкой реального железа.

Источник

Переводы видео, саммари новостей про AI

IBM выкатила платформу Bob для закрытых контуров без выхода в сеть (часть 1 из 2)

IBM выпустила в общий доступ self-hosted версию своей среды для агентной разработки Bob. Система закрывает типовой цикл работы с софтом: изучает кодовую базу проекта, планирует изменения, пишет код и прогоняет тесты. Главная фишка релиза в том, что платформу теперь разрешили ставить на собственное железо, в суверенные облака или полностью изолированные air-gapped сети без выхода во внешнюю сеть.

Полноценные агенты вроде Claude Code или Cursor привыкли гонять контекст в облако, из-за чего безопасники в банках и на закрытых предприятиях сразу блокируют к ним доступ. Новая редакция Bob пытается решить эту проблему на уровне архитектуры, разделяя управляющую среду и сами генеративные модели.

Что умеет платформа из коробки

В поставку входит стандартный интерфейс для популярных IDE, консольная утилита BobShell, агентный движок, параллельный вызов внешних инструментов (tool calling), а также готовые профили под разные задачи.

При этом IBM решила не включать базовую модель в дистрибутив. Клиентам предлагают схему BYOL (Bring Your Own License). Выделять вычислительные мощности под инференс и покупать лицензии на сами веса придется своими силами. Список одобренных моделей на старте четко поделен под два сценария:

• Полностью изолированный режим (on-prem и air-gap): официально поддерживаются NVIDIA Nemotron и Poolside Laguna. Все артефакты сборки, контекст проекта и сам код физически остаются на ваших внутренних серверах.
• Гибридный сценарий через изолированный SaaS-шлюз: можно отправлять запросы во внешние модели по защищенным приватным каналам. В списке числятся Claude Sonnet 5.0, Claude Opus 4.8, Gemini 3.7 Flash и OpenAI GPT 5.6 Sol.

На практике это дает гибкость. Например, банк может крутить чувствительный процессинговый код сугубо локально через Nemotron, а второстепенные задачи отдавать во внешние LLM по закрытому каналу. Разработчик при этом работает в едином интерфейсе и не переключает контекст. В планах у IBM стоит умный динамический роутинг между моделями прямо на лету, но пока эту функцию в прод не отгрузили.

Зачем это нужно при живых конкурентах

На рынке автономных кодеров уже тесно, но у каждого игрока свой фокус:

• GitLab Duo Self-Hosted жестко привязан к платформе GitLab Self-Managed и крутится на vLLM, Bedrock или Azure.
• Mistral Vibe for Code опирается на открытые веса Devstral и позволяет дообучать модели через утилиту Forge прямо на своих мощностях.
• GitHub Copilot в полностью локальном виде урезан до CLI-интерфейса и требует сторонних провайдеров для подтягивания весов.

IBM бьет в сегмент, где крутятся самые большие корпоративные бюджеты: модернизация легаси. За отдельные деньги к Bob продаются премиум-пакеты под старый Enterprise Java, системы IBM i и мейнфреймы IBM Z. Это как раз тот код, владельцы которого физически не могут выгрузить проект в сторонние сервисы из-за регуляторов и отсутствия экспертизы по древним стекам на публичном рынке.

Факты о релизе

• Платформа перешла в статус General Availability и доступна корпоративным заказчикам.
• Для полностью изолированных контуров пока валидированы только Nemotron от NVIDIA и Laguna от Poolside.
• Ценника в открытом доступе нет, продажи идут исключительно через демонстрации и корпоративных менеджеров.
• Лицензии на сторонние языковые модели покупаются и настраиваются заказчиком отдельно.

Что в сухом остатке

Источник

Переводы видео, саммари новостей про AI

IBM выкатила платформу Bob для закрытых контуров без выхода в сеть (часть 2 из 2)

Если вы работаете в финтехе, телекоме или госсекторе, куда путь облачным сервисам закрыт политиками безопасности, Bob дает рабочий вариант затащить агентную разработку внутрь периметра. Правда, порог входа высокий: придется готовить серьезную серверную ферму с GPU под инференс локальной Nemotron и выбивать бюджет у IBM на закрытые enterprise-лицензии. Если мейнфреймов и древнего Java-кода в компании нет, проще присмотреться к связке GitLab Duo или локальным моделям от Mistral, которые обойдутся значительно дешевле во внедрении и поддержке.

Источник

Переводы видео, саммари новостей про AI