Практичні зауваження: відсутні витрати на API: створення локальної багатоагентної системи ШІ з

Використовуйте цей документ як оновлену версію ідей з книги „Без витрат на API: створення локальної багатоагентної системи ШІ за допомогою Gemma 4, Ollama та Google ADK“ для співробітників-операторів: чіткі етапи, впорядковані блоки коду та примітки щодо відновлення, які залишаються при передачі обов’язків. Етап Огляду найкраще функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний запис, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.

Що ми створюємо

На етапі «Що ми створюємо» необхідно визначити вхідні дані, відповідального за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь граф. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.

Чому Gemma 4 E4B?

Для етапу Why Gemma 4 E4B необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови.

gemma4:e4b

gemma4:e2b

Використовуване обладнання

На етапі використання обладнання необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну структуру процесу. Розділіть процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови. На етапі використання обладнання необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.

Крок 1: Встановіть Ollama

Під час виконання кроку 1 «Встановити Ollama» спочатку складіть перелік вимог: необхідні параметри входу, сигнал про успішне виконання та наслідки часткової невдачі. Такий перелік допоможе зберегти чесність подальших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, щоб оператори могли їх перевіряти, не читаючи весь код. Записуйте ідентифікатор запиту, ідентифікатор моделі та час відгуку після кожного виклику. Без цих записів періодичні помилки постачальника можуть здаватися багами додатку.

brew install ollama

brew update
brew upgrade ollama

ollama --version

Крок 2: Завантажте Gemma 4

Під час виконання етапу «Крок 2: Завантаження Gemma», спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допоможе зберегти чесність подальших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Записуйте ідентифікатор запиту, ідентифікатор моделі та час затримки після кожного виклику. Без цих записів періодичні помилки постачальника виглядають як баги програмного забезпечення.

ollama pull gemma4:e4b

ollama list

NAME            ID              SIZE
gemma4:e4b      ...             9.6 GB

Крок 3: Пряме тестування Gemma

Під час роботи над етапом Step 3 Test Gemma спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Записуйте ідентифікатор запиту, ідентифікатор моделі та час виконання при кожному виклику. Без цих даних періодичні помилки постачальника виглядають як баги програми. Під час роботи над етапом Step 3 Test Gemma спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних середовищ.

ollama run gemma4:e4b

Create an outline for an article explaining AI agents to beginners.

/bye

Крок 4: Перевірка того, чи вже працює Ollama

Найкраще перевіряти ефективність кроку 4, розглядаючи його як вимірювану характеристику. Збережіть один ідеальний запис виконання, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Забезпечте фіксацію версії інтерпретатора та файлу блокування залежностей перед запуском циклу. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.

http://127.0.0.1:11434

ollama serve

Error: listen tcp 127.0.0.1:11434: bind: address already in use

curl http://127.0.0.1:11434/api/tags

ollama ps

Крок 5: Створення проекту ADK

Крок 5 «Створення сцени» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний варіант виконання, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Забезпечте фіксацію версії інтерпретатора та файлу блокування залежностей перед початком використання циклів. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв під час демонстрацій API.

cd /Users/yourusername
mkdir bloggeragent
cd bloggeragent

touch requirements.txt .env .gitignore __init__.py agent.py

bloggeragent/
├── .env
├── .gitignore
├── __init__.py
├── agent.py
└── requirements.txt

Крок 6: Створення віртуального середовища

Крок 6 «Створити етап» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис виконання, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну ієрархію процесів. Закріпіть інтерпретатор та файл з параметрами залежностей перед тим, як пояснювати принцип роботи циклу. Різниця у налаштуваннях між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API. Крок 6 «Створити етап» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис виконання, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити разом із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демонстрації до спільних середовищ.

python3 -m venv .venv

source .venv/bin/activate

(.venv)

which python

/Users/philipobiorah/bloggeragent/.venv/bin/python

Крок 7: Встановіть Google ADK із підтримкою локальних моделей

На етапі встановлення Google у рамках кроку 7 необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови.

google-adk[extensions]==2.2.0
python-dotenv
litellm>=1.84

python -m pip install --upgrade pip
python -m pip install -r requirements.txt

ImportError: LiteLLM support requires:
pip install google-adk[extensions]

python -m pip install --upgrade "google-adk[extensions]==2.2.0"
python -m pip install --upgrade "litellm>=1.84"

python -c "from google.adk.models.lite_llm import LiteLlm; print('LiteLLM connection ready')"

LiteLLM connection ready

Крок 8: Налаштуйте підключення до локального Ollama

На етапі 8 «Налаштування етапу» необхідно визначити вхідні дані, власника етапу та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити етап з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без необхідності переписування машини станів розмови.

OLLAMA_API_BASE=http://127.0.0.1:11434

GOOGLE_API_KEY

.env
.venv/
__pycache__/
*.pyc

Етап 9: Налаштування пакету Python

Для кроку 9 «Налаштувати етап» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, тестовані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних. Розділіть процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови. Для кроку 9 «Налаштувати етап» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу з демо-середовища у спільні середовища.

from . import agent

Крок 10: Визначення локальної моделі Gemma

Під час виконання кроку 10 «Визначення стадії» спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретів та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Фіксуйте ідентифікатор запиту, ідентифікатор моделі та час виконання при кожному виклику. Без цих записів періодичні помилки постачальника виглядають як баги додатку.

import datetime

from dotenv import load_dotenv
from google.adk.agents import Agent, LoopAgent
from google.adk.models.lite_llm import LiteLlm
from google.adk.tools import agent_tool

load_dotenv()

MODEL = LiteLlm(
    model="ollama_chat/gemma4:e4b"
)

MODEL = LiteLlm(
    model="ollama_chat/gemma4:e2b"
)

Крок 11: Створення робочого процесу з кількома агентами

Під час виконання кроку 11 «Створення сцени» спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Записуйте ідентифікатор запиту, ідентифікатор моделі та час затримки при кожному виклику. Без цих записів періодичні помилки постачальника виглядають як баги програми.

Налаштування __init__.py

Під час роботи над етапом Configure init py спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну функцію, а не на складну послідовність операцій. У кожному виклику фіксуйте ідентифікатор запиту, ідентифікатор моделі та час виконання. Без цих даних періодичні помилки постачальника виглядають як баги програмного забезпечення. Під час роботи над етапом Configure init py спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Реєструйте час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовищ до спільних.

from . import agent

Змініть імпорти для локальної Gemma

Метод «Змініть імпорти для стадії» найкраще працює, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію поза кодом додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Фіксуйте версію інтерпретатора та файл з блокуванням залежностей перед початком використання циклів. Розбіжності між ноутбуком та системою CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.

from google.adk.models.lite_llm import LiteLlm

import sys
from pathlib import Path

import datetime
from dotenv import load_dotenv
from google.adk.agents import Agent, LoopAgent
from google.adk.tools import agent_tool

Замініть хостовану модель Gemini

Процес заміни хостованої версії Gemini працює найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи разом. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Заблокуйте інтерпретатор та файли з інформацією про залежності перед тим, як почнете використовувати цикли. Розбіжності між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API.

MODEL = os.getenv("MODEL", "gemini-flash-latest")

MODEL = LiteLlm(
    model="ollama_chat/gemma4:e4b"
)

import datetime

from dotenv import load_dotenv
from google.adk.agents import Agent, LoopAgent
from google.adk.models.lite_llm import LiteLlm
from google.adk.tools import agent_toolload_dotenv()MODEL = LiteLlm(
    model="ollama_chat/gemma4:e4b"
)

model=MODEL

Що демонструє цей проект

Етап «Що демонструє цей проект» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Закріпіть інтерпретатор та файл з параметрами залежностей перед тим, як пояснювати принцип циклів. Розбіжності між ноутбуком та середовищем CI є найпоширенішою причиною прихованих збоїв у демонстраціях API. Етап «Що демонструє цей проект» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демонстрації до спільних середовищ.

Повна реалізація проекту

На етапі повної реалізації проекту необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення перед зміною коду. Оператори мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функціоналу мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови.

git clone https://github.com/philipobiorah/bloggeragent.git
cd bloggeragent

python3 -m venv .venv
source .venv/bin/activate

python -m pip install -r requirements.txt

Висновок

На етапі завершення необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно розділити процес створення клієнта від циклу обробки повідомлень, щоб можна було замінити постачальників без переписування машини станів розмови.

Посилання

На етапі „Джерела“ необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних. Розділіть процес створення клієнта від циклу обробки повідомлень, щоб можна було замінювати постачальників без переписування машини станів розмови. На етапі „Джерела“ необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-середовищ до спільних середовищ.

Чек-лист операцій

Під час виконання етапу чек-листу операцій спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та наслідки часткової несправності. Цей чек-лист допомагає зберігати прозорість подальших змін у коді.

Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань.

У кожному запиті фіксуйте ідентифікатор запиту, ідентифікатор моделі та час виконання. Без цих записів періодичні помилки постачальника можуть здаватися багами програми.

Зберігайте стан графа у простій та типованій формі. Вкладені структури даних приховують інформацію про те, який вузол заповнив певне поле, що ускладнює продовження роботи після перерв.

Коли дозволяє бюджет, додавайте тест на базову функціональність, який перевіряє критичний шлях у процесі інтеграційного тестування за допомогою фікстур, а не реальних платних API.

Документуйте одночасно шлях успішної роботи та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

Перш ніж піднімати стек на новий рівень, заморозьте версії, зафіксуйте ідеальний запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження швидкості, перевірки прав доступу та чіткий власник для зміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.

Примітка до пакету 4ecfd0db9610: не включайте ключі постачальника до репозиторію, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.