За последние два года компания приобрела немало AI‑инструментов: чат‑ботов, плагины для письма, роботов по обслуживанию клиентов и систему внутреннего обмена знаниями. Однако по‑настоящему устойчивых компетенций оказалось не так уж много. Шаблоны запросов до сих пор хранятся на личных компьютерах, бизнес‑процессы разбросаны по углам документов, после запуска интеллектуальных агентов отсутствует обратная связь и доработки, а ключевые сотрудники по‑прежнему полностью заняты одними и теми же типами консультаций. Проблема зачастую заключается не в недостаточной «умности» моделей, а в том, что…Система не оформила «работу» как управляемую компетенцию должности.。
Сначала разберёмся: почему окно чата не может быть назначено на должность?
Чат‑бот отвечает на один вопрос и затем завершает диалог. Для должности требуется непрерывно принимать и обрабатывать задачи: собирать информацию, применять правила, вызывать системы, обновлять статусы и при возникновении исключений передавать запрос на следующий уровень. Типичным примером является оформление командировочных расходов: пользователь сначала может сказать: «Помогите оформить командировку», затем в середине спросить: «Сколько осталось лимита на этот месяц», а позже добавить ещё одну квитанцию. Если система будет рассматривать каждый разговор как новый сеанс, процесс прервется, контекст будет утерян, и впоследствии невозможно будет проанализировать, была ли ошибка в правилах или в интерфейсе.
В отрасли уже существует практика создания интеллектуальных агентов в формате «цифровых сотрудников»: им присваиваются должность, номер сотрудника, границы компетенции и записи о выполненной работе, а также добавляются редактируемые SOP, база знаний, инструменты и журнал выполнения задач. В направлении открытого кода проект StaffDeck, опубликованный такими организациями, как OpenBMB, рассматривает агента как управляемый набор ресурсов, а не просто фрагмент инструкций. Для компаний, разрабатывающих решения самостоятельно или на заказ, стоит заимствовать не сам термин продукта, а именно эту объектную модель.
Логика бизнеса: в системе должно быть как минимум семь типов объектов.
При создании системы цифровых сотрудников сначала включите бизнес‑объекты в спецификацию, а затем приступайте к выбору модели.
- Архив должности: ФИО или имя персонажа, служебный номер, обязанности, статус онлайн, объект обслуживания. Без профиля нет куда привязать права и оценки.
- Граничные возможности: какие документы можно читать, какие поля можно заполнять, а на что нельзя давать обещания. Границы должны быть изменяемыми администратором, а не жёстко закодированными в системных подсказках.
- SOP / Процессно‑ориентированные навыки: Разбивайте сложные процессы на узлы, поддерживая условные ветвления, вызовы инструментов, поиск знаний и переключение на работу с человеком.
- Онтология знаний: Темы, правила, источники и руководства по эксплуатации хранятся отдельно; ответы должны однозначно указывать на источник, а поиск — поддаваться настройке.
- Интеграция инструментов: HTTP‑интерфейс или MCP, используемые для проверки лимитов, создания документов и изменения статуса, а не просто для генерации текста.
- Плановая задача: Такие периодические задачи, как сводка ежедневных отчётов, напоминания о просроченных делах и инспекция складских запасов, не должны ждать, пока пользователь сам обратится.
- Отслеживание и обратная связь: фиксируются маршруты, этапы, инструменты, знания и ответы; лайки, дизлайки и ручное переключение передаются на следующий этап редактирования.
Одно реальное обращение часто включает несколько задач. Цифровой сотрудник должен сначала перейти в SOP по возмещению расходов, собрать все необходимые поля и выполнить проверку по правилам, после чего переключиться на SOP по запросу лимитов и вызвать соответствующий интерфейс. Если пользователь в процессе задаёт вопрос о политике, следует сохранить текущий узел и вернуться к исходному процессу после ответа. В случае вопросов, выходящих за рамки установленных правил, передать контекст создателю или дежурному сотруднику; категорически запрещается давать ответы без обоснования.
Логика проектирования: роли, автоматизированные машины состояний, иерархия знаний
Как переключить роли?
Как минимум, можно выделить четыре категории людей:Создатель(Закрепить опыт в виде стандартов для сотрудников),Администратор(управление правами, публикация, квоты),Пользователь(назначение задач цифровым сотрудникам),Дежурный(Продолжение исключения). Создатель не должен по умолчанию обладать правами на изменение складских запасов и цен; пользователь не должен видеть полные подсказки и ключи. Открытые интерфейсы также должны быть иерархизированы: ключ уровня учётной записи позволяет управлять ресурсами, а ключ уровня сотрудника — только создавать сессии и читать собственные треки.
SOP использует автомат конечного состояния, не ограничивайтесь лишь использованием диалоговой памяти.
Естественный язык может генерировать черновой вариант, а выполнение обязательно должно проходить по состоянию машины: текущий узел, собранные слоты, доступные вызываемые инструменты, повторные попытки при сбое, ручной узел. После прерывания задачи необходимо сериализовать контекст и вернуться к исходному узлу для продолжения. Несколько SOP‑ов допускают переключение в реальном времени, но при переключении следует сохранять информацию о том, откуда пришло и какие данные уже подтверждены, чтобы избежать дублирования заполнения форм пользователем. Версии и ветки должны быть откатываемыми; даже если на месте изменяется одна фраза в шаблоне, это сразу же публикуется, и впоследствии невозможно будет возложить ответственность.
Знания не следует превращать в хаотичный сборник для поиска.
Создавайте навигационный индекс по документам, разделам, страницам и аннотациям: сначала определяйте, к какой категории относится информация, а затем находите соответствующий текст. Разделение знаний по «ведрам»: отдельно храните нормативные положения, описания продуктов, послепродажные формулировки и примеры исключений; целевый поиск гораздо надёжнее, чем поиск по ключевым словам в масштабе всей базы. Каждый ответ привязывайте к источнику, правилам и бизнес‑теме; в тестовой среде должно быть видно, «почему именно этот фрагмент был выбран». Часто устранить проблему помогает отладка поиска, а не переход на более мощную модель.
Разработка и внедрение: интерфейсы, изоляция, мониторинг, приёмка
Во время выполнения рекомендуется использовать единый вход, чтобы избежать разветвления потоков для каждого компонента и предотвратить смещение состояния. Обнаружение возможностей, изолированное выполнение, целостность артефактов и расчёт квот должны осуществляться во время выполнения, а не на основе условных соглашений. Перед публикацией компонентов на внутреннем рынке необходимо проводить проверку прав доступа: заголовки аутентификации, переменные окружения и учётные данные подключения не должны присутствовать в обычных интерфейсах чтения.
- Исполнительный канал: Синхронный поток подходит для диалогов; асинхронный Run + поток событий подходит для возобновления работы после разрыва соединения и для очередей задач; оба используют одну и ту же ядро.
- Статус канала: Входом могут служить WeChat, WeCom, Feishu и DingTalk, однако данные о статусе сотрудников, сведения о беседах и Trace должны быть едиными; запрещается вести отдельные базы данных на каждом из этих каналов.
- Безопасность: Конфигурация модели ссылается только на существующие номера конфигураций и не передаёт обратно ключ поставщика; при загрузке результатов инструмента в Trace осуществляется их деанонимизация.
- Ручное обеспечение: При превышении времени ожидания, низкой степени доверия, несанкционированном доступе и при активном переходе пользователя на оператора — все четыре условия должны обеспечивать полную передачу контекста.
При приёмке не ограничивайтесь проверкой лишь «возможности общения». Подготовьте набор повторяемых сценариев: нормальное завершение цикла, вмешательство в процесс, недостаток лимита, тайм‑аут интерфейса, запись с превышением прав доступа, отсутствие источника — отказ в ответе. По каждому сценарию проверяйте: восстановлены ли узлы, правильно ли записаны документы, полна ли трассировка, попадают ли исключения на соответствующих сотрудников. Коэффициент прохождения выборочной проверки, уровень обработки тайм‑аутов и количество ответов без оснований — эти показатели гораздо лучше, чем звёздная оценка удовлетворённости, подходят для определения допуска к запуску.
Порядок запуска: сначала — повторяющаяся работа
Не стоит сразу пытаться стать универсальным помощником. Выберите одну из ежедневно повторяющихся задач — например, ведение протоколов по отслеживанию продаж, контроль и ускорение рассмотрения заявок, ответы на вопросы по политикам или предварительную проверку расходов — и оформите её как четыре фразы: ввод данных, вывод, права доступа и исключения. Затем дополните это SOP‑процессом и двумя‑тремя интерфейсами для чтения или ограниченного внесения данных. Когда основные данные запущены в грязное состояние, а узлы утверждения неясны, сначала приведите в порядок объекты и статусы, а затем внедряйте интеллектуальное исполнение — после автоматизации обработки грязных данных информация будет распространяться по всей компании ещё быстрее.
Как понять, что проект разработан правильно: теперь этапы, ранее решавшиеся путём массовых напоминаний и заполнения таблиц, больше не являются основным процессом; протоколы, напоминания и сводные отчёты можно проверять выборочно по документам; случаи, которые трудно объяснить, передаются на рассмотрение вышестоящему уровню; за чувствительные операции отвечает специальный проверяющий, а журналы доступны для просмотра. Чтобы оценить соответствие разработки требованиям, следует смотреть…Можно ли восстановить тот же SOP после его прерывания?、Ответ может указывать на источник?、Могут ли пограничные кейсы перейти к следующему этапу редактирования?. После прохождения этих трёх этапов можно будет расширять штат; это гораздо надёжнее, чем сначала создавать множество точек для общения.
Техническая сложность системы цифровых сотрудников заключается не в генерации диалогов, а в том, чтобы превратить должности, процессы, знания, инструменты и рабочие треки в версионируемые программные объекты. Текст подсказки можно менять десять раз в неделю, но если модель объекта распадётся, то для каждой последующей функции придётся писать отдельный набор кода. Сначала необходимо наладить работу этих семи типов объектов и состояниях машины; только тогда можно будет позволить себе обновлять модель. В противном случае каждое изменение модели превращается в новый проект, а не в простую конфигурационную модификацию.