Англійська мова для агентів штучного інтелекту: словник, який вам потрібен

Якщо ви створюєте LLM-заснованих агентів — або проводите інтерв’ю в компаніях, які це роблять — вам потрібно більше, ніж навички Python. Вам потрібно мати змогу * говорити * про агентів точно англійською: під час перегляду дизайну, обговорення запитів на витягування, після смерті жертв і під час співбесід на роботу.

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

---

Агент Луп

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

У дискусіях щодо дизайну ви почуєте:

“Агент запускає цикл доти, поки не буде виконано умову зупинки — у цьому випадку, max_steps або виклик інструменту, що повертає « task complete ». ”

“Ми бачили, як агент застряг у тісному петлі — він продовжував викликати той самий інструмент з тими ж аргументами. Нам потрібен детектор застряглого циклу, який підраховує повторювані ідентичні виклики інструментів. ”

Найбільш поширеною архітектурою петлі сьогодні є ReAct (Reasoning + Acting). Агент, що використовує шаблон ReAct:

1. ** Причини ** щодо того, що робити далі (виробляє « думку » у своєму блокноті)
2. ** Дія ** за допомогою виклику інструменту
3. ** Спостерігає ** за результатом інструменту
4. Повторюється до завершення

Повний запис думок, дій і спостережень за один запуск називається ** траєкторією **.

---

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

Більшість сучасних агентів взаємодіють зі світом через ** tool call ** (також називається ** function call **). Агент не виконує код безпосередньо — він виробляє структурований вивід, який фреймворк інтерпретує як виклик інструменту.

Ключовий словник:

• ** Схема інструменту ** — визначення JSON інструменту: його назва, опис і параметри. Агент бачить схему у її контексті і використовує її, щоб знати, які інструменти існують і як їх викликати.

• ** Tool call ** — запит агента на виклик інструменту: {"tool": "search_web", "args": {"query": "current weather London"}}

• ** Результат інструменту ** — відповідь, яку буде повернено агенту після виконання інструменту.

• ** Реєстр інструментів ** — збірник всіх інструментів, доступних для агента або системи агентів.

У переглядах коду ви зустрінете такі обговорення:

“Опис інструменту неоднозначний — send_email і draft_email з’ являються в реєстрі, але агент продовжує вибирати неправильний. Нам потрібно загострити описи, щоб агент міг розрізнити, коли кожен з них повинен бути використаний. ”

Це називається ** інженерія опису інструментів ** — і це справжнє, важливе мистецтво.

---

Оркестрова композиція

Складні завдання все частіше обробляються не одним агентом, а ** багатоагентною системою **. В оглядах архітектури:

• ** Оркестратор- агент ** — агент верхнього рівня, який розкладає завдання, делегує підзавдання підагентам і агрегує результати.

• ** Суб-агент / робочий агент ** — спеціалізований агент, відповідальний за одну частину проблеми. Агент кодування може делегувати «написати тест» до під-агента, який пише тест.

• Crew — команда агентів, що працюють разом (цей термін популяризують такі платформи, як CrewAI).

• ** Передача/ делегування агента ** — передавання керування і контексту від одного агента до іншого.

Обережно щодо втрати контексту під час передачі:

• “Після передачі, агент- одержувач, здається, не знає, що було вирішено на перших трьох кроках. Нам потрібно визначити, який контекст буде серіалізований і переданий.»*

---

Органічні сполуки

У дискусіях щодо архітектури агентів постійно з’ являються чотири шаблони:

** Планувальник- виконавець **: агент планувальника створює план високого рівня; агент виконавця виконує його крок за кроком. Ці дві ролі можуть бути однією і тією ж моделлю або різними моделями, оптимізованими для кожного завдання.

** Цикл відображення ** (також відомий як ** самовдосконалення **): агент переглядає свій власний вивід і покращує його перед поверненням кінцевого результату. У перегляді коду: “Агент тепер виконує крок відображення перед затвердженням своїх змін — якщо лінтер не вдається, він переглядає.”

** Архітектура пам’ яті **: Три типи пам’ яті, які виникають під час обговорення проектування:

• • Пам’ ять у контексті * — текст, який зараз знаходиться у контекстному вікні агента
• • Епізодична пам’ ять * — доступні записи минулих запусків агента (зазвичай зберігаються за допомогою векторного пошуку)
• • Семантична пам’ ять * — загальні факти і знання, збережені у базі знань або сховищі даних

** RAG у циклі агента ** (Retrieval- Augmented Generation): агент запитує векторний склад на кожному кроці обґрунтування, щоб отримати відповіді у отриманих документах. Ви почуєте: * « Агент використовує RAG для отримання відповідної документації перед написанням коду. » *

---

Observability

Коли агенти працюють, спостережність не підлягає обговоренню. Словник:

• ** Trace ** — повний запис виконання агента від початку до кінця: кожен крок, виклик інструменту і крок обґрунтування.
• ** Обсяг ** — одинична одиниця роботи у межах трасування (один виклик інструменту, один виклик LLM, один крок обґрунтування).
• ** Бюджет токенів ** — максимальна кількість токенів, яку агент може використовувати за один запуск (жорстке або м’ яке обмеження).

Такі інструменти, як LangSmith і LangFuse, призначені для спостереження за агентами — вони надають вам змогу перевіряти окремі діапазони, бачити, які інструменти було викликано, і вимірювати споживання токена на кожному кроці.

В оглядах інцидентів: * “Агент, що втік, спожив 2 мільйони жетонів за 4 години. Нам потрібен аналіз токенів на рівні спектру в LangSmith, щоб побачити, який крок обґрунтування був петлею. “*

---

Guardrails

Захисні огорожі — це рівень безпеки навколо системи агентів:

• ** Захисні лінії вводу ** — перевірки, які виконуються на введенні користувача перед тим, як воно досягне агента (визначення введення запитів, PII, запитів, що не належать до теми).
• ** Захисні огорожі виводу ** — перевірки, які виконуються на відповіді агента перед тим, як вона повертається або виконується відповідна дія (визначення шкідливого вмісту, галюцинаційних заяв, конфіденційних даних у виводі).
• ** Людина- у- петлі (HITL) ** — шаблон, за якого агент зупиняє роботу і вимагає схвалення людини перед виконанням високоризикованої дії (неповоротне виклик API, надсилання електронної пошти, розгортання коду).

У розробці переглядів: * “Стек охоронних рейок повинен запускати перевірки вводу спочатку, потім агент, а потім перевірки виводу. Крок HITL запускається тільки якщо запланована дія включає зовнішній запис.”*

---

Корисні фрази для обговорень

У перегляді архітектури і обговоренні коду вам допоможуть такі фрази:

Situation	Useful phrase
Explaining stopping conditions	”The agent terminates when either max_steps is reached or a tool call returns the sentinel value.”
Describing a bug	”The agent is stuck in a tight loop — calling the same tool with identical arguments on every iteration.”
Proposing a guardrail	”We should add an output guardrail to redact PII before the response is written to the audit log.”
Discussing observability	”I’ve added span-level instrumentation — we can now see exactly how many tokens each reasoning step consumes.”
Recommending HITL	”For the email-sending tool, I recommend we require human approval — this action is not reversible.”

---

Практикуйте ці поняття

Якщо ви бажаєте перевірити свої знання цих термінів у контексті, Вправи з мови на CoderLingo містить:

• Агентська петля і шаблон реакції
• Словник викликів інструментів і функцій
• Мульти-агент оркестрація
• Спостережливість агента (сліди, проміжки, бюджети токенів)
• Агентские перила
• Агентні шаблони (планувальник-виконавець, відображення, пам’ять, RAG)

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