Оберіть, куди надходитимуть запити, перш ніж підключати модель
Portward працює з трьома типами моделей: хмарним AI-провайдером через стандартний API-ендпоінт, моделлю, що працює локально на вашому ПК, та вбудованою моделлю. Кожен вибір визначає, куди надходитимуть ваші запити, тому обирайте його до того, як передати агенту завдання на сервері.
Три способи підключення моделі
Хмарний AI-провайдер
Хмарний провайдер підключається через стандартний API-ендпоінт, який ви вводите в налаштуваннях разом із власним API-ключем. Portward надсилає ваші запити на цей ендпоінт, і запит може містити текст будь-якого файлу або журналу, прочитаного агентом, тому хмарна модель отримує цей текст. Ваші чати, робочі папки та API-ключі залишаються на вашому ПК, а секрети в результаті інструментів приховуються перед надсиланням моделі. Цей маршрут поширений для довгих журналів і великих конфігураційних файлів, оскільки модель не обмежена вашим обладнанням. Ознайомтеся з умовами провайдера, щоб дізнатися, як він обробляє запити, і натисніть кнопку Test після введення ендпоінту.
Модель на вашому ПК
Модель, що працює локально на вашому ПК, зберігає все на машині: з локальною моделлю нічого не виходить за її межі. Ви підключаєте Portward до локального ендпоінту, а кнопка Test повідомляє час відповіді та вікно контексту. Швидкість і якість залежать від моделі та вашого обладнання, а менша модель може допускати більше помилок у довгому конфігураційному файлі, тому уважно читайте кожну diff. Цей маршрут підходить для нотаток і журналів, які ви не хочете надсилати жодному провайдеру, наприклад, копії поштової конфігурації, що містить приватні імена.
Вбудована модель
Вбудована модель готова до використання без власного ендпоінту, тому перед першим завданням нічого вводити не потрібно. Обирайте її, коли хочете переглянути картки, diff та режими затвердження перед підключенням чого-небудь іншого. Згодом ви можете перейти на хмарну або локальну модель, якщо завдання вимагатиме більшої потужності. Якість варіюється від завдання до завдання, тому читайте кожну картку результату та diff перед затвердженням, а також перевіряйте результат на сервері з другого сеансу.
Що перевіряє кнопка Test
Кнопка Test перевіряє ендпоінт, а потім показує час відповіді та вікно контексту. Запустіть її після введення хмарного або локального ендпоінту, перш ніж дати агенту завдання на сервері. Вікно контексту показує, скільки тексту вміщується в один запит, що важливо, коли ви вставляєте довгий журнал або конфігураційний файл. Якщо тест не вдається, перевірте адресу ендпоінту та ключ, виправте їх і запустіть тест знову перед початком завдання.
Оберіть модель для завдання
Використовуйте більшу модель для складних кроків, таких як читання довгого журналу або планування зміни брандмауера, і меншу модель для невеликих редагувань, наприклад, однієї рядка в скопійованому конфігураційному файлі. Інструмент run_on_model надсилає складний крок до більшої моделі, тоді як решта чату залишається на вашій основній. Інструмент task розподіляє незалежні перевірки, наприклад, місце на диску та статус служби, між паралельними субагентами. Cron запускає збережений запит за розкладом, а плани зберігаються після перезапуску, тому довге завдання може продовжитися після закриття програми.
Якість варіюється між моделями, і будь-яка модель може неправильно прочитати журнал або запропонувати неправильне налаштування. Читайте diff перед затвердженням. Ask first зупиняється перед діями, що щось змінюють, Plan only створює план і нічого не виконує, а Auto-run діє миттєво, тому узгодьте режим із ризиком зміни. Перевірте результат самостійно, наприклад, увійшовши в систему з другого сеансу.
