今天主要是在通过阅读源码学习 Agent ，并且赶上了 deepseek harness 公测以及 deepseek v4 pro 正式版的发布。

Pi 和 Codex 如何处理执行中的新消息

Agent 执行任务时，用户仍然可以继续发送消息。这些消息大致有两种处理方式：steering 和 follow-up。

• steering 是给正在执行的任务补充指令。例如你发现 Agent 理解偏了，可以告诉它「先别改代码，先查清楚原因」；
• follow-up 是先把消息排到后面，等当前任务结束后再处理。

这两个名字描述的是消息应该在什么时候被处理。steering 不一定会强制终止正在运行的模型或工具，具体行为取决于 Agent Loop 如何实现。

Pi

Pi 的处理方式比较直接，主要依靠两层循环。

内层循环负责执行当前任务，并在执行过程中接收 steering；等内层循环结束后，外层循环再检查有没有 follow-up，有的话就继续处理下一条。

Codex

理解 Codex 的处理方式，需要先知道什么是 turn。

turn 可以理解为 Codex 完成一次任务的完整执行周期：从用户发出请求开始，到 Codex 给出最终回复，或者任务被中止为止。

一个 turn 里不一定只请求一次模型。模型可能先决定读取文件或运行命令，拿到工具返回的结果后再继续思考；也可能因为用户补充了新指令而多执行一轮。这些步骤仍然属于同一个 turn，共用同一个 turn ID。因此，turn 更接近「一次任务」，而不是「一条消息」或「一次 API 调用」。

当客户端发现有正在运行的 turn 时，steering 会通过 turn/steer 发送。Core 收到以后不会创建新 turn，而是先把消息放进当前 turn 的 pending input。等当前模型请求或工具调用到达安全边界，Agent Loop 再读取这条消息，将它加入上下文，然后继续执行当前任务。整个过程保持原来的 turn ID。

follow-up 走的是另一条路径。以 TUI 为例，任务运行时按 Enter 会立即尝试 steering；按 Tab 则不会把消息发给当前 turn，而是先放进客户端的 queued messages。

当前 turn 完成后，客户端会从队列里取出下一条消息，通过 turn/start 创建一个新的 turn，并分配新的 turn ID。如果队列里还有其他 follow-up，就继续等这一轮结束后再依次执行。

所以 Codex 中的两种「队列」并不在同一个位置：steering 进入 Core 中当前 turn 的 pending input；follow-up 留在客户端队列里，等待下一个 turn 开始。

Codex 还要处理 sub-agent 消息、等待唤醒、Review 和 Compact 等状态，所以它没有只靠两层循环表达整个流程，而是把 active turn、pending input、mailbox 和任务状态拆开管理。源码读起来更绕，但也更适合支撑复杂的 Agent 行为。

DeepSeek Harness

今天发布了deepseek harness 公测版和 DeepSeek V4 Pro 正式版。

dsh 我的体验如下：

简单体验了一下 DeepSeek Harness，给我最大的感受是：Everything is a plugin——Agent Loop 甚至也是插件。

另一个很有意思的设计是 Agent 预设。你可以进入「创造模式」，通过对话描述自己想要的 Agent，让它帮你组合插件、工具、Skills、提示词和模型 Provider。
最终得到的是一个可复制、可编辑的 Agent Preset 目录，核心是 agent.cordis.yml。

以后不只可以分享 skill，还可以分享 agent.cordis.yml。

Deepseek v4 pro 正式版发布，并且提高了价格，分空闲时间段和高峰时间段，8 月 17 日开始实行。