雨天小六

读懂 Codex(7.1):Agent 身份怎样由 Role、Thread、Prompt、Tool 和 Status 组合

· 更新于 2026-08-02 · 专栏:读懂 Codex

#Codex#Agent Runtime#Multi-Agent#Extension#软件架构

Codex 没有一个包办全部语义的 Agent 对象:AgentPath/ThreadId 负责寻址,Role 负责派生配置,Session 持有运行状态,Prompt 与工具面按 Turn/Step 编译,AgentStatus 只是事件投影。

本节只研究“身份分层与组合,不展开 Spawn 事务”。输入是 AgentPath、ThreadId、SessionSource、Role 名称、当前 Turn/Step 配置,状态由 AgentControl、AgentRegistry、ThreadManager 与各子 Session 持有,成功输出为 可寻址、可运行、可观察状态的 Agent 实例。相邻章节中看起来相似的对象如果由不同组件拥有,就不能用一个布尔状态替代。

先确定边界和状态所有者

问题本节答案
谁发起AgentPath、ThreadId、SessionSource、Role 名称、当前 Turn/Step 配置
谁拥有可变状态AgentControl、AgentRegistry、ThreadManager 与各子 Session
成功产物可寻址、可运行、可观察状态的 Agent 实例
不在本节内身份分层与组合,不展开 Spawn 事务之外的上游产品策略和下游业务实现

这张表的用途不是复述名词,而是约束实现顺序:校验必须发生在副作用之前;已经提交的状态只能由原所有者撤销;只读投影不能反过来成为控制权威。

端到端调用链

  1. 解析 AgentPath
  2. 查 Registry 得 ThreadId
  3. ThreadManager 取得 Session
  4. Role/Prompt/Tool 按时点生效
  5. 事件投影 AgentStatus
Agent 身份怎样由 Role、Thread、Prompt、Tool 和 Status 组合的端到端机制流程,展示解析 AgentPath、查 Registry 得 ThreadId、ThreadManager 取得 Session、Role/Prompt/Tool 按时点生效、事件投影 AgentStatus
图 7.1-1:解析 AgentPath → 查 Registry 得 ThreadId → ThreadManager 取得 Session → Role/Prompt/Tool 按时点生效 → 事件投影 AgentStatus。图中每条箭头都表示下一层只接收上一层已经确认的状态。

这条链里至少有三种时间尺度:配置或身份在 Thread 创建时冻结,Turn 内状态由 Session 串行协调,Step 级目录与能力在每次模型采样前重新捕获。若把后一个时点的新状态拿去解释前一个时点已经发出的调用,就会产生跨代错误。

源码机制拆解

地址和运行身份必须分开

AgentPath 是 V2 工具面使用的树形地址,ThreadId 是实际 Thread 的稳定身份。Registry 同时维护 path→metadata 与 thread→path 两个索引,所以重载 Thread 时地址可以保持不变。

这项约束直接决定了边界两侧的数据形状。实现时应先证明前置状态,再写入由 AgentControl、AgentRegistry、ThreadManager 与各子 Session 持有的对象;不能用日志、UI 状态或模型描述代替真实状态更新。

Role 不是运行中的 Agent 对象

Role 只在创建或恢复时形成一层高优先级配置;它可以改变模型、Reasoning 或 Developer Instructions,却不持有活动 Turn、Mailbox 或历史。

这项约束直接决定了边界两侧的数据形状。实现时应先证明前置状态,再写入由 AgentControl、AgentRegistry、ThreadManager 与各子 Session 持有的对象;不能用日志、UI 状态或模型描述代替真实状态更新。

Prompt 与工具面是时间相关的能力视图

Prompt 由 Thread/Turn/Step 状态编译,工具面又由当前 Step 的配置、模型能力和扩展目录决定。两个 Agent 即使 Role 相同,也可能因为环境或 Step 不同而看到不同能力。

这项约束直接决定了边界两侧的数据形状。实现时应先证明前置状态,再写入由 AgentControl、AgentRegistry、ThreadManager 与各子 Session 持有的对象;不能用日志、UI 状态或模型描述代替真实状态更新。

Status 是观察结果,不是控制权威

AgentStatusTurnStartedTurnCompleteTurnAbortedErrorShutdownComplete 事件推导;关闭边、释放 Residency 或取消 Task 仍由各自状态所有者执行。

这项约束直接决定了边界两侧的数据形状。实现时应先证明前置状态,再写入由 AgentControl、AgentRegistry、ThreadManager 与各子 Session 持有的对象;不能用日志、UI 状态或模型描述代替真实状态更新。

Python 风格伪代码

下面的伪代码提炼状态机与错误顺序,不逐行翻译 Rust,也不假装 Python 对象具有 Rust 的所有权保证:

async def resolve_agent(control, reference, caller):
    path = caller.agent_path.resolve(reference)
    thread_id = control.registry.thread_id(path)
    if thread_id is None:
        raise UnknownAgent(path)

    thread = control.thread_manager.get(thread_id)
    if thread is None:
        thread = await control.ensure_v2_agent_loaded(path)

    return AgentView(
        path=path,
        thread_id=thread_id,
        role=control.registry.metadata(thread_id).role,
        status=thread.status_watch.current(),
        # prompt/tools belong to the current sampling step, not identity itself
    )

阅读这段伪代码时要检查三件事:第一,输入是否在副作用前完成规范化;第二,异步等待是否仍携带原 Thread/Turn/Step 身份;第三,失败后究竟释放了什么、又保留了什么。只写快乐路径会把本节最重要的一致性条件删掉。

失败、取消与恢复

Agent 身份怎样由 Role、Thread、Prompt、Tool 和 Status 组合的三类失败分支、可观察结果和恢复责任
图 7.1-2:失败不会抹掉已经提交的状态;每条分支都由拥有该状态的组件执行恢复或补偿。
故障点已发生的状态可观察结果恢复责任
路径存在但 Thread 未加载Registry 仍保留地址不能直接把它判为 NotFound走 V2 按需恢复
事件晚到旧 Turn 已发出终态事件只更新状态投影不得反向改写 Role 或地址
同 Role 的两个 Agent配置相似但 ThreadId 不同保持历史和 Mailbox 隔离按路径分别寻址

取消不自动等于回滚,列表不自动等于权威存储,模型看见的描述也不自动等于已经获准执行。对于已经建立的 Thread、写入的 Edge、入队的 Mailbox、安装的插件或外部工具副作用,必须由相应所有者执行显式关闭、补偿或保留。

并发与一致性不变量

  • 同一身份不能在并发路径中被重复预留或重复注册;若允许幂等重试,幂等键必须是稳定路径、ThreadId、request id 或 catalog revision,而不是展示名称。
  • 一次模型采样看见的 Prompt、工具目录和执行入口必须来自同一个 Step 快照;刷新只影响后续 Step。
  • Watch/Activity/事件是通知机制,不是状态本身。被唤醒后必须重新读取 Registry、Session、Mailbox、Store 或 Binding 的权威值。
  • 失败路径不得“为了干净”删除仍可恢复的历史;同样也不得把只剩历史的对象伪报成当前仍驻留运行。

设计思路与代价

本节设计保护的核心不变量是:Codex 没有一个包办全部语义的 Agent 对象:AgentPath/ThreadId 负责寻址,Role 负责派生配置,Session 持有运行状态,Prompt 与工具面按 Turn/Step 编译,AgentStatus 只是事件投影。代价是同一个功能会跨越地址、配置、Session、队列、存储或扩展适配层,测试也必须覆盖正常、并发和中途失败。更短的单体实现虽然容易演示,却无法区分“存在、已加载、正在运行、可恢复、已关闭、模型可见”这些彼此独立的事实。

设计动机部分是根据生产类型、调用顺序和测试行为归纳;源码可直接证明的是字段、分支、状态所有者和失败结果。文章不会把推断写成服务端或产品层的未公开事实。

源码与测试证据

位置能证明什么
codex-rs/protocol/src/agent_path.rsAgentPath 的语法、join 与相对/绝对 resolve
codex-rs/core/src/agent/control.rs共享控制平面和列表投影
codex-rs/core/src/agent/registry.rspath/thread 双向索引与元数据
codex-rs/core/src/agent/status.rs事件到 AgentStatus 的投影
测试/可执行检查覆盖重点预期
codex-rs/protocol/src/agent_path.rs正常、边界与状态转换应与本节不变量一致
codex-rs/core/src/agent/control_tests.rs失败、并发或兼容行为应与本节不变量一致

当前环境没有 Cargo,本轮不伪报 Rust 测试执行;验证由锁定提交下的源码—测试静态对读、源文件存在性检查、Mermaid 渲染、Astro 生产构建和公开页面检查组成。

Mini Codex 复刻建议

Mini Codex 应先复刻本节的协议不变量:明确状态所有者、稳定身份、可回滚预留、同 Step 快照、超时/取消和单一终态。平台沙箱、远程 Executor、OAuth、Backend App Route 或第三方 MCP Server 的安全性质不能由一个本地 Python mock 证明,适配器只能验证调用顺序和故障处理。

本节结论

Codex 没有一个包办全部语义的 Agent 对象:AgentPath/ThreadId 负责寻址,Role 负责派生配置,Session 持有运行状态,Prompt 与工具面按 Turn/Step 编译,AgentStatus 只是事件投影。 掌握这一点后,再看相邻模块时就能判断它是在改变身份、运行状态、模型可见上下文、外部能力,还是仅提供观察快照。

阅读导航

上一节:第七章总览 · 下一节:Built-in Role、Agent TOML 与模型覆盖

源码依据

本文基于锁定提交 fe01054a28fa4bd04716d9ceadb410f2443a50ce 的生产代码和相邻测试静态核对。关键入口如下:

评论


← 返回文章列表