100 советов по созданию личного ИИ-агента: от облачного прототипа до продакшена

Разработчик шесть недель создавал персонального ИИ-агента с нуля — не оболочку чат-бота, а постоянного ассистента, который управляет задачами, отслеживает сделки, читает электронную почту, анализирует бизнес-данные и проактивно выявляет пропущенные моменты. Проект начинался в облаке (Claude Projects с общими файлами памяти, богатыми контекстными окнами, пользовательскими навыками), а затем мигрировал в Claude Code внутри VS Code, что открыло доступ к локальным файлам, git-трекингу, shell-хукам и запланированным безголовым задачам. Миграция заставила решать проблемы, о существовании которых они не знали. Эти 100 советов — дистиллированный результат, при этом 20x максимальное использование Claude сместилось с 100% разработка / 0% реальный мир изначально до 20% / 80% через шесть недель.

Основа и идентичность (1–8)

• Пишите Конституцию, а не системный промпт. Системный промпт перечисляет команды; Конституция объясняет правила. Когда агент сталкивается с крайним случаем, на который нет правила, он рассуждает на основе Конституции, а не угадывает. Это отделяет агентов, которые деградируют изящно, от тех, которые уверенно галлюцинируют.
• Дайте агенту имя, голос и роль. Пример: "Всегда от первого лица. Прямолинейно. Данные прежде эмоций. Без слов-паразитов. Без итоговых резюме." Это устраняет сотни микропринятий решений за сессию и создает единообразие для аудита.
• Разделяйте жесткие правила и руководства по поведению. Жесткие правила в выделенном разделе — никогда не переопределяются. Руководства по поведению адаптируются. Их смешение лишает смысла и то, и другое.
• Глубоко определите своего принципала. Кому служит агент? Что их раздражает? Как они принимают решения? Пример: "Принимает решения на основе данных, а не интуиции. Хочет альтернативы с оценками, а не одну рекомендацию. Ненавидит расплывчатые ответы."
• Постройте Карту возможностей и Карту компонентов отдельно. Карта возможностей: что умеет агент (навыки, интеграции, автоматизации). Карта компонентов: как он построен (файлы, соединения). Смешение создает бесполезный документ после третьего месяца.
• Определите, чем агент НЕ является. "Не суммаризатор. Не машина для согласия. Не поисковик. Не ждет, когда его спросят." Негативные определения предотвращают дрейф к общей полезности.
• Постройте ментальную модель ДУМАТЬ vs. ДЕЛАТЬ. Когда не уверен → ДУМАТЬ (анализировать, черновик, подготовка). Когда ясно → ДЕЛАТЬ (выполнять, писать, отправлять). Никогда не зависать. По умолчанию действовать на уровне наименьшего риска, показывая результат.
• Версионируйте файл идентичности в git. git blame на конфигурации помогает отлаживать регрессии поведения, которые прослеживаются до конкретных правок.

Система памяти (9–18)

• Используйте плоские markdown-файлы для памяти — не базу данных. Читаемые, ищемые через grep, отслеживаемые через git, напрямую загружаемые агентом. Никакого инфраструктурного слоя.
• Разделяйте память по доменам, а не по датам. Файлы вроде entities_people.md, entities_companies.md, entities_deals.md, hypotheses.md, task_queue.md. Один файл = один домен. Хронологические дампы становятся непоисковыми после второй недели.
• Создайте индексный файл MEMORY.md. Единый индекс, перечисляющий каждый файл памяти с однострочным описанием. Агент сначала загружает индекс, затем извлекает конкретные файлы по запросу. Это позволяет предсказуемо использовать контекстное окно.
• Четко различайте "кэш" и "источник истины". Помечайте каждый файл кэша временной меткой last_sync:. Например, локальный deals.md является кэшем CRM; CRM — это SSOT.