/dl 的三种用法：双引擎评审、子需求委派、上线观察
OpenCockpit 里 /dl 的三种日常用法：用 --wait 让另一个引擎同时做代码评审，把子需求派出去再用 /qa 澄清，以及上线后派一个会话盯着，不占用当前对话。
/dl 把任务交给一个全新的会话（任意项目、任意引擎），并返回一张带链接的回执。机制就这么多，真正好用的地方在于怎么搭配。下面是每天都会用到的三种用法。
1. 每次评审都多一个视角
/dl --wait codex cr
/cr
一条消息，两行。第一行把代码评审交给 Codex，在新会话里做；第二行在你自己的会话里跑 /cr，用的是当前会话的引擎。
两边互相看不到对方的结论。不同的模型会漏掉不同的东西：两边都指出的问题基本可以确定是真的，只有一边指出的，正是你该亲自看一眼的地方。
关键在 --wait。不加它，/dl 在子会话启动时就返回了；加上它，这一轮会等 Codex 做完，拿着结果继续往下走。所以这一轮结束时，两份评审都已经摆在你面前，而不是一份评审加一个待会儿再去看的链接。
2. 把子需求派出去
做功能做到一半，发现有一块值得单独开个会话：可能在另一个仓库，也可能只是不想和当前对话搅在一起：
/dl 给 api 项目加一个导出 CSV 的接口
/qa
回执马上就回来了，你接着干手头的事：
Delegated **CSV 导出接口** to claude in `/Users/me/work/api` — [open session](/project?cwd=…&sessionId=…)
第二行的 /qa 会跟着任务一起交出去，所以子会话的第一件事是澄清需求，而不是动手写。它拿到的任务说明是根据你一句话写出来的，里面全是猜测；/qa 会把这些猜测摊开：一份简短的 PRD，列出范围、假设，以及少数需要你拍板的决策，每条都附带推荐。
等有空了，点链接进入子会话，回复几个字母（1A 2B），然后再让它开工。
3. 上线后派一个会话盯着
服务已经发出去了，主对话也转到别的事上，但总得有人盯着：
/dl 观察一下 api 服务上线后的日志和监控，有异常就总结出来
这次不加 --wait。观察没有明确的结束点，等着它只会白白占住当前对话。子会话自己跑，用的是和你一样的命令行：你在终端里能看到的日志和监控，它都能看到。结束后它会在最近会话里显示为未读；也可以随时问一句：
上线观察那边怎么样了？
agent 会找到回执、查询子会话，告诉你它是 running、done、failed 还是 incomplete，并总结它发现了什么。
等还是不等
三个场景用同一条规则：只有这一轮接下来的事要用到结果时，才加 --wait。评审要用，因为两份意见要放在一起看；子需求和上线观察不需要，就让它们在后台跑，你什么时候方便什么时候去看。
同一个仓库里的并行分工，Claude 自带的 subagent 仍然更轻量。/dl 负责剩下的：另一个引擎、另一个目录，或者一个你想打开、亲自接手的会话。