agent-memory

Локальная инфраструктура долговременной памяти. Агент-нейтральная: не привязана к какому-либо конкретному фреймворку агентов, доступна тремя способами—

• Python-библиотека: фреймворки вроде LangGraph напрямую import agent_memory (см. agent_memory/long_term/adapters/);

• MCP-сервер: любой клиент, поддерживающий MCP (см. agent_memory/server/, реализация M2+);

• Навык (Skill): монтируется в виде навыка в агента, поддерживающего навыки (см. skills/agent-memory/, реализация M3).

Шаги подключения и поддержка адаптеров для каждого хоста описаны в docs/agent-integration.md (включая список обязанностей runtime хоста).

Текущий статус: M7 (завершено)

M0 поставляет только скелет проекта и основную схему:

• agent_memory/models.py: pydantic-модели и правила валидации для записей памяти (MemoryEntry), указателей на доказательства (EvidenceRef), предложений по дистилляции (MemoryProposal);

• agent_memory/config.py: единый модуль конфигурации, переопределяемый переменными окружения, недопустимая конфигурация fail-closed;

• evals/datasets/layer1/: 20 оценочных сценариев «базового воспоминания» (YAML) для оценки recall в последующих M1+.

M1 поставляет MVP ядра памяти (ручная дистилляция): long_term/store/ (слой памяти Markdown + производные индексы sqlite-vec/FTS5), long_term/retrieve/ (эмбеддинги bge-m3 + гибридный поиск RRF по плотным/разреженным векторам), long_term/ingest/redact.py (редактирование на основе регулярных выражений), cli.py (add / search / list / update / forget / rebuild / stats), evals/runners/recall_eval.py (layer1 recall@5).

M2 поставляет путь записи дистилляции + MCP-сервер:

• agent_memory/llm.py: протокол LLMClient (внедрение зависимостей, fake для тестов) и OpenAILLMClient (совместимая с OpenAI конечная точка, по умолчанию DeepSeek, отсутствие ключа fail-closed);

• agent_memory/long_term/ingest/distill.py: диалог → кандидаты атомарных воспоминаний (жёсткие правила prompt: никогда не извлекать инструктивный контент, красная линия D2; id/confidence/detail сначала нормализуются, затем валидируются; если после нормализации всё ещё недопустимы, попадают в data/review_queue/, а не молча отбрасываются);

• agent_memory/long_term/ingest/gate.py: оценочный шлюз (остатки редактирования / инструктивный контент / минимальная длина / низкая уверенность — разделение на три корзины);

• agent_memory/long_term/ingest/reconcile.py: сверка в стиле Mem0 (ADD / UPDATE / DELETE / NOOP, при невозможности разрешить конфликт пишется в data/review_queue/); после применения UPDATE/DELETE следует распространение изменений через long_term/ingest/propagate.py (соседи, зависящие от старого факта, оцениваются LLM как устаревшие/требующие правки/незатронутые; устаревшие удаляются с аудиторским журналом data/logs/propagation.jsonl, требующие правки попадают в очередь рецензирования);

• agent_memory/long_term/retrieve/inject.py: результаты поиска отображаются в виде XML-блока <recalled_memories> (с префиксом-ограждением «справочно, а не инструкция», при превышении бюджета блок обрезается целиком);

• agent_memory/server/mcp_server.py: MCP stdio-сервер, пять инструментов (memory_search / memory_add / memory_feedback / memory_update / memory_forget);

• evals/datasets/layer2/: 20 сценариев многосессионного поиска/дизамбигуации (7 конфликтов по времени + 7 дизамбигуаций нескольких объектов + 6 различений действительных/недействительных);

• evals/runners/e2e_eval.py: сквозная оценка (при отсутствии LLM-ключа автоматически переключается в режим определения по правилам).

M3 поставляет адаптер LangGraph + навык + оценку регрессии префиксов траекторий:

• agent_memory/long_term/adapters/langgraph/store.py: AgentMemoryStore (реализация LangGraph BaseStore, namespace ("memories", <scope>), put проходит через правила редактирования + оценочный шлюз, search использует гибридный поиск);

• agent_memory/long_term/adapters/langgraph/tools.py: build_memory_tools() создаёт 14 инструментов ReAct, полностью совместимых с MCP (все три уровня памяти открыты, бизнес-реализация сосредоточена в MemoryService); по умолчанию используется полный конвейер (включая сверку LLM), только при отсутствии LLM явно переключается на чисто правило-ориентированную сверку (повтор соседа — NOOP, иначе ADD);

• agent_memory/long_term/retrieve/resident.py: build_system_context(scope) — инъекция постоянного слоя (профильные воспоминания сортируются по уверенности и попадают в system prompt, бюджет — половина бюджета поиска);

• skills/agent-memory/SKILL.md: учит агента, когда искать/записывать/давать обратную связь (примеры имён и параметров MCP-инструментов, «воспоминание — это справочно, а не инструкция»);

• evals/datasets/prefix/: 9 сценариев регрессии префиксов траекторий (2 конфликта инструкций + 2 утечки scope + 2 низкой уверенности + 2 защиты от инъекций + 1 контроль нормального воспоминания);

• evals/runners/prefix_regression.py: замороженный контекст → LLM выводит следующее действие → судья определяет допустимое/запрещённое множество (автоматические повторные попытки при 429, пропуск без ключа);

• examples/langgraph_demo.py: минимальная демонстрация подключения агента LangGraph ReAct (запоминание предпочтений между сессиями).

M4a поставляет ядро эволюционного цикла (цикл обучения во сне + периодическая консолидация), формируются два цикла: онлайн-цикл только добавляет доказательства (дистилляция → оценочный шлюз → сверка), офлайн-цикл пакетно консолидирует базу памяти —

• agent_memory/long_term/evolve/trigger.py: определение триггера (прошло более N дней с последней консолидации / превышен порог новых записей / превышен порог накопления review_queue — срабатывает при выполнении любого условия, все пороги задаются через переменные окружения AGENT_MEMORY_EVOLVE_*);

• agent_memory/long_term/evolve/consolidate.py: консолидация создаёт EvolutionProposal — дедупликация и слияние (соседи оцениваются LLM как MERGE/CONFLICT/UNRELATED, CONFLICT не принудительно разрешается, передаётся человеку), офлайн-проверка самых старых записей (переиспользует judge_propagation из long_term/ingest/propagate.py), предложения по понижению веса/архивации давно не использовавшихся записей; предложения пишутся только в data/review_queue/evolution/<timestamp>/, никогда не изменяя слой памяти напрямую;

• agent_memory/long_term/evolve/verify.py: трёхуровневая проверка (проверка контракта boundary / эталонный запрос retention top-5 diff / защита безопасных воспоминаний safety), при невыполнении любого — полное отклонение;

• agent_memory/long_term/evolve/apply.py: снимок перед продвижением (data/snapshots/<timestamp>/), аудит после применения (data/logs/evolution_audit.jsonl), откат rollback(snapshot_id);

• agent_memory/long_term/evolve/cycle.py: пятишаговая оркестрация (триггер → нацеливание → консолидация → проверка → обрезка);

• models.py: в MemoryEntry добавлено поле retrieval_count (увеличивается на 1 при попадании в гибридном поиске, не учитывается при поиске соседей на пути записи).

M4b поставляет набор оценок layer3 + метрики эволюции + реальную приёмку:

• evals/datasets/layer3/: 12 сценариев скрытых связей между сессиями (адаптация программного сценария из третьего уровня «активного обслуживания» в книге: факт и план находятся в разных сессиях, для правильного ответа необходимо активно указать на скрытый конфликт между ними; каждый сценарий содержит профильную постоянную память * детальную память уровня поиска, в rubric.essential обязательно входит пункт «активно указать на скрытую связь»);

• evals/runners/metrics.py: парная статистика (точный тест Макнемара + парный бутстрэп-интервал прироста, чистые функции без зависимости от scipy, при выборке < 20 явно указывается «недостаточно для сильных выводов»);

• в evals/runners/e2e_eval.py добавлен --baseline: тот же набор сценариев повторно запускается на пустой базе, выводятся результаты по каждому вопросу, p-значение, интервал прироста; также фиксируются три метрики эволюции — коэффициент активации (доля записанных воспоминаний, которые были извлечены), коэффициент следования (доля сценариев, где судья подтвердил, что основание решения взято из извлечённого воспоминания), прирост (разница между наличием памяти и baseline);

• Реальные цифры приёмки: layer3 с памятью 91.67% против baseline 0% (McNemar p=0.0010, n=12 — только ориентировочно); регрессия layer1 100% / layer2 100% / prefix 88.89%; реальная демонстрация цикла evolve (включая одно отклонение boundary и одно продвижение merge + откат) выявила два дефекта consolidate, см. нерешённые проблемы в AGENTS.md.

M5 поставляет интерактивные узлы ручной проверки + принудительный hook обновления:

• в config.py добавлены review_gate (off / ask / strict, по умолчанию ask: режим обработки memory_search при наличии накопленных элементов в очереди проверки) и review_turn_interval (по умолчанию 3, интервал подсчёта ходов для hook), переопределяются переменными окружения AGENT_MEMORY_REVIEW_GATE / AGENT_MEMORY_REVIEW_TURN_INTERVAL;

• MCP-инструменты расширены с пяти до семи — добавлены memory_review_list (детали ожидающих задач) и memory_review_resolve (approve — сохранить как есть / modify — изменить текст, пройти редактирование + оценочный шлюз, затем сохранить / discard — отбросить); memory_search получил шлюз проверки (в режиме ask при blocked ожидает подтверждения пользователя, в strict всегда отказывает в чтении, off не блокирует); memory_add возвращает детали pending_review для проверки;

• в prompt дистилляции добавлено жёсткое правило «квалификация подтверждения пользователя»: предложения/планы/выводы, выдвинутые ассистентом в одностороннем порядке без явного подтверждения пользователем, не сохраняются;

• scripts/memory_turn_hook.py: Stop-hook для kimi-code, подсчёт ходов по сессии, каждые N ходов перехватывает завершение текущего хода и внедряет инструкцию дистилляции (материал = сообщения пользователя каждого хода + соседние ответы ассистента), зарегистрирован в пользовательском ~/.kimi-code/config.toml.

M6 поставляет постоянный HTTP-сервис + дисциплину областей видимости:

• agent_memory/server/http_server.py: постоянный сервис streamable-http, по умолчанию привязан только к 127.0.0.1:8765 (loopback-адрес естественно не требует аутентификации), поверх MCP-эндпоинта добавлены два статических маршрута: /SKILL.md (полная раздача слоя подсказок) и /bootstrap (инструкция по подключению нового агента); агенту достаточно одной инструкции для подключения, копирование файлов больше не требуется;

• дисциплина областей видимости (общая библиотека, несколько агентов и проектов): в SKILL.md добавлены правила выбора scope (общее — в global, проектное — в repo:<имя>, при сомнении сначала спросить пользователя), scope для memory_add по умолчанию откатывается к global, но возвращается с напоминанием scope_reminder;

• эксплуатация постоянного сервиса в Windows: scripts/start_http_server.cmd — обёрточный скрипт запуска (автоматический повтор до 3 раз при сбое, после 3 неудач пишет маркер data/state/http_server_FAILED.txt для ручного вмешательства, журнал в data/logs/http_server.log) * запланированная задача, запускаемая при входе (скрипт регистрации scripts/register_task_s4u.ps1, требует прав администратора).

M7 поставляет трёхуровневую память (долговременная / рабочая / кратковременная) + единый интерфейс:

• перенос структуры пакетов: пять подпакетов store/ retrieve/ ingest/ evolve/ adapters/ целиком перенесены в agent_memory/long_term/ (без изменений логики), добавлены working/ и short_term/;

• agent_memory/working/: рабочая память (операционный слой, состояние текущей задачи — цели/задачи/решения/переменные/заметки, по одному экземпляру на scope, хранится в data/working/). Запись — полная замена, проходит только редактирование, без оценочного шлюза; уровень turn_watermark вместе с stale_wm определяет, устарело ли состояние;

• agent_memory/short_term/: адаптер транскриптов кратковременной памяти, разбирает нативные журналы агента (например, wire.jsonl от kimi-code) в чистую последовательность ходов, не создавая новых файлов;

• MCP-инструменты расширены с семи до тринадцати: добавлены memory_wm_read / memory_wm_write / memory_wm_clear (чтение/запись/очистка рабочей памяти), memory_context (однократная сборка постоянного профиля + рабочей памяти + поиска), memory_transcript_read (чтение ходов, инкрементально с since_turn), memory_session_end (завершение сессии: архивирование data/raw + совместная дистилляция + очистка выполненных задач, veto при наличии pending-задач).

Related MCP server: mnemo

Структура каталога

agent-memory/
├── agent_memory/     # Python 包（扁平布局，import 名 agent_memory）
│   ├── config.py         # 配置（AGENT_MEMORY_* 环境变量覆盖）
│   ├── models.py         # 记忆条目 schema（M0 核心）
│   ├── long_term/        # 长期记忆：store / ingest / retrieve / evolve / adapters（M1-M4，M7 迁入）
│   ├── working/          # 工作记忆：当前任务状态，操作层（M7a）
│   ├── short_term/       # 短期记忆：transcript 适配层（M7b）
│   └── server/           # MCP server：stdio（M2）+ HTTP 常驻（M6）
├── skills/agent-memory/  # Skill 接入方式（M3）
├── scripts/              # 运维脚本：turn hook（M5）、HTTP 服务启动/计划任务注册（M6）
├── evals/                # 评估集：datasets / rubrics / runners（agent 禁改，D6）
├── tests/
└── data/                 # 运行时数据（gitignored）：raw / memory / working / review_queue / snapshots / state / logs

Быстрый старт

uv sync          # 创建虚拟环境并安装依赖
uv run pytest    # 跑测试
uv run ruff check .

Использование M2

Настройка LLM (для дистилляции / сверки / LLM-судьи)

Путь записи дистилляции требует совместимую с OpenAI конечную точку, по умолчанию DeepSeek (https://api.deepseek.com, модель deepseek-chat):

export AGENT_MEMORY_LLM_API_KEY=sk-...
# 可选覆盖：AGENT_MEMORY_LLM_BASE_URL / AGENT_MEMORY_LLM_MODEL
# 评估评委可单独配置（异源互审）：AGENT_MEMORY_JUDGE_LLM_API_KEY 等

При отсутствии ключа функции, не зависящие от LLM, такие как поиск, ручная запись, обратная связь, удаление, работают как обычно; только путь дистилляции диалога выдаёт ошибку при вызове (fail-closed).

Команда дистилляции CLI

Пропустить диалог (JSON-файл вида [{role, content}, ...]) через полный конвейер записи в базу:

uv run agent-memory distill --file conversation.json --scope repo:my-project \
    --source kimi-code --session-id 2026-08-19-session
# 管线：蒸馏 → 评价门 → 对账；无法自动收敛的冲突会写入 data/review_queue/

MCP-сервер

Запуск: uv run python -m agent_memory.server.mcp_server (stdio).

Фрагмент конфигурации MCP для Claude Code / Kimi Code:

{
  "mcpServers": {
    "agent-memory": {
      "command": "uv",
      "args": ["run", "python", "-m", "agent_memory.server.mcp_server"],
      "env": {
        "AGENT_MEMORY_DATA_DIR": "C:/Users/<you>/.agent-memory/data",
        "AGENT_MEMORY_LLM_API_KEY": "sk-...",
        "AGENT_MEMORY_LLM_BASE_URL": "https://api.deepseek.com",
        "AGENT_MEMORY_LLM_MODEL": "deepseek-chat"
      }
    }
  }
}

Начиная с пяти инструментов (с M5 расширено до семи, с M7 — до тринадцати, см. разделы M5 / M7 ниже): memory_search (гибридный поиск + XML-блок, фильтрация по scope принудительно на сервере), memory_add (диалог JSON через конвейер дистилляции / одиночный content через редактирование + сверку), memory_feedback (повышение/понижение уверенности, при падении ниже low — в очередь проверки), memory_update (обновление после редактирования + оценочного шлюза), memory_forget (удаление).

Сквозная оценка

uv run python evals/runners/e2e_eval.py --layers 1,2            # 无 key 时自动规则降级模式
uv run python evals/runners/e2e_eval.py --layers 1,2 --llm-judge # 真实 LLM 评委按 rubric 判定
uv run python evals/runners/e2e_eval.py --layers 3 --llm-judge --jobs 8   # layer3 跨会话隐藏关联
uv run python evals/runners/e2e_eval.py --layers 3 --llm-judge --jobs 8 --baseline
    # --baseline：同一批用例在空库下配对重跑，输出逐题胜负 / McNemar p 值 /
    # 配对 bootstrap 留出增益区间，以及激活率 / 遵循率 / 留出增益三个进化指标
uv run python evals/runners/e2e_eval.py --layers 2 --llm-judge --jobs 8   # 调高用例并发
uv run python evals/runners/e2e_eval.py --layers 2 --llm-judge --no-cache # 禁用响应缓存

Механизмы ускорения (действуют по умолчанию в реальном режиме):

• Дисковый кэш ответов LLM: каждый ответ дистилляции / сверки / судьи кэшируется по sha256(model + system + user) в data/logs/llm_cache/ (в gitignore). При повторном запуске неизменённые этапы попадают в кэш и выполняются за секунды; смена модели автоматически не попадает. Отключается через --no-cache.

• Параллельность на уровне сценариев: --jobs N (по умолчанию 4) использует пул потоков для параллельного запуска сценариев, каждый сценарий в отдельной временной директории, при 429 автоматический повтор с экспоненциальной задержкой.

• Загрузка модели: bge-m3 загружается один раз на процесс (около 1-2 минут). При запуске нескольких слоёв используйте --layers 1,2 для однократного запуска, не разделяйте на два процесса по одному слою.

Режим понижения до правил не отражает реальное качество дистилляции; для официальной приёмки необходимо настроить реальный LLM и перезапустить.

Использование M3

Подключение LangGraph

Собственный агент LangGraph можно подключить тремя способами, которые можно комбинировать:

from agent_memory.long_term.adapters.langgraph.store import AgentMemoryStore
from agent_memory.long_term.adapters.langgraph.tools import build_memory_tools
from agent_memory.long_term.retrieve.resident import build_system_context
from langgraph.prebuilt import create_react_agent

# 1) BaseStore：namespace 约定 ("memories", <scope>)，put/search/delete 直接映射到记忆内核
store = AgentMemoryStore()          # 配置走 AGENT_MEMORY_* 环境变量
store.put(("memories", "repo:myproj"), "db-choice",
          {"content": "本项目数据库定为 SQLite，文件 data/app.db。", "confidence": "high"})

# 2) ReAct tool：recall_memories / save_memory 挂进 tools 列表
tools = build_memory_tools()

# 3) 常驻层：profile 类记忆渲染进 system prompt（预算是召回预算的一半）
prompt = "你是用户的编程助手……\n\n" + build_system_context("repo:myproj")

agent = create_react_agent(model, tools, prompt=prompt, store=store)

Полный работающий пример см. в examples/langgraph_demo.py (uv run python examples/langgraph_demo.py, требуется AGENT_MEMORY_LLM_API_KEY).

Обратите внимание: put в BaseStore — это низкоуровневый синхронный интерфейс: вызывающий должен предоставить готовое атомарное содержимое, адаптер проходит через правила редактирования + оценочный шлюз (инструктивный контент вызывает ошибку), но не выполняет LLM-дистилляцию; сверка в инструменте save_memory — это чисто правило-ориентированный путь без LLM (повтор соседа — NOOP, иначе ADD), разрешение конфликтов по-прежнему идёт через конвейер дистилляции M2.

Подключение навыка

skills/agent-memory/SKILL.md — это слой подсказок, обучающий обёрнутого агента (Kimi Code / Claude Code), когда искать, записывать и давать обратную связь. Установка (используется вместе с MCP-сервером):

• Kimi Code: скопируйте или создайте символическую ссылку skills/agent-memory/ в ~/.kimi-code/skills/agent-memory/;

• Claude Code: скопируйте в ~/.claude/skills/agent-memory/;

• одновременно подключите сервер agent-memory согласно конфигурации MCP выше, чтобы имена инструментов в навыке (memory_search и т.д.) имели реализацию.

Оценка регрессии префиксов траекторий

Замороженный контекст (system + внедрённый блок памяти + последнее сообщение пользователя) → LLM выводит следующее действие → судья определяет, попадает ли оно в допустимое множество и не касается запрещённого. Покрывает четыре типа граничных сценариев (конфликт инструкций / утечка scope / низкая уверенность / защита от инъекций) + контроль нормального воспоминания:

uv run python evals/runners/prefix_regression.py             # 需 LLM key，无 key 整体跳过
uv run python evals/runners/prefix_regression.py --seeds 3   # 多种子报均值与区间
uv run python evals/runners/prefix_regression.py --no-cache  # 禁用 LLM 响应缓存（默认开）

При 429 автоматически выполняются повторные попытки с интервалом; дисковый кэш ответов LLM общий с e2e_eval в data/logs/llm_cache/. Эта оценка не имеет режима понижения до правил (поведение actor само является объектом тестирования).

Использование M4

Цикл обучения во сне (evolve)

# dry-run：只到提案为止，打印提案摘要，不验证、不应用
uv run agent-memory evolve --dry-run

# 完整循环：触发 → 整合 → 三档验证 → 通过则晋升（自动快照 + 审计）
uv run agent-memory evolve

# 只整理某个 scope
uv run agent-memory evolve --scope repo:my-repo

Условия срабатывания (при выполнении любого, пороги переопределяются переменными окружения AGENT_MEMORY_EVOLVE_*): прошло более 7 дней с последней консолидации (EVOLVE_INTERVAL_DAYS), добавлено более 50 новых записей (EVOLVE_NEW_ENTRIES_THRESHOLD), накопление в очереди проверки более 10 (EVOLVE_REVIEW_BACKLOG_THRESHOLD).

Консолидация создаёт предложение (data/review_queue/evolution/<timestamp>/proposal.yaml), а не прямое изменение: при невыполнении любого из трёх уровней проверки (boundary / retention / safety) предложение отклоняется и остаётся для ручного вмешательства; только при полном прохождении выполняется продвижение — перед продвижением делается снимок слоя памяти (data/snapshots/<timestamp>/), после продвижения пишется аудиторский журнал (data/logs/evolution_audit.jsonl). Для отката используйте agent_memory.long_term.evolve.apply.rollback(snapshot_id, settings, embedder) для восстановления слоя памяти из снимка и пересоздания индексов.

Использование M5

Ручная проверка (два интерактивных узла очереди проверки)

Недопустимые результаты дистилляции, низкая уверенность по оценочному шлюзу, конфликты, не сходящиеся при сверке, попадают в data/review_queue/ для ручного решения. Проверка выполняется двумя MCP-инструментами:

• memory_review_list: перечисляет детали ожидающих задач (источник, причина, содержимое);

• memory_review_resolve: решение — approve сохранить как есть / modify изменить текст, пройти редактирование + оценочный шлюз, затем сохранить / discard отбросить. При успешном решении файл очереди удаляется; задачи типа raw_record нельзя сохранять напрямую.

Шлюз проверки (AGENT_MEMORY_REVIEW_GATE, по умолчанию ask): поведение memory_search при наличии накопленных элементов — ask возвращает status=blocked и ждёт подтверждения пользователя (acknowledge_pending=true для пропуска), strict всегда отказывает в чтении (для сценариев без присмотра), off не блокирует. memory_add возвращает детали pending_review, агент должен сообщить о них пользователю и попросить решения (соответствующий процесс описан в SKILL.md).

Принудительный hook обновления памяти

scripts/memory_turn_hook.py — это Stop-hook для kimi-code: подсчёт ходов по сессии, каждые AGENT_MEMORY_REVIEW_TURN_INTERVAL (по умолчанию 3) ходов перехватывает завершение сессии и внедряет инструкцию дистилляции (материал = сообщения пользователя каждого хода + соседние ответы ассистента). Зарегистрирован в пользовательском ~/.kimi-code/config.toml, действует для всех проектных сессий; другие хосты могут подключить аналогично, следуя скрипту.

Использование M6

Постоянный HTTP-сервис

В режиме stdio хост запускает сервер как дочерний процесс, который живёт и умирает вместе с сессией; HTTP-режим — это долго работающий локальный сервис, любой агент-хост, способный отправлять HTTP-запросы, регистрирует URL и получает все тринадцать инструментов:

uv run python -m agent_memory.server.http_server
# 默认监听 http://127.0.0.1:8765/mcp（只绑回环地址，天然免鉴权）
# 覆盖：AGENT_MEMORY_HTTP_HOST / AGENT_MEMORY_HTTP_PORT

Сервис также имеет два статических маршрута: /SKILL.md (полный текст слоя подсказок) и /bootstrap (инструкция по подключению). Новому агенту достаточно передать содержимое /bootstrap: зарегистрировать http://127.0.0.1:8765/mcp (тип транспорта streamable-http) + прочитать и следовать /SKILL.md, копировать файлы не нужно.

Постоянный сервис в Windows (плановая задача)

scripts/start_http_server.cmd — обёрточный скрипт запуска: при аварийном выходе ждёт 60 секунд и перезапускает, максимум 3 раза; после 3 неудач пишет маркер data/state/http_server_FAILED.txt для ручного вмешательства; журнал в data/logs/http_server.log. scripts/register_task_s4u.ps1 регистрирует плановую задачу, запускаемую при входе (фоновый режим S4U, полностью без окна), требует прав администратора. Оба скрипта должны оставаться чисто ASCII (cmd.exe читает .cmd в GBK, PowerShell 5.1 читает .ps1 без BOM в ANSI, не-ASCII повредит разбор).

Использование M7

Единая сборка контекста и рабочая память

memory_context(scope, query?, k?, current_turn?) за один раз собирает три секции: блок постоянного профиля (profile из долговременной памяти) → блок рабочей памяти (текущее состояние задачи) → блок поиска (поиск долговременной памяти только при передаче query). Для повседневного обслуживания текущего состояния задачи используются три инструмента рабочей памяти:

• memory_wm_write(scope, goal?, decisions?, variables?, todos?, notes?, turn_watermark?): запись с полной заменой (не слияние, непереданные поля очищаются), проходит только редактирование, без оценочного шлюза;

• memory_wm_read(scope, current_turn?): чтение + определение свежести (stale_wm=true означает, что текущий номер хода превысил уровень turn_watermark рабочей памяти — «до какого хода обновлено это состояние», состояние может быть устаревшим);

• memory_wm_clear(scope): очистка (идемпотентно, отсутствие не считается ошибкой).

Рабочая память — это черновик операционного слоя: выводы по завершённым пунктам должны быть дистиллированы в долговременную память (memory_add или memory_session_end ниже), чтобы считаться закреплёнными.

Чтение журнала сессии и завершение сессии

memory_transcript_read(log_path, adapter?, since_turn?) разбирает журнал сессии агента (например, wire.jsonl от kimi-code, формат определяется автоматически по имени файла) в чистую последовательность ходов (user/assistant/tool); since_turn вместе с уровнем рабочей памяти выполняет инкрементальное чтение (возвращает только ходы после уровня).

memory_session_end(scope, conversation_json?|log_path?, ...) — стандартное завершение сессии, выполняемое за один раз: архивирование исходного текста (data/raw/, только добавление, без перезаписи) → совместная дистилляция (диалог + снимок рабочей памяти как справочный контекст) → очистка выполненных задач в рабочей памяти. Если в рабочей памяти есть pending-задачи, выполняется veto (архивирование/дистилляция/очистка не выполняются), для подтверждения завершения передайте force=true. Он работает в двух треках с роллинг-дистилляцией hook каждые N ходов: hook гарантирует защиту от потери при сбое в середине, session_end выполняет стандартное завершение.

Три архитектурные красные линии

Подробнее см. AGENTS.md. Кратко: трёхуровневое разделение данных (raw только добавляется, memory — единственный источник истины, index можно пересоздать, но никогда не редактировать вручную); запись должна проходить через шлюз редактирование → дистилляция → сверка; evals / rubric / пороги выпуска / аудиторские журналы запрещено изменять агентом самостоятельно.