За останні два роки компанія купила чимало інструментів штучного інтелекту: чат-помічників, плагіни для письма, ботів обслуговування клієнтів та внутрішні системи запитів і відповідей. Однак справжніх, стійких здібностей залишилося небагато. Підказки досі лежать на персональному комп’ютері, бізнес‑процеси розкидані по кутках документів, після запуску інтелектуальних агентів не вистачає зворотнього зв’язку та коригувань, а ключові фахівці й далі зайняті однотипними запитами, які забирають усі їхні робочі години. Проблема часто полягає не в тому, що моделі недостатньо розумні, а в тому, щоСистема не передбачила «виконання роботи» як управлінську компетенцію посади.。
Спочатку роз’яснімо: чому вікно чату не може бути призначено для посади?
Чат-бот відповідає на запитання і одразу завершується. Позиція має постійно приймати роботу: збирати інформацію, перевіряти правила, викликати систему, записувати стан, а у разі виникнення винятків — підвищувати до вищого рівня. Типовим прикладом є відрядження та його оплата: користувач спочатку може сказати «Допоможіть оформити відрядження», потім середньою частиною запитати «Скільки залишилося ліміту цього місяця», а згодом додати ще один чек. Якщо система буде розглядати кожну розмову як новий сеанс, процес буде перериватися, контекст загубиться, і після цього неможливо буде проаналізувати, чи була помилка у правилах, чи у інтерфейсі.
У галузі вже існує практика створення інтелектуальних агентів у форматі «цифрових співробітників»: їм надають посаду, робочий номер, межі компетенції та записи про роботу, а також доповнюють змінюваними SOP‑ами, базою знань, інструментами й історією виконання. У напрямку відкритого коду проект StaffDeck, опублікований такими організаціями, як OpenBMB, представляє агента як операційно керований набір ресурсів, а не просто фрагмент підказки. Для внутрішнього розроблення чи адаптації підприємствами важливіше запозичувати не назву продукту, а саме цю об’єктну модель.
Бізнес-логіка: у системі має бути принаймні сім типів об’єктів
Створюючи систему цифрових співробітників, спочатку вписуйте бізнес-об’єкти у специфікацію, а потім обговорюйте вибір моделі.
- Архів посади: ім’я або ім’я персонажа, робочий номер, обов’язки, стан онлайн, об’єкт обслуговування. Без файлів немає де прив’язати права та оцінку.
- Межа можливостей: Які документи можна читати, які поля можна заповнювати, і чого не можна обіцяти. Межі мають бути змінними адміністратором, а не закріпленими в попередньому тексті.
- SOP / Процесно-орієнтовані навички: Розбиваємо складні процеси на вузли, підтримуємо умовні розгалуження, виклик інструментів, пошук знань та переключення на людину.
- Онтологія знань: Теми, правила, джерела та інструкції зберігаються окремо; відповіді повинні мати чітке посилання на джерело, а пошук має бути налаштованим.
- Інтеграція інструментів: HTTP-інтерфейс або MCP, які використовуються для перевірки лімітів, створення документів та зміни статусу, а не лише для генерації текстового повідомлення.
- Часові завдання: Такі періодичні завдання, як зведення щоденних звітів, нагадування про завершення випереджених термінів та інспекція запасів, не можна чекати, поки користувач спочатку звернеться.
- Відстеження та зворотній зв'язок: Записувати маршрути, кроки, інструменти, знання та відповіді; ставити лайки, негативні відгуки та передавати роботу людям для наступного раунду переробки.
Одне справжнє запитання часто містить кілька завдань. Цифровий співробітник має вміти спочатку перейти до SOP зі звітності про витрати, зібрати всі поля та провести перевірку за правилами, а потім переключитися на SOP для перевірки ліміту й викликати інтерфейс. Якщо користувач у середині процесу запитує про політику, слід зберегти поточний вузол і після відповіді повернутися до первинного процесу. У разі питань, що виходять за рамки правил, необхідно передати контекст створювачеві або черговому працівнику; заборонено давати відповіді без обґрунтування.
Логіка проектування: ролі, діяльнісний автомат, ієрархія знань
Як змінити роль?
Принаймні виділяють чотири категорії людей:Створювач(закріплення досвіду серед співробітників),Адміністратор(управління правами доступу, публікація, квоти),Користувач(надавати завдання цифровим співробітникам),Дільничний(Далі — винятки). Створювач не повинен за замовчуванням мати права на зміну запасів та цін; користувач не повинен бачити повний текст підказки та ключ. Відкриті інтерфейси також мають бути розподілені за рівнями: ключ рівня облікового запису може керувати ресурсними налаштуваннями, а ключ рівня співробітника може лише створювати сесії та читати власні дії.
SOP використовується за допомогою автоматів станів, не обмежуйтеся лише пам’яттю про розмови
Природна мова може генерувати черговий проєкт, а виконання обов’язково має відбуватися за допомогою станового автомату: поточний вузол, зібрані слоти, доступні для виклику інструменти, спроба повторного виконання у разі помилки, ручний вузол. Після перерви завдання повинно бути здатне серіалізувати контекст і продовжити вихід з того ж вузла. Багато SOP-ів дозволяють реальний час переключатися, однак при переключенні необхідно зберігати інформацію про те, звідки прийшло завдання та які дані вже підтверджено, щоб уникнути повторного заповнення форм користувачами. Версії та гілки повинні мати функцію відкоту; навіть якщо на місці зміниться лише один попередній текст, система одразу ж буде готова до запуску, а подальші зміни вже не дадуть можливості притягнути до відповідальності.
Не перетворюйте знання на змішаний пошук.
Створюйте навігаційний індекс за документами, розділами, сторінками та анотаціями: спочатку визначте, до якої категорії може належати інформація, а потім знаходьте вихідний текст. Розподіл знань за «баками»: окремо зберігайте нормативні положення, описи продуктів, післяпродажні формулювання та приклади винятків; це забезпечує більш стабільне результативне пошукове запитування, ніж загальний пошук за ключовими словами. Кожна відповідь повинна мати прив’язку до джерела, правил та бізнес-теми; у тестовому середовищі має бути видно, чому саме відповідає цей фрагмент. Налаштування пошуку часто допомагає вирішити проблему краще, ніж заміна моделі на більш потужну.
Розробка та впровадження: інтерфейси, ізоляція, моніторинг, приймання та перевірка
Під час виконання рекомендується використовувати єдиний вход, щоб уникнути розходження стану через те, що кожна функція працює за своїм окремим маршрутом. Виявлення можливостей, ізольоване виконання, цілісність продуктів та обчислення квот повинні здійснюватися під час виконання, а не за допомогою умов. Перед публікацією функцій на внутрішньому ринку слід проводити сканування прав доступу: заголовки аутентифікації, змінні середовища та облікові дані підключення не мають з’являтися у звичайних інтерфейсах читання.
- Канал виконання: Синхронний поток підходить для розмов; асинхронний Run + потік подій підходить для продовження передачі після перерви та для черги завдань; обидва використовують один і той же ядро.
- Статус каналу: WeChat, Enterprise WeChat, Feishu та DingTalk можуть використовуватися як входи, але дані про співробітників, розмови та Trace мають бути уніфікованими; заборонено створювати окремі системи пам’яті для кожного каналу.
- Безпека: Конфігурація моделі посилається лише на існуючий номер конфігурації та не передає назад ключ постачальника; при внесення результатів інструменту до Trace здійснюється дезінформація.
- Штучне забезпечення: перевищення часу, низька довіра, несанкціонований доступ, активне переключення користувача на співробітника — усі чотири вимоги мають забезпечувати повну передачу контексту.
Під час приймання не обмежуйтеся перевіркою лише функції «можливості спілкування». Підготуйте набір повторюваних сценаріїв: нормальне закриття ланцюжка, втручання під час роботи, недостатній ліміт, тайм-аут інтерфейсу, запис за надмірними правами, відповідь з відмовою без джерела. Для кожного сценарію перевіряйте: чи відновлено відповідний вузол, чи правильно записано документ, чи повна інформація у трасі, чи передано виняток відповідному спеціалісту. Рівень успішності вибіркових перевірок, показник обробки тайм-аутів та кількість відповідей без належних підстав — це більш адекватні критерії для контролю введення системи в експлуатацію, ніж зірковий рейтинг задоволеності.
Послідовність запуску: спочатку один етап повторюваних робіт
Не починайте одразу зі створення універсального помічника. Виберіть фрагмент, який щоденно повторюється понад півгодини — наприклад, зведення про перегляд продажів, нагадування про затвердження, відповіді на запитання щодо процедур або попереднє перевірочне розгляд витрат — і оформіть ввод, вивід, права доступу та винятки у вигляді чотирьох речень, додавши до цього SOP та два–три інтерфейси лише для читання або обмеженого запису. Якщо основні дані нечисті, а вузли затвердження недостатньо чітко визначені, спочатку доповніть об’єкти й стани, а потім додайте інтелектуальні функції виконання — після автоматизації брудних даних вони будуть поширюватися по всій компанії ще швидше.
Як визначити, що проект розробки виконано правильно: той етап, де раніше залежно від підштовхувань у групах та заповнення таблиць, більше не є основним шляхом; протоколи, нагадування та зведення можна перевіряти на вибірковій основі за документами; у незрозумілих випадках передбачено механізм подальшого розгляду; сенситивні операції проходять перевірку, а журнал можна переглядати. Щоб оцінити, чи відповідає розробка встановленим вимогам, слід дивитися…Чи можна відновити ту ж саму SOP після її перерви?、Чи можна посилатися на джерело у відповіді?、Чи може прикордонний випадок перейти до наступного раунду редагування?. Після того як ці три напрямки будуть виконані, можна розширювати штат; це надійніше, ніж спочатку створювати безліч точок зв’язку у чатах.
Технічна складність системи цифрових співробітників полягає не у генерації діалогів, а у перетворенні посад, процесів, знань, інструментів та треків у версійні програмні об’єкти. Підказки можна змінювати десять разів на тиждень, але якщо модель об’єкта розпадеться, кожна наступна навичка потребуватиме власного набору коду. Спочатку потрібно успішно запустити ці сім категорій об’єктів та машину станів; лише після цього можна буде ефективно оновлювати модель. В іншому випадку кожне оновлення моделі перетворюватиметься на новий проект, а не на зміну конфігурації.