62 lines
3.9 KiB
Markdown
62 lines
3.9 KiB
Markdown
# AGENT-PLAN.md — План работ: Агенты + Трекер
|
||
|
||
## Фаза 1: Конфиг агента (agent.json → минимум)
|
||
|
||
### 1.1 Разделение конфигов
|
||
- [ ] **agent.json** — только подключение: `token`, `tracker_url`
|
||
- [ ] **config.json** — внутренняя конфигурация LLM: `api_key`, `model`, `provider`, `prompt` (override)
|
||
- [ ] Picogent `resolveConfig()` — читает оба файла, мержит
|
||
- [ ] Убрать дублирующиеся поля (name, slug, capabilities) из agent.json
|
||
|
||
### 1.2 Трекер: расширить auth_ok
|
||
- [ ] WS `auth_ok` возвращает полный AgentConfig: name, slug, capabilities, model, prompt, chat_listen, task_listen, max_concurrent_tasks
|
||
- [ ] Picogent мержит remote config с локальными override-ами (config.json приоритетнее)
|
||
|
||
### 1.3 Горячее обновление конфига
|
||
- [ ] Новый WS event `config_updated` — трекер → агент при изменении через UI
|
||
- [ ] Picogent обрабатывает event, обновляет runtime config без рестарта
|
||
|
||
### 1.4 Systemd template для мульти-агент
|
||
- [ ] `picogent@.service` — шаблонный unit: `ExecStart=node ... /opt/agents/%i/`
|
||
- [ ] `systemctl start picogent@coder`, `systemctl start picogent@reviewer`
|
||
|
||
---
|
||
|
||
## Фаза 2: Память агента (ТРЕБУЕТ РЕСЕРЧ)
|
||
|
||
### Вопросы для исследования
|
||
- [ ] **Per-project vs shared memory?** — стоит ли разделять память по проектам? Агент работает на нескольких проектах — смешивать или изолировать?
|
||
- [ ] **Структура памяти** — как организовать memory/:
|
||
- `memory/global/` — общие знания, уроки
|
||
- `memory/projects/{slug}/` — контекст конкретного проекта
|
||
- `memory/sessions/` — автокомпакция сессий
|
||
- [ ] **Загрузка контекста** — как агент выбирает какую память загружать? По текущему проекту? По задаче? Всю?
|
||
- [ ] **Размер контекста** — лимиты на bootstrap context (сейчас 15K chars). Как масштабировать при росте памяти?
|
||
- [ ] **Компакция** — автоматическая очистка старой памяти? Суммаризация?
|
||
- [ ] **Shared knowledge** — если два агента работают на одном проекте, должны ли они видеть память друг друга?
|
||
|
||
### Возможные решения
|
||
- **Вариант A:** Flat memory — всё в `memory/`, агент сам разбирается (текущее)
|
||
- **Вариант B:** Per-project dirs — `memory/projects/{slug}/`, загружается по контексту задачи
|
||
- **Вариант C:** Semantic search — агент ищет по памяти через embeddings (тяжёлое решение)
|
||
- **Вариант D:** Project files as memory — документы проекта на трекере = общая память команды
|
||
|
||
---
|
||
|
||
## Фаза 3: UUID-based workspace (отложено)
|
||
|
||
- [ ] Workspace именуется по `member.id` (UUID) вместо slug
|
||
- [ ] Симлинки `agents/coder → agents/{uuid}` для удобства
|
||
- [ ] Переименование slug не ломает workspace
|
||
|
||
---
|
||
|
||
## Решения (принятые)
|
||
|
||
| Решение | Дата |
|
||
|---------|------|
|
||
| agent.json = token + tracker_url, config.json = LLM config | 2026-02-25 |
|
||
| Трекер = source of truth для routing/orchestration | 2026-02-25 |
|
||
| Агент не раскрывает api_key трекеру | 2026-02-25 |
|
||
| Directory mode для мульти-агент (уже работает) | 2026-02-25 |
|