OpenAI 宣布计划收购 Ona，目标很明确——把 Codex 从一个「跑完就扔」的代码生成工具，升级为能在安全、持久化云环境中长时间运行的 AI Agent 平台。这意味着 Codex 不再只是帮你写一段函数，而是能挂在一个企业工作流里，持续几个小时甚至几天地执行任务、维护状态、与多个系统交互。
短命 Agent 的瓶颈
当前大多数 AI Agent 的运行模式是：收到指令 → 在临时沙箱里执行 → 返回结果 → 沙箱销毁。这种模式对单次任务够用，但面对企业级场景就暴露了几个硬伤：
- 状态丢失：Agent 每次启动都是空白记忆，无法积累上下文。一个需要跨多个仓库协调重构的 Agent，不可能每次都从头读代码。
- 无法长驻：涉及 CI/CD 流水线、监控响应、渐进式代码迁移的任务，天然需要 Agent 持续运行数小时。
- 安全边界模糊：临时沙箱的权限控制粗糙，企业不敢让 Agent 直接碰生产数据库或内部 Git 仓库。
Ona 的核心能力正是解决这三点——提供安全隔离的持久化云环境，Agent 可以在里面长期驻留、保持状态、按企业策略访问资源。
Codex + Ona 会变成什么
收购完成后，Codex 的架构大概率会从「一次性执行」转向「驻留式 Agent」。具体来说：
持久化环境：每个 Agent 拥有自己的云工作空间，文件系统、进程、网络配置在任务周期内持续存在。Agent 可以在同一个环境里反复执行、调试、迭代，而不是每次重建。
安全策略嵌入：Ona 的环境支持企业级权限控制——网络出口限制、文件系统只读挂载、API 调用白名单。这意味着企业可以放心让 Codex Agent 操作内部代码仓库，而不担心它越权访问生产数据库。
多步骤工作流：一个 Agent 不再只做一件事。它可以：拉代码 → 分析依赖 → 生成迁移方案 → 提 PR → 跑测试 → 根据测试结果修改 → 再提交。整个链条在同一个环境里连贯完成。
现在就能实践的持久化 Agent 设计
虽然 Codex + Ona 的完整产品形态还没落地，但持久化 Agent 的设计思路今天就可以用 OpenAI API + 容器化环境来模拟。下面是一个用 Python 实现的长驻 Agent 框架，核心是「环境保持 + 状态持久 + 多轮执行」：
import os
import json
import time
from pathlib import Path
from openai import OpenAI
client = OpenAI()
# ---- 持久化工作空间 ----
WORKSPACE = Path("./agent_workspace")
WORKSPACE.mkdir(exist_ok=True)
def load_state() -> dict:
"""从工作空间加载 Agent 状态，实现跨轮次记忆"""
state_file = WORKSPACE / "state.json"
if state_file.exists():
return json.loads(state_file.read_text())
return {"history": [], "artifacts": []}
def save_state(state: dict):
"""保存状态，下次启动时 Agent 不需要从头开始"""
(WORKSPACE / "state.json").write_text(json.dumps(state, ensure_ascii=False, indent=2))
# ---- 工具定义：Agent 可以在持久环境中读写文件 ----
TOOLS = [
{
"type": "function",
"function": {
"name": "write_file",
"description": "将内容写入工作空间中的文件",
"parameters": {
"type": "object",
"properties": {
"filename": {"type": "string", "description": "文件名"},
"content": {"type": "string", "description": "文件内容"},
},
"required": ["filename", "content"],
},
},
},
{
"type": "function",
"function": {
"name": "read_file",
"description": "读取工作空间中的文件内容",
"parameters": {
"type": "object",
"properties": {
"filename": {"type": "string", "description": "文件名"},
},
"required": ["filename"],
},
},
},
]
def execute_tool(name: str, args: dict) -> str:
"""在持久化工作空间中执行工具——文件不会在 Agent 退出后消失"""
if name == "write_file":
path = WORKSPACE / args["filename"]
path.parent.mkdir(parents=True, exist_ok=True)
path.write_text(args["content"])
return f"已写入 {path}"
elif name == "read_file":
path = WORKSPACE / args["filename"]
if path.exists():
return path.read_text()
return f"文件 {path} 不存在"
return "未知工具"
# ---- 多轮执行循环 ----
def run_agent(task: str, max_rounds: int = 5):
state = load_state()
state["history"].append({"role": "user", "content": task})
for round_num in range(max_rounds):
print(f"\n--- 第 {round_num + 1} 轮 ---")
response = client.responses.create(
model="gpt-4.1",
input=state["history"],
tools=TOOLS,
)
# 收集 Assistant 输出
assistant_items = []
tool_calls = []
for item in response.output:
if item.type == "message":
text = item.content[0].text
print(f"Agent: {text}")
assistant_items.append({"role": "assistant", "content": text})
elif item.type == "function_call":
tool_calls.append(item)
# 如果没有工具调用，Agent 认为任务完成
if not tool_calls:
state["history"].extend(assistant_items)
save_state(state)
print("\n✅ Agent 认为任务完成，状态已保存。下次启动可继续。")
break
# 执行工具调用，结果写入历史
tool_results = []
for tc in tool_calls:
result = execute_tool(tc.function.name, json.loads(tc.function.arguments))
print(f" 工具 {tc.function.name} → {result}")
tool_results.append({
"type": "function_call_output",
"call_id": tc.call_id,
"output": result,
})
state["history"].extend(assistant_items)
state["history"].extend(tool_results)
save_state(state)
# ---- 运行示例 ----
if __name__ == "__main__":
# 第一次运行：让 Agent 分析并生成方案
run_agent(
"分析当前工作空间中的代码文件（如果有的话），"
"生成一个 Python 模块 refactor_plan.py，"
"包含对现有代码的重构建议列表。"
)
# 隔一段时间再次运行——Agent 会读取上次保存的状态和文件
# run_agent("根据 refactor_plan.py 中的建议，逐项执行重构并记录进度")
运行前确保已安装 openai 包并设置了 OPENAI_API_KEY：
pip install openai
export OPENAI_API_KEY="sk-..."
python agent_persistent.py
这个示例的关键设计点：
- 工作空间持久化：文件写在本地目录，Agent 退出后不消失。Ona 提供的是云端版本，但思路一致。
- 状态序列化：每次执行后保存对话历史和中间产物，下次启动 Agent 不需要重新分析。
- 多轮循环：Agent 不是一次性返回结果，而是反复调用工具、检查结果、调整策略，直到任务完成。
企业落地的现实考量
持久化 Agent 听起来强大，但落地时有几个必须正视的问题：
成本控制。Agent 长驻意味着持续的 API 调用和云资源消耗。一个跑 8 小时的迁移 Agent，Token 费用可能远超预期。建议设置 max_rounds 和单轮 Token 上限，并在每轮检查预算。
安全边界。持久环境给了 Agent 更多权限，也给了更多犯错空间。生产环境中必须限制：网络出口（只允许访问内部 Git 和 CI API）、文件系统范围（只挂载项目目录）、操作审计（每次工具调用都记录日志）。
容错与恢复。Agent 运行时间长，中途崩溃的概率显著增加。状态持久化本身就是容错手段——崩溃后从 state.json 恢复，而不是从头开始。但需要设计合理的 checkpoint 频率，避免每一步都写磁盘拖慢速度。
人机协作节奏。不是所有任务都适合 Agent 全自动跑完。关键决策点（比如删除生产表、合并主分支）应该暂停等待人类确认。在工具定义中加入 request_approval 类型，是务实的做法。
收购 Ona 之后，Codex 有机会从「代码补全工具」变成「企业开发流程的驻留协作者」。但持久化 Agent 的成熟，不只是技术问题——权限模型、成本治理、容错设计，这些才是决定它能不能真正进入企业生产环境的关键。现在用上面的框架做原型验证，比等产品上线后再踩坑要划算得多。