Lific 实战：让 AI 编程 Agent 的计划、任务与交接不再困在上下文窗口里
让 Claude Code、Codex 或 OpenCode 连续写几天代码时，最容易失效的往往不是模型能力，而是工作状态。需求拆到一半，依赖关系留在聊天记录；下一轮会话虽然能读仓库，却不知道哪个任务被阻塞、哪个方案已经否决、上个 Agent 为什么没有继续改某个文件。把这些内容塞进 AGENTS.md 或一串 Markdown TODO 能解燃眉之急，但多人和多 Agent 同时工作后，状态很快分散。
Lific 是一个用 Rust 编写的本地优先 issue tracker：一个二进制文件、内嵌 SQLite 数据库和 Web UI，同时提供 CLI、REST API 与 MCP 服务。它的定位并非替代大型团队的项目管理平台，而是给一个人带着多个编码 Agent 工作时，提供可持续的任务、计划、文档和审计记录。项目为 Apache-2.0 许可；仓库当前的 Cargo.toml 标明版本为 2.2.1。
先把“会话记忆”换成可查询的工作状态
Lific 的关键取舍是：计划和 issue 不属于某个对话，而属于一个本地服务。它把任务、评论、页面、模块和嵌套计划写入 SQLite；Web UI 嵌入同一个二进制，默认服务地址是 http://localhost:3456。这意味着重开终端、切换 Agent 或第二天继续工作时，状态仍在。
与“让 Agent 每次先读一大段项目说明”相比，这种方式有三个工程收益：
- 工作项有稳定 ID。 例如
APP-42可出现在 commit、日志、评论和提示词中，比临时描述更容易检索和追踪。 - 计划与执行可以闭环。 Lific 的 plan 是可嵌套步骤树；步骤可关联真实 issue。完成步骤会关闭对应 issue，重新打开 issue 也会将步骤恢复为未完成。
- 多工具操作可追溯。
lific connect能为连接的工具建立独立 bot 身份。这样日志中能区分“哪个 harness 修改了什么”，而不只是看到一个模糊的管理员操作。
这不是把所有决策都交给 Agent。更好的做法是由人维护优先级和验收标准，让 Agent 通过受限的工作项读取上下文、写入进展，并把不确定之处留在评论里。
60 秒启动一个本地实例
Lific 官方 README 给出的最短路径如下。init 会建立配置和数据库、打印一次 API key，并注册后台服务；connect 会探测并写入所选客户端的 MCP 配置。
cargo install lific lific init lific connect lific doctor
在 Linux 上，默认配置位于 ~/.config/lific/，数据位于 ~/.local/share/lific/；如果希望 tracker 与单个仓库放在一起，可使用 lific init --here。初始化后先执行健康检查很重要：lific doctor 会检查配置、数据库、服务、OAuth discovery 和一次 MCP 往返；它在真正故障时以非零状态退出，适合接入脚本或 CI。
如果不想让它注册后台服务，可以改为前台运行：
lific init --no-service lific start
这种模式适合容器、进程管理器或排查网络、配置问题。不要同时让同一份数据库被两个独立实例写入；Lific 的本地优先设计是“一套 SQLite 数据库对应一个权威实例”，不是多节点 CRDT 同步系统。
上线前还应把备份当作日常操作，而不是故障后的补救。Lific 提供 lific dump 与 lific restore，可把数据库及附件打成单一归档；自动归档也有保留策略。对于个人或小团队，最实际的节奏是：在升级版本、批量导入任务、让 Agent 执行大范围状态迁移前各做一次 dump，并将归档复制到实例所在磁盘之外。恢复演练时先在临时目录或测试实例验证，避免为了找回一条误删任务又覆盖掉最新工作状态。
连接编码 Agent：优先使用自动配置，但理解它写了什么
lific connect 支持 OpenCode、Claude Code、Claude Desktop、Cursor、VS Code、Codex、Zed、Gemini、Windsurf、Goose 和 Crush。它会按各客户端的配置格式写入 MCP 条目，并尝试合并 JSON，而非粗暴覆盖已有配置。对于脚本化环境，可明确指定客户端并预览结果：
lific connect --client claude-code --scope project lific connect --client codex --yes lific connect --dry-run --client vscode
前一条将配置写到项目范围；第二条用于非交互配置；第三条只显示将要做的变更。完成后需要重启对应客户端，使 MCP server 被重新加载。
自动配置失败或你使用的客户端不在支持列表中时，官方 README 还提供 Streamable HTTP 的通用形态。示例中的 key 必须替换为你自己的值，且本地 HTTP 地址不应直接暴露到不受信任网络：
{
"lific": {
"type": "remote",
"url": "http://localhost:3456/mcp",
"headers": {
"Authorization": "Bearer your-api-key"
}
}
}
Lific 也提供无需常驻服务的 stdio 方式：lific --db path/to/lific.db mcp。前者更适合多个本地客户端共享一个 tracker；后者适合把数据库作为局部工具直接交给一个客户端。两者不要混为一谈：HTTP 服务有用户、API key 与审计链路，stdio 则是直接访问指定数据库。
给 Agent 一套可执行的协作约定
连接 MCP 只解决“能调用工具”，不自动解决“何时调用”。建议在仓库中把以下节奏固化下来：
- 开始前让 Agent 查询可执行工作项，而不是根据模糊的 TODO 自行挑题；被依赖项阻塞的任务不应被当作可开始任务。
- 编码前先将实现步骤写入 plan，并把关键步骤关联 issue；这样会话压缩或换模型后，下一位执行者能从计划树恢复。
- 每次完成一个可验证单元后更新 issue 状态、记录测试命令及结果；不要只在聊天里说“已完成”。
- 出现设计分歧时写评论或 Markdown page，链接到受影响的 issue。这样决策理由与任务相邻，而不是沉入某段历史对话。
CLI 适合把这套约定放进脚本。以下命令均来自项目 README 中的命令参考：
lific project list lific issue list --project APP lific issue create --project APP --title "修复登录回调" --priority high lific issue update APP-42 --status done lific search "authentication" --project APP
当输出被管道接收时，Lific 会自动输出 JSON；这让 shell、CI 或另一个 Agent 能消费结构化结果。对于首次接入的仓库，lific agents-md 可以向 AGENTS.md 写入带标记的说明块，告诉不同 Agent 该项目使用哪个 tracker 以及基本工作流。它是协作提示，不是权限边界；真正的项目访问控制仍应依赖 Lific 的成员角色、API key 或 OAuth 设置。
MCP 的上下文成本与权限边界
工具数量本身也会占上下文。Lific README 将完整 tools/list 响应描述为 27 个 MCP 工具、5,641 tokens（v2.2.1、o200k tokenizer 的测量值）。这解释了它为什么把 issue、plan、page、关系、评论、搜索和导出收进同一套紧凑工具面：连接前先确认客户端的 MCP 上下文预算，避免再叠加大量不常用 server。
安全上更值得关注的是身份隔离。默认推荐的 connect 流程会为每个客户端创建独立 bot identity，因此可以撤销某一个工具的 key，而不影响其他工具；而 OAuth 方式可用浏览器登录，但以你的身份执行操作，审计粒度较低。若开启项目级授权，新实例默认执行 viewer、maintainer、lead 等成员检查；实例管理员和 operator-trusted 凭据是有意的高权限例外，应只交给受控自动化。
Lific 也明确列出不适合的场景：需要 SSO/SAML、甘特图与大规模人类协作时，应考虑 Linear 或 Plane；希望任务随 Git diff 演进时，Markdown/Git 原生 tracker 更合适；需要多节点并发同步时，也不应把单 SQLite 实例当成分布式数据库。
什么时候值得引入它？
如果你的工作流已经出现“一个 Agent 写代码、另一个 Agent 审查、第三个 Agent 接手修复”，而任务状态仍散落在对话、临时文件和 commit message 里，Lific 的价值在于把这些协作痕迹变成可查询、可授权、可备份的本地服务。先用一个项目试运行：只迁移当前迭代的 issue 和一个计划，观察 doctor、审计记录和交接是否真的减少了重复解释；确认收益后，再让更多客户端通过 MCP 接入。
试运行的验收标准不必复杂：一次会话中创建任务和计划，换一个客户端继续读取并更新；随后用审计记录确认身份归属，再从备份中验证能恢复到预期状态。只有这条完整链路跑通，才说明它真正替代了散乱的上下文记忆，而不是又增加了一套需要人工维护的表面流程。
相关链接