Web UI 里完成一次代码修改很直观，但团队真正想要的是：PR 创建后自动让 Agent 做检查，把工具调用、最终结论和退出状态交给流水线，而不是让人盯着浏览器。
DeepSeek Harness 的 Headless Profile 就是这个入口。官方定义很清楚：一次调用只执行一个任务，不开 GUI、不启服务、不留后台进程；成功退出码为 0，中止或错误为 1。
最小调用
dsh --profile headless "运行测试，只报告失败原因，不修改文件"
参数任务适合短提示词。长任务建议从标准输入传入：
{
echo "审查当前改动："
git diff --stat
} | dsh --profile headless
官方说明位置参数存在时不会读取 stdin；空参数和空管道会在执行前失败。脚本里不要同时传两份任务，再猜哪一份生效。
为什么自动化要用 JSON
默认模式把最终回答写到 stdout，把推理提示和诊断写到 stderr。机器消费时应启用 --json，获得一行一个对象的 NDJSON 流：
dsh --profile headless --json "运行测试并总结" > dsh-events.ndjson
事件从 session 开始，以 final 结束，中间可能有 status、text、thinking、tool_call 和 tool_result。注意它是面向运行展示的投影，不是完整 Session 日志；除最终事件外，字符串还可能被限制长度。审计系统不能把它当作无损事件源。
流水线至少检查三层结果：进程退出码、是否收到 final、任务自己的验收证据。例如 Agent 说“测试通过”时，CI 仍应独立再跑一次测试。
一个可靠的 CI 分层
第一层只读：让 Agent 分析 Diff、测试失败和风险，不允许写工作区。第二层受控修改：只在临时分支或一次性工作目录中运行。第三层独立验证：由 CI 自己执行 lint、test、build 和安全扫描。
不要把“Agent 退出码为 0”解释为“业务验收通过”。Headless 的成功表示这次任务完成，不替代你的测试断言。
会话续跑什么时候有用
每次调用默认创建新的 session-<uuid>。启用 JSON 后，首个事件会给出会话 ID；后续可以通过：
dsh --profile headless --session-id "session-..." "根据上次结果继续"
官方实现会拒绝不存在的会话，也会核对持久化、工作目录、Preset 和会话类型，避免在不匹配的组合中静默开空会话。续跑适合“分析—确认—修复”两阶段工作，不适合无限复用一个历史越来越长的万能会话。
提示词要写成验收协议
自动化任务建议包含四部分：允许范围、禁止范围、验证命令、输出格式。例如：
只检查 src/ 与 test/。
不要修改文件，不要安装依赖，不要访问网络。
执行现有测试；若环境缺依赖，报告 blocker，不要自行绕过。
最终输出：结论、证据、风险、建议下一步。
这比“帮我看看代码”更容易稳定回归，也更容易判断模型、工具或版本变化是否造成退化。
CI 中最容易踩的坑
- 把长期 API Key 写进仓库变量或日志；
- 允许 Agent 直接推送默认分支；
- 使用可写缓存，让不同 PR 互相污染；
- 只保存最终自然语言，不保存测试与 Diff；
- 自动重试所有失败，导致重复修改或费用失控；
- 把 NDJSON 投影误当完整审计日志。
最终建议
先用只读任务接入 CI，确认退出码、JSON 解析和独立测试三条链路。再开放临时工作区写权限，并为每次运行设置时间、Token、并发和重试上限。
Headless 的价值不是“没有界面”，而是把 Agent 变成一个有输入、有事件、有退出状态、可被其他系统约束的执行单元。
继续阅读：Cordis 插件、事件与自定义工具开发。需要回看完整顺序时，返回DeepSeek Harness 专题路线。