LWC，一款 Agent 主动式记忆工具，欢迎试用
## LWC——由 Agent 自主安装、维护并持续成长的记忆系统
大多数 Agent 其实并没有真正的记忆。
它们搜索原始文件、重新推导答案，然后在会话结束时丢弃有价值的综合成果。下一次会话又几乎从零开始，重复同样的调查过程。
**LWC （`llm-wiki-cli`）**为编程 Agent 提供持久、基于来源的记忆，并让知识在工作过程中不断积累。
它最关键的区别是：**Agent 掌管记忆的完整生命周期。**
Agent 自主安装 LWC 、召回已有知识、阅读新来源、更新概念、记录矛盾、维护引用，并将值得保留的发现写回长期记忆。
人类负责定义目标、提供来源、提出问题和审查结果，但被明确排除在日常记忆维护之外。
### 人类不是记忆的编辑者
LWC 不是一个附加了 AI 助手的人类笔记应用。
在正常使用中，人类不应手动操作 CLI 、编辑 SQLite 数据库或修改生成的 Wiki 页面。Agent 是唯一的写入者。
SQLite 是记忆的权威存储；相互链接的 Markdown Wiki 则是可重建、供人阅读的投影。你可以使用 Obsidian 或其他 Markdown 工具查看它，但它不是写入接口。
这种分工很重要。一旦人类和 Agent 同时编辑同一份记忆，引用就可能漂移，关系可能失去一致性，来源信息可能消失，最终没人知道哪个版本才是权威。
LWC 选择了更严格的边界：
```
人类 → 目标、来源、问题、审查
Agent → 召回、推理、维护、写回
LWC → 持久化、来源追踪、索引、图、历史
```
人类控制意图，Agent 对记忆负责。
### 记忆是一张图，而不是一堆笔记
LWC 不只是不断生成 Markdown 文件，它还会构建一张可遍历的记忆图，连接：
- 不可变的来源及其历史版本；
- 概念、决策、综合结论和查询结果；
- 引用与明确的来源类型；
- Wiki 链接与语义关系；
- 矛盾和历史变化；
- 通过 CodeGraph 接入的代码符号与依赖关系。
即使不知道准确关键词，Agent 也可以直接探索这张图：
```
lwc graph neighbors page:architecture
lwc graph path page:implementation page:policy
lwc graph impact page:policy
lwc cg callers UserService
lwc cg callees UserService
lwc cg impact UserService
```
这使 Agent 能够回答：
- 哪些内容依赖这项决策？
- 哪些概念由相同的来源支撑？
- 如果这项策略发生变化，会影响什么？
- 新来源与现有知识在哪里发生冲突？
- 哪些代码实现了这条架构规则？
- 修改这个符号会影响哪些调用方？
自动生成的图边仅限结构性和证据性事实。语义关系则是明确、带类型且可审计的，并可根据需要记录来源、理由、证据和置信度。
LWC 可以使用 Grafeo 或嵌入式 SurrealDB 遍历物理文档图。集成的 CodeGraph 层则把持久化的项目知识与代码库结构连接起来。
### 它是记忆，而不是查询时 RAG
典型的 RAG 工作流是：
```
问题 → 检索片段 → 生成答案 → 遗忘
```
LWC 会保留其中真正有价值的工作：
```
任务 → 召回已经维护的记忆
→ 基于来源和既有综合成果进行推理
→ 更新页面、引用和关系
→ 将改进后的记忆留给下一次会话
```
LWC 仍然支持文档、段落和句子级检索，但检索只是记忆系统中的一种操作，而不是整个系统的组织原则。
优秀的答案不必消失在聊天记录里。Agent 可以将其转化为持久的决策、概念、操作手册或综合页面，并连接到支撑它们的证据。
### 本地、确定性、Agent-first
LWC 是一个由 SQLite 支持的 Rust CLI 。
它提供：
- 不可变、基于 SHA-256 去重的来源；
- 文档、段落和句子级召回；
- 支持 CJK 的确定性多语言词法搜索；
- 引用与明确的来源追踪；
- 来源版本跟踪与有界差异比较；
- 知识图与 CodeGraph 遍历；
- 支持验证和回滚的事务变更集；
- 项目级与全局记忆作用域；
- 可重建的 Markdown 投影；
- 本地只读 Wiki 与图查看器；
- 面向受支持 Agent 的原生 Skills 、Instructions 、Hooks 和 MCP 集成。
它不需要托管的 LLM API 、Embedding 模型、向量数据库或后台守护进程。
你现有的 Agent 负责推理，LWC 提供记忆协议和持久化层。
### 让 Agent 自己安装 LWC
既然 LWC 是为 Agent 设计的，推荐的安装方式自然也不是让人类手动执行 Shell 命令。
将下面这段提示词粘贴给 Codex 、Claude Code 、OpenCode 、Cursor 或你常用的编程 Agent：
```
为当前用户和你自己的 Agent 运行时完整安装并配置 LWC 。
以 https://github.com/JanYork/llm-wiki-cli 为唯一可信来源。安装前阅读项目的 README 、SECURITY.md 和官方 using-lwc Skill 。
安装经过校验和验证的官方 LWC CLI 与规范 Skill ，初始化全局记忆，在支持的情况下配置原生 Instructions 和生命周期 Hooks ，并保留用户现有的所有配置。
除非我明确要求，否则不要初始化项目 Wiki 。完成后验证 CLI 、Skill 、配置、Hooks 和 Agent 集成是否正确安装。
请直接执行并完成安装，而不是只告诉我应该运行哪些命令。
```
Agent 会识别自己的运行时和原生配置规范，安装对应组件，保留已有配置并验证最终结果。
README 中仍然提供 npm 、Shell 和 Cargo 手动安装方式，供维护者和调试场景使用。
LWC 的灵感来自 Andrej Karpathy 的 LLM Wiki 模式和 Vannevar Bush 的 Memex——而其中一直缺失的记忆维护者，如今终于可以交给 Agent 。
**仓库：** [https://github.com/JanYork/llm-wiki-cli](https://github.com/JanYork/llm-wiki-cli)
如果你正在构建长期运行的编程 Agent 、自主研究工作流、项目记忆，或者任何应该由 Agent 而不是人类负责记忆的知识系统，非常欢迎提供反馈。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233920)
大多数 Agent 其实并没有真正的记忆。
它们搜索原始文件、重新推导答案，然后在会话结束时丢弃有价值的综合成果。下一次会话又几乎从零开始，重复同样的调查过程。
**LWC （`llm-wiki-cli`）**为编程 Agent 提供持久、基于来源的记忆，并让知识在工作过程中不断积累。
它最关键的区别是：**Agent 掌管记忆的完整生命周期。**
Agent 自主安装 LWC 、召回已有知识、阅读新来源、更新概念、记录矛盾、维护引用，并将值得保留的发现写回长期记忆。
人类负责定义目标、提供来源、提出问题和审查结果，但被明确排除在日常记忆维护之外。
### 人类不是记忆的编辑者
LWC 不是一个附加了 AI 助手的人类笔记应用。
在正常使用中，人类不应手动操作 CLI 、编辑 SQLite 数据库或修改生成的 Wiki 页面。Agent 是唯一的写入者。
SQLite 是记忆的权威存储；相互链接的 Markdown Wiki 则是可重建、供人阅读的投影。你可以使用 Obsidian 或其他 Markdown 工具查看它，但它不是写入接口。
这种分工很重要。一旦人类和 Agent 同时编辑同一份记忆，引用就可能漂移，关系可能失去一致性，来源信息可能消失，最终没人知道哪个版本才是权威。
LWC 选择了更严格的边界：
```
人类 → 目标、来源、问题、审查
Agent → 召回、推理、维护、写回
LWC → 持久化、来源追踪、索引、图、历史
```
人类控制意图，Agent 对记忆负责。
### 记忆是一张图，而不是一堆笔记
LWC 不只是不断生成 Markdown 文件，它还会构建一张可遍历的记忆图，连接：
- 不可变的来源及其历史版本；
- 概念、决策、综合结论和查询结果；
- 引用与明确的来源类型；
- Wiki 链接与语义关系；
- 矛盾和历史变化；
- 通过 CodeGraph 接入的代码符号与依赖关系。
即使不知道准确关键词，Agent 也可以直接探索这张图：
```
lwc graph neighbors page:architecture
lwc graph path page:implementation page:policy
lwc graph impact page:policy
lwc cg callers UserService
lwc cg callees UserService
lwc cg impact UserService
```
这使 Agent 能够回答：
- 哪些内容依赖这项决策？
- 哪些概念由相同的来源支撑？
- 如果这项策略发生变化，会影响什么？
- 新来源与现有知识在哪里发生冲突？
- 哪些代码实现了这条架构规则？
- 修改这个符号会影响哪些调用方？
自动生成的图边仅限结构性和证据性事实。语义关系则是明确、带类型且可审计的，并可根据需要记录来源、理由、证据和置信度。
LWC 可以使用 Grafeo 或嵌入式 SurrealDB 遍历物理文档图。集成的 CodeGraph 层则把持久化的项目知识与代码库结构连接起来。
### 它是记忆，而不是查询时 RAG
典型的 RAG 工作流是：
```
问题 → 检索片段 → 生成答案 → 遗忘
```
LWC 会保留其中真正有价值的工作：
```
任务 → 召回已经维护的记忆
→ 基于来源和既有综合成果进行推理
→ 更新页面、引用和关系
→ 将改进后的记忆留给下一次会话
```
LWC 仍然支持文档、段落和句子级检索，但检索只是记忆系统中的一种操作，而不是整个系统的组织原则。
优秀的答案不必消失在聊天记录里。Agent 可以将其转化为持久的决策、概念、操作手册或综合页面，并连接到支撑它们的证据。
### 本地、确定性、Agent-first
LWC 是一个由 SQLite 支持的 Rust CLI 。
它提供：
- 不可变、基于 SHA-256 去重的来源；
- 文档、段落和句子级召回；
- 支持 CJK 的确定性多语言词法搜索；
- 引用与明确的来源追踪；
- 来源版本跟踪与有界差异比较；
- 知识图与 CodeGraph 遍历；
- 支持验证和回滚的事务变更集；
- 项目级与全局记忆作用域；
- 可重建的 Markdown 投影；
- 本地只读 Wiki 与图查看器；
- 面向受支持 Agent 的原生 Skills 、Instructions 、Hooks 和 MCP 集成。
它不需要托管的 LLM API 、Embedding 模型、向量数据库或后台守护进程。
你现有的 Agent 负责推理，LWC 提供记忆协议和持久化层。
### 让 Agent 自己安装 LWC
既然 LWC 是为 Agent 设计的，推荐的安装方式自然也不是让人类手动执行 Shell 命令。
将下面这段提示词粘贴给 Codex 、Claude Code 、OpenCode 、Cursor 或你常用的编程 Agent：
```
为当前用户和你自己的 Agent 运行时完整安装并配置 LWC 。
以 https://github.com/JanYork/llm-wiki-cli 为唯一可信来源。安装前阅读项目的 README 、SECURITY.md 和官方 using-lwc Skill 。
安装经过校验和验证的官方 LWC CLI 与规范 Skill ，初始化全局记忆，在支持的情况下配置原生 Instructions 和生命周期 Hooks ，并保留用户现有的所有配置。
除非我明确要求，否则不要初始化项目 Wiki 。完成后验证 CLI 、Skill 、配置、Hooks 和 Agent 集成是否正确安装。
请直接执行并完成安装，而不是只告诉我应该运行哪些命令。
```
Agent 会识别自己的运行时和原生配置规范，安装对应组件，保留已有配置并验证最终结果。
README 中仍然提供 npm 、Shell 和 Cargo 手动安装方式，供维护者和调试场景使用。
LWC 的灵感来自 Andrej Karpathy 的 LLM Wiki 模式和 Vannevar Bush 的 Memex——而其中一直缺失的记忆维护者，如今终于可以交给 Agent 。
**仓库：** [https://github.com/JanYork/llm-wiki-cli](https://github.com/JanYork/llm-wiki-cli)
如果你正在构建长期运行的编程 Agent 、自主研究工作流、项目记忆，或者任何应该由 Agent 而不是人类负责记忆的知识系统，非常欢迎提供反馈。
---
原文链接：[点击查看](https://www.v2ex.com/t/1233920)
评论
暂无评论。