Практичні поради: Створення ефективних AI-агентів: архітектурні шаблони

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

1. Що таке AI-агент?

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

2. Основна архітектура агента

Під час роботи над етапом 2 «The Core Agent» спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.

Інтерфейс користувача або системи

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

Час виконання агента

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

3. Шар моделі

Етап 3 «Рівень моделі» працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу завдань. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Визначте бюджет на токени за кожен раунд та сесію. Інструменти типу агентів активно розширюють контекст; жорсткі ліміти запобігають тому, щоб демонстрації перетворювалися на несподівані рахунки.

4. Інструменти, які перетворюють моделі на агентів

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

search_leads()
get_account()
get_customer_history()
get_recent_emails()
create_opportunity()
schedule_meeting()
generate_proposal()

5. Шаблон 1: Агент, який використовує інструменти

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

User
  ↓
Agent
  ↓
LLM
  ↓
Choose Tool
  ↓
Execute Tool
  ↓
Tool Result
  ↓
LLM
  ↓
Final Response

get_weather("Chicago", "tomorrow")

6. Паттерн 2: ReAct

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

Goal
 ↓
Reason
 ↓
Action
 ↓
Observation
 ↓
Reason
 ↓
Action
 ↓
Observation
 ↓
Final Answer

User Goal:
Find our highest-value customer with an unresolved support case.

Reason:
I need customer revenue data.Action:
query_customer_database()Observation:
Customer A has the highest revenue.Reason:
Now I need unresolved support cases.Action:
search_support_cases(customer_a)Observation:
Two unresolved cases found.Final Answer:
Customer A is the highest-value customer currently
associated with unresolved support cases.

7. Pattern 3: Plan-and-Execute

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

середовищ.

Goal:
Prepare me for tomorrow's meeting with Acme Corp.

1. Retrieve account information
2. Review recent opportunities
3. Retrieve previous meeting notes
4. Review recent emails
5. Identify unresolved issues
6. Find relevant company news
7. Generate meeting briefing

User Goal
   ↓
Planner
   ↓
Task Plan
   ↓
Executor
   ↓
Tools
   ↓
Results
   ↓
Evaluator
   ↓
Final Output

8. Шаблон 4: Архітектура маршрутизатора

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

┌── HR Agent
                  │
User → Router ────┼── Finance Agent
                  │
                  ├── IT Support Agent
                  │
                  └── Sales Agent

9. Шаблон 5: Агенти-керувальники та працівники

Під час праці над 9-м етапом Pattern 5 Supervisor спочатку запишіть угоду: необхідні вхідні дані, сигнал успіху та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Документуйте одночасно шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.

Research Agent
                     ↑
                     │
User → Supervisor → Data Agent
                     │
                     ↓
                 Report Agent

10. Pattern 6: Agentic RAG

Під час роботи над 10-м етапом Pattern 6 Agentic спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій. Перед налаштуванням запитів вимірюйте рівень відтворення інформації за фіксованим набором запитань. Часта зміна формулювань запитів рідко допомагає покращити якість пошуку. Під час роботи над 10-м етапом Pattern 6 Agentic спочатку запишіть угоду: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.

Question
 ↓
Vector Search
 ↓
Relevant Documents
 ↓
LLM
 ↓
Answer

Question
 ↓
Agent
 ↓
Do I need retrieval?
 ↓
Which source?
 ↓
Search
 ↓
Evaluate results
 ↓
Enough information?
   ↓        ↓
  Yes       No
   ↓         ↓
Answer    Search Again

11. Шаблон 7: Рефлексія та самооцінка

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

Generate Answer
     ↓
Evaluate Answer
     ↓
Is it sufficient?
  ↓          ↓
 Yes         No
  ↓           ↓
Return       Improve

12. Архітектура пам’яті

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

Робоча пам’ять

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

Пам’ять розмови

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

Довгострокова пам’ять

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

Епізодична пам’ять

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

13. Стан часто є важливішим за пам’ять

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

state = {
    "goal": "",
    "user_id": "",
    "plan": [],
    "completed_tasks": [],
    "tool_results": {},
    "approval_status": None,
    "errors": [],
    "final_answer": None
}

14. Архітектури агентів на основі графа

Під час роботи над 14 етапами архітектури агентів на основі графів спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Документуйте як шлях успішної роботи, так і шлях відновлення одночасно. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Робіть контрольні позначки після дорогих кроків. Функція відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.

Start
  ↓
Classify Request
  ↓
Retrieve Data
  ↓
Analyze
  ↓
Risk Check
  ↓
Need Approval?
 ↓          ↓
Yes         No
 ↓           ↓
Human       Execute
Approval      ↓
 ↓          Finish
Execute
 ↓
Finish

15. Архітектура з участю людини

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

Agent Recommendation
       ↓
Policy Check
       ↓
High-Risk Action?
    ↓        ↓
   Yes       No
    ↓         ↓
Human       Execute
Approval
    ↓
Execute

16. Обмеження для агентів

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

Обмеження для вхідних даних

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

Інструментальні обмеження

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

Обмеження для результатів

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

Механізми контролю виконання

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

17. Фреймворки реалізації

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

середовищ.

Python
+
LLM API or local model
+
Functions
+
FastAPI
+
Database

Фреймворки на основі графів

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

Багатоагентні фреймворки

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

Платформи оркестрації AI для корпорацій

Під час роботи над етапом платформ оркестрації Enterprise AI спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність у подальших змінах коду. Віддавайте перевагу невеликим, тестованим одиницям коду перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Робіть контрольні позначки після дорогих кроків. Система відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається знову виконати пізніший етап. Під час роботи над етапом платформ оркестрації Enterprise AI спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність у подальших змінах коду. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-режиму до спільних середовищ.

18. Фреймворк практичної реалізації

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

Крок 1: Визначте мету

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

Крок 2: Визначення обов’язків агента

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

Retrieve account information
Retrieve opportunities
Analyze customer communication
Retrieve open support issues
Generate meeting briefing
Recommend discussion topics

Cannot modify CRM records
Cannot send email
Cannot change pricing
Cannot create contracts

19. Крок 3: Визначення інструментів

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

get_account(account_id)
get_opportunities(account_id)
get_support_cases(account_id)
get_email_history(account_id)
search_company_news(company_name)

manage_customer()

get_customer_profile()

20. Крок 4: Проектування потоку керування

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

21. Крок 5: Додавання стану та пам’яті

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

Conversation state
Task state
User preferences
Long-term knowledge
Audit history

22. Крок 6: Додавання можливості спостереження

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

Request
Agent decision
Model used
Prompt version
Tool selected
Tool input
Tool output
Execution time
Token usage
Cost
Errors
Retries
Final response
Human overrides

Request ID: 78425

Step 1:
Intent → Customer Meeting PreparationStep 2:
Tool → get_account()Step 3:
Tool → get_opportunities()Step 4:
Tool → search_support_cases()Step 5:
LLM → Generate briefingTotal execution: 4.8 seconds
Tool calls: 3
Model calls: 2

23. Крок 7: Оцінка агента

Під час виконання етапу 7 «Оцінка» з 23 кроків спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.

Завершення завдання

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

Вибір інструментів

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

Точність інструменту

Обґрунтованість

Безпека

Ефективність

Затримка

Витрати

24. Відновлення після збою

Tool Call
   ↓
Success?
 ↓      ↓
Yes     No
 ↓       ↓
Continue Retry
          ↓
       Still Fails?
        ↓       ↓
       Yes      No
        ↓        ↓
     Fallback  Continue
        ↓
     Escalate

25. Багатоагентні системи: використовуйте їх обережно

Supervisor
 ├── Financial Analysis Agent
 ├── Legal Analysis Agent
 ├── Market Research Agent
 └── Report Generation Agent

Search Agent
Thinking Agent
Tool Agent
Summary Agent
Response Agent

26. Архітектура корпоративних агентів

User
                     ↓
               Agent Gateway
                     ↓
             Identity / Access
                     ↓
                  Router
                     ↓
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
   Sales Agent    HR Agent    Finance Agent
       ↓             ↓             ↓
             Agent Runtime
                   ↓
        ┌──────────┼──────────┐
        ↓          ↓          ↓
       RAG       Tools      Memory
        ↓          ↓          ↓
    Knowledge    APIs     Databases
      Base
                   ↓
             Policy Engine
                   ↓
          Human Approval Layer
                   ↓
              Observability
                   ↓
              Evaluation

27. Детерміністичне програмне забезпечення та ймовірнісний ШІ

Probabilistic Intelligence
          +
Deterministic Control
          =
Reliable Agentic System

28. Почніть з робочих процесів, потім додайте автономність

Етап 1 — Асистент

Етап 2 — Асистент, що використовує інструменти

Етап 3 — Керований агент

Етап 4 — Автономний робочий процес

Етап 5 — Багатоагентна система

29. Що робить AI-агента ефективним?

30. Заключні міркування

Короткий огляд архітектури

AI Agent
│
├── Model
├── Instructions
├── Context
├── Tools
├── Retrieval
├── Memory
├── State
├── Planning
├── Orchestration
├── Guardrails
├── Human Oversight
├── Observability
└── Evaluation

Чек-лист для роботи