传统软件系统建立在确定性逻辑之上。

输入满足某个条件，程序执行对应分支。
参数类型不正确，编译器或运行时抛出异常。
数据库事务提交成功，数据状态随之改变。
测试用例输入固定，预期输出也相对固定。

程序员可以通过代码、类型、断言和测试，推导系统的大部分行为。

例如：

def calculate_total(price: float, quantity: int) -> float:
    return price * quantity

只要输入确定，输出也确定。

但 ChatGPT、Codex 和 AI Agent 引入了一种完全不同的计算模式：

概率计算。

同一个任务，模型可能生成不同方案。
同一段代码，模型可能做出不同解释。
相同的上下文，不同调用可能产生不同计划。
一个判断通常不是“绝对正确”，而是“在当前信息下更可能正确”。

这意味着 AI 系统不再只需要处理：

正确
错误

还要处理：

可能正确
证据不足
结果冲突
低置信度
不可验证
需要人工判断

一旦概率模型开始参与代码修改、工具调用、任务调度和系统决策，就会出现一个新的工程问题：

系统允许多少不确定性进入执行链？

如果每一步都要求绝对确定，AI 将无法完成复杂任务。

但如果系统允许模型在高度不确定时继续执行，错误就可能不断累积，最终影响真实系统。

因此，AI Agent 需要一种传统软件中并不常见的治理机制：

Uncertainty Budget，不确定性预算。

它要解决的不是如何消灭所有不确定性，而是如何限制不确定性在系统中的传播范围。

---

一、概率模型和确定性程序的根本差异

传统程序通常可以抽象为确定性函数：

y = f(x)

给定相同输入 x，程序大概率返回相同输出 y。

而大模型更接近：

y ~ P(y | x)

输出 y 是从条件概率分布中采样得到的。

模型并不是从一个固定答案表里找到结果。

它是在当前上下文条件下，生成一个概率较高的输出。

例如，让 Codex 修复一个空数组导致的接口异常。

它可能生成以下几种方案：

方案 A：在 Controller 层转换空数组
方案 B：在 Service 层忽略空筛选条件
方案 C：在 Query Builder 中统一处理空集合
方案 D：修改接口约定，禁止传入空数组

这些方案可能都具有一定合理性。

模型最终选择哪个方案，取决于：

当前上下文
代码结构
任务描述
历史信息
提示规则
模型参数
生成路径

因此，AI 输出天然具有不确定性。

这并不意味着 AI 不可靠。

它意味着 AI 的可靠性不能继续只依赖传统的“执行是否成功”。

系统还必须评估：

模型是否理解了目标
方案是否建立在正确假设上
证据是否足够
置信度是否可信
输出是否经过外部验证

---

二、不确定性不是一个数，而是一组来源

很多系统会让模型返回一个置信度：

{
  "answer": "问题可能来自空数组未被查询构造器处理",
  "confidence": 0.86
}

看起来很清楚。

但一个单独的 0.86 很难真正说明问题。

因为不确定性可能来自不同层面。

可以把它分成至少五类：

1. Intent Uncertainty
   意图不确定性

2. Context Uncertainty
   上下文不确定性

3. Knowledge Uncertainty
   知识不确定性

4. Planning Uncertainty
   规划不确定性

5. Execution Uncertainty
   执行不确定性

1. 意图不确定性

系统是否真正理解用户想做什么。

例如：

帮我优化订单模块。

“优化”可能指性能、结构、稳定性或可维护性。

2. 上下文不确定性

系统是否获得了足够的信息。

例如只看到 Service 文件，却没有看到 Controller 和测试。

3. 知识不确定性

模型是否具备正确领域知识。

例如它是否真正理解某个框架版本的事务行为。

4. 规划不确定性

即使目标和上下文清楚，执行计划是否合理。

5. 执行不确定性

工具调用之后，外部系统到底发生了什么。

例如请求超时，但操作可能已经成功。

所以更合理的不确定性对象应该是：

from dataclasses import dataclass


@dataclass
class UncertaintyProfile:
    intent: float
    context: float
    knowledge: float
    planning: float
    execution: float

其中数值越高，代表不确定性越大。

例如：

profile = UncertaintyProfile(
    intent=0.10,
    context=0.45,
    knowledge=0.20,
    planning=0.30,
    execution=0.05
)

这表示目标相对清楚，但上下文不足。

此时系统应该优先补充上下文，而不是继续生成更复杂计划。

---

三、模型置信度不等于真实正确率

一个常见误区是：

模型说自己有 90% 把握，就意味着结果有 90% 概率正确。

实际上，模型的自我置信度可能并未经过良好校准。

它可能：

对正确答案低估
对错误答案高估
对熟悉表达产生虚假自信
把语言流畅度误认为逻辑可靠性

例如一个解释写得非常完整：

问题的根因是连接池在高并发下耗尽，
导致事务无法获取数据库连接。

这句话可能听起来很专业。

但如果没有：

连接池监控
错误日志
线程堆栈
数据库指标
复现结果

它仍然只是一个假设。

所以 Agent 不能把模型自评置信度直接当成执行依据。

更可靠的方法是拆分：

Model Confidence
模型主观置信度

Evidence Strength
证据强度

Verification Strength
验证强度

可以定义综合可靠性：

def reliability_score(
    model_confidence: float,
    evidence_strength: float,
    verification_strength: float
) -> float:
    return (
        model_confidence * 0.2
        + evidence_strength * 0.35
        + verification_strength * 0.45
    )

这里故意降低模型自信的权重。

因为对工程系统而言，外部证据和真实验证通常比语言自信更重要。

---

四、什么是不确定性预算

不确定性预算可以理解为：

一个任务在继续自动执行前，最多允许保留多少未解决的不确定性。

例如文章草稿任务风险较低，可以容忍较高不确定性。

预算：0.7

但生产数据库修改任务风险很高，只能容忍非常低的不确定性。

预算：0.1

可以设计：

TASK_UNCERTAINTY_BUDGET = {
    "draft_text": 0.70,
    "code_explanation": 0.55,
    "code_generation": 0.40,
    "local_patch": 0.25,
    "create_pull_request": 0.18,
    "production_deployment": 0.08,
    "data_deletion": 0.02
}

任务越接近不可逆操作，预算越低。

这不是说高风险任务必须完全没有不确定性。

而是说：

在进入高风险阶段之前，系统必须通过检索、测试、验证或人工审批，把不确定性降低到允许范围内。

---

五、不确定性会沿任务链累积

假设一个 Agent 执行四个步骤：

理解需求
生成计划
修改代码
部署系统

每一步都有一定错误概率。

为了简化，假设每一步正确率分别是：

需求理解：0.90
计划生成：0.85
代码修改：0.90
部署判断：0.95

整个链路全部正确的概率近似为：

0.90 × 0.85 × 0.90 × 0.95 ≈ 0.65

单步看起来都不错。

但整条链路只有约 65% 的概率完全正确。

这就是不确定性传播。

任务步骤越多，风险越容易累积。

可以写成：

from math import prod


def chain_reliability(step_reliabilities: list[float]) -> float:
    return prod(step_reliabilities)

例如：

reliability = chain_reliability([
    0.90,
    0.85,
    0.90,
    0.95
])

这说明 AI Agent 不能只看当前步骤的置信度。

还要看整个任务链已经积累了多少不确定性。

---

六、长任务必须设置不确定性检查点

如果 Agent 一口气执行十几个步骤，只在最后验证一次，风险会非常高。

更合理的方式是在关键阶段设置检查点。

需求解析
    ↓
不确定性检查
    ↓
上下文收集
    ↓
不确定性检查
    ↓
计划生成
    ↓
计划审查
    ↓
代码执行
    ↓
测试验证

程序结构可以设计为：

class UncertaintyCheckpoint:
    def __init__(
        self,
        name: str,
        max_uncertainty: float
    ):
        self.name = name
        self.max_uncertainty = max_uncertainty

    def evaluate(self, score: float) -> bool:
        return score <= self.max_uncertainty

例如：

CHECKPOINTS = {
    "before_planning": UncertaintyCheckpoint(
        name="before_planning",
        max_uncertainty=0.45
    ),
    "before_tool_execution": UncertaintyCheckpoint(
        name="before_tool_execution",
        max_uncertainty=0.25
    ),
    "before_production_action": UncertaintyCheckpoint(
        name="before_production_action",
        max_uncertainty=0.08
    )
}

任务越往后，允许的不确定性越低。

---

七、不是所有不确定性都必须消除

完全消除不确定性通常是不现实的。

例如架构设计本身就没有唯一答案。

你可能无法证明某个方案绝对最好。

此时更合理的做法不是要求确定答案，而是明确：

有哪些假设
有哪些候选方案
每个方案的风险是什么
哪些条件会改变结论

可以定义 Decision Under Uncertainty：

from dataclasses import dataclass


@dataclass
class DecisionOption:
    name: str
    expected_value: float
    risk: float
    reversibility: float
    evidence_strength: float

系统可以优先选择：

高预期价值
低风险
高可逆性
证据较强

例如：

def option_score(option: DecisionOption) -> float:
    return (
        option.expected_value * 0.35
        - option.risk * 0.30
        + option.reversibility * 0.20
        + option.evidence_strength * 0.15
    )

这说明面对不确定性时，系统可以通过选择可逆方案降低风险。

不一定要等到所有问题都有答案。

---

八、可逆性可以扩大不确定性预算

假设两个动作具有相同的不确定性。

动作 A：

生成本地代码草稿

动作 B：

直接修改生产数据库

虽然判断不确定性相同，但两者风险完全不同。

因为动作 A 可轻松撤销。

动作 B 可能不可逆。

因此不确定性预算还应受到可逆性影响。

可以设计风险函数：

def effective_risk(
    uncertainty: float,
    impact: float,
    reversibility: float
) -> float:
    return (
        uncertainty
        * impact
        * (1.0 - reversibility)
    )

其中：

uncertainty：判断不确定程度
impact：动作影响范围
reversibility：可逆程度

如果一个动作高度可逆，即使模型不是完全确定，也可以先执行并验证。

这也是沙箱、临时分支、草稿和预览模式的重要价值。

它们不是简单方便用户。

它们是在工程上降低不确定性的实际成本。

---

九、Codex 应该优先在低风险环境中消化不确定性

Codex 生成代码时，不应该直接在主分支上修改。

更合理的流程是：

创建隔离工作区
    ↓
生成补丁
    ↓
运行静态检查
    ↓
运行测试
    ↓
生成 diff
    ↓
人工审查
    ↓
合并

这个流程的本质，是把模型的不确定性限制在隔离环境中。

class IsolatedExecutionEnvironment:
    def create(self):
        ...

    def apply_patch(self, patch):
        ...

    def run_verification(self):
        ...

    def destroy(self):
        ...

只有当验证结果把不确定性降低到预算之下时，补丁才允许进入主系统。

def can_merge(
    uncertainty: float,
    verification_passed: bool,
    review_approved: bool
) -> bool:
    return (
        uncertainty <= 0.15
        and verification_passed
        and review_approved
    )

---

十、信息缺失应该提高预算消耗

很多 Agent 在缺少信息时，会自动补全假设。

例如用户说：

给订单接口增加缓存。

系统可能默认：

使用 Redis
缓存五分钟
以订单 ID 为 Key
更新订单时主动失效

这些假设可能合理，但并非用户明确要求。

每一个未验证假设都应该消耗不确定性预算。

可以设计：

@dataclass
class Assumption:
    description: str
    confidence: float
    impact: float
    verified: bool = False

假设成本：

def assumption_uncertainty(
    assumption: Assumption
) -> float:
    if assumption.verified:
        return 0.0

    return (
        (1.0 - assumption.confidence)
        * assumption.impact
    )

高影响、低置信度的假设必须优先确认。

例如：

“系统允许最终一致性”

这是一个高影响假设。

如果没有业务确认，不能直接进入架构决策。

---

十一、上下文覆盖率可以量化

Agent 常说自己“已经理解项目”。

但这个判断往往缺少衡量标准。

可以把上下文拆成必要组件：

目标定义
相关代码
调用关系
接口契约
测试覆盖
运行日志
部署规则
历史决策

然后计算覆盖率：

def context_coverage(
    required_items: set[str],
    available_items: set[str]
) -> float:
    if not required_items:
        return 1.0

    return len(
        required_items & available_items
    ) / len(required_items)

例如：

需要 8 类上下文
当前获得 5 类
覆盖率 = 62.5%

上下文不确定性可以近似：

context_uncertainty = 1.0 - context_coverage

当然，现实系统还要考虑每类上下文的重要程度。

CONTEXT_WEIGHTS = {
    "goal": 1.5,
    "source_code": 1.3,
    "api_contract": 1.4,
    "tests": 1.2,
    "logs": 1.0,
    "history": 0.6
}

---

十二、检索不是为了增加信息，而是降低不确定性

很多 RAG 系统的目标被描述为“给模型更多资料”。

但从不确定性角度看，检索真正的目标是：

找到能区分多个候选判断的证据。

例如 Agent 有三个根因假设：

H1：空数组拼接导致 SQL 错误
H2：序列化层不支持空列表
H3：数据库驱动处理 IN () 失败

最有价值的下一步不是继续读更多随机文件。

而是找到能快速排除假设的证据。

可以使用信息增益来选择工具：

@dataclass
class EvidenceAction:
    name: str
    expected_information_gain: float
    cost: float
    risk: float

工具选择：

def evidence_action_score(
    action: EvidenceAction
) -> float:
    return (
        action.expected_information_gain
        / max(action.cost + action.risk, 0.01)
    )

这让 Agent 的工具调用从“收集更多信息”升级为“主动减少关键不确定性”。

---

十三、验证的价值是降低后验不确定性

模型先根据上下文生成一个判断，这可以看成先验概率。

P(H)

得到新证据后，系统更新判断：

P(H | E)

例如模型最初认为：

70% 可能是 Query Builder 问题

运行测试后发现：

空数组会生成 SQL：WHERE status IN ()

这条证据会显著提高该假设的后验概率。

虽然 Agent 系统不一定真的运行完整贝叶斯计算，但可以借鉴这种结构。

@dataclass
class Hypothesis:
    name: str
    prior: float
    evidence_scores: list[float]

简化更新：

def update_hypothesis(
    hypothesis: Hypothesis
) -> float:
    score = hypothesis.prior

    for evidence in hypothesis.evidence_scores:
        score = score + (
            1.0 - score
        ) * evidence

    return min(score, 1.0)

验证不是简单给结果打勾。

它是在减少系统对真实状态的不确定性。

---

十四、多 Agent 共识可能制造虚假确定性

当多个 Agent 给出同样结论时，系统可能认为可靠性更高。

例如五个 Agent 中有四个都认为方案 A 正确。

但如果这些 Agent：

使用同一个基础模型
读取同一个错误上下文
遵循相似提示
共享同一错误假设

那么四票并不是四份独立证据。

它可能只是同一种偏差被重复了四次。

这叫相关性错误。

如果判断来源高度相关，不能简单通过数量提高置信度。

可以定义 Agent 独立性：

@dataclass
class AgentJudgment:
    agent_id: str
    conclusion: str
    model_family: str
    context_id: str
    reasoning_strategy: str

两个判断的独立性取决于：

模型是否不同
上下文是否独立
工具证据是否不同
推理角色是否不同

可以设计简单独立性权重：

def independence_weight(
    judgment: AgentJudgment,
    previous: list[AgentJudgment]
) -> float:
    weight = 1.0

    for item in previous:
        if judgment.model_family == item.model_family:
            weight *= 0.8

        if judgment.context_id == item.context_id:
            weight *= 0.7

        if (
            judgment.reasoning_strategy
            == item.reasoning_strategy
        ):
            weight *= 0.8

    return weight

这能避免“多个相似 Agent 同意”被误认为强证据。

---

十五、模型分歧本身是一种风险信号

如果多个独立 Agent 对同一问题给出明显不同结论，不应该强行选多数。

分歧可能意味着：

上下文不完整
问题本身存在多解
需求存在歧义
关键事实尚未验证
模型能力不足

可以计算分歧度。

例如对候选方案的概率分布：

方案 A：0.40
方案 B：0.35
方案 C：0.25

分布越均匀，系统越不确定。

可以借用熵：

import math


def entropy(probabilities: list[float]) -> float:
    return -sum(
        p * math.log2(p)
        for p in probabilities
        if p > 0
    )

高熵意味着分歧较大。

此时系统应该：

补充证据
降低动作风险
选择可逆方案
请求人工决策

而不是让另一个模型再“拍板”。

---

十六、风险不能只由概率决定

一个错误发生概率很低，不代表可以忽略。

还要考虑损失。

可以使用期望损失：

Expected Loss =
    Probability of Failure × Failure Impact

程序表示：

def expected_loss(
    failure_probability: float,
    impact: float
) -> float:
    return failure_probability * impact

例如：

文档格式错误：
概率 20%，影响 0.1
期望损失 = 0.02

生产数据删除错误：
概率 1%，影响 100
期望损失 = 1.0

虽然生产删除错误概率更低，但期望损失远高于文档错误。

因此高影响动作必须设置更低的不确定性预算。

---

十七、不确定性预算应该动态变化

任务预算不应该固定不变。

它会随着任务进展变化。

例如初始研究阶段：

允许较高不确定性

因为只是探索候选方案。

进入代码修改阶段：

要求中等不确定性

进入合并和部署阶段：

要求极低不确定性

可以定义动态预算：

STAGE_BUDGETS = {
    "exploration": 0.70,
    "planning": 0.45,
    "implementation": 0.30,
    "verification": 0.20,
    "approval": 0.10,
    "production": 0.05
}

运行时检查：

def within_budget(
    stage: str,
    uncertainty: float
) -> bool:
    return uncertainty <= STAGE_BUDGETS[stage]

---

十八、低置信度不应该总是触发追问

系统不能每遇到不确定性就停止。

否则 Agent 会变得极其低效。

更合理的处理方式取决于：

风险
可逆性
信息获取成本
用户是否必须参与

可以设计动作矩阵：

不确定性	风险	可逆性	推荐动作
高	低	高	先执行草稿或实验
高	高	低	请求确认
中	低	高	执行并验证
中	高	高	沙箱执行
低	高	低	仍需审批
低	低	高	自动执行

程序结构：

def choose_uncertainty_action(
    uncertainty: float,
    risk: float,
    reversibility: float
) -> str:
    if risk > 0.8 and reversibility < 0.2:
        return "human_approval"

    if uncertainty > 0.6 and reversibility > 0.7:
        return "sandbox_experiment"

    if uncertainty > 0.5:
        return "collect_more_evidence"

    if risk < 0.3:
        return "auto_execute"

    return "execute_with_verification"

---

十九、AI Agent 需要不确定性账本

复杂任务中，不确定性不应该只存在模型语言里。

它应该被结构化记录。

@dataclass
class UncertaintyItem:
    item_id: str
    category: str
    description: str
    probability: float
    impact: float
    status: str
    evidence_refs: list[str]
    mitigation: str | None

例如：

{
  "item_id": "u-18",
  "category": "context",
  "description": "无法确认订单接口是否允许空数组",
  "probability": 0.55,
  "impact": 0.80,
  "status": "open",
  "evidence_refs": [
    "controller-source",
    "api-doc-v2"
  ],
  "mitigation": "读取接口测试与调用方代码"
}

这可以形成不确定性账本：

Open Uncertainties
Resolved Uncertainties
Accepted Risks
Escalated Decisions

任务完成时，系统不应只报告做了什么。

还应该报告：

哪些不确定性已经解决
哪些风险被接受
哪些假设仍然存在
哪些结论依赖人工决策

---

二十、确定性控制层必须压住概率推理层

AI Agent 最关键的架构原则之一是：

概率模型不能直接控制所有系统状态。

更合理的分层是：

概率推理层
    ↓
生成候选计划、判断和解释

确定性控制层
    ↓
验证状态、权限、预算和约束

工具执行层
    ↓
改变外部系统

结构可以表示为：

┌──────────────────────────┐
│ Probabilistic Reasoning  │
│ ChatGPT / Codex / Agent  │
└─────────────┬────────────┘
              ↓
┌──────────────────────────┐
│ Deterministic Control    │
│ Policy / State / Budget  │
└─────────────┬────────────┘
              ↓
┌──────────────────────────┐
│ Tool Execution           │
│ Files / APIs / Database  │
└──────────────────────────┘

模型可以建议：

当前最可能的修复方案是修改 Query Builder。

控制层负责检查：

上下文覆盖率是否足够
方案是否超过不确定性预算
是否触发高风险限制
是否需要先运行测试

只有通过控制层，工具执行才被允许。

---

二十一、一个可落地的不确定性感知 Agent Runtime

可以设计如下运行时：

class UncertaintyAwareRuntime:
    def __init__(
        self,
        planner,
        uncertainty_estimator,
        evidence_engine,
        policy,
        verifier
    ):
        self.planner = planner
        self.uncertainty_estimator = (
            uncertainty_estimator
        )
        self.evidence_engine = evidence_engine
        self.policy = policy
        self.verifier = verifier

    def run(self, task):
        context = self.evidence_engine.collect_initial_context(
            task
        )

        profile = self.uncertainty_estimator.estimate(
            task,
            context
        )

        stage = "planning"

        while not self.policy.within_budget(
            stage,
            profile
        ):
            action = self.evidence_engine.next_best_action(
                task,
                context,
                profile
            )

            evidence = action.execute()
            context.add(evidence)

            profile = self.uncertainty_estimator.estimate(
                task,
                context
            )

            if action.requires_human:
                return {
                    "status": "human_input_required",
                    "uncertainty": profile
                }

        plan = self.planner.create_plan(
            task,
            context
        )

        plan_profile = (
            self.uncertainty_estimator
            .estimate_plan(plan, context)
        )

        if not self.policy.within_budget(
            "implementation",
            plan_profile
        ):
            return {
                "status": "plan_rejected",
                "uncertainty": plan_profile
            }

        result = self.execute_in_sandbox(plan)

        verification = self.verifier.verify(
            result,
            task
        )

        if not verification.passed:
            return {
                "status": "verification_failed",
                "verification": verification
            }

        return {
            "status": "completed",
            "result": result,
            "remaining_uncertainty": (
                verification.remaining_uncertainty
            )
        }

这个 Runtime 的重点不是让模型输出一个置信度数字。

而是让不确定性真正影响任务流程。

---

二十二、ChatGPT 与 Codex 在不确定性系统中的不同作用

ChatGPT 更擅长处理语义不确定性。

例如：

用户真正想解决什么问题
多个表达是否存在歧义
哪些要求彼此冲突
哪些假设需要向用户解释

Codex 更擅长处理工程不确定性。

例如：

相关文件是否完整
调用链是否确认
补丁影响范围多大
测试是否覆盖关键路径
代码是否与当前版本兼容

两者可以形成协作：

ChatGPT：
解析目标与约束
    ↓
Codex：
检查代码与工程证据
    ↓
Verifier：
运行确定性验证
    ↓
Runtime：
判断是否低于不确定性预算

---

二十三、为什么 GPT-5.6 这类更强模型仍然需要预算治理

模型能力增强后，通常会带来：

更好的推理
更长的上下文处理
更完整的代码生成
更强的任务规划
更自然的工具调用

但它也会带来一个容易被忽略的问题：

更强的模型能够在更复杂的不确定环境中继续行动。

弱模型遇到信息不足时，可能直接失败。

强模型却可能根据有限信息构建一套完整方案。

这提高了任务完成率，也提高了“错误方案看起来非常完整”的风险。

因此，模型越强，越不能只依赖表面输出质量。

必须通过：

证据
测试
预算
权限
可逆性
人工检查点

限制不确定性的传播。

模型能力提高的是推理上限。

系统治理决定的是错误下限。

---

二十四、不确定性治理不是让 Agent 变保守

有人可能认为，加入不确定性预算会让 Agent 不断停止、追问和拒绝执行。

这取决于系统设计。

好的不确定性治理不是让 Agent 什么都不做。

而是让它选择与当前认知水平相匹配的动作。

信息不足时，可以：

生成候选方案
运行低风险实验
创建本地补丁
补充测试
读取日志
构造最小复现

而不是直接：

部署生产
删除数据
修改权限
发送外部通知

这不是保守。

这是风险匹配。

真正成熟的 Agent 应该具备：

低确定性时做低风险动作
高确定性时推进高影响动作

---

二十五、写在最后：AI 的可靠性不是确定，而是知道自己有多不确定

传统软件系统追求确定性。

输入明确。
规则明确。
状态明确。
结果明确。

AI 系统却天然运行在概率空间中。

它理解的是可能的意图。
生成的是可能的方案。
做出的是基于当前证据的判断。
执行的是带有风险的动作。

所以，AI Agent 的成熟不能用“永远正确”来衡量。

更现实的标准是：

它能否识别自己的不确定性
它能否说明不确定性来自哪里
它能否主动寻找降低不确定性的证据
它能否在不确定性过高时停止
它能否选择与风险相匹配的动作

ChatGPT Plus / Pro 与 Codex 可以让 AI 更擅长理解、生成和执行。

但当 AI 进入真实工程系统后，最重要的问题不再只是：

模型能不能完成任务？

而是：

系统是否知道模型在多大程度上可能出错？

一个可靠的 AI Agent，不是始终表现得自信。

而是能够把以下内容明确区分：

已知事实
高概率判断
待验证假设
未知状态
不可接受风险

模型负责在概率空间中寻找可能答案。

验证系统负责用真实证据缩小答案范围。

控制系统负责确保剩余不确定性不会越过风险边界。

人类负责处理无法通过技术手段消除的重要分歧。

未来真正高级的 AI 工程，不只是训练更强的模型。

还要构建一种新的运行时纪律：

每一个结论都标记证据
每一个计划都评估不确定性
每一个动作都匹配风险预算
每一个高影响结果都经过验证

生成能力决定 AI 能提出多少可能性。

不确定性治理决定其中多少可能性可以进入现实。

这才是 ChatGPT、Codex 与 AI Agent 从“看起来聪明”走向“真正可靠”的关键。