ИИ-агент DeepSeek: первый цикл с инструментом и проверкой

ИИ-агент на DeepSeek получается не из одного промпта, а из связки модели, вашего приложения и разрешённого инструмента. Ниже показана схема безопасного пробного цикла: модель предложит получить сведения из локального справочника, приложение проверит аргументы, выполнит чтение и вернёт результат модели. Понадобятся доступ к DeepSeek API и возможность запустить небольшой Python-проект. Если нужен просто ответ без внешних действий, достаточно обычного чата.

Что именно делает DeepSeek в агенте

DeepSeek поддерживает вызов инструментов через API: модель формирует имя функции и аргументы, но не исполняет функцию сама. Исполнение, проверка прав и передача результата лежат на вашем приложении. Это прямо показано в официальном руководстве Tool Calls. Поэтому фраза «дать агенту доступ к базе» на практике означает написать узкий код доступа и решить, какие данные ему разрешено видеть.

Не смешивайте три продукта: веб-чат DeepSeek отвечает на вопросы, API даёт модель приложению, агентный интерфейс поверх API определяет инструменты и порядок работы. Для примера ниже веб-чат не нужен. Статья про устройство ИИ-агента через API объясняет общий цикл без привязки к поставщику.

Когда стоит брать API, а когда не стоит

Выбирайте API, если агент должен читать ваши данные, возвращать ответ в сервисе или работать по повторяемому сценарию. Если задача ограничивается анализом текста, сначала проверьте её в чате. Не подключайте инструмент только ради слова «агент»: каждый инструмент добавляет место, где возможны ошибка аргумента, лишние права и неверный результат.

• Задача: «найти статус заказа по тестовому номеру» подходит для узкого инструмента чтения.
• Задача: «самостоятельно исправить все заказы» слишком широка для первого запуска.
• Результат: ответ должен содержать статус и идентификатор исходной записи, а не догадку модели.
• Граница: инструмент не видит чужие записи и не меняет состояние.

Правило первого запуска: один инструмент, только чтение, тестовые данные. Право записи добавляйте после отдельной проверки сценария и разрешения владельца данных.

Какие исходные условия нужны

Создайте учётную запись и ключ в официальной платформе DeepSeek. Доступность оплаты и API в вашей стране проверяйте непосредственно в личном кабинете до проектирования рабочего сервиса: условия могут меняться. Ключ храните в переменной окружения на стороне сервера. Не вставляйте его в страницу, репозиторий, пример ответа модели или журнал. Для Python можно использовать совместимый клиент с базовым адресом API; он указан в документации API.

Подготовьте маленький вымышленный справочник: «A-101: готов», «A-102: ожидает проверки». Он нужен только для теста, реальные заказы не понадобятся. Определите точный формат входа: номер вида A-101; остальные строки инструмент отклоняет. Сохраните исходный файл и ожидаемые ответы, чтобы после правки можно было повторить тот же тест.

По теме: Как создать MCP сервер на Python: код и проверка

Как собрать первый цикл с инструментом

В официальном примере Tool Calls приложение отправляет описание функции, получает tool_calls, добавляет в историю сообщение модели, затем передаёт ответ инструмента с тем же tool_call_id. Ваше приложение выполняет функцию между этими двумя запросами. Без возврата результата модель не узнает, что нашлось в справочнике.

1. Опишите одну функцию lookup_order с обязательным строковым аргументом order_id. Название и описание должны обещать только чтение статуса.
2. Отправьте системное правило «отвечай только по результату инструмента; при отсутствии записи сообщай, что она не найдена» и вопрос с тестовым номером.
3. Проверьте, что модель запросила именно lookup_order, а order_id соответствует допустимому формату. Любое другое имя или значение отклоните в коде.
4. Выполните поиск в тестовом справочнике. В журнале сохраните только идентификатор теста, имя функции и исход «найдено/не найдено», без ключа.
5. Передайте ответ инструмента модели с исходным tool_call_id. Покажите пользователю итог и исходный статус рядом для сверки.

Для устойчивой схемы не доверяйте аргументу лишь потому, что он пришёл в формате JSON. Проверьте тип, длину, допустимые символы и право текущего пользователя читать запись. Строгая схема функции помогает формату, но не заменяет проверку полномочий; требования и ограничения режима strict описаны в руководстве DeepSeek.

Как проверить, что агент действительно работает

Проведите три пробы с тем же кодом. Существующий A-101 должен вернуть статус из справочника; отсутствующий A-999 должен дать «не найдено»; значение с неожиданными символами должно быть отклонено до поиска. Сверяйте не только красивый текст, но и журнал вызова, аргумент и фактический ответ функции. В материале о проверке ответов агента разобрано, почему финальная фраза не является доказательством выполненного действия.

Если тест с существующим номером не прошёл, идите по цепочке: был ли tool_calls в ответе, совпало ли имя функции, прошла ли проверка аргумента, нашлась ли запись, вернулся ли результат с тем же tool_call_id. Если сбой появился после включения режима рассуждения, проверьте требование DeepSeek передавать reasoning_content обратно при последующих вызовах с инструментами; это описано в руководстве Thinking Mode.

По теме: ИИ-агент: память между сеансами без ошибок и утечек

Что ограничить до реального запуска

В рабочем сервисе человек и агент должны видеть только свои записи. Проверяйте это на стороне инструмента по удостоверенной личности пользователя, а не по просьбе в промпте. Для действия с внешним эффектом сделайте отдельную функцию, отдельное право, предварительный просмотр и явное подтверждение. OWASP описывает избыточную функциональность, права и автономность как источники риска для агентных систем.

Поставьте ограничение числа вызовов за задачу и понятную остановку при ошибке. При тайм-ауте не повторяйте действие записи вслепую: сначала проверьте, успел ли внешний сервис его принять. Эта граница полезна даже для простого бота и разобрана на общем уровне в статье о настройке ИИ-агента.

Когда этот способ не подходит

Если требуется доступ к секретам без возможности ограничить права, нельзя проверить собственника записи или результат должен быть юридически значимым без контроля человека, такой пилот запускать нельзя. Сначала исправьте модель доступа и процесс подтверждения. Если API недоступен для вашего аккаунта, не обходите ограничения случайным посредником с неизвестным обращением с данными. Тестовую схему можно отложить или выполнить на другом официально доступном сервисе.

Частые вопросы

DeepSeek сам выполняет функцию?

Нет. Модель предлагает вызов; ваше приложение проверяет и исполняет функцию, а затем отправляет результат обратно.

Можно ли обойтись без программирования?

Для простого ответа используйте чат. Для собственного инструмента нужен код или платформа, которая явно показывает права, журнал и шаг подтверждения.

Почему агент придумал статус?

Проверьте, получал ли он настоящий ответ функции. Запретите выдавать статус без результата инструмента и отдельно показывайте источник записи.

Нужны ли сразу несколько инструментов?

Нет. Начните с одного чтения. Добавляйте следующий инструмент только под отдельную проверяемую задачу.