如果只是把 Codex 当成“更强的代码生成器”，其实会错过它最重要的部分。

传统 AI 编程的核心流程是：

用户输入需求
    ↓
LLM 推理
    ↓
生成代码
    ↓
结束

而今天以 Codex 为代表的 Coding Agent，核心已经变成：

用户提出目标
    ↓
读取项目上下文
    ↓
模型推理
    ↓
调用工具
    ↓
读取工具结果
    ↓
再次推理
    ↓
继续调用工具
    ↓
测试 / 编译 / 检查
    ↓
修改
    ↓
验证
    ↓
完成

这个变化看起来只是多了几个步骤，但从软件工程角度看，它其实意味着 AI 的角色发生了根本变化：

AI 从“生成代码的人”，逐渐变成了“可以操作开发环境的软件工程 Agent”。

OpenAI 在 2026 年公开拆解 Codex Agent Loop 时，也明确把 Agent Loop 描述为 Codex 中负责协调 用户、模型与工具调用 的核心逻辑。一个 Turn 内部可以发生多次模型推理和 Tool Call，直到模型最终停止调用工具并返回结果。

本文就从工程实现的角度，拆开看看 Codex 背后的几个关键概念：

• Agent Loop
• Tool Calling
• Context Engineering
• AGENTS.md
• Shell 与测试反馈
• MCP
• Sandbox
• 长上下文管理
• Plan / Execute / Verify
• AI 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 执行：

cat package.json

得到：

{
  "scripts": {
    "dev": "next dev",
    "test": "vitest",
    "lint": "eslint ."
  }
}

然后把这个执行结果重新加入 Context。

模型再次推理：

项目使用 Vitest。

下一步应该找到相关测试。

于是再次 Tool Calling。

这就是为什么：

真正的 Coding Agent 不是一次推理，而是一连串“推理—执行—反馈”的循环。

---

二、Agent Loop 到底是什么？

我们可以先抽象成一个非常简单的伪代码。

while True:

    response = model(context, tools)

    if response.type == "final":
        return response

    if response.type == "tool_call":

        result = execute(
            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 Call；Agent 执行工具并把结果加入输入，再次请求模型。这个过程会持续到模型不再产生工具调用。

理解这一点非常重要。

因为以后你评价一个 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 可以先搜索：

rg "reserve" src/

返回：

src/order/order_service.ts
src/payment/webhook.ts
src/inventory/inventory_service.ts

继续读：

sed -n '1,240p' src/order/order_service.ts

再读：

sed -n '1,200p' src/payment/webhook.ts

最终得到调用关系。

这时候 AI 才真正有机会判断：

库存扣减逻辑出现了两次调用。

这就是 Agent 与“问代码”的最大不同：

它可以主动寻找缺失的信息。

---

四、Tool Calling 是整个 Agent 系统的关键

如果没有 Tool Calling，模型的世界只有 Prompt。

例如你问：

这个项目为什么启动失败？

模型只能根据你复制进去的信息猜。

有工具以后，它可以自己执行：

npm install
npm run dev

获得：

Error: Cannot find module '@/lib/auth'

接下来搜索：

find src -iname "*auth*"

发现：

src/libs/auth.ts

然后检查 import：

import { auth } from "@/lib/auth";

发现实际目录是：

libs

修改：

import { auth } from "@/libs/auth";

重新执行：

npm run dev

如果通过，再继续：

npm test

最终：

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 调用。

比如：

npm test

pytest

go test ./...

cargo test

mvn test

npm run lint

ruff check .

mypy app

npm run typecheck

甚至：

git diff

git status

grep

rg

find

所以只要给 Agent：

Shell
+
Filesystem

它就已经拥有非常强的工程操作能力。

---

七、Compiler 其实是 AI 最好的老师之一

例如 Codex 写了一段 TypeScript：

const user: User = {
  id: 1,
  username: "Tom"
};

然后运行：

npm run typecheck

返回：

Property 'email' is missing in type

这个 Error 实际上就是新的 Context。

Agent 下一轮得到：

User 类型必须包含 email。

于是修改：

const user: User = {
  id: 1,
  username: "Tom",
  email: "tom@example.com"
};

再运行：

npm run 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 修改：

function calculateShipping(total: number) {
  if (total >= 99) {
    return 0;
  }

  return 10;
}

看起来正确。

但是项目原来的规则还有：

偏远地区固定收 20 元。

如果测试完整：

expect(calculateShipping(120, "normal")).toBe(0);

expect(
  calculateShipping(120, "remote")
).toBe(20);

Agent 一跑 Test：

FAILED
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

很多人第一反应：

那直接把整个项目全放进去就行了。

但这是一个误区。

因为问题不只是：

放不放得下。

还有：

模型能不能快速找到真正重要的信息。

比如一个大型 Monorepo：

apps/
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 Issue：

Issue #1821

支付接口偶尔返回 500。

传统流程：

浏览器打开 GitHub
↓
复制 Issue
↓
ChatGPT
↓
复制日志
↓
ChatGPT
↓
打开文档
↓
复制文档
↓
ChatGPT

如果这些系统都能作为 Agent Tool：

Codex
  │
  ├── 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 Protocol：

Agent
 │
 ├─ MCP Server A
 ├─ MCP Server B
 ├─ MCP Server C
 └─ MCP Server D

Agent 只需要理解：

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
Reviewer

Developer：

完成需求。

Reviewer：

只看 Diff。

寻找：

Bug

Security

Regression

Edge Case

Missing Test

例如：

Developer Agent
      ↓
     Diff
      ↓
Reviewer Agent
      ↓
 Findings
      ↓
Developer Agent
      ↓
    Fix

这样可以减少：

自己证明自己正确

造成的偏差。

---

二十八、Git Diff 是非常高价值的 Context

在 Review 阶段，不一定要把整个仓库再次丢给模型。

很多时候可以先给：

git diff

因为它直接告诉 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？

数据库？

代码规范？

安全？

依赖？

测试？

SEO？

Agent 不知道：

Optimization Objective

是什么。

更好的 Prompt：

优化 GET /api/products 的响应时间。

目前 P95 为 1.8 秒。

目标：

P95 < 600ms。

约束：

1. 不修改 API Response。
2. 不增加 Redis。
3. 不修改数据库 Schema。
4. 优先检查 N+1 Query。

完成后提供 benchmark 对比。

这就是：

Goal
+
Metric
+
Constraints
+
Validation

---

三十、未来 Prompt 的最佳结构可能不是一句话，而是一份 Task Spec

例如：

# Goal

修复库存超卖。

# Current Behavior

两个并发订单可能同时读取 stock=1，
最终都成功创建订单。

# 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 Coding：

Human
↓
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 编程真正值得关注的技术主线。