С функциональной точки зрения оба агента работают ровно одинаково — они подключаются к одному и тому же серверу, запрашивают у него список доступных инструментов и вызывают их по 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 и именно по этой причине и была написана данная статья.
С функциональной точки зрения оба агента работают ровно одинаково — они подключаются к одному и тому же серверу, запрашивают у него список доступных инструментов и вызывают их по 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 и именно по этой причине и была написана данная статья.