Сэм Альтман из OpenAI в интервью в начале апреля 2025 года сказал следующее:
Меня меньше волнует вопрос, когда AI заменит разработчиков. Гораздо важнее — когда разработчик с AI станет в 10 раз продуктивнее. Думаю, это может случиться уже в этом году
И я решил разобраться на основе собственных наблюдений, почему этого пока не произошло в полной мере.
Пока система вероятностная, контролировать придётся.
Мы и раньше контролировали детерминированные системы, ведь человек сам по себе тоже вероятностная система и всё время ошибается. Но способы контроля меняются. Когда мы делегируем, например, написание кода агентам, классические подходы вроде код-ревью человеком начинают хуже работать - как минимум из-за эффекта бутылочного горлышка. Человек просто не успевает за агентами, которые могут работать ночи напролёт.
Получается, нам нужно выстраивать альтернативные механизмы контроля качества.
В прямом смысле, нет. LLM систему во ФСТЭК не сертифицирует. Но Агентые системы на базе LLM сильно помогут вокруг самого процесса и заберут знатную долю рутины.
Хороший вопрос. Думаю, сейчас мы до конца не знаем, к чему приведёт ускорение разработки продуктов, но уже очевидно: это происходит прямо сейчас. Если раньше разработчик объяснял компьютеру, как сделать, то теперь всё чаще достаточно сформулировать, что нужно сделать. На мой взгляд, главный вывод заключается в том, что нам всем стоит учиться правильно формулировать свои намерения — независимо от роли.
С функциональной точки зрения оба агента работают ровно одинаково — они подключаются к одному и тому же серверу, запрашивают у него список доступных инструментов и вызывают их по HTTP. Разница лишь в том, как мы реализуем клиентскую логику:
Нативная реализация (FastAPI + OpenAI‑клиент): всё вручную, сами вызываем нужные HTTP‑методы и обновляем контекст.
Фреймворк openai-agents: весь цикл работы с инструментами происходит «из коробки».
Но в обоих случаях сервер остаётся один и тот же. То есть, независимо от того, используем ли мы «чистый» код или готовый фреймворк, все агенты переиспользуют единый сервер и единый набор инструментов, не дублируя реализацию.
Спасибо за комментарий! Вы правы, что существуют официальные Python SDK и MCP Inspector, но в статье мне было важно не повторить документацию, а показать основную идею протокола на простом, наглядном примере — без лишней обвязки и магии. Суть в том, чтобы вынести логику взаимодействия с внешним миром из каждого агента в отдельный сервер. Тогда «рой» агентов сможет использовать одни и те же инструменты без дублирования, используя стандартные LLM‑механизмы вроде function calling.
Важно помнить, что сам протокол изначально создавался под локальные сценарии — прежде всего для интеграции с Claude Desktop. Прямая цитата из документации:
«build a simple MCP weather server and connect it to a host, Claude for Desktop»
То есть о масштабируемой сетевой архитектуре речи тогда ещё не шло. Это, конечно, сдерживает развитие MCP, но сообщество активно его пушит вперёд. А то, что к инициативе подключились Google и OpenAI, даёт надежду на ускорение вразвитие протокола.
Возможно и относительно просто, но надо понимать, что написать код для черчения всегда сложнее, чем просто взять и начертить. Но если требуется часто считать и рисовать однотипные валики, это уже повод для написании отдельной программы или библиотеки.
Согласно ГОСТ 2.103-2013 существует несколько стадий разработки конструкторской документации (Эскизный проект -> Технический проект -> Рабочая документация), на каждой стадии, согласно упомянутому в статье документу, расчёт норм производиться по разному.
Если говорить от чистого сердца, то документ не является эталоном, а служит отправной точкой для каждого предприятие, при разработке своих собственных норм, основываясь на личном опыте и на те задачи, ради которых эти нормы и разрабатываются.
Cчитать чужой труд дело не благородное, но иногда нужное. В нашем случае, что бы отчитываться перед заказчиком.
На написание кода ушло около 2-х недель в свободное от работы время, плюс две недели на написание статьи и рефакторинг. Намного больше времени понадобилась, что бы разобраться с API и именно по этой причине и была написана данная статья.
Сэм Альтман из OpenAI в интервью в начале апреля 2025 года сказал следующее:
И я решил разобраться на основе собственных наблюдений, почему этого пока не произошло в полной мере.
Мы и раньше контролировали детерминированные системы, ведь человек сам по себе тоже вероятностная система и всё время ошибается. Но способы контроля меняются. Когда мы делегируем, например, написание кода агентам, классические подходы вроде код-ревью человеком начинают хуже работать - как минимум из-за эффекта бутылочного горлышка. Человек просто не успевает за агентами, которые могут работать ночи напролёт.
Получается, нам нужно выстраивать альтернативные механизмы контроля качества.
В прямом смысле, нет. LLM систему во ФСТЭК не сертифицирует. Но Агентые системы на базе LLM сильно помогут вокруг самого процесса и заберут знатную долю рутины.
Хороший вопрос. Думаю, сейчас мы до конца не знаем, к чему приведёт ускорение разработки продуктов, но уже очевидно: это происходит прямо сейчас. Если раньше разработчик объяснял компьютеру, как сделать, то теперь всё чаще достаточно сформулировать, что нужно сделать. На мой взгляд, главный вывод заключается в том, что нам всем стоит учиться правильно формулировать свои намерения — независимо от роли.
С функциональной точки зрения оба агента работают ровно одинаково — они подключаются к одному и тому же серверу, запрашивают у него список доступных инструментов и вызывают их по HTTP. Разница лишь в том, как мы реализуем клиентскую логику:
Нативная реализация (FastAPI + OpenAI‑клиент): всё вручную, сами вызываем нужные HTTP‑методы и обновляем контекст.
Фреймворк
openai-agents: весь цикл работы с инструментами происходит «из коробки».Но в обоих случаях сервер остаётся один и тот же. То есть, независимо от того, используем ли мы «чистый» код или готовый фреймворк, все агенты переиспользуют единый сервер и единый набор инструментов, не дублируя реализацию.
Спасибо за комментарий! Вы правы, что существуют официальные Python SDK и MCP Inspector, но в статье мне было важно не повторить документацию, а показать основную идею протокола на простом, наглядном примере — без лишней обвязки и магии. Суть в том, чтобы вынести логику взаимодействия с внешним миром из каждого агента в отдельный сервер. Тогда «рой» агентов сможет использовать одни и те же инструменты без дублирования, используя стандартные LLM‑механизмы вроде function calling.
Важно помнить, что сам протокол изначально создавался под локальные сценарии — прежде всего для интеграции с Claude Desktop. Прямая цитата из документации:
То есть о масштабируемой сетевой архитектуре речи тогда ещё не шло. Это, конечно, сдерживает развитие MCP, но сообщество активно его пушит вперёд. А то, что к инициативе подключились Google и OpenAI, даёт надежду на ускорение вразвитие протокола.
https://debianforum.ru/index.php?topic=151.0
Если говорить от чистого сердца, то документ не является эталоном, а служит отправной точкой для каждого предприятие, при разработке своих собственных норм, основываясь на личном опыте и на те задачи, ради которых эти нормы и разрабатываются.
На написание кода ушло около 2-х недель в свободное от работы время, плюс две недели на написание статьи и рефакторинг. Намного больше времени понадобилась, что бы разобраться с API и именно по этой причине и была написана данная статья.