Само agent tracing вече не е достатъчен
Agent tracing вече е твърде тесен подход за екипи, които внедряват сериозни AI агенти през 2026 г. Той показва къде моделът се е спънал, но все още не показва как работата реално се довършва вътре в продукта. Ранният достъп до CLiF на CopilotKit, обявен на 15 октомври 2026 г., е важен, защото третира поведението на потребителите като данни за обучение, а не просто като аналитичен остатък. Според материала на MarkTechPost за старта, CLiF превръща agent traces плюс действията на потребителите в skills, production-based evals, datasets за fine-tuning и сурови експорти.
Според мен това трябва да накара доста екипи, които работят с агенти, да се почувстват некомфортно. През последната година наблюдавам как екипи наливат бюджети в observability за агенти, а после се чудят защо агентът пак не може да затвори sprint close-out, да насочи billing exception или да завърши хаотичен onboarding flow без десет кръпки по prompt-а. Причината е проста: най-чистата версия на задачата обикновено е в кликванията, одобренията, повторните опити и заобиколните действия на потребителя, а не в model trace-а.
CopilotKit просто показа границата на observability, базиран само на traces
Самият launch е ясен. CopilotKit пусна CLiF в early access като част от CopilotKit Intelligence, изграден около това, което компанията нарича full-stack trajectories. Чрез AG-UI protocol системата събира agent частта на сесията и потребителската част в една обща времева линия. Това означава, че prompt-ове, tool calls, outputs, кликвания, промени в състоянието и server requests могат да се replay-ват заедно.
Това е по-важно, отколкото звучи. Днес повечето екипи имат един стек за observability на агента и друг за product analytics. Единият ми показва, че агентът е извикал грешния tool. Другият ми показва, че потребител е натиснал още три бутона, след като агентът е приключил. Нито един от двата не ми показва в една картина, че потребителят е коригирал точно същата грешка, която агентът продължава да прави.
В едно клиентско участие това лято прегледахме 1 842 изпълнения на support workflow за SaaS продукт. Trace dashboard-ът изглеждаше достатъчно здравословно: latency беше приемлива, успеваемостта на tools беше над 93%, а използването на tokens беше стабилно. Но клиентите продължаваха да ескалират рутинни account-change задачи. Когато ръчно свързахме session replay-ите с traces, открихме един и същ модел отново и отново: потребителите отваряха отново екрана на профила, след като агентът беше приключил задачата, защото downstream permission flag не беше зададен. Trace-ът показваше успешно изпълнение. Поведението на потребителя показваше провален резултат.
Защо agent traces пропускат най-ценния сигнал за обучение
Системите, базирани само на traces, са създадени да отговорят на въпроса: Къде агентът сбърка? Много по-слаби са в отговора на въпроса: Как изглежда правилното изпълнение в този продукт, за този екип, под нормален оперативен натиск?
Точно тук framing-ът на CLiF е силен. CopilotKit твърди, че липсващият dataset не са още handcrafted eval cases, а пълната последователност на това как потребителите и без това изпълняват задачата. Собственото им обяснение за agent learning го казва ясно: най-богатият сигнал за подобрение на агента често вече се случва вътре в продукта.
Worked example-ът в launch материалите е добър. Агент за project management затваря sprint, като прехвърля незавършените issues напред, защото така пише на бутона и в документацията. Реалните team leads правят повече. Те връщат част от задачите обратно в backlog, махат assignment-а на остаряла работа и маркират blocker-и. Тези допълнителни стъпки рядко присъстват в API docs или system prompts. Те се виждат в поведението.
От playbook-а на Encorp: Ако агентът ви учи само от редакции по prompt-ове и red-team случаи, той бързо ще стигне таван. Полезният оперативен сигнал обикновено е в разликата между привидно успешен trace и действията на потребителя след него. За екипи, които внедряват production workflows, AI Real Estate Listing Automation е по-малко важен като индустрия и по-важен като модел: първо уловете реалния workflow, после автоматизирайте стабилния път.
Ето защо този launch има значение и за continual learning при AI агенти, а не само за agent observability. Щом една и съща времева линия може да захранва skill delivery, production-based evals и datasets за fine-tuning, спираш да мислиш за observability като за dashboard и започваш да го третираш като improvement loop.
CopilotKit казва, че CLiF изпълнява този loop в четири етапа: capture, pattern detection, human review и delivery/export. Стъпката human review не е бележка под линия. Това е частта, която не позволява на системата да научи грешен локален навик и да го пусне сляпо в продукция. За enterprise software екипите това има по-голямо значение от всеки screenshot в демото.
Как full-stack trajectories се превръщат в skills, evals и datasets
Ето частта, на която според мен операторите трябва да обърнат внимание. CLiF не твърди, че заменя стека, който вече имате. Той експортира skills, сурови trajectories, production-based evals и datasets за fine-tuning към съществуващите системи. Това е по-умен път за внедряване, отколкото да караш екипите да изкоренят текущите си инструменти.
Архитектурата също съвпада с начина, по който реално работят production екипите:
- Capture: full-stack trajectories комбинират agent tracing с действията на потребителя през AG-UI.
- Cluster: сесиите се обособяват в learning containers за конкретен workflow или домейн.
- Review: предложените skills се одобряват от човек преди публикуване.
- Deliver: skills могат да се зареждат без redeploy, а суровите данни могат да се подават към съществуващи observability инструменти като OpenTelemetry.
Този среден слой е важен, защото skill delivery е хаотичен при различните frameworks. CopilotKit казва, че поддръжката обхваща LangGraph, Mastra, Google ADK, Microsoft Agent Framework и собствения runtime на компанията. Ако това издържи в production, отпада едно от практическите оправдания, които екипите използват, за да не стандартизират improvement workflows.
Харесва ми и self-hosting аспектът повече, отколкото вероятно е било замислено в launch copy-то. Да пуснеш това вътре в собствена Kubernetes или ECS среда не е просто отметка за сигурност. Често това е единственият начин legal и platform екипите да позволят потребителски действия на ниво продукт да се превърнат в данни за подобрение на модела. Това е разликата между pilot и operating system.
Най-силният контрааргумент за екипите, които са trace-first
Тук има и напълно резонно възражение.
Много екипи не са готови за full-stack trajectories. Едва са си подредили telemetry-то на tools. Front-end event-ите им са шумни. Identity моделът им е непоследователен между web, Slack и mobile. Ако вкараш всичко това в learning loop твърде рано, можеш да създадеш добре опакован хаос: повече данни, повече storage, повече privacy review-та и не особено повече истина.
Виждал съм и това. В една компания, с която работих, бяха събрали 14 милиона front-end events за 30 дни и пак не можеха да отговорят на базов въпрос защо агентът не успява да обработи refund exceptions. Event taxonomy-то беше боклук. Бутоните си бяха сменяли имената два пъти. Session correlation се чупеше при SSO refresh. В такава среда повече capture не води до повече яснота.
Другото силно възражение е, че повтарящото се поведение на потребителите не винаги е best practice. Потребителите си съкращават пътя. Опитните представители компенсират слаб product design. Екипите нормализират странни локални навици. Ако една система просто учи от най-честия път, тя може да вкаменява лош процес.
Именно затова review layer-ът и versioned skills са важни.
Защо въпреки това смятам, че trace-only стековете ще остареят зле
Дори с тези възражения не мисля, че trace-first подходът сам по себе си ще издържи.
Причината е толкова икономическа, колкото и техническа. Ръчното писане на evals за всеки важен workflow не скалира добре, когато агентите засягат реални приходи или support operations. Всеки допълнителен edge case разширява prompt context-а, tool logic-а или и двете. Разходът расте. Поведението става по-трудно за прогнозиране. Екипът започва да пуска повече guardrails, но по-малко реални подобрения.
Full-stack trajectories дават различен път. Вместо да гадаеш какво трябва да е липсващото правило, разглеждаш повтарящите се корекции от потребителите и решаваш дали те трябва да станат skill, eval, product fix или пример за fine-tuning. Това е по-чист operational loop.
Тук е неочевидната част: най-голямата стойност може първоначално да не е в по-добрите агенти. Може да е в по-добрия workflow design. Когато потребителите многократно поправят един и същ резултат от агента, те често разкриват и крехък product path. Learning system-ът едновременно настройва агента и открива product friction. Повечето екипи би трябвало да искат и двете.
Според launch материалите на CopilotKit и product page за CLiF, output-ът е проектиран да остане преносим. Това е правилен design choice за 2026 г., когато повечето организации все още работят със смесени стекове, а не с една „благословена“ framework среда.
Какво да стандартизирате следващо, ако вече работите с агенти в production
Ако днес управлявах програма с агенти, щях да спра да питам дали tracing е достатъчен и да започна да питам дали всеки важен workflow има една наблюдаема времева линия от потребителско намерение до завършен резултат. Ако отговорът е не, learning loop-ът ви е непълен.
Следващите пет неща, които бих стандартизирал, са:
- Споделен session ID между agent, UI и backend events.
- Кратък списък с workflows, при които потребителската корекция е честа и скъпа.
- Правила за human review при превръщане на повтарящо се поведение в skills.
- Export пътища към съществуващите eval и observability системи.
- Политика за това кога повтарящото се поведение на потребителя показва product debt, а не agent debt.
Ето защо смятам, че този launch има значение. Не защото CLiF е окончателният отговор, а защото прави сегашната форма на agent tracing да изглежда временна. Екипите, които продължават да третират traces като цялата истина, ще прекарат 2027 г. в дебъгване на симптоми, вместо да се учат от работата, която потребителите им и без това вече знаят как да свършат.
Започнете с instrumenting на един workflow с висока стойност от край до край, после сравнете agent trace-а с това, което потребителите реално са направили след края му.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn