夜行代理 cnlangzi/nightme

NightMe

安享好梦，NightMe 彻夜向前。

奔赴你的星辰大海，拥有你的自由生活。而那些必须死守电脑、避无可避的无奈，就让 NightMe 替你守候。

English · 简体中文

Go Reference

What is NightMe

NightMe 把你的本地 AI Coding Agent（Claude Code、Codex、DeepSeek Harness (DSH)、GitHub Copilot CLI、Pi、OpenCode 等）放进聊天里跑。你在任何已接入的 IM 里发条消息，NightMe 就把消息路由到对应的 agent 进程，回复以结构化卡片形式返回。

多个 chat 并行——一个项目一个，目录就是项目本身：每个 ChatSession 跑在自己的工作目录上，目录即项目本体。多个 Agent 并行工作——切换是即时的，无需冷启动。整个开发周期被规范成 Git Team Workflow（/gtw）：讨论 → issue → worktree → commit → push → PR → close，每一步一个斜杠命令、一张 IM 卡，集成 GitHub 和 GitLab。NightMe 不替换你的 agent 订阅或记忆，只在它们前面做一个轻量代理。

Why NightMe

一个 chat，一个 CWD，一个项目

作为独立开发者，你一个人同时管很多项目。每个飞书群组或 DM 是一个 ChatSession，每个 ChatSession 有自己的 CWD（当前工作目录）。CWD 就是 项目：用 /cwd <path> 设置，随时可以改。多个 chat 并行跑，各自绑定各自的目录。

You (Feishu)
│
▼

┌─ ChatSession ─┐ ┌─ ChatSession ─┐ ┌─ ChatSession ─┐
│ CWD: ~/a │ │ CWD: ~/b │ │ CWD: ~/c │
│ │ │ │ │ │
│ AI Agents: │ │ AI Agents: │ │ AI Agents: │
│ Claude Code │ │ Claude Code │ │ Claude Code │
│ Codex │ │ Codex │ │ Codex │
│ Pi │ │ Pi │ │ Pi │
│ OpenCode │ │ OpenCode │ │ OpenCode │
│ DSH │ │ DSH │ │ DSH │
│ Copilot │ │ Copilot │ │ Copilot │
└───────────────┘ └───────────────┘ └───────────────┘

▲ CWD = 项目；agent 在该 CWD 里跑；全部从同一个 NightMe 实例并行 ▲

飞书聊天列表——多个并行 ChatSession（DM + 群组），每个钉在各自项目上

项目之间靠目录隔开。 每个 ChatSession 的 CWD 互不影响——重跑 /cwd 只改当前 session 的工作目录。多个项目同时跑着，互不打扰。

与传统工具的差异（Hermes、openclaw、cc-connect、happycoder）：他们一次只激活一个 session。NightMe 在一个实例上同时跑所有项目。切换 chat 是即时的——同一个 daemon，无需冷启动，无需重新初始化。

三项核心能力

| 能力 | 实际意义 |
| 并行多 ChatSession | 一台机器 N 个 session，各自跑不同项目或任务。 |
| CWD = 项目 | 每个 ChatSession 绑定一个当前工作目录——目录 就是 项目。用 /cwd <path> 设置；随时切换。 |
| 同 Chat 多 agent | /use <agent> 切换当前 agent。前一个 agent 切到后台继续跑——任务推进、结果照常回，只是新消息不再路由给它。 |

在此之上：Git Team Workflow。 用 /gtw plan 定方案 → /gtw new 把讨论生成 issue → /gtw fix <id> 开 worktree 并把 issue 交给 agent → /gtw commit · /gtw push · /gtw pr 按 Conventional Commits 交付 → /gtw close 收尾。整个团队的需求、开发和 Git 操作共用一套规范。

支持的接入

NightMe 直接接住你已经在用的 AI 编程 agent 和日常聊天的 IM。下面是目前支持的，以及正在路上的。

AI Coding Agent

| Agent | 状态 |
| Claude Code | 可用 |
| Codex | 可用 |
| Pi | 可用 |
| DSH（DeepSeek Harness） | 可用 |
| Cursor | 可用 |
| OpenCode | 可用 |
| GitHub Copilot CLI | 可用 |

聊天 Channel

| Channel | 状态 |
| 飞书 Feishu（国内）/ Lark（国际） | ⭐ 推荐 — nightme login feishu |
| Telegram | 正式发布 — nightme login telegram |
| Slack | 开发中 — nightme login slack |

Prerequisites

- macOS、Linux 或 Windows — NightMe 是单文件 Go 二进制。Linux 默认版本是完全静态、无运行时依赖的；如果需要系统栏图标见 Linux：默认不带系统栏图标。
- 一个聊天平台 — 飞书 / Lark（国内或国际）或 Telegram。nightme login feishu 通过扫码完成飞书 / Lark 的 bot 注册；nightme login telegram 走 BotFather 流程。
- 至少一个本地 AI Coding Agent — Claude Code、Pi、OpenCode、Codex、DeepSeek Harness (DSH)、GitHub Copilot CLI 任一。装好 CLI 放到 $PATH 上，NightMe 会作为子进程拉起。

Install

三种方式装 nightme：

1. One-liner（推荐）：

macOS / Linux：
curl -fsSL https://nightme.dev/install.sh | bash

Windows（PowerShell）： powershell -c "irm https://nightme.dev/install.ps1 | iex"

会把最新版 release 装到 $PATH 上的稳定路径，并跑 nightme version 验证。Linux 上装的是不带系统栏图标的版本，见下文。

2. 预编译二进制（手动）：

- 去 latest release page 下载对应平台的压缩包（如 nightme_<version>_darwin_amd64.tar.gz、 nightme_<version>_linux_amd64.tar.gz、 nightme_<version>_windows_amd64.zip）
- 解压后里面的二进制就叫 nightme（Windows 是 nightme.exe），放到 $PATH 上并加可执行权限：
tar -xzf nightme_<version>_darwin_amd64.tar.gz
mv nightme /usr/local/bin/nightme
chmod +x /usr/local/bin/nightme

Windows 上解压后把 nightme.exe 放到 PATH 上的某个目录即可。
- Linux 每个架构还额外发一个 -gui 包，见下文。

3. 从源码（开发或钉死一个 commit）：

git clone https://github.com/cnlangzi/nightme.git
cd nightme
make dev

make dev 直接从源码跑 nightme，配置文件用 example config，无需单独构建。

Linux：默认不带系统栏图标

Linux 每个架构发两个包：

| 压缩包 | 系统栏图标 | 运行时依赖 |
| nightme_<version>_linux_<arch>.tar.gz | 无 | 无 —— 完全静态 |
| nightme_<version>_linux_<arch>-gui.tar.gz | 有 | libgtk-3-0、libayatana-appindicator3-1 |

默认包就是 install.sh 下载的那个，也是服务器上你想要的那个：完全静态、不链接任何动态库，任何发行版、任何 glibc 版本、不装任何包都能跑。

系统栏图标需要 GTK3 和 AppIndicator，而这是无头服务器没有理由安装的库。把它们作为硬依赖的后果是：在纯服务器上二进制根本起不来 —— 连 nightme version 都不行，因为动态链接器在任何代码执行之前就拒绝了这个进程：

nightme: error while loading shared libraries: libayatana-appindicator3.so.1:
cannot open shared object file: No such file or directory

所以 Linux 上系统栏图标改成可选。如果你在桌面环境跑 NightMe 并且想要图标，直接用 -gui 包覆盖现有的即可 —— 包里的二进制同样叫 nightme，其他什么都不用改：

sudo apt install libgtk-3-0 libayatana-appindicator3-1 # Debian / Ubuntu
tar -xzf nightme_<version>_linux_amd64-gui.tar.gz
sudo mv nightme /usr/local/bin/nightme

从源码构建也是同样的区分：make build 出不带图标的版本，make build-gui 出 bin/nightme-gui（需要 libgtk-3-dev 和 libayatana-appindicator3-dev）。

不带图标不会少任何功能：daemon 是通过 Unix socket 控制的，所以 start / stop / restart / status / logs 和 REPL 行为完全一致。macOS 和 Windows 不受影响 —— 它们的系统栏后端随 OS 自带，图标一直是编进去的。

升级与维护

nightme update 是就地升级路径：解析最新 release、下载对应 asset、用发布的 SHA256SUMS 校验、替换二进制、重启 daemon。--tag vX.Y.Z 钉版本；--yes 跳过确认（CI）；--no-install 只下载不替换。重跑 one-liner 安装脚本同样完成替换。

nightme clean 清空 nightme.log 和 daemon-stderr.log、清掉按会话存放的附件 inbox（~/.nightme/inbox），保留配置、session 状态、锁文件和 daemon socket。nightme clean --all 是全量本地重置——还会删配置、session store、生命周期文件和缓存；用 --all 前先 stop daemon。

Quickstart

nightme login feishu # 终端打印二维码；用 Feishu 移动端扫码 nightme start # daemon 在后台跑起来

start 返回后，NightMe 会给你的 Feishu DM 发一条 welcome message——这就是它已经 ready 的信号。

CLI commands

大多数时候你都在 chat 里。需要回终端的只有这几条：

| 命令 | 作用 |
| nightme start / stop / restart | 开关 NightMe。开也好关也好，你的 agent 照常干活。 |
| nightme status | NightMe 在跑吗？ |
| nightme list | 列出你所有的 agent：在哪个 chat、哪个项目、还活着还是已结束。 |
| nightme kill | 一次性停掉所有 agent。在 chat 里发条消息就回来了，对话不丢。 |
| nightme logs | 实时看 NightMe 在干什么。 |
| nightme config | 交互菜单：实例名、主 agent、每个 agent 的二进制路径。 |
| nightme update | 就地升级：检查、下载、SHA256 校验、安装、重启 daemon。 |
| nightme clean | 清空日志、清掉附件 inbox；--all 全量本地重置（先停 daemon）。 |
| nightme workflow | list / show / dry-run ~/.nightme/workflows/ 下的 workflow YAML。 |
| nightme doctor | 觉得哪里不对时，看一眼 NightMe 是否健康。仅 Unix。 |
| nightme version | 打印版本信息。 |

nightme test 在 PTY 里起一个 CLI，做本地快速验证。

「停」分三个范围：/close（单个项目）· nightme kill（所有 agent）· nightme stop（NightMe 自己）。三种都不会丢对话。

Slash commands

Chat 级别的斜杠命令。/gtw 子命令见 它们自己的 section，这里不列。

| 命令 | 干什么 |
| /cwd <path> | 绑定这个 Chat 到一个工作区。会校验路径，下次发消息时 lazy-spawn。 |
| /use <agent> | 切换当前 agent（claude / codex / dsh / opencode / copilot / omp / pi）。前一个 agent 切到后台继续跑——任务推进、结果照常回，只是新消息不再路由给它。 |
| /stop | 停掉当前 agent 上的 in-flight turn。会话留着，队列里的消息继续流。 |
| /steer <msg> | 停掉 in-flight turn 并把 <msg> 插到队首。下个 turn agent 第一眼看到的就是这条。 |
| /close [agent] | 终止当前工作区里 AgentSession 的 bridge 进程。AgentSession 记录保留——下次发消息触发 respawn 时会用 --resume <sessionID> 接着聊。 |
| /new [agent] | 重置 agent 对话上下文（Claude Code 的 /clear 等价）。进程保留，队列清空。 |
| /watch on\|off | 当前 Chat 的消息监听模式（默认群内只听 @bot / @_all）。 |
| /think on\|off | 是否在回复卡里展示 agent 思考过程。 |
| /tools on\|off | 是否展示每个工具的独立线程回复（默认关）。 |
| /handoff <name> | 把当前任务序列化到 ~/.nightme/handoff/<name>.md，下一个 agent（或新 session）从任意目录接手。 |
| /resume <name> | 在当前 session 里继续 ~/.nightme/handoff/<name>.md 描述的任务。 |
| /review [--agent <agent>] | 当前分支对比默认分支做 review（PR 模式），findings 注回当前 chat。--agent 指定用哪个 agent 跑 review。 |
| /wiki init [--modules] [--llmstxt] [--arch] | 读码、分模块、写每个模块的 wiki 文件——把仓库 wiki 作为项目资产。 |
| /queue <message> | 把一条消息作为独立 Prompt 追加进队列。 |
| /help | 在 Chat 里列出所有斜杠命令。 |

!cmd 在当前 Chat 的 CWD 里直接跑 shell 命令——规则见 Shell mode。

任何不匹配斜杠命令（或 !cmd）的消息，都会被透传到底层 agent 当作普通 prompt——跟你直接在 Claude Code 自己的 CLI 里发消息一样。NightMe 不拦截也不改写；agent 收到原样消息，会运行它自带的斜杠命令（例如 Claude Code 的 /clear / /compact / /init 等）。

Always-in-the-loop

你随时知道 agent 在哪、干到哪、烧了多少钱——每条回复都带一张固定页脚，写清楚关键信息，不用离开 chat。多数「AI 写代码 + 聊天」工具都跟黑盒一样；NightMe 把可视化当成一等公民。

StatusBar——钉在每条 Feishu 回复上

飞书页脚卡——CWD / git / agent / token，每条回复都带

每条回复都带一张固定页脚，写清楚关键信息：

- CWD — 当前 ChatSession 处于哪个目录（也就是项目）
- Git status — 分支、是否 dirty、ahead / behind
- Agent status — idle / running / thinking
- Token usage — 当前 session 已用 / 上限

别的工具把你丢进黑盒。NightMe 让你随时看到 agent 在哪、干到哪、花了多少。

Flexible visibility

| 开关 | 作用 |
| /think on\|off | 是否展示 agent 的思考过程。 |
| /tools on\|off | 是否展示每个工具的独立线程回复（默认关）。 |
| /watch on\|off | 监听群内所有消息，不再只听 @bot / @_all。 |

为什么这很重要： NightMe 默认把状态摊开，想安静的时候随时切回静音——这是你的选择，不会突然跳出来。

What we do differently

| 特性 | openclaw / Hermes | NightMe |
| Sessions survive daemon restart | ❌ | ✅ |
| 真的 /stop 和 /steer | ❌ | ✅ |
| 没有 server-side timeout | 30 min | none |
| Clean prompts, no preamble | ❌ | ✅ |

四点不同，简而言之：

1. Sessions survive。 Daemon 重启、网络抖动、合盖休眠——聊天从你断的地方接住。上游 CLI 的 session 通过 --resume <session-id> 恢复。

2. 真的 escape hatches。 /stop 停掉 in-flight turn。/steer <msg> 改方向。两者都保留 session 和上下文。

3. No clock on you。 Claude 跑 30 分钟，NightMe 等 30 分钟。你决定什么时候停。

4. No prompt padding。 没有 preamble、没有 brand voice、没有 injected system message。CLI 只看到你写的话。

We sit in front of Claude / Codex / DSH (DeepSeek Harness) / Pi / OpenCode. You stay in control. Nothing in a black box.

Shell mode

你并不总是需要 agent 跑 shell 命令。用 Claude Code / Codex 时，让 agent 跑命令要绕它的 tool loop——链路长，context 也被消耗，agent 忙着读 shell 输出，你正事反而被挤到一边。

!cmd 跳过这一切。在 chat 里敲 !make test，NightMe 直接在 chat 的 CWD 里跑命令。回复是一张简洁的 IM 卡。No agent, no round trip, no context eaten。

项目里那些本来就有的脚本——make、npm test、deploy hook——谁 run 都一样。agent 在中间想一遍反而浪费时间。

✅ $ make test
exit 0 · 12ms · ~/work/foo stdout: All tests passed

Git Team Workflow (/gtw)

/gtw 是一套完整的 Git 团队工作流——从 chat 里的讨论一路走到合并的 PR，全程在 chat 里完成。 每个需求落成一个 issue，每个 issue 独占一个分支和 worktree，每个 commit 和 PR 都遵循 Conventional Commits，issue 在 GitHub / GitLab 上的状态随工作推进。无论是哪位同事、哪个 AI agent 来做，需求、开发和 Git 操作都按同一套规范走。

/gtw plan ──▶ /gtw new ──▶ /gtw new -y ──▶ /gtw fix <id> [-y] ──▶ /gtw commit ──▶ /gtw push ──▶ /gtw pr ──▶ /gtw close
(设计) 起草方案 创建 issue #N worktree + agent 提交 推送远程 PR 收尾 ▲ │ └───┘ /handoff <name> · /resume <name> （上下文太长，或要切换 agent）

| 步骤 | 命令 | 规范了什么 |
| 1. 需求 | /gtw plan → /gtw new → /gtw new -y | 先在 chat 里把方案定下来、不动代码，再把讨论变成一个自包含的 issue：背景、范围、带验收标准的需求、方案设计、关键决策、实施计划。 |
| 2. 开发 | /gtw fix <id> [-y] | 一个 issue = 一个分支 = 一个 worktree，从刚 sync 过的默认分支切出。issue 打上 nightme/wip 标签并派发给 agent。 |
| 3. 交接 (可选) | /handoff <name> · /resume <name> | 把任务状态写进文件，新 session 或另一个 agent 接着做，进度不丢。 |
| 4. 提交 | /gtw commit [-a <agent>] | agent 暂存改动并写出符合 Conventional Commits 的 commit message。只在本地。 |
| 5. 推送 | /gtw push | 把分支推到 origin。worktree 有未提交改动时拒绝。 |
| 6. PR | /gtw pr [-a <agent>] | 用 Conventional Commits 标题、结构化正文和 Closes #<id> 创建 PR / MR。 |
| 7. 收尾 | /gtw close | 移除 nightme/wip 标签、worktree 和本地分支；chat 回到默认分支，并 sync 到最新。 |

第 1–2 步跑在 chat 当前的 agent session 里，你一直在和做分析的那个 agent 对话。commit 和 pr 起一个 one-shot agent，做完就退出，不污染主对话。push、close、back、sync 是纯 Git / 平台操作，不经过 agent。每一步回复一张 IM 卡。GitHub（gh）和 GitLab（glab）根据 origin 自动识别；新仓库第一次用无需任何配置。

默认就支持并行：三个 issue 就是三个 worktree、三个分支、三个 agent，互不共享状态。

1. 需求 → issue：/gtw plan · /gtw new

/gtw plan [topic] 在讨论需求之前，让 chat 当前的 agent 进入 plan mode。agent 以设计伙伴的身份工作：只读做决策需要的代码，比较方案并给出推荐，只问仓库回答不了的问题，每个定下来的点都用一行 Decision: 标出。它不改文件、不跑 build 或测试、不写实现代码、不把方案拆成任务清单；祈使句式的需求（"把 X 文件里的 Y 改成……"）它当作要核对的设计输入，而不是要执行的指令；你同意某个方案也不会让它动手——方案定完时它会提示你执行 /gtw new。plan mode 在 /gtw new 起草 issue 时结束；再执行一次 /gtw plan 会重申规则，讨论接着往下走，不会从头开始。

和 agent 来回讨论完一个需求后，/gtw new 把这段讨论归档成 GitHub / GitLab issue，没看过聊天记录的开发者或编码 agent 拿到就能实现。它跑在 chat 当前的 agent session 里，因为讨论只存在于那里。

它是两段式命令——agent 起草，人来决定：

1. /gtw new — agent 从对话里提取所有需求、约束、决策和边界情况（plan mode 留下的 Decision: 行作为已定结论），消解前后矛盾（被否决的方案连同理由放进 Decisions 一节）。还有阻塞性的问题没定时，它只问一次——所有问题放在一条消息里，每个附建议默认值——然后停下；在 chat 里回答即可，它接着写草稿（再跑一次 /gtw new 也行）。一段讨论默认只生成一个 issue，同一改动的代码、测试、文档始终放在一起。只有讨论里包含互不相关的目标、且每个目标不依赖其他目标也算完成时，它才会在同一轮提问里建议拆成几个 issue，你同意后每个 issue 一份草稿。没有问题时，它写出草稿并把完整文档显示在 chat 里：背景与目标、范围、术语、带验收标准的需求、方案设计、边界情况、约束、关键决策、实施计划、待定事项。想改（包括拆分、合并）就在 chat 里提，它会重写草稿。
2. /gtw new -y — 确认草稿没问题后，NightMe 通过 gh / glab 按草稿顺序逐个创建 issue（正文末尾附一行 Generated by NightMe），回复 issue 编号。草稿之间用 {{ISSUE:NN}} 互相引用，创建时替换成真实编号，而且一份草稿只能引用同一组里编号更小的草稿。创建前先校验全部草稿，任一不合法就一个都不建；中途失败时已建的 issue 照常保留，再跑 /gtw new -y 只建剩下的。这一步不经过 agent。

issue 标题遵循 Conventional Commits，/gtw fix 据此生成可读的分支名。草稿存放在 ~/.nightme/issue-drafts/ 下每个 chat 一个目录，一个 issue 一个文件（01.md、02.md……）；/gtw new 会清空它，/gtw new -y 每建好一个 issue 就把对应草稿换成 NN.created 记录，agent 据此不会再重写已建好的 issue。

2. 开发：/gtw fix

/gtw fix <issue-id> 先 sync 默认分支，按 issue 标题创建 worktree 和分支，给 issue 打上 nightme/wip 标签，把 chat 的 CWD 切进 worktree，跑 fix hooks，再把 issue（正文和附件）派发给 chat 当前的 agent。

- 先评估（默认） — agent 对照代码核实 issue，贴出实施计划后停下等你。在 chat 里审过方案，再让 agent 动手。
- -y / --yes — agent 直接实现。

/gtw fix --name <branch>（或 -n）创建一个不关联 issue 的本地 worktree，由你自己指挥 agent。

/gtw back 临时离开 fix worktree 而不拆掉它——chat 的 CWD 回到仓库根目录并 sync 默认分支，worktree、分支和未提交的改动都留在磁盘上。/gtw back <worktree> 再切回去。

/gtw sync（git checkout <default> && git pull --rebase origin <default>）是主仓库操作，在 worktree 里会拒绝执行。/gtw fix、/gtw back、/gtw close 都已经自带 sync，整个流程里不需要手动调用。

3. 交接：/handoff · /resume

agent 的上下文太长，或者剩下的工作更适合换一个 agent 时：

1. /handoff <name> — agent 把任务状态（目标、已完成、未完成、下一步）写进 ~/.nightme/handoff/<name>.md。
2. 清空重来：/new 重置当前 agent 的上下文，或 /use <agent> 切换 agent。
3. /resume <name> — agent 读取交接文件，在同一个 worktree 里接着做。

4–6. 交付：/gtw commit → /gtw push → /gtw pr

1. /gtw commit [-a <agent>] — 一个 one-shot agent 暂存 worktree 里的改动，提交成一个或多个 Conventional Commits（<type>(<scope>): <subject>）。NightMe 会校验 commit 确实落地、worktree 已干净。遇到合并冲突或 detached HEAD 时拒绝；没有可提交的内容则什么都不做。不会 push。
2. /gtw push — 把分支推到 origin。只接受干净的 worktree：有未提交改动时拒绝，并提示先跑 /gtw commit。
3. /gtw pr [-a <agent>] — 一个 one-shot agent 根据分支改动写出 Conventional Commits 标题和结构化正文；关联 issue 的修复由 NightMe 追加 Closes #<id>，并以一行 Generated by NightMe 签名收尾，然后创建 PR / MR。分支必须已在 origin 上；该分支已有打开的 PR 时，回复里直接给出链接。

commit 和 pr 使用的 agent 按优先级取：-a <agent>，其次 ~/.nightme/gtw.yml 里的 commit.agent / pr.agent，最后是 chat 当前的 agent。

7. 收尾：/gtw close

/gtw close 结束任务：移除 issue 上的 nightme/wip 标签，删掉 worktree，强制删除本地分支，把 chat 的 CWD 切回仓库根目录，并 sync 默认分支。worktree 有未提交改动时拒绝——先 commit、stash 或丢弃。如果标签移除之后的某一步失败，标签会被加回去，重跑 /gtw close 时从同一个状态开始。

Hooks——把开发环境一起带过去

AI 工具的索引（CodeGraph、语言服务器、缓存）一般放在仓库里。每个 worktree 是新 checkout——都要重建。Hooks 把这件事自动化了。

最常见的是 fix: hooks: after——在 /gtw fix 开新 worktree 之后立刻跑，让新 worktree 的 dev env 就地装起来：

~/.nightme/gtw.yml
fix:
hooks:
after:
- codegraph init # 重新索引新 worktree
- npm install # 装依赖
- go mod download # 下载 Go modules

每个命令（不只是 fix）都有 hooks.before 和 hooks.after：

| Hook | 触发时机 | 典型用途 |
| before | 主流程之前 | 记录起始 SHA、拍状态快照 |
| after | 主流程之后（即使失败也跑） | 重新索引、装依赖、暖缓存 |

铁律（来自代码）：

- v1 只支持 shell hook——其他类型会告警并跳过。
- Hook 失败 绝不阻塞主流程。挂了就在回复里挂个 ⚠️ 提示，主命令继续。
- stdout / stderr 全部回显，能看到实际跑过什么。
- 单个 hook 默认 30s 超时。

输出语言——commit / PR / issue 正文

/gtw commit、/gtw pr、/gtw new 写出来的文本用什么语言，以前完全由模型自己决定——同一个仓库里中英文提交混排。设一次语言，之后生成的文本都跟着它走。

语言配置在 ~/.nightme/gtw.yml，分两个作用域：

| 作用域 | 配置键 | 生效范围 |
| 用户级 | lang: | 所有仓库 |
| 仓库级 | repos.<host>/<owner>/<repo>.lang: | 仅该仓库 |

仓库键由 origin remote URL 自动解析出来，你不用手写。仓库级优先于用户级；两级都没设时语言是 English。

~/.nightme/gtw.yml
lang: 简体中文 # 所有仓库

repos:
github.com/cnlangzi/nightme:
lang: zh-CN # 仅该仓库

/gtw config 的四种形式：

| 命令 | 作用 |
| /gtw config lang | 回显生效语言及其来源作用域 |
| /gtw config lang <value> | 设置当前仓库的语言 |
| /gtw config -g lang <value> | 设置所有仓库的语言 |
| /gtw config --unset lang | 删除该条目（加 -g 删用户级） |

语言值是自由文本——简体中文、zh-CN、Simplified Chinese 都可以。结构化标记不论什么语言都保持英文：## Summary by NightMe 标题、PR 分类标签、Risk: 行、Issue: #<id> 与 Closes #N trailer、 Conventional Commits 的 type 关键词。issue 标题保持英文 / ASCII——分支名是从它派生的。

Workflow 自动化

nightme workflow 规划和检查 YAML 定义的自动化。Workflow 放在 ~/.nightme/workflows/.yaml，按 name: 去重加载。

| 子命令 | 作用 |
| nightme workflow list | 汇总每个 workflow：名称、workspaces、触发器、jobs。--json 输出机器可读。 |
| nightme workflow show <name> | 打印一个 workflow 的解析细节：触发器、jobs、steps、生效的 agent。 |
| nightme workflow run <name> | 打印执行计划——哪个触发器会命中、哪些 step 跑、什么顺序。--workspace 覆盖 workspace。 |

run 是规划 dry-run：只解析和排计划，不真正调 agent。

YAML schema——on: 触发器、worker:、jobs.<name>.steps、${{ }} 表达式——见 docs/WFE.md。

For developers

Architecture (advanced)

┌─────────────┐ ┌─────────────┐ ┌──────────────────────────┐
│ Channel │ → │ Gateway │ → │ ChatSession (per chat) │
│ (Feishu, │ ← │ (router + │ ← │ ├─ AgentSession pool │
│ Web TUI) │ │ binding) │ │ │ (agent, cwd) 1:1 │
└─────────────┘ └─────────────┘ │ ├─ InputBuffer FSM │
│ ├─ readPump │
│ └─ EventHandler │
│ ↓ │
│ AgentSession → Bridge │
│ (PTY / ACP / SDK / │
│ JSON-IO / RPC) │
│ ↓ │
│ Agent CLI │
└──────────────────────────┘

- Channel 拥有 transport。
- Gateway 路由入站。inbound 子包负责斜杠命令派发链；其它都转发到 ChatSession 的 active AgentSession。
- ChatSession 是每个 chat 的 context。拥有 AgentSession 池和 InputBuffer FSM。daemon 重启之间持久化。
- AgentSession 是每个 CLI 进程的句柄。每个 (agent, cwd) 一份，/use 和 /cwd 切换之间保活。
- Bridge 是每个 agent 的 transport——acp、claudecode、codex、copilot、dsh、omp、opencode、pi 或 pty（在 internal/bridge/ 下），按 CLI 支持情况选。

完整责任表见 docs/SPEC.md §1，"Channel 是 dumb renderer" 的设计动机见 §0.1。

Configuration

NightMe 从 ~/.nightme/config.yaml（或 $NIGHTME_CONFIG 指定的文件）读 YAML。环境变量可覆盖：NIGHTME__<KEY>（如 NIGHTME_PRIMARY）。

primary: claude # 全局默认 agent

agents: # 列表：每项 = name / bridge / command
- name: claude
bridge: claude
command: "claude --dangerously-skip-permissions"
- name: codex
bridge: codex
command: codex
- name: opencode
bridge: opencode
command: opencode
- name: pi
bridge: pi
command: "pi"
- name: dsh
bridge: dsh
command: dsh
- name: copilot
bridge: copilot
command: copilot # bridge 默认注入 --allow-all-tools --acp --stdio
- name: omp
bridge: omp
command: omp # bridge 默认注入 --mode rpc --approval-mode yolo

feishu:
app_id: "cli_xxxxxxxxxxxxxxxx"
app_secret: "xxxxxx…xxxx" verification_token: "" encrypt_key: ""

session: # 初始 PTY + aggregator 参数 default_pty_cols: 80 default_pty_rows: 24 output_chunk_size: 4096 # bytes output_flush_interval_ms: 200 # milliseconds

logging:
level: "info" # debug | info | warn | error
file: "" # 空 = stdout；非空 = 文件路径

paths:
data_dir: "~/.nightme" # chat_sessions.json + agent_sessions.json 的根

/gtw 工作流读的是 另一个文件：~/.nightme/gtw.yml——见上文的 Hooks 那一节。

完整 schema 和每个 bridge 的说明见 configs/nightme.example.yaml。

日志写到 ~/.nightme/nightme.log（权限 0600），JSON 格式。属性名里含 secret、token、password 的会被自动改成 REDACTED*。

Documentation

| 文档 | 内容 |
| docs/PRD.md | 产品定义——做什么、为什么做、为谁做。不讲技术。 |
| docs/SPEC.md | 技术架构——组件、数据流、NFR。 |
| docs/FEATURES.md | 功能索引——每个 F-XX 一行。 |
| docs/CHANNEL.md | 多 channel 架构——所有有凭据的 channel 自动并行启动，per-channel session 隔离。 |
| docs/CHATSTORE.md | chat_sessions.json 真相源、ChatSession hydrate、AgentSessionPool。 |
| docs/WFE.md | Workflow YAML + 引擎运行时架构——触发器、步骤、bot↔wfe 边界。 |
| docs/feat/ | 每个 feature 的设计文档。 |
| docs/bridge/ | 每个 agent bridge 的设计：claude、codex、dsh、opencode、pi、copilot、omp。 |
| docs/channel/feishu.md | 飞书 adapter 参考（渲染规则、卡片语义、线程路由）。 |
| docs/flow/ | 横切流程文档（如 3-layer doc model）。 |
| docs/E2E_TESTING.md | 飞书端到端手动测试 + 排错。 |
| docs/WINDOWS.md | Windows bridge 陷阱（env、.cmd shim、argv、信号）+ 修复。 |
| docs/TESTS.md | CI runner 上的跨平台 agent 启动 smoke test。 |
| docs/Wiki.md | /wiki init 设计——仓库 wiki 作为持久文档资产。 |
| docs/primary-agent-detection.md | Primary agent 解析链、内置白名单、首次运行 prompt。 |
| CHANGELOG.md | 当前 snapshot（单 [Unreleased] 段）。 |
| MIGRATION.md | 历史 snapshot 之间的 breaking change 列表。 |

Development

make build # ./bin/nightme，带 version metadata
make test # go test -race ./... (~20 packages, race-tested)
make lint # go vet ./... (0 warnings required by CI)
make install # go install to $GOBIN
make dev # go run ./cmd/nightme (uses example config)

CI 跑在 GitHub Actions（.github/workflows/ci.yml），每次 push 和 PR 都会跑：go vet、go test -race、go build 必须全过。

Project layout

cmd/nightme/ # cobra CLI (start / stop / restart / status / logs / doctor / test / config / list / login / kill / clean / update / workflow / version)
configs/ # example YAML config
docs/
PRD.md SPEC.md FEATURES.md # 3-layer doc model
WFE.md # workflow YAML + 引擎运行时（schema / 触发器 / 步骤 / bot↔wfe 边界） feat/ # F-XX per-feature design bridge/ channel/ flow/ # per-subsystem design images/ # README-served screenshots internal/ agent/ # Agent / AgentEvent / Info / Starter interface agentsession/ # AgentSession + Prompt + Spawner (per-CLI-process runtime unit) bridge/ # Bridge abstraction, one sub-package per agent acp/ claudecode/ codex/ copilot/ cursor/ dsh/ omp/ opencode/ pi/ pty/ channel/ # Channel interface bot/ echo/ feishu/ slack/ telegram/ # adapters (feishu production; telegram ready; slack in development) chatsession/ # ChatSession + pool manager + persistence cli/ # shared CLI helpers (config / doctor / login) command/ # Slash-command Commander / Registry / Factory cwd/ close/ newcmd/ use/ think/ tools/ watch/ stop/ steer/ services/ handoff/ resume/ review/ wiki/ queue/ # task-continuity / review / wiki / queue gtw/ # /gtw plan / new / fix / commit / push / pr / close / back / sync (Git team workflow) config/ # YAML loader + env overrides daemoncontrol/ # IPC for nightme doctor / status errors/ # CodedError + ExitCode gateway/ # Slash router + binding + receipt FSM inbound/ outbound/ # inbound dispatch chain + outbound sender gatewaytest/ # integration test harness logging/ # slog + secret redaction login/ # IM bot 注册——feishu / slack / telegram onboarding messages/ # IM message types + dispatch prcache/ # PR metadata cache (per-F-50) registry/ # JSON-backed chat_sessions.json + agent_sessions.json (0600, atomic) shell/ # !cmd shell-mode dispatcher statusbar/ # Feishu footer-card stamp runtime (per F-58, F-133) testdata/ # shared test fixtures version/ # build-time version metadata

Exit codes

| Code | 含义 |
| 0 | Success |
| 1 | Generic / unmapped error |
| 2 | Config error |
| 3 | Auth error |
| 4 | Channel error |
| 5 | Session error |
| 6 | Agent error |
| 7 | Bridge error |
| 8 | Validation error |
| 9 | Not found |

Contributing

PRs 和 issues 都欢迎。大改动的话先开 issue 聊聊，再写代码。

详细指南在 /docs — 设计流程参考 3-layer doc model。

感谢使用 NightMe——我们欢迎更多 channels（Slack、Web TUI、其他）和更多 AI Coding Agents（Claude Code、Codex、DeepSeek Harness (DSH)、Pi、Cursor、OpenCode、GitHub Copilot CLI、任何新的）接入。Drop 一个 Channel / Bridge，架构处理剩下的事。

联系维护者：

- Twitter：@imlangzi
- 微信：langzi（加好友请注明 "NightMe"）

License

MIT——全文见 LICENSE。