Версия: 1.0.0
Дата: 2025-11-10
Статус: Анализ инструментов
1. ДОКУМЕНТЫ
- Спецификации (DESIGN.md)
- Документация проектов (PROJECT.md, ROADMAP.md)
- Код агентов (Python файлы)
- Конфигурация (YAML, JSON)
2. ПРОЕКТЫ
- Создание из шаблонов
- Жизненный цикл (active → archived)
- Связи между компонентами
- Метаданные (версия, дата, автор)
3. АГЕНТЫ
- Регистрация агентов
- Вызов агентов (Task очередь)
- Состояние агентов (контекст)
- Координация между агентами
- Логирование действий
4. ЗНАНИЯ (Knowledge Base)
- Templates библиотека
- Components каталог
- История решений (Git)
- Метрики и аналитика
Текущее решение: Markdown (.md)
Плюсы:
- ✅ Читаемость (человек и машина)
- ✅ Git friendly (text diff работает)
- ✅ Простота (не нужен парсер)
- ✅ Универсальность (GitHub, VS Code поддерживают)
Альтернативы:
- reStructuredText (сложнее)
- AsciiDoc (избыточно)
- LaTeX (для научных документов, не наш случай)
Решение: ✅ Остаёмся на Markdown
Проблема: Нужно генерировать DESIGN.md, PROJECT.md с переменными.
Варианты:
A. Jinja2 (шаблонизатор Python)
pip install jinja2
# Шаблон
template = """
# {{ project_name }} — Спецификация
**Версия:** {{ version }}
**Дата:** {{ date }}
## Описание
{{ description }}
"""
# Использование
from jinja2 import Template
tmpl = Template(template)
result = tmpl.render(
project_name="DocumentAgent",
version="1.0.0",
date="2025-11-10",
description="Агент документации"
)
Плюсы:
- ✅ Мощный (циклы, условия)
- ✅ Широко используется
- ✅ Поддержка наследования шаблонов
Минусы:
- ⚠️ Нужна установка библиотеки
B. f-strings Python (встроенные)
# Простые случаи
doc = f"""
# {project_name} — Спецификация
**Версия:** {version}
"""
Плюсы:
- ✅ Встроено в Python
- ✅ Просто для базовых случаев
Минусы:
- ⚠️ Нет логики (циклов, условий)
- ⚠️ Сложно для больших шаблонов
C. Python string.Template (встроенный)
from string import Template
tmpl = Template("# $project_name — Спецификация")
result = tmpl.substitute(project_name="DocumentAgent")
Плюсы:
- ✅ Встроено
- ✅ Безопаснее f-strings
Минусы:
- ⚠️ Очень ограниченный функционал
Рекомендация:
- Фаза 0-1: f-strings (простота)
- Фаза 2+: Jinja2 (когда шаблоны усложнятся)
Проблема: Нужно читать существующие DESIGN.md, извлекать структуру.
Варианты:
A. Python-Markdown
pip install markdown
import markdown
md = markdown.Markdown()
html = md.convert("# Header\n\nText")
# Результат: HTML
Плюсы:
- ✅ Конвертация Markdown → HTML
- ✅ Расширяемость
Минусы:
- ⚠️ Нам не нужен HTML, нужна структура
B. mistune (быстрый парсер)
pip install mistune
import mistune
ast = mistune.create_markdown(renderer=None)
tree = ast("# Header\n\nText")
# Результат: AST (Abstract Syntax Tree)
Плюсы:
- ✅ Быстрый
- ✅ Возвращает AST (можно обрабатывать)
Минусы:
- ⚠️ API сложноват
C. Регулярные выражения (простое извлечение)
import re
# Извлечь заголовки
headers = re.findall(r'^#+\s+(.+)$', markdown_text, re.MULTILINE)
# Извлечь метаданные
version = re.search(r'\*\*Версия:\*\*\s+(.+)', markdown_text)
Плюсы:
- ✅ Встроено в Python
- ✅ Достаточно для простых случаев
Минусы:
- ⚠️ Не подходит для сложной структуры
Рекомендация:
- Фаза 0-1: Регулярные выражения (для метаданных)
- Фаза 2+: mistune (если нужен полный парсинг)
Проблема: Проверить что DESIGN.md содержит все обязательные разделы.
Варианты:
A. JSON Schema (для YAML frontmatter)
pip install jsonschema
schema = {
"type": "object",
"properties": {
"version": {"type": "string"},
"status": {"enum": ["draft", "approved"]}
},
"required": ["version", "status"]
}
from jsonschema import validate
validate(instance=data, schema=schema)
Плюсы:
- ✅ Строгая валидация
- ✅ Стандарт
Минусы:
- ⚠️ Только для YAML/JSON, не для Markdown
B. Pydantic (Python модели)
pip install pydantic
from pydantic import BaseModel
from datetime import datetime
class DesignSpec(BaseModel):
version: str
date: datetime
status: str
# Валидация
spec = DesignSpec(
version="1.0.0",
date="2025-11-10",
status="draft"
)
Плюсы:
- ✅ Type safety
- ✅ Автоматическая конвертация типов
- ✅ Хорошие сообщения об ошибках
Минусы:
- ⚠️ Нужна библиотека
C. Простые проверки (Python)
def validate_design_md(content):
required_sections = [
"# ОПРЕДЕЛЕНИЕ",
"# КОНТЕКСТ",
"# АНАЛИЗ"
]
for section in required_sections:
if section not in content:
raise ValueError(f"Missing section: {section}")
return True
Плюсы:
- ✅ Просто
- ✅ Контроль
Минусы:
- ⚠️ Хрупкое (зависит от форматирования)
Рекомендация:
- Фаза 0-1: Простые проверки
- Фаза 2+: Pydantic (если нужна строгая типизация)
Проблема: Скопировать структуру из templates/ в projects/, заменить переменные.
Варианты:
A. shutil + os (встроенные Python)
import shutil
import os
# Копирование директории
shutil.copytree(
'templates/streamlit-mvp-v1/structure',
'projects/myapp'
)
# Замена переменных в файлах
for root, dirs, files in os.walk('projects/myapp'):
for file in files:
if file.endswith('.md') or file.endswith('.py'):
path = os.path.join(root, file)
with open(path, 'r') as f:
content = f.read()
# Замена
content = content.replace('{{PROJECT_NAME}}', 'myapp')
with open(path, 'w') as f:
f.write(content)
Плюсы:
- ✅ Встроено в Python
- ✅ Простота
Минусы:
- ⚠️ Ручная обработка каждого файла
- ⚠️ Нет продвинутой логики
B. cookiecutter (генератор проектов)
pip install cookiecutter
# Структура шаблона с {{cookiecutter.project_name}}
cookiecutter templates/streamlit-mvp-v1/
# Интерактивно спрашивает переменные
Плюсы:
- ✅ Популярный инструмент
- ✅ Поддержка Jinja2
- ✅ Hooks (pre/post генерации)
Минусы:
- ⚠️ Интерактивный (не для автоматизации)
- ⚠️ Нужна библиотека
C. Свой ProjectGenerator класс
class ProjectGenerator:
def __init__(self, workspace):
self.workspace = workspace
def create_from_template(self, template_name, project_name, variables):
template_path = f"{self.workspace}/templates/{template_name}"
project_path = f"{self.workspace}/projects/{project_name}"
# Копирование
shutil.copytree(template_path, project_path)
# Замена переменных через Jinja2
self._replace_variables(project_path, variables)
return project_path
Плюсы:
- ✅ Полный контроль
- ✅ Гибкость
- ✅ Интеграция с агентами
Минусы:
- ⚠️ Нужно писать сами
Рекомендация: ✅ Свой ProjectGenerator (максимальный контроль)
Проблема: Хранить метаданные (версия, дата создания, статус, шаблон).
Варианты:
A. YAML frontmatter (в PROJECT.md)
---
version: 1.0.0
created_at: 2025-11-10
template: streamlit-mvp-v1
status: active
---
# Проект Marketplace
Описание...
Библиотека: python-frontmatter
pip install python-frontmatter
import frontmatter
# Чтение
with open('PROJECT.md') as f:
post = frontmatter.load(f)
print(post['version']) # 1.0.0
print(post.content) # Markdown без frontmatter
Плюсы:
- ✅ Всё в одном файле
- ✅ Git friendly
- ✅ Читаемо
Минусы:
- ⚠️ Нужна библиотека
B. Отдельный project.yaml
# projects/marketplace/project.yaml
name: marketplace
version: 1.0.0
created_at: 2025-11-10
template: streamlit-mvp-v1
status: active
Плюсы:
- ✅ Просто парсить (PyYAML)
- ✅ Можно расширять
Минусы:
- ⚠️ Отдельный файл (может рассинхронизироваться)
C. SQLite база
import sqlite3
conn = sqlite3.connect('platform/.claude/projects.db')
CREATE TABLE projects (
name TEXT PRIMARY KEY,
version TEXT,
created_at TIMESTAMP,
template TEXT,
status TEXT
)
Плюсы:
- ✅ Запросы (SQL)
- ✅ Индексы (быстро)
- ✅ Транзакции
Минусы:
- ⚠️ Не Git friendly
- ⚠️ Отдельное хранилище (риск рассинхронизации)
Рекомендация:
- Фаза 0-2: YAML frontmatter (простота + Git)
- Фаза 3+: SQLite (если нужны сложные запросы)
Проблема: Управление статусами (active → archived → deprecated).
Варианты:
A. Статус в метаданных (YAML)
status: active # active | archived | deprecated
B. Директории по статусам
projects/
├── active/
│ └── marketplace/
├── archived/
│ └── old-project/
└── deprecated/
└── legacy-app/
Плюсы:
- ✅ Визуальная ясность
- ✅ Просто перемещать
Минусы:
- ⚠️ Git history теряется при перемещении
C. State Machine (Python)
from transitions import Machine
class Project:
states = ['draft', 'active', 'archived', 'deprecated']
transitions = [
{'trigger': 'activate', 'source': 'draft', 'dest': 'active'},
{'trigger': 'archive', 'source': 'active', 'dest': 'archived'},
{'trigger': 'deprecate', 'source': '*', 'dest': 'deprecated'},
]
Плюсы:
- ✅ Контроль переходов
- ✅ Валидация
Минусы:
- ⚠️ Усложнение
Рекомендация: ✅ Статус в YAML (простота)
Проблема: Агенты должны регистрироваться в системе.
Варианты:
A. AgentAPI (реестр в памяти)
class AgentAPI:
def __init__(self):
self.agents = {} # name -> agent_instance
def register_agent(self, agent):
self.agents[agent.name] = agent
print(f"✅ Registered: {agent.name}")
def call_agent(self, name, task):
return self.agents[name].execute(task)
Плюсы:
- ✅ Простота
- ✅ Быстро
Минусы:
- ⚠️ Только в памяти (не персистентно)
- ⚠️ При перезапуске теряется
B. Конфигурационный файл (agents.yaml)
# platform/config/agents.yaml
agents:
DocumentAgent:
enabled: true
module: platform.agents.document_agent
class: DocumentAgent
CodeAgent:
enabled: true
module: platform.agents.code_agent
class: CodeAgent
Динамическая загрузка:
import importlib
def load_agents_from_config():
with open('platform/config/agents.yaml') as f:
config = yaml.safe_load(f)
agents = {}
for name, cfg in config['agents'].items():
if cfg['enabled']:
module = importlib.import_module(cfg['module'])
agent_class = getattr(module, cfg['class'])
agents[name] = agent_class(workspace)
return agents
Плюсы:
- ✅ Конфигурация вне кода
- ✅ Легко включать/выключать агентов
- ✅ Персистентность
Минусы:
- ⚠️ Сложнее
Рекомендация: ✅ Конфигурационный файл (гибкость)
Проблема: CentralAgent вызывает других агентов, нужна очередь задач.
Варианты:
A. Синхронные вызовы (простые)
# CentralAgent
result1 = api.call_agent("DocumentAgent", task1)
result2 = api.call_agent("CodeAgent", task2)
result3 = api.call_agent("GitAgent", task3)
Плюсы:
- ✅ Просто
- ✅ Понятный поток
Минусы:
- ⚠️ Медленно (последовательное выполнение)
- ⚠️ Блокирующие вызовы
B. Асинхронные вызовы (asyncio)
import asyncio
async def workflow():
task1 = api.call_agent_async("DocumentAgent", task1)
task2 = api.call_agent_async("CodeAgent", task2)
# Параллельное выполнение
results = await asyncio.gather(task1, task2)
Плюсы:
- ✅ Быстрее (параллелизм)
- ✅ Эффективнее (I/O bound задачи)
Минусы:
- ⚠️ Сложнее код
- ⚠️ Отладка труднее
C. Task Queue (Celery / RQ)
# С Celery
from celery import Celery
app = Celery('cifra', broker='redis://localhost:6379')
@app.task
def run_agent(agent_name, task):
return api.call_agent(agent_name, task)
# Использование
result = run_agent.delay("DocumentAgent", task)
result.get() # Ждём результата
Плюсы:
- ✅ Распределённое выполнение
- ✅ Retry механизм
- ✅ Мониторинг (Flower)
Минусы:
- ⚠️ Нужен Redis/RabbitMQ
- ⚠️ Сложность инфраструктуры
Рекомендация:
- Фаза 0-2: Синхронные вызовы (простота)
- Фаза 3: asyncio (параллелизм)
- Фаза 4+: Celery (если нужно распределение)
Проблема: Агенты имеют контекст (context: dict), нужно сохранять между вызовами.
Варианты:
A. В памяти (BaseAgent.context)
class BaseAgent:
def __init__(self):
self.context = {} # В памяти
Плюсы:
- ✅ Быстро
- ✅ Просто
Минусы:
- ⚠️ Теряется при перезапуске
B. Файлы YAML
# platform/.claude/agents/DocumentAgent_context.yaml
last_project: marketplace
templates_used:
- streamlit-mvp-v1
documents_created: 15
Плюсы:
- ✅ Персистентность
- ✅ Git friendly
- ✅ Читаемость
Минусы:
- ⚠️ Медленнее (I/O)
C. SQLite
CREATE TABLE agent_context (
agent_name TEXT PRIMARY KEY,
context JSON,
updated_at TIMESTAMP
)
Плюсы:
- ✅ Быстрые запросы
- ✅ Транзакции
Минусы:
- ⚠️ Не Git friendly
Рекомендация: ✅ YAML файлы (персистентность + Git)
Проблема: Нужно видеть что делали агенты (для отладки и аналитики).
Варианты:
A. Python logging
import logging
logging.basicConfig(
level=logging.INFO,
format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
handlers=[
logging.FileHandler('platform/.claude/agents.log'),
logging.StreamHandler()
]
)
logger = logging.getLogger('DocumentAgent')
logger.info("Created PROJECT.md for marketplace")
Плюсы:
- ✅ Встроено в Python
- ✅ Уровни (DEBUG, INFO, WARNING, ERROR)
- ✅ Форматирование
Минусы:
- ⚠️ Простой текст (сложно парсить)
B. Structured logging (structlog)
pip install structlog
import structlog
log = structlog.get_logger()
log.info(
"document_created",
agent="DocumentAgent",
project="marketplace",
file="PROJECT.md",
duration=1.5
)
# Вывод: JSON
# {"event": "document_created", "agent": "DocumentAgent", ...}
Плюсы:
- ✅ Структурированные логи (JSON)
- ✅ Легко парсить и анализировать
- ✅ Интеграция с аналитикой
Минусы:
- ⚠️ Нужна библиотека
C. Session журналы (текущее решение)
# platform/.claude/session-2025-11-10.md
## 14:30 - DocumentAgent
- Создан PROJECT.md для marketplace
- Использован шаблон: streamlit-mvp-v1
- Время: 1.5s
Плюсы:
- ✅ Читаемо для человека
- ✅ Git friendly
Минусы:
- ⚠️ Сложно парсить программно
Рекомендация:
- Фаза 0-1: Python logging (встроено)
- Фаза 2+: structlog (для аналитики)
Проблема: Cascade Search нужно быстро находить компоненты.
Варианты:
A. Файловый каталог (catalog.yaml)
# components/catalog.yaml
formatters:
- name: format_price
path: components/shared/lib/formatters.py
description: "Форматирование цены в рубли"
usage_count: 45
tags: [formatting, price, currency]
validators:
- name: validate_inn
path: components/shared/lib/validators.py
description: "Валидация ИНН"
usage_count: 23
tags: [validation, inn, business]
Поиск:
import yaml
with open('components/catalog.yaml') as f:
catalog = yaml.safe_load(f)
# Поиск по тегам
results = [c for c in catalog['formatters'] if 'price' in c['tags']]
Плюсы:
- ✅ Просто
- ✅ Git friendly
- ✅ Читаемо
Минусы:
- ⚠️ Линейный поиск (медленно для 1000+ компонентов)
B. SQLite FTS (Full-Text Search)
CREATE VIRTUAL TABLE components_fts USING fts5(
name,
path,
description,
tags
);
-- Поиск
SELECT * FROM components_fts WHERE components_fts MATCH 'price';
Плюсы:
- ✅ Быстрый поиск
- ✅ Полнотекстовый поиск
- ✅ Ranked results
Минусы:
- ⚠️ Отдельная БД (не Git friendly)
C. Whoosh (Python полнотекстовый поиск)
pip install whoosh
from whoosh.index import create_in
from whoosh.fields import Schema, TEXT, ID
schema = Schema(
name=ID(stored=True),
path=TEXT(stored=True),
description=TEXT,
tags=TEXT
)
# Индексация
ix = create_in("indexdir", schema)
writer = ix.writer()
writer.add_document(
name="format_price",
path="components/shared/lib/formatters.py",
description="Форматирование цены",
tags="formatting price currency"
)
writer.commit()
# Поиск
from whoosh.qparser import QueryParser
with ix.searcher() as searcher:
query = QueryParser("tags", ix.schema).parse("price")
results = searcher.search(query)
Плюсы:
- ✅ Быстрый поиск
- ✅ Полнотекстовый
- ✅ Python native
Минусы:
- ⚠️ Нужна библиотека
- ⚠️ Индекс отдельно от Git
Рекомендация:
- Фаза 0-2: YAML catalog (простота)
- Фаза 3+: Whoosh (если компонентов >100)
Проблема: Cascade Search по ключевым словам не всегда находит релевантное.
Пример:
- Запрос: "нужно форматировать деньги"
- Существующий компонент: "format_price" (нет слова "деньги")
- Обычный поиск: НЕ НАЙДЁТ
Решение: Embeddings + Vector Search
Варианты:
A. OpenAI Embeddings + FAISS
pip install openai faiss-cpu
import openai
import faiss
import numpy as np
# 1. Создать embeddings для всех компонентов
descriptions = [
"Форматирование цены в рубли",
"Валидация ИНН",
# ...
]
embeddings = []
for desc in descriptions:
response = openai.Embedding.create(
input=desc,
model="text-embedding-ada-002"
)
embeddings.append(response['data'][0]['embedding'])
embeddings = np.array(embeddings)
# 2. Создать FAISS индекс
dimension = embeddings.shape[1] # 1536 для ada-002
index = faiss.IndexFlatL2(dimension)
index.add(embeddings)
# 3. Поиск
query = "нужно форматировать деньги"
query_embedding = openai.Embedding.create(
input=query,
model="text-embedding-ada-002"
)['data'][0]['embedding']
distances, indices = index.search(
np.array([query_embedding]),
k=5 # топ-5 результатов
)
# indices[0] содержит индексы наиболее похожих компонентов
Плюсы:
- ✅ Находит семантически похожие (не только по ключевым словам)
- ✅ ОЧЕНЬ точно
Минусы:
- ⚠️ Стоимость (OpenAI Embeddings API)
- ⚠️ Нужна библиотека (FAISS)
- ⚠️ Сложность
B. Sentence Transformers (локальные embeddings)
pip install sentence-transformers
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
# Embeddings
embeddings = model.encode(descriptions)
# Поиск (cosine similarity)
from sklearn.metrics.pairwise import cosine_similarity
query_embedding = model.encode(["нужно форматировать деньги"])
similarities = cosine_similarity(query_embedding, embeddings)
# Топ-5
top_indices = similarities[0].argsort()[-5:][::-1]
Плюсы:
- ✅ Локально (бесплатно)
- ✅ Быстро после загрузки модели
Минусы:
- ⚠️ Нужна библиотека + модель (~500MB)
- ⚠️ Менее точно чем OpenAI
Рекомендация:
- Фаза 0-3: Простой поиск (ключевые слова)
- Фаза 4+: Semantic Search (если компонентов >500)
Проблема: Git история — это знания (что было сделано, почему).
Инструменты:
A. GitPython (работа с Git из Python)
pip install gitpython
from git import Repo
repo = Repo('/opt/claude-workspace')
# История коммитов
commits = list(repo.iter_commits('master', max_count=100))
for commit in commits:
print(f"{commit.hexsha[:7]} - {commit.message}")
# Поиск в истории
commits_with_agent = [
c for c in commits
if 'DocumentAgent' in c.message
]
# Diff между версиями
diff = repo.git.diff('HEAD~1', 'HEAD')
Плюсы:
- ✅ Полный доступ к Git из Python
- ✅ Анализ истории
Минусы:
- ⚠️ Нужна библиотека
B. git log через subprocess
import subprocess
# История
result = subprocess.run(
['git', 'log', '--oneline', '-10'],
capture_output=True,
text=True
)
print(result.stdout)
Плюсы:
- ✅ Встроено (subprocess)
- ✅ Просто
Минусы:
- ⚠️ Парсинг текста
Рекомендация: ✅ GitPython (удобнее для анализа)
| Категория | Задача | Фаза 0-1 | Фаза 2+ | Фаза 3+ |
|---|---|---|---|---|
| Документы | Шаблонизация | f-strings | Jinja2 | Jinja2 |
| Парсинг | regex | mistune | mistune | |
| Валидация | Простые проверки | Pydantic | Pydantic | |
| Проекты | Создание | shutil | ProjectGenerator | ProjectGenerator |
| Метаданные | YAML frontmatter | YAML | SQLite | |
| Статусы | YAML | YAML | State Machine | |
| Агенты | Регистрация | AgentAPI (память) | agents.yaml | agents.yaml |
| Координация | Синхронные вызовы | asyncio | Celery | |
| Состояние | В памяти | YAML файлы | YAML + SQLite | |
| Логирование | Python logging | structlog | structlog | |
| Знания | Индексация | YAML catalog | Whoosh | Whoosh |
| Semantic Search | - | - | Sentence Transformers | |
| Git анализ | subprocess | GitPython | GitPython |
Что устанавливаем:
# Обязательно
pip install anthropic # Claude API
pip install pyyaml # Конфигурация
# Опционально (полезно)
pip install python-frontmatter # Метаданные в Markdown
pip install pytest # Тестирование
pip install click # CLI
Что НЕ нужно сразу:
- ❌ Jinja2 (пока f-strings)
- ❌ SQLite (пока YAML)
- ❌ Celery (пока синхронно)
- ❌ Whoosh (пока простой каталог)
- ❌ Semantic Search (рано)
Документы:
- Markdown
- f-strings (шаблоны)
- regex (парсинг метаданных)
Проекты:
- shutil + os (копирование)
- YAML frontmatter (метаданные)
- Статус в YAML
Агенты:
- AgentAPI (реестр в памяти)
- agents.yaml (конфигурация)
- Синхронные вызовы
- Python logging
- YAML (состояние агентов)
Знания:
- YAML catalog
- Git (через subprocess или GitPython)
- Простой поиск (линейный)
Фаза 2:
- Jinja2 (шаблоны)
- Pydantic (валидация)
- structlog (логирование)
- GitPython (анализ истории)
Фаза 3:
- asyncio (параллелизм)
- Whoosh (полнотекстовый поиск)
- SQLite (метрики)
Фаза 4:
- Celery (распределённое выполнение)
- Semantic Search (Sentence Transformers)
- State Machine (сложные переходы)
Q1: Согласны с минимальным стеком (Фаза 0)?
- anthropic, pyyaml, python-frontmatter, pytest, click
Q2: Нужно ли сразу GitPython?
- Или пока через subprocess?
Q3: Semantic Search добавлять сразу?
- Или подождать пока компонентов наберётся?
Q4: Какие инструменты вы бы добавили?
- Что я упустил?
Q5: Начинаем с этим стеком?
- Или ещё что-то нужно обсудить?
Версия: 1.0.0
Дата: 2025-11-10
Статус: Готов к обсуждению