Semantic Kernel против LangChain: что выбрать под LLM-агента

Если вам нужно связать языковую модель с вашим кодом, базой данных и внешними API, вы почти наверняка упрётесь в выбор между двумя фреймворками: LangChain от одноимённого стартапа и Semantic Kernel от Microsoft. Оба решают одну задачу — оркестрацию вызовов LLM, подключение инструментов и памяти, построение агентов. Но делают это из разных миров: LangChain вырос в Python-экосистеме и оптимизирован под скорость прототипирования, Semantic Kernel — под встраивание ИИ в существующие .NET- и enterprise-приложения. Цена ошибки на старте — недели переписывания, когда прототип упирается в потолок выбранного инструмента.

Что это вообще за инструменты

LangChain появился в конце 2022 года и быстро стал стандартом де-факто для Python-разработчиков, собирающих цепочки вызовов к LLM. Вокруг него выросла инфраструктура: LangGraph для графов состояний агента, LangSmith для трассировки и отладки, сотни готовых интеграций с векторными базами, моделями и загрузчиками документов.

Semantic Kernel — SDK от Microsoft, ориентированный прежде всего на команды, которые уже живут в .NET и Azure. Его главная идея — плагины: вы описываете функции (нативные или на основе промптов), а ядро само решает, какие вызвать для выполнения задачи. SK позиционируется как «лёгкий слой оркестрации», который не навязывает всю архитектуру приложения.

Языки и рантайм

LangChain — это в первую очередь Python, с полноценным TypeScript/JavaScript-портом. Semantic Kernel начинался с C#, а позже получил поддержку Python и Java. На практике зрелость версий отличается: под .NET у SK самый полный набор возможностей, Python-версия догоняет, Java-версия обычно отстаёт по фичам. Проверяйте статус конкретной функции в документации перед тем, как закладывать её в архитектуру.

Ключевые различия по существу

Разница не в том, «кто мощнее», а в том, под какой контекст заточен каждый фреймворк. Ниже — сравнение по параметрам, которые реально влияют на проект.

Оба проекта открыты под лицензией MIT, так что юридического барьера для коммерческого использования нет ни там, ни там. Разница — в инженерной культуре вокруг них.

Выбирайте не «лучший фреймворк вообще», а тот, что совпадает с вашим стеком. Python-команда на LangChain и .NET-команда на Semantic Kernel сделают рабочего агента быстрее, чем любая из них — на чужом для себя инструменте.

Как выглядит код

Разница философий видна уже на простом примере — вызове модели с промптом. LangChain через LCEL (LangChain Expression Language) собирает пайплайн из компонентов оператором |:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template(
    "Переведи на английский: {text}"
)
model = ChatOpenAI(model="gpt-4o-mini")

chain = prompt | model
result = chain.invoke({"text": "Привет, мир"})
print(result.content)

Semantic Kernel на C# строит вызов вокруг ядра и функции из промпта:

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o-mini", apiKey);
var kernel = builder.Build();

var translate = kernel.CreateFunctionFromPrompt(
    "Переведи на английский: {{$text}}");

var result = await kernel.InvokeAsync(
    translate, new() { ["text"] = "Привет, мир" });

Console.WriteLine(result);

LangChain читается как поток данных, SK — как вызов сервиса с параметрами. Ни один подход не «правильнее»: первый ближе к data-инженерному мышлению, второй — к привычному ООП-коду корпоративного бэкенда.

Точные версии и API сверяйте с документацией

Оба фреймворка развиваются быстро, и публичные API периодически ломают обратную совместимость между минорными версиями. Имена классов, сигнатуры методов и статус конкретных фич (например, планировщиков в SK или отдельных цепочек в LangChain) уточняйте в актуальной документации проекта, а не по устаревшим туториалам — примеры выше отражают общий подход, а не гарантированно рабочий код на вашей версии.

Когда что выбирать

Свести решение к чек-листу проще, чем к теоретическому спору.

• Берите LangChain, если пишете на Python или TypeScript, нужна максимальная скорость от идеи до прототипа, важен доступ к большому числу готовых интеграций (векторные базы, загрузчики документов, экзотические модели) и вам подходит внешний сервис трассировки LangSmith.
• Берите Semantic Kernel, если ваш продукт живёт в .NET/C#, вы встраиваете ИИ-функции в существующее корпоративное приложение, у вас уже есть инфраструктура Azure и вы цените предсказуемость и типизацию над количеством готовых блоков.
• Рассмотрите оба параллельно, если команда смешанная: часть логики можно вынести в Python-сервис на LangChain, часть — оставить в .NET-монолите на SK, связав их по HTTP. Это дороже в поддержке, но иногда честнее, чем ломать привычный стек.

Что учесть про агентов и графы

Если задача сложнее одиночного промпта — многошаговый агент с ветвлениями, откатами и состоянием, — у LangChain для этого есть отдельный слой LangGraph, который описывает поведение агента как граф узлов и переходов. В Semantic Kernel аналогичную роль играют планировщики и связка плагинов, а также агентная подсистема, которую Microsoft активно перерабатывает. Перед выбором проверьте, в каком статусе (preview, stable) находятся нужные вам агентные возможности в каждом фреймворке — именно здесь чаще всего встречаются экспериментальные API.

Итог простой. Это не соревнование «кто победит рынок», а два инструмента под разные команды. LangChain выигрывает в скорости старта и широте экосистемы, Semantic Kernel — в интеграции с .NET и корпоративной дисциплине. Ошибка не в выборе «слабого» фреймворка, а в выборе чужого для вашего стека.