ljos

ljos

只需告诉编码 Agent 一次规则。每当提示词涉及该规则时，它都会再次收到规则，而钩子会拒绝违反规则的命令。

编码 Agent 会在会话结束后忘记学到的内容，而且会运行它们选择的任何 shell 命令。ljos 在你自己的机器上解决这两个问题。它会将你告诉 Agent 的内容保存在本地存储中，并在模型读取每条提示词之前，将匹配的笔记传回。它会在 shell 命令运行前，依据你的规则和内置的破坏性命令列表检查命令。它通过 Agent 自带的钩子和 MCP 设置接入 Agent。除非你启用远程判定器，否则任何内容都不会离开这台机器。

它会在 Claude Code、Codex、Cursor、GitHub Copilot CLI、Gemini CLI、Windsurf、Factory 的 Droid、Kiro、Qwen Code、Crush、Auggie、Amp、goose、OpenHands、Grok Build、opencode、omp 和 Antigravity 的 agy 中阻止被拒绝的命令。Cline 钩子也会安装，但上游文档尚未说明钩子失败是否会阻止命令运行。 它通过 MCP 在 Zed、VS Code、Claude Desktop、Continue、Roo Code、Kilo Code、hermes 和 Amazon Q 中提供记忆、技能和工具。

五分钟

curl -fsSLO https://github.com/leidarljos/ljos/releases/latest/download/install.sh && sh install.sh
export PATH="$HOME/.local/bin:$PATH"
ljos prefer "Push a tag with git push origin TAG; --follow-tags skips lightweight tags."
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."

程序会安装到 ~/.local/bin，而 export 行会将其添加到你粘贴命令时所在 shell 的 PATH 中。从下一个版本开始，如果 ~/.local/bin 不在 PATH 中，安装程序还会将该行添加到 ~/.profile 和 ~/.bashrc，并在存在 ~/.zshrc 时添加到其中，这样新的 shell 就能找到 ljos；--no-modify-path 则不会修改这些文件。

安装程序会从 GitHub 发布页下载每个程序，根据已发布的 SHA-256 校验和进行验证，并在某个平台没有发布版本时使用 cargo 从源代码构建。然后，它会为找到的每个编码 Agent 运行 ljos onboard。如果没有找到任何 Agent，它仍会设置跟踪器、记忆写入器和 deed 存储，并提示以后可以使用 ljos onboard --harness NAME。它会展示防护机制在强制推送前发出确认提示。其程序包括 ljos、packset（记忆）、vissue（跟踪器）、deedar（工作记录）、claimdag（工作分配）、ljos-policyd（命令检查）和 ljos-consensus（投票），以及用于基于语义搜索的编码器 packset-embed。 --no-embed 会跳过编码器；此时搜索只匹配词语，无法找到与记忆没有任何相同词语的释义。若某个平台没有可用的编码器构建版本，安装程序会发出警告并继续安装，不包含编码器。--with-embed 仍被接受，但不会产生任何变化。ljos doctor 会列出缺失的部分。 --version 0.29.0 会安装该 ljos 版本，而不是最新版本；--pin packset=0.14.0 则会将另一个仓库固定在指定版本。如果固定的版本没有适用于该平台的发布版本，安装程序会构建该版本的 crate，绝不会使用更新版本。 安装程序还会使用 gh 2.49 或更高版本，或使用 cosign，检查每个 tarball 的 GitHub 构建证明，并用一行汇总结果；如果有任何构建证明缺失或验证失败，--attest 会停止安装。 packset、deedar 和 consensus 将从下一个版本开始附带构建证明；在此之前，汇总结果会将它们分别标记为尚未发布。 ljos-hud（桌面面板）是可选组件，doctor 会将其列为 info。 不含 phronesis 构建的 ljos-policyd 只会使用自身的表检查命令，doctor 会将其策略行标记为 warn。 从源代码构建（cargo install，或在没有发布 tarball 的平台上使用 binstall）需要 Rust 1.89 或更高版本；rustc --version 会显示你当前使用的版本，而 rustup update stable 可以安装最新版本。 较旧的 Rust 会导致多个 crate 构建失败，并可能在没有任何提示的情况下安装低于 0.5.0 的 ljos-policyd，因此 doctor 会将该行标记为 no 并指出修复方法。

从 0.29.0 版本开始，每个 ljos 版本都会将脚本作为 install.sh 附上。 运行前请先阅读脚本；它位于此仓库的 scripts/install.sh。手动安装：

cargo binstall --locked ljos packset vissue-cli vissue-mcp deedar-cli claimdag-cli ljos-policyd ljos-consensus   # or: cargo install --locked, same list
ljos onboard                                # every coding tool found on this machine: MCP server, hooks and skill
ljos prefer "Push a tag with git push origin TAG; --follow-tags skips lightweight tags."
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."

--harness 接受 claude、codex、grok、cursor、antigravity、 opencode、omp、hermes、windsurf、zed、vscode、claude-desktop、 gemini、amazonq、kiro、copilot、factory、qwen、crush、cline、 auggie、amp、goose、openhands、continue、roo 或 kilo。 Cursor 的 IDE 和其 agent CLI 共用 ~/.cursor/mcp.json。 新机器上运行 ljos cloud up，或运行 sh scripts/install.sh --cloud。 这两种方式都会在下一次发布中提供；上面安装命令获取的版本两者都不包含。 在此之前，可从 develop 使用它们：检出该分支后运行 sh scripts/install.sh --cloud；如果已安装的 ljos 没有 cloud up，脚本会使用 cargo 构建该代码树中的 ljos。 二进制文件会放在 ~/.local/bin 中，~/.cursor/mcp.json 会将 ljos-mcp 指定为 PATH 上的程序，而 LJOS_TRACKER_REMOTE 会克隆为共享跟踪器。docs/cloud-vm.md 介绍了环境文件、推送模式和作业步骤。 Codex 只有在你信任钩子后才会运行它。运行 ljos onboard 后，在 Codex 中打开 /hooks，并在守卫运行前信任每个 ljos 钩子；升级重写钩子后，也要再次信任它。在此之前，只有 rm、 git 和 find 垫片会守卫 Codex 的命令。ljos doctor 能检测到不受信任的钩子时，会报告该情况。

开启一个新会话，并询问与偏好相关的内容，例如如何标记发布版本。在模型读取提示词之前，钩子会添加：

Remembered, oldest first (`ljos search` for more):
- [preference, today] Push a tag with git push origin TAG; --follow-tags skips lightweight tags.

若要在终端中读取相同文本，而不包含运行器的 JSON： echo "how do I push the v0.32.0 tag?" | ljos hook --prompt --text。

之后，当 Agent 尝试执行 git push --force origin main 时，运行器会在执行前询问。ljos-policyd 会先根据自带规则作出回应，并以相同方式询问将 --force-with-lease 推送到 main、master、 develop 或受保护分支的操作：

{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"ask","permissionDecisionReason":"git-force-push: it rewrites shared history, so the agent asks you first (ljos rule `git-force-push`)"}}

sh -c "cd repo && git push -f origin main" 会得到相同的回应。只有你自己的规则涵盖的命令（例如 terraform destroy -auto-approve）则会遵循该规则：

{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Destroy only from the release runbook. (ljos rule `terraform destroy*`)"}}

钩子会显示你从写下内容的那一刻起添加的内容：偏好（ljos prefer）、规则（ljos rule），以及你用 ljos remember 输入的经验。Agent 在 ljos finish 时提出的经验会暂不显示，直到你在自己的终端中运行 ljos accept ID；随后它也会立即显示。Agent 在其运行器内部执行的 ljos remember 会作为一段经历保存：当提示词与之相关时，钩子会显示它；在评审将其提升为长期经验之前，ljos due 会一直列出它。

如果对话围绕某个问题展开，钩子还会确保工作记录在跟踪器中：连续调用 40 次工具却没有向工作席位汇报时，它们会提醒 Agent 记录工作。在环境中或 ~/.config/ljos/env 中设置 LJOS_TRACK_WORK=on 后，没有问题的对话会在首次工具结果中收到提示，要求使用 vissue q 创建问题并进入工作席位；如果对话使用了工具却从未触及工作席位，Stop 会阻止该轮一次。如果未启用此设置，从未进入工作席位的对话不会听到任何有关跟踪器的提示。在 ljos 支持的各类 Agent 中，grok 和 antigravity 会注册 Stop。对于 claude 或 codex，请将 Stop 添加到对应运行器在 ~/.config/ljos/harnesses.toml 中的 hook_events。

你将获得什么

• 每条提示词对应独立记忆：每条记忆只含一个断言，并根据提示词进行搜索。只有当断言与提示词共享词语，或判断器确信该断言与提示词相关时，断言才会传递给 Agent。经验教训会按复查周期重新出现；如果有新断言证明旧断言错误，它会取代旧断言，而不是对其进行编辑。
• 一个跟踪器 vissue：Git 仓库中的纯文本 org 文件。ljos sitting ISSUE 会开启工作并认领任务；ljos finish ISSUE --lesson "..." 会完成闭环并记录工作带来的经验教训。ljos accept ID 会写入该经验教训并记录接受情况。
• 对 Shell 命令的检查：ljos-policyd 内置的拒绝规则（强制推送、在临时目录之外执行 rm -rf、git reset --hard 等，以及通过 env、timeout、xargs 和其他包装命令进行的读取），还有你在规则包中编写的规则（ljos rule）。每个命令都会在执行时逐行检查，此外还有一道防护，可防止 Agent 重写检查器自身的二进制文件和钩子文件。普通的分支 git push 会获准执行，不论它指定哪个远程，也不论能否读取该远程的所有者；git push -u origin BRANCH 也会获准执行。推送标签的处理方式与推送分支相同。强制推送（--force、-f、+refspec）、删除远程分支或标签，以及 --mirror，默认都会要求确认，无论你是否编写了自己的规则。带有或不带 --force-if-includes 的 --force-with-lease 推送到 main、master、develop 或检出配置所保护的分支（ljos.toml 或 .ljos/gates.toml 中的 protected_branches）时会要求确认，推送到任何其他分支时则会执行。如果没有 refspec，防护机制会读取当前分支的上游；如果无法确定，则会要求确认。 编写规则时，像 git push* 这样范围过宽的模式会被拒绝。
• 对于有多个合理答案的决策，会交由各自持有观点的角色处理。它们通过基于信任权重的共识达成结论，并从结果中学习。角色可以在自己保留的运行器会话中进行推理。
• 业绩记录（deedar）：对工作成果进行内容寻址的记录，并在任务单中引用。

术语

术语	含义
seat	一台机器上的一个 Agent 运行器，以及它的记忆和断言
pack	记忆存储（packset），每个原子对应一条断言
sitting	一张任务单上的一项工作，由 ljos sitting 开启，由 ljos finish 关闭
island	某个标题激活的记忆，以及它们之间的链接
deed	对某项工作成果进行签名的记录
card	由个人冻结的文件；Agent 只读取，不写入
persona	持有观点、锚点及其所涉领域的投票者

两个动词，构成一个循环

ljos sitting ISSUE [--playbook NAME] 会开启一次研习。它按协议顺序运行各步骤，并在第一个未响应的存储处停止： doctor、卡片、评审时钟、由议题标题激活的岛屿、作战手册、工作集、时间线和声明。回忆之前会先复制作战手册。未指定 --playbook 时，研习会依次采用已绑定的名称、标题中的封闭集令牌，然后是 sit。作战手册名称会作为跟踪器备注保留，直到完成或释放；绑定名称之前，ljos panel 会拒绝运行。 研习会输出一份简短报告：ljos 是否已就绪、需要采取什么行动、席位针对该任务记得什么，以及声明。 --verbose 会完整输出每个部分。

ljos finish ISSUE --lesson "..." [--outcome OPTION] 会将其关闭。该经验会以 L0（derived）提案的形式写入，来源为 agent-derived。ljos accept 会将其提升为 explicit，将其写为长期经验，并记录该人员已接受。在 Agent 运行器下，它只会接受由另一段对话提交的提案，例如工作者提交的提案，因此 Agent 无法接受自己的提案。在你自己的终端中运行 ljos finish 输入的经验，如果上方没有 Agent 运行器，会立即作为你的经验写入。ljos accept、ljos forget 和 ljos graded 接受 ID 的前八个字符。岛屿会触发，会话节点会完成；指定的结果会降低被其驳斥的投票者的权重。通过 ljos remember 输入的经验仍保持为 user-declared，相同的文字也会满足尚未处理的提案。除非指定 --close，否则工单会保持打开状态；而 --close 只会在工作获接受时关闭工单。每次完成时都会运行此循环，因此无论有没有人要求，席位都会记住经验。

如果跟踪器是一个 git 检出目录，声明和完成操作都会分别提交工单的 issues.org（仅此文件）并推送，使另一台主机也能看到两者。LJOS_TRACKER_GIT=commit 会将更改保留在本地；off 则会跳过提交。若跟踪器的 .ljos/sync.toml 指定了同步范围，每次完成时也会将本机内存同步出去，并使用 age 为该文件中指定的接收方加密，作为 .ljos/atoms/<host>.jsonl.age 提交并随分支推送。该提交和推送也受 LJOS_TRACKER_GIT 控制。=push 会提交、按每个议题进行字段合并后变基，再推送；推送失败的更改会排队，等待下一次写入和会话结束时重试。=commit 会提交加密日志，但不会拉取或推送。如果跟踪器没有 .ljos/sync.toml，则不会同步。ljos doctor 会统计 origin 缺少的提交，并在仍有提交尚未推送时发出警告。

Claude Code 插件

该插件包含工具服务器（ljos-mcp）、技能（席位协议、设置、记忆、研习、提交、决策和邮件）、研习、完成、记忆和 doctor 命令、panelist Agent，以及 ljos onboard --harness claude 注册的钩子。市场配置文件位于此仓库中，同一目录树也是下文的 Cursor 插件。

claude plugin marketplace add leidarljos/ljos
claude plugin install ljos@leidarljos
claude plugin install vissue@leidarljos

ljos@leidarljos 就是此仓库。vissue@leidarljos 是跟踪器服务器，从 leidarljos/vissue 获取。ljos、ljos-mcp 和 vissue-mcp 会保留在 PATH 中；Five minutes 中的 install.sh 命令会将它们以及 packset、deedar、claimdag、consensus 和 ljos-policyd 安装到 ~/.local/bin。这些插件会运行相应的二进制文件，也会在 ~/.cargo/bin 和 ~/.local/bin 中查找。启动一个新会话。/ljos:sitting ISSUE 会开启一次研习，/ljos:finish ISSUE --lesson "..." 会将其关闭。在检出目录中，claude plugin validate . 会检查市场配置，claude plugin validate .claude-plugin/plugin.json 会检查插件。传入 --strict 可在出现警告时判定失败。

Cursor 插件

此仓库也是一个 Cursor 插件。它为 Cursor 的 Agent 提供 ljos 记忆、命令防护、ljos_* 工具、上述技能、一条告知 Agent 使用这些功能的规则，以及四个命令：/sitting、/finish、/remember 和 /doctor。

先安装程序（参见“五分钟”中的 install.sh 行），然后在 Cursor 的 Agent 聊天中输入：

/add-plugin leidarljos/ljos

Cursor 会将以这种方式添加的插件固定在首次获取时的提交上。若要获取更新，请在 Cursor 的本地插件文件夹中放置一个克隆，然后拉取更新：

git clone https://github.com/leidarljos/ljos ~/.cursor/plugins/local/ljos

然后重新加载窗口。Cursor 只会加载指向该文件夹内部的文件夹中的符号链接，因此请克隆，而不要创建链接。

这些钩子运行的都是与 ljos onboard --harness cursor 相同的 ljos hook。其中两个钩子 beforeShellExecution 和 preToolUse 会在命令运行前检查命令。第三个钩子 beforeSubmitPrompt 会查询当前席位已知的信息。Cursor 不会将提示词钩子的文本传给模型，因此该备注会通过下一条工具结果传达给 Agent。安装插件后，ljos onboard 会检测到它并将 Cursor 交由插件处理，因此不会重复注册钩子。缺少程序时，钩子会说明如何安装程序，并允许命令运行；ljos-setup 技能会引导 Agent 完成安装。

在聊天中授予命令权限

Grok Build 和 Claude 会将询问规则显示为运行器自身的权限提示。钩子会返回 ask，批准该提示即可运行命令。

对于没有原生钩子提示的客户端，询问规则会返回一个请求 ID。使用该 ID 调用 MCP 工具 ljos_request_approval。支持 MCP 表单征询的客户端会显示确切的命令、目录、对话和规则。选择 仅允许此命令一次 并提交表单，即可授权重试一次。授权会在请求创建十五分钟后过期。

拒绝、关闭提示、不勾选复选框或客户端出错，都不会授予任何权限。该工具不接受任何授权标志作为参数。每个不同的命令、目录、对话或规则都需要单独授权，拒绝规则仍然有效。

对于不支持表单征询的客户端，请在此对话中回复 approve REQUEST_ID，或在你自己的终端中运行 ljos approve REQUEST_ID。该终端命令在编码运行器下会拒绝运行，席位的防护也会拒绝在 Agent 运行的任何命令中执行它。未注明该 ID 的聊天消息不会授予任何权限。

客户端必须先加载该工具才能使用它，因此从不包含 ljos_request_approval 的版本升级后，请重新连接。当其他调用转发到升级后的二进制文件时，已拥有此工具的连接会继续使用其自身的授权处理程序。

使用已构建的服务端验证协议：

python3 scripts/test_approval.py target/debug/ljos-mcp

谁在席位上

席位是已连接的程序。ljos-mcp 会用初始化它的客户端名称来命名席位。在它打开的 shell 中运行的 ljos，会通过进程树或共享的会话 ID 找到同一个名称。这样，Runner 的工具和它的动词就属于同一个席位，无需设置变量。如果某个 shell 中只有它上级的程序，或 Runner 下的登录用户能确定席位名称，那么从该 shell 发起的跟踪器写入会被拒绝，直到设置 LJOS_SEAT。如果 seats.toml 列出了席位，那么未列出的席位发起的写入也会被拒绝。

像 Grok Bot 这样的纯 shell Agent 没有 MCP 客户端，也没有命令钩子，进程树中也无法确定它的席位名称。ljos onboard --harness grokbot 会写入技能文件和环境文件；加载该文件后，LJOS_SEAT 就会设为席位名称。ljos hook --prompt 是提示词钩子。ljos policy --fail-on-deny 在拒绝时以 1 退出。不带该标志时，ljos hook 仍会以 0 退出。

声明属于单个会话；记忆、投票和信任则归属于席位。ljos seat 会打印这两个名称及其来源。ljos onboard 会打印每个 Runner 所用的唯一 MCP 配置项，ljos protocol 会打印 Agent 首先读取的文本。

无需设置任何变量。ljos onboard --harness NAME 会创建契约存储区：deedar 会回退到（~/.local/share/deedar/store），并在 ~/.local/share/vissue/tracker 下创建跟踪器，该位置由 ~/.config/vissue/config.toml 指定；除非 DEEDAR_URL 或 VISSUE_ROOT 已指定位置。没有写入器响应时，ljos remember 会启动写入器。无论从哪个目录访问，席位记忆都属于唯一的工作区 seat，且每项声明都会记录写入它的席位。

邮件

ljos send SEAT TEXT 会向指定席位发送消息。 ljos send --group NAME TEXT 会向该组的其他成员发送消息。 --interrupt 会将消息置于下一条提示词的顶部。--issue ID 会将消息关联到一项 vissue 问题。此时，原子会采用该问题的范围，因此 ljos sync 会将其纳入密封日志。

ljos inbox 会列出未读邮件，但不会写入回执。若 pack 未响应，则会报错；ljos send 会指出负责保留邮件的 packset 版本。ljos read ID 会写入一条回执。ljos reply ID TEXT 会回复发件人并保留该问题。ljos hook --prompt 会打印未读邮件，并为显示的每条消息写入回执。如果 pack 未响应，它会打印 mail could not be checked，但仍以 0 退出。Shell 席位会轮询 ljos inbox。 在推送模式下，分离的唤醒进程会先推送密封日志，然后触发唤醒。 发送操作不会等待，推送失败会记录为唤醒日志中的一行。 ljos inbox --sync [COMMIT] 会持续获取，直到远程端包含该提交，最长等待 30 秒（LJOS_INBOX_SYNC_WAIT）；否则会获取远程端的最新提交，导入密封日志，然后列出邮件。 没有远程端时，只会列出邮件。

决策面板并发

决策面板最多同时运行 LJOS_PANEL_CONCURRENCY 个成员；有成员退出后，就会启动下一个。未设置时，并发数为机器的并行度，最高限制为 4。LJOS_MAX_PARALLEL 是同一设置项。设为 0 时会启动所有成员。

命令

引用契约时只需指出其名称；数据仍保存在 deedar 中。完成操作不会关闭工单，完成节点也不会。工作被接受后，使用 finish --close 关闭工单。不带 --close 时，finish 会释放声明，并将工单恢复到声明前的状态，与 ljos release 一样，因此不会有工单在无人持有的情况下仍处于 STARTED 状态。

ljos sitting vissue-xxxx --playbook sit        # doctor, cards, due, island, playbook, recall, timeline, claim
ljos finish vissue-xxxx --lesson "..." [--outcome ship]   # file the lesson, fire, complete, learn
ljos accept <id>                                   # write a filed proposal into the pack
ljos calibrate -p project                      # trust rows from the voting history, no truth labels
ljos remember "the default fuse is CombMNZ"
ljos prefer "CombMNZ over RRF"
ljos search fuse
ljos island "rebuild the packset site"
ljos evidence deed-…
ljos deed vissue-xxxx --add deed-…
ljos recall vissue-xxxx
ljos claim <node>                              # the session node, and the tracker issue to STARTED under the same name
ljos claim --next [--role <role>]              # the first ready node in claimdag's order for you
ljos release <node>
ljos seat                                      # who is sitting: the seat, this conversation's holder, and where the names came from
ljos complete <node> --status done
ljos cards
ljos policy -- ls
ljos approve <request-id>                       # record explicit consent for one stopped command
ljos consensus vissue-xxxx
ljos trust alice bob 0.8 --why deed-… [--about docs]
ljos persona reviewer --anchor 0.2 --view "Reads for what breaks in production." --about release
ljos playbooks                                 # sit, arena, land, company-panel, overnight, feature
ljos playbook vissue-xxxx company-panel        # bind a recipe; sitting copies the body before recall; panel refuses until then
ljos vote vissue-xxxx --for hold --expect ship --confidence 0.6 --used none
ljos predict vissue-xxxx --expect ship          # the same forecast on its own; two forecasts and consensus names the surprisingly popular answer
ljos rule 'terraform destroy*' --verdict deny --why "Destroy only from the release runbook."   # argv law in the pack; the hook and policy enforce it (see "What a rule reads" in the reference)
ljos brief reviewer vissue-xxxx                # what a subagent playing reviewer starts from
ljos note ISSUE "..."                         # the agent's own lesson; the prompt does not treat it as a fact
ljos panel vissue-xxxx --out panel             # every persona's brief as a file, for a runner without MCP
ljos panel vissue-xxxx --cloud                  # one prompt file per persona: seat env, slot, push rules
ljos vote vissue-xxxx --for hold --as reviewer
ljos panel vissue-xxxx --jev                   # with Jev on: cast when every seat is sure and agrees, else briefs for subagents
ljos learn vissue-xxxx --outcome ship
ljos due
ljos hud                                       # execs sibling ljos-hud (overlay; P pops out)
ljos habit mab-cr-all 0.579 --unit acc --every 7d --source example-0001   # an example reading; the one before closes and is kept as what it was
ljos habit                                     # every habit as it stands, the change since the last reading, when the next is due
ljos graded <atom-id> [--lapsed]
ljos handover --out bag --project x --issue vissue-xxxx
ljos receive bag [--since bridge.txt] [--import]
ljos doctor                                    # whether ljos is ready, and only the rows that need action
ljos doctor --all                              # every row
ljos protocol
ljos mcp                                       # serve MCP over stdio through the ljos-mcp beside this ljos
ljos onboard                                   # at a terminal, every runner found on this machine; into a pipe, the one MCP server entry any runner takes
ljos onboard --harness all --dry-run           # what onboarding every runner found would write
ljos onboard --harness json                    # the one MCP server entry any runner takes
ljos onboard --harness hermes                  # register with a runner named in harnesses.toml; opencode, hermes, omp, grok, antigravity, cursor come as shapes
ljos onboard --harness grokbot --skills ~/.grokbot/skills   # shell-only: skill and an env file, no MCP server and no hook
source ~/.config/ljos/grokbot.env              # LJOS_SEAT=grokbot; the process tree is not this seat
echo "$prompt" | ljos hook --prompt            # the prompt hook, from a shell
ljos policy --fail-on-deny -- git push --force # exit 1 on a deny; without the flag the exit stays 0
ljos findings out/campaign.json --remember     # file each resolved finding as a proposal
ljos group ops --add bob                       # a group of seats; membership is a pack atom
ljos send bob "the build is red" --issue acme-4 --interrupt
ljos send --group ops "the build is red"
ljos inbox                                     # unread mail; listing writes no receipt. hook --prompt marks what it shows read
ljos read <id>                                 # the receipt the sender sees
ljos reply <id> "looking"                      # back to the sender, on the same issue

MCP

ljos-mcp 通过标准输入输出提供相同的动词，ljos mcp 也一样，它会运行安装在旁边的 ljos-mcp。默认情况下，它会列出二十一个核心工具，优先列出规则和记忆：rule、request_approval、prefer、remember、search、start、guard_check、file、options、note、recall、sitting、finish、claim、release、send、inbox、reply、vote、consensus 和 doctor，每个工具都带有前缀 ljos_。 每个列出的工具都会在每次会话中占用其描述和架构所需的令牌：核心工具集为 8,103 个令牌，全部五十二个工具则为 17,691 个令牌（基于 o200k_base 对 initialize 指令和 tools/list 结果进行计数）。在服务的环境中设置 LJOS_MCP_TOOLS=all 会列出所有工具；LJOS_MCP_TOOLS=core,island,due 则会添加指定工具。工具执行失败时，会返回带有原因且标记为 isError 的结果，供模型读取。该服务还提供协议 ljos://protocol、只读卡片 ljos://cards/，以及三个提示词。ljos_due 会返回最早的八项认领，以及仍然到期的总数。将以下内容粘贴到运行器存放服务配置的位置：

{"mcpServers": {"ljos": {"command": "ljos-mcp"}}}

官方 MCP Registry 会从 ljos 的 crates.io 页面列出该服务，并检查其中的这一行：

• mcp-name: io.github.leidarljos/ljos

server.json 保存 Registry 条目，发布版本标签时会将其发布。Dockerfile 会构建并启动 ljos-mcp，供运行该服务的 Registry 列出其工具。

examples/unanimous-green/ 展示了两名实现者和两名审阅者如何通过 ljos consensus 达成一致的 GREEN。

一个由五个人格组成的评审小组为此席位选择了工具适配器。其投票、各人格评估的内容，以及学习前后对 settle 的两种解读，都在 examples/runtime-panel/ 中。

烟雾测试

scripts/smoke.sh 会在临时存储上运行每个循环。它涵盖记忆、共识、学习、一次 sitting 及其 finish，以及一项会关闭先前认领的改写。它还涵盖习惯、as-of 读取，以及已签名的交接；该交接先被接收，之后因一个字节发生变化而遭到拒绝。一条规则会经过 hook 和 policy。

然后，两个席位各自使用独立的 LJOS_SEAT 和 *_SESSION_ID，依次传递一张票据。A 开始 sitting、引用一项 deed 并交接；B 导入；A 释放；B 开始 sitting；双方投票；运行 consensus；finish 关闭票据；tracker git 报告提交记录。最后，scripts/herd.sh 会在一张有竞争的票据上运行八次 sitting、八次 finish 和一次 island fire。 scripts/terra/ 包含用于在集群上构建、运行烟雾测试并运行席位 herd 的 Slurm 脚本。

可选：Jev

默认情况下，席位会在本地进行所有判断。你可以在允许的机器上将这些判断交给 TypeSafe 托管的决策模型 Jev：创建 ~/.config/ljos/jev.toml，设置 enabled = true，并提供密钥命令。然后，Jev 会判断哪些认领与提示词相关，以及该提示词是在纠正 Agent，还是在让它作出选择。它还会为某个人格投票、判断 Agent 是否可以停止，并检查到期的认领是否仍然有效。

投票会记录为 judge:<model>，而不是人格名称。ljos due --judge 会列出评判者认为仍然有效的认领；ljos graded 会将其标记为已回忆。ljos judge-score 会根据结果读取评判日志。 本地答案仍会作为后备方案，没有该文件的机器会像以前一样运行。每条提示词的费用约为 $0.00004，即约 900 个输入令牌按每百万个令牌 $0.042 计费，输出免费；ljos doctor 会打印本月的支出。聊天后端必须指定 usd_per_mtok_in。说明文档的判断部分介绍了 Jev 如何与席位已有的功能配合；操作指南则说明了设置方法。

文档

该组织网站介绍如何就座：https://leidarljos.github.io。crate 网站采用 Org 加 Sphinx：https://leidarljos.github.io/ljos/.

页面	解答的问题
首次记录	安装、记住一句话，并搜索它
就座	sitting 开始，finish 结束
运行器	任何运行器都使用同一个入口；座位会自行命名
策略	哪些 shell 命令会被拒绝、由哪一层拒绝，以及用户如何批准命令
入门	在临时存储上使用记忆、约定和一次就座
操作指南	接入、入门、习惯、交接、信任
参考	每个动词、工具和变量
原理说明	契约、记忆模型、作为数据的时间，以及会不断学习的约定