Інтеграція Anthropic Computer Use для автоматизації інтерфейсів

Потрібно автоматизувати роботу з legacy CRM, у якої немає API? Або протестувати десктоп-інтерфейс на візуальні баги, які не ловлять unit-тести? Ми інтегруємо Anthropic Computer Use — рішення, де Claude керує комп'ютером через скріншоти та дії, адаптуючись до будь-яких змін інтерфейсу. На відміну від AutoHotkey або PyAutoGUI, агент не ламається через зсув кнопки на 5 пікселів. Наш досвід — 5+ років в AI/ML та 20+ проєктів з автоматизації, тому ми гарантуємо надійне рішення під ключ.

Як працює Computer Use

Claude отримує скріншот і повертає команду: клік, введення тексту, скрол. Реалізація на Python з бібліотекою anthropic:

import anthropic
import base64
import subprocess
from pathlib import Path

client = anthropic.Anthropic()

def get_screenshot() -> str:
    """Робить скріншот і повертає base64"""
    import pyautogui
    screenshot = pyautogui.screenshot()
    screenshot.save("/tmp/screen.png")
    return base64.standard_b64encode(Path("/tmp/screen.png").read_bytes()).decode()

def execute_action(action: dict) -> str:
    """Виконує дію з Computer Use"""
    import pyautogui

    action_type = action["type"]

    if action_type == "screenshot":
        return get_screenshot()

    elif action_type == "mouse_move":
        pyautogui.moveTo(action["coordinate"][0], action["coordinate"][1])
        return "moved"

    elif action_type == "left_click":
        pyautogui.click(action["coordinate"][0], action["coordinate"][1])
        return "clicked"

    elif action_type == "double_click":
        pyautogui.doubleClick(action["coordinate"][0], action["coordinate"][1])
        return "double_clicked"

    elif action_type == "type":
        pyautogui.write(action["text"], interval=0.05)
        return "typed"

    elif action_type == "key":
        pyautogui.press(action["key"])
        return "key_pressed"

    elif action_type == "scroll":
        direction = 1 if action["direction"] == "up" else -1
        pyautogui.scroll(direction * action.get("amount", 3), x=action["coordinate"][0], y=action["coordinate"][1])
        return "scrolled"

    return "unknown_action"

def run_computer_use_agent(task: str, max_iterations: int = 30) -> str:
    """Запускає агент Computer Use для виконання завдання"""

    tools = [{
        "type": "computer_20250124",
        "name": "computer",
        "display_width_px": 1920,
        "display_height_px": 1080,
        "display_number": 1,
    }]

    messages = [{"role": "user", "content": task}]

    for iteration in range(max_iterations):
        response = client.messages.create(
            model="claude-opus-4-5",
            max_tokens=4096,
            tools=tools,
            messages=messages,
        )

        if response.stop_reason == "end_turn":
            return next((b.text for b in response.content if hasattr(b, "text")), "Done")

        # Обробляємо tool_use блоки
        tool_results = []
        for block in response.content:
            if block.type == "tool_use" and block.name == "computer":
                action = block.input
                result = execute_action(action)

                # Якщо запросив скріншот — додаємо зображення
                if action["type"] == "screenshot":
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": [{
                            "type": "image",
                            "source": {"type": "base64", "media_type": "image/png", "data": result}
                        }]
                    })
                else:
                    # Після дії робимо скріншот, щоб Claude бачив результат
                    import time
                    time.sleep(0.5)  # чекаємо анімації UI
                    screenshot = get_screenshot()
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": [{
                            "type": "image",
                            "source": {"type": "base64", "media_type": "image/png", "data": screenshot}
                        }]
                    })

        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})

    return "Max iterations reached"

Чому Computer Use надійніше за звичайний RPA?

Класичні RPA-інструменти (Selenium, Playwright) вимагають стабільних селекторів і не адаптуються до зсувів елементів. Computer Use аналізує контекст: якщо кнопка змінила положення, агент «бачить» це на скріншоті та коригує дію. Це критично для інтерфейсів, які оновлюються або кастомізуються. Computer Use працює через аналіз скріншотів і повернення команд природною мовою, що робить його стійким до змін UI.

Як ми реалізуємо інтеграцію?

Ми проектуємо архітектуру, налаштовуємо Docker sandbox з віртуальним дисплеєм і пишемо агента під ваше завдання.

Безпечний sandbox через Docker

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    xvfb x11vnc \
    python3-pip \
    chromium-browser \
    libreoffice \
    && rm -rf /var/lib/apt/lists/*

RUN pip3 install anthropic pyautogui pillow

# Віртуальний дисплей
ENV DISPLAY=:99
CMD ["bash", "-c", "Xvfb :99 -screen 0 1920x1080x24 & python3 /app/agent.py"]

import docker

def run_in_sandbox(task: str) -> str:
    """Запускає Computer Use завдання в Docker-контейнері"""
    container = docker.from_env().containers.run(
        "computer-use-sandbox",
        command=f'python3 -c "from agent import run_computer_use_agent; print(run_computer_use_agent({repr(task)}))"',
        remove=True,
        mem_limit="2g",
        cpu_period=100000,
        cpu_quota=50000,  # 50% CPU
        network_disabled=True,  # вимикаємо мережу, якщо не потрібна
        volumes={"/tmp/output": {"bind": "/output", "mode": "rw"}},
    )
    return container.decode()

Типові завдання для Computer Use

• Робота з legacy-системами без API — старі 1С-конфігурації, Excel-макроси, корпоративні ERP з лише десктоп-інтерфейсом.
• Тестування UI — агент клікає по інтерфейсу як реальний користувач, помічає візуальні баги, які unit-тести пропускають.
• RPA без коду — збір даних з кількох веб-інтерфейсів, перекладання даних між системами без API.

Порівняння з альтернативами

Що входить в роботу

• Аналіз завдання та проектування архітектури агента
• Розробка та налаштування Docker sandbox з віртуальним дисплеєм
• Інтеграція з вашою системою (обмін даними, логування)
• Тестування на реальних сценаріях та оптимізація
• Документація та навчання вашої команди
• Підтримка після впровадження (1 місяць)

Процес роботи

1. Аналітика — розбираємо завдання, визначаємо scope та метрики успіху.
2. Проектування — обираємо модель, налаштовуємо sandbox, пишемо прототип.
3. Реалізація — розробляємо агента, додаємо логування та обробку помилок.
4. Тестування — проганяємо на тестових даних, фіксимо баги.
5. Деплой — розгортаємо у вашій інфраструктурі (on-prem або хмара).
6. Підтримка — моніторинг, доопрацювання за зворотним зв'язком.

Терміни орієнтовно

• Базовий Computer Use агент з pyautogui: 2–3 дні
• Docker sandbox з віртуальним дисплеєм: 2–3 дні
• Конкретне завдання автоматизації legacy-системи: 1–2 тижні
• Моніторинг та логування дій агента: 3–5 днів

Терміни уточнюються після оцінки проекту. Вартість розраховується індивідуально — зв'яжіться для первинної консультації.

Типові складнощі та їх вирішення

• Латентність: кожна дія потребує скріншоту та виклику LLM — в середньому 300–800 мс на крок. Рішення — кешування повторюваних кроків, паралельний запуск незалежних гілок агента та попереднє збереження станів, які агент часто відвідує.
• Галюцинації: агент може невірно ідентифікувати кнопку або ввести дані не в те поле. Рішення — валідація через порівняння скріншотів до/після, явне підтвердження ключових кроків та обмеження області видимості агента лише потрібним вікном.
• Безпека: агент має прямий доступ до операційної системи. Рішення — строгий Docker sandbox з вимкненою мережею, лімітами ресурсів (CPU 50%, RAM 2 ГБ), білим списком дозволених додатків та аудит-логом кожної дії.

Наш стек для Computer Use включає Python 3.11+, Playwright для керування браузером, Docker з віртуальним дисплеєм Xvfb, а для on-premise сценаріїв — VNC-сервер для спостереження за агентом в реальному часі. Логування кожної дії зберігається в structured JSON для подальшого аудиту та аналізу нештатних ситуацій. Оцініть ваш проект: напишіть нам — ми запропонуємо архітектуру та точні терміни. Гарантуємо якість та прозорість на всіх етапах.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.