Практичні нотатки: 21 шаблон агентного проектування пояснено просто

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

Агентські шаблони проектування — діаграми архітектури + практичний посібник (21 шаблон)

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

Зміст

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

1) Ланцюг запитів (Pipeline)

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

flowchart TD
A[Input] --> B[Step 1 Prompt e.g. summarize ]
B --> C[Step 2 Prompt e.g. extract structured data ]
C --> D[Step 3 Prompt e.g. format output ]
D --> E[Final Output]

2) Маршрутизація

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

flowchart TD
I[User Request Input] --> R{Router intent and confidence }
R --> A[Workflow A e.g. Q&A ]
R --> B[Workflow B e.g. coding ]
R --> C[Workflow C e.g. retrieval ]
R --> Q[Ask Clarifying Question]
A --> O[Output]
B --> O
C --> O
Q --> I

3) Паралелізація

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

flowchart TD
I[Input] --> F[Fork]
F --> A[Task A e.g. retrieve source 1 ]
F --> B[Task B e.g. retrieve source 2 ]
F --> C[Task C e.g. retrieve source 3 ]
A --> J[Join Merge]
B --> J
C --> J
J --> O[Output]

4) Рефлексія (Створення → Критика → Вдосконалення)

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

flowchart TD
D[Draft Output] --> C[Critique Review check requirements errors ]
C --> R[Revise using critique]
R --> D
C --> O[Final Output]

5) Використання інструментів (виклик функцій)

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

sequenceDiagram
autonumber
participant U as User
participant L as LLM Agent
participant T as Tool API
U->>L: Request
L->>L: Decide tool and arguments
L->>T: Call tool args
T-->>L: Tool result
L-->>U: Answer using result

6) Планування

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

flowchart TD
G[Goal] --> P[Create Plan steps and dependencies and tools ]
P --> S1[Execute Step 1]
S1 --> C1{Step success }
C1 --> S2[Execute Step 2]
C1 --> RP[Revise Plan Recover]
RP --> P
S2 --> C2{Done }
C2 --> S3[Next Steps ]
C2 --> O[Output]
S3 --> C2

7) Співпраця кількох агентів

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

графа.

flowchart LR
G[Goal] --> C[Coordinator]
C --> R[Research Agent]
C --> B[Builder Agent]
C --> V[Verifier Reviewer Agent]
R --> S[Synthesis]
B --> S
V --> S
S --> O[Final Output]

8) Керування пам’яттю

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

flowchart TD
E[Events Conversation] --> STM[Short-term Memory session buffer ]
E --> LTM[Long-term Memory Store vector DB ]
Q[Current Query] --> RET[Retrieve relevant memory]
LTM --> RET
STM --> CTX[Assemble Context]
RET --> CTX
CTX --> L[LLM Agent]
L --> O[Output]

9) Навчання та адаптація

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

flowchart TD
R[Run Agent] --> L[Log outcomes success fail and user edits ]
L --> A[Analyze patterns where it fails ]
A --> U[Update prompts routes retrieval or fine-tune ]
U --> E[Evaluate before rollout]
E --> R
E --> A

10) Протокол контексту моделі (MCP)

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

flowchart LR
A[Agent LLM] --> C[MCP Client]
C <--> S[MCP Server]
S --> T1[Tool: Documents]
S --> T2[Tool: DB]
S --> T3[Tool: Tickets]
T1 --> S
T2 --> S
T3 --> S
S --> C --> A

11) Встановлення та моніторинг цілей

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

flowchart TD
G[Define Goal and Success Criteria] --> X[Execute steps]
X --> M[Monitor state metrics progress budget risk ]
M --> X
M --> A[Adjust plan change route escalate]
A --> X
M --> O[Output]

12) Обробка винятків та відновлення

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

flowchart TD
A[Action Tool Call] --> E{Error }
E --> N[Next Step]
E --> R[Retry with backoff]
R --> S{Recovered }
S --> N
S --> F[Fallback route tool]
F --> T{Still failing }
T --> N
T --> H[Escalate to Human Safe Stop]

13) Участь людини у процесі (HITL)

Модель „13 Human in the stage“ працює найкраще, коли її розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Зберігайте стан графа у випрямленому та типованому форматі. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, що ускладнює продовження роботи після перерв. Модель „13 Human in the stage“ працює найкраще, коли її розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Зберігайте конфігурацію поза кодом програми. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф.

sequenceDiagram
autonumber
participant U as Human
participant A as Agent
participant S as System Tools
A->>U: Proposal and rationale
U-->>A: Approve Edit Reject
A->>S: Execute approved action
S-->>A: Result
A-->>U: Confirmation and summary

14) Отримання знань (RAG)

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

flowchart TD
Q[Question] --> E[Embed Rewrite Query]
E --> R[Retrieve top-k chunks vector keyword hybrid ]
R --> RR[Rerank Filter optional ]
RR --> C[Compose grounded prompt question and context ]
C --> L[LLM]
L --> O[Answer and citations quotes optional ]

15) Міжагентська комунікація (A2A)

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

sequenceDiagram
autonumber
participant A as Agent A
participant B as Agent B
participant C as Agent C
A->>B: Task request schema and constraints
B-->>A: Result or stream updates
A->>C: Verification request
C-->>A: Verified flagged findings
A-->>A: Merge and decide next step

16) Оптимізація з урахуванням ресурсів

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

цілу діаграму.

flowchart TD
I[Request] --> S[Score difficulty and risk and SLA]
S --> D{Choose compute level}
D --> L1[Fast Cheap path small model and minimal tools]
D --> L2[Balanced path hybrid retrieval and standard model]
D --> L3[Strong path best model and RAG and Reflection]
L1 --> O[Output]
L2 --> O
L3 --> O

17) Техніки міркування

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

flowchart TD
P[Problem] --> D[Decompose choose reasoning strategy]
D --> A[Act: tool calls sub-steps optional ]
A --> V[Verify constraints checks tests cross-check]
V --> D
V --> O[Answer]

18) Захисні механізми / шаблони безпеки

Під час роботи над 18 стадіями шаблонів безпеки Guardrails спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну послідовність операцій. Робіть перевірки після дорогих кроків. Система повторного запуску не повинна знову оплачувати один і той самий виклик LLM, коли оператор намагається виконати пізнішу операцію.

flowchart TD
IN[User Input] --> IV[Input Validation policy risk checks ]
IV --> PC[Policy Constraints system rules and boundaries ]
PC --> TR[Tool Restrictions allowlist and sandbox and rate limits]
TR --> L[LLM Agent]
L --> OV[Output Validation PII leak checks and format checks]
OV --> OUT[Safe Output]
OV --> ESC[Escalate Refuse Human review]

19) Оцінка та моніторинг

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

flowchart TD
RUN[Agent Runs] --> LOG[Log traces inputs tools outputs latency cost ]
LOG --> EVAL[Evaluate quality golden set and metrics ]
EVAL --> DRIFT[Drift Anomaly detection]
DRIFT --> IMP[Improve prompts routes retrieval model ]
IMP --> DEP[Deploy and A B test]
DEP --> RUN

20) Пріоритизація

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

flowchart TD
T[Incoming tasks] --> N[Normalize into task objects]
N --> S[Score tasks urgency impact risk deps cost ]
S --> Q[Queue Scheduler]
Q --> X[Execute next task]
X --> U[Update scores new info failures deadlines ]
U --> S
X --> O[Outputs Results]

21) Дослідження та відкриття

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

flowchart TD
S[Start: unknown space] --> H[Generate hypotheses options]
H --> G[Gather evidence search tools experiments ]
G --> E[Evaluate findings rank eliminate]
E --> R[Refine hypotheses]
R --> G
E --> O[Best answer strategy]

Поширені шаблони та практики (те, що насправді використовують команди)

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

Чек-лист для експлуатації

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

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

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

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

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

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

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

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