Дослідницький агент Roman для ZCode: від шуму спільноти до доказів для продукту
Roman, модератор спільноти Z.ai, описує плагін ZCode, який він спланував, спроєктував і розробив: простежувані докази та фінальна відповідь людини.
Редакційний вступ
Ця стаття про Roman, модератора спільноти Z.ai, та його проєкт ZCode Discord Research Agent. Далі він від першої особи розповідає про планування, інженерні рішення та розробку. Це особиста розповідь про проєкт, а не офіційне оголошення Z.ai чи твердження про замовлення, впровадження або схвалення компанією.
Розповідь Roman від першої особи
Проблема, яку я вирішив дослідити
У спільнотах на кшталт Discord Z.ai користувачі говорять про нагальні потреби задовго до того, як інші помічають тенденцію. Побачити її формування в такому потоці складно. Я вирішив побудувати технологічне рішення цієї проблеми.
Матеріалу вже було багато, і саме це ускладнювало роботу. Спільнота підтримки може бути повною інформації, з якої важко робити висновки. Одна людина описує зламаний процес у темі про помилку. Інша повідомляє про той самий збій під іншою назвою. Єдина корисна діагностична деталь міститься на скриншоті. Довга розмова змішує прямі скарги, короткі згоди й запитання про виправлення. Більше прочитаних повідомлень не гарантує обґрунтованішого продуктового рішення.
Я спланував, спроєктував і розробив ZCode Discord Research Agent, щоб скоротити відстань між словами спільноти й діями, які продуктова команда може відповідально вжити. Мені потрібен був повторюваний спосіб досліджувати відгуки, зберігати підстави висновків і створювати звіт, який керівник підтримки зможе перевірити. Мета продукту в тому, щоб дослідження можна було обґрунтувати, а не лише прискорити.
Дослідницький процес
Я побудував проєкт як нативний плагін для ZCode з локальним набором інструментів Python. Процес починається з визначення охоплення і збору, переходить до аналізу, звітності та, за потреби, перевіреної відповіді. Збирач отримує повідомлення тем і метадані вкладень; агент застосовує дослідницький метод. Генератор звітів перетворює структурований аналіз на робочі документи.
Збір має зберігати сказане, аналіз пояснювати його значення, а звіт показувати висновок і його межі. Правдоподібний абзац не замінює цього ланцюжка доказів.
Рішення залишаються явними. Семантичне групування, перегляд скриншотів і розрізнення скарги та випадкової репліки належать до процесу під керівництвом агента. Я не стверджую, що невеликий скрипт Python автоматично розуміє кожну розмову.
Інженерія з урахуванням структури Discord
Дослідницький інструмент має враховувати структуру джерела. Форуми Discord містять теми з потрібними розмовами. Проєкт включає пошук категорій і каналів, нових та архівних тем, посторінкове завантаження повідомлень, завантаження вкладень і локальний маніфест збору. API-шар повторює запити за обмеження частоти та мережевих помилок.
Збирач має налаштовані обмеження кількості форумів і тем; обхід повідомлень за замовчуванням обмежений 800 повідомленнями на тему. Наявні кешовані файли тем пропускаються замість постійного оновлення. Це скорочує повторну роботу, але обмежує висновки: вибірка не доводить, що прочитано всі розмови, а кешована тема не обов'язково актуальна.
Інструменти працюють локально, у середовищі оператора, без окремого хостингового сервісу облікових даних. Це архітектурний вибір, а не загальна гарантія приватності, безпеки чи схвалення платформи.
Як бачити тенденції без вигаданої впевненості
Десять повідомлень не обов'язково означають десять постраждалих користувачів. Один автор може дублювати скаргу, кілька відповідей лише питають про новини, а коротке 'так само' містить менше інформації, ніж докладний опис збою.
Тому процес відділяє чіткі скарги від пограничних відповідей, виключає запитання про статус із підрахунку скарг і рахує однаковий текст одного автора лише раз. Пов'язані повідомлення групуються в родини проблем зі збереженням посилань на початкові теми. Якщо в тексті немає корисних діагностичних ідентифікаторів, досліднику пропонується переглянути завантажені скриншоти.
Числа стає легше оскаржити. Керівник має мати змогу запитати, чому автора врахували, яка тема підтверджує висновок і яких доказів бракує. Я хотів, щоб звіт витримував такі запитання.
Звіти, які можна перевіряти
Звітний шар створює книгу Excel з кількома аркушами та HTML для друку; за наявності необов'язкової бібліотеки ReportLab доступний PDF. Книга розділяє підсумок, теми за родинами проблем, детальні докази, аудит відповідей і перевірки вкладень.
Керівник може почати з пріоритетів, а дослідник конкретного збою повернутися до доказів. Якщо висновок оскаржать за місяць, у звіті залишиться шлях до початкових тем.
Допомога підтримці з фінальною відповіддю людини
Особливо цікаво, що той самий дослідницький процес може допомагати самій підтримці.
Отримавши запитання, він може зібрати докази з тем, знайти документацію через локальну базу знань і запропонувати можливі рішення з джерелами. Фахівець із незнайомою помилкою отримує досліджену відправну точку.
Фінальну відповідь навмисно пише людина. Агент пропонує, а людина вирішує, що почує спільнота. Процес підготовки відповіді вимагає офіційної документації чи схваленого прецеденту модераторів, точних URL і чесної ескалації, коли джерела не дають відповіді. Він виключає вигадані обіцянки виправлень, дат або компенсацій. Надсилання залишається окремим кроком із попереднім схваленням людини. Я хотів передавати докази, зберігаючи людське судження і голос.
Як зробити інструмент придатним для інших
Встановлення я теж розглядав як частину продукту. Репозиторій містить власний опис маркетплейсу плагінів, тому завантажений ZIP може бути джерелом встановлення. Документований шлях дозволяє керівнику підтримки попросити ZCode встановити локальний плагін без ручного складання середовища Python.
Основні скрипти використовують стандартну бібліотеку Python; пряма генерація PDF має необов'язкову залежність. Код містить шляхи для macOS, Windows і Linux; живі перевірки наразі записані лише для macOS, включно з реальним збором тем, завантаженням вкладень, створенням звітів і повним циклом роботи з базою знань. Підтримку Windows і Linux реалізовано, але записи перевірок досі вимагають живих тестів на цих системах.
Що побудовано і що далі
Це рання реалізація з робочими частинами та незавершеною роботою. Записи перевірок підтверджують конкретні тести, а не промисловий масштаб, впровадження чи виміряну економію часу. Охоплення збору, свіжість кешу, поведінка на різних платформах і правила автоматизованого дослідження спільнот потребують подальшої роботи перед широким розгортанням. Ці межі варто назвати прямо.
Саме таку інженерну роботу я хочу робити: почати з операційної проблеми, обрати відповідний процес, побудувати інструменти й обмежити твердження наявними доказами. Бажання краще розуміти користувачів стало системою, яка перетворює відгуки на перевірювані продуктові пріоритети.
Коли команда вирішує, чому приділити увагу, вона має вміти показати чому.
Примітка до публікації
Можливості проєкту та записані перевірки описує Roman; це не незалежно повторені випробування продукту. Публічна документація ZCode підтверджує механізм плагінів і локальних маркетплейсів, але не результати проєкту чи дотримання правил платформи.