SENTINEL AGENT — конструктор агентных операционных приложений

ИИ-уровень команд для операционной онтологии в стиле Foundry: LLM-агент, который подключается через MCP, отвечает на вопросы на естественном языке реальными данными из запросов, предлагает одобряемые человеком действия и генерирует операционные дашборды по запросу — самосоздаваемый операционный инструмент в стиле Palantir AIP.

Происхождение: этот проект развивает ИИ-агента генератора сайтов, созданного мной для Locari (мой SaaS для генерации лидов — в продакшене; приватный репозиторий) от «LLM генерирует сайт» до «LLM работает с корпоративной онтологией под управлением»: та же ДНК агентского цикла, но каждая возможность теперь типизирована, внесена в белый список, предпросматривается, одобряется человеком и аудируется. Он работает в паре с PACIFIC SENTINEL (Проект 1), чью FastAPI-онтологию этот агент может потреблять напрямую.

Демо из 3 промптов

Запустите всё (офлайн, без API-ключа):

.venv/bin/python scripts/demo.py

Или введите эти промпты в веб-приложение:

Related MCP server: Vela MCP Server

Что такое MCP и как это повторяет Palantir AIP

MCP (Model Context Protocol) — открытый протокол, который даёт LLM типизированную, обнаруживаемую, ограниченную поверхность инструментов для внешних систем. Сервер предоставляет инструменты (имя + описание + JSON Schema); любой клиент — агент, IDE, чат-приложение — подключается, перечисляет их и вызывает. Граница протокола — это граница управления: модель может делать только то, что предоставляет сервер.

Этот проект — миниатюра архитектуры AIP от Palantir:

Как работает human-in-the-loop

 user ──ask──▶ Agent (LLM)                 MCP server                FastAPI (operator)
                │  propose_action(...) ──▶ validate params
                │                          run constraint checks
                │                          build before/after PREVIEW   (no mutation)
                │ ◀── proposal + action_id ─┘
 UI shows preview card ──── human clicks Approve ──▶ approve_action(operator_key)
                                                     └─ mints SINGLE-USE token
                                                   execute_action(token)
                                                     ├─ re-validates vs CURRENT state
                                                     ├─ applies the change
                                                     └─ audit log: proposed→approved→executed

Три уровня контроля удерживают агента в режиме «только предложения»:

1. Белый список — approve_action / reject_action / execute_action удаляются из списка инструментов LLM; агентский цикл отклоняет любой вызов инструмента, который ему не был предоставлен.

2. Ограничение возможностей — для одобрения требуется OPERATOR_KEY, который существует только в процессе оркестрационного сервера (внедряется в env дочернего процесса MCP). Никакой LLM-контекст никогда его не содержит, поэтому агент не может создать токены одобрения даже в принципе.

3. Механика токенов — токены одноразовые (secrets.compare_digest, сжигаются при первом использовании), а выполнение повторно проверяет каждое ограничение по текущему состоянию, поэтому устаревшее одобрение не может превысить лимит депо.

Та же философия управляет дашбордами: агент генерирует строго проверяемую JSON-спецификацию (extra="forbid", 3 типа виджетов, ограниченные размеры), которую интерпретируют фиксированные React-компоненты — никакого HTML, JSX или исполняемого кода.

Архитектура

 React 18 + Vite + TS + Tailwind          FastAPI (port 8100)              MCP server (stdio subprocess)
 ┌──────────────┬───────────────┐   WS    ┌──────────────────────┐  MCP    ┌─────────────────────────┐
 │ Chat panel   │ Actions cards │ ◀─────▶ │ /ws  agent events    │ ◀─────▶ │ 9 tools over ontology   │
 │ (markdown)   │ Live trace    │  HTTP   │ /actions/{id}/approve│  stdio  │ ┌─ StubOntology (dflt)  │
 │              │ Dashboard     │ ◀─────▶ │ /actions/{id}/reject │         │ └─ HttpOntology ──▶ Project 1
 │              │ canvas        │         │ /audit  /health      │         │    (pacific-sentinel)
 └──────────────┴───────────────┘         │ OpsAgent loop + LLM  │         └─────────────────────────┘
                                          │ (Claude ⟷ MockLLM)  │
                                          └──────────────────────┘

Запуск

# Backend
python3.11 -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/python -m pytest                  # 60 tests, fully offline
.venv/bin/python scripts/demo.py            # scripted 3-prompt demo (mock LLM)
.venv/bin/python scripts/smoke_mcp.py       # raw MCP stdio smoke run

# CLI
.venv/bin/python -m ops_agent.cli --llm mock "Which units are critically low on water?"

# Web app: API on :8100, frontend on :5174
LLM_MODE=mock .venv/bin/python -m uvicorn ops_agent.server:app --port 8100
cd frontend && npm install && npm run dev   # open http://localhost:5174
npm test                                    # 8 Vitest component tests

# Real LLM (claude-opus-4-8; key read from env, never hardcoded)
export ANTHROPIC_API_KEY=sk-ant-...
.venv/bin/python -m ops_agent.cli "Which units are critically low on water?"

# Against Project 1's live ontology instead of the stub
ONTOLOGY_BACKEND=http ONTOLOGY_API_URL=http://localhost:8000 ...

Режимы LLM — LLM_MODE=auto (по умолчанию: live, если задан ANTHROPIC_API_KEY, иначе mock) / mock / live. MockLLM ведёт себя как модель с вызовом инструментов (обосновывающий запрос → фильтрованный запрос → ответ; разбор действий; построение дашбордов), поэтому каждый поток — включая тесты и демо — работает офлайн и детерминированно.

Вехи

• M1 MCP-сервер: инструменты онтологии только для чтения поверх сменного бэкенда + тесты

• M2 Агентский цикл: вызов инструментов LLM через MCP, белый список, события аудита, CLI

• M3 FastAPI WebSocket-стриминг + React-интерфейс чата/трассировки

• M4 предложение → одобрение человеком (ключ оператора + одноразовый токен) → выполнение → аудит

• M5 генерация спецификации дашборда (безопасный JSON) + React-рендерер (recharts)

• M6 демо-скрипт, скриншоты, этот README