ai-memory 的 Windows 支持实战指南WSL2、Docker Desktop、原生二进制与常驻服务的完整方案【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory本篇技术指南围绕 ai-memory 在 Windows 平台上的全场景部署展开从agent 实际运行在哪里就在哪里安装的核心原则出发完整覆盖全 WSL2、原生 Windows Docker Desktop、预编译 release 二进制、原生源码构建四种安装模式并深入讲解 Claude Code 在 Windows 上的原生 Hook 命令exec form、AI_MEMORY_HOOK_PLATFORM平台切换、Spool 时序调优以及如何用 WinSW 把ai-memory serve包装成真正的 Windows 服务含 Task Scheduler 静默被杀陷阱的根因分析。读完后你将能在 Windows 上为 Claude Code、Codex、Cursor、Devin、Kimi Code、Kiro CLI 等任意 agent 正确接入 ai-memory 的长时记忆与 handoff 能力并让服务跨注销与重启稳定常驻。核心原则在 agent 实际运行的同一环境中安装Windows 支持有两条完全不同的路径选择哪条取决于你的 agent CLI 到底运行在哪里。经验法则只有一句话在启动 Claude Code、Codex、Command Code、Devin CLI、Cursor、Gemini CLI、Kimi Code、Kiro CLI、Antigravity CLI 或其他 agent 的同一个环境里运行install-mcp和install-hooks。如果 agent 运行在WSL2 内部就在 WSL2 内安装 ai-memory如果 agent 是原生 Windows 进程就在 Windows 的 PowerShell 里安装不要把 Windows wrapper 与 WSL2 启动的 agent 混用除非你有意覆盖每一个配置与 hook 路径在原生 Windows 上要让服务跨注销/重启存活请使用服务包装器见后文 Scenario E。不要通过任务计划程序用Start-Process启动它——那看起来能用但会在下次重启时被静默杀掉。这条原则之所以关键是因为hook 配置里包含可执行路径WSL2 agent 需要 Linux 路径和 POSIX.shhook原生 Windows agent 需要 Windows 路径但 hook 运行器因 agent 而异——本地受支持 profile 默认使用宿主原生命令Claude Code 可能直接使用其受支持的 exec 形式command: …ai-memory.exe、args: [hook, --event, …]不经过 shell详见 Native Hook Command其他 agent 使用与其 hook schema 匹配的原生单条命令字符串。PowerShell/Git Bash 脚本包只是兼容性回退不强制执行 capture-policy v1。从源码看这一设计对应 render_shared.rs 中的HookCommandPlatform枚举Posix、Windows、WindowsBash、WindowsNative、PosixNative五种平台形态每种形态由hook_command()渲染出完全不同的命令字符串——这正是混用必坏的根本原因同一份配置文件不可能同时满足 Linux 路径与 Windows 路径。Scenario A全 WSL2最接近 Linux 的方案当 agent CLI 安装在 WSL2 发行版内部并在其中启动时使用。整个流程与 Linux 完全一致# 在 WSL2 内部执行 mkdir -p ~/.local/bin wrapper_basehttps://github.com/akitaonrails/ai-memory/releases/latest/download/ai-memory-wrapper wrapper_tmp$(mktemp -d) trap rm -rf $wrapper_tmp EXIT curl -fsSL $wrapper_base -o $wrapper_tmp/ai-memory-wrapper curl -fsSL $wrapper_base.sha256 -o $wrapper_tmp/ai-memory-wrapper.sha256 (cd $wrapper_tmp sha256sum -c ai-memory-wrapper.sha256) install -m 0755 $wrapper_tmp/ai-memory-wrapper ~/.local/bin/ai-memory rm -rf $wrapper_tmp trap - EXIT export PATH$HOME/.local/bin:$PATH docker run -d --name ai-memory \ --restart unless-stopped \ -p 127.0.0.1:49374:49374 \ -v ai-memory-data:/data \ akitaonrails/ai-memory:latest ai-memory install-mcp --client claude-code --apply ai-memory install-hooks --agent claude-code --apply此模式下 ai-memory 的表现与 Linux 完全一致配置文件写入 WSL2 家目录Hook 脚本暂存于~/.local/share/ai-memory/hooks/Hook 命令指向.sh脚本agent 也应当从 WSL2 启动才能执行这些 WSL 路径。需要注意如果 Docker 引擎由 Docker Desktop 提供给 WSL2需要先为该发行版启用 WSL 集成如果 WSL2 内部运行的是原生 Docker 引擎则完全不涉及 Windows wrapper。Scenario B原生 Windows Docker Desktop当 agent CLI 以原生 Windows 进程运行、而 ai-memory 服务器希望跑在 Docker 镜像中时使用。wrapper 渲染宿主侧 agent 配置时使用http://127.0.0.1:49374但其自身的瘦客户端命令status、search等通过 Docker Desktop 的host.docker.internal别名从辅助容器内访问服务器——因为 Docker Desktop 在 Windows 上不给 Linux 容器提供 host 网络。只有当服务器位于其他地方homelab 或远程主机时才需要设置AI_MEMORY_SERVER_URLwrapper 会尊重该变量并跳过别名。# 安装 Windows Docker wrapper $UserBin $HOME\bin New-Item -ItemType Directory -Force $UserBin | Out-Null $ReleaseBase https://github.com/akitaonrails/ai-memory/releases/latest/download $WrapperAssets { ai-memory.ps1 ai-memory-wrapper.ps1 ai-memory.cmd ai-memory-wrapper.cmd } foreach ($Entry in $WrapperAssets.GetEnumerator()) { $File $Entry.Key $Asset $Entry.Value Invoke-WebRequest -Uri $ReleaseBase/$Asset -OutFile $UserBin\$File Invoke-WebRequest -Uri $ReleaseBase/$Asset.sha256 -OutFile $UserBin\$File.sha256 $Expected ((Get-Content $UserBin\$File.sha256 -Raw) -split \s)[0] $Actual (Get-FileHash $UserBin\$File -Algorithm SHA256).Hash.ToLower() if ($Actual -ne $Expected.ToLower()) { throw Checksum mismatch for $Asset } Remove-Item $UserBin\$File.sha256 } Get-ChildItem $UserBin\ai-memory.* | Unblock-File # 将 wrapper 目录加入用户 PATH供后续终端使用 $UserPath [Environment]::GetEnvironmentVariable(Path, User) if (($UserPath -split ;) -notcontains $UserBin) { $NewUserPath (($UserPath, $UserBin) | Where-Object { $_ }) -join ; [Environment]::SetEnvironmentVariable(Path, $NewUserPath, User) $env:Path $env:Path;$UserBin } # 用 Docker Desktop 启动服务器。镜像默认 allowlist 已包含 # host.docker.internalwrapper 瘦客户端命令status、search……不会被 403 拒绝。 docker run -d --name ai-memory --restart unless-stopped -p 127.0.0.1:49374:49374 -v ai-memory-data:/data akitaonrails/ai-memory:latest # 不要再运行 ai-memory serve上面的长驻容器就是服务器。 # 验证 wrapper 能访问服务器 ai-memory status # 为原生 Windows agent 接线 MCP 与生命周期 hooks ai-memory install-mcp --client claude-code --apply ai-memory install-hooks --agent claude-code --apply此模式下PowerShell wrapper 运行 Linux 容器但让 CLI 为原生 Windows agent 渲染 hook 命令配置文件通过挂载的 Windows 家目录写入Hook 脚本暂存于$HOME\.local\share\ai-memory\hooks\本地受支持 profile 默认使用宿主原生命令Claude Code 可能使用 exec 形式command可执行文件 argsargv 数组其他 agent 使用与其 hook schema 匹配的原生单条命令字符串。wrapper 用 PowerShell-EncodedCommand渲染.ps1回退命令这样 hook 运行器无法在内部 PowerShell 进程收到命令之前展开其中的$env:设置这些命令强制文本输出并抑制进度记录避免嵌套 PowerShell 运行器向 stderr 输出CLIXML数据。PowerShell/Git Bash 脚本包只是兼容性回退不强制执行 capture-policy v1。升级 wrapper/镜像之后请为每个原生 Windows agent 重新运行install-hooks --agent agent --apply让既有 hook 条目获得当前命令形式。其他客户端使用对应的--client/--agent值例如codex、command-code、devin、kimi-code、kiro-cli、cursor、gemini-cli。Devin 的特殊路径install-mcp --client devin --apply将 MCP 配置写入%USERPROFILE%\.devin\config.jsoninstall-hooks --agent devin --apply默认把生命周期 hooks 写入%USERPROFILE%\.devin\hooks.v1.json如希望放在 Devin 主配置文件中的hooks键下请传--config-file %USERPROFILE%\.devin\config.json。Kiro CLI 的特殊路径install-mcp --client kiro-cli --apply写入%USERPROFILE%\.kiro\settings\mcp.json除非$env:KIRO_HOME覆盖根目录install-hooks --agent kiro-cli --apply更新.kiro\agents下既有的 v2 agent 文件项目级 agent 用--config-file。Kiro v3 hook 捕获仍不受支持原因在于缺少其独立 schema 的已净化实时生命周期与内置工具 payload fixtures。这些命令必须从启动 Kiro 的同一个原生 Windows 环境运行生成的执行路径才有效。从源码看Kiro 的事件词汇表在 render_shared.rs 中定义为 v2 的 5 个 camelCase 触发词agentSpawn/userPromptSubmit/preToolUse/postToolUse/stop与 v3 的 5 个 PascalCase 触发词。Scenario C预编译 release 二进制无需工具链当 agent CLI 是原生 Windows 进程、且希望走快速原生 hook 路径、同时不安装 Rust 工具链或 Docker时使用。每个 tagged release 都会发布ai-memory-windows-x86_64.zip见仓库 Releases 页。# 下载并解压到用户数据目录任意稳定路径均可原生 hook exec-form 命令 # 从 ai-memory.exe 所在位置渲染 $Dest $env:LOCALAPPDATA\ai-memory New-Item -ItemType Directory -Force $Dest | Out-Null Invoke-WebRequest -Uri https://github.com/akitaonrails/ai-memory/releases/latest/download/ai-memory-windows-x86_64.zip -OutFile $env:TEMP\ai-memory.zip Expand-Archive $env:TEMP\ai-memory.zip -DestinationPath $Dest -Force Get-ChildItem $Dest\ai-memory.exe | Unblock-File # 加入 PATH可选但方便 $UserPath [Environment]::GetEnvironmentVariable(Path, User) if (($UserPath -split ;) -notcontains $Dest) { [Environment]::SetEnvironmentVariable(Path, $UserPath;$Dest, User) $env:Path $env:Path;$Dest } # 对接 MCP 生命周期 hooks $Dest\ai-memory.exe install-mcp --client claude-code --apply $Dest\ai-memory.exe install-hooks --agent claude-code --apply --server-url https://memory.example.com --auth-token token该 zip 与 Linux release tarball 内容一致仅不含 Linux 专属的服务资产包含ai-memory.exe、完整的hooks/捆绑.ps1.sh、crates/ai-memory-cli/templates/config.default.toml、README.md、LICENSE和docs/{install,windows}.md。由于install-hooks从运行中的二进制读取ai-memory.exe路径请把解压出的.exe放在稳定位置移动后需重新运行install-hooks。此模式只在终端打开期间维持服务器运行。要跨注销与重启保持存活继续看 Scenario E。Scenario D原生 Windows 源码构建用于在 Windows 上开发 ai-memory 本身或不想为 CLI 命令使用 Docker wrapper 的场景。git clone https://github.com/akitaonrails/ai-memory .\ai-memory Set-Location .\ai-memory cargo build --workspace cargo test --workspace target\debug\ai-memory.exe init target\debug\ai-memory.exe serve --transport http --bind 127.0.0.1:49374最后一条命令会占据终端。持久化服务器方案见 Scenario E。构建失败os error 4551的排查在启用Smart App Control或App Control for Business的机器上cargo build可能在编译任何自有代码之前就失败error: failed to run custom build command for proc-macro2 An Application Control policy has blocked this file. (os error 4551)这不是工具链问题重装 Rust 也无济于事。Cargo 会把每个 crate 的build.rs编译成target\debug\build\下的未签名可执行文件而这类策略会阻止未签名二进制从用户可写目录运行。proc-macro2和icu_properties_data因为构建较早通常是第一个中招的。解决方法为 checkout 的target目录添加路径排除或在策略已信任的位置构建。该问题由 CaioCoelhoChaves 在运行 #478 的测量时报告。在原生 Windows 上从 Git Bash 做 release 验证时使用同一 checkout 配合 Rust MSVC 工具链cargo test --workspace cargo build --locked --release -p ai-memory-cli ./target/release/ai-memory.exe --version版本输出应与 checkout 的 package 版本一致。其他构建细节普通构建使用内置vendored样式表不下载任何内容重新生成样式表TAILWIND_BUILD1 cargo build -p ai-memory-web支持固定的tailwindcss-windows-x64.exe且在curl/wget不可用时回退到 PowerShellInvoke-WebRequest原生构建与 hook 运行需要 Git for Windows 的git.exe在PATH上。当 libgit2 在打开新建的 wiki 仓库时遇到 Windows 路径解析错误ai-memory 会回退到 Git CLI而不是把这一特定情况当作致命错误。在仓库目录的另一个 PowerShell 窗口中target\debug\ai-memory.exe install-mcp --client claude-code --apply target\debug\ai-memory.exe install-hooks --agent claude-code --apply原生 Windows 构建会渲染 agent 特定的宿主原生生命周期命令。Claude Code 可能使用受支持的二进制 exec 形式见下文其他 agent 使用与其 hook schema 匹配的原生单条命令字符串。捆绑的.sh与.ps1事件脚本只是兼容性回退不强制执行 capture-policy v1测试会强制它们之间的事件/agent 一一对应parity。Capture-policy 支持原生ai-memory.exe hook命令在 spool 或网络投递之前强制执行最近 marker 的[capture] ignore_paths策略遗留的.ps1与.sh路径则不会。升级后请重新运行install-hooks --agent agent --apply刷新原生 hook 条目selected-install 能力输出会说明强制执行是否生效。参见 Capture exclusions。关于该策略的落地方式从 hook.rs 可以看到完整调用链hook 先解析 payload 中的cwdcapture_policy()解析最近 marker 的[capture] ignore_pathspolicy.inspect()判定keep / drop / metadata-only三种处置最终按capture-modeallowlist/denylist持久化在 data dir 的capture-mode文件中决定是否放行。allowlist 模式下没有.ai-memory.tomlmarker 的仓库直接不产出任何捕获——这是 event 无关的硬门禁测试allowlist_gate_covers_events_that_never_reach_capture_policy专门钉死了这一点。Scenario E用 WinSW 把服务器变成常驻 Windows 服务Scenario C 和 D 都以ai-memory serve占据前台终端告终。试运行可以日常使用不行关窗口、注销或重启后服务器就没了。Linux 上packaging/systemd/ai-memory.service 提供了Restarton-failure与RestartSec5s。请注意韧性的归属——是 systemd 在做重启不是 ai-memory。原生 Windows 通过服务包装器获得同样的待遇。ai-memory 没有实现 Windows Service 控制码分发器所以用sc create或New-Service直接指向ai-memory.exe是行不通的SCM 启动进程后等待它报到永远等不到然后杀掉它。⚠️ 不要用任务计划程序 Start-Process启动服务器症状LastTaskResult 0永远报告成功服务器每次重启后消失没有崩溃对话框、没有 Application Error 事件、服务器日志在启动行之后再无一行。一个唯一症状是绿灯的失败正是这条警告存在的原因。坏形态是任务 action 为powershell.exe -File start-server.ps1而脚本用Start-Process启动ai-memory.exe任务触发powershell.exe运行脚本Start-Process启动ai-memory.exe后立即返回不等待子进程脚本无事可做powershell.exe退出。任务计划程序以返回码 0 记录实例完成操作日志事件 201/102任务计划程序把每个任务实例放进一个 job object。action 进程退出时job 被拆除所有仍归属于它的进程都被终止。ai-memory.exe是任务 PowerShell 的子进程从未脱离 job所以它在启动后的同一秒内随之死亡。因此服务器日志恰好只有一行——它自己的启动行——之后什么都没有。如果你确实想用任务计划程序去掉包装层把任务 action 直接指向ai-memory.exe参数带serve这样任务计划程序监控的进程就是服务器本身只要它运行就留在 job 里。同时还要任务设置为无论用户是否登录都运行以跨注销存活并在无交互会话下启动清除默认的3 天执行时限-ExecutionTimeLimit ([TimeSpan]::Zero)否则它会终止一个完全健康的长跑服务器显式设置失败重启-RestartCount、-RestartInterval。任务默认没有Restarton-failure。即便修正了那也是假装成服务的任务。更推荐下面的 wrapper。WinSW 配置WinSW 把任何控制台二进制包装成真正的 Windows 服务。它的配置是放在可执行文件旁边的单个 XML 文件无需单独安装服务管理器。WinSW 从自己的文件名推导配置文件名所以把下载的可执行文件改名并让 XML 使用相同基名$Dest $env:LOCALAPPDATA\ai-memory # 从 https://github.com/winsw/winsw/releases 下载匹配你运行时的 WinSW release #.NET Framework 4.6.1 或自包含 .NET 构建 # 固定具体 release tag 而非 latest并记录你装的是哪个版本—— # 它是作为服务运行的第三方二进制。 Move-Item .\WinSW-x64.exe $Dest\ai-memory-service.exeai-memory-service.xml放在旁边。把下面的C:\Users\you\AppData\Local\ai-memory替换成你展开后的$Dest——要写全路径不要在文件里留变量service idai-memory/id nameai-memory MCP server/name descriptionLong-term memory server for AI coding agents./description executableC:\Users\you\AppData\Local\ai-memory\ai-memory.exe/executable arguments--data-dir C:\Users\you\AppData\Local\ai-memory serve --transport http --bind 127.0.0.1:49374/arguments startmodeAutomatic/startmode onfailure actionrestart delay5 sec/ log moderoll/ /serviceonfailure actionrestart delay5 sec/是 SCM 恢复动作对应 systemd 单元的Restarton-failureRestartSec5s。这里务必使用绝对路径不要用%LOCALAPPDATA%。Windows 服务默认以LocalSystem运行%LOCALAPPDATA%会针对那个账户展开——指向C:\Windows\System32\config\systemprofile\AppData\Local——服务就会在一个你永远不会去看的地方悄悄服务一个空数据目录而你的真实 wiki 在你的 profile 里原封未动。要么像上面那样写全路径要么加serviceaccount块让服务以你的用户运行。安装并启动 $Dest\ai-memory-service.exe install $Dest\ai-memory-service.exe start $Dest\ai-memory-service.exe status # 验证服务器真的在应答而不只是显示 Running Get-Service ai-memory ai-memory statusstop、restart、uninstall是其余命令。因为 bind 是 loopback服务账户不影响可达性以你的用户运行的 agent 仍能访问127.0.0.1:49374。只有数据目录对账户敏感——这正是上面的绝对路径解决的问题。继续以你自己的用户运行install-mcp和install-hooks而不是以服务身份——它们写的是按用户划分的 agent 配置本页开头的规则依然适用。以上内容依据 WinSW 项目文档与 ai-memory CLI 接口验证随后由 #530 的报告者在真实硬件上端到端跑通并从任务计划程序事件 ID 根因定位了上述 job-object 失败模式。验证环境Windows 11 25H2build 26200.9168 WinSW v2.12.0WinSW-x64.exe ai-memory v1.38.0在提权 PowerShell 会话中、针对一次性的服务 id/端口/数据目录执行。已确认installstart服务以LocalSystem身份Running、StartType AutomaticMCPinitialize在绑定端口上得到应答绝对--data-dir生效未产生systemprofile\AppData\Local\ai-memory崩溃恢复——强杀被包装的ai-memory.exe后 8 秒内新进程开始应答与 5 秒onfailure延迟加启动时间一致以及干净的stopuninstall。服务配置为StartType Automatic实际开机启动未独立验证。验证时2026-08-31v2.12.0 是 WinSW 最新稳定版已发布的 3.x 均为预发布版。Native Hook CommandClaude Code 在 Windows 上在原生 Windows 上Claude Code hooks 默认使用 Claude 的exec form渲染command是真实的ai-memory.exe路径args是 argv 数组。这直接派生二进制而不是把一条带引号的字符串发给 shell或用一个bash -c包装.sh脚本{ type: command, command: C:\\Users\\you\\.cargo\\bin\\ai-memory.exe, args: [hook, --event, pre-tool-use, --agent, claude-code, --server-url, http://host:49374, --auth-token, ...] }这避免了每次工具调用都要拉起 Git Bash 外加cat/sed/curl子进程。Windows 上进程派生很昂贵因此原生路径每次 hook 大约快 3-5 倍在 i7-6700HQ 上实测约 735 ms shell → 约 150-205 ms 原生。要点二进制路径来自运行install-hooks的那个ai-memory所以cargo install --locked --path crates/ai-memory-cli会把它放到稳定的~/.cargo/bin路径上exec form 需要真实的可执行文件路径.exe不会通过 shell 运行.cmd/.batshim。install-hooks使用运行中ai-memory.exe的路径所以 release 二进制和 Cargo 构建的二进制都能直接工作.sh/.ps1脚本仍随包捆绑作为回退——Docker/setup-agent流程无本地二进制继续输出 shell 命令exec 形式的底层实现在 render_shared.rs 的windows_native_exec_spec()把--data-dir、hook --event 事件 --agent agent --server-url url、--auth-token、--project-strategy、--capture-assistant仅stop事件作为 argv 逐项渲染命令路径剥掉 Windows verbatim 前缀后原样给出。AI_MEMORY_HOOK_PLATFORM的五个取值在运行install-hooks之前设置该环境变量所选平台才会被烘焙进渲染出的 hook 命令。五个取值及语义取值渲染形态说明windows-nativeClaude exec-form 直接二进制调用原生 Windows 上的默认windowsPowerShell-EncodedCommand 暂存的.ps1脚本原生 Windows Docker-wrapper 的默认因为辅助容器无法把自己的 Linux 二进制装进宿主 hook 条目windows-bashbash -c Git Bash 里的.sh此前的默认想切回去、或作为不支持 exec form 的旧版 Claude Code 的回退时设置posixPOSIX.shLinux/macOS Docker-wrapper 的默认宿主无本地二进制原生安装想显式切回脚本时设置posix-nativemacOS/Linux 直接二进制调用exe hook --event …原生 macOS/Linux Claude Code 安装的默认cargo/release 二进制与windows-native对应。Linux/macOS Docker wrapper 强制posix宿主渲染的配置继续用.sh脚本从源码看这五个值对应 render_shared.rs 的解析逻辑from_env_override()统一解析环境变量大小写不敏感unix也映射到posixcurrent()/for_bash_runner()/for_bash_script_runner()三个入口分别服务本地安装 / Claude 类 bash 运行器 / setup-agent 脚本暂存三条渲染路径各自带自己的平台默认。这样同一个变量在三条路径上行为一致不会出现一个路径认、另一个路径忽略的漂移。另外两个与路径相关的细节项目自动 scope 把 Windows 反斜杠和 POSIX 斜杠视为同一种路径分隔符在比较 hookcwd、存储的repo_path和家目录兜底守卫时统一归一化wrapper 或测试需要一个不同于进程HOME的宿主家目录时可设置AI_MEMORY_HOME它会在启动自愈或 cwd 前缀匹配前经过同一条路径边界归一化。调优 Spool 时序高延迟实例原生 hook 在本地 spool 事件。session-start在拉取 handoff 前做一次短的有界清理排空session-end启动一个分离的hook-drain辅助进程避免大量积压拖住 Claude Code 等 agent 不退出。内置时序在 agent 面对路径上保持很短但高延迟或大积压实例可以用整分钟级别的覆盖来调大。与AI_MEMORY_HOOK_PLATFORM不同这些变量是hook 在运行时读取的因此只需设置在 agent 的环境里即可生效无需重新运行install-hooks。原生 hook 接受带或不带单个前置 UTF-8 BOM 的合法 JSON某些 PowerShell 管道在向原生进程写入时会加上这个标记。任何其他畸形 stdin 都不会被 spool 或发送hook 向 stderr 打印一条固定警告、stdout 返回{}并以成功退出绝不会弄坏宿主 agent。警告内容永不包含 payload。环境变量内置默认最大覆盖限制什么AI_MEMORY_HOOK_DRAIN_TIMEOUT_MINUTES3 秒60 分钟排空期间每个事件 POSTAI_MEMORY_HOOK_HANDOFF_TIMEOUT_MINUTES3 秒60 分钟同步session-starthandoff GETAI_MEMORY_HOOK_START_BUDGET_MINUTES3 秒60 分钟session-start等待排空锁与清理排空的总时间AI_MEMORY_HOOK_BACKGROUND_DRAIN_BUDGET_MINUTES5 分钟60 分钟分离的hook-drain在session-end后可花费的总时间AI_MEMORY_HOOK_INCREMENTAL_THRESHOLD32 个事件正整数触发 250 mspost-tool-use追赶排空的 spool 积压规模时序值必须是正整分钟。缺失、空、非数字或零值回退到内置默认超过 60 的值被钳制。增量阈值是正事件数非法值回退到 32。session-start预算限制 hook 在拉取 handoff 前最多阻塞多久后台预算限制session-end后的分离清理不会让 agent 等待。这些常量在 hook.rs 中有精确对应DEFAULT_DRAIN_TIMEOUT 3s、DEFAULT_HANDOFF_TIMEOUT 3s、DEFAULT_START_BUDGET 3s、DEFAULT_BACKGROUND_DRAIN_BUDGET 5min、MAX_OVERRIDE_MINUTES 60、DEFAULT_INCREMENTAL_THRESHOLD 32、INCREMENTAL_DRAIN_BUDGET 250ms。解析函数parse_minutes()实现了缺省回退 60 分钟钳制的全部规则。Windows 上还有一个特有的锁语义细节被争用的排空锁可能以原生ERROR_LOCK_VIOLATION错误码报告而不是 Rust 的WouldBlock错误种类。ai-memory 把两者都视为正常的锁忙状态因此并发排空会按照同一套 spool 时序规则等待、跳过或过期而不是让 hook 失败。当前 Harness 注意事项Windows hook 支持是新的需要针对原生 Windows agent 构建做真实环境测试。ai-memory.exe中没有 Windows Service 分发器持久化来自包装器Scenario E正如 Linux 上来自 systemdClaude Code 可在 Windows 原生使用也可在 WSL2 内使用。原生 Claude Code 默认把 hooks 作为直接二进制调用无 shell执行AI_MEMORY_HOOK_PLATFORMwindows-bash恢复 Git Bashbash -c路径。WSL2 里的 Claude Code 使用常规 WSL.sh路径Codex、Command Code、Devin CLI、OpenCode、Cursor、Gemini CLI、Antigravity CLI、Grok Build CLI、Zero、Kimi Code、OpenClaw 可能各自选择不同的 Windows 配置位置或 shell 执行行为。ai-memory 使用当前最佳已知默认值但需要在实际安装上验证MCP over HTTP 对路径的敏感度应低于 hooks但install-mcp --apply仍写入 client 专属配置文件请确认 agent 确实加载了它OpenClaw、OpenCodev1ai-memory.ts加 2 beta 的ai-memory-opencode2.ts、OMP / Oh My Pi 和 Pi 使用生成的 TypeScript 集成而不是 shell hook 捆绑因此它们的 Windows 行为取决于宿主运行时是否正确加载这些文件。Pi 的生成扩展还桥接了 MCP 工具因为 Pi 没有原生mcp.json安装面。建议的测试清单WSL2 模式所有 install 命令都在 WSL2 内运行确认生成的 hook 命令引用 WSL 路径下的.sh文件从 WSL2 启动 agent在 agent 中调用memory_status记录ai-memory status发一条 prompt然后确认其sessions或observations计数增加。原生 Windows 模式所有 install 命令都在 PowerShell 或cmd.exe中用ai-memory/ai-memory.ps1运行确认生成的 hook 命令与 agent 匹配Claude Code 应使用原生…ai-memory.exe hook --event …命令或在AI_MEMORY_HOOK_PLATFORMwindows-bash时用bash -c.sh其他脚本 hook agent 应使用powershell.exe ... -EncodedCommand payload条目指向 Windows 家目录下生成的.ps1hooks启动原生 Windows agent在 agent 中调用memory_status记录ai-memory status发一条 prompt然后确认其sessions或observations计数增加。上报时请说明测试的模式、使用的 agent 与版本以及 hook 命令是执行成功还是因路径/shell 错误失败。内置/web浏览器列出的是编译后的 wiki 页面那里零页面并不代表原始 hook 观察被遗漏。总结ai-memory 的 Windows 支持围绕安装环境 运行环境这一原则展开通过 render_shared.rs 中五种HookCommandPlatform的统一渲染机制把同一个安装逻辑映射到 WSL2 的.sh脚本、Windows 的 PowerShell-EncodedCommand以及最快、最省进程开销的原生 exec-form 二进制调用。无论是追求最 Linux 化的全 WSL2 方案、最省事的 Docker Desktop wrapper、零工具链的 release 二进制还是用于开发的源码构建最终都能通过 WinSW 把服务器变成跨重启的常驻服务——前提是避开任务计划程序的 job-object 陷阱并用绝对路径写死数据目录。记住升级 wrapper 或镜像后重跑一遍install-hooks --apply让既有 hook 条目跟上最新的命令形态。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考