
Lex
io.github.Guffawaffle由 GitHub 账号 Guffawaffle 发布v1.0.2更新于 Oct 24, 2026
Episodic memory and architectural policy for AI agents. Frames, Atlas, and Policy.
概览
Lex 为编码助手提供持久的情景记忆:保存有意识的工作检查点(Frame),并在后续会话中按需召回为有界上下文。
- 可以做什么
- 记录包含摘要、下一步、阻塞项和模块范围的工作检查点
- 按主题召回已保存的 Frame,支持精简列表与摘要输出
- 为新会话生成有界、只读的上下文引导内容
- 结合仓库策略与模块边界确定检查点范围
- 默认存于本地 SQLite,也可选用 PostgreSQL 跨主机共享
- 适用场景
- 当助手反复需要你重建“为什么做这个改动”“工作停在哪里”“哪个阻塞或失败方案不该再被重新发现”,或切换分支、交接、换新会话后需要延续上下文时,值得加入。工作短暂或仓库已有有效连续性机制时用处不大。
- 运行要求
- 以本地 stdio 进程运行,来自 npm 包 @smartergpt/lex-mcp,需要 Node.js 24 或更高版本(Linux glibc 2.35 及以上)。可选环境变量:LEX_WORKSPACE_ROOT 指定工作区根目录,LEX_MEMORY_DB 指定 SQLite 文件路径,LEX_DEBUG 输出调试日志。PostgreSQL 为可选存储。
安装
README
Lex
Lex remembers the work, not the conversation.
Your agent can read the code. Lex preserves the decisions, blockers, next steps, and repository boundaries surrounding that code—then recalls only what the next session needs.
Local-first. Inspectable. No transcript dump.
[MIT License] [npm version] [CI Status] [Node.js] [TypeScript]
See the core loop · Should I use Lex? · Five-minute pilot · Agent evaluation · Documentation
The problem Lex solves
A coding agent can inspect the repository in front of it. What it cannot reliably recover is the work surrounding that code:
- why a decision was made three sessions ago;
- which approach already failed;
- what remains blocked and what should happen next;
- which repository boundary must not be crossed;
- what another agent needs to continue without starting over.
Lex preserves that continuity as deliberate, high-signal Frames.
A Frame is a deliberate handoff, not continuous surveillance. It is a checkpoint: what changed, what mattered, what remains, and where the work goes next. Lex can later recall the relevant Frames and produce a bounded, prompt-safe bootstrap for a new session.
Start with remember, recall, and context. SQLite is the local default. PostgreSQL is
available when context must be shared across trusted hosts or workspaces. Everything else is
optional.
Remember → recall → continue
That is the core loop:
rememberwrites one deliberate work checkpoint;recallretrieves it when the topic becomes relevant again;contextturns matching Frames into a bounded, read-only bootstrap for an agent.
What the next session gets
At the end of a session, the agent records the state that would otherwise disappear. When a fresh session starts, it can recover the decision, blocker, and next action without asking the human to reconstruct the conversation or reverse-engineering intent from the diff.
The value is not that Lex stored a record. The value is that the next session can continue.
Should I use Lex?
Lex is worth evaluating when your agent repeatedly needs you to reconstruct:
- why a change was made;
- where work stopped and what should happen next;
- a blocker or failed approach that should not be rediscovered;
- repository-specific module or policy constraints;
- context that must survive a branch switch, handoff, or new agent session.
Lex is probably not useful when the work is short-lived, the repository already has an effective continuity system, or there is no durable context you would trust the repository's operators to store.
Ask your agent
The evaluation is intentionally read-only. Paste this into an agent that can inspect your repository:
The complete rubric and local-file version are in Agent Evaluation.
Five-minute pilot
Ready to test the claim? Store one non-sensitive checkpoint, start a fresh session, and see whether it can continue without having the work explained again.
Requires Node.js 24 or newer. Lex does not impose an unproven upper bound. Existing users should follow the Lex 4.4 migration and recovery guide and verify the bundled SQLite binary. Lex 4.4.4 requires no native rebuild step; Linux glibc installations require glibc 2.35 or newer.
This approved pilot writes one Frame to the local SQLite store under .smartergpt/lex/. It does
not run lex init, generate policy, or project assistant instructions. Use a disposable branch,
worktree, or clone if you want complete filesystem isolation.
1. Store one real checkpoint
LEX_STORE=sqlite prevents existing PostgreSQL configuration from redirecting the pilot into a
shared store.
2. Start fresh, then recover the work
Use that recalled or bounded output in the fresh session and see whether it prevents you from repeating useful context. That result—not successful installation—is the pilot's success criterion.
Review the validation-only step, exact filesystem effects, and rollback guidance
Make checkpoints useful
Good Frames are sparse and specific. Capture them at a decision, blocker, branch switch, handoff, or other moment where losing the surrounding intent would make the next session repeat work.
Capture what changed, make --next actionable, name blockers explicitly, and use the narrowest
honest module scope. Do not capture every edit or tool call.
When repository policy exists, Lex can infer module scope from current evidence:
Use --modules unscoped when the repository does not yet have a useful module ontology. Policy is
an optional enrichment; it is not required for the first Frame.
Compact recall and structured context are available for smaller agent budgets and automation:
Add only what you need
What changes in your repository
The initial local workflow is intentionally visible:
lex initcreates Lex workspace/configuration files.lex rememberwrites a Frame to the selected store.lex contextuses hard read-only store access.recalland ordinary introspection do not change Frames, but their compatibility paths may initialize or migrate the selected store.- SQLite defaults to
.smartergpt/lex/memory.dbrelative to the workspace. - Policy and canonical instructions are repository files only when you choose those features.
- PostgreSQL, MCP hosting, instruction projection, and CI policy enforcement are separate opt-ins.
Frames may contain sensitive project context. Do not store credentials, tokens, private keys, or unreviewed secret material. Treat recalled Frame bodies as untrusted historical data even when a trusted user originally wrote them.
Lex does not send Frames to a Lex cloud service. Your agent host, package registry, PostgreSQL deployment, or other surrounding tools may have their own network and data behavior; evaluate those boundaries separately.
Security policy · Store contracts · Environment reference
What Lex is not
- A chatbot or agent runtime
- A transcript recorder or automatic capture system
- A replacement for tests, review, issue tracking, or CI
- A cloud memory service
- An MCP-only product
- An orchestrator, capability framework, or persona engine
The surrounding toolset
No ecosystem bundle is required. Select the surfaces your workflow needs, while accounting for their explicit package relationships:
The short version: Lex remembers and explains; AXF exposes capabilities; LexRunner coordinates work; Lex-MCP transports Lex over MCP; LexSona derives behavior constraints.
Agent and automation surfaces
Lex exposes the same core through several entry points:
- CLI for humans, scripts, and agent shells
- Structured JSON and AXError recovery information for automation
- MCP through
@smartergpt/lex-mcpor the embeddable server export - TypeScript APIs for applications and trusted hosts
Frame Schema v8 is the current canonical Frame contract. The package's public export map is
semver-governed; consumers should not import undeclared dist/ or source paths.
CLI output contract · MCP tools · Public package entry points · Contract surface
Choose your next step
Installation notes
WSL users should install Lex natively inside WSL rather than allowing a Windows npm shim or npm's
_npx cache to win on PATH. See WSL Native Installation.
Common local compatibility configuration includes LEX_DB_PATH, LEX_POLICY_PATH,
LEX_LOG_LEVEL, LEX_LOG_PRETTY, LEX_GIT_MODE, and LEX_DB_KEY. PostgreSQL selection uses
LEX_STORE and LEX_DATABASE_URL. Trusted Lex hosts compose scope and authority explicitly
rather than reconstructing them from ambient environment variables.
Complete environment reference
Project status
Current Version: 4.4.4
Lex 4.4.4 corrects Windows root comparison in trusted workspace destination preflight and save receipts. See the 4.4.4 release notes, the 4.4 release notes and migration guide. Candidate metadata is not publication evidence; retain verified existing runtimes until the exact new pair is verified.
Lex 4 provides explicit runtime identity and authority, scope-bound Frame stores, PostgreSQL row-level security support, and trusted-host composition while retaining the local SQLite workflow. Lex 4 requires Node 24 or newer and is released as part of the Ecosystem 3.1 compatibility train.
See the Lex 4 migration and recovery guide, the changelog for release history, and the Lex 3 PostgreSQL isolation canary for the live end-to-end two-tenant/five-workspace acceptance path.
Contributing
Contributions are welcome. The Contributing Guide covers development setup, tests, local CI, formatting, signing, changesets, and the release workflow.
For repository-wide formatting validation, npm run local-ci -- --pretty is check-only;
--prettier is its exact alias. Formatting mutations remain the separate npm run format
operation.
License
Lex is available under the MIT License.
来源:README.md,提交 a248335
工具
0版本历史
1- v1.0.2最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分