用 nohup 让 OpenCode 任务在后台持续运行（即使关掉终端）
- 1. 什么是 nohup？为什么需要它？
- 2. nohup vs &——它们不是一回事
- 3. 基本用法与输出
- 4. 监控后台进程
- 5. 用 nohup 运行 OpenCode 本身
- 6. 指示 OpenCode 内部使用 nohup
- 7. 什么时候改用其他工具？
- 8. 总结
OpenCode 是一个终端型的 AI 编程 Agent。它能做的事情很多——运行完整的测试套件、批量重构代码、从零构建项目——但这些任务往往耗时很长。如果在任务进行中关掉终端，一切都会停止。
本文详细解释 nohup 如何解决这个问题，以及如何指示 OpenCode 自主使用 nohup 执行重负载的 Shell 任务。
1. 什么是 nohup？为什么需要它？
当你打开终端并执行命令时，该命令是你 Shell 会话的子进程。当你关闭终端（或 SSH 连接断开）时，操作系统会向该会话下的所有进程发送一个叫 SIGHUP 的信号。大多数程序收到 SIGHUP 后就会终止。这对交互式程序没问题，但对长时间运行的任务来说就是个麻烦。
nohup（no hang up 的缩写）是一个 POSIX 标准工具，它在 SIGHUP 到达进程之前拦截它。进程永远不会收到这个信号，所以它不知道终端已经关闭。它继续运行。
一句话理解：nohup 将进程从它的控制终端断开。进程成为会话的”孤儿”——仍然活着，仍然在工作，只是不再绑定到你的终端窗口。
nohup 早在 1970 年代就是 Unix 的一部分，今天每个 Linux 系统都默认安装了它。不需要额外安装。
2. nohup vs &——它们不是一回事
很多开发者把这两个搞混。它们解决的是不同的问题，配合使用效果更好。
| 写法 | 作用 | 是否阻挡 SIGHUP |
|---|---|---|
command & | 后台运行，立即返回提示符 | ❌ 不阻挡 |
nohup command | 阻挡 SIGHUP，终端关闭后存活 | 会阻挡，但占用终端 |
nohup command & | 后台运行 且 终端关闭后存活 | ✅ 阻挡 |
核心区别：
&— 让命令在后台运行，立即取回 Shell 提示符。但进程仍然会在会话结束时收到 SIGHUP。nohup— 阻挡 SIGHUP，进程在终端关闭后仍然存活。但如果不加&，它仍然占用终端。nohup ... &— 两者结合：后台运行且终端关闭后存活。这是你几乎每次应该使用的标准写法。
3. 基本用法与输出
nohup your-command &
执行后，Shell 会打印两样东西并返回提示符：
[1] 14823
nohup: ignoring input and appending output to 'nohup.out'
[1]是 Shell 任务编号14823是进程 ID（PID）——保存这个 PID，后续检查进程状态或终止进程时会用到
输出重定向
默认情况下，nohup 将所有输出写入当前目录下名为 nohup.out 的文件。建议将其重定向到自定义文件，这样你永远知道去哪里看：
nohup your-command > agent.log 2>&1 &
> agent.log— 将标准输出发送到agent.log2>&1— 将标准错误重定向到同一文件。所有内容都在一个地方
注意： nohup 会自动将标准输入重定向到
/dev/null。进程无法接收键盘输入——它完全脱离了终端。任何需要用户输入的程序都会挂起或失败。
4. 监控后台进程
进程通过 nohup 启动后，有几种简单的方法查看它的状态。
实时查看日志
tail -f agent.log
这会实时流式输出新写入的内容。按 Ctrl+C 停止追踪——这不会杀死进程，只会终止 tail 命令本身。
检查进程是否仍在运行
# 通过 PID 检查
ps -p 14823
# 通过进程名查找
pgrep -a opencode
在 ps 的输出中，如果 TTY 列显示 ?，说明该进程没有控制终端——这正是 nohup 任务的典型特征。
随时终止进程
# 正常停止
kill 14823
# 强制杀死（如果进程不响应）
kill -9 14823
5. 用 nohup 运行 OpenCode 本身
OpenCode 的非交互模式（-p 参数）是实现此功能的关键。通过命令行传入提示词，OpenCode 处理任务、输出结果到 stdout，然后退出。没有 TUI，不需要键盘输入——天然适合与 nohup 配合使用。
nohup opencode -p "修复所有失败的测试。每次修复后运行测试，直到全部通过。" > opencode.log 2>&1 &
echo "已启动。PID: $!"
$!保存了最后一个后台进程的 PID。立即输出它，这样你不会丢失追踪。
现在你可以关闭终端、断开 SSH 连接，或者去干别的事。OpenCode 会持续工作，直到任务完成——这就是日志文件重要的原因。
重要：
-p模式下所有权限自动批准。OpenCode 非交互运行时会自动批准所有工具调用——文件读写、Shell 命令等。确保在无人值守运行前，你信任传入的提示词。
6. 指示 OpenCode 内部使用 nohup
这是最常见、也最有用的实际场景。你正在 OpenCode 的 TUI 中交互式操作，然后想让 Agent 启动一个重负载的 Shell 任务，但不希望它阻塞自身——或者任务可能会因为超时而失败。
OpenCode 通过其 bash 工具完全访问你的 Shell。你只需要告诉它：
“在后台用 nohup 运行完整测试套件。将输出写入 test-run.log。每 30 秒检查一次日志，报告进度，直到所有测试完成或出现错误。”
OpenCode 会执行类似这样的命令：
nohup npm test > test-run.log 2>&1 &
echo $! > test.pid
然后在一个循环中轮询日志：
while kill -0 $(cat test.pid) 2>/dev/null; do
echo "--- $(date) ---"
tail -20 test-run.log
sleep 30
done
echo "进程完成。"
tail test-run.log
这让 Agent 保持活跃且知情。它不是在空等——它在实时观察输出，向你报告进度，并在出现问题时随时准备采取行动。
关键提示词设计要点： 告诉 OpenCode 使用 nohup、告诉它日志写在哪里、告诉它持续轮询直到完成。少了最后一条，Agent 可能执行完命令就认为任务结束了。
7. 什么时候改用其他工具？
nohup 适合一次性的长期运行任务。但并非所有场景都适用：
| 场景 | 推荐方案 |
|---|---|
| 需要稍后重新连接到交互式会话 | tmux 或 screen — 如果你运行的是 OpenCode 的 TUI 本身，想走开后再回来不丢失会话，tmux 是最佳选择。nohup 帮不了你，因为 TUI 需要终端来渲染界面 |
| 需要 OS 级别的进程管理 | systemd-run — 重启策略、资源限制、通过 journald 日志记录 |
| 重复性工作流 | CI/CD 流水线 — GitHub Actions、Jenkins 等，而不是在本地用 nohup |
| 需要持续运行并自动重启的进程 | 系统服务或进程管理器（如 PM2）— nohup 用于一次性任务，不适合需要持续运行的守护进程 |
8. 总结
我们回顾一下核心要点：
| 要点 | 说明 |
|---|---|
& vs nohup & | & 实现后台（非阻塞）执行；nohup 确保进程在终端/SSH 断开后存活。两者结合使用效果最佳 |
| 两层用法 | 可以直接用 nohup 运行 Agent 本身；但更强大的模式是指示 Agent（如 OpenCode）在内部对长任务使用 nohup 或 & |
| Agent 自动化模式 | 后台启动任务 → 记录日志 → 存储 PID → 定期检查状态 → 继续工作流。将 AI Agent 转变为自主、弹性的执行系统 |
Nohup 只是其中一种技术。当与 AI 编程 Agent 配合使用时，合理的指令设计可以避免无谓的错误反馈循环，让 Agent 真正自主完成长时间的任务。
版权所有，本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处：https://www.wangjun.dev//2026/05/nohup-opencode-tasks/