企业官网建设流程全解析

OpenLore 是一个极简、可扩展、agent 原生的 AI 知识仓库（knowledge repository）：你只需要指向一个 Markdown 文件夹，团队里的每个 AI Agent——无论是 Claude Code、Codex、Cursor 还是 CI 任务——都能读取完全相同的文件。它没有向量数据库、没有摄取管道、没有 SDK，知识就是普通的 Markdown，随时可以检查、随时可以治理。📜

为什么需要 OpenLore？一个真实痛点

当你的团队开始让多个 AI Agent 参与工作时，会遇到一个尴尬的局面：

• 每个 Agent 各自维护一份"上下文"，版本很快就不一致；
• 想让不同 Agent 看到不同的内部文档，靠 git 仓库很难精细控制权限；
• 接入向量数据库方案，又要部署数据库、写摄取管道、学一套检索 API，维护成本远超知识本身的价值。

OpenLore 的思路很直接：把共享上下文当成基础设施，而不是检索问题。一份 Markdown 目录就是一个"知识仓库"，更新一次文件，所有 Agent 下次读取时自动看到新版本。

告别向量数据库：OpenLore 与 RAG 方案的核心区别

这是理解 OpenLore 的关键：

换句话说，OpenLore 不需要 Agent"学习"一套专属的检索 API——它使用 Agent 本来就熟悉的 shell 组合模式，在虚拟文件系统上工作。相关说明见官方介绍 docs/introduction.md。

一张图看懂 OpenLore 工作原理

整个连接过程可以概括为 4 步：

1. Authenticate（认证）——通过免密、SSH key、证书、passkey 或 OAuth 登录解析出一个身份（identity）；
2. Compose a view（组装视图）——只挂载该身份被授权的 docsets 和路径；
3. Explore（探索）——在该视图上执行纯 Go 实现的 shell 命令，或通过 MCP 的shell工具；
4. Contribute safely（安全贡献）——开启写权限后，整个文件变更先经过授权与校验，再原子提交。

一个重要的安全设计：这里的"shell"是内存中的 Go 解释器，不是真正的操作系统 shell。普通会话里没有bash、exec、curl，没有进程执行，也没有环境网络访问，详见 SECURITY.md。

快速上手：3 步跑起你的 OpenLore 知识仓库

第 1 步：安装

# macOS / Linux（Homebrew） brew install --cask aakarim/tap/lore

Linux 和 Windows 也可以直接下载 release 二进制文件，具体见 docs/quickstart.md。如果需要从源码构建，可先克隆仓库：

git clone https://gitcode.com/gh_mirrors/ope/OpenLore

第 2 步：指向你的 Markdown 目录

openlore ./docs

启动后：SSH 监听2222端口，Web 视图和 MCP 端点共享8080端口，./docs的内容出现在/下。就这么简单。

第 3 步：接入你的 Agent

# Claude Code（MCP） claude mcp add --transport http openlore http://localhost:8080/mcp # Codex（MCP） codex mcp add openlore --url http://localhost:8080/mcp # 任何带 shell 的 Agent（SSH） ssh -p 2222 localhost "grep -r 'retry' /"

还可以让 OpenLore 自动生成使用说明，粘贴到团队的AGENTS.md中：

ssh -p 2222 localhost agents >> AGENTS.md

甚至可以让 Agent 自己完成整个安装配置：

ssh openlore.sh teach | claude

同一个知识表面，多种传输方式

OpenLore 的核心理念是一份虚拟文件系统，多种传输方式（transports）：

• SSH——传统终端体验，grep、find、ls全套可用；
• SFTP / SSHFS——可以直接在 VS Code 里浏览和编辑远程知识文件，无需本地镜像；
• MCP——为 Claude Code、Codex、Cursor、OpenCode 等 MCP 客户端提供shell工具；
• Web 视图——人类友好的浏览器查看界面，还带分析 Dashboard。

各传输方式共享同一份文件系统视图，具体行为见 docs/transports.md，完整用法见 docs/usage.md。

访问控制：让每个 Agent 只看到它该看的

当多个 Agent 接入后，你一定会希望它们看到不同的内容。OpenLore 用docsets和identities来组织这件事，配置写在lore.json里：

{ "docsets": { "public": { "paths": ["/public"], "access": { "allow": { "guest": "ro" } } }, "backend": { "paths": ["/backend"], "access": { "allow": { "backend": "rw" } } } }, "roles": { "backend": {} }, "identities": [ { "name": "backend-agent", "public_key": "ssh-ed25519 AAAA…", "roles": ["backend"] } ] }

• 一个docset就是一组路径 + 访问规则；
• 一个identity就是一把 SSH key、passkey 或 OAuth 登录 + 角色；
• 权限模型支持ro（只读）、publish（发布）、rw（读写）三种授予级别，还支持路径别名和私有 home 目录。

以backend-agent身份连接的 Agent 只能看到/backend，其他人最多看到/public。docset 的完整规则（嵌套、授予、别名、fail-closed 校验）见 docs/docsets.md。

治理化写入：默认只读，开启后也安全

OpenLore默认只读。当你决定开启写权限时，所有写入只走一条策略受控的写入路径，它会依次检查：

1. 谁在写——身份与 docset 授权是否匹配；
2. 文件是否合规——是否通过该目录的 folder rules；
3. 内容是否过期——比较交换（compare-and-swap）保护，过期写入直接拒绝而不是合并。

典型的受控写入长这样：

# 让 Agent 向 inbox 发布成果，但不能编辑其他任何东西 echo "# Findings" | publish /backend/research/findings.md # 应用补丁 cat change.diff | patch /backend/api.md

写入是整文件原子交换，插件还可以在提交前校验或延迟写入。用户侧配置见 docs/writing.md，内部实现见 docs/write-system.md。

OpenLore 适合哪些场景？

• 团队共享的 Agent 记忆——给多个 Agent 共享或隔离的 docset，让它们发布发现、交接工作、跨会话积累上下文；
• 编码 Agent 的内部文档库——把 API 文档、runbook、架构笔记放在一个可 grep 的熟悉接口后面；
• 团队工件仓库——共享 Markdown、JSON 等文档，比 git 更自然，比 Wiki 工具更 agent 原生；
• 受治理的知识贡献——贡献者向 inbox 发布内容，现有文档保留给维护者，防止误覆盖；
• 可移植的知识包——把文档嵌入自包含的二进制文件，或打包为桌面 MCP 扩展；
• 公开文档站点——开启公共访问后，任何路过的 Agent 都能读到你的公开知识，改善 AEO/GEO。

什么情况下你需要 OpenLore？

一个简单判断标准（来自官方 FAQ）：

• 只有一个 Agent、一个仓库——把 Markdown 放在仓库里就够了，不需要 OpenLore；
• 多个 Agent、多个仓库、多个人需要同一份知识，并且你需要明确"谁能读、谁能写、谁能发布"——这正是 OpenLore 的定位。

总结：把知识从"检索问题"变回"基础设施"

OpenLore 用极小的代价解决了 AI Agent 时代的一个实际问题——共享上下文：

✅ 单个 Go 二进制，无向量数据库、无管道、无 SDK； ✅ 知识永远是普通 Markdown，人类和 Agent 都能直接检查； ✅ Agent 用它们已经会用的cat、grep、find，零学习成本； ✅ 身份、docset、角色三级访问控制，写入原子且受治理； ✅ 纯 Go shell 解释器，安全设计内建。

安装、服务一个文件夹、接入 Agent——三步之后，你的团队就拥有了一个可持续更新、可检查、可治理的极简 AI Agent 知识仓库。更多资料可从 openlore.yml 参考、命令参考 和配置示例 openlore.yml.example、lore.json.example 入手。