Практические заметки: вашему агенту для кодирования не нужен лучший промпт

В следующих примечаниях описывается практический подход к решению проблемы «Вашему агенту для программирования не нужен лучший запрос». Основное внимание уделяется контрактам, проверкам и шаблонам кода, а не мотивирующим формулировкам.

Ему нужны лучшие условия работы

На этапе определения лучших условий работы сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых данных несколько раз — частая причина износа ресурсов.

Цикл curl

При работе над этапом цикла curl сначала запишите условия работы: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список поможет сохранять честность при последующих изменениях кода. Документируйте одновременно успешный сценарий работы и сценарий восстановления. Повторные попытки, проверки со стороны операторов и обработка некорректных сообщений являются частью продукта, а не элементами последующей доработки. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых заголовков — распространенная причина избыточных нагрузок.

search for artifact
      ↓
try dependency
      ↓
Maven failure
      ↓
search web
      ↓
curl documentation
      ↓
download JAR
      ↓
inspect classes
      ↓
try another version
      ↓
search again

Итерация 1: Исправление среды

При работе над этапом «Исправление 1» сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист помогает сохранять честность при последующих изменениях кода. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг терпит неудачу, ошибка должна указывать на конкретную ответственность, а не на запутанную цепочку операций. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинакового преамбула — частая причина избыточных затрат ресурсов.

LLM + prompt

Model
  + instructions
  + repository
  + build
  + tools
  + runtime
  + available evidence
  + project knowledge
  + feedback loops

Итерация 2: Обеспечьте агенту инструменты навигации, которые уже используют инженеры

При работе над второй итерацией на этом этапе сначала запишите контракт: необходимые входные данные, сигнал успешного завершения и действия при частичной неудаче. Такой чек-лист помогает сохранять честность при последующих изменениях кода. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия создаваемым элементам, определите критерии успешности и не допускайте молчаливого частичного завершения работы. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых заголовков — частая причина ресурсозатрат.

shell + filesystem + internet

interface
   ↓
implementation
   ↓
usage
   ↓
test

Итерация 3: Иногда лучшим контекстом является человек, указывающий на нужный файл

При работе над этапом «Итерация 3 Sometimes» сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист помогает сохранять честность при последующих изменениях кода. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Очевидность затрат с самого начала предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых заголовков — частая причина избыточных затрат. При работе над этапом «Итерация 3 Sometimes» сначала запишите контракт: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой чек-лист помогает сохранять честность при последующих изменениях кода. Документируйте одновременно «идеальный путь» и путь восстановления. Повторные попытки, проверки со стороны людей и обработка некорректных сообщений являются частью продукта, а не элементами последующей доработки.

AllMiniLmL6V2EmbeddingModel
        ↓
AbstractInProcessEmbeddingModel
        ↓
OnnxBertBiEncoder

Hugging Face tokenizer
        ↓
ONNX Runtime
        ↓
token representations
        ↓
pooling
        ↓
normalization
        ↓
embedding

Итерация 4: Почему мы решаем, что должен изучить агент?

Этап «Почему» в рамках итерации 4 работает лучше всего, когда рассматривается как измеримая величина. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг терпит неудачу, причина сбоя должна указывать на конкретную ответственность, а не на запутанную цепочку операций. Установите лимит токенов на один ход и на всю сессию. Инструменты агентов активно расширяют объем контекста; жесткие ограничения предотвращают появление неожиданных счетов.

Небольшой эксперимент с Integrallis Vectors

Небольшой эксперимент на этом этапе будет наиболее эффективен, если рассматривать его как измеримую поверхность. Зафиксируйте один успешный пример, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Рассматривайте этот этап как контракт между входными данными и проверенными результатами. Дайте названия создаваемым элементам, определите критерии успеха и не соглашайтесь на молчаливое частичное выполнение задачи. Установите лимит токенов на каждый ход и на каждую сессию. Инструменты агента активно расширяют контекст; строгие ограничения предотвращают появление неожиданных счетов.

../vectors/

Initial working model
        ↓
low confidence recognized
        ↓
specific evidence requested
        ↓
source inspected
        ↓
previous hypothesis falsified
        ↓
new working model
        ↓
better engineering recommendation

Да, агент научился…

Этап обучения агента Yes the Agent работает наилучшим образом, когда его рассматривают как измеримую среду. Соберите один идеальный пример взаимодействия, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Записывайте время выполнения операций, а также стоимость токенов или запросов рядом с функциональными результатами. Отслеживание затрат на раннем этапе предотвращает неожиданные счета при переходе от демо-версии к общедоступным средам. Установите лимиты на количество токенов за один ход и за сессию. Инструменты агента активно расширяют контекст; жесткие ограничения не позволяют демо-версиям превращаться в неожиданные счета. Этап обучения агента Yes the Agent работает наилучшим образом, когда его рассматривают как измеримую среду. Соберите один идеальный пример взаимодействия, один случай сбоя и запись о возврате к предыдущему состоянию перед расширением объема работ. Документируйте одновременно успешный путь выполнения задачи и путь восстановления после сбоя. Повторные попытки, проверка человеком и обработка неработающих сообщений являются частью продукта, а не элементами последующей доработки.

Процесс обучения агента должен сохраняться дольше самого агента.

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

docs/engineering/

docs/knowledge/

docs/knowledge/vector-backends/
    onnx-embedding-pipeline.md
    integrallis-vectors.md
    candidate-assessment.md

Local embedding baseline:
- all-MiniLM-L6-v2
- 384 dimensions
- ONNX Runtime
- DJL HuggingFaceTokenizer
- mean pooling
- L2 normalization

Long inputs:
- partitioned before inference
- embeddings combined using token-count weightingLangChain4j:
- useful as a verified reference implementation
- not required by the runtime designUpstream source:
- available locally for deeper verification

retained knowledge
       ↓
task understanding
       ↓
remaining uncertainty
       ↓
targeted evidence
       ↓
new learning
       ↓
updated retained knowledge
       ↓
next agent

Исследования — часть делегирования

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

"Agent, do everything."

"Human specifies every line."

Агент — это не джинн в лампе

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

Coding Agent
                          │
          ┌───────────────┼───────────────┐
          │               │               │
       Harness         Knowledge        Research
          │               │               │
        tools          project facts     source
        build          decisions         docs
        IDE            constraints       experiments
        runtime        prior learning    external evidence
          │               │               │
          └───────────────┼───────────────┘
                          ↓
                    Clear boundaries
                          ↓
                   Precise delegation
                          ↓
                    Implementation
                          ↓
                     Verification
                          ↓
                  Retained knowledge
                          │
                          └──────→ next agent

От формулировки запросов к настройке рабочих условий

На этапе перехода от формулировки запросов к их реализации сначала запишите условия контракта: необходимые входные данные, сигнал успешного выполнения и действия при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Лучше использовать небольшие, тестируемые модули вместо обширных скриптов. При сбое какого-либо шага причина должна быть связана с конкретной ответственностью, а не с запутанной структурой обработки. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинаковых данных — распространённая причина износа ресурсов.

better environment
      ↓
cheaper investigation
      ↓
better evidence
      ↓
better decisions
      ↓
retained learning
      ↓
better starting environment
      ↓
next agent

Происхождение OSK

При работе над этапом, посвящённым происхождению OSK, сначала запишите контракт: необходимые входные данные, сигнал о успехе и действия при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия элементам, определите критерии успеха и не допускайте молчаливого частичного выполнения задачи. Храните в кэше стабильные системные инструкции и схемы инструментов. Пересылка одинаковых заголовков — частая причина избыточных расходов.

Другой способ программирования с агентами

При работе над подходом «A different way to stage» сначала запишите условия взаимодействия: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отображение затрат на раннем этапе предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинаковых данных — частая причина избыточных затрат. При работе над подходом «A different way to stage» сначала запишите условия взаимодействия: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список помогает сохранять честность при последующих изменениях кода. Документируйте как успешный, так и восстановительный сценарии работы. Повторные попытки, проверки со стороны человека и обработка неработоспособных сообщений являются частью продукта, а не элементами последующей доработки.

Human request
      ↓
Agent generates code

Human hypothesis
      ↓
discussion
      ↓
agent reconnaissance
      ↓
identify uncertainty
      ↓
targeted research
      ↓
retained evidence
      ↓
human + agent design
      ↓
implementation
      ↓
real-world friction
      ↓
verification
      ↓
revised architecture
      ↓
new retained knowledge

Это гипотезы, а не законы

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

Чек-лист операций

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

Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь кодовый граф.

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

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

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

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

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

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

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

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