VMware Tanzu спонсировал этот пост.
Чтобы сделать хорошие агентские приложения ИИ, разработчики должны хорошо справиться с тем, что они ужасны: документация. Это связано с тем, что агентские приложения ИИ используют много инструментов, и для понимания, когда и зачем использовать эти инструменты, ИИ нужна хорошая документация.
Я кодировал серверы Code Model Context Protocol (MCP), чтобы помочь мне играть в Solo Dungeons & Dragons с Claude, как я рассказывал в своей предыдущей статье по этой теме. Играть в D & D только с роботами ИИ — это весело и восхитительно. Добавление в агентских рабочих процессах ИИ значительно улучшает его: он добавляет случайность к ИИ, который может вырвать его из предсказуемых сюжетов. Когда я делал эти маленькие инструменты MCP, я обнаружил, что большую часть своего времени на написание описаний того, что делает каждый инструмент, и уточняет эти описания, когда я проверяю инструменты. Вот почему я думаю, что документация важнее, чем когда -либо, когда речь идет о агентском ИИ, будь то удовольствие от изучения жутких лесов или примирения региональных заказов на покупку.
Документация важна
Когда вы смотрите на примеры кода MCP, вы видите, что основной способ рассказать ИИ, что делает инструмент с описанием естественного языка инструмента. Каждый инструмент имеет описание, и каждый из параметров инструмента также имеет описание. Итак, если вы пишете кучу инструментов MCP, то, как вы описываете их роботу, становится важным.
Эти описания инструментов MCP не являются типичными описаниями API. Типичные описания API документируют, что что -то делает. Действительно хорошие также описывают, как это делает код, включая обработку ошибок и поведение.
Это, безусловно, важно для документации по агентским ИИ, но вы также хотите описать, когда ИИ должен использовать инструмент, почему он будет использовать его и как применять результаты инструмента. Вы хотите иметь мнение о том, для чего подходит инструмент. И как только вы загружаете в примерах, ваши документы в конечном итоге почти выглядят как история.
Оракулы
Хорошим примером этого является написание инструмента MCP, чтобы служить «оракулом» в сольной ролевой игре. В сольной ролевой игре, как следует из названия, вы играете самостоятельно, составляя историю, когда вы идете. В этих случаях вы часто хотите, чтобы случайные идеи управляли тем, что происходит в вашей истории, которые помогут вам придумать неожиданные повороты. Oracle — это способ создания этих случайных идей, когда вы сольной ролевой игре. Например, у вас может быть оракул, который дает вам идеи о том, как что-то пахнет: свежий, как бекон, трехдневный тофу, яблоки и так далее. Там может быть список из 20 или 100 из них. Когда ваш персонаж вошел в комнату и увидит кучу чего -то, чтобы выяснить, что это за куча, вы бросите немного костей и используете одну из случайно выбранных записей из этого Oracle. Вы катитесь 54: «Старая обувь». И, таким образом, в своем журнале сольной ролевой игры вы пишете: «Свен, гном вошел в плохо зажженную комнату за конюшни и заметил кучу чего -то. Используя свой значительный обонятельный смысл, он пахл чем -то безошибочным: гоблинские туфли».
В моей любимой системе сольной ролевой игры, машине разворачивания сюжета, существует более 40 оракулов для вещей от запахов, непрерывных персонажей (NPC), темах разговора, как выглядит любой заданный объект и так далее.
Когда я играю в Solo D & D с Клодом, он делает достойную работу, отвечая на мой гном тем, что произойдет дальше в истории. Но, по дизайну, это очень предсказуемо в ответ. В конце концов, что делает генеративный ИИ: он говорит вам следующие вероятные слова (конечно, токены), которые следуют тому, что вы только что напечатали. В этом случае самая предсказуемая вещь, которая произойдет, это то, что какой -то монстр прячется под этой кучей обуви, или что это какой -то монстр, который имитирует кучу обуви.
Использование результата от Oracle может вырвать его из этой предсказуемости. Теперь, как правило, я наканул кости на оракул, который у меня есть, а затем вводит результат в Клод. Но с помощью инструмента MCP я могу создать небольшой инструмент и попросить Клода решить, когда позвонить Oracle. Мне больше не нужно управлять поиском таких вещей, как «старая обувь» в оракуле, и передавать их Клоду.
Результатом, как мы увидим, является то, что я могу оставаться в игре больше и не решать, когда нужно вызвать оракул.
Код прост
Давайте посмотрим на пример настольного компьютера Claude, который приводит к использованию инструмента, а затем использует инструмент. Сначала мы посмотрим на конечный результат, а затем на коде. Это покажет, почему документация для инструмента очень ценна.
Ниже я прошу Клода начать играть в D & D и рассказать ему немного о ситуации, торговце, идущий по дороге. В пользовательском интерфейсе вы можете увидеть, как он называет инструменты EasyChatdm, три из них:
Вы видите, что Клод делает простой агент AI Workflow:
Это очень простой рабочий процесс, но он демонстрирует отличительные особенности «агента».
Клод ведет себя автономно. Он решил вызвать каждый из этих инструментов, составить план и ответить на результаты. Это приводит к тому, что Клод придумывает следующее движение торговца. В зависимости от того, как вы играете, этот процесс может стать еще более подробным. Для более сложных вещей, таких как создание приключений, я видел, как оно называется 10 или более инструментов в одной агентской цепочке.
Инструменты, которые я использую здесь, просты — Oracle NPC просто выбирает случайную линию текста из файла. Но легко увидеть, как вы могли бы сделать более сложные вещи, такие как инструменты, такие как получение пользовательских записей, поиск инвентаря, даже выполнение проверки документов. Инструменты могут делать все, что вы хотите, это просто код.
Вместо просто строки кода вы также можете вернуть гораздо более структурированный выход, например, JSON. Вы можете начать цепочку других событий за пределами Клода, например, пакетная работа для дальнейшего анализа. Но для моего случая, просто зная, что торговец хочет накачать восприятие об их интеллекте, достаточно для меня.
Spring AI делает код быстрым и простым
Как я уже сказал в своем предыдущем посте, фактический код Oracle довольно скучный. Я использую библиотеки MCP Spring AI, поэтому мне не нужно выполнять большую часть работ по лесам, чтобы сделать сервер MCP. И когда вы, наконец, добираетесь до кода и отбрасываете всю обработку ошибок и ведение журнала, весь код делает случайным образом выбирать одну из 303 строк из текстового файла.
Я обнаружил, что документация для мотивации NPC — это то, что важно. Описание того, что делает инструмент и когда его использовать, является интересной работой:
Это описание инструмента хорошо работает в моей игре: его называют довольно регулярно, и мне нравится, как он включен в продолжающуюся историю. Теперь у меня не было никакой документации и просто назвал инструмент MCP «Мотивация NPC». ИИ, вероятно, может выяснить, что с этим делать. У меня также могут быть документы, которые говорят «описания мотивации NPC». Оба из них-тип документации, с которой я обычно сталкиваюсь: либо ничего, либо не слишком прозрачное переписку имени метода.
Эти два метода документирования не дают ИИ много рекомендаций о том, когда это позвонить, что с ним делать и когда не называть его. Документация — это ваш шанс дать направление и стиль игры для ИИ.
Мотивация NPC является относительно проста. Часто, однако, вам нужно много воображения и нюансов, чтобы интерпретировать результат из оракула. Например, другой тип Oracle сообщает вам, в какой степени что -то происходит. Вы можете спросить: «Есть ли воючий гоблин, прячущий в этой куче обуви? Простая да/нет, оракул ответит… да или нет. Но есть также больше нюансированных оракулов, которые вернут градиент ответов, таких как« Да, но… »или« Нет, еще не… »
В этом случае мне нравится тренировать ИИ с некоторыми примерами того, как интерпретировать результаты, как вы можете видеть в документации для easychatdm_subjective_oracle:
Новый навык для разработчиков
То, что я делаю в документации easychatdm_subjective_oracle, и для других инструментов обучает ИИ о том, как думать и использовать эти инструменты. Привести примеры также, как всегда, важно. Вот почему документация важна, и, я думаю, документирование ваших инструментов ИИ более подробно, гуманистическим способом очень важно.
Конечно, мы знаем реальность большинства документации по коде: она ничего не говорит, потому что разработчики не писали ее. Большинство людей сказали бы, что документация важна, но, основываясь на том, что мы видим, она низкая в списке приоритетов.
Я обнаружил, что чем лучше документы, тем лучше сессия D & D с роботами. И я уверен, что это будет иметь место для всех этих захватывающих вариантов использования AI Enterprise.
Лучше хорошо писать документы.
Недавние десятилетия достигли больших успехов в инфраструктуре; Теперь пришло время создать приложения, которые используют максимальную пользу из этих новых инструментов. Решения VMware Tanzu ускоряют разработку и поставку приложений с помощью оптимизированных путей к производству, автоматизированным операциям платформы и улучшению затрат, производительности и безопасности. Узнайте больше последних из VMware Tanzu Trending Stories YouTube.com/thenewstack Tech, которые движутся быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Майкл Коте изучает, как крупные организации становятся лучше в создании программного обеспечения, чтобы лучше работать и развивать свой бизнес. Его книги «Изменение мышления», «Монолитная трансформация» и «Узкое дело» охватывают эти темы. Он был отраслевым аналитиком в Redmonk и 451 … Подробнее от Michael Coté
