这一阶段对应两篇文章：
- Unrolling the Codex agent loop（2026-01-23）
- From model to agent: Equipping the Responses API with a computer environment（2026-03-11）
这一阶段的目标只有一个：
把“LLM 会回答问题”升级成“Agent 如何持续完成任务”的脑内模型。
第一阶段总览：先别急着谈“智能”，先看“闭环”
很多人第一次接触 agent，会下意识把它理解成：
大模型 + 工具 = agent
这个理解不算错，但太浅。更准确地说，agent 是一个持续闭环系统：
接收任务 → 组织上下文 → 调模型推理 → 选择工具 → 执行工具 → 读取结果 → 更新上下文 → 继续推理 → 直到结束。 这正是 OpenAI 在 Unrolling the Codex agent loop 里强调的核心：agent 的本质是一个 loop，而不是一次回答。
而 From model to agent 进一步补了一层：
光有 loop 还不够。要让它真的能做复杂任务，还必须给它一个可执行环境，包括隔离容器、文件系统、可选结构化存储、受控网络等。否则它只能“想”，不能“干”。
所以第一阶段你要建立的不是“prompt 技巧”，而是下面这张心智图：
模型负责判断，agent 负责闭环，运行时负责落地。****
一、先把最小概念讲透：Model 和 Agent 到底差在哪
最简单的区分方式：
Model
像一个只会“看题作答”的大脑。你给它输入，它给你输出。
Agent
像一个能“接任务并执行”的系统。它不仅回答，还会：
- 决定下一步干什么
- 调用工具
- 读写文件
- 处理中间结果
- 在多轮中保持任务连续性
- 在必要时收束并交付最终结果
OpenAI 在文章里明确说，单靠 prompt，你只能调用模型已经训练好的智能；但如果给模型一个计算机环境，它就能处理更广泛的工作流，比如运行服务、调用 API、生成表格和报告。
所以一句话：
模型解决“这一步怎么想”，agent 解决“整件事怎么做完”。
二、Agent loop 是什么：把它想成“带工具的迭代求解器”
OpenAI 对 agent loop 的描述非常清楚：
-
agent 先把用户输入组织成 prompt
-
发起模型推理
-
模型有两种可能输出
- 直接给最终答复
- 请求调用某个工具
-
如果请求工具，agent 执行工具，把工具输出追加回上下文
-
再次调用模型
-
重复，直到模型不再请求工具，而是产出面向用户的 assistant message 这套机制可以压缩成一句话：
Agent = “模型决策器” + “工具执行器” + “状态累积器”****
你可以把它类比成一个程序员排查 bug：
- 先读问题
- 猜一个方向
- 跑个命令看结果
- 根据结果修正判断
- 再跑下一个命令
- 改代码
- 测试
- 最后汇报
这就是 agent loop，只不过“猜方向”的是模型，“跑命令”的是执行环境，“保存上下文”的是 agent runtime。
三、为什么单次调用模型不够：复杂任务天然需要中间状态
这一步是第一阶段里最关键的认知转折。
很多任务无法靠“一次推理”完成，因为中间状态太多。比如让 agent：
- 看一个代码仓库
- 找到架构入口
- 生成架构文档
- 跑测试验证
- 修改失败点
- 最后输出 README 更新说明
这里面每一步都会产生新信息。而这些信息不是预先全知道的，是执行后才知道的。
所以 agent 不是“更强的回答器”，而是“边做边获得信息的系统”。 OpenAI 在 Unrolling the Codex agent loop 里明确说，agent 的输出不仅是 assistant message，很多时候主要输出其实是它在本地环境里写下或修改的代码；assistant message 只是一个“本轮已完成”的终止信号。
这句话很重要，因为它把 agent 从“聊天工具”拉回到了“任务执行系统”。
四、Prompt 不是一句话，而是一个“上下文装配结果”
很多人以为 prompt 就是用户输入的那句话。这在 agent 场景里通常是错的。
OpenAI 在 Unrolling the Codex agent loop 里解释得很具体：用户并不是直接指定最终 prompt，而是提交不同类型的信息，由 Responses API 把它们组织成模型真正消费的上下文。重点包括三类输入：
- instructions
- tools
- input
而且这些内容还按角色分层，至少包含 system、developer、user、assistant，优先级从高到低。
这意味着，agent 的真实输入不是一句“帮我做 X”，而是一整套结构化上下文，例如：
- 系统级规则
- 开发者级规则
- 工具清单
- 权限说明
- 当前工作目录
- 可写目录
- 网络限制
- 用户消息
- 历史消息
- 历史工具调用结果
OpenAI 甚至展示了 Codex 会把本地环境信息加入上下文，比如当前工作目录和 shell 类型；也会加入权限说明，明确文件权限、网络访问和何时需要向用户请求授权。
所以第一阶段你要建立一个很重要的感觉：
Agent 的质量，往往不是由“用户那一句话”决定，而是由“整套上下文装配质量”决定。
五、为什么工具是必需品：模型看见世界，工具改变世界
在 agent loop 里，模型本身并不直接执行动作。
模型做的是：提出动作请求。
真正执行动作的是工具和运行时。
OpenAI 的例子里，Codex 会把工具列表提供给模型，其中包括：
- shell 工具
- plan/update_plan 工具
- web_search
- 以及用户通过 MCP 接入的其他工具
这说明一个本质问题：
模型负责选择动作，工具负责落地动作。****
这和传统软件里的“planner + executor”很像。
如果没有工具，模型最多只能描述“应该做什么”；
有了工具，它才能真正去：
- 运行命令
- 读取目录
- 打开文件
- 搜索资料
- 访问数据库
- 生成工件
所以做 agent 时，一个非常常见的误区是： 把精力都放在 prompt wording 上，却忽略了工具设计。 实际上，很多 agent 效果差，不是因为模型不够聪明，而是因为：
- 可用工具太弱
- 工具 schema 不清晰
- 工具结果不可读
- 权限模型混乱
- 上下文反馈太噪
六、上下文窗口为什么会成为核心瓶颈
一旦 agent 进入循环，上下文就会不断变长：
- 用户消息要保留
- 历史 assistant 消息要保留
- 工具调用记录要保留
- 工具输出要保留
- 新一轮决策还要再加进去
OpenAI 明确指出，随着对话增长，用来采样模型的 prompt 也会持续增长；而每个模型都有 context window 上限，并且这个上限同时包含输入和输出 token。一个 agent 在单轮里做上百次工具调用，是完全可能把上下文耗尽的。 这就是为什么： Agent 最大的工程问题之一，不是“会不会调用工具”，而是“能不能在长任务中不把自己撑爆”。****
这也是第一阶段必须理解的关键：
一旦做真实 agent，你就不能再把上下文当成“无限聊天记录”。
七、Compaction 是什么：不是简单摘要，而是上下文续命机制
OpenAI 在 From model to agent 里专门讲了 compaction。 当任务持续很久、上下文快满时，系统不能简单粗暴地丢掉旧内容，否则 agent 会失忆。于是他们加入了原生 compaction：让模型分析先前的对话状态，生成一个加密、token 更省、但保留关键信息的表示。之后新的上下文窗口由这个 compaction item 加上早期窗口里高价值部分组成，从而让长任务可以跨越窗口边界继续推进。
这里最值得你抓住的是：
Compaction 的目标不是“更短”，而是“在更短的前提下尽量保住任务连续性”。****
所以它和普通摘要不一样。普通摘要面向人阅读，compaction 面向后续推理。它本质上是 agent 的“工作记忆压缩”。
你可以把它理解成：
- 普通聊天摘要：给人回顾
- compaction：给 agent 继续干活
这也是为什么 OpenAI 说它是原生能力，而不是让开发者自己维护一套手工 summarization/state-carrying 系统。
八、为什么需要“计算机环境”：别把所有东西都塞进 prompt
这篇里非常实用的一点，是它把“真实 agent”会遇到的工程问题点得很透：
- 中间文件放哪里
- 大表格怎么处理，难道全贴进 prompt？
- 工作流怎么安全访问网络
- 长时任务的超时与重试怎么处理
OpenAI 给出的答案是： 不要让开发者自己从头拼这些，而是给 Responses API 配一个受控的计算机环境，包括：
- 隔离执行环境
- 文件系统
- 可选结构化存储（如 SQLite）
- 受限网络访问
这背后的第一性原理非常简单：
模型擅长理解和决策，计算机环境擅长存储、执行和与外部系统交互。
如果你把所有资源都塞进 prompt，会立刻遇到三个问题：
- token 太贵
- 上下文太乱
- 信息不可持续复用
因此，文件系统不是附属品，而是 agent 的长期外部记忆之一。
OpenAI 也明确说，容器不只是跑命令的地方，还是模型的工作上下文；模型可以在容器里读文件、查数据库、在网络策略控制下访问外部系统。
九、为什么“bounded output”和“并发执行”很重要
一旦 agent 开始用 shell，就会产生大量终端输出。
如果原样把所有日志都回灌给模型，结果通常不是更聪明，而是更混乱。
OpenAI 提到两个关键机制：
- 可以并发执行多个 shell 命令，分别在独立会话里流式返回
- 可以对单个命令输出设定上限，只保留开头和结尾，并标记中间省略内容
这两个机制解决的其实是同一个问题：
让模型看到“有用的结果”，而不是“海量的原始噪音”。
这件事非常关键。因为 agent 系统的瓶颈不只是推理能力，还包括信息带宽管理能力。
工程上常见的错误是：
“既然模型上下文大，就把所有日志都喂回去。”
但正确做法通常是：
把原始信息保存在环境里，只把当前判断真正需要的那部分送回上下文。
十、总结
1. 用户不是在和“一个回答器”交互
而是在给“一个任务闭环系统”下达目标。
2. Agent 的核心不是一次回答，而是循环
推理、调用工具、读结果、继续推理，直到结束。
3. 真正的 prompt 不是一句话
而是系统把 instructions、tools、environment、history、user input 组装后的结构化上下文。
4. 工具决定 agent 能不能“动手”
模型选择动作，工具执行动作。
5. 长任务的核心难点是上下文管理
不是“会不会想”，而是“能不能不断推进又不失忆”。
6. 运行时环境是 agent 的外部身体
文件系统、数据库、网络策略、隔离容器，都是让 agent 从“会说”变成“会做”的前提。
