lema-mcp

lema-mcp

你的编码 Agent 可以读取代码，却无法读懂代码背后的 理由。 lema-mcp 为你的 Agent 提供记录下来的 原因，以及项目已经排除的备选方案，并附上来源引用。开箱即支持 React、Kubernetes 和 Rust，也可以通过一条命令支持你自己的代码库。

一个本地 MCP 服务。无需账户、无需数据库，处理你自己的代码库时无需联网——30 秒即可安装，然后询问项目为何做出某项决定，或你正打算采用的方法是否已被否决。

❌ 不使用 lema

• Agent 根据训练记忆编造 理由——说得头头是道，有时却是错的。理由记录在 RFC / KEP / PR 讨论串中，从未写进代码。
• 它会再次提出维护者 两年前就已否决 的方法——因为被否决的备选方案在源代码中 毫无痕迹。
• 问“这个方案以前被排除过吗？”，你得到的却是一个自信的猜测，无法分辨是真实结论还是幻觉。

✅ 使用 lema

• 从项目实际记录的讨论中获得一个带有 引用 的答案——每个 [n] 都链接到作出决定的 RFC / PR。
• 如果项目已否决你的方案，就会给出类型化的 ruled_out 判定，附上记录的原因 以及 指向文档中替代做法的链接。
• 如果你的方案 就是 项目当前有效的记录决策，就会给出类型化的 settled 判定，并引用作为依据的决策，同时提供说明具体做法的文档链接。
• 如果记录中没有相关内容，就会坦诚告知 “没有记录的结论”——这表示 未知，不代表 已获批准。lema 不会用猜测填补空白。

lema 保存的是 推理过程——作出决策的原因、被否决的方案——而非 API 语法或代码示例。要找这些内容，请使用文档工具。要了解 原因，lema 才是合适的选择。

30 秒上手——无需账户

npx lema-mcp try react        # or: kubernetes · rust

这会将一个只读公共服务写入项目的 .mcp.json。重新加载 Agent 的 MCP 服务（在 Claude Code 中输入 /mcp），然后试用旗舰工具 check_approach——说出一种方案，获取记录的判定：

> "Let's add a delayMs prop to Suspense to debounce the fallback."   (repo: react)

  ⛔ ruled_out — the React team considered and rejected this.
     "<the recorded rationale, summarized — not a quote>"  [1]
     Where to look instead →  https://react.dev/reference/react
     [1] reactjs/rfcs#212

> "I'll add a global event bus for cross-component communication."   (repo: react)

  ◦ no_recorded_ruling — React's public record doesn't settle this.
     (Unknown — not approved.)

也可以直接用自然语言提问——“React 为什么采用 Hooks 而不是 mixins？”——获取一个带引用的答案；如果记录中没有相关内容，它会坦诚说明。

目前支持：React · Kubernetes · Rust，数据来自 lema 的公共 API（api.lema.sh）。无需令牌。这是一个精选的三项目演示语料库，并非对你拥有的图谱进行分析。

安装

无需账户的公开演示（React 的已记录决策，无需设置）：

如果 Cursor 按钮没有打开安装提示（浏览器无法处理 cursor:// 深层链接时很常见），请将以下内容粘贴到 .cursor/mcp.json（项目级）或 ~/.cursor/mcp.json（全局）：

{
  "mcpServers": {
    "lema": {
      "command": "npx",
      "args": ["-y", "lema-mcp@latest"],
      "env": { "LEMA_MCP_MODE": "public", "LEMA_PUBLIC_REPO": "react-rfcs" }
    }
  }
}

这样即可访问 React 的公开记录——询问 “React 为什么排除了 X？”，即可获得附有引用的答案，无需账户。若要配置自己的仓库以进行记录，或将演示指向 Kubernetes 或 Rust，请使用下方针对各客户端的设置说明。

npx 只需要 Node，无需 Go 工具链或账户。用两条命令即可涵盖 lema 的两种使用方式：

npx lema-mcp try react   # read-only: ask React/Kubernetes/Rust why + what's ruled out
npx lema-mcp init        # your repo: decision capture + the never-reopen guard

两种方式都不会破坏现有配置，且支持幂等执行——它们会合并到现有配置中，重复运行不会有任何变化。init 和 try 共用同一个 lema 服务键；经过身份验证的 init 服务包含公开工具，因此二者可以共存，try 也不会将其降级。

npx lema-mcp init        # or: npx lema-mcp try react

{
  "mcpServers": {
    "lema": { "command": "npx", "args": ["-y", "lema-mcp@latest"] }
  }
}

{
  "mcpServers": {
    "lema": { "command": "npx", "args": ["-y", "lema-mcp@latest"] }
  }
}

{
  "mcpServers": {
    "lema": {
      "command": "npx",
      "args": ["-y", "lema-mcp@latest"],
      "env": { "LEMA_MCP_MODE": "public", "LEMA_PUBLIC_REPO": "react-rfcs" }
    }
  }
}

{
  "mcpServers": {
    "lema": {
      "command": "npx",
      "args": ["-y", "lema-mcp@latest"],
      "env": { "LEMA_MCP_MODE": "public", "LEMA_PUBLIC_REPO": "react-rfcs" }
    }
  }
}

{
  "mcpServers": {
    "lema": { "command": "npx", "args": ["-y", "lema-mcp@latest"] }
  }
}

{
  "servers": {
    "lema": { "command": "npx", "args": ["-y", "lema-mcp@latest"] }
  }
}

go install github.com/lemahq/lema-mcp/cmd/lema-mcp@latest

公开配置只设置 LEMA_MCP_MODE + LEMA_PUBLIC_REPO （react-rfcs · k8s-enhancements · rust-rfcs）——API URL 已编译进程序。

托管团队：登录一次，自动解析仓库

登录 Lema 后，在仓库之外保存一份组织级凭据。常规设置包含身份凭据，而不是复制来的工作区 UUID：

# ~/.config/lema/credentials
LEMA_API_URL=https://api.lema.sh
LEMA_API_TOKEN=lema_live_...

chmod 600 ~/.config/lema/credentials
npx lema-mcp@latest doctor context

更改 MCP 配置后，请重启编码 Agent。从那以后，Lema 会将经过验证的 Git 远程地址与结账内容相匹配以确定 Repository，找到其 Project，并将一个不可变的目标收据传递给每项操作。并行打开两个仓库不会创建可变的“活动仓库”，每位用户也会保留各自的组织级凭据。

有关多仓库 Project、歧义恢复、没有远程地址的仓库、工作树和兼容性覆盖，请阅读 目标上下文：Project、仓库和运行。

两种使用方式

1. 公开记录 — React、Kubernetes、Rust（只读，无需账户）

询问热门项目为何作出某项决定，或查看某个方向是否已在记录的 RFC/KEP 讨论中被否决。这是 try 服务。

2. 你自己的仓库 — 记录 + 永不重提（本地，无需账户）

大多数“上下文”工具都是只读的——不过是更方便地 grep 文档。lema 也能读取，但它真正的作用是永不重提：

• Agent 敲定一个选择 → 调用 record_decision，记录所选方案以及被否决的备选方案，并说明每个方案被否决的原因（这些内容永远不会留在代码里）。
• 在任何人提出一个方向之前 → check_decided 会在该选项状态为 CLOSED 时返回先前的决定。
• 每次编辑时，PreToolUse guard hook（由 init 安装）都会读取草稿改动，并在已被否决的选项被重新提出之前显示 CLOSED 决定 — 依据你记录的决定以及仓库自身的 ADR 强制执行。

决定会记录到 .lema/decisions.jsonl — 一个纯文本追加式文件，你可以将它提交到仓库，这样整个团队的 Agent 就能通过 git 共享这份记忆。无需密钥，也不会在我们这边调用大模型：由你的 Agent 作出决定；lema 负责保存并将其提供给 Agent。

“永不重提”是什么样的

你的 Agent 又想采用一个你已否决的选项 — 它会返回 CLOSED，并附上原始原因：

⛔ CLOSED — 不要提议 “SWR”： 不支持一流的变更操作 / 缓存失效机制 — 我们得自己手动实现 (决定于 2026-06-04 · “Web 应用的数据获取” · 选择了 TanStack Query)

这样，Agent 会显示先前的决定，而不是重新争论。替代某项决定后，之前选定的选项也会变为 CLOSED — 双向强制执行。（这就是对临时目录运行 npx lema-mcp demo 得到的实际输出。）

此 guard 是建议性的，并且故障时默认放行：在默认的 context 模式下，它会将提示作为非阻塞提醒注入 — 永远不会硬性阻止编辑，也不会自动批准编辑。LEMA_GUARD_MODE=ask 会在匹配度较高时询问你；off 是紧急关闭开关。发生任何错误 → 不会输出任何内容，并会自动退出，不造成干扰。

可用工具

你的 Agent 通过 MCP 调用这些工具。

公开记录（无需账户）

你自己的仓库

在你自己的仓库中，完整服务会注册读取和记录工具（以及公开的 check_approach）；npx lema-mcp try 服务只运行公开入口。

lema settle — 在终端中进行裁定（托管模式）

此软件包还会安装 lema 命令。settle 是裁定流程的终端环节：它会为 托管决策起草裁定，并打印深层链接，你可以通过在浏览器中点击来使裁定生效——终端凭据永远不会使任何裁定生效（这种分工是架构设计的一部分：程序化主体无法创建有约束力的裁定，这是有意为之）。

lema settle accept <decision-id>...              # draft an accept, print the bind link
lema settle reject <decision-id> --reason <why>  # proposed drafts only; takes effect immediately
lema settle supersede <decision-id> --by <decision-id>  # takes effect immediately

accept 会起草裁定；reject 和 supersede 会在同一个请求中由服务器执行（它们没有浏览器确认步骤——命令会说明这一点）。 决策 ID 必须是完整 UUID，或唯一的 6 个以上字符的 UUID 前缀（d_xxxxxx 定位符是内容哈希，因此会被拒绝）。需要托管身份凭据（LEMA_API_URL 和 LEMA_API_TOKEN）。LEMA_WORKSPACE_ID 是可选项，仅用于 CI、恢复或消除歧义，不是常规仓库设置所需。

lema 有何不同（坦诚之处）

lema 的品牌核心就是坦诚——这正是“为什么”工具值得信赖的原因：

• 弃答 ≠ 认可。 沉默就如实报告为沉默。lema 宁可说“没有记录的裁定”，也不会凭空捏造。
• 有引用、有总结——不直接引用原文。 回答以记录的决策为依据，并用转述的方式表达（“记录表明……”），每项声明都关联到可追溯的参考资料。
• 本地优先。 记录和执行完全在你的设备上运行，数据保存在你拥有的文件中。我们这边不需要密钥、不上传数据，也不调用模型。
• 不捏造图谱。 冷导入不会写入任何决策→决策边，也不会写入任何由来源作者提供的日期；lema 展示记录中的实际内容，不添加任何无法负责的内容。

执行机制会改变 Agent 的行为吗？

我们在两个并非由我们编写的真实公开仓库（Backstage、vite）上进行了测量：将其中记录的六项决策转写为 record_decision 格式，并用真实的 lema-mcp guard 二进制文件检查 Agent 的编辑草稿。共进行了 168 次试验，0 个错误。坦诚地说，这项结果证明的是这种机制确实可行，而不是“Agent 有 58% 的时间会出错”：

• 对于唯一一项与 2026 年前沿模型判断相悖的决策（node-fetch → 原生 fetch），盲测 Agent 有 58.3% 的概率（14/24）再次提议使用已弃用的库；lema 将这一比例降至 0%，与预先加载文档的测试组持平，且无需将文档放入上下文。
• 对于模型本来就能正确处理的另外五项决策，lema 保持沉默：48 次试验中，再次提议的比例为 0%，错误弃权率也为 0%。不会唠叨。

公开仓库基准测试会低估其价值——模型在训练中已经吸收的决策，往往更可能是公开决策。真正能因执行机制而改变结果的决策，通常是专有的、反主流的、近期的、团队特有的。完整方法和每次原始试验记录： ./docs/enforcement-lift。

配置与隐私

• LEMA_GUARD_MODE — context（默认，非阻塞）、ask（匹配度较高时询问用户）或 off。
• LEMA_DISABLE_QUERY_LOGGING=1 — 完全从使用日志中移除查询文本。否则，记录日志前会清除查询中类似凭据的子字符串。
• LEMA_USAGE_LOG / LEMA_QUESTION_LOG / LEMA_GUARD_LOG — 可选启用的本地日志文件；除非设置，否则均关闭。
• LEMA_API_URL + LEMA_API_TOKEN — 托管服务身份凭据。环境变量的优先级高于 ~/.config/lema/credentials。
• LEMA_WORKSPACE_ID — 经过验证的显式目标，适用于 CI、恢复或消除歧义兼容场景。正常使用由 Git 管理的仓库时，请不要设置。

许可证

MIT。lema-mcp 是 lema 的免费本地切入点，lema 是记录 原因 的系统。托管决策图谱、团队原因视图以及面向管理者的 Intelligence 层，均可在 lema.sh 使用。