Diptiman Raichaudhuri, адвокат з розвитку персоналу в Confluent Diptiman Raichaudhuri, адвокат з розвитку персоналу в Confluent Інженерні команди експериментують з агентами AI у швидкому темпі.Насправді, нещодавнє опитування PwC виявило, що Для розробників Python ця зміна не вимагає вивчення абсолютно нового штабу. Існуючі мікросервіси можуть бути модифіковані за допомогою агентських кінцевих точок, створення агента AI часто є "тільки іншим кінцевим пунктом API", розробленим за допомогою знайомих інструментів, таких як FastAPI. 79 79 З оркестровими агентами можна об'єднати відповіді з різних агентичних покликань і повернути користувачеві єдиний, значущий уявлення. Це являє собою перехід від простих циклів запиту-відповіді до шаблону, де різноманітні мікрослужби обмінюються повідомленнями по декількох корпоративних додатках. Для розробника Python, який використовує рамки, такі як FastAPI, цей перехід є безшумним - оркестровий просто стає більш витонченою "API-інтерфейсом", що координує потік даних між різними спеціалізованими агентами. MCP разом з великими мовними моделями (LLM), такими як Claude, ChatGPT або Gemini, можуть брати запити користувачів як природні мовні входи і вибирати правильний набір інструментів для виклику з серверів MCP. Цей робочий процес значно спрощує взаємодії агентів. Модель контекстного протоколу Модель контекстного протоколу Рамки, такі як FastMCP, дозволяють розробникам Python швидко будувати детерміністичні інструменти MCP, так що неоднозначність LLM, які намагаються зрозуміти інструкції користувача, замінюється компонентами підприємства для отримання уявлень. FastMCP є рамкою вибору для перетворення кінцевих точок REST API на основі FastAPI в специфікацію виклику інструментів MCP. У той час як MCP абстрагує окремі виклики інструментів на базах даних та API, існуючу кодову базу API Python потрібно модифікувати, щоб запровадити ці кінцеві пункти виклику. Для розгортань виробництва, переконайтеся, що точний інструмент MCP викликається, замість того, щоб перераховувати "всі інструменти", які часто призводять до Для потокового робочого навантаження, залишається найпопулярнішою формою потокового потоку даних з відкритим кодом для розробки мікросервісів, які взаємодіють з подіями в реальному часі. Apache Kafka має випробуваний Python SDK, добре підходить для створення мікросервісів, які вбудовують виробників Kafka і споживачів Kafka. Розробники Python можуть будувати архітектуру, орієнтовану на події, з мікросервісами, які здійснюють обмін повідомленнями через кінцеві точки REST, в той час як Kafka довго зберігає потокові дані. Апач Кафка Апач Кафка Для збагачення, агрегації та трансформації потокових даних, що зберігаються в Kafka, Apache Flink SQL надає знайому модель програмування. З Flink SQL, робочі процеси агентства в режимі реального часу накладають правила якості даних і трансформують дані в польоті на теми Kafka. Це важливий крок у всьому трубопроводі даних і гарантує, що агенти, які закликають дані внизу трубопроводу, мають багаті, чисті та надійні дані. Давайте застосуємо ці поняття до потоку роботи агентів в реальному часі для роздрібного магазину, який прагне краще зрозуміти поведінку своїх клієнтів. Уявіть, що у нас є магазин одягу, який приймає і виконує замовлення. З часом, дані історичних замовлень накопичуються, підкреслюючи поведінку покупців, відзначаючи, які продукти продаються швидко, повторюють клієнтів, і які вікові групи замовляють найбільше одягу. Уявлення з цих історичних даних допомагають магазину вирішувати стратегію впровадження нової лінії одягу і планів валюти для максимізації доходів. У той же час, поведінка покупців в реальному часі відображає, як клієнти купують продукти, як це відбувається. Припустимо, що історичні дані зберігаються як таблиці Apache Iceberg, а поведінка в реальному часі зберігається на Кафці. Об'єднавши ці два джерела, ми надамо магазину точну поведінку покупця в реальному часі, засновану на минулих звичках. Щоб зробити це, агентам AI доведеться витягувати інформацію з системи онлайн-аналітичної обробки (OLAP) і Apache Kafka. Щоб ілюструвати це, давайте розглянемо систему OLAP, яка складається з .Parquet файлів, що зберігаються в Apache Iceberg Lakehouse, який запитується DuckDB, і поточного зберігання в реальному часі, споживаного від Apache Kafka. Два агенти AI, кожен запитуючи за допомогою DuckDB MCP і Kafka MCP Будь-яка агентична рамка, як LangGraph або AWS Strands, може викликати інструменти на цих серверах MCP і отримати необхідну інформацію.На додаток до агентичної рамки, агент-оркестратор може об'єднати відповіді з цих серверів MCP і представити унікальні подробиці про поведінку покупки магазину та клієнтів в реальному часі. Для розробника Python AI, перший крок для розробки цього рішення вимагатиме визначення інструментів FastMCP для Kafka і DuckDB MCP. Потім необхідно побудувати агентичні запрошення, а потім кінцеві точки API, які дозволять запровадникам взаємодіяти з цими агентами. Останній крок буде додати функції спостереження та оцінити відповіді AI для поліпшення агентичного потоку і зробити його надійним. Оцінка кінцевих відповідей від агентів проти стандартів, відповідності та бенчмарків залишається важливим кроком для забезпечення прийняття користувача. Оскільки більшість збагачення, очищення та агрегації даних в реальному часі відбуватиметься на шарі FlinkSQL, розробка інструментів MCP і шарів запрошення буде включати тільки чистий пітонічний розвиток Розробники Python, знайомі з Kafka і Flink, можуть створювати такі агентичні робочі потоки, як вищезазначені, працюючи на знайомій території FastAPI, FastMCP і відкритих агентських рамках, таких як LangGraph і AWS Strands. Для сучасних розробників Python шлях до створення витончених агентів AI не вимагає повного архітектурного перегляду. Об'єднуючи FastMCP для відкриття інструментів MCP, а також Apache Kafka і Apache Flink SQL для цілісності даних в реальному часі, ви можете забезпечити, щоб ваші агенти працювали на чистих, надійних даних. Незалежно від того, використовуєте ви LangGraph або AWS Strands, перехід до агентичних робочих потоків є по суті еволюцією шаблонів мікросервісів, які ви вже знаєте. Чат з Кафкою і Флінком - агенти AI і конфлюнтовані MCP для розробників додатків Python Кафка і Флінк з точки зору розробника додатків (150 слів) 
 
 
 
 
 Розробники програм створюють мікросервіси для бізнес-додатків, Кафка як де-факто стандарт для поточного зберігання Простий у використанні як об'єкт обміну повідомленнями для мікросервісів, що розмовляють один з одним - кошик API <-> замовлення створення API <-> лояльність API <-> замовлення виконання API і т.д.. Flink створює збагачені, трансформовані та високоякісні агреговані дані на теми Кафки Що робити, якщо агент AI може бути вбудований в мікросервіси? (150 слів) 
 
 
 
 Мікропослуги завжди матимуть кінцеві пункти REST Введіть «/chat» як чат з агентами Інші кінцеві точки будували б ділову логіку, яка була б передана `/chat/ як контекст. MCP (Model Context Protocol) - мова, якою розмовляють агенти AI (200 слів) 
 
 
 Викрийте інструменти Kafka і Flink за допомогою режиму транспортування MCP-HTTP Агенти будуть оглядати і відкривати інструменти і використовувати допомогу LLM, щоб відповідати запиту користувача з конкретним інструментом Роздрібний магазин поведінки агента - приклад(400 слів) 
 
 
 
 
 
 Поясніть налаштування - роздрібний продавець, який приймає швидкі замовлення через магазини Run Confluent MCP - описуйте github repo mcp-confluent і Kafka, Flink специфічні інструменти Список агентів інструментів Kafka і FLink та інтроспекції за допомогою LLM. Агент відповідає на питання «який магазин прийняв найбільше замовлень за останні 5 хвилин». Агент закликає інструменти MCP споживати повідомлення Кафки і відповідає.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Це аудіо створено мовою оригіналу історії!

Як розробники Python можуть створювати агентів AI, використовуючи MCP, Kafka і Flink

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps