在编写 Agent runtime 时最常见的陷阱是把四种职责混在一起：一次 tool call 里既要读会话状态、检查权限。又要执行 shell，最终直接把结果推给 UI。在 demo 阶段这看似省事但出现以下痛点：

• 调用的状态到底归谁管理？其实，
• 副作用是否已经可靠产生？不过，
• 失败后该相信哪一份记录？
• 恢复边界如何定义才能避免“数据丢失”或“重复执行”？

从Owner来看，跨 await 持有权威状态

owner 负责保存跨 await跨调用仍然有效的状态。它掌握当前 session、turn、调用身份还有继续执行所需的上下文，并决定哪些状态可以被更新、持久化或恢复。

使用者痛点：UI 上显示“工具已完成”，但 owner 可能还没有把完成事实写入自己的持久化记录。于是重新打开会话时前端看到的事件找不到对应的恢复点。

在排查 Agent 状态时第一步先不是问“有没有 event”，而是问“这个 event 对应的权威 owner 是谁”。如果只能指向一段渲染代码，那么恢复边界往往未定义。

Executor：只负责碰世界

executor 是实际调用文件程序、shell、PTY、pipe 或远端 backend 的层级。它收到已经调度好的 invocation，并产生真实副作用或明确错误。

使用者痛点：将 “使用者是否批准”“UI 要显示什么”“下一轮上下文放什么” 混进 executor，会导致一次失败难以解释。例如进程已经启动，但模型只收到一个 Err；目录已改变，却没有对应的 TurnDiff重试时不知道上一步走到了哪。

源码中有关键边界：当 tool future 返回 Err 时drain 分支调用的是 error_or_panic不会自动补出一条 durable output。说白了失败调用可能没有可回放的工具产物；模型输出、机器状态、后续 prompt 必须分别核对，不能压成一个 “调用结果”。说起来，

Governor：决定这次能不能做

governor 负责审批、权限检查和 sandbox 限制。它回答的是 “这次请求允许执行到哪里”，而不是 “执行完以后发生了什么”。

使用者痛点：If 权限逻辑埋在 executor 内部，审查日志里只剩 “handler 返回成功/失败”。这样无法分辨拒绝是因为缺少使用者批准、沙箱限制还是执行本身出错。更糟的是同一个工具在不同 session 或模式下可能拥有不同权限，但调用者只能看到统一的工具名。

将 governor 拆出来后每次 invocation 至少留下三条可核对事实：

• 请求了什么权限；
• 采用了哪个 sandbox；按理说，
• 最终是批准、拒绝还是绕过。

Observer：投影而非机器本身

alert observer 负责生成 item、diff、event 和 transcript。这些数据对 UI、日志和下一轮提示很关键，但它们仅是观察结果的投影。

使用者痛点：TurnDiff 并不是完整审计日志。普通 shell、外部进程或目录/权限变化可能没有对应的 AppliedPatchDelta;patch move 与失败前缀也没有事务回滚。observer 看不到这些变化。只能说明投影缺失，无法用来证明机器没有改变。

This is *** “UI 显示完成” cannot replace an execution receipt. A reliable receipt must at least reference executor。governor’s decision,and durable owner;其实，observer only projects se facts without creating m.

四种责任合在一起时的模糊故障描述

You can use a single apply_patch failure to test boundaries:

owner 保存 session/turn 与调用身份
governor 决定 permission、sandbox 与审批结果
executor 对文件执行 patch。返回成功或错误
observer 生成 item、diff、transcript，供界面和日志读取

If patch has already modified some files,executor must provide a verifiable side‑effect receipt;if governor rejects request,observer should display “rejected” instead of a generic failure;if process crashes before returning,owner must know wher this invocation produced a durable result. Each layer answers one concrete question,giving retry strategies a solid basis.

实用检查表

• Status ownership：
• SIDE‑EFFECT receipt：
• P​ermission audit：
• P​rojection clarity：
• Error recovery：

The value of se questions lies in breaking “tool call succeeded” into verifiable responsibilities. Model sees ToolSpec,runtime runs handler。UI displays event—each belongs to a distinct boundary. Mixing m into one object shortens code but makes recovery rely on guesswork.

进一步阅读 & 源码依据

The complete responsibility handoff is detailed in codex‑internals documentation . Relevant source locations include:

• #codex-rs/core/src/session/turn.rs#L419-L459,L1112-L1206,L1892-L1916
• #codex-rs/core/src/tools/router.rs#L28-L78,L221-L243
• The corresponding chapters: -recovery‑boundaries,-tool‑spec‑registry,-apply‑patch‑turn‑diff & -approval‑permissions‑sandbox.

`