Разработка на AI агенти след отделянето на SDK от Cline
Обръщам внимание, когато инструмент за AI кодиране спре просто да пуска нови функции и започне да преработва основната си инфраструктура. Тази седмица разработката на AI агенти получи точно такъв сигнал: Cline извади вътрешния си agent harness в самостоятелен open-source TypeScript runtime, @cline/sdk, и започна да мигрира собствените си продукти към него.
Това е важно, защото повечето agent проекти не се провалят на демо. Провалят се, когато UI-ят крашне, когато state-ът се оплете с оркестрацията или когато екипът иска един и същ агент да работи в CLI, IDE, браузър и scheduled job, без да поддържа четири отделни code path-а. Според анализа на MarkTechPost, отговорът на Cline е да отдели loop-а от продуктовата обвивка и да направи runtime-а за повторна употреба.
Защо това издание е важно за разработката на AI агенти отвъд самия Cline?
От гледна точка на имплементацията аз виждам това по-малко като продуктов launch и повече като архитектурна корекция. Старият модел държеше agent loop-а твърде плътно вързан за VS Code extension-а. Това е приемливо в началото, но щом екипите поискат персонализирани AI агенти в няколко различни среди, тази обвързаност започва да струва скъпо. Не можете лесно да премествате сесии, да сменяте provider-и или да държите long-running задачи живи, когато front-end-ът се рестартира.
Редизайнът на Cline адресира точно този failure mode. В официалното си съобщение екипът казва, че новият runtime означава, че long-running работата вече не умира при UI рестарт и сесиите могат да се прехвърлят по-чисто между различни среди, защото loop-ът остава stateless, а runtime-ът около него става durable и portable. Това се вижда директно в launch публикацията на Cline и в SDK документацията.
В един клиентски проект миналото тримесечие видяхме същия проблем в напълно различен стек: browser-based support agent изглеждаше стабилен, докато потребител не refresh-неше страницата по средата на задача. Моделът беше наред. Проблемът беше в orchestration дизайна. Затова това издание е релевантно за enterprise AI интеграции, дори никога да не ползвате Cline.
Как е организиран реално новият четирислоен стек?
Тази част ми харесва, защото границите между пакетите са практични, а не академични. Стекът започва от @cline/shared в основата, минава през @cline/llms, @cline/agents и стига до @cline/core, който @cline/sdk re-export-ва.
Ето практичния прочит на това разделение:
@cline/shared: типове, схеми, helper контракти, extension utilities@cline/llms: provider routing и model catalog-и@cline/agents: stateless, browser-compatible execution loop@cline/core: Node runtime аспекти като sessions, storage, built-in tools, scheduling, telemetry, transports и plugin loading
Техническата печалба тук е дисциплината в dependency-ите. Provider логиката стои в @cline/llms, а не в loop-а, така че AI API интеграция става основно конфигурационен проблем, а не пренаписване. Stateless loop-ът в @cline/agents също прави browser или serverless embedding далеч по-реалистичен.
Ако трябва да го обясня на delivery екип, бих казал, че Cline е разделил мисленето, routing-а и операционната част в различни кутии. Това е разликата между добро демо и AI интеграционна архитектура, която може да се поддържа.
Какъв operational проблем всъщност решаваше Cline?
Големият проблем е чупливостта при реална употреба. Agent системите често изглеждат способни в кратки сесии, а после стават крехки, когато трябва да поддържат persistence, retries, checkpoints, scheduled work или handoff-и между различни продуктови среди.
Документацията на Cline посочва няколко operational промени: durable sessions, native scheduling, checkpointing, built-in web search, MCP connectors и plugin loading на runtime ниво. Това не са козметични промени. Това са скучните, но решаващи части, които определят дали AI автоматизация на работни процеси ще издържи в контакт с реални потребители.
Смятам също, че browser-compatible stateless loop-ът е подценен. Той означава, че основният decision cycle може да се embed-не там, където екипите реално имат нужда, докато по-тежките runtime отговорности остават отделени. Това намалява изкушението да се дублира orchestration логика в CLI, web app и IDE.
За екипи, които изграждат вътрешни copilots или AI automation agents, тук има един неочевиден урок: ако session моделът, tool моделът и transport моделът живеят на едно място, всяка продуктова промяна се превръща в пренаписване на агента. Ако са добре разделени, продуктовите екипи могат да се движат по-бързо, без да чупят loop-а.
Казват ли benchmark числата нещо полезно, или това е просто launch-week театър?
Някои от benchmark твърденията си струва да се отбележат, с обичайното уточнение, че benchmark-и, пуснати от самия екип, трябва да се валидират във вашата среда. Cline публикува Terminal Benchmark 2.0 резултати в tbench.ai, според които Cline CLI с claude-opus-4.7 достига 74.2%, срещу публикуваните от Anthropic 69.4% за Claude Code със същия модел. При claude-opus-4.6 Cline отчита 71.9% срещу 65.4% за Claude Code.
При open-weight модели Cline отчита 55.1% за kimi-k2.6, спрямо 37.1% за OpenCode и 45.5% за Pi-Code, при pass@1 scoring към 8 май 2026 г.
Тези числа не доказват универсално превъзходство. Но подсказват, че пренаписването не е било само структурно. Екипът също казва, че е пренаписал prompt-ите, опростил е loop-а, стегнал е context handling-а и е подобрил error feedback-а. Тази комбинация обикновено има по-голямо значение от избора на модел сам по себе си.
Cline казва, че е “rewrote the prompts, simplified the loop, tightened context management, improved feedback loops and error handling, and rethought how tools are defined and surfaced to the model.”
Като оператор бих приемал тези резултати като причина да тествам, а не като причина веднага да стандартизирам. Benchmark-ите показват дали една система е интересна. Не показват как ще се държи с вашите репозитории, вашите approval policy-и и вашите failure budget-и.
Как plugins и provider extensions променят уравнението build-vs-buy?
Тук SDK-то става нещо повече от рефакториране. Според документацията, plugin-ите могат да регистрират tools, да наблюдават lifecycle events, да добавят rules и commands и да оформят това, което агентът вижда. Екипите могат да прототипират като локални .ts или .js модули, а после да ги package-нат с manifest, когато поведението стане стабилно.
Това има значение за услуги по AI имплементация, защото повечето реални внедрявания имат нужда бързо от domain-specific tools: търсене във вътрешна документация, test runners, deployment guards, ticketing hooks или approval policy-и. Ако plugin surface-ът е чист, няма да ви се налага да форквате runtime-а всеки път, когато даден бизнес екип иска още една възможност.
Custom provider-ите също са практичен детайл. Cline предоставя registry функции в @cline/llms, така че екипите могат да имплементират ApiHandler и да регистрират собствен provider или модел. За компании, които работят със self-hosted endpoints, Bedrock routing или OpenAI-compatible gateway-и, това намалява триенето при enterprise AI интеграции.
Свързан service pattern, който виждам тук, е operationalizing на agent workflows, а не просто прототипиране. За екипи, които правят подобно внедряване, най-близкото съвпадение е страницата AI DevOps workflow automation, защото реалното предизвикателство е да поддържате agent jobs, tools, approvals и runtime поведение стабилни в production.
Защо native multi-agent support е по-важен, отколкото звучи?
Защото отделните orchestration слоеве много бързо създават нови failure surface-и. Runtime-ът на Cline включва agent teams и subagents директно, така че една сесия може да делегира към специалисти, да следи прогреса и да пази handoff бележките вътре в същия runtime.
Това е по-чисто от това да сложите multi-agent framework върху single-agent tool и после да се опитвате да синхронизирате логове, state и permissions. Виждал съм екипи да губят седмици в wiring на message passing между specialist agents, само за да открият, че скъпата част не е делегирането. Скъпата част е recovery-ът след частичен failure.
Ако subagent-ите споделят persistence, checkpointing и tool discipline на runtime-а, edge case-овете са по-малко. Компромисът е, че тогава зависите повече от абстракциите на runtime-а. Ако те не пасват на продуктовите ви ограничения, може пак да ви трябва custom orchestration.
Затова правилният въпрос не е „поддържа ли multi-agent?“. Правилният въпрос е „къде живеят state-ът, handoff-ите и approval-ите, когато един агент блокира в 2 през нощта?“. Изглежда, че Cline е помислил точно за това.
Какво трябва да тестват първо екипите, ако оценяват този SDK сега?
Бих държал оценката тясна и operational.
Първо, тествайте durability: стартирайте дълга задача, прекъснете UI-а, възстановете сесията и проверете дали работата продължава чисто. Второ, тествайте provider switching през @cline/llms, вместо да вграждате model логиката твърдо в приложението. Трето, тествайте един plugin, който докосва реална вътрешна система, например извличане на документация или CI статус. Четвърто, тествайте дали subagent-ите намаляват усилието на операторите, или просто добавят още traces за дебъгване.
Практическата начална конфигурация е ясна: Cline изисква Node.js 22 или по-нова версия, поддържа Anthropic, OpenAI, Google, AWS Bedrock, Mistral, LiteLLM и OpenAI-compatible endpoints и предлага примери в repo-то и документацията си. За първи тест бих пропуснал лъскавото demo и бих минал директно към един workflow, който в момента се чупи във вашата среда.
Ако този workflow стане по-евтин, по-устойчив и по-лесен за наблюдение, тогава SDK-то си върши работата. Ако не, архитектурата може и да е правилна, но все още да не е правилната за вашия стек.
Какво следя аз след това издание?
Следя IDE миграциите повече от самия SDK пакет. Миграцията на VS Code и JetBrains към един и същ runtime ще покаже дали модулният дизайн наистина издържа под продуктов натиск.
Следя и дали външни екипи ще изградят сериозни plugin-и и custom provider-и, а не само примерни интеграции. Обикновено тогава става ясно дали един runtime е действително reusable, или просто добре опакован. В разработката на AI агенти трудното рядко е да накараш един агент да тръгне веднъж. Трудното е едно и също agent поведение да оцелее през инструменти, екипи и месеци.
Написано от екипа на Encorp. Свържете се с нас: запазете 30-минутен разговор или ни последвайте в LinkedIn.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation