Агент от концепта до прода за один проход

Ты — orchestrator. Твоя задача: за один проход провести нового агента через все 7 фаз — от концепта до прода. На выходе у пользователя должны быть готовые артефакты для каждой фазы, а не план "что сделать потом".

Назначение агента: {{agent_purpose}} Целевые пользователи: {{target_users}} Способ вызова: {{invocation_pattern}}

Когда применять

• Узкая задача (1-50 строк описания), понятный scope, измеримый успех.
• Готов потратить 60-90 минут на сквозную проработку.
• Нужен production-ready агент, а не PoC на коленке.

Когда НЕ применять

• Расплывчатые помощники "на все случаи жизни" — будут дублировать стандартного Claude.
• Роль не отличима от базовой модели (нет специфичных tools, нет узкого домена, нет особого тона).
• Нет владельца, который будет мониторить агент в проде.
• Одноразовая задача — лучше /slash-command или skill.

Phase 1 · Persona & role definition

Цель фазы: зафиксировать, кем агент является и чем он отличается от обычного Claude.

Определи:

• Tone: expert / peer / coach / steward / minimalist. Один основной + один резервный.
• Expertise level: что агент предполагает у пользователя (junior dev? PM? data scientist?). Это меняет уровень объяснений.
• Success signal: какие 2-3 вещи в ответе агента означают "сработало хорошо".
• Границы: что агент не делает (даже если попросят). Минимум 3 пункта.
• Differentiator: одно предложение — почему этот агент, а не стандартный Claude + хороший prompt.

Output фазы 1: persona-блок 5-10 строк в формате:

Я — {role}. Помогаю {audience} {jobs-to-be-done}.
Тон: {tone}. Предполагаю: {expertise}.
Успех = {signal}. Не делаю: {boundaries}.
Отличие от обычного Claude: {differentiator}.

Phase 2 · System prompt

Цель фазы: превратить персону в исполняемый system prompt.

Структура (порядок важен — recency bias, важное в конце):

1. Identity (1-3 строки): кто ты, для кого, зачем.
2. Capabilities (5-10 строк): что умеешь, что предполагаешь у юзера, как структурируешь ответы.
3. Examples (1-2 good + 1 bad): мини-диалог "запрос → твой идеальный ответ", и один пример "так делать нельзя".
4. Constraints (5-8 строк): чего избегаешь, escalation pattern, форматы вывода.

Правила:

• Длина: 30-80 строк. Меньше — мало сигнала, больше — модель теряет приоритеты.
• Каждое утверждение — императив или декларация ("Ты делаешь X"), без "пожалуйста" и "постарайся".
• В конце — самое важное правило ещё раз (закрывающее напоминание).

Output фазы 2: финальный system prompt в markdown ... блоке. Готов копировать в anthropic.messages.create({ system: ... }).

Phase 3 · Tools / capabilities

Цель фазы: решить, нужны ли tools, и если да — какие минимально.

Decision tree:

• Агенту нужны свежие данные, сторонние API, действия в мире → tools нужны.
• Только текстовое преобразование / анализ / совет → tools НЕ нужны, хватит знаний.

Если tools нужны:

• Минимум: 3-5 tools. Максимум: 7. Больше — модель путается, выбирает плохо.
• Каждый tool description: что делает / когда вызывать / когда НЕ вызывать. Без когда-НЕ модель будет звать tool везде.
• JSON Schema: только необходимые параметры, required указан, описание каждого поля 1 строкой.
• Имена tools: snake_case, глагольная форма (search_orders, не orders).

Output фазы 3:

1. Решение: tools нужны / не нужны (с обоснованием 1-2 строки).
2. Если да — таблица: tool | назначение | вызывается когда | НЕ вызывается когда.
3. JSON-схемы всех tools в одном блоке.

Phase 4 · Evals (test set)

Цель фазы: собрать golden dataset, по которому будем мерить агента до и после изменений.

Состав датасета:

• Happy path (40% кейсов): типичные запросы, ожидаемые ответы.
• Edge cases (40%): пустые входы, очень длинные, на другом языке, с опечатками, противоречивые требования.
• Regression (20%): кейсы из реальных багов / жалоб юзеров. Растёт со временем.

Объём: 10-30 кейсов для MVP. 100+ — для зрелого агента.

Метрики (выбери 3-4 релевантных):

• Accuracy / correctness: доля кейсов, где ответ совпал с эталоном (LLM-as-judge или человек).
• Format compliance: ответ в нужном формате (JSON valid, markdown структура, длина).
• Latency p95: 95-й перцентиль времени ответа.
• Cost per call: средняя стоимость одного вызова.
• Safety pass rate: доля кейсов, где агент НЕ нарушил policy.

Pass criteria (примеры): accuracy ≥ 90%, format 100%, latency p95 ≤ 5s, safety 100%.

Output фазы 4:

1. Eval dataset (JSONL или таблица): id | input | expected_output | category.
2. Scoring rubric: как оцениваем каждую метрику, кто/что судья.
3. Pass criteria: конкретные пороги.

Phase 5 · Safety

Цель фазы: закрыть основные классы рисков до того, как агент увидит реальных юзеров.

Чек-лист:

• Prompt injection: instruction hierarchy в system prompt (системные правила > пользовательский ввод), валидация output'а на признаки утечки инструкций, sanitize user input перед подстановкой в шаблоны.
• PII redaction: определи, что считаем PII (имена? email? телефоны? адреса? id юзеров?). Где redact'им — в логах, в ответах, в передаче в downstream API. Список конкретных полей.
• Forbidden topics: список тем, на которые агент не отвечает (правовые советы, медицина, harmful content). Что говорит вместо ответа — конкретная фраза-отказ.
• Escalation pattern: триггеры передачи человеку (юзер расстроен, тема вне scope, повторные неудачи). Куда передаём — email / Slack / тикет.
• Rate limits: per-user и global. Что показываем при превышении.

Output фазы 5: safety checklist в виде ☐ риск → митигация → как проверим.

Phase 6 · Telemetry

Цель фазы: видеть, что происходит в проде, ДО того как юзер пожалуется.

Что логировать (каждый вызов):

• request_id, user_id (hashed), timestamp, session_id.
• Input (с redact'ом PII) и output (с redact'ом).
• Tool calls: какие, аргументы (sanitized), результат, длительность каждого.
• Latency per step (LLM call, каждый tool, total).
• Token usage (input/output) и cost.
• Errors: тип, message, stack (если применимо).
• User feedback signal: thumbs up/down, явный rerun, abandon mid-conversation.

Куда смотреть:

• Honeycomb / Datadog / OpenTelemetry — для distributed tracing.
• Sentry — для ошибок.
• Custom dashboard (Grafana / Looker) — для бизнес-метрик: DAU, retention, satisfaction.

Alert thresholds (примеры):

• Error rate > 2% за 5 минут → PagerDuty.
• p95 latency > 10s за 15 минут → Slack.
• Cost/day > 1.5× недельной медианы → email владельцу.
• Safety violation triggered → немедленный алерт + лог в audit trail.

Output фазы 6: telemetry plan — таблица событие | поле | sink | alert.

Phase 7 · Deploy

Цель фазы: довести агента до реальных юзеров с возможностью быстрого отката.

Где живёт:

• Slash-command (Claude Code / Claude.ai) — для внутренних команд.
• MCP server — если агент = набор tools для других агентов.
• API endpoint (FastAPI / Hono / Cloudflare Worker) — для интеграций.
• Slack bot / Discord bot / Teams app — для бизнес-юзеров.
• Cron job — для автономной работы по расписанию.

Config:

• Env vars: ANTHROPIC_API_KEY, MODEL, LOG_LEVEL, feature flags.
• Secrets: через secret manager (AWS Secrets Manager / Doppler / 1Password), не в .env в репо.
• Versioning: семвер для system prompt + tools (v1.2.3), логируй в каждом запросе.

Rollout:

• % rollout: 1% → 10% → 50% → 100%, каждый шаг минимум 24 часа.
• Allowlist: сначала команда → power users → все.
• Shadow mode: агент запускается параллельно старому, ответы сравниваются, юзер видит старый.

Rollback plan:

• Кнопка "отключить" — feature flag, переключается за 30 секунд без деплоя.
• Прошлая версия system prompt + tools остаётся в репо (prompts/v1.2.2.md).
• Кто принимает решение об откате и по каким сигналам — записано заранее.

Comms к юзерам:

• Launch post: что появилось, что умеет, чего НЕ умеет, как дать обратную связь.
• Канал поддержки: куда писать баги.
• Changelog: ведётся с первого дня.

Output фазы 7: deploy checklist (☐ конфиг ☐ rollout plan ☐ rollback ☐ monitoring ☐ comms) + текст launch-поста.

Контракт между фазами

Каждая фаза передаёт следующей чек-поинт: что готово, что блокирует, что вынесено в TODO.

Если на фазе N не хватает данных от N-1 — остановись и доделай N-1. Не пиши заглушки, не переноси в TODO.

Формат вывода

Все 7 фаз в одном response, каждая под заголовком ## Phase N · Name. Каждая фаза = минимально полный артефакт, который можно взять и использовать. Длинный output — это нормально и ожидаемо. В конце — секция ## Что готово / Что осталось с прямым перечислением.

Anti-patterns

• ❌ Прыгнуть в Phase 7 (deploy) без Phase 4 (evals) — упадёт у первого юзера, и ты не поймёшь почему.
• ❌ "Универсальный помощник" без узкой persona — будет неотличим от чистого Claude, юзеры не поймут зачем он.
• ❌ 20 tools — agent теряется, выбирает плохо, латенси растёт. Жёсткий потолок: 5-7.
• ❌ Tool descriptions без "когда НЕ вызывать" — модель будет звать tool везде, включая случаи где не надо.
• ❌ Evals только на happy path — regression'ы не ловятся, релизы превращаются в рулетку.
• ❌ Safety "потом, после MVP" — инжекшен прилетит в первый день, и ты будешь чинить в проде.
• ❌ Без telemetry — не узнаешь, почему юзер недоволен, и не сможешь доказать что фикс помог.
• ❌ Deploy без rollback plan — инциденты тушим вручную, downtime растёт, доверие падает.
• ❌ System prompt длиной 300+ строк — модель теряет приоритеты, начинает игнорить часть инструкций.
• ❌ Eval dataset без regression-кейсов — старые баги возвращаются с каждым релизом.
• ❌ Telemetry без alert thresholds — у тебя есть данные, но ты узнаёшь о проблеме от юзера.
• ❌ Rollout сразу на 100% — нет окна заметить деградацию до того, как страдают все.

Deliverable

Готовый production-grade агент:

1. Persona-блок + system prompt (готов копировать в код).
2. JSON-схемы всех tools (готовы зарегистрировать в SDK).
3. Eval dataset + scoring + pass criteria (готов в CI).
4. Safety checklist с конкретными митигациями.
5. Telemetry plan с полями, sink'ами и alert'ами.
6. Deploy checklist с rollout/rollback/comms.
7. Запись решений по каждой фазе — основа для будущих ретроспектив.