Что такое эволюция (evolution) в Harness Engineering (component registry, drift detection)?

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

Эволюция в Harness Engineering — это слой управления изменениями в жизненном цикле AI-агента. Он включает ComponentRegistry (реестр версионированных компонентов: промптов, инструментов, конфигураций), DriftDetector (обнаружение отклонений реального поведения агента от ожидаемого) и Architecture rules (проверки, не нарушают ли изменения rules|архитектурные ограничения). Вместе эти механизмы обеспечивают контролируемое, воспроизводимое и безопасное обновление агентных систем, что критически важно для production-развёртываний.

1. Термин: Evolution (эволюция) в Harness Engineering

Evolution — это концепция и набор инструментов (слой 10, библиотека @harness-one/devkit и утилита evolve-check), которые управляют изменениями в агентной системе. В отличие от обычного версионирования кода, эволюция отслеживает поведенческие и конфигурационные изменения компонентов агента: промптов, инструментов, guardrails, цепочек вызовов. Цель — гарантировать, что каждое обновление не ломает архитектурные инварианты и не приводит к дрейфу (непреднамеренному изменению поведения).

Термин «Harness Engineering» — фреймворк для создания AI-агентов с акцентом на тестируемость, наблюдаемость и безопасность. «Эволюция» — это его ключевой слой, отвечающий за контроль версий и целостность агента.

2. ComponentRegistry (реестр компонентов)

ComponentRegistry — централизованный каталог, в котором хранятся все версионированные артефакты агента: промпты (system, user, few-shot), инструменты (функции, API-вызовы), конфигурации (гиперпараметры LLM, чанкинг, эмбеддинги), guardrails (фильтры ввода/вывода]]).

Registry позволяет:

• Откатиться к предыдущей версии, если новое поведение деградировало.
• Сравнивать две версии любого компонента (например, diff промптов).
• Блокировать изменения, если они нарушают rules|Architecture rules.

Пример структуры реестра (псевдокод на Python):

class ComponentRegistry:
    def __init__(self):
        self.components = {}  # name -> list of versions

    def register(self, name: str, version: str, artifact: dict):
        if name not in self.components:
            self.components[name] = []
        self.components[name].append({"version": version, "artifact": artifact})

    def get_latest(self, name: str) -> dict:
        return self.components[name][-1]["artifact"]

    def diff(self, name: str, v1: str, v2: str) -> str:
        # возвращает diff между двумя версиями
        pass

3. DriftDetector (обнаружение дрейфа)

DriftDetector — компонент, который сравнивает ожидаемое поведение агента (заданное тестами, эталонными кейсами) с реальным поведением после изменений. Дрейф может быть:

• Data drift — изменился ввод пользователей (актуально для RAG, если база знаний обновляется).
• Concept drift — изменилось восприятие «правильного ответа» (например, под новые требования бизнеса).
• Behavioral drift — один и тот же промпт начал выдавать другой ответ из-за новой версии LLM.

DriftDetector запускает набор end-to-end тестов на стейджинг-окружении и вычисляет метрики: faithfulness (верность фактам), answer relevance, safety (отсутствие токсичности). Если метрики упали ниже порога — фиксируется дрейф, и новое изменение блокируется или отправляется на доработку.

class DriftDetector:
    def __init__(self, registry, test_suite):
        self.registry = registry
        self.test_suite = test_suite  # список (query, expected_output, expected_behavior)

    def detect(self, new_version_tag: str) -> dict:
        # загрузить все компоненты новой версии
        # прогонить тесты
        # сравнить с baseline (предыдущей стабильной версией)
        results = {"scores": {}, "drift_flagged": False}
        for test in self.test_suite:
            response = self._run_agent(test["query"])
            score = self._evaluate(response, test)
            results["scores"][test["id"]] = score
        # если средний score упал >10% -> drift
        if (results["scores"]["avg"] < self.baseline_avg * 0.9):
            results["drift_flagged"] = True
        return results

4. Architecture rules (архитектурные правила)

Architecture rules — это формальные ограничения, которые проверяются при каждом изменении. Примеры правил:

• guardrails_layer == 0 — guardrails всегда должны быть первым слоем (выполняться до инструментов и LLM).
• max_depth_of_tool_calls <= 3 — агент не может делать цепочку вызовов глубже 3.
• use_only_approved_models — можно использовать только модели из белого списка.
• no_circular_tools — инструменты не могут ссылаться друг на друга циклически.

Проверки выполняются утилитой evolve-check на этапе CI/CD. Если правило нарушено — релиз отклоняется.

Пример конфигурации правил в формате YAML:

architecture_rules:
  - id: "RULE-001"
    description: "Guardrails должны быть первым слоем"
    check: "agent.layers[0].type == 'guardrail'"
    severity: "critical"

  - id: "RULE-002"
    description: "Максимальная глубина вызова инструментов - 3"
    check: "max_depth(agent.tools) <= 3"
    severity: "major"

  - id: "RULE-003"
    description: "Все инструменты должны быть зарегистрированы в ComponentRegistry"
    check: "all(tool.name in registry for tool in agent.tools)"
    severity: "critical"

5. Инструменты: @harness-one/devkit и evolve-check

@harness-one/devkit — npm-пакет (Node.js), который предоставляет API для работы с реестром и детектором дрейфа. Позволяет программно:

• регистрировать новые версии компонентов;
• запускать сравнение метрик;
• получать отчёт о дрейфе.

evolve-check — CLI-утилита, которая интегрируется в pipeline CI/CD (например, GitHub Actions). Она:

1. Загружает текущий манифест агента.
2. Извлекает из реестра предыдущую стабильную версию.
3. Применяет Architecture rules.
4. Запускает DriftDetector на тестовом наборе.
5. Возвращает статус: pass / fail с описанием нарушений.

Это напоминает инструменты вроде pre-commit для агентов, только на уровне поведения, а не только синтаксиса.

6. Пример полного цикла эволюции

1. Разработчик меняет промпт для инструмента поиска документов.
2. Команда evolve-check регистрирует новую версию промпта в ComponentRegistry.
3. Прогоняются Architecture rules: проверяется, что guardrails остались первым слоем.
4. DriftDetector запускает 50 тестовых запросов. Метрика faithfulness падает с 0.92 до 0.80.
5. Дрейф зафиксирован — релиз отклоняется. Разработчик получает отчёт: «Ваше изменение уменьшило точность фактов на 12%».
6. Разработчик возвращается к предыдущей стабильной версии, улучшает промпт, повторяет цикл.

7. Преимущества и вызовы

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

Задача: Реализовать упрощённый прототип эволюции для агента, который отвечает на вопросы по документации.

Инструменты: Python, JSON для реестра, библиотека sentence-transformers для эмбеддингов (базовый детектор дрейфа), pytest.

Шаги:

1. Создать ComponentRegistry как JSON-файл: { "prompt_system": { "versions": [{"version": "1.0.0", "content": "Ты — ассистент..."}] } }.
2. Написать DriftDetector, который загружает baseline (набор вопросов с эталонными ответами) и новую версию. Вычисляет косинусное сходство эмбеддингов эталонного ответа и реального ответа агента как метрику faithfulness.
3. Определить одно Architecture rule: «Агент не должен вызывать инструмент delete_document при вопросе типа "как сделать копию"» (проверять через регулярку).
4. Написать скрипт evolve-check.py, который:
   • загружает текущий манифест;
   • проверяет правило;
   • прогоняет DriftDetector;
   • выводит результат (pass/fail).
5. Закоммитить всё в Git, добавить GitHub Action, который запускает скрипт на каждый PR.

Ожидаемый результат: Рабочий pipeline, который блокирует PR, если правка промпта снижает faithfulness более чем на 10%.

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

Навигация

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