Ние създаваме неправилни системи. Не малко погрешно, фундаментално, структурно, катастрофално погрешно. Моделът е винаги един и същ. Екипът открива магията на Големия езиков модел. Те го опаковат в Python скрипт. Те му дават достъп до базата данни, API портала и дневниците за поддръжка на клиентите. Те хвърлят три гигабайта документация в контекстния прозорец, защото "1 милион токена" звучат като безкрайно съхранение. Наричат го „агент“. Монолитен, всезнаем, недиференциран блок от логика, който се опитва да бъде едновременно изпълнителен директор, управител и администратор на базата данни. И това се проваля. Тя халюцинира. Тя се обърква. Тя струва богатство в използването на токени. Латентността се свива, докато потребителското преживяване се чувства като чакане за свързване на повикване през 1999 г. Когато се счупи (и винаги се счупва), инженерите не могат да го дебютират, защото логиката не е в кода. Прекарах последната година, разкъсвайки тези системи.Решението не е по-добро решение.Не е по-голям модел.Решението е архитектура. Пълен технически анализ с код и бенчмаркове → Пълен технически анализ с код и бенчмаркове → Защо третираме 1 милион токена като безкрайна RAM? Сегашната ортодоксия в развитието на AI е съблазнена от "Контекстния мит на прозореца". Ние сме били продадени лъжа. Лъжата е, че ако дадете на модел достатъчно контекст, той може да реши всеки проблем. Продавачите натискат "безкраен контекст" като крайна функция. 128k. 1 милион. 2 милиона токена. Последствията са съблазнителни. Не се притеснявайте за архитектурата. Не се притеснявайте за обработката на данни. Просто го изхвърлете. Това доведе до възхода на парадигмата на Бог-агент. В този светоглед "Агентът" е уникална единица. Той притежава цялото състояние на приложението. Той има достъп до всеки инструмент в библиотеката. Когато потребителят задава въпрос, Бог-Агентът получава заявката, разглежда нейния масивен контекст (който съдържа цялата история на вселената) и се опитва да разсъждава по пътя си към отговор. Изглежда като научна фантастика мечта за уникален, съзнателен AI. Но в производството това е кошмар. Ние ефективно искаме от младши разработчик да запомни цялата кодова база, ръководството на компанията и правните архиви и след това да ги помоли да поправят CSS грешка в рамките на 30 секунди. Те няма да поправят грешката.Те ще имат паническа атака. Защо моят агент струва 50 долара, за да каже "Не знам"? Пукнатините в архитектурата на God Agent са видими за всеки, който тласка кода към производство. Колкото повече информация предоставяте, толкова по-малко внимание моделът обръща на критичните битове. Това не е просто усещане. Това е архитектурен дефект. Изследванията показват, че моделите се борят да извличат информация от средата на дълги контексти. Чрез неуспех да курират, ние активно увреждаме изпълнението. Ние създаваме системи, където "шумът" на несъответстващата документация преодолява "сигнала" на конкретното намерение на потребителя. 1. Context Pollution (The Needle in the Haystack) Всеки токен струва пари. Всеки токен отнема време да се обработи. Божествен агент, който препрочита контекст от 50 000 токена за всеки ход на разговора, изгаря пари. Това е изчислително разхитително. Ние управляваме суперкомпютър, за да отговорим "да" или "не", защото не се притеснявахме да филтрираме входовете. 2. Latency and Cost Когато Бог Агент се проваля, защо се проваля? Това беше поканата? Стъпката на извличане? Изходът на инструмента? Или просто се разсейва от несъответстващ текст от страница 405 от документацията? Не можете да тествате едно покана, която променя поведението си въз основа на променливата супа на масивен контекст прозорец. 3. The Debugging Black Hole Един-единствен агент с достъп до всичко е кошмар за сигурността. Ако бързото инжектиране работи, нападателят е собственик на замъка. Няма булеварди. Няма "нулево доверие", защото архитектурата разчита на максимално доверие в вероятностния модел. 4. The Governance Void Дали решението е просто микроуслуги (отново)? Да, това е така. Пътят напред е и на . Aggressive Context Curation Agentic Mesh Трябва да го заменим с мрежа от малки, специализирани, силно ограничени агенти, които комуникират чрез стандартизирани протоколи. В мрежата, нито един агент не знае всичко. Агентът на маршрутизатора знае как да класифицира намерението. Агентът за поддръжка знае политиката за връщане. Агентът за кодиране знае Python. Агентът на SQL знае схемата на базата данни. Те не споделят контекст, те споделят съобщения. Това е преходът от монолит към микроуслуги. Това е единственият начин за мащабиране на сложността. Когато Агентът за поддръжка работи, той не трябва да знае схемата на базата данни. Той не се нуждае от библиотеките на Python. Неговият контекст е непокътнат. Той е куриран. Нека разгледаме разликата в структурата на кода. Оригинално име: The God Prompt Това е, което повечето хора пишат днес. # GOD AGENT - ANTI-PATTERN # We dump everything into one system prompt. system_prompt = """ You are an omniscient AI assistant for Acme Corp. You have access to: 1. The User Database (Schema: users, orders, items...) 2. The Codebase (Python, React, TypeScript...) 3. The Company Handbook (HR policies, returns, holidays...) 4. The Marketing Style Guide Instructions: - If the user asks about SQL, write a query. - If the user asks for a refund, check the handbook policy then query the DB. - If the user asks for code, write Python. Current Context: {entire_rag_retrieval_dump} {last_50_messages} """ # Result: The model gets confused. # It tries to apply HR policies to SQL queries. # It hallucinates tables that don't exist. Пийтън The New Way: Агентската мрежа Тук разделяме логиката. рутерът не върши работата. # MESH ARCHITECTURE - PATTERN # Step 1: The Router Agent # Its only job is to classify and route. It has NO domain knowledge. router_prompt = """ You are a routing system. Analyze the user input and route to the correct agent. Available Agents: 1. billing_agent (Refunds, invoices, payments) 2. tech_support_agent (Python, SQL, Bug fixes) 3. general_chat_agent (Casual conversation) Output JSON only: {"target_agent": "name", "reasoning": "string"} """ # Step 2: The Specialist Agent (Billing) # This agent loads ONLY when called. # It has zero knowledge of Python or SQL. billing_agent_prompt = """ You are a Billing Specialist. You handle refunds and invoices. Tools available: [stripe_api, invoice_db] Context: {user_transaction_history_only} {refund_policy_summary} """ Пийтън Виждате ли разликата? Не може да халюцинира SQL синтаксиса, защото не знае какво е SQL. Неговата вселена е малка. billing_agent Как агентите наистина говорят без халюцинации? Аз съм скептичен към големите технологични рамки. Те обикновено добавят набъбване. Но Google Agent Development Kit (ADK) и протоколът Agent-to-Agent (A2A) са различни. Google осъзна, че ако искаме агентите да работят, те трябва да говорят помежду си като софтуер, а не като чатботове. Протокол A2A Това е променителят на играта. Протоколът A2A е неутрален на доставчика стандарт за агенти, за да откриват и разговарят помежду си. Той използва "Агентни карти". Това са стандартизирани JSON метаданни, които описват какво може да направи агент. Помислете за това така: { "agent_id": "billing_specialist_v1", "capabilities": ["process_refund", "check_invoice_status"], "input_schema": { "type": "object", "properties": { "transaction_id": {"type": "string"}, "user_intent": {"type": "string"} } }, "output_schema": { "type": "object", "properties": { "status": {"type": "string", "enum": ["success", "failed"]}, "refund_amount": {"type": "number"} } } } джон Когато агентът на маршрутизатора трябва да обработи възстановяване, той не се опитва да халюцинира повикването на API. , ръкостиска чрез A2A, преминава структурирания полезен товар и чака структуриран отговор. billing_specialist Това е стандартизация.Това ни позволява да изградим където агенти от различни екипи или дори различни компании могат да си сътрудничат. Agentic Mesh Понастоящем агент на OpenAI не може да говори с агент на Vertex AI. С A2A те споделят протокол. Какво всъщност означава това Приемането на мрежа архитектура променя всичко за начина, по който изграждаме. Традиционната наблюдаемост (логи, метрики, следи) е недостатъчна. Трябва да видим на Защо маршрутизаторът се предава на агента за фактуриране? Защо агентът за фактуриране отхвърля искането? Трябва да проследим цената и закъснението на всеки възел в мрежата. Ако нямате това, не изграждате система. 1. Observability is Mandatory Agentic Observability Разумната верига В модела на God Agent, сигурността е двоичен превключвател. Агентът за фактуриране не се доверява на агента на маршрутизатора по подразбиране. Той проверява полезния товар. Той проверява политиката. Той ограничава радиуса на взрива. 2. Zero Trust Security Zero Trust Инженерингът като самостоятелна дисциплина умира. Истинската работа е в логиката на маршрутизацията, дефиницията на схемата и стратегията за куриране на контекста. 3. The End of "Prompt Engineering" System Engineering Трябва да станем безмилостни редактори. Целта не е да попълним контекстния прозорец. Целта е да го изпразним. Трябва да компресираме. Трябва да обобщим. Трябва да инжектираме само точно това, което е необходимо за следващата незабавна стъпка. Ако агентът е натоварен с писането на SQL, той се нуждае от схемата. Нуждаем се от декларация за мисия на компанията. 4. Aggressive Context Curation не (Звучи очевидно, но виждам, че се игнорира в 90% от кодовите бази.) Прочетете пълния технически дефект → Прочетете пълния технически дефект → TL;DR за скалъперите God Agents се проваля: Намаляването на контекстния прозорец води до объркване, високи разходи и невъзможност за дебютиране. Разделяне на притесненията: Създайте специализирани агенти (Billing, SQL, Chat), които правят едно нещо добре. Използване на протоколи: агентите трябва да комуникират чрез
