ai-memory
面向 AI 编码代理的长期记忆基础设施,用 Rust 实现,通过 MCP 和生命周期钩子自动捕获会话,整理成 git 版本化的 markdown wiki,支持跨 Claude Code/Codex 等多个 agent 的无缝交接。亮点是纯 Rust 单二进制架构,无需向量库也能用 FTS5/实体/图/向量混合检索,LLM 可选;已适配 20+ 种 agent 客户端,适合多工具混用和团队共享部署场景。
README
为 AI 编码 agent 提供长期记忆。中途退出 Claude Code, 在同一目录启动 OpenAI Codex,无需重新解释架构、 失败过的方案或未解决的问题。
支持矩阵
| 领域 | 状态 | 说明 |
|---|---|---|
| Linux | 支持 | 主要 Docker/服务器目标和 CI 平台。发布的 Docker 镜像支持 linux/amd64 和 linux/arm64。原生 Arch/AUR 包包含系统和用户级 systemd 单元。 |
| macOS | 支持 | 工作区测试在 CI 中运行;标记版本发布原生 ai-memory-macos-aarch64.tar.gz 和 ai-memory-macos-x86_64.tar.gz 二进制。在 Apple Silicon 上推荐使用原生二进制。参见 docs/macos.md。 |
| 通过 WSL2 的 Windows | 支持 | 当 agent 在 WSL2 内运行时,使用 Linux 安装路径。 |
| 原生 Windows | 实验性 | 标记版本发布包含 ai-memory.exe 的 ai-memory-windows-x86_64.zip;也提供 Docker Desktop 包装器和源码构建。本地支持的 profile 默认使用宿主机原生 hook 命令;Claude Code 可能使用其 Windows exec 形式,而其他 agent 使用匹配其 hook schema 的原生单命令字符串。PowerShell/Git Bash 脚本是兼容性回退方案。参见 docs/windows.md。 |
| Claude Code | 支持 | MCP 配置 + 生命周期 hooks;原生命令强制执行捕获排除。install-mcp --session-aware 可选地通过本地 stdio 桥启用每次会话自动作用域隔离。当使用 --capture-assistant 安装且服务器启用 capture_assistant(双重 opt-in,默认关闭)时,可选地在 Stop 时捕获 assistant 的最后一轮回复。 |
| Codex | 支持 | MCP 配置 + 生命周期 hooks;原生命令强制执行捕获排除。没有自动的真正会话结束 hook,因此当你需要最终摘要/交接时,运行 ai-memory finalize-session。 |
| Command Code | 支持 | MCP 配置(~/.commandcode/mcp.json)+ 其四个稳定的生命周期 hook 事件(~/.commandcode/settings.json);原生命令强制执行捕获排除,且 SessionStart 注入交接。Stop 只是轮次边界,因此在最后一轮后使用 ai-memory finalize-session --agent command-code。ai-memory run command-code 添加精确的 v3 原生会话恢复和可见事件导入;实验性的非沙箱 Mods 仍被排除。 |
| Devin CLI | 支持 | MCP 配置 + 生命周期 hooks。Hooks 使用 Devin 的 PostCompaction 事件,通过 hookSpecificOutput.additionalContext 注入交接,并省略子 agent 事件,因为 Devin 不暴露它们。 |
| OpenCode | 支持 | 远程 MCP 配置 + 生成的 TypeScript 插件;生成的插件强制执行捕获排除。 |
| Cursor | 支持 | MCP 配置 + 生命周期 hooks。 |
| Gemini CLI | 支持 | MCP 配置 + 生命周期 hooks。 |
| Oh My Pi / OMP | 支持 | 使用 --client omp / --agent omp(或 oh-my-pi)以获取原生 .omp MCP 配置 + TypeScript 扩展;生成的扩展强制执行捕获排除。 |
| Pi | 支持 | 生成的 ~/.pi/agent/extensions/ai-memory.ts 扩展提供生命周期捕获和 HTTP MCP 桥;生成的扩展强制执行捕获排除。 |
| Crush | 仅托管 | ai-memory run crush 恢复其项目本地会话数据库,并通过临时受支持的全局上下文文件提供可移植上下文;不提供生命周期 hook 安装器。 |
| 托管工作流 | opt-in | ai-memory run 为 Claude Code、Codex、OpenCode、Pi、Crush、Kimi Code、Command Code、两个不兼容的 Kiro CLI 引擎、OMP、Grok Build CLI 和 Antigravity CLI 提供透明的跨 harness 连续性。直接启动保持不变。参见 docs/managed-workstreams.md。 |
| Claude Desktop | 仅 MCP | 使用 mcp-remote;无生命周期 hooks。 |
| OpenClaw | 支持 | MCP 配置 + 原生插件生命周期 hooks;生成的插件强制执行捕获排除。 |
| Antigravity CLI | 支持 | MCP 配置(serverUrl)+ 生命周期 hooks(agy 别名)。只有 invocationNum = 0 的 PreInvocation 映射到 SessionStart;后续模型调用无法消费下一次会话的交接。没有自动的真正会话结束 hook,因此当需要摘要、交接和 opt-in 的 SessionEnd 整合时,在最后一轮后运行 ai-memory finalize-session --agent antigravity-cli。ai-memory run antigravity(别名 antigravity-cli、agy)通过 --conversation 添加托管工作流恢复;会话文本不被解码,因此该 harness 的分类账来自 hook 捕获。 |
| Grok Build CLI | 支持 | MCP 配置(install-mcp --client grok → $GROK_HOME/config.toml,默认 ~/.grok/config.toml)+ 生命周期 hooks(install-hooks --agent grok → $GROK_HOME/hooks/ai-memory.json,默认 ~/.grok/hooks/ai-memory.json,Grok 专用 hook 包)。捕获正常工作;无 hook 交接注入 —— Grok 忽略 SessionStart stdout,因此通过 MCP memory_handoff_accept 恢复交接。ai-memory run grok 添加托管工作流恢复,上下文包通过 --rules 原生传递。Skills 根目录:.grok/skills / $GROK_HOME/skills(默认 ~/.grok/skills)。 |
| Swival CLI | 仅 MCP | install-mcp --client swival --apply 将原生 HTTP 条目合并到项目根目录的 .swival/mcp.json 中,保留兄弟服务器。生命周期和托管工作流支持不被声称,因为 Swival 的回调契约不暴露稳定的会话标识符。 |
| Zero | 支持 | install-mcp --client zero(原生 HTTP + bearer,位于 ~/.config/zero/config.json)+ 通过 install-hooks --agent zero --apply 的生命周期 hooks(~/.config/zero/hooks.json 中的 exec 形式原生命令,JSON payload 通过 stdin,无 shell)。捕获正常工作,包括 specialist(子 agent)事件;无交接注入 —— Zero 丢弃 sessionStart stdout,因此通过 MCP memory_handoff_accept 恢复交接。 |
| Kimi Code | 支持 | MCP 配置(~/.kimi-code/mcp.json 中的 url 条目)+ 生命周期 hooks(~/.kimi-code/config.toml 中的 [[hooks]],10 个事件,包括子 agent 启动/停止和用于工具失败捕获的 PostToolUseFailure);两条路径都遵循 $KIMI_CODE_HOME。交接通过 UserPromptSubmit stdout 注入(Kimi Code 丢弃 SessionStart hook stdout);ai-memory run kimi 添加托管工作流恢复。 |
| Kiro CLI | 支持 | MCP 配置使用 install-mcp --client kiro-cli(别名 kiro)和 Kiro 的 Bedrock 兼容 schema 风格。install-hooks --agent kiro-cli 将 v2 hooks 合并到现有 agent 配置中;显式 --agent kiro-cli-v3 目标写入不兼容的独立 v3 注册。两者都保留无关条目、遵循 $KIRO_HOME、强制执行捕获排除,并在会话启动时注入待处理交接。Kiro 没有真正的 SessionEnd hook;使用 ai-memory finalize-session --agent kiro-cli,并发会话时加 --session-id <uuid>。ai-memory run kiro 管理 v2;加 --v3、--mode 或 --agent-engine v3 以进行版本安全的 v3 恢复。 |
| VS Code Copilot | 仅 MCP | .vscode/mcp.json 用于 Copilot agent 模式;无生命周期 hooks(Copilot 尚未暴露它们)。 |
| Zed | 仅 MCP | Zed 用户 settings.json 中 context_servers 下的原生远程 MCP;无生命周期 hooks 或托管工作流支持。 |
| Hermes Agent | 社区 | 核心 hook 摄取识别 agent=hermes 和 Hermes 文档化的 shell-hook tool_name / tool_input payload,用于具体会话归属、工具族标题和捕获排除。社区维护的 ai-memory-hermes-plugin 可用,但不提供一方的安装器;使用前请审查其兼容性矩阵、安装/卸载脚本和密钥处理。Hermes 忽略会话启动 hook stdout,因此通过 MCP 恢复交接。 |
| LLM/认证提供商 | 支持 | Anthropic、OpenAI、OpenAI OAuth/Codex、GitHub Copilot、Gemini、OpenCode Zen/Go、OpenAI 兼容端点,以及用于原生 hooks 的通用 OIDC 设备认证。 |
| Embedding 提供商 | 支持 | OpenAI、Voyage、Google Gemini,以及无密钥的 OpenAI 兼容端点,如 Ollama、LM Studio 和 vLLM。 |
这是什么
LLM 编码 agent 在会话结束时丢失上下文。ai-memory 给它们一个
共享的、持久的 wiki,由经过净化的生命周期观察编译而成。当
会话结束时,相关观察变成连贯的摘要;下一个
agent 收到一个有界的交接。可选的 ai-memory run 启动
添加可移植的可见事件分类账和原生 per-harness 恢复,以实现更高保真度的
跨 harness 连续性。
wiki 是 git 仓库中的纯 markdown —— 可 grep、可在
Obsidian 中打开、可用 rsync 备份。无需维护向量数据库,无需
write_note 仪式,无需手动加载上下文。完整设计
在 docs/ARCHITECTURE.md 中;影响和
先例在底部。
主要特性
- 零摩擦生命周期捕获。 Hooks 即发即忘地发送有界的、 净化的 prompt、工具生命周期和会话边界观察。直接 启动保持这条轻量路径;它不是完整的原生转录。 用户 prompt 和压缩后摘要保留最多 16 KiB; 通知和工具摘录保留最多 2 KB,每个观察 体有 16 KiB 的持久后备。
- Opt-in 托管工作流。 先
ai-memory run claude,再ai-memory run codex --yolo,然后ai-memory run command-code,透明地恢复 一个逻辑工作流,带原生 per-harness 会话、可移植的可见事件 分类账和全分类账搜索。交付的包有来源标记;Claude 转录导入拒绝 Claude 已持久化并通过工具读回的包。 不带 harness 的ai-memory run继续此 checkout 中最新可用的 Claude Code、 Codex、OpenCode、Pi、Crush、Kimi Code、Command Code 或 Kiro CLI v2/v3 会话。 在首次 显式使用时,交互式启动器可以继承同一 checkout 中的先前会话; 之后的切换不能选择无关的原生历史。原生 参数原样传递,除了 wrapper 拥有的--yolo和--fresh;直接 命令不受影响。kimi-code和kimi-cli是已安装kimi命令的接受别名;commandcode、cmdc和cmd选择 跨平台command-code可执行文件(原生 Windows 上为cmdc);而kiro-cli选择已安装的kiro-cli命令。Kiro 默认为 v2;ai-memory run kiro --v3选择 v3,而 返回的已链接 v3 工作流透明地选择其引擎。 - 按仓库的捕获排除。 最近的标记文件
[capture]ignore_paths策略在匹配的已识别文件工具事件到达 本地 spool 或服务器之前丢弃它们。参见 捕获策略参考。 - 可选的按操作者记忆槽。 在共享服务器上,
[slots] per_user = true将引擎写入的_slots/上下文保持在 由已验证操作者派生的有界命名空间中。会话简报和 整合 prompt 接收共享槽加上调用者自己的;精确的 wiki 读取和搜索保持项目范围,因此这是上下文注入 隔离而非 RBAC。参见 多用户操作。 - 跨 agent 交接。 中途退出 Claude Code,几小时后 在同一目录启动 Codex —— 下一个 agent 在其第一个 prompt 之前看到 一个"你上次停在哪里"的块。
- 按构造的项目隔离。 每个项目位于
<wiki_root>/<workspace_id>/<project_id>/…,由稳定 UUID 键控。 Workspace 默认为"default"。项目从$cwd派生: CLI 子命令(bootstrap、write-page、lint等)向上遍历到 主 git 仓库根,因此同一仓库的所有 worktree 共享一个 项目身份;hook 路由器默认为basename($cwd),并且 可以选择 repo-root 规则。在任何 祖先目录中放置.ai-memory.toml标记文件 以显式覆盖任一字段 —— 非常适合多客户端咨询、工作/个人分离、mono-repo 或 链接的 git worktree。 同一页面路径可以存在于两个项目中而不冲突; 重命名是一次列更新;清除是一次rm -rf。 - 全局偏好作用域。 常驻的用户/团队上下文 —— 技术
选择、代码风格、持久的个人规则 —— 位于保留的
_global作用域中(memory_write_page带scope: "global")。默认memory_query读取时将它与每个项目联合为global_scope_hits,因此偏好随你进入新项目, 无需命名魔法项目或付出全项目global=true的扇出代价。事件捕获从不写入那里。 - 实体辅助召回。 整合将每个页面最多 10 个特定名词存储在规范的
entities:frontmatter 中。精确、前缀和复合词 匹配形成项目范围的 RRF 流,因此查询可以恢复页面, 即使其正文使用不同措辞。该流是词法级的, 不增加查询时 LLM 调用。 - 权威感知召回。 FTS5、实体匹配 RRF、图邻居 RRF 和
可选的向量 RRF 按相关性生成候选。在截断之前,
有界调整偏好维护良好的
_rules/、decisions/、procedures/和gotchas/页面,而非紧密匹配的情景性会话证据。层级、pinned和显式canonical/active/source-of-truth或superseded/historical/test-fixture/do-not-answer-from标签 有贡献但不会成为绝对过滤器,因此定向历史搜索 仍然能找到会话页面。这些信号只影响检索来源; 检索到的文本仍然是不受信任的历史证据,永远不会从其 命名空间、层级、标签、pin 或排名获得指令权威。 - 与代码智能工具并行的清晰路由。 在结构化的 MCP 服务器、LSP 或其他实时代码工具旁运行 ai-memory,无需 同步它们的存储。使用记忆来获取先前决策、理由、失败的尝试、 程序和交接;使用当前 checkout 和结构化提供者 来获取符号、调用者、依赖和影响分析。在行动前 对照 checkout 验证历史代码声明,并将源码、构建、 测试和观察到的运行时行为视为操作真理。参见 历史记忆和实时代码智能。
- Karpathy 风格 LLM wiki。 页面在会话结束时(或 PreCompact;没有真正会话结束事件的客户端可以
使用
ai-memory finalize-session --agent <agent>进行手动最终关闭) 从观察编译,而不是在原始日志上检索。 取代链 + git 版本化 markdown 意味着你可以 使用ai-memory checkpoints、restore-page或原始git log进行时间旅行。 - 内置
/web浏览器。 wiki 的只读 HTML UI —— 项目列表、文件夹树、FTS5 搜索、markdown 渲染、深色 模式。挂载在与 MCP 相同的 axum 服务器上。 - 服务器范围的 MCP 客户端活动。
GET /admin/activity/by-client?since_days=7显示哪些 MCP 客户端 正在调用记忆工具,分为读取和写入。计数使用有界的 UTC 日 桶,因此任意客户端名称不能随请求量增长数据库; 共享部署保持该端点仅 root 可访问。参见 MCP 客户端活动。 - 多 agent + 多机器就绪。 支持的客户端:Claude
Code、Codex、Command Code、Devin CLI、OpenCode、Cursor、Claude Desktop(通过
mcp-remote)、 Gemini CLI、Antigravity CLI、Grok Build CLI、Kimi Code、OpenClaw、Oh My Pi / OMP(omp/oh-my-pi)、通过生成的桥接扩展的 Pi、VS Code GitHub Copilot agent 模式(仅 MCP,工作区.vscode/mcp.json)、Kiro CLI (MCP + v2 生命周期 hooks)和 Zed(仅 MCP,用户settings.json)。 服务器可在本地(loopback)运行,也可在家庭实验室机器(LAN/VPN/cloud) 上运行,带 bearer-token 认证。共享服务器可以选择[auto_scope]模式 进行按用户或 会话感知的当前项目路由;Claude Code 通过install-mcp --session-aware内置 opt-in 桥。 - 瘦客户端 CLI。
ai-memory status、bootstrap、checkpoints、restore-page、purge-project、rename-project、move-project、move-session、audit-contamination、lint、curator、auto-improve、auto-improve-report、pending-writes、embed、forget-sweep、backup、finalize-session都是 运行中服务器的 HTTP 客户端 —— 从不直接接触 SQLite 或 wiki 文件。status还从最后一次真实提供商调用报告被动的 LLM/embedding 提供商健康。服务器是 唯一事实来源。finalize-session通过GET /admin/open-sessions列出匹配的打开 会话,然后将合成的session-endhooks 发回服务器。在共享部署中,它默认为 调用者自己的加上未归属的会话;root 可以传--all-owners进行 显式跨操作者恢复。当并发会话共享一个 agent 和 作用域时,传--session-id <uuid>以定位一个确切的打开会话;它不能 与--all组合。 - LLM 是 opt-in。 零 LLM 模式仍然给你 FTS5、手动声明的 实体和图邻居搜索,加上基于规则的摘要。当你想要整合页面、lint 矛盾或分阶段 自动改进提案时,添加提供商。
使用场景
"退出 Claude Code 并在 Codex 中继续同样的工作。" 当你想要原生会话恢复加上可移植的可见 历史(而不仅仅是摘要交接)时,使用可选的托管启动器:
cd /path/to/project ai-memory run claude # 退出 Claude Code,然后在 Codex 中继续同一工作流。 ai-memory run codex --yolo # 在 Command Code 中继续,保留其自己的精确原生会话。 ai-memory run command-code # 之后,省略名称以恢复此处最新的可用托管会话。 ai-memory run # 在同一工作流中启动新的 Codex 会话,保留可移植历史。 ai-memory run --fresh codex # Kiro 默认为 v2;显式选择其不兼容的 v3 引擎一次。 ai-memory run kiro --v3"选择项目,而不是记住它在哪里。" 从包含你的 checkout 的目录开始, 在托管 harness 之前选择 checkout:
ai-memory show # 无需启动任何东西的机器可读发现。 ai-memory show --json每次成功的
ai-memory run保存一个客户端本地 checkout 链接,由 配置的服务器加 workspace/project 键控。show将这些链接与 服务器的公开活动和页面计数元数据连接。对当前目录的快速、有界深度 1 扫描还会找到携带项目 标记(.git、Cargo.toml、package.json、go.mod、pyproject.toml等) 的新 checkout,同时跳过依赖和构建目录。服务器从不 暴露 checkout 路径,因此两台客户端机器可以安全地为远程家庭服务器上的同一项目使用 不同的本地路径。列表始终以
+ New project开头:输入名称,ai-memory 验证可移植的目录名,私下暂存新的 checkout,将其 workspace 和 project 固定在.ai-memory.toml中,并为所选 agent 安装路由块 和托管的 Agent Skills。最终目录 仅在每个设置步骤成功后出现,然后show从中启动。harness 菜单只提供主机上实际安装的 agent,使用与
run在启动时强制执行的相同PATH查找。--no-scan只使用保存的链接;--workspace过滤两个来源;--yolo、--fresh和尾随的原生参数原样转发。 非终端使用必须传--json;JSON 模式仅发现, 从不启动 harness。第一次显式运行可以提供来自此确切 checkout 的现有会话 或启动新会话。切换 harness 启动或恢复链接到 共享工作流的原生会话,因此过时的本地会话不能替换 更新的跨 harness 历史。正常退出后,如果前一个启动器仍在完成 收尾,下次启动会短暂等待;已处理的失败立即释放 工作流。如果链接的原生转录被删除, ai-memory 在启动前检测到孤儿并重新开始;
--fresh强制 对一个 harness 进行该恢复。托管模式目前涵盖 Claude Code、 Codex、OpenCode、Pi、Crush、Kimi Code、Command Code、Kiro CLI v2/v3、OMP、 Grok Build CLI 和 Antigravity CLI;直接 harness 启动保持不变。参见 托管跨 harness 工作流。"直接把我放回原处。" 从任何目录,无需输入名称 或阅读列表:
ai-memory continue它选择托管启动最近的 checkout,重新验证 路径及其解析的作用域,然后像裸
ai-memory run那样 继续。目录被移动、被替换、 现在解析到不同项目或具有损坏排序时间戳的链接 会在 stderr 上报告并被跳过,因此恢复永远不会悄悄落在错误的 项目中。--workspace缩小搜索范围;--yolo和--fresh被 转发。"下午 4 点退出,早上 9 点在另一个 agent 中继续。" 经典 场景。下一个受支持 hook 客户端中的 SessionStart hook 前置一个 带未解决问题、下一步和会话摘要的带类型交接。Grok 捕获生命周期事件但忽略 SessionStart stdout,因此在从交接恢复时 让它调用
memory_handoff_accept。Zero 有相同的 无 stdout 行为,也必须调用memory_handoff_accept。"六周前我们关于 X 决定过什么?" 从 agent 使用
memory_query X进行 FTS5 与实体匹配和链接页面扩展的融合(加上 配置了 embedder 时的向量相似度)。对于快速的纯终端 FTS5 查找,使用ai-memory search X;该 admin 命令不运行 混合流。页面是 LLM 整合的,因此命中是一个连贯的决策页面,而不是原始的 聊天日志。传explain: true查看每个命中在项目或显式作用域检索中 排名如此的原因。跨项目global: true搜索使用其单独的仅 FTS 排序器,并报告 该活动流,没有逐命中 RRF 细节。"永久记住这个。" 当某些东西值得保留在 自动捕获的会话日志之外 —— 一个决策、一个约定、一个 坑 —— 告诉 agent "保存一个永久笔记,关于我们为 X 标准化了 Postgres" 或 "将此标注为项目规则",它会调用
memory_write_page写入持久的、git 版本化的 wiki 页面。从 终端是ai-memory write-page --path decisions/0007-db.md --body $'# Standardised on Postgres\n\n...' --pinned。--pinned使其免于衰减清理;--body第一行上的 H1 成为页面标题(省略--title—— 它仍然被 接受,但 LLM 调用者会在 JSON 转义中出错, 见 issue #67)。与交接(一次性使用)或 自动合成的会话页面(整合时重写)不同, write-page 笔记是你的:它出现在memory_query中,在/web中渲染,并一直保留到你更改它。"你找到的那个页面已过时。" Agent 调用
memory_feedback,带页面的路径和一个信号:helpful/not_helpful调整保留在清理候选中的情景性 页面的保留强度(它们移动其显著性,这缩放衰减公式的时间项), 而stale/wrong将显著性设下限 并 使任何当前 页面在下一个memory_lint报告中显示为feedback_flagged发现。 反馈从不删除任何东西 —— 它降低置信度并标记审查 —— 并且它附加到记录反馈时的当前版本,因此 稍后的重写清除该标志。检索到的页面文本不受信任, 本身永远不会授权反馈。"记住这个,但只到 sprint 结束。" 传
expires_at给memory_write_page(RFC3339 或YYYY-MM-DD= 该 日结束,UTC)—— 或手动将expires_at:放在页面的 frontmatter 中。 超过 TTL 后页面从搜索/最近/简报中消失 (传include_expired: true给memory_query仍可看到它), 下一次 forget sweep 硬删除文件和其行。TTL 胜过 pin;memory_lint警告 pinned+expiring 组合。"这个新项目在 ai-memory 之前有几个月的历史。"
cd /path/to/my-project && ai-memory bootstrap收集git log、README、docs/、模块头部、项目规则,并 一次性摘要成种子 wiki 页面。未来的会话 在此基础上构建。"那个会话教会了什么持久教训?" 当配置了 LLM 提供商时,ai-memory 为每个项目中新完成的会话运行后台 自动改进调度器。它将提议的 wiki 编辑记录在 pending-writes 审计跟踪中,然后 默认通过正常的 wiki 写入路径立即批准它们。调度器 tick 不重叠:如果审查所有项目耗时超过间隔, 下一个 tick 会延迟到当前完成。调度和 批准是分开的:设置
[auto_improve.scheduler] enabled = false停止自动 审查,或设置[auto_improve] require_approval = true保持计划和 手动提案都待人工审查。ai-memory auto-improve --session-id <uuid>和 MCPmemory_auto_improve仍然 可用于手动补跑或定向重跑。当其session_id被省略时,MCP 工具选择最新完成的 没有持久化自动改进运行的会话,因此重复调用会跳过短暂的 preflight-skipped 会话;显式 ID 重跑该会话。ai-memory auto-improve-report --workspace <w> --project <p>返回只读的 遥测报告,涵盖最近的自动改进结果,不暂存或 创建提案;加--stage创建一个待处理报告页面用于 审计/批准。在区分操作者的部署中,待处理学习 提案按合格的操作者身份隔离,因此一个人对 页面的提案不会阻塞另一个人的;未归属和单用户 部署保留共享的待处理队列。参见docs/auto-improve-eval-gates.md获取 示例可执行 eval 评分器。现有安装不需要按项目迁移。调度器初始化 每个项目的首次运行水位线,因此历史会话不会在升级时 被自动审查,然后记录每个会话的声明,以便失败的调度审查 不会永远重试;对旧会话或 你想要补跑失败的调度会话使用手动 auto-improve。较旧的配置可能仍包含
[auto_improve] mode = ...行;当前 ai-memory 忽略该旧键, 因此你可以方便时删除它。"我应该考虑哪些维护?"
ai-memory curator对冷 情景性页面、过期槽、重复的精确规范化标题和悬空的 跨项目链接运行无 LLM、基于规则的维护报告。它是仅报告的, 除非传--stage;暂存 将一个报告页面排队等待批准,并且本身仍不执行维护操作。 共享服务器可以选择[decay] breadth_weight为被多个已识别操作者加强的页面 给予保留奖励;默认0.0保持现有保留分数不变。**"为整个
[原 README 过长已截断]