Comments 13
Есть вариант промптов, так называемые контракты. Где модель обязуется... И далее по тексту.
Отлично ложится на отношения "Заказчик - Исполнитель" (Contractor по-английски) (y)
В любом контракте есть пункт о последствиях (штрафах) за невыполнение обязательств. А вот что сделаешь с моделью, которая не делает, что обещала? Какой же это тогда контракт и что это за обещание такое, которое можно не выполнять и тебе ничего не будет?
Не очень мне такое название. Почему management? Это разработка. А почему driven? Если агент это исполнитель, то исполнитель не может вести / drive.
Я бы плясал от CASE-систем, computer aided software engineering. Тут всё правильно названо. Теперь поменять на что-то агентское и всё.
"Настоящий" BDSM! Только хардкор и никакой ванили
Интересная метафора с «Заказчиком и Исполнителем». 👍
Думаю, она хорошо подчёркивает отличие LLM от привычного инструмента: результат не всегда предсказуем, а взаимодействие требует «договариваться».
При этом любопытно, что в отличие от человеческого Исполнителя, у Модели нет собственных целей и мотивации — поэтому в какой-то мере это гибридная сущность между «умным инструментом» и «условным специалистом».
Кажется, именно из-за этой двойственности вокруг LLM и возникает столько разных моделей взаимодействия.
Ха, а вот и альтернативщики - "Toolkit to help you get started with Spec-Driven Development"
SDD - тоже неплохо. У меня была попытка называть инструкции для агента "спецификациями". Но чатик меня переубедил - мол, слишком узкий background у этого термина. Спецификации редко пишутся на человеческом языке, они для специалистов, что в теме. А вот инструкции - это как раз для людей со стороны.
В целом наблюдается тенденция к появлению дополнительной категории ЯП: машкоды <= ассемблер <= высокого уровня <= спецификации / инструкции.
Вы плотно подобрались к модели субъект - субъект, практически почувствовали её. Удачи в экспериментах
ADSM: ролевые игры