过去的软件系统，大多是围绕“请求”构建的。

用户点击按钮，前端发起请求，后端执行逻辑，数据库返回结果，系统完成响应。

这种模式可以被抽象为：

Request
  ↓
Controller
  ↓
Service
  ↓
Database
  ↓
Response

它是一种典型的请求驱动架构。

系统只有在收到明确指令时才开始工作。

但随着 ChatGPT Plus、ChatGPT Pro 与 Codex 逐渐进入开发流程，软件系统正在出现另一种趋势：

AI 不再只是响应一次请求，而是开始围绕事件、状态与目标持续推进任务。

这意味着，AI Agent 与传统软件的结合，不应该只停留在聊天窗口或代码生成接口。

更值得讨论的方向，是如何把 ChatGPT Pro、Plus 与 Codex 放入事件驱动架构中，使 AI 能够感知系统变化、判断任务优先级、生成执行计划，并在边界内完成工程操作。

这并不是简单增加一个模型接口。

它涉及事件总线、状态机、任务编排、幂等控制、权限治理、可观测性和人工审批。

从这个角度看，ChatGPT Plus、ChatGPT Pro 与 Codex 正在推动软件架构从“请求驱动”走向“事件驱动的智能执行系统”。

---

一、传统请求驱动架构的局限

请求驱动架构非常适合确定性业务。

例如：

用户提交订单
系统创建订单
系统返回订单编号

对应代码可能是：

async function createOrder(
  input: CreateOrderInput
): Promise<Order> {
  validateOrderInput(input)

  const order = await orderRepository.create(input)

  return order
}

这种结构具有几个优点：

输入明确
执行路径明确
输出明确
错误边界明确

但它并不擅长处理持续变化的复杂任务。

例如：

项目测试失败后自动分析原因
依赖库更新后判断兼容风险
生产指标异常后生成排查计划
代码仓库变化后检查架构约束
用户反馈积累后识别高频问题

这些问题没有一个单一请求可以完整描述。

它们更像事件：

测试失败事件
依赖更新事件
性能异常事件
代码提交事件
用户反馈事件

系统需要在事件发生后，根据上下文决定下一步。

这已经不再是普通函数调用，而是任务协调。

---

二、事件驱动系统的中心是状态变化

在事件驱动架构中，系统关注的不是“谁调用了哪个函数”，而是“系统发生了什么变化”。

例如：

OrderCreated
PaymentCompleted
InventoryReserved
OrderCancelled
RefundCompleted

每个事件都描述一个已经发生的事实。

事件不会告诉系统所有后续动作，而是由其他组件订阅事件并做出响应。

OrderCancelled
      ↓
Inventory Service：恢复库存
Payment Service：判断是否退款
Notification Service：发送通知
Analytics Service：记录取消数据

可以定义一个基础事件结构：

type DomainEvent<TPayload> = {
  id: string
  type: string
  occurredAt: string
  aggregateId: string
  payload: TPayload
  metadata: {
    correlationId: string
    causationId?: string
    source: string
  }
}

例如：

type OrderCancelledPayload = {
  orderId: string
  userId: string
  reason: string
}

const event: DomainEvent<OrderCancelledPayload> = {
  id: "evt-1001",
  type: "ORDER_CANCELLED",
  occurredAt: new Date().toISOString(),
  aggregateId: "order-9001",
  payload: {
    orderId: "order-9001",
    userId: "user-101",
    reason: "USER_REQUEST"
  },
  metadata: {
    correlationId: "flow-88",
    source: "order-service"
  }
}

这种结构让系统可以围绕状态变化协作。

而 AI Agent 的加入，会让事件处理进一步升级。

---

三、ChatGPT Plus 可以成为事件语义归一化层

系统事件通常来自不同来源：

代码仓库
测试平台
监控平台
用户反馈
项目管理系统
日志系统
CI/CD

这些事件格式不同、语义不同、重要程度不同。

例如：

GitHub Push Event
Unit Test Failed Event
Production Error Event
Customer Complaint Event
Dependency Vulnerability Event

如果直接把所有事件交给 ChatGPT Pro 或 Codex，系统会产生大量噪声。

ChatGPT Plus 可以承担第一层语义归一化。

Raw Events
   ↓
ChatGPT Plus
   ↓
Normalized Engineering Events

例如，多个原始事件：

测试失败：UserServiceTest
日志异常：NullPointerException
用户反馈：修改昵称后页面报错

可以被归一化为：

event:
  type: USER_PROFILE_UPDATE_FAILURE

  confirmed_facts:
    - 用户修改昵称后出现异常
    - UserServiceTest 当前失败
    - 错误涉及空值处理

  affected_area:
    - user-profile
    - user-service

  severity:
    level: medium

  unknowns:
    - 是否影响所有用户
    - 是否与旧数据有关

这一步不是解决问题。

而是把不同来源的信号转成统一工程语义。

---

四、ChatGPT Pro 可以成为事件推理与任务规划器

当事件被归一化后，ChatGPT Pro 可以进一步判断：

这是一个真实故障还是偶发噪声？
是否需要立即处理？
哪些模块可能受影响？
应该先分析还是直接修复？
是否需要 Codex 介入？
是否需要人工审批？

因此，ChatGPT Pro 更适合位于事件协调层。

Normalized Event
      ↓
ChatGPT Pro Reasoning
      ↓
Task Plan
      ↓
Codex / Test Agent / Human

可以定义一个任务规划结果：

type AgentTaskPlan = {
  eventId: string
  objective: string
  priority: "low" | "medium" | "high" | "critical"
  tasks: Array<{
    id: string
    agent: "CODEX" | "TEST" | "REVIEW" | "HUMAN"
    action: string
    dependsOn: string[]
    scope: string[]
  }>
  constraints: string[]
  approvalRequired: boolean
}

示例：

{
  "eventId": "evt-1001",
  "objective": "定位并修复用户昵称为空时的异常",
  "priority": "medium",
  "tasks": [
    {
      "id": "task-1",
      "agent": "CODEX",
      "action": "只分析 user profile 模块，不修改代码",
      "dependsOn": [],
      "scope": [
        "src/user/profile.service.ts",
        "tests/user/profile.test.ts"
      ]
    },
    {
      "id": "task-2",
      "agent": "TEST",
      "action": "生成昵称为空和 null 的失败场景",
      "dependsOn": [
        "task-1"
      ],
      "scope": [
        "tests/user/profile.test.ts"
      ]
    }
  ],
  "constraints": [
    "不修改数据库结构",
    "不改变接口返回格式",
    "不影响登录模块"
  ],
  "approvalRequired": false
}

这就是事件到任务的转换。

---

五、Codex 是事件驱动架构中的受控执行者

Codex 在这个系统中不应该负责决定任务是否值得执行。

它更适合承担具体工程任务。

Event
  ↓
ChatGPT Plus：整理语义
  ↓
ChatGPT Pro：规划任务
  ↓
Codex：执行代码层任务

Codex 接收到的不是原始事件，而是经过约束的工程任务。

codex_task:
  trigger_event:
    type: USER_PROFILE_UPDATE_FAILURE

  goal:
    - 修复 nickname 为 null 时的保存异常

  allowed_files:
    - src/user/profile.service.ts
    - tests/user/profile.test.ts

  forbidden_files:
    - src/auth/*
    - database/migrations/*
    - src/payment/*

  constraints:
    - 不改变接口返回字段
    - 不引入新依赖
    - 保持旧用户数据兼容

  verification:
    - 原测试必须通过
    - 新增 null 测试
    - 新增空字符串测试

  stop_conditions:
    - 需要修改数据库
    - 需要修改认证模块
    - 影响文件超过 3 个

这里最重要的是：

事件可以触发 Codex，但不能直接授权 Codex 无限执行。

事件只是信号。

任务规格才是执行协议。

---

六、事件驱动 AI 系统必须有状态机

一个事件触发后，任务不会立即完成。

它会经历多个状态：

RECEIVED
  ↓
NORMALIZED
  ↓
ANALYZED
  ↓
PLANNED
  ↓
APPROVED
  ↓
EXECUTING
  ↓
VERIFYING
  ↓
REVIEWING
  ↓
COMPLETED

异常状态包括：

CONTEXT_MISSING
SCOPE_VIOLATION
VERIFICATION_FAILED
HUMAN_REJECTED
BASELINE_CHANGED

可以定义：

type AIEventTaskState =
  | "RECEIVED"
  | "NORMALIZED"
  | "ANALYZED"
  | "PLANNED"
  | "APPROVED"
  | "EXECUTING"
  | "VERIFYING"
  | "REVIEWING"
  | "COMPLETED"
  | "CONTEXT_MISSING"
  | "SCOPE_VIOLATION"
  | "VERIFICATION_FAILED"
  | "HUMAN_REJECTED"
  | "BASELINE_CHANGED"

状态转换必须受到控制。

const allowedTransitions: Record<
  AIEventTaskState,
  AIEventTaskState[]
> = {
  RECEIVED: [
    "NORMALIZED"
  ],

  NORMALIZED: [
    "ANALYZED",
    "CONTEXT_MISSING"
  ],

  ANALYZED: [
    "PLANNED"
  ],

  PLANNED: [
    "APPROVED",
    "HUMAN_REJECTED"
  ],

  APPROVED: [
    "EXECUTING",
    "BASELINE_CHANGED"
  ],

  EXECUTING: [
    "VERIFYING",
    "SCOPE_VIOLATION"
  ],

  VERIFYING: [
    "REVIEWING",
    "VERIFICATION_FAILED"
  ],

  REVIEWING: [
    "COMPLETED",
    "HUMAN_REJECTED"
  ],

  COMPLETED: [],
  CONTEXT_MISSING: [],
  SCOPE_VIOLATION: [],
  VERIFICATION_FAILED: [],
  HUMAN_REJECTED: [],
  BASELINE_CHANGED: []
}

这可以防止 AI Agent 跳过关键步骤。

---

七、事件驱动 AI 必须保证幂等性

事件系统中，事件可能重复投递。

这是分布式系统的常见现象。

例如：

同一个测试失败事件被发送两次
同一个代码提交事件被重复消费
同一个监控告警被多次触发

如果 Codex 每收到一次事件都重新修改代码，就可能造成重复变更。

因此，事件处理必须幂等。

type ProcessedEvent = {
  eventId: string
  taskId: string
  status: "PROCESSING" | "COMPLETED" | "FAILED"
}

处理前检查：

async function handleEngineeringEvent(
  event: DomainEvent<unknown>
) {
  const existing =
    await eventRepository.findByEventId(
      event.id
    )

  if (existing?.status === "COMPLETED") {
    return {
      status: "IGNORED",
      reason: "EVENT_ALREADY_PROCESSED"
    }
  }

  await eventRepository.markProcessing(
    event.id
  )

  const result =
    await processEvent(event)

  await eventRepository.markCompleted(
    event.id,
    result.taskId
  )

  return result
}

AI Agent 系统不能假设每个事件只会出现一次。

---

八、事件溯源可以保存 AI 工程决策历史

传统事件溯源不是只保存当前状态，而是保存所有状态变化事件。

例如：

OrderCreated
PaymentCompleted
OrderShipped
OrderCancelled

通过重放事件，可以恢复当前状态。

AI 工程也可以使用类似结构。

EngineeringTaskCreated
ContextNormalized
PlanGenerated
HumanApproved
CodexStarted
FileModified
TestFailed
PatchRevised
HumanMerged

可以定义：

type EngineeringAgentEvent =
  | {
      type: "TASK_CREATED"
      taskId: string
      goal: string
    }
  | {
      type: "CONTEXT_NORMALIZED"
      taskId: string
      contextVersion: string
    }
  | {
      type: "PLAN_GENERATED"
      taskId: string
      planVersion: string
    }
  | {
      type: "CODEX_EXECUTION_STARTED"
      taskId: string
      baselineCommit: string
    }
  | {
      type: "FILE_MODIFIED"
      taskId: string
      file: string
    }
  | {
      type: "VERIFICATION_FAILED"
      taskId: string
      reason: string
    }
  | {
      type: "TASK_COMPLETED"
      taskId: string
      commitId: string
    }

这样可以追踪：

任务为什么被创建？
ChatGPT Pro 当时如何规划？
Codex 基于哪个代码版本执行？
测试为什么失败？
最终谁批准了合并？

事件历史会成为 AI 工程审计基础。

---

九、事件总线不能成为无限自动化通道

如果所有事件都可以自动触发 Agent，系统可能迅速失控。

例如：

每次测试失败都启动 Codex
每次日志异常都创建修复任务
每次用户投诉都修改代码

这会导致任务风暴。

因此，事件需要经过过滤、聚合和优先级判断。

Raw Events
  ↓
Filter
  ↓
Deduplication
  ↓
Aggregation
  ↓
Priority Classification
  ↓
Agent Planning

例如，连续出现 100 条相同错误日志，不应该创建 100 个 Codex 任务。

应该聚合为：

aggregated_event:
  type: DATABASE_TIMEOUT_SPIKE

  count: 100

  time_window:
    minutes: 5

  affected_services:
    - order-service
    - payment-service

  severity:
    level: high

之后由 ChatGPT Pro 判断是否需要执行工程任务。

---

十、ChatGPT Pro 应该区分事实、推测和建议

事件分析中最大的风险，是把推测当成事实。

例如：

事实：
订单接口延迟增加。

推测：
可能与数据库连接池有关。

建议：
检查连接池使用情况。

这三者必须分开。

可以定义：

type EventAnalysis = {
  facts: EvidenceItem[]
  hypotheses: Hypothesis[]
  recommendations: Recommendation[]
}

例如：

{
  "facts": [
    {
      "statement": "订单接口 P95 延迟从 200ms 上升到 1200ms",
      "source": "monitoring"
    }
  ],
  "hypotheses": [
    {
      "statement": "可能与数据库连接池耗尽有关",
      "confidence": 0.62
    }
  ],
  "recommendations": [
    {
      "action": "检查连接池等待时间和活跃连接数"
    }
  ]
}

ChatGPT Pro 可以生成假设，但不能把假设直接当成 Codex 修改依据。

Codex 应该优先执行诊断任务，而不是直接改代码。

---

十一、事件驱动 AI 要支持“诊断任务”和“修改任务”分离

面对异常事件，第一步不应该总是修改代码。

应先诊断。

异常事件
  ↓
诊断任务
  ↓
确认原因
  ↓
修复任务

可以定义两种任务：

type AgentTask =
  | {
      type: "DIAGNOSTIC"
      readOnly: true
      objective: string
      allowedResources: string[]
    }
  | {
      type: "MODIFICATION"
      readOnly: false
      objective: string
      allowedFiles: string[]
      requiredVerification: string[]
    }

诊断任务示例：

task:
  type: DIAGNOSTIC

  objective:
    - 分析订单接口延迟增加原因

  read_only:
    - true

  allowed_resources:
    - application logs
    - database metrics
    - order-service source
    - recent commits

  output:
    - confirmed facts
    - likely causes
    - missing evidence
    - recommended next action

只有诊断结果足够明确，才生成修改任务。

这能避免 Codex 基于错误假设直接改代码。

---

十二、Codex 修改代码前必须验证仓库基线

事件发生时，代码仓库可能处于某个版本。

但当 Codex 真正开始执行时，仓库可能已经变化。

例如：

事件生成时：
Commit A

ChatGPT Pro 规划时：
Commit A

Codex 执行时：
Commit B

此时任务可能已经过期。

任务必须绑定仓库基线：

type VersionedCodexTask = {
  taskId: string
  baselineCommit: string
  contextVersion: string
  planVersion: string
  allowedFiles: string[]
}

执行前检查：

async function verifyTaskBaseline(
  task: VersionedCodexTask
) {
  const currentCommit =
    await git.getCurrentCommit()

  if (
    currentCommit !== task.baselineCommit
  ) {
    return {
      valid: false,
      reason: "BASELINE_CHANGED"
    }
  }

  return {
    valid: true
  }
}

如果基线变化，应重新规划。

---

十三、事件优先级不应该只由模型决定

ChatGPT Pro 可以分析事件严重程度，但最终优先级不应该完全由模型自由判断。

应结合确定性规则。

Priority
=
Rule-based Severity
+
Business Impact
+
AI Analysis

例如：

function calculatePriority(
  event: NormalizedEvent,
  analysis: EventAnalysis
): Priority {
  if (
    event.type === "SECURITY_BREACH"
  ) {
    return "CRITICAL"
  }

  if (
    event.affectedUsers > 10000
  ) {
    return "HIGH"
  }

  if (
    analysis.confidence < 0.5
  ) {
    return "REVIEW_REQUIRED"
  }

  return "MEDIUM"
}

安全、支付、权限、数据丢失等事件，可以由规则直接提升优先级。

AI 负责补充分析，而不是单独控制优先级。

---

十四、事件驱动 AI 系统需要背压机制

当事件产生速度超过 Agent 处理速度时，系统会积压。

Event Production Rate
>
Agent Processing Rate

这会导致：

任务堆积
上下文过期
重复分析
资源耗尽
高优先级任务被阻塞

因此需要背压机制。

可以按优先级建立队列：

Critical Queue
High Queue
Medium Queue
Low Queue

调度器优先处理高风险事件。

type TaskQueue = {
  critical: AgentTask[]
  high: AgentTask[]
  medium: AgentTask[]
  low: AgentTask[]
}

还可以设置任务过期时间：

type ExpiringAgentTask = {
  taskId: string
  expiresAt: string
  baselineCommit: string
}

如果任务已经过期，应丢弃或重新分析。

---

十五、人工审批应该根据风险动态插入

不是所有任务都需要相同审批强度。

低风险任务可以自动执行并等待事后审查。

中风险任务可以先审批计划。

高风险任务必须人工批准每个关键步骤。

approval_policy:
  low:
    before_execution: false
    before_merge: true

  medium:
    before_execution: true
    before_merge: true

  high:
    before_execution: true
    before_write: true
    before_merge: true

例如：

低风险：
修正文档
补充注释
增加测试

中风险：
修复业务 bug
调整缓存逻辑
小范围重构

高风险：
修改权限
修改支付
数据库迁移
生产部署

ChatGPT Pro 可以评估风险，但审批规则应由系统策略控制。

---

十六、事件驱动 Agent 的可观测性

传统事件系统需要观察：

Event Throughput
Consumer Lag
Failure Rate
Retry Count
Dead Letter Queue

AI Agent 系统还需要观察：

Planning Latency
Context Conflict Rate
Codex Scope Violation Rate
Verification Failure Rate
Human Rejection Rate
Task Drift Rate

可以定义指标：

type AgentEventMetrics = {
  receivedEvents: number
  normalizedEvents: number
  createdTasks: number
  planningLatencyMs: number
  scopeViolationRate: number
  verificationFailureRate: number
  humanRejectionRate: number
  averageCompletionTimeMs: number
}

这些指标可以帮助判断 AI 工作流是否真正可靠。

---

十七、死信队列可以保存无法处理的 AI 任务

传统消息系统使用 Dead Letter Queue 保存处理失败的消息。

AI Agent 系统也需要类似机制。

无法自动处理的任务可以进入：

Agent Dead Letter Queue

原因包括：

上下文冲突
权限不足
仓库版本变化
连续验证失败
任务范围无法确定
需要业务决策

死信任务结构：

type AgentDeadLetterTask = {
  taskId: string
  originalEvent: string
  failureReason: string
  retryCount: number
  lastAttemptAt: string
  requiredHumanAction: string
}

这比无限重试更安全。

---

十八、一个完整的事件驱动 AI 工程架构

可以把整个系统分成六层：

Event-driven AI Engineering Platform

├── Event Ingestion Layer
│   ├── Git Events
│   ├── CI Events
│   ├── Monitoring Events
│   ├── User Feedback Events
│   └── Security Events
│
├── Normalization Layer
│   └── ChatGPT Plus
│
├── Reasoning Layer
│   └── ChatGPT Pro
│
├── Coordination Layer
│   ├── Task State Machine
│   ├── Priority Queue
│   ├── Approval Policy
│   └── Version Check
│
├── Execution Layer
│   ├── Codex
│   ├── Test Agent
│   └── Documentation Agent
│
└── Governance Layer
    ├── Human Review
    ├── Audit Log
    ├── Rollback
    └── Observability

这里的关键不是模型数量。

而是层与层之间的责任边界。

---

十九、一个简化的事件驱动 Agent 程序

type EngineeringEvent = {
  id: string
  type: string
  payload: unknown
  occurredAt: string
}

class EventDrivenAIEngineering {
  async handle(
    event: EngineeringEvent
  ) {
    const duplicated =
      await this.isDuplicateEvent(
        event.id
      )

    if (duplicated) {
      return {
        status: "IGNORED"
      }
    }

    const normalized =
      await chatgptPlus.normalize(
        event
      )

    const analysis =
      await chatgptPro.analyze(
        normalized
      )

    if (
      analysis.contextConflicts.length > 0
    ) {
      return this.sendToHumanReview({
        event,
        analysis
      })
    }

    const plan =
      await chatgptPro.createPlan({
        normalized,
        analysis
      })

    const approved =
      await this.checkApprovalPolicy(
        plan
      )

    if (!approved) {
      return {
        status: "APPROVAL_REQUIRED",
        plan
      }
    }

    const baselineValid =
      await this.verifyBaseline(
        plan.baselineCommit
      )

    if (!baselineValid) {
      return {
        status: "BASELINE_CHANGED"
      }
    }

    const result =
      await codex.execute(
        plan.codexTask
      )

    const verification =
      await this.verify(result)

    if (!verification.passed) {
      return {
        status: "VERIFICATION_FAILED",
        result,
        verification
      }
    }

    return this.sendToHumanReview({
      event,
      plan,
      result,
      verification
    })
  }

  private async isDuplicateEvent(
    eventId: string
  ): Promise<boolean> {
    return false
  }

  private async checkApprovalPolicy(
    plan: AgentTaskPlan
  ): Promise<boolean> {
    return plan.priority !== "critical"
  }

  private async verifyBaseline(
    commit: string
  ): Promise<boolean> {
    return true
  }

  private async verify(
    result: unknown
  ) {
    return {
      passed: true
    }
  }

  private async sendToHumanReview(
    payload: unknown
  ) {
    return {
      status: "HUMAN_REVIEW_REQUIRED",
      payload
    }
  }
}

这段代码表达了事件驱动 AI 工程的基本原则：

先去重
再归一化
再推理
再规划
再审批
再检查版本
再执行
再验证
最后人工审查

---

二十、ChatGPT Plus、Pro 与 Codex 的价值，不只是模型能力

从事件驱动架构的角度看，ChatGPT Plus、ChatGPT Pro 与 Codex 的价值不应该只用“更强”来描述。

它们处在完全不同的位置。

ChatGPT Plus：
事件语义整理层

ChatGPT Pro：
事件推理与任务规划层

Codex：
代码仓库执行层

三者组合后，系统才可能从被动响应走向持续任务处理。

但模型只是其中一部分。

真正决定系统可靠性的，还有：

事件幂等
任务状态机
版本控制
范围约束
优先级队列
背压机制
人工审批
审计日志
回滚能力

如果没有这些工程结构，AI 越能执行，系统越容易失控。

---

二十一、结语：AI Agent 时代，软件开始从“响应请求”走向“响应变化”

传统软件等待用户请求。

事件驱动软件监听系统变化。

AI Agent 系统则在变化发生后，尝试理解变化、判断影响、规划任务并推进执行。

这三者可以表示为：

Request-driven System：
收到命令后执行

Event-driven System：
状态变化后响应

Agent-driven System：
状态变化后理解、规划并执行

ChatGPT Plus、ChatGPT Pro 与 Codex 共同构成了这种系统的基础雏形。

事件发生
  ↓
ChatGPT Plus 整理语义
  ↓
ChatGPT Pro 判断影响并规划
  ↓
Codex 在边界内执行
  ↓
测试系统验证
  ↓
人类审批

这并不意味着系统会完全自治。

相反，越接近真实执行，越需要严格治理。

可以用一个公式概括：

Event-driven AI Reliability
=
Event Quality
× Context Accuracy
× Planning Quality
× Execution Control
× Verification Strength

如果事件本身不准确，后续推理没有意义。

如果上下文过期，ChatGPT Pro 的计划可能错误。

如果任务边界不清，Codex 可能扩大修改范围。

如果没有测试和人工审查，执行结果就无法被信任。

因此，2026 年的软件工程讨论，不应该只停留在 ChatGPT Plus、ChatGPT Pro 或 Codex 能生成多少代码。

更值得关注的问题是：

当软件系统开始能够感知事件、理解变化并自动推进任务后，我们应该如何设计它的边界、状态、权限和责任？

这才是 ChatGPT Pro、Plus、Codex 与 AI Agent 真正进入工程系统之后，最有价值的技术问题。