mcpField
F
Firekeep

Firekeep

本地服务
firekeep.ai记忆与知识31 天前更新

关于 Firekeep

Firekeep 是自托管的运行层,可在 AI Agent 和 MCP 客户端之间延续知识、工作状态与协作信息。它面向希望跨会话和运行环境复用经验的个人与团队,并提供可检查的证据和治理控制。

主要功能

  1. 01跨会话记忆与检索
  2. 02共享协作与任务队列
  3. 03会话状态与交接简报
  4. 04操作策略与流程执行约束
  5. 05可回放的追踪记录与证据
  6. 06文档和代码分析

适用场景

  1. 01在不同 Agent 运行环境间复用已验证修复
  2. 02在上下文压缩或中断后恢复工作
  3. 03协调多个 Agent 处理共享任务
  4. 04审查并执行获批流程

MCP 相关

Firekeep 通过本地 MCP 网关将兼容客户端连接到共享的自托管 Keep。客户端可用 MCP 工具记录和检索上下文,也可使用协作与操作策略功能。

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置
{
"mcpServers": {
"kapella-hub-firekeep": {
"command": "uvx",
"args": [
"firekeep-client"
]
}
}
}
启动命令uvx firekeep-client

本地服务需要在你的电脑上安装运行环境(如 Node.js 18+)。各客户端的配置文件位置不同,请参考客户端文档。

安装包
pypifirekeep-client1.8.2

工具

1

收录的工具列表 · 更新于 3 天前

此工具无需参数。

详细介绍

Firekeep

你的 Agent 不该像陌生人一样协作。

通过一个共享的、可自托管的 Keep,连接 Claude Code、Codex、Kiro、OpenCode 和其他 MCP 客户端。

每解决一个问题,都应让下一个问题更容易解决。Firekeep 会保存工作过程中的经验——持久知识、工作状态、操作流程、协作信息和可检查的证据——并在下一个会话、工具或机器中重新发挥作用。

在一台工作站上使用它,保持自己的工作连续性。需要时再添加团队成员,无需从头重建团队上下文。

网站 · 安装 · 产品导览 · Firekeep Studio · 证据 · 隐私 · 支持


一个 Keep,跨越多种运行时

flowchart LR
    A["Claude Code<br/>stores a proven fix"] --> K[("your self-hosted<br/>Keep")]
    K --> B["Codex<br/>recalls the fix + evidence"]
    K --> C["Kiro<br/>reuses the procedure"]
    K --> D["OpenCode / MCP client<br/>continues informed"]

Agent 保留各自原生的界面和由提供方管理的会话。能够延续下去的是它们通过同一个本地 MCP 网关明确记录和取用的 Firekeep 上下文。这意味着,一个人可以切换工具而不丢失上下文,团队也可以只积累一次上下文,并在后续工作中持续使用。

了解 Claude Code 和 Codex 如何共享一个 Keep →

安装 Firekeep

安装程序会一并配置 Claude Code、Codex、Kiro 和 OpenCode(如果 Claude Desktop 的配置目录存在,也会配置它),随后询问你要将 Firekeep 服务部署在哪里。完整的设置流程请参阅**安装指南**。

curl -fsSL 'https://firekeep.ai/latest/install?src=github' | sh    # macOS / Linux
irm 'https://firekeep.ai/latest/install.ps1?src=github' | iex      # Windows PowerShell

服务可运行于 linux/amd64 或 linux/arm64(v1.6.2 之后的服务版本;v1.6.2 及更早版本仅支持 amd64),需要 Docker Compose v2、双核 CPU 和 Git;默认堆栈建议配备 16 GB RAM。默认绑定到 127.0.0.1。选择主机前,请参阅**要求与配置说明**。

首次尝试 Firekeep?分享哪些做法有效,以及你在哪一步遇到了困难 →

运行时支持范围

  • **客户端套件:**一并配置 Claude Code、Codex、Kiro 和 OpenCode;如果 Claude Desktop 的配置目录存在,也会添加它。其他 MCP 客户端可使用通用接入方式。
  • **Claude Code:**托管式 MCP、指令和生命周期钩子。其支持的工具调用前钩子可以硬性阻止编辑、写入或 Shell 操作。
  • **Codex:**托管式 MCP 和 AGENTS.md 指引。Codex 不提供原生钩子,因此不能据此推断其支持生命周期自动化和编辑前强制拦截。
  • **Kiro CLI:**配置了 MCP、引导规则和生命周期钩子的命名 Firekeep Agent。在已验证的 Kiro CLI 2.12.1 功能中,其编辑前钩子仅提供建议。
  • **Firekeep Studio:**在一个桌面工作区中运行 Codex、Claude Code、Kiro CLI 和 Grok。直接使用 Grok 适配器时,不支持 Keep 记忆、钩子或工作简报;Studio 会明确说明这一限制,而不会沿用其他运行时的状态。

维护中的详细信息请参阅**集成指南和Studio 运行时矩阵**。

可衡量的检索,附带评测方法

在 2026-08-28 LongMemEval-S 的认可评测中,Firekeep 达到了 97.7% Evidence Recall@10:在评分的 470 个问题中,有 459 个问题的前十条结果中至少出现了一个带标签的证据会话。该指标评估的是检索,而非生成答案的准确率;这是一次经过校正的确定性运行结果,并非多次运行得到的置信区间。

评测方法 · 结果数据

Firekeep 解决的问题

人们不会通过从头重读每封电子邮件、每份文档、每个工单或每个源文件来积累专业判断力。他们会记住发生了什么、某项决策为何奏效、如何诊断故障,以及哪种流程在实践中经受住了考验。这些经验会改变他们处理下一个问题的方式。

Agent 也应该以同样的方式不断进步。Firekeep 将工作背后的知识、工作状态、协作协调和证据连接起来,让下一个 Agent 能够借助上一个 Agent 积累的经验开始工作。

详细能力图谱

能力含义
MemoryAgent 会跨会话记住哪些做法有效、哪些失败,以及哪些内容至关重要。支持语义检索和图检索、置信度评分、矛盾处理,以及四种记忆类型(参考型/程序型/情景型/瞬时型),并根据类型调整回忆衰减;支持可恢复的归档优先老化,以及注重令牌用量的回忆,并可选择由 LLM 进行综合。系统会根据记录的会话结果(按结果加权记忆),以及 Agent 对实际采取行动的知识所提供的反馈(memory_feedback),重新排列回忆结果。
Knowledge Autopilot知识库会自行维护,但不会擅自做决定。当两条未经确认的记忆确实相互冲突时,不会悄悄丢弃任何一条——两条都会保留以供回忆,并标记为有争议,直到人工裁定(/memory/contested/resolve)。会话清理器会结束崩溃或被搁置的会话,使失败计入结果评分。每个审核队列(草稿技能、过时技能、流程提案、有争议的记忆对、评估死信)都会汇入同一个收件箱,并附有每周摘要;/memory/{id}/evidence 会在一次读取中展示影响记忆排名的所有信号。
Fleet-as-GPU (Night Shift)已连接 Agent 的机器会在夜间使用本地模型为知识库处理任务,且只会生成草稿。会话结束钩子会为每个会话排入一个蒸馏任务;服务端的夜间处理流程会为每项过时技能排入一个任务(重新编写它),并为每对有争议的记忆排入一个任务(提出裁定建议);firekeep night-shift 会处理队列——只要会话开始时 LM Studio 或 Ollama 正在运行,系统就会为你启动它。每份草稿仍须由人工启用,每对记忆也须由人工裁定;Autopilot 标签页会按任务类型显示批准率台账,表明是否值得保留整个 Agent 群组的工作成果。
Team Continuity记忆带有经过验证的工作区/成员来源信息,以及不可信的运行时 agent_id 标签和项目。按贡献者划分的活动报告和由 LLM 综合生成的交接简报,让一个 Agent 能接续另一个 Agent 尚未完成的工作。
Session Continuity通过会话工具记录的计划、决策和进度会在上下文压缩后保留。系统会在下次启动时自动检测崩溃的会话,并提供恢复选项,同时在影子上下文中嵌入定期生成的工作区快照(git 分支、近期提交、差异统计)。
Environment Awareness配置的 Docker、git 和文件采集器会监控运行状态,而不只是依赖提示词。容器重启、新提交和文件变更都会进入可重放的事件流。
Agent Coordination提供共享频道、公告板、结构化任务队列、带单调递增围栏令牌的资源租约、在线状态注册表和直接消息。并发 Agent 可以分配工作、跟踪进度,并通过租约避免编辑冲突;启用钩子的客户端会在其他 Agent 已持有文件租约时阻止编辑。
Predict-then-Act GatewayAgent 会在执行重大操作前声明意图(action_before → `allow
SkillsAgent 通过 skill_create 工具(在客户端执行,并使用完整会话上下文)编写可复用的“遇到 X 时该怎么做”操作手册;文档→技能流水线会在人工审核下从 wiki/运行手册中起草更多技能。匹配度最高的技能会注入下次会话的简报中。(服务端自动综合功能由 SKILL_SYNTHESIS_ENABLED 控制,但默认关闭——仅使用 CPU 的部署无法在可行时间内运行生成 LLM。)
Enforced Runbooks步骤带有命令匹配器的技能就是可由人工启用的运行手册:advise(第 1 轮建议)、require_ack(匹配的命令会受到质询,只有经过审计的确认后才会继续——一次性许可绑定到工作区、成员、会话、命令哈希、步骤、套件版本和执行),或 block(默认拒绝,并要求服务端回执,客户端只有收到后才会接受允许)。证据按成功评分——只有命令以 0 退出时,该步骤才计为成功;每个强制执行事件都会记入偏差台账(仪表板+收件箱),其中保存命令哈希,绝不保存命令文本。模式只能由人工通过仅限管理员的路由设置;Agent 可以提出运行手册,但不能启用它们。通过 PROCEDURE_ENABLED 选择启用,目前正在我们自己的部署中进行内部试用——请参阅 docs/guides/living-procedures.md。
Decision Board当澄清事项需要的问题不止一两个时,Agent 会打开一个本地浏览器看板,其中预先填入从团队记忆中检索到的证据——提出更好的问题,并结合团队已有的经验。本地网关会代理 Decision Board 流程和 Cortex /decision/synthesize。
Living Instructions指令层会衡量自身效果:通过确定性重放计算逐条指令的合规情况表(会话是否在回答前进行回忆、是否边进行边记录、是否声明重大操作),并提供趋势、按运行时细分的结果和暴露回执——会话会携带实际传达给它们的指令文本内容哈希;任何无法验证的内容都会报告为未知,而不计入统计。这一设计诚实反映了自身局限:它衡量的是行为,而非行为是否有所帮助。由 Agent 群组起草的改写版本仍需人工裁定并进行 A/B 验证,此功能已列入路线图。
Trust Ledger按 Agent 建立的任职记录,基于 Agent 通过网关发出的声明(action_before/action_after):声明的操作数量、核对率、预测匹配校准度(根据声明的置信度与核对结果计算 Brier 分数)、反转次数、会话数、首次/最近出现时间。仅用于查看——它只报告,不会设置门槛。其设计本身诚实透明:校准度反映的是行为,而非能力;系统只会看到已声明的操作;agent_id 是自行报告的标签,因此记录按声明的身份归属;低于阈值时,校准度会显示信号不足,而非凭空捏造数值。将记录转化为已获得自主权的能力代理(强制执行部分)已列入路线图。
Auto-Evals + Pattern Discovery在会话完成时,根据重放轨迹计算质量指标。模式检测已启用;自动晋级/验证和 A/B 实验端点均已实现,但默认关闭,直到部署拥有足够的会话量以便负责任地使用这些功能。
Replay & Explainability每次记忆读取/写入、会话生命周期事件、环境变更、协作操作和网关决策都会记录为结构化轨迹。可检查、缩小范围,并重建任意先前事件的上下文。
Encrypted Secrets基于 Fernet 的保险库,用于保存基础设施凭据、API 令牌和连接字符串。它与记忆分开——秘密绝不会出现在回忆结果中。
Business Knowledge导入公司文档(wiki 页面、工单、API 文档)——可手动导入,也可通过定期运行的 Confluence 采集器导入。内容块会存入向量存储,并在记忆回忆时与运行记忆一同自然呈现。
Code Intelligence基于 Tree-sitter 的符号搜索、调用者关系图、架构图和影响分析;返回的是符号片段,而非整个文件——通过本地网关在客户端运行(套件会安装 firekeep-symdex)。提供 38 个 MCP 工具(默认隐藏 8 个分析工具,可通过 SYMDEX_ANALYTICS_ENABLED 启用)。

Firekeep 有何不同

Firekeep 不是另一个聊天机器人封装,也不是提示词编排层。

它是一个面向互联 AI Agent 的运行层——位于现有工具背后的基础设施,让它们变得更好。

  • 默认可自托管。 服务、数据存储、嵌入模型和默认生成模型都运行在你的基础设施上。只有当你选择启用连接器或外部 Symdex AI 提供商时,才会向第三方传输数据。
  • 深入工作所在之处。 编码是当前最成熟的工作流,由 Symdex 提供代码智能。但这并非产品边界:Docdex 会将选定的文档文件夹纳入同一个 Keep;Maildex 会纳入成员的电子邮件(只读 IMAP、始终仅成员本人可见,使用 firekeep maildex add);共享的连续性、协作、治理和证据层则与具体领域无关。
  • 持久化 + 可观测性。 大多数 Agent 工具专注于让 Agent 在当下变得更聪明。Firekeep 关注的是会话之间的情况,以及出问题之后发生的事。
  • 原生支持 MCP。 四个远程服务和两个客户端本地后端通过一个本地 firekeep stdio 网关提供 Model Context Protocol 工具。已发布的适配器可配置 Claude Code、Claude Desktop、Codex、Kiro 和 OpenCode;其他 MCP 客户端可手动配置。
  • 不依赖特定 Agent。 更换 Agent 客户端,无需重建底层记忆和协作层。Cursor 提供了文档记录的手动 MCP 接入方式;Aider 目前没有已发布的适配器。
  • 支持 A2A 发现。 Relay 会在 /.well-known/agent.json 发布 Agent-to-Agent Agent 卡片,用于能力发现。这仅用于发现,并非 A2A 任务执行端点。

安装和运维详情

只需一条命令,并回答两个必要问题:每条记忆、会话和重放事件都归属到的Agent 身份,以及 Firekeep 服务的位置——在这台机器上用 Docker 部署、兑换加入码、连接已运行的服务,或稍后再决定(firekeep doctor 会告诉你如何完成后续设置)。选择在此部署时,会自动为你运行 firekeep init;该安装程序不会提出任何问题,堆栈启动后机器会自动注册,因此无需仪表板、隧道或粘贴密钥,firekeep doctor 就会显示正常。安装完成后,它会输出可直接粘贴到第二台机器上的命令。

安装程序随后会提供一个可跳过的提示,让你为另一个 MCP 客户端的规则文件进行配置;无论如何选择,都会生成四个已发布适配器的配置。

v1.6.2 之后发布的服务镜像支持 linux/amd64 和 linux/arm64,因此 x86-64 或 ARM64 Linux 主机(例如 AWS Graviton、Ampere)以及 Apple 芯片 Mac 上的 Docker Desktop 均可原生运行;v1.6.2 及更早版本仅支持 amd64。客户端引导程序会在 CI 中针对 Ubuntu、Debian、Alpine、Fedora、Rocky、Arch 和 openSUSE(x86_64 和 aarch64)进行测试;macOS 使用相同脚本,但不在 CI 测试范围内。

来自此代码检出
bash install.sh              # build the server from source
bash install.sh --pull       # the same installer against the published images
cd client && ./install       # the kit from this checkout (.\install.ps1 on Windows)
firekeep install             # re-render the runtime adapters only

install.sh 不会提示输入任何内容:主机地址会自动检测,Neo4j 密码会自动生成(--ip / --neo4j-password 或 FIREKEEP_VPS_IP / FIREKEEP_NEO4J_PASSWORD 可覆盖对应值)。堆栈启动后,脚本便会返回,而不会等待约 3.3 GB 的模型拉取完成。在此之前,内存写入会返回 status="partial"(已存储并排队等待回填,但尚不可搜索),且 firekeep doctor 会显示一条说明此情况的 embeddings WARN 行。使用 bash install.sh --wait-for-models 可等待完成。

服务器后续的运维——访问和身份验证、仪表板、备份、更新,以及有意开放端口——请参阅 docs/DEPLOYMENT.md。

移除
firekeep uninstall            # remove the client kit from this machine
firekeep uninstall --server   # also tear down the server + ALL its data

firekeep uninstall 只会移除工具包安装的内容——各运行时配置中的 Firekeep 配置块(保留你自己的设置)、启动器及其 PATH 条目,以及 ~/.firekeep——并会先征求确认(使用 --yes 可跳过提示)。它绝不会触碰你自行设置的服务器。使用 --server 还会对本机配置的堆栈运行 docker compose down -v,删除 Neo4j/Qdrant/Redis 卷——其中的每条记忆、会话和密钥都将永久删除;此操作还会单独确认数据丢失,普通卸载或 --yes 都无法触发。若你可能需要恢复数据,请先备份(参阅 docs/DEPLOYMENT.md)。

Firekeep Studio

Firekeep Studio 展示了多运行时对话工作区、会话、Mission 控制和运行时状态

下载 Windows 版 · 下载通用 macOS 版 · 探索 Studio →

studio/ 是一款独立的桌面客户端,适合希望 Firekeep 成为自己唯一打开的 Agent 应用的用户。它为 Codex、Claude Code、Kiro CLI 和 Grok 提供了与运行时无关的对话界面:任何受支持的运行时都可以明确设为主运行时,其他运行时则可在全新的只读上下文中进行审阅;此外,还内置了 /compare、/consensus、明确指定的共享工作区、Windows 语音输入和系统语音输出、感知缓存的令牌保护、带名称和颜色标记的本地会话、实时提供商模型与推理能力发现,以及类型化的 Client Kit 控件。当前选定的运行时会通过醒目的视觉标识明确显示,可隐藏完整检查器;Studio 还可通过现有的 Client Kit 连接跳转到仪表板,而不会暴露连接凭据。围栏式 Mermaid 响应会呈现为可原生缩放的图表,现有的 Firekeep Decision Board 则会在 Studio 中以原生的问题/证据/操作面板打开。其经过本地身份验证的推送机制保留了原有的长轮询方式,避免仅为确认面板已就绪而额外触发一次 Agent 回合。 主运行时选择器会显示实时就绪状态和传输上下文;响应滚动会照顾滚动离开末尾位置的读者;复制/粘贴则使用有界的纯文本原生剪贴板操作。每次运行中,已完成的回答会优先显示,详细的工作事件则折叠在工作日志中。与运行时无关的 Agents 视图会将 Codex、Claude、Kiro、Grok 或未来任何支持聊天的适配器平铺为可选择的窗格,各自支持独立的原生续接;共享撰写框会面向当前选定的窗格,而活动运行会按顺序执行,以确保工作区安全。 Mission Mode 提供了一个以结果为边界的执行框架:一个主写入者、确定性的本地检查、有界修复、独立审阅证据、明确的人为验收,以及与所有 Agent 文本分开存储的任务结果。

Studio 使用提供商支持的结构化边界,而不抓取 TUI 内容;身份验证由提供商自行管理(OS 加密的 API 密钥除外);对于运行时原生配置提供 Keep 记忆、钩子、策略和连接能力的情况,它会继续使用现有的 Python Client Kit。运行时卡片会明确报告这些证据;直接的 xAI Grok 适配器会明确标注为不具备 Keep 记忆,而不会继承其他运行时的声明。预览 构建和安装程序命令、安全边界、运行时矩阵以及完整的 / 命令清单,均见 Studio README。

Studio 0.5 通过独立的签名发布渠道提供 x64 Windows 安装程序和通用 macOS 安装程序。打包版本会在启动后不久检查 Studio 更新;Windows 会在重启时下载并安装经过验证的更新,而 macOS 仅在版本经过 Apple 签名和公证时使用原生自动更新。 当前版本页面、校验和及两种安装程序均发布在 Firekeep Studio releases。

一个真实的工作流

以下是 Agent 使用 Firekeep 时发生的事情:

1. 会话开始。 在支持生命周期钩子的运行时中,客户端会先获取 Cortex 聚合的 GET /briefing,其中包含相关记忆、任务、环境状态和技能。随后,Agent 调用 ctx_start_session("fix auth middleware bug");Bridge 创建持久会话,shim 则将其与该简报关联起来。

2. 探索代码。 Agent 不必读取每个文件,而是调用 Symdex 上的 search_symbols("auth middleware") 和 get_callers("require_scope")。它能在几毫秒内获得有针对性的文件列表和调用方。

3. 检查环境。 Sentinel 一直在监控 Docker。它检测到 cortex-api 容器在过去一小时内重启了 3 次,并向 Relay 的 #alerts 频道推送了一条警报。Agent 会在上下文中看到这条信息。

4. 开展工作。 Agent 编辑文件、运行测试,并通过 ctx_update 记录重要进展。Bridge 会持久保存明确记录的内容。当上下文窗口被压缩时,Agent 会调用 ctx_get_shadow,取回持久化的工作状态——计划、决策、进展和文件知识。

5. 会话完成。 Agent 调用 ctx_complete_session,还可以选择传入结构化自评——task_result("success" / "partial" / "failure",表示 TASK 的结果,而非 RPC 的结果),以及最多 10 条简短的 task_evidence 佐证。只有经过验证的会话所有者才能提交评分,而且评分会作为该会话唯一的权威结果保存,之后永不覆盖。Bridge 会以原子方式将会话标记为已完成,并将后台蒸馏任务加入队列,写入情景记忆;失败会重试,最终移入可见的死信队列。自动评估会根据重放轨迹计算质量指标——没有可识别评分的会话会显示为 unknown,而不会被猜测为成功,因此基于结果的评分(Outcome-Weighted Memory、质量趋势)绝不会把未反馈当作胜利。等蒸馏成功后,下次有人处理身份验证中间件时,就能找到这些记忆。

6. 出了问题? 打开仪表板中的 Replay 标签页。加载会话。查看每项操作、每次记忆读取和每个决策点。点击失败事件并运行追因分析——它会沿因果链回溯,帮助确定根本原因。

架构

Local Machine                               VPS
┌──────────────────────────┐              ┌────────────────────────────────────┐
│ Claude / Codex / Kiro /  │              │ FirekeepCortex   — Memory & RAG    │
│ OpenCode / MCP client    │              │ FirekeepBridge   — Sessions        │
│           │              │              │ FirekeepSentinel — Monitoring      │
│  one `firekeep` gateway  │◄──── MCP ───►│ FirekeepRelay    — Coordination    │
│    ├─ symdex (local)     │              │ Dashboard        — Web UI          │
│    └─ decision (local)   │── Browser ──►│ Neo4j · Qdrant · Redis · Ollama    │
└──────────────────────────┘              └────────────────────────────────────┘

Symdex 和 Decision Board 作为 stdio 本地 MCP 服务在客户端运行(随工具包安装)——Symdex 必须位于它所索引的工作树中,因此不再是 VPS 容器。

默认情况下,跨越该边界的两条箭头无法从公网访问。 开箱即用时,VPS 端监听回环地址并要求提供 API 密钥,因此本地设备端需要通过 SSH 隧道、专用网络或你主动配置的 HTTPS 前端访问它。请参阅 docs/DEPLOYMENT.md → 访问与身份验证。

服务功能
FirekeepCortex长期记忆。语义 + 图 RAG、归档/恢复生命周期、睡眠周期整合、四种带类型感知衰减的记忆类型、带置信度评分的版本化记忆、自动处理矛盾并取代旧记忆、由 Agent 编写的技能(skill_create)+ 文档→技能流水线,以及 Agent Gateway(先预测后执行界面)。
FirekeepBridge会话持久化。通过上下文压缩保留工作上下文(计划、决策、进度、文件知识)。完成后自动提炼到 Cortex。检测崩溃会话并通过工作区快照恢复。会话清理器会放弃空闲超过 72 小时的会话,使离开的会话在结果评分中登记为未成功。向回放流发出会话生命周期事件。
FirekeepSentinel环境观察器。监控 Docker 健康状态、Git 提交和文件更改。发生错误时向 Relay 广播警报。容器重启、新提交和文件更改会进入可回放的事件流。
FirekeepRelayAgent 协调。实时发布/订阅频道、持久公告板、结构化任务队列、使用单调递增围栏令牌的资源租约、在线状态注册表、直接消息,以及供外部发现的 A2A Agent 卡片端点。
Dashboard涵盖协调、记忆、诊断、设备、成员、策略、保险库和运维的 Web UI。
Firekeep Studio可选的本地桌面控制台和任务执行框架,供主 Agent 使用,支持确定性验证、独立审查者、Windows 听写、系统语音回复、跨运行时比较和 Client Kit 控制。它不是 VPS 服务。

代码智能(FirekeepSymdex——38 个 MCP 工具,8 项分析功能默认由功能标志隐藏)和 Decision Board(firekeep-decision)作为随工具包安装的 stdio 本地 MCP 服务在客户端运行,而非 VPS 容器。

共享模块(无需额外容器):Replay Engine(跨所有服务的结构化跟踪日志)、Auth(API 密钥范围)、Vault(使用 Fernet 加密的密钥存储)、Corpus(业务文档导入 → 向量分块;定时 Confluence 收集器)、Auto-Evals(10 项 Tier-1 质量指标 + 趋势追踪 + 回归检测)、Pattern Engine(策略检测;推广验证和 A/B 实验默认通过功能标志关闭)、Policy Engine(复合预编辑安全检查——租约、文件风险、路径拒绝、会话健康状态、近期失败)、Agent Gateway(先预测后执行界面,带有用于重复低风险操作的快速路径缓存)、Skills(由 Agent 通过 skill_create 编写 + 文档→技能草稿由人工审核;默认关闭服务端合成)、Memory Improvements(优先归档的复合老化机制,支持预览/审计/恢复、令牌预算、LLM 合成流程、限制嵌入输入并按需缩减至适配)。

完整设计规范请参阅 docs/DESIGN.md。

仪表板

在主机上通过 http://localhost:8040 访问,也可以从其他位置通过隧道访问 (docs/DEPLOYMENT.md → 访问仪表板)。 仪表板有独立的基本身份验证登录(用户名为 admin;密码只写入一次 dashboard/.htpasswd.cred)。之后,nginx 会在每次后端调用时注入仪表板的 API 密钥,因此 SPA 无需你在浏览器中粘贴密钥,也能与受身份验证保护的服务栈协同工作。

标签页显示内容
Overview服务运行状况、快捷统计、近期事件和记忆
Sessions活动/已暂停/已完成/已放弃的会话,影子上下文检查器
EventsSentinel 事件流,带来源和严重性筛选器
Relay任务队列、频道、公告板、私信、活动认领/租约
ScopeFirekeepScope 澄清会话 — 活动屏幕、回答提示词
Memory记忆检索、活动/归档浏览器、一键恢复、维护预览/审计、存储表单、贡献者、命名空间/标签统计
SkillsAgent 编写及从文档提取的技能卡片 — 审核、启用、编辑、退役 — 以及 Living Procedures 操作手册卡片:强制模式徽章和管理员模式控制、每个步骤的观察统计、偏差视图;若已启用的操作手册没有会话持有当前版本,则显示“未主动强制执行”警告
Knowledge文档→技能导入(粘贴/URL)+ 技能草稿审批队列
Autopilot审核收件箱(技能草稿/过时技能/需重新审核技能、流程提案、操作手册偏差、带有集群拟议裁决的争议记忆对,以及评测死信)、“本周变更”摘要、Living Instructions 合规表(每条指令的比率、趋势、按运行时划分的数据、曝光状态)、Trust Ledger 卡片(每个 Agent 的声明/核对/校准/撤销情况),以及显示各作业审批率的集群表格 — 只读;仅提出建议并报告,不会修改任何内容
Patterns发现的策略卡片;启用相关功能标志后,可使用晋升验证和实验控制
Ops工作进程、队列深度、活动 Agent、向量存储信息、Discipline 计数器(未标记的记忆调用)
Policy用于编辑前安全检查的运行时策略规则,可逐条切换
Vault加密密钥管理(基于 Fernet,Redis DB 7)
Replay会话跟踪时间线、事件检查器、根因缩小范围
Evals汇总质量指标、按会话划分的评分卡、质量趋势
Devices设备凭据和一次性注册命令
Members人员和一次性成员邀请

仪表板是零依赖的静态 SPA。无需构建步骤、npm 或框架。

文档

文档内容
docs/DEPLOYMENT.md运行服务:访问与身份验证、更新、备份、故障排查、本地开发(安装说明见 firekeep.ai/docs.html)
docs/CONFIGURATION.md所有环境变量、Redis DB 分配、智能功能
docs/MCP-TOOLS.md服务端和已注册的客户端本地后端的完整 MCP 工具参考;可见工具清单因 dex 注册和功能标志而异
docs/DESIGN.md完整架构规范、服务契约、集成点
docs/COMPARISON.md与基础版 Claude Code 的逐项功能对比
docs/SETUP-CODEX.mdCodex 集成指南
docs/SETUP-CLAUDE-CODE.mdClaude Code 集成指南
docs/MULTI-AGENT.mdAgent 智能功能:预先简报、会话总结、多 Agent 协调
studio/README.mdFirekeep Studio 运行时矩阵、命令、安全模型、开发与打包

技术栈

Python 3.11 服务端服务(客户端支持 Python 3.10 及更高版本)/ FastAPI / FastMCP / Neo4j / Qdrant / Redis / Ollama / Docker Compose / tree-sitter / TypeScript / Electron / React

服务端的嵌入和生成默认使用本地 Ollama,因此默认服务端路径不会产生模型 API 费用。Symdex 也可选择使用 Anthropic、Gemini 或兼容 OpenAI 的端点来生成符号摘要和脚手架;启用其中任一提供方可能会将代码片段发送到本机之外,并产生提供方费用。后台自动索引会明确禁用 AI 摘要。

路线图

当前已实现
  • 完整的记忆生命周期(学习、召回、衰减、矛盾检测、版本管理)
  • 四种记忆类型(reference / procedural / episodic / transient),支持按类型感知的召回衰减;直接学习的内容默认归为 episodic,而原始事件整合会对提取出的知识进行分类
  • 注重 Token 用量的召回,支持可选的大模型综合
  • 以归档优先的复合老化机制(年龄 × 访问次数 × 置信度),提供仪表板预览、审计和恢复;已确认的记忆、技能和语料块永远不会因老化而归档,且默认关闭自动彻底清除
  • 团队连续性:经过验证的工作区/成员溯源信息,以及运行时 agent_id + project、贡献者报告、大模型综合生成的交接简报
  • 会话可跨上下文压缩持久化,并支持崩溃检测和工作区快照恢复
  • 在会话生命周期中发出 Bridge 重放事件(started / updated / completed / abandoned)
  • Docker + git + 文件监控,并通过 Relay 发送提醒;容器/提交/文件活动会流入重放流
  • Agent 协作:频道、公告板、带 fencing token 的租约、结构化任务队列、状态注册表、直接消息
  • 会话开始时进行启动前简报,从所有服务汇集情报;当记忆调用缺少身份标头时,会显示规范警告
  • 会话复盘:引导完成任务更新和租约清理
  • 多 Agent 支持(任务分配、收件箱轮询、文件租约强制执行)
  • 技能:由 Agent 通过 skill_create 创建(客户端);另有 docs→skills 流程(粘贴/URL/定时 Confluence 收集器),在人工审核下起草技能;最佳匹配项会注入下一次简报(服务端自动综合功能通过 SKILL_SYNTHESIS_ENABLED 控制,默认关闭)
  • Night Shift:firekeep night-shift 会处理整个任务目录中的任务——会话提炼(由会话结束钩子排队)、过时技能重写以及有争议的判定提案(由服务端每晚排队)——在你自己的机器上使用本地模型(LM Studio 或 Ollama,自动检测),生成归属于原始会话的记忆、标明所重写过时技能的草稿技能(reauthor_of),以及记录在争议条目对上的判定提案——绝不自动应用,始终等待人工审核。如果本地模型端口有响应,会话开始时便会在后台启动(设置 FIREKEEP_NO_AUTO_NIGHTSHIFT=1 可选择退出)。生成过程不会在服务端运行;默认拒绝云托管模型,确保会话内容不会离开本机
  • Decision Board:由 Agent 启动的本地澄清看板,预先填入检索到的团队记忆证据(stdio 服务 firekeep-decision + Cortex /decision/synthesize)
  • 个人/绕过模式:会话期间使用 /personal(或 firekeep personal / FIREKEEP_BYPASS=1)可让 Firekeep 在私人工作期间完全休眠——hooks、sidecar、decision board 和 shim 均遵循同一个 is_bypassed() 门控;会话结束时自动清除
  • Pattern Engine:策略检测、类别分类(procedural / risk / behavioral)和隔离控制;自动晋升/验证功能通过 PATTERN_VALIDATION_ENABLED=false 控制,默认关闭
  • 实验框架:命名数据集、卡方显著性检验、效应量置信区间,以及通过 PATTERN_EXPERIMENTS_ENABLED=false 控制的受控策略提示实验,默认关闭
  • 在启用模式验证后,可选择开启反馈循环,衡量简报提示是否能改善结果
  • 运行时策略引擎:编辑前复合检查(租约、文件风险、路径拒绝规则、会话健康状况、近期失败)
  • Agent Gateway(先预测再执行):MCP action_before / action_after,网关返回 allow | rethink | block,并为重复的低风险操作提供快速路径缓存
  • 使用 Fernet 加密的密钥库,提供 MCP 工具和 REST API
  • 重放追踪,支持缩小根因范围和重建各事件的上下文
  • 自动评估:会话完成时计算 10 项 Tier-1 质量指标,跟踪趋势并检测回归
  • 知识自动驾驶第 1 轮(仅提供可见性,不会自主修改):按反馈加权的召回 + memory_feedback 工具、用于将崩溃会话计为失败的 Bridge 会话回收器、针对未确认记忆冲突的有争议而非替代处理,并提供人工判定、Autopilot 审核收件箱 + 每周摘要、每条记忆的证据记录(/memory/{id}/evidence),以及影子模式技能阶梯,记录哪些草稿可晋升为 trial、哪些试用技能可晋升为 active——参见 docs/guides/knowledge-autopilot.md
  • Living Instructions 第 1 + 2 轮(测量):Autopilot 标签页中的逐条指令合规表(判定条件固定为预注册基线)、随时间变化的趋势,以及第 2 轮测量规范——渲染块中标记指令内容哈希、五个归因标头、按运行时细分,以及 exposed/not-exposed/unknown 状态;所有无法验证的内容均报告为 unknown。经人工判定后改写,以及通过简报交付的 A/B 变体,均列入路线图——参见 docs/ROADMAP.md 中的设计规范
  • Dreaming:自动整合记忆 + 人物档案(DREAM_ENABLED,默认关闭)
  • Living Procedures 第 1 + 2 轮:将观察到的技能视为流程,提出频率/效用建议并交由人工审核;第 2 轮还包括强制执行手册:命令步骤匹配器、由人工启用的 advise / require_ack / block 强制策略(仅在成功后记录证据)、challenge→ack→一次性许可协议、失败时关闭的阻止模式,以及在仪表板和 Autopilot 收件箱中显示的逐工作区偏差记录(PROCEDURE_ENABLED,默认关闭;在公告前进行内部实测)——参见 docs/guides/living-procedures.md
  • Trust Ledger 第 1 轮:按需从重放网关事件汇总的逐 Agent 履历记录(GET /autopilot/trust + 仪表板卡片)——包括声明/对账计数、预测匹配校准、撤销次数和会话数。仅提供可见性,适用于整个部署;首个数字发布前已预注册并冻结计算公式。具备强制执行能力的代理经纪器(逐步授予自主权)将在后续轮次推出
  • 语料租户隔离加固:成员私有文档来源、在每个数据出口实施共享可见性筛选、按来源限定的点标识(不同成员间相同文本不再合并为一个可删除点)、考虑主体身份的来源授权,以及已提交代际门控——为即将推出的客户端 dex 提供通用基础设施
  • 每个适配器都注册一个可降级运行的本地 MCP 网关,汇集四个远程服务、本地客户端 Decision Board,以及所有已注册的 dex
  • dex 注册表:dex 是 Keep 支持的领域索引,可通过 firekeep dex list|add|remove 查看和切换,配置文件为 ~/.firekeep/dexes.json。每个发行版都附带全部三个轮子的捆绑包,并经过校验和验证——注册控制活动,而非安装。默认注册 Symdex 和 docdex(自客户端 1.2.0 起,缺少注册表时会自动填入这两项);firekeep dex remove 可关闭 dex,移除状态会在更新后保留。同一文件也包含能力项——用于操作某个领域而非为其建立索引的条目,标记为 role: capability,既不捆绑,也绝不会自动填入——参见 docs/guides/dexes.md
  • 代码智能:通过网关运行客户端侧的 firekeep-symdex(包含 38 个工具,另有 8 个分析功能默认隐藏);注册为 dex 后即可挂载
  • 文档:客户端侧的 firekeep-docdex——将人工注册的文件夹(firekeep docdex add ~/Notes)提取为文本并导入语料库,通过常规的 memory_recall 显示。默认仅成员本人可见,即使使用共享 Keep 也是如此;可使用 --shared 设为工作区共享;支持 md/txt/pdf/docx,不支持 OCR;本地文件删除后,其语料库副本会在下次同步时一并删除
  • 电子邮件:客户端侧的 firekeep-maildex——成员注册的 IMAP 邮箱(firekeep maildex add),只读(每次打开均为 EXAMINE,每次获取均为 PEEK;该轮子不具备发送能力),始终仅成员本人可见
  • 桌面:客户端侧的 firekeep-hands——注册表中的首个能力项,而非索引,因此它会操作所属领域,而不是为其建立索引。你的运行时可以观察和驱动此计算机上的应用及由 Hands 管理的浏览器;每个重要步骤都必须等待单独的审批代理通过真实且非注入的按键操作批准。仅限自愿启用,且绝不捆绑(firekeep hands enable),也绝不自动填入;有关明确列出的限制——锁屏、提权窗口、截图离开本机、提示词注入——请参见 docs/guides/hands.md
  • Docs→skills 知识流程(knowledge_ingest、URL 导入)+ 可选启用的定时 Confluence 收集器(SP3)
  • Web 仪表板,除记忆、协作、重放、策略和运维功能外,还提供设备和成员管理
  • A2A Agent 卡片端点(/.well-known/agent.json),用于外部发现
  • 业务知识导入:将文档切分为块并存入向量存储,在记忆召回时显示
  • Webhook 通知(Slack、Discord、通用 HTTP)
  • 身份验证:按密钥配置 API 作用域(memory:read/write、session:read/write、replay:read、eval:read、admin 等),默认启用,密钥由安装程序初始化
已承诺(firekeep.ai 上公布的两项路线图计划)
  • 关联实例 — 多个 Firekeep 服务在组织内共享知识,让一个团队学到的内容可供其他团队回忆
  • 领域配置 — 为同一套客户端工具包提供不同体验(目前支持编码和文档,后续将支持研究),并共用一个大脑:绝不拆分为不同产品,也绝不分开存储记忆

这两项计划背后的决策记录——配置而非客户端、关联层前置条件、结果信号门控、实施顺序——请参阅 docs/ROADMAP.md。

计划中(较小事项)
  • 导出 Grafana 指标
  • Jira 连接器摄取(Wiki/Confluence 自动同步已发布,需选择启用)
  • 技能版本管理和回滚

状态

Firekeep 正在积极开发中,并且每天都在使用。核心实现——记忆、会话、环境监控、协作、回放、客户端工具包和 Symdex——在当前代码库中已通过 4,000 多项自动化测试。该架构针对单主机部署而设计。

此公开、可查看源代码的代码库目前处于早期访问阶段。

许可证

Firekeep 根据 BUSL-1.1 提供源代码,个人和团队均可免费将其用于自托管生产环境——工作区规模不限,可部署在你控制的基础设施上;在 Firekeep 处于早期访问阶段期间,团队均可免费使用。商业版提供 Enterprise 治理和支持(请联系 [email protected])。 每个版本在首次公开发布四年后转换为 Apache-2.0 许可证。 完整授权内容请参阅 LICENSE,许可证状态请参阅 docs/LICENSING.md。 Symdex 在提取其独立 Core 并根据 Apache-2.0 许可证单独发布之前,仍受此许可证约束。

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。