На сентябрьском Flow 2025 проводилось огромное количество активностей вне докладов. Одной из таких активностей была coffee tables: в промежутке между докладами можно было обсудить горячую тему.
Скилы — вечно горячая тема. LLM-агенты — горячая тема в моменте (впрочем, возможно тоже надолго). В результате организовался стол, на котором кофе был самым холодным предметом.
Мы старались не спорить, что нужно, а что нет, но просто собрать все идеи.
Как видно на картинке, сначала предполагалось, что скилов нужно мало. По мере обсуждения мы делились кейсами и вспоминали, что эти кейсы от нас требовали. При этом буквы уменьшались, слова сокращались и виден результат неоднократных попыток использовать пустое пространство сверху листа.
Итак, расшифровка и комментарии (что мы обсуждали, но на лист не попало). Некоторые пункты сгруппированы, но постарался ничего не упустить.
Работа с промптами.
Общие правила работы с промптами (идентификация роли, предоставление контекста, chain of thought, использование JSON для структурирования промпта и т.п.).
Понимание принципов токенизации и представления диалога (например, формат OpenAI Harmony Response Format, используемый OpenAI для обучения oss-моделей).
MarkDown как основной формат неструктурированных сообщений для LLM.
Умение проектировать мосты ИИ во внешний мир.
Подходы к организации взаимодействия LLM с внешним миром: Tool Calling, ReAct, PAL (Program-aided Language Models).
Structured Output как технология (подходы) получения результатов работы LLM в структурированном виде.
Понимание векторного поиска, принципы построения RAG-агентов.
Типовые протоколы взаимодействия LLM c внешним миром: MCP (экспонирование инструментов для агента), A2A (экспонирование других агентов).
Проектирование рабочих процессов (алгоритмов решения задачи). Разработка решений, использующих LLM, — это чаще всего комбинация вызовов LLM, запуска инструментов и действий пользователей. Очень похоже на проектирование обычных автоматизированных процессов.
Работа с интеграциями (в реальной жизни любой LLM-агент — это почти всегда интеграции).
Понимание проблем организации асинхронной работы: LLM — медленная и дорогая, с ней по другому нельзя.
Работа с брокерами как ключевой элемент организации асинхронной работы.
Понимание протокола JSON RPC, т.к. он используется как в MCP, так и в A2A.
Умение создавать агенты, в том числе для прототипирования.
Знание OpenAI API (как наиболее распространенного API для работы с LLM).
Типовые фреймворки для создания агентов (LangChain, PocketFlow, Vercel AI SDK, Sprint AI, JetBrains Koog и т.п.).
Умение разрабатывать агентов в low-code системах (n8n, Make и т.п.).
Умение отлаживать/тестировать/оценивать работу LLM-агентов. Ключевая сложность – недетерминированность работы LLM.
Понимание подходов к оценке основных характеристик работы LLM-агентов (уровень успешности выполнения задач, стоимость, время работы и т.п.).
Владение тестовыми фреймворками. Это могут быть как классические фреймворки для модульного тестирования — PyTest, Jest, JUnit, — так и специализированные фреймворки для тестирования приложений, использующих LLM (ragas, promptfoo).
Мониторинг и работа с логами. В реальных условиях агенты LLM-агенты менее прогнозируемы, чем обычные программы. Чтобы не нарушать вопросы информационной безопасности, быть уверенным в качестве выполнения модели своих функций, предотвращать неконтролируемое использование дорогостоящих ресурсов, критически важно производить мониторинг за работой агентов и уметь отслеживать ситуации, когда все пошло не по плану.
Когда мы все это нарисовали возник вопрос «Это точно про системного аналитика»? Впрочем, не было ни одной роли в создании современных ИТ-продуктов (информационных систем), которая бы подошла под эти скилы.
Попробуем назвать такого человека «специалист по созданию ИИ-агентов». Но, я уверен, описанные скилы ближе всего именно к системному аналитику.
А что вы думаете по этому поводу?
Источник: habr.com
