Как изменилась роль инженера с приходом Harness Engineering?

Краткий тезис

С появлением Harness Engineering роль инженера сместилась от прямого написания алгоритмов к проектированию среды исполнения (execution environment) для AI-агентов. Вместо того чтобы писать каждый шаг вручную, инженер теперь определяет контекст, инструменты, границы и политики, внутри которых агент принимает решения автономно. Это переход от «программиста» к «архитектору агентных систем».

1. Понятие Harness Engineering

Harness Engineering — это подход к разработке AI-систем, при котором инженер создаёт «упряжку» (harness) — структурированную среду, в которой AI-агент может безопасно и эффективно выполнять задачи. Термин введён для описания новой роли: вместо написания кода для каждого возможного сценария инженер фокусируется на проектировании ограничений и возможностей для агента.

Ключевые элементы harness:

• контекст (context) — набор знаний, правил и памяти,
• инструменты (tools) — API, функции, базы данных,
• границы (boundaries) — допустимые действия и привилегии,
• политики (policies) — правила принятия решений, приоритеты, fallback-механизмы.

2. Традиционная роль инженера (до Harness Engineering)

До появления Harness Engineering работа инженера строилась по классическому циклу «код → тест → развёртывание»:

1. Определить задачу (например, «найти ответ в документах»).
2. Написать реализацию (поиск по эмбеддингам, ранжирование, генерация).
3. Обработать исключения (таймауты, ошибки API, неверные форматы).
4. Протестировать и развернуть.

Каждый новый сценарий требовал нового кода. Роль была похожа на программиста-исполнителя, который жёстко прописывает логику.

3. Новая роль: архитектор агентных систем

С Harness Engineering фокус смещается на проектирование среды, а не алгоритмов. Инженер задаёт:

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

Пример трансформации:

• Классический RAG инженер писал:

  docs = vectorstore.similarity_search(query, k=5)
  context = "\n".join([d.page_content for d in docs])
  answer = llm.generate(f"Use context: {context}...")
  

• Agentic RAG с Harness инженер проектирует:

  tools:
    - name: search_docs
      api: vectorstore.similarity_search
      parameters: {query, k}
    - name: web_search
      api: brave_search
      parameters: {query}
  policies:
    - if tool fails → retry with fallback
    - if confidence < 0.7 → ask user clarification
  

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

4. Ключевые компоненты среды исполнения

5. Сравнение: инженер-программист vs архитектор агентов

6. Инструменты для Harness Engineering

Современные фреймворки упрощают создание среды исполнения:

• LangChain / LangGraph – описание графа действий и инструментов,
• CrewAI – мультиагентные системы с ролями,
• Microsoft AutoGen – настройка политик взаимодействия,
• Semantic Kernel – контекст и плагины от Microsoft,
• OpenAI Assistants API – встроенные инструменты, контекст и файлы.

Эти инструменты позволяют инженеру декларировать среду, а не писать её реализацию.

7. Как меняется процесс разработки

1. Анализ задач – какие цели должен решать агент, какие границы установить.
2. Проектирование среды – выбор инструментов, контекстных данных, политик.
3. Прототипирование – быстрая сборка на фреймворке.
4. Симуляция и отладка – тестирование агента на разных сценариях, анализ логов.
5. Непрерывное уточнение – добавление новых политик на основе ошибок.

Инженер тратит больше времени на этапы 1–2, меньше на написание кода каждого шага.

8. Влияние на архитектуру Agentic RAG

В Agentic RAG Harness Engineering проявляется особенно ярко:

• Агент может сам решать, когда выполнять retrieval, а когда – генерацию без контекста.
• Инженер задаёт политику ретривера (например, «если confidence ниже 0.5 → расширь запрос синонимами»).
• Вместо жёсткой цепочки «retrieve → prompt → generate» проектируется цикл: агент итеративно уточняет запрос, переключается между инструментами и возвращает ответ.

Пример кода политики на Python (упрощённо):

class RetrieverPolicy:
    def decide(self, query, initial_docs):
        if not initial_docs:
            # fallback: расширенный поиск
            return self.expand_query(query)
        if max_score < 0.6:
            # уточнить у пользователя
            return self.ask_clarification(query)
        return initial_docs

Здесь инженер не пишет сам поиск, а только решение, когда и как его применять.

9. Навыки, необходимые современному инженеру

• Системное проектирование – умение выделять границы и политики.
• Понимание LLM и агентов – как модели принимают решения, ограничения, склонность к галлюцинациям.
• Декларативное мышление – описание «что должно быть», а не «как».
• Безопасность и контроль – предотвращение нежелательных действий агента.
• Наблюдаемость (observability) – настройка логирования и метрик для отладки поведения агента.

10. Проблемы и вызовы

• Непредсказуемость агента – агент может выбрать неожиданный путь, несмотря на политики.
• Сложность отладки – поведение зависит от состояния среды и контекста, трудно воспроизвести.
• Дрейф политик – со временем агент может начать использовать инструменты не по назначению.
• Безопасность – нужно гарантировать, что агент не выйдет за границы.

Решение – комбинировать Harness Engineering с мониторингом и обратной связью от пользователей.

11. Пет-проект для закрепления

Задача: создать простого AI-агента для ответа на вопросы о курсе (поиск по лекциям + веб-поиск).

Инструменты: LangChain, FastAPI, Python, тестовый набор документов (mock).

Шаги:

1. Определите инструменты: search_lectures (поиск по векторному индексу) и web_search (подключите бесплатное API, например DuckDuckGo).
2. Спроектируйте политику:
   • Сначала всегда используйте search_lectures.
   • Если результат пустой или confidence < 0.5 → вызовите web_search.
   • Если оба инструмента не дали ответа → сформулируйте сообщение «нет информации».
3. Реализуйте harness на LangChain: создайте Tool objects, AgentExecutor с промптом, содержащим политику.
4. Протестируйте на запросах: на которые есть ответ в лекциях, на которые нет, на borderline.
5. Добавьте логирование всех вызовов инструментов и решений агента.

Ожидаемый результат: агент корректно выбирает инструменты по вашей политике, при этом вы не писали ни одного if-else про последовательность. Вы изменили только политику — и поведение агента изменилось.

12. Связь с другими вопросами

Навигация

• Предыдущий: 738
• Следующий: 740
• Индекс: 00. Индекс разборов