读者对象：了解大模型的调用和工具执行、ReAct等知识，但想近一步学习了解多智能体等更复杂实现机制的技术人员。
备注说明： 所分析的是Codex CLI 命令行执行方式下智能体代码的执行机制，Codex App应用的代码是没有开源的，但底层执行逻辑是一致的。代码位置 ：github.com/openai/code… · Rust 工作区 codex-rs · commit 8c07694（2026-10-18 克隆） Codex 代码中智能体执行机制同时提供了两个版本，通过如下的参数进行控制，后续称为 V1、V2。 通过研究同一场景的实现机制的对比和版本的演进，能对自己的产品研发具有借鉴意义。
针对Codex中多智能体的使用/触发，可以看我写的前一篇文章 ： 《从使用者角度看看Codex如何使用多智能体》
1. 基线：普通 ReAct 是怎么执行的
1.1 它要解决什么问题
给模型一个需要多步才能完成的任务——例如"把配置文件里的超时改成 30 秒"——模型不可能一步到位：它要先想清楚改哪个文件、再真的去改、看到结果后确认改成功了，才能回复用户。
ReAct 就是把这类过程标准化成一个闭环：想一步、做一步、看一步结果，再想下一步，直到模型认为可以给出最终答案。它是今天绝大多数智能体（Codex 也在其列）的底座。不理解这个闭环，就看不懂 V1/V2 到底"多"出了什么。
1.2 机制：一个闭环，四个动作
- 模型读上下文。 上下文是一个消息列表（messages），里面放着任务描述，以及此前每一轮的执行结果。
- 模型做一次推理。 输出两种可能之一：一个结构化的工具调用请求（用哪个工具、参数是什么），或者一条最终答案。
- 运行时（Runtime）执行工具。 若是工具调用，由外层运行时真正执行（读写文件、执行命令、查询数据），把返回结果作为一条新消息追加进上下文。
- 回到第 1 步。 模型基于更新后的上下文继续推理；若第 2 步输出的是最终答案，循环结束。
由此得到三个关键性质：
- 单线程：动作顺序执行，不存在并行的执行体；
- 单上下文：全程共享同一份记忆，无隔离、无分叉；
- 同步内联：工具结果直接回填同一上下文，调用方原地等待。
另有一个工程细节不容忽略：循环必须设最大步数保护。否则模型可能反复调用同一个工具，永远停不下来。
1.3 代码样例
下面是一份最小实现（教学示意，省略了错误处理与重试；call_model 为伪函数，真实项目里它是一次大模型 API 调用，返回结构化结果）：
from typing import Any
# ---------- 工具层：由外层运行时真正执行 ----------
def edit_file(path: str, old: str, new: str) -> str:
"""把文件中一处 old 替换为 new。"""
return f"已替换 1 处：{path}"
TOOLS = {"edit_file": edit_file}
# ---------- ReAct 主循环 ----------
def react_loop(task: str, max_steps: int = 10) -> str:
# 上下文：一个消息列表，所有回合共享同一份
messages: list[dict[str, Any]] = [{"role": "user", "content": task}]
for _ in range(max_steps):
# 模型只负责“决定”：读上下文，输出思考 + 工具调用请求或最终答案
reply = call_model(messages, tools=TOOLS)
if reply.tool_calls:
# 把“思考 + 工具调用请求”写进上下文
messages.append(reply.to_message())
for call in reply.tool_calls:
# 真正执行工具的是运行时，不是模型
result = TOOLS[call.name](**call.args)
# 观察结果作为新消息追加，驱动下一轮推理
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
continue # 回到循环顶部
# 没有工具调用：模型给出最终答案，循环结束
return reply.content
return "已达到最大步数，任务未完成"
请注意其中两行的分工：call_model 只产出"用哪个工具、参数是什么"的请求；TOOLScall.name 才真正执行工具。模型负责决定，运行时负责执行——这条分界线在 V1/V2 里依然成立，只是组织的形态变了。
1.4 一张图看懂普通的ReAct机制
普通 ReAct 的执行闭环：模型读上下文后二选一——输出工具调用请求（由运行时执行，观察结果写回上下文，进入下一轮），或直接给出最终答案（循环结束）。左侧是随回合增长的消息列表，底部是单线程、单上下文、同步内联三个关键性质。
1.5 再进一步：普通 subagent 长什么样
许多框架在 ReAct 之上加了"子智能体"：父在某一轮决定"这块活交给一个专职的子去干"，于是同步调用一个子——父原地等待，子自己跑完一整个 ReAct 循环，把最终答案作为这次调用的返回值交还父；父把答案内联回填进自己的上下文，继续下一轮。子用完即弃：没有名字、没有历史、不留记录。
# 普通 subagent：同步内联，跑完即弃
def run_subagent(task: str) -> str:
sub_messages = [{"role": "user", "content": task}] # 子只拿到任务描述
return react_loop_with(sub_messages) # 子自己跑完整个循环
# 父智能体中：调用即阻塞，拿到最终答案才继续
answer = run_subagent("把 config.py 的超时改成 30 秒")
messages.append({"role": "tool", "content": answer}) # 结果内联回填父上下文
请记住这个"同步内联"的形态。Codex V1 的 spawn_agent 看起来在做同样的事，底层却是另一套路——下一章开始对比。
2. 三种执行模式对比
2.1 三者定位
- 普通 ReAct：一个智能体、一条循环、单线程单上下文，全程同步。
- Codex V1：父派生独立线程的子智能体，父子各自跑循环，子完成后异步通知父。
- Codex V2：核心与 V1 相同，额外支持子智能体的驻留、换出与重载，并挂了一个树级共享信箱。
V1 与 V2 的主要差异在驻留层、完成信号和通信设施，不在进程边界。
2.2 共同底座
三者的内核都是 ReAct：都是"模型决定下一步、运行时执行、结果喂回模型"这个循环；真正的执行者都是外层运行时，模型只输出结构化的工具调用请求。区别只在于这个循环有几个、怎么组织。
2.3 对比总览
三种执行模式对比。该图表达普通 ReAct 的"单循环、同步内联"，V1 的"异步派生 + 独立线程 + 单向状态通知"，V2 的"异步派生 + 驻留换出 + 信箱寻址"三者在执行结构上的差异。
为便于窄屏阅读，拆成两段：表 A 看 V1 相对普通 ReAct 改了什么，表 B 看 V2 相对 V1 又补了什么。
表 A：普通 ReAct ↔ Codex V1（跨越点：并行 + 异步）
表 B：Codex V1 ↔ Codex V2（跨越点：驻留 + 信箱）
一个最易混淆的点：普通 ReAct 也常支持"一个回合里并行调多个工具"，就是一次大模型调用可以返回多个要执行的工具信息，应用程序运行时可以并行执行这些工具，但这和 Codex 的并行不是一回事——前者是同一条循环、同一个上下文里的并行步骤，结果仍全部回填同一处；后者是多个独立执行体、多个独立上下文的并行，各自有各自的循环和记忆，靠异步消息或通知汇合。区分点就一句：并行的是"步骤"还是"执行体"。
2.4 两次跃迁的直白解释
把三种模式排成一条线，从普通 ReAct 到 V2 是两次递进。
第一次跃迁（普通 ReAct → V1）：从"一个循环"到"多个并行循环"，从"同步"到"异步"。 普通 ReAct 是"一个人从头干到尾"，所有事在一条上下文、一条线程里顺序完成。V1 允许父在干活的同时派出好几个子Agent并行干别的，父子各有各的上下文和线程。代价是控制流变了：父派完不傻等，而是先返回一个 id 继续干自己的活，子Agent干完了再回头异步通知父。V1 换来并行能力，付出的代价是结果不再内联回填、要异步收。
第二次跃迁（V1 → V2）：从"静态常驻、单向协作"到"可换出重载、可寻址、可唤醒"。 V1 的子Agent跑完后线程并不销毁，但也没有"请出内存"一说——不显式关闭就一直占着线程，并发一多容易达到系统的线程控制上限。父若想再让它干活，得自己主动调 send_input 给它开一个新回合（被关闭过的先 resume_agent 拉起来）；拿结果则靠 wait 或读子线程。总之协作全靠父单向发起：完成通知只带"状态"不带内容，兄弟之间无法直接说话。V2 补了三块：换出与重载（空闲的子Agent释放，需要时唤醒续跑，资源不再静态占用）、信箱（任意智能体可按标识互相发消息，支持"先排队、对方上线再投递"和"发信即唤醒对方开工"两种模式）、更干净的上下文继承（默认子只拿指令快照，不再把父整段历史复制过去）。
3. V1 相对"普通 subagent"的差异
第 1.5 节的同步 subagent 是最容易和 V1 混淆的对象。相同点是：都由父模型在一次决策里触发、子都跑自己的推理循环、都能再往下派生子。但底层是两回事。
用代码对照更直观：
# 普通 subagent：父阻塞，结果内联回填
answer = run_subagent(task) # 等子跑完才继续
messages.append({"role": "tool", "content": answer})
# Codex V1：异步派生，父不阻塞
agent_id = spawn_agent(task) # 立即返回子的 ID
# 父继续做别的事；子在独立线程里并行跑自己的 ReAct 循环
# 子跑完后，一条“仅状态”的通知被写进父的历史
一句话：普通 subagent 是"函数调用"，V1 是"派生线程 + 异步消息"。 前者不并行（父在等），后者并行，代价是结果不再内联回填、要异步收。
4. V1 的异步完成通知：结果到底怎么回到父
这是 V1 最容易被误解的一处。父智能体并不是靠一次"同步返回值"拿到子智能体的结果的。
V1 异步完成通知流程。该图表达从父调用 spawn_agent、经独立监工等到子终态、再把"状态"写回父历史、最后由父自行取结果的八步过程；左侧三个标注点出"异步"具体落在哪里，右侧点出"通知不含实际输出"这一关键边界。
完整过程分八步：
- 父调用 spawn_agent。 运行时创建子线程后，spawn_agent 工具立刻返回子的 agent_id，父这一回合的工具调用就此结束，父不阻塞、继续做别的事。
- 运行时挂上监工。 派生时若不走 V2 驻留通道，运行时会起一个独立的监工后台任务，并把父子线程标识、父回合标识、子的引用名交给它。监工和父的回合解耦，只负责盯子的状态。
- 子并行运行。 子智能体在自己的独立线程里跑自己的 ReAct 循环，父子并行推进。
- 子到达终态。 监工持续观察子的状态，直到它进入终态（已完成、出错、关闭等都算；仍在运行或初始化中的不算）。
- 监工过滤误报。 如果终态是关闭、且整棵树正在关停，监工直接返回、不通知——这是"整树生命周期交接"，不是子的执行结果，不能误报。
- 组装完成通知。 监工生成一条完成通知，内容只有两项：子的引用名和终态状态。
- 写入父历史。 监工把这条通知追加进父的对话历史——但只记录、不驱动新一轮推理。它渲染成一段带标记的结构化文本，角色相当于 user，让父在之后的某一轮里能读到。
- 父自取结果。 因为通知里没有子的实际输出，父要在后续某一轮读到这条通知后，再由模型决定下一步——通常是调等待工具阻塞等子并取其最终消息，或直接读子的线程历史。
"异步"具体落在三处：① spawn_agent 立即返回、父不阻塞；② 监工是独立后台任务、和父子并行；③ 通知只写进历史、不抢占父当前回合。三处都不占用父的执行流。
一个必须讲准的边界：由于通知是"只写历史、不驱动新回合"，它并不会自动把父叫醒去开新一轮大模型调用；父何时处理这条通知，由上层（终端界面、应用服务后端、调用方）按各自策略决定。这正是 V2 要改进的地方——V2 的完成消息带实际内容、可寻址、还能触发新回合（见第 6 章）。
5. V1 的短板与 V2 的改进
把 V1 放到真实的大规模、长期协作场景里，会暴露三个软肋；V2 的增强基本是一一对症。
短板一：子智能体只能常驻，不能换出。 V1 每个子派生后就是一条常驻线程，没有"先请出内存、腾地方"的机制。并发一多容易超过线程配额上限，要么新派生的子被拒，要么内存和线程被占满。V2 引入驻留层 + LRU 换出：空闲子智能体按策略换出（保留状态，不是杀死），需要时由发信或派活重载唤醒，续上之前的进度。于是一棵很大的智能体树也能在固定槽位里运转。
短板二：上下文继承太粗。 V1 的继承开关配置只有"全给或不给"上下文：选全给就把父的整段历史复制给子——既浪费上下文窗口，也把父的全部中间过程泄露给子。V2 把它做成可调的 fork_turns（不继承 / 全继承 / 继承最近 N 条），默认只给一份指令快照，上下文干净、省窗口空间占用、不泄露上下文；需要时才全继承或继承最近 N 条。
短板三：协作单向，且没有信箱。 V1 的完成通知只带"谁 + 状态"，没有内容、不可寻址、父子不可双向通信；父事后想再叫子Agent干活，只能自己主动调 send_input（被关闭过的先 resume_agent），兄弟之间想互通消息则完全没有渠道——总之没有标准信箱。V2 在树级挂了共享信箱：任意智能体可按目标寻址发消息，支持"先排队、对方上线再投递"和"发信即唤醒对方开工"两种模式；完成消息也从"空通知"升级成带实际内容的消息。
6. 两代实现差异总表
演进的主线：是"第一代进程内多线程 → 加上资源弹性与真正的多智能体通信"——把常驻变成可换出/重载，把单向一次性的状态通知变成可寻址、带内容、可唤醒的信箱，把粗粒度上下文继承变精细，把线程标识寻址变成规范路径寻址。这也是许多智能体框架从"能跑"走向"可治理"时都要补的一课。
7. 小结
一条主线收束全篇：
- 普通 ReAct 是基线：单循环、单线程、单上下文、同步内联——模型决定，运行时执行。
- Codex V1 完成第一次跃迁：把"派活"从同步函数调用变成异步派生——子有独立线程、独立上下文、持久身份和可恢复的历史；代价是结果异步回流、只带状态、不带内容。
- Codex V2 完成第二次跃迁：在异步派生之上补资源弹性（驻留/换出/重载）与真正的多智能体通信（树级信箱、可寻址、可唤醒、可带内容），并把上下文继承从"全给或不给"细化到按需裁剪。
分水岭始终是那一句：并行的是"步骤"（普通 ReAct）还是"执行体"（V1 / V2）。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Readers: Know LLM ' s call and tool implementation, React, etc., but want to take a step closer to learning about the technical staff of more complex implementation mechanisms such as AI agent.
Note: The mechanism for the implementation of AI agent code under Codex CLI Z53Z execution mode is analysed and the code applied by Codex App is open-sourced, but the underlying execution logic is consistent. Code location: Github.com/openai/code.... Rust Workspace codex-rs. commit 8c07694 (2026-10-18 cloning) Code Code AI agent implementation mechanism provides two versions simultaneously, controlled by the following parameters, followed by V1, V2. By studying the comparison and evolution of the implementation mechanisms of the same scene, it can be useful to learn from the development of their products.
For the use/trigger of more than AI agent in Codex, see my previous article: "How Codex uses more than Z42Z from a user's point of view"
Baseline: General React How
1.1 What is it going to solve?
To give the model a task that will take more than one step to complete - for example, "Replace timeout in the configuration file to 30 seconds" - the model cannot be put in place one step: It needs to figure out which document to change, then really change, and then confirm that the change has worked.
React is to standardize such processes into a closed circle: one step, one step, one step, one step, and next step, until the model believes that the final answer can be given. It's the base of the vast majority of AI agent today. If you don't understand this loop, you don't understand what's out of V1/V2.
1.2 Mechanism: one closed circle, four actions
- Model reading context. context is a message list (messages) containing a description of the mission and the results of each previous round of implementation.
- Models do a deduction. Output is one of two possibilities: a structured tool call request (with which tool, parameters) or a final answer.
- Runtime (Runtime) implementation tool. In the case of tool call, the return result is added as a new message to context when the outer layer is actually running (read and write files, execute commands, query data).
- Back to step 1. The model is based on an updated context; if step 2 output is the final answer, the cycle ends.
This gives rise to three key characteristics:
- One-way: action sequence, no parallel implementer;
- Single context: Sharing the same memory throughout the journey, without isolation or partition;
- Synchronization: The results of the tool go back to the same context and the caller waits.
Another project detail cannot be ignored: the cycle must be protected by a maximum number of steps. Otherwise, the model may repeatedly call on the same tool and never stop.
1.3 Code sample
The following is a minimal achievement (teaching, omitting error processing with retry; call mode is a pseudo-function, and in the real project it is a LLM API call that returns the structured result):
from typing import Any
# ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------- -- -- -- -- -- -- -- -- --
def edit_file(path: str, old: str, new: str) -> str:
""Replace one of the old files with new."
Return f "Replaced 1 Place: {path}"
TOOLS = {"edit_file": edit_file}
# --React main cycle -- -- --
def react_loop(task: str, max_steps: int = 10) -> str:
# context: A list of messages, all rounds shared
messages: list[dict[str, Any]] = [{"role": "user", "content": task}]
for _ in range(max_steps):
# The model is only for "decision": read context, output thinking + tool call request or final answer
reply = call_model(messages, tools=TOOLS)
if reply.tool_calls:
# Write "Think + tool call Request" in context
messages.append(reply.to_message())
for call in reply.tool_calls:
# The real implementation tool is running time, not model
result = TOOLS[call.name](**call.args)
# Watch results added as new news, driving the next round of reasoning
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
# Back to the top of the cycle
# No tool call: The model gives the final answer, the loop ends
return reply.content
"The maximum number of steps has been reached, the task is not completed."
Please note the division of labour between the two lines: call model to produce only "what tool, what parameters are" requests; TOOLScall.name for real implementation tools. The model is responsible for decision-making and, at the time of operation, for implementation - the dividing line remains valid in V1/V2, except for a change in the pattern of the organization.
1.4 A map of the normal Rect mechanism
Normal Rect: The model reads context and selects one - the output of the tool call request (executed by running time, the observation returns to context and enters the next round) or gives the final answer directly (end of cycle). On the left side is the list of messages that grow with the round, and at the bottom is the three key properties of single-line, single-context, and synchronous interconnectivity.
1.5 Further: what does ordinary subagent look like?
Many of the frameworks added "Son AI agent" to React: The father decided in one round to "send this job to a full-time son" and then synchronized the call to a son - the father waited, the son ran the whole react cycle and returned the final answer to the father as the return value of the call; the father filled it back into his context and continued the next round. Discarded after use: no name, no history, no record.
# Normal subagent: Synchronize inline, run away
def run_subagent(task: str) -> str:
Sub messages = ["Role": "user", "content": task}] #
# Son runs his own cycle
# Father AI agent: Call is blocked until final answer is obtained
= run subagent
# Turns out it's back to context
Remember this "sync inline" form. Codex V1's spawn agent looks like he's doing the same thing, but the bottom is another way -- the next chapter begins to compare.
2. Comparison of the three modes of implementation
2.1 Three location
- Normal React: a AI agent, a cycle, one-way context, synchronised.
- Codex V1: Son AI agent of the father-born independent thread, the father and the son run around each other and inform the father when the child is finished.
- Codex V2: Same core as V1, additional support for the presence, replacement and reloading of sub-AI agent and a tree-scale shared mailbox.
The main differences between V1 and V2 are in the cantonment level, completion of signal and communications facilities and are not within the process boundary.
2.2 Common Basement
The kernels of all three are rect: they're the cycle of "model decision next step, run-time execution, feed-back model"; the real implementers are the outer layer when running, and the model only outputs structured tool call requests. The difference is that the cycle has a few, how it is organized.
2.3 Comparative overview
Three implementation models. The figure shows the difference in the implementation structure between the normal Rect's "one-cycle, synchronous interconnectivity", the "separatist of V1" + independent thread + one-way notification, and the "speechive of V2" + presence to exchange + mailbox address.
To help narrow screen reading, break it down into two sections: Table A, look at what the V1 relative React changed, Table B, look at what the V2 relative to the V1 adds.
Table A: Normal Reform ↔Codex V1 (cross point: parallel + walk)
Table B: Codex V1 ↔ Codex V2 (Cross point: Stay + Mailbox)
One of the most confusing points: normal Rect is also often supportive of "one round with multiple tools" -- a LLM call that returns multiple tools to execute, and applications run in parallel, but that's not the same thing with Codex -- The former are parallel steps in the same cycle, in the same context, with the result that they are all filled in; the latter are parallels of multiple independent implementers, multiple independent contextes, each with its own cycle and memory, which are co-ordinated with different messages or notifications. The difference is between "steps" and "implementors".
2.4 Direct explanation of two leaps
The three modes are lined up, from normal rect to V2 are two-step.
The first leap from "One Cycle" to "More Parallel Cycles" to "Sync" to "Wanking." Normal Rect is "a man from the beginning to the end" and everything is done in a context, a thread. V1 The father was allowed to send several sons, Agent, to work in parallel, each with a context and a thread. The price is to control the flow: the father did not wait, but went back to an id to do his job, and the son Agent did his job before going back to the father. V1 In exchange for parallel capacity, the cost is that the result is no longer interconnective filling and a different harvest.
Second leap (V1 → V2) from "static residence, one-way collaboration" to "replaceable reloadable, addressable, awakening". V1 sub-Agent does not destroy the threads after running, but there is no "please get the memory out" saying — no visible closure keeps the threads running and more than easily reaches the limit of the system's linear control. If the father wants to get him to work again, he has to set his own send input for a new round (to be pulled up by a closed first resume agent); the result depends on the wait or the reading of the sub-routine. In any case, the collaboration is initiated by the father alone: the completion notice is only "state" without content, and brothers cannot speak directly. Three pieces of V2 were added: the replacement with heavy load (the spare Agent released, awakening when needed, resources are no longer static), the mailbox (any kind of AI agent can send messages to each other by identification, supporting the two models "Call first, the other on the line and send a message to awaken the other" ), the cleaner context succession (the default only takes a snapshot of the instructions and no longer reproduces the entire father's history).
3. V1 Difference relative to "normal subagent"
The synchronization of Section 1.5 is the most easily confused object with V1. The same thing: it's all triggered by a father's model in a decision-making process, it's all going through its own reasoning cycle, and it's all going down there. But the bottom is different.
Intuitive with code:
# Normal subagent: Father blocking, resulting in a backfilling
# Wait till the waiter runs
messages.append({"role": "tool", "content": answer})
# Codex V1: He's an alien, and his father doesn't block
# Return the child's ID immediately
# The father continues to do something else; the son runs his ReAct cycle in parallel with the independent thread
# When the boy runs, a "state" notification is written into the history of his father
One sentence: Normal subagent is "Function Call" and V1 is "Specific Thread + Step News". The former are not parallel (the father is waiting) and the latter are parallel, at the cost of no more interlocking and different harvests.
4. Step completion notification for V1: how to get back to the father
This is one of the most easily misunderstood places. Father AI agent didn't get the result of Z42Z on a "sync return value".
V1 Step completion notification process. This chart shows the eight-step process of calling from the father, waiting for the end of the child by an independent supervisor, writing the "state" back to the father's history and finally the father's own results; the three point points on the left show where the "discretion" is, and the "notices" on the right do not contain the actual output."
Complete process in eight steps:
- Father calls spawn agent. When running, when creating the sub-routine, the spawn agent tool returns to the agent id of the son. The tool call of the father's turn is over and the father does nothing else.
- Hang on to the supervisor on the run. If born without the V2 presence channel, an independent supervisory backstage mission is performed and the father-son thread identification, father-round identification, and child reference is given to it. The monitor and the father are responsible only for the baby's state.
- Sub running in parallel. The son AI agent runs his own rect loop in his own independent thread, and the father and the son advance in parallel.
- Son to death. Monitors continuously observe the condition of the sub-unit until it reaches its final stage (completed, errored, shut down, etc.; still in operation or in initialization).
- Supervisor filters false reports. If the final act is closed and the whole tree is shut down, the supervisor returns, without notice. It's the whole tree life cycle. It's not a child's execution.
- Notification of assembly completion. The supervisor produces a completion notice containing only two references: the child ' s reference and the final state.
- Write in father history. The supervisor added the notification to the father's history of dialogue - but only recorded and did not drive a new round of reasoning. It's retrofitted into a stylized text, the role of which is equivalent to the user, so that the father can read it in a later round.
- Father takes his own results. Because there is no actual output of the child in the notification, the father has to read the notification on a subsequent rotation before the model decides next step - usually waiting for the tool to block the child and extract its final message, or the linear history of the directly read item.
"Step" falls in three places: 1 spawn agent returns immediately and does not obstruct the father; 2 Supervisors are independent backstage tasks in parallel with the father and son; 3 Notifications are written in history and do not take over the father's current round. All three do not take up the father's execution stream.
A boundary that must be correct: because the notice is "historic, not driving a new round", it does not automatically wake up the father to open a new round of LLM calls; when the father handles the notification, it is determined by each other's strategy (end interface, application service backend, caller). This is where V2 is to be improved - V2 completion message with actual content, addressable, and triggers a new round (see chapter 6).
5. V1 shortboard and V2 improvements
Putting V1 in a real, large-scale, long-term collaboration scenario exposes three soft spots; the increase in V2 is basically a pair of symptoms.
Shortboard 1: Sub-AI agent can only be permanent and cannot be replaced. V1 Every child is born on a permanent basis, and there is no mechanism for RAM first. More than one can easily exceed the limit on linear quotas, either by rejecting newly born children or by full RAM and circuit occupation. V2 Introduction of Script + LRU: Free AI agent is strategically replaced (reserved, not killed) by a reloading of mail or dispatch when required to continue progress. So a large AI agent tree can also operate in fixed slots.
Shortboard II: context inheritance is too rough. Inheritance switches for V1 are configured only "to give or not give" context: Select to copy the entire history of the father to the son - waste of context window and leak to the child all the middle process of the father. V2 makes it truncable fork turns (not inheriting the last Article N), by default giving only one command snapshot, context cleans, saves window space, does not divulge context; inherits or inherits the last Article N only when required.
Shortboard III: Collaboration one-way and no mailbox. V1 completion notices are only "who + status" and have no content, no location and no two-way communication between the father and the son; the father then wanted to call his son Agent to work, but only sent input (first closed resume agent) on his own initiative, and there was no channel between brothers to communicate — in any case, no standard mailbox. V2 A shared mailbox was installed at the tree level: any AI agent can send a message by target to support the two models "Call first, hand each other over on the line" and "Call each other up to work"; the completed message is also upgraded from "free notice" to a message with actual content.
6. Summary of variances achieved for two generations
The main line of evolution: it's "Multiline Ranges within the First Generation Process" plus resource elasticity and real multi-AI agent communication -- turning permanent presence into removable/reloadable, turning one-way one-off status notifications into a searchable address, with content, a wake-up call box, decorating the coarse context inheritance, and turning the thread identification site into a normative path search. This is also a lesson that many AI agent frameworks need to fill in as they move from running to being governance.
Summary
One main line closes:
- General React is the baseline: single cycle, single course, single context, synchronous Inline - Model decision, run-on.
- Codex V1 completes the first leap: turning Pyramid from a synchronous function to an aniso-- – There is an independent thread, an independent context, a permanent identity and a recoverable history; the cost is a different flow of results, only a state, without content.
- Codex V2 completes the second leap: the elasticity of the resources (suspension/replace/reload) over the staggered product, communicates with the true multi-AI agent (tree-grade mailbox, addressable, awakening, contentable), and details the succession of context from "all or no" to "cut on demand."
The watershed is always the same sentence: parallel is the "step" or "executor" (V1/V2).
Auto-fetched and translated by AI Atlas. All rights belong to the original author.