上一课的收尾是在本地 Web UI 会话里验证流式回复：那个自定义 LLM 适配器挂在 ctx.llm 的接缝上，连到云托管模型端点，把流式响应转成 StreamChunk，认证错误与瞬时故障的重试路径各归各位。交互式运行这条路已经跑通——工具、适配器与会话都在浏览器这个驾驶舱里完成过验证。现在换一个场景：凌晨的 CI 流水线里没有人在屏幕前点按钮，任务却要照常执行，失败要能被追溯。你需要的不是又一个界面，而是一台能自动跑完任务并退出的运行器，外加一份事后能查证的运行记录。前者是 headless 运行器，后者是会话轨迹。焦点只有两个：会话如何保存执行轨迹，headless 如何支撑一次性自动化运行。两件事分开看，最后在流水线里合起来用。

轨迹是流水线的黑匣子，也是一份可操作的数据。检索：按来源或事件过滤记录，定位某一次工具调用。重放：用同一条事件流再跑一遍，验证改动后的行为是否如预期。分叉：从历史某一点复制一份轨迹，另起分支继续实验。检索、重放与分叉共用同一条事件流。你之前用 defineTool 开发的工具，每次被 agent 循环调用，调用与结果都会成为该会话日志中的事件。排查'模型改错了文件'这类事故时，你能精确看到是哪个上下文、哪次调用导致了失败。注意两个边界：一是轨迹能还原过程、提升可复现性，但不能保证结果正确；二是会话默认活在内存里，持久化、查询与遥测由独立子系统承担，需要时另行启用。这意味着轨迹可以当回归素材：重放它，看改动后的行为是否仍然成立。报告问题或复盘事故时，附上轨迹比贴一段对话更接近现场——它记录了当时的全部上下文。

headless 不是单独的程序，而是由 profile 组装出来的运行形态，这套机制你在配置档案一节已经见过，这里只补它和运行形态的关系。profile 列出它堆叠的 bundle、安装的插件，并持有你的 cordis.patch.yml；web 与 headless 就是随 dsh 提供的两个 profile 模板。dsh-base 是每个 profile 的第一层：模型适配器、工具、持久化、沙箱与审批策略都在其中。web 模板在其上追加浏览器应用，headless 模板在其上追加一次性运行器——两者共享基座，差别只在堆叠的 bundle。配置按固定顺序叠加：先按 profile 列出的顺序应用每个 bundle，再应用 profile 的 cordis.patch.yml，然后是用户主目录级补丁，最后是 --patch 覆盖层。你前面写的补丁逐层盖上去，就能定制 headless 的模型、工具与策略。补丁按行 id 定位并整体替换该行配置，或插入新行——这正是你覆盖 headless 默认行为的入口。

把这两件事放进一条流水线看：准备阶段用 profile 与补丁固定任务形态；执行阶段由 headless 一次性运行器接手，无人值守地跑完；收尾阶段靠会话轨迹留痕、检索与分叉，让失败可归因。CI 的每次触发都复现同一套准备与执行，差异只来自输入；这正是脚本化编排想要的可重复性。准备、执行、留痕三个阶段互不耦合：你可以单独更换模型或任务，不必改动整条流水线。没有图形会话，是它适合进调度器与流水线脚本的根本原因。