如果只是把 Codex 当成“更强的代码生成器”其实会错过它最重要的部分。传统 AI 编程的核心流程是用户输入需求 ↓ LLM 推理 ↓ 生成代码 ↓ 结束而今天以 Codex 为代表的 Coding Agent核心已经变成用户提出目标 ↓ 读取项目上下文 ↓ 模型推理 ↓ 调用工具 ↓ 读取工具结果 ↓ 再次推理 ↓ 继续调用工具 ↓ 测试 / 编译 / 检查 ↓ 修改 ↓ 验证 ↓ 完成这个变化看起来只是多了几个步骤但从软件工程角度看它其实意味着 AI 的角色发生了根本变化AI 从“生成代码的人”逐渐变成了“可以操作开发环境的软件工程 Agent”。OpenAI 在 2026 年公开拆解 Codex Agent Loop 时也明确把 Agent Loop 描述为 Codex 中负责协调用户、模型与工具调用的核心逻辑。一个 Turn 内部可以发生多次模型推理和 Tool Call直到模型最终停止调用工具并返回结果。本文就从工程实现的角度拆开看看 Codex 背后的几个关键概念Agent LoopTool CallingContext EngineeringAGENTS.mdShell 与测试反馈MCPSandbox长上下文管理Plan / Execute / VerifyAI Coding 的工程化设计一、先理解一个概念Codex 本质上是 Harness Model很多人谈 Codex 时会把注意力全部放到模型上这个 Codex 模型代码能力多少分但实际工程能力并不能简单等价为模型能力。一个 Coding Agent 更接近Coding Agent LLM Prompt Context Tools Execution Environment Agent Loop Permission System Validation其中真正负责把这些组件串起来的部分通常可以称为Agent Harness可以把它理解为模型外面的一层“操作系统”。LLM 本身可以决定我应该读取 package.json。但 LLM 自己并不能真的打开文件。Harness 会提供一个类似shell(command)这样的 Tool。于是模型可以产生一个 Tool Call{name:shell,arguments:{command:[cat,package.json]}}Harness 执行catpackage.json得到{scripts:{dev:next dev,test:vitest,lint:eslint .}}然后把这个执行结果重新加入 Context。模型再次推理项目使用 Vitest。 下一步应该找到相关测试。于是再次 Tool Calling。这就是为什么真正的 Coding Agent 不是一次推理而是一连串“推理—执行—反馈”的循环。二、Agent Loop 到底是什么我们可以先抽象成一个非常简单的伪代码。whileTrue:responsemodel(context,tools)ifresponse.typefinal:returnresponseifresponse.typetool_call:resultexecute(response.tool,response.arguments)context.append(response)context.append(result)真实系统当然比这个复杂很多。但是核心思想就是Model ↓ 决定下一步 ↓ Tool ↓ Environment ↓ Observation ↓ Model形成循环┌──────────────┐ │ Model │ └──────┬───────┘ ↓ Tool Call ↓ ┌──────────────┐ │ Environment │ └──────┬───────┘ ↓ Result ↓ ┌──────────────┐ │ Model │ └──────────────┘OpenAI 当前公开的 Codex Agent Loop 工作方式也是类似结构模型要么输出最终回答要么请求 Tool CallAgent 执行工具并把结果加入输入再次请求模型。这个过程会持续到模型不再产生工具调用。理解这一点非常重要。因为以后你评价一个 AI 编程工具不能只看一次生成代码准不准。还应该看Agent 能不能发现自己错了这两个能力区别非常大。三、为什么 Agent 比传统 ChatGPT 更适合真实项目举一个非常典型的例子。需求修复订单重复扣库存的问题。如果是传统 ChatGPT你可能需要手动提供Controller Service Repository Database Schema 相关日志但是问题到底在哪里你自己都不一定知道。真实项目可能是POST /orders ↓ OrderController ↓ OrderService.create() ↓ InventoryService.reserve() ↓ PaymentService.pay() ↓ OrderRepository.save()但支付回调还有Payment Callback ↓ PaymentWebhook ↓ OrderService.confirm() ↓ InventoryService.reserve()最终发现创建订单扣一次 支付成功又扣一次 库存重复减少Coding Agent 可以先搜索rgreservesrc/返回src/order/order_service.ts src/payment/webhook.ts src/inventory/inventory_service.ts继续读sed-n1,240psrc/order/order_service.ts再读sed-n1,200psrc/payment/webhook.ts最终得到调用关系。这时候 AI 才真正有机会判断库存扣减逻辑出现了两次调用。这就是 Agent 与“问代码”的最大不同它可以主动寻找缺失的信息。四、Tool Calling 是整个 Agent 系统的关键如果没有 Tool Calling模型的世界只有 Prompt。例如你问这个项目为什么启动失败模型只能根据你复制进去的信息猜。有工具以后它可以自己执行npminstallnpmrun dev获得Error: Cannot find module /lib/auth接下来搜索findsrc-iname*auth*发现src/libs/auth.ts然后检查 importimport{auth}from/lib/auth;发现实际目录是libs修改import{auth}from/libs/auth;重新执行npmrun dev如果通过再继续npmtest最终52 tests passed这就形成了Hypothesis ↓ Action ↓ Evidence ↓ Correction而不是Hypothesis ↓ 直接输出这是 Agent 系统可靠性提升非常重要的一环。五、工具到底是什么从模型角度看Tool 可以理解成一个具有名称、描述和参数 Schema 的函数。例如{name:shell,description:Execute a shell command,parameters:{type:object,properties:{command:{type:array},workdir:{type:string}},required:[command]}}模型看到后就知道我有一个叫 shell 的工具。 它可以运行命令。然后可能生成{name:shell,arguments:{command:[npm,test]}}Codex 当前的 Agent Harness 会把 shell、计划工具、Web 工具以及配置好的 MCP 工具等暴露给模型OpenAI 公布的 Agent Loop 实现中也展示了这些 Tool Definition 如何进入模型请求。因此Tool Calling 本质上是在给 LLM 增加“手”。模型负责思考。Tool 负责行动。六、为什么 Shell 对 Coding Agent 如此重要因为现代软件开发的大多数验证工具本身都可以通过 Shell 调用。比如npmtestpytestgotest./...cargotestmvntestnpmrun lintruff check.mypy appnpmrun typecheck甚至gitdiffgitstatusgreprgfind所以只要给 AgentShell Filesystem它就已经拥有非常强的工程操作能力。七、Compiler 其实是 AI 最好的老师之一例如 Codex 写了一段 TypeScriptconstuser:User{id:1,username:Tom};然后运行npmrun typecheck返回Property email is missing in type这个 Error 实际上就是新的 Context。Agent 下一轮得到User 类型必须包含 email。于是修改constuser:User{id:1,username:Tom,email:tomexample.com};再运行npmrun typecheck通过。这个过程中根本不需要用户介入。所以 AI Coding 很重要的一条原则是尽可能把“正确与否”变成机器可验证的信号。例如TypeScript → Type Check Python → mypy Code Style → Lint 业务逻辑 → Unit Test API → Integration Test 页面 → E2E Test Build → Compiler机器反馈越丰富Agent 越容易纠正错误。八、Test 是 Coding Agent 的 Reward Signal虽然这里不是强化学习意义上的 Reward但从工程工作流看Test 的作用非常接近修改正确 → PASS 修改错误 → FAIL例如需求修改 calculateShipping()。 订单满 99 元免运费。Agent 修改functioncalculateShipping(total:number){if(total99){return0;}return10;}看起来正确。但是项目原来的规则还有偏远地区固定收 20 元。如果测试完整expect(calculateShipping(120,normal)).toBe(0);expect(calculateShipping(120,remote)).toBe(20);Agent 一跑 TestFAILED Expected: 20 Received: 0它立即知道还有一个我之前没考虑到的业务约束。所以Test Suite实际上可以理解为项目内部的一套Executable Specification即可执行的业务规则。九、为什么 AI Coding 时代更应该写测试有一种观点是AI 都能自动写代码了 以后还需要写那么多测试吗实际上很可能恰恰相反。AI 写代码越多自动修改速度 ↑代码变化频率也会↑如果没有自动验证Regression Risk同样会上升。于是未来的软件开发可能形成Agent 生产代码速度 ↑ ↓ Test Coverage 必须 ↑ ↓ 自动验证能力 ↑没有测试的大型项目会越来越不适合 Agent。十、Context Engineering 才是 AI 编程真正的核心很多人还停留在Prompt Engineering比如研究怎么写一句更聪明的 Prompt但在大型 Coding Agent 系统中更重要的问题已经逐渐变成模型现在应该看到什么也就是Context Engineering例如你让 Codex修复登录失败问题。有用 Context 可能包括AuthController AuthService JWT Middleware UserRepository Login Tests 最近 Git Diff Runtime Log无用 Context 可能包括Landing Page CSS Blog Image Upload Analytics Admin Dashboard所以并不是Context 越大越好。而是Relevant Context 越准确越好。十一、一个 Agent 的 Context 可能有哪些组成部分可以抽象成Context │ ├── System Instructions │ ├── Developer Instructions │ ├── User Task │ ├── AGENTS.md │ ├── Repository Files │ ├── Conversation History │ ├── Tool Definitions │ ├── Tool Results │ ├── Environment │ ├── Test Output │ ├── Git Diff │ └── External Documentation而 Codex 当前的实际 Agent Loop 中初始请求本身就会组合模型 Instructions、可用 Tools、用户输入、Sandbox 信息、本地环境信息以及从项目层级聚合的指令内容。因此一个看起来非常简单的修复这个 Bug背后真正进入模型的 Context可能远远不止这五个字。十二、AGENTS.md 为什么重要这就引出了 Codex 工程化使用里非常关键的文件AGENTS.md它的作用可以理解为给 Agent 的项目开发手册。比如# Project Architecture This is a Next.js application. ## Structure src/app Routes and pages. src/components Reusable UI components. src/services Remote API calls. src/server Business logic. src/db Database access. ## Rules - TypeScript only. - Never use any. - Database access must remain in src/db. - Business logic belongs in src/server. - UI components cannot query database directly.以后 Agent 每次进入项目就不需要重新解释数据库代码放哪里 Service 怎么组织 允许不允许 any十三、AGENTS.md 还可以设计成分层规则假设项目project/ │ ├── AGENTS.md │ ├── frontend/ │ └── AGENTS.md │ └── backend/ └── AGENTS.md根目录可以写# Global Rules - Do not add dependencies unless required. - Run tests before finishing. - Never commit secrets.而frontend/AGENTS.md可以专门规定# Frontend - React TypeScript. - Use existing design system. - Do not add inline CSS. - Components must support dark mode.Backend# Backend - Python 3.13. - FastAPI. - Use SQLAlchemy. - Repository layer owns DB access. - Service layer owns business rules.这样 Context 就更加结构化。OpenAI 当前公开的实现说明中也提到Codex 会从$CODEX_HOME以及从项目根目录到当前工作目录的目录层级读取AGENTS.md、AGENTS.override.md等项目说明并把相关内容聚合进用户指令上下文。十四、不要把 AGENTS.md 写成百科全书一个常见错误把整个公司开发规范 全部塞进去。最后AGENTS.md 20,000 行结果并不一定更好。好的 Agent Context 应该追求High Signal Low Noise建议重点保留Architecture Commands Constraints Validation Conventions Forbidden Actions Definition of Done例如# Commands Test: npm test Lint: npm run lint Type Check: npm run typecheck # Constraints Do not: - modify generated files - edit migrations manually - add packages without justification - bypass existing service layer # Before finishing Run: npm test npm run lint npm run typecheck这比几十页描述性文档更实用。十五、Context Window 为什么是 Agent 的核心资源Agent Loop 有一个非常现实的问题每做一次 Tool Call都可能产生新的 Context。例如读取文件 2000 tokens 运行 Test 5000 tokens 读取另外一个文件 3000 tokens 搜索代码 2000 tokens Git Diff 4000 tokens随着 Agent 不断执行Context ↓ 越来越大OpenAI 在解释 Codex Agent Loop 时也指出随着 Conversation 和 Tool Call 不断增加Prompt 会持续增长而任何模型都存在有限 Context Window因此 Context Window Management 本身就是 Agent Harness 的重要职责。十六、为什么“大 Context Window”仍然不能解决所有问题假设一个模型能处理400K tokens很多人第一反应那直接把整个项目全放进去就行了。但这是一个误区。因为问题不只是放不放得下。还有模型能不能快速找到真正重要的信息。比如一个大型 Monorepoapps/ packages/ services/ infra/ docs/ scripts/ tests/几十万甚至上百万行代码。如果当前任务只是修复购物车数量计算错误。理想 Context 应该集中在Cart Product Price Promotion Cart Tests而不是让大量无关信息干扰推理。所以Large Context Window并不等于Perfect Context.十七、Context Compression 为什么重要假设 Agent 已经进行了 100 次 Tool Call。历史可能有第一次调查 第二次调查 错误尝试 A 错误尝试 B 已经失效的日志 旧测试结果 修改前代码 修改后代码如果所有内容永久保留Noise会越来越多。因此成熟的 Agent Harness 一般都需要某种Context Management比如Summarization Compaction Pruning Selective Retrieval把历史从完整操作记录压缩为当前有效事实 剩余任务 关键约束这是长任务能否稳定执行的重要因素。十八、MCP 又是什么随着 Coding Agent 越来越复杂光有本地 Shell 已经不够。Agent 可能还需要访问GitHub Documentation Issue Tracker Database Browser Monitoring Internal API Design System Company Knowledge Base这时候就需要一种标准化 Tool 接入方式。其中一个越来越重要的协议就是MCP Model Context Protocol你可以简单理解为给 AI Agent 连接外部工具和数据源的一种统一接口。Codex 当前的工具体系可以把用户配置的 MCP Server 暴露为模型可调用工具OpenAI 的 Codex Agent Loop 公开实现中也展示了 MCP Tool 如何与 Shell 等工具一起进入 Tool Definitions。十九、MCP 可以解决什么问题假设开发者正在处理 GitHub IssueIssue #1821 支付接口偶尔返回 500。传统流程浏览器打开 GitHub ↓ 复制 Issue ↓ ChatGPT ↓ 复制日志 ↓ ChatGPT ↓ 打开文档 ↓ 复制文档 ↓ ChatGPT如果这些系统都能作为 Agent ToolCodex │ ├── GitHub Tool ├── Logs Tool ├── Docs Tool ├── Database Tool └── Shell那么 Agent 可以读取 Issue ↓ 搜索代码 ↓ 查询错误日志 ↓ 查看 API 文档 ↓ 修改项目 ↓ 运行 Test整个 Context 流动会自然很多。二十、MCP 的真正价值不是“多一个工具”它真正有意思的地方是Tool Interface Standardization以前每接一个系统GitHub Adapter Slack Adapter Database Adapter Browser Adapter Docs Adapter每一个都自己设计。未来通过统一 Tool ProtocolAgent │ ├─ MCP Server A ├─ MCP Server B ├─ MCP Server C └─ MCP Server DAgent 只需要理解Tool Name Description Arguments Result就可以调用。这会让 AI Agent 更像一个真正的平台。二十一、但 MCP 有一个非常重要的安全问题很多人会把Agent MCP理解成Agent 能力无限扩展。技术上确实如此。但与此同时Attack Surface也扩大了。例如某 MCP Tool 可以删除数据库 发送邮件 修改生产配置 创建 GitHub PR 执行部署那么 Agent 的一个误判就可能产生真实影响。特别值得注意的是OpenAI 当前关于 Codex Agent Loop 的公开说明明确指出Codex 自己提供的 Shell Tool 会受到其 Sandbox 权限描述约束而其他来源的工具例如 MCP Server 提供的工具并不自动继承 Codex Shell Sandbox需要工具自身执行相应 Guardrail。这一点非常重要。二十二、所以 Agent 权限设计应该遵循最小权限原则推荐Least Privilege例如开发 Agent 默认Read Repository YES Write Workspace YES Run Tests YES Read Documentation YES Delete Production DB NO Deploy Production NO Send Email NO涉及高风险动作Production Deploy Database Migration Delete Resource Publish Package Send Message Merge PR最好进入Human Approval流程。例如Agent ↓ 准备 Migration ↓ 运行测试 ↓ 生成执行计划 ↓ 等待人工批准 ↓ Production而不是Agent ↓ 直接执行 Production Migration二十三、Sandbox 到底是什么Sandbox 可以理解为Agent 的活动边界。例如Agent 可以 读项目目录 修改 workspace 运行 npm test但不能 访问 ~/Documents 读取 SSH Key 修改系统配置 访问其他项目这也是为什么 Coding Agent 的安全性不能只依靠Prompt 请不要做危险操作。真正可靠的限制应该落到Permission Layer即使模型想执行rm-rf/执行环境也应该直接拒绝。二十四、Prompt Safety 不等于 System Safety这是 Agent 系统设计中非常重要的一点。错误设计System Prompt: Never delete important files.然后 Agent 实际权限Full Root Access这并不安全。更合理的设计System Prompt Sandbox Permission Tool Schema Approval Audit Log多层防护。即Defense in Depth二十五、Plan Tool 为什么开始变重要复杂任务往往包含十几个步骤。例如把 Express 项目迁移到 Fastify。如果 Agent 直接开始改File A ↓ File B ↓ File C ↓ 突然发现 Architecture 不兼容很容易越改越乱。所以更稳定的方式是Explore ↓ Plan ↓ Execute ↓ Verify例如Plan 1. Identify Express bootstrap. 2. Locate middleware. 3. Map routes. 4. Identify error handler. 5. Replace server bootstrap. 6. Migrate middleware. 7. Run unit tests. 8. Run integration tests. 9. Review diff.当前 Codex 的 Agent Harness 也存在独立的 Plan Tool用来维护任务计划状态。这说明 Agent Engineering 已经不仅是让模型思考。还在加入显式任务状态管理。二十六、一个好的 Codex Workflow 应该是什么样建议复杂任务不要直接Implement everything.而采用Explore ↓ Plan ↓ Implement ↓ Test ↓ Review例如第一步Explore不要修改代码。 先调查当前 Authentication 系统。 找出 1. Login API 2. JWT 生成 3. Refresh Token 4. Middleware 5. User Session 6. Auth Tests 最后输出调用链。第二步Plan现在要增加 单设备登录限制。 请先给实现计划。 要求 - 不改变现有 Login API response。 - 保持 Refresh Token 兼容。 - 尽量减少 Schema 修改。第三步Implement按照刚才计划实现。 不要修改无关模块。第四步Verify运行 pytest tests/auth ruff check . mypy app第五步Review重新检查本次 Git Diff。 重点寻找 - Race condition - Session bypass - Token replay - Missing test - Backward compatibility 如果发现问题直接修复后重新测试。这已经是一套相当完整的软件工程 Agent Loop。二十七、Review Agent 是一个非常值得使用的模式可以把 Coding Agent 分成两个角色Agent A Developer Agent B ReviewerDeveloper完成需求。Reviewer只看 Diff。 寻找 Bug Security Regression Edge Case Missing Test例如Developer Agent ↓ Diff ↓ Reviewer Agent ↓ Findings ↓ Developer Agent ↓ Fix这样可以减少自己证明自己正确造成的偏差。二十八、Git Diff 是非常高价值的 Context在 Review 阶段不一定要把整个仓库再次丢给模型。很多时候可以先给gitdiff因为它直接告诉 Agent这次到底改变了什么。例如- if (!user) { if (!user user.active) {Reviewer 很容易发现这里可能存在 Null Dereference。所以 Review Prompt 可以非常简单Review 当前 git diff。 不要重新实现功能。 只寻找 1. Logic bug 2. Security issue 3. Regression 4. Missing error handling 5. Missing tests 按严重程度排序。这种 Prompt 通常非常有效。二十九、Agent 最怕什么任务一个典型坏 Prompt优化一下这个项目。为什么差因为搜索空间接近无限性能 架构 UI 数据库 代码规范 安全 依赖 测试 SEOAgent 不知道Optimization Objective是什么。更好的 Prompt优化 GET /api/products 的响应时间。 目前 P95 为 1.8 秒。 目标 P95 600ms。 约束 1. 不修改 API Response。 2. 不增加 Redis。 3. 不修改数据库 Schema。 4. 优先检查 N1 Query。 完成后提供 benchmark 对比。这就是Goal Metric Constraints Validation三十、未来 Prompt 的最佳结构可能不是一句话而是一份 Task Spec例如# Goal 修复库存超卖。 # Current Behavior 两个并发订单可能同时读取 stock1 最终都成功创建订单。 # Expected Behavior 库存为 1 时只能有一个订单成功。 # Constraints - PostgreSQL. - 不引入 Redis Lock. - 保持现有 API 格式. - 不增加外部服务. # Investigation 先检查 - InventoryService - OrderService - Transaction boundary - DB isolation - Inventory tests # Validation 增加并发测试。 运行 pytest tests/inventory pytest tests/order # Definition of Done - 并发情况下不存在超卖 - 原测试全部通过 - 新增 Regression Test这样 Agent 的成功率通常比帮我修一下库存超卖。高很多。三十一、这其实已经不是 Prompt Engineering它更接近Software Specification Engineering也就是说程序员未来可能越来越多地做定义问题 定义约束 定义接口 定义测试 定义完成标准Agent 负责搜索 实现 运行 修改 验证人的核心价值逐渐向Intent Architecture Judgment Verification迁移。三十二、Codex ChatGPT 的工程价值到底在哪里很多人讨论 ChatGPT Plus、Pro 和 Codex 时很容易只看今天哪个模型 Benchmark 第一但真实项目里的最终效果我认为更接近AI Engineering Effectiveness Model Capability × Context Quality × Tool Quality × Feedback Quality × Repository Quality × Task Specification × Validation Quality任何一项接近 0最终效果都会明显下降。例如模型非常强Model 10但是没有测试 没有类型 没有文档 需求模糊 项目目录混乱Agent 仍然可能频繁犯错。相反一个拥有清晰 Architecture 完整 Test Type System AGENTS.md 标准化 Commands 良好 Git History的仓库会非常适合 Coding Agent。三十三、未来最有价值的代码库是 Agent-Friendly Repository以前README主要解决新人如何理解项目。以后README AGENTS.md Tests Types Architecture Docs还会解决AI 如何理解项目。一个理想 AI-Friendly Repository 可能是project/ │ ├── AGENTS.md │ ├── README.md │ ├── package.json │ ├── docs/ │ ├── architecture.md │ ├── api.md │ └── database.md │ ├── src/ │ ├── tests/ │ ├── scripts/ │ └── .github/它明确告诉 Agent项目是什么 代码在哪里 哪些不能改 如何验证 什么叫完成三十四、未来开发者可能越来越像“Agent Tech Lead”以前程序员一天70% 写代码 20% Debug 10% 设计以后可能变成20% 自己写代码 25% 设计 Task 20% Review Agent 15% Architecture 10% Debug 10% 验证当然这只是一个抽象示例。真正变化的是开发者逐渐从Implementation Bottleneck变成Decision Bottleneck也就是说AI 可以同时写很多代码。但最后仍然需要有人回答这样设计对不对 这个 Trade-off 能不能接受 这个 Bug 是否真的解决 这个权限是否安全 这个数据结构能不能维护五年三十五、结语Codex 真正改变的不是写代码速度而是 Software Engineering Loop传统 ChatGPT 编程Human ↓ Prompt ↓ LLM ↓ Code而 Agent CodingHuman ↓ Intent ↓ Agent Harness ↓ Model ↓ Tool ↓ Environment ↓ Feedback ↓ Model ↓ Test ↓ Review ↓ Human所以真正值得研究的已经不只是LLM 会不会写代码而是模型如何获得正确 Context 模型有哪些 Tools Tool 权限如何控制 环境如何反馈 失败以后如何继续 如何管理长 Context 如何验证结果 什么时候交还给 Human这些问题加在一起才组成今天真正意义上的Agentic Software Engineering如果说第一阶段的 ChatGPT 是AI 能不能帮我写代码那么 Codex 所代表的下一阶段正在变成AI 能不能进入软件工程闭环并持续完成一个可以验证的任务从 Agent Loop、Tool Calling到 AGENTS.md、MCP、Sandbox再到自动测试和 Context Engineering本质上都在解决同一个问题如何让 LLM 从“会回答代码问题”变成“能够可靠地在真实工程环境里工作”。这可能才是未来几年 AI 编程真正值得关注的技术主线。