4.8 KiB
4.8 KiB
AGENT-PLAN.md — План работ: Агенты + Трекер
Фаза 1: Конфиг агента (agent.json → минимум)
1.1 Разделение конфигов ✅
- agent.json — только подключение:
token,tracker_url,ws_url,transport,session_id - config.json — LLM:
api_key,model,provider - Picogent
loadAgentConfig()— читает оба файла, мержит (env > config.json > agent.json) - name, slug, capabilities теперь приходят из Tracker (auth.ok)
1.2 Трекер: расширить auth_ok ✅
- WS
auth_okвозвращаетagent_config: model, provider, prompt, chat_listen, task_listen, max_concurrent_tasks, capabilities - AgentConfig model: добавлены
provider,max_concurrent_tasks - Picogent мержит remote config с локальными override-ами
1.3 Горячее обновление конфига ✅
- Новый WS event
config.updated(WSEventType.CONFIG_UPDATED) - Tracker отправляет при PATCH /members/{id} с agent_config
- Picogent обрабатывает event, обновляет runtime model/provider/prompt
1.4 Systemd template для мульти-агент ✅
picogent@.service:ExecStart=node dist/index.js /root/projects/team-board/agents/%i/systemctl start picogent@coder
Фаза 2: Память агента ✅ РЕАЛИЗОВАНО
Структура (двухуровневая, per-project)
agents/{slug}/
AGENT.md # инструкции (статичные)
memory/
agent.md # личные уроки, стиль (грузится ВСЕГДА)
projects/
{project_uuid}/
context.md # архитектура, решения (грузится per-task)
recent.md # последние действия (rolling window, ~20 записей)
Почему UUID, а не slug? Slug проекта может измениться (переименование). UUID — immutable. Память агента не ломается при переименовании проекта.
Загрузка контекста
- Task приходит с
project_id(UUID) - Bootstrap:
AGENT.md+memory/agent.md+memory/projects/{project_uuid}/context.md+recent.md - Итого ~7K chars вместо 15K (экономия ~50%)
- Кросс-проектная инфа — on-demand через MCP-тулзы, НЕ в bootstrap
Компакция
- После завершения задачи: LLM суммаризирует сессию → 3-5 строк → append
recent.md recent.md: rolling window, последние ~20 записей, старые вытесняются- Weekly: LLM ревьюит
recent.md→ обновляетcontext.md(long-term) - Сырые JSONL сессии: удалять через 7 дней (суммаризация уже произошла)
Кросс-проектный доступ
- Агент = member в своём проекте, viewer в связанных
- Viewer = read-only (list_tasks, list_project_files через REST)
- Viewer НЕ получает WS push-события (экономия токенов)
- Три уровня контроля: AGENT.md → MCP-тулзы → API (403)
Shared knowledge
- Project docs (README, ARCHITECTURE) = shared, живут в трекере/репо
- Personal memory = agent-only, не шарится между агентами
- Координация — через project docs или чат, не через чужую память
Фаза 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 |
| Per-project память: agent.md (always) + projects/{uuid}/ (per-task) | 2026-02-25 |
| Папки памяти по UUID проекта (не slug — slug может измениться) | 2026-02-25 |
| Viewer-роль: read-only доступ к чужим проектам | 2026-02-25 |
| Viewer без WS push — только REST pull | 2026-02-25 |
| Shared knowledge через project docs, не через чужую память | 2026-02-25 |