本文作者：sitin（@sitinme）。版权归作者所有，未经授权禁止转载。
很多 AI 留在聊天框里，只能告诉你代码应该怎么改。
到了 Codex 这里，它却能自己读取项目、修改文件、运行测试，把一项工作继续做几个小时。
这中间到底多了什么？
9 月 10 日，OpenAI 宣布 Agents API 进入 public beta（公测），把支撑 Codex 的同一套 harness 和基础设施通过 API 带给开发者。
要讲清楚这件事，我先给一个便于理解的简化拆法：
Agent ≈ Model（大模型） + Harness（运行框架）。
Model 负责思考、理解、推理和决策。你给它一段需求，它可以分析问题、生成代码，也可以判断下一步应该做什么。但模型本身并不知道项目文件放在哪里，也不会自动打开终端运行测试。
Harness 负责组织上下文、工具调用、状态和子 Agent，并让模型通过工具访问具体的执行环境。它运行这样一个循环：模型判断 → 调用工具 → 读取结果 → 继续判断。模型在这个循环里不断根据真实结果调整下一步，才有可能把一个目标持续推进下去。
所以，Agent 想连续干活，需要 Harness 和一个可操作的执行环境。
谁来保存任务状态？
谁把文件、终端和浏览器交给它？
工具调用失败以后从哪里继续？
任务太大时，怎样拆给不同的子 Agent？
最后又怎样留下过程，让人检查它到底做了什么？
Harness 负责组织 Agent 配置、Session、上下文、工具调用和执行环境。文件、终端等操作，则实际运行在具体的执行环境里。
Model 像负责思考的大脑，Harness 像连接工作流程的调度层和任务管理系统；两者合在一起，再配合具体执行环境，才形成能接到目标后持续行动的 Agent。
现在，我们可以通过 Agents API，把 Codex 这种“接到任务以后继续往下干”的工作方式放进自己的产品。
01 Harness 把模型接到真实工作上
把这个简化关系分清以后，再回头看 Codex，差别就很明显了。
一个模型再聪明，如果只有聊天框，能做的事情依然有限。
你问一句，它回答一句。需要文件时你上传，需要运行代码时你自己复制，需要继续上次的工作时，你还得重新交代背景。
有了 Harness，模型周围会多出一整套工作条件：
- 它知道当前要完成什么；
- 它能读取文件和使用工具；
- 它能看到任务进行到了哪里；
- 工作太多时，可以拆给几个子 Agent；
- 中间失败以后，可以根据已有状态继续；
- 最后留下文件、记录和可以检查的结果。
所以 Codex 的价值，不只是“这个模型很会写代码”。它还有一个真实工作现场。
它可以进入项目，读取资料，运行命令，修改文件，再打开结果检查。
把这些能力组织起来的运行框架，就是 Harness。
02 长任务并不是让 AI 一直想
很多人会把“长任务”理解成让模型一次思考几个小时。
但真正的长任务，更像我们平时做项目。
先理解目标，再拆分步骤；做到一半发现问题，就回去修改；需要其他资料时，再补充输入；最后还要检查结果。
比如，给一个维护了多年的老项目做框架和依赖升级。
这不是把“请升级到最新版”丢给模型，然后等它一次性改完。一个比较完整的过程，至少会经历这些轮次：
读取仓库结构和项目规则，确认目标版本与验收标准 → 盘点依赖、锁文件、构建脚本和受影响的模块 → 分批修改版本配置，先处理核心框架和明确的不兼容 API → 运行构建与测试，读取真实错误和警告 → 根据错误继续修复调用方式、类型和配置 → 检查关键页面与接口，确认运行时行为没有回退 → 整理 diff、升级清单、验证结果和未解决问题
第一轮可能只是读文件和搜索调用关系，产物是依赖盘点和影响范围。第二轮修改配置以后，锁文件和 diff 就成了下一轮的输入。运行测试报出的错误，又会告诉模型应该回到哪一个模块继续处理。
如果升级跨越多个大版本，中间还可能需要暂停下来确认迁移指南，或者把“先让构建通过”和“再检查页面行为”拆成两个阶段。模型不是一直在后台凭空思考，它是在每次工具调用返回结果以后，基于当前文件、终端输出和任务状态决定下一步。
这条链路里，每一步都会产生新东西。
升级后的配置、锁文件、修复过的源码、测试日志和检查记录，都会成为后续行动可以读取的依据。最后交付的也不只是一句“升级完成”，而是一组能让人复查的变更和结果。
这才是长任务能稳定推进的关键。
不要让 AI 靠记忆硬撑，要让工作过程留下可以继续使用的东西。
03 Session 给任务留下一张工作台
Agents API 里有一个很重要的概念，叫 Session。
它可以理解成一项任务自己的工作台。
你先创建一个 Agent，规定它使用什么模型、遵守哪些要求、可以调用什么工具。真正开始某项工作时，再给它创建一个 Session。
这项任务产生的消息、状态、工具调用和结果，都会围绕这个 Session 继续积累。
这样做解决了一个很实际的问题：任务不必绑在某一次请求上。
一次性请求通常围绕一次输入返回结果；一个 Agent 任务则可能等待工具结果、接收补充资料，也可能在运行一段时间以后才发现缺少权限，需要分成多个阶段继续推进。
有了 Session，产品可以继续查询它的状态，也可以在原来的任务里补充一句：
“先完成接口部分，页面暂时只给方案，不要修改。
Agent 收到新要求后，继续在同一项任务上工作。
这和在 Codex 里不断追加要求的体验很接近。
区别在于，Codex 已经把界面、项目和执行过程做好了；Agents API 则让开发者把类似的能力接进自己的产品。
04 工具决定 Agent 能不能真正交付
即使有模型和 Session，Agent 依然需要工具才能真正完成工作。
比如一个代码 Agent，可能需要：
- 读取仓库文件；
- 搜索函数和调用关系；
- 修改代码；
- 运行测试；
- 查看测试结果。
一个内容 Agent 需要的工具又不一样：
- 搜索最近的资料；
- 读取过去发布的文章；
- 创建和修改文档；
- 调用图片模型；
- 检查最终素材。
工具不是越多越好。
如果任务只是整理文章，就没有必要给它生产部署权限。如果只需要读取数据，也不应该顺手开放删除和发布能力。
更稳妥的做法是按任务开放能力。
需要搜索，就给搜索；需要改本地文件，就限制在指定目录；涉及发布、发送、删除和付费操作，再单独由人确认。
Agent 的能力边界越清楚，长任务越容易放心地交出去。
05 子 Agent 适合处理彼此独立的部分
Agents API 还支持子 Agent。
这也是 Codex 处理复杂任务时很有用的一种方式。
例如维护一个独立软件，准备做一次较大的依赖升级，可以把互相独立的前期工作拆开：
- 一个 Agent 查迁移文档、版本兼容性和已知破坏性变更；
- 一个 Agent 盘点依赖、配置和 API 的调用点，整理受影响的模块；
- 一个 Agent 检查现有测试覆盖、补充关键路径的验收清单并标出风险。
它们分别完成以后，再由主 Agent 汇总结论。
这种拆法适合并行做资料核对、调用点盘点和风险检查，因为它们的输出可以分别汇总。
但如果让三个 Agent 同时改同一组文件，最后很可能出现互相覆盖的修改或无法判断的冲突。
共享文件的修改仍应串行进行，由主 Agent 统一安排顺序并验收结果。子 Agent 更适合搜索、对比、独立检查和互不重叠的实现。
这和带一个小团队差不多。
分工本身不难，难的是每个人交回来的东西能不能拼到一起。
06 长任务能不能用，最后看验收
Agent 做完以后说一句“已经完成”，这件事还没有真正结束。
以老项目的框架和依赖升级为例，构建通过只能说明编译或打包链路走通了，不能直接等于任务完成。至少还要继续做几轮验收：
- 跑测试和关键路径，确认核心接口、页面或命令的行为没有回退；
- 检查运行时日志和实际启动结果，排除只在构建阶段暴露不出来的问题；
- 审核代码 diff、依赖清单和锁文件，确认没有无关升级或意外改动；
- 记录仍未解决的兼容性问题、警告和需要人工确认的遗留项。
给 Codex 或其他 Agent 下任务时，可以把验收标准直接写进去：
请先运行构建和测试，再检查关键接口、页面或命令的运行时结果。 请审阅代码 diff、依赖清单和锁文件，确认没有无关改动。 请列出仍未解决的兼容性问题、警告和需要人工确认的遗留项。 只有完成这些检查，才能报告升级完成。
这一段往往比堆很多提示词更有用。
它把任务的终点，从“AI 写完了”推进到“结果经过检查并且可以被人接手”。
07 Codex 和 Agents API 到底是什么关系
Codex 是一个已经做好的 Agent 工作环境。
你打开一个项目，把任务交给它，就可以直接查看执行过程、文件改动和最终结果。
Agents API 面向的是想开发自己产品的人。
开发者需要自己决定：
- Agent 放在哪个产品里；
- 能使用哪些工具；
- 怎样在产品里展示和续接任务状态；
- 怎样展示执行过程；
- 哪些操作必须等待用户确认。
它们之间最直接的关系，是 Agents API 把支撑 Codex 的同一套 harness 和基础设施带给开发者；开发者需要选择执行环境，并决定产品界面、工具、知识和工作流，也不意味着把 Codex App 嵌入自己的产品。
如果你只是想让 AI 帮你完成本地项目，直接使用 Codex 会简单很多。
如果你已经在 Codex 里跑通一套稳定工作流，接下来想把这种能力提供给自己的用户，Agents API 才值得继续研究。
08 这次开放真正改变了什么
过去，如果要把一个能持续工作的 Agent 放进产品，开发者往往要自己搭一套 agent loop：管理上下文，调度工具，保存任务状态，再把子 Agent 和执行环境连接起来。
这些工作本身不一定是产品的核心，却决定了 Agent 能不能跨多个步骤稳定推进。
Agents API 现在提供了支撑 Codex 的同一套 harness 和基础设施。开发者可以把精力放到真正属于自己产品的部分：接入什么工具，提供哪些知识，怎样设计工作流，以及用户怎样看到过程和结果。
比如，一个代码维护产品可以让 Agent 处理依赖升级和回归检查；一个数据分析产品可以让 Agent 分派查询、整理证据并生成报告；一个运营系统可以让 Agent 串起资料检索、内容草拟和人工审核。
这些只是通用的产品方向，具体能不能跑通，仍取决于工具、数据、执行环境和验收标准怎么设计。
模型会继续变强，但用户最终关心的依然是同一件事：
任务交出去以后，过程看得见，遇到问题接得上，最后的结果真的能用。
参考资料：
- Introducing the Agents API｜OpenAI
- OpenAI Agents API：创建 Agent
- OpenAI Agents API：创建 Session
- OpenAI Agents API：查看任务过程
最近发现一个好用的 AI 生图工具，分享一下。
写文章、做 PPT、搞 README 配图的时候经常需要快速出一张图，HiAPI.ai 直接输入描述就能出图，也支持生视频，响应很快，出图质量也不错。
新注册用户送 50 张 GPT Image 2 免费额度，不用绑卡，需要快速出图的可以试试。
👉 HiAPI.ai(直达链接：https://www.hiapi.ai/invite/QwfK)
想了解更多可以加我 vx: 257735 聊。
