第1节 引言与问题形式化

技术报告§1.1–1.5
本节建立长程智能体的形式化问题框架,阐述任务视界与上下文窗口的根本张力,定义 Harness 架构,并分解四重核心矛盾。

1.1 长程任务的问题陈述

1.1.1 任务视界与上下文窗口的张力

长程编码任务(long-horizon coding task)是指需要数十乃至数百步推理与操作才能完成的复杂编程工作,如"重构整个代码库架构""实现一个完整的功能模块""调试并修复分布式系统中的隐蔽缺陷"。这类任务的核心特征是任务视界(task horizon)——从任务开始到完成所需的信息累积量和交互步数——远超单次对话的上下文容量。

形式化地,定义任务 $T$ 的信息需求函数 $\mathcal{I}_T: \mathbb{N} \to \mathbb{R}$,表示在执行到第 $n$ 步时所需累积的信息总量(以 token 为单位)。定义上下文窗口预算 $W \in \mathbb{R}$ 为模型单次推理所能处理的 token 上限。长程任务的矛盾可形式化为:

$$ \mathcal{I}_T(H) \gg W $$

其中 $H$ 是完成任务 $T$ 所需的总步数(任务视界长度)。该不等式表明:完成任务所需的信息总量远超单次上下文窗口的承载能力。

1.1.2 交互步数的累积效应

令 $o_t$ 表示第 $t$ 步的观测(上下文窗口内容),$a_t$ 表示第 $t$ 步的动作(工具调用或文本输出)。轨迹 $\tau = (o_1, a_1, o_2, a_2, \ldots, o_H, a_H)$ 的总信息量为:

$$ \mathcal{I}_T(H) = \sum_{t=1}^{H} |o_t| + \sum_{t=1}^{H} |a_t| $$

其中 $|\cdot|$ 表示以 token 为单位的长度度量。由于每一步的观测 $o_t$ 需要包含此前所有相关交互的摘要(以保持连贯性),存在递归关系:

$$ |o_t| = \mathrm{compress}(o_{t-1}, a_{t-1}, \text{new\_context}_t) $$

其中 $\mathrm{compress}: \mathcal{O} \times \mathcal{A} \times \mathcal{C} \to \mathcal{O}$ 表示上下文组装函数,将前一步的观测、动作和新上下文信息压缩为新的观测。在 naive 实现中,$\mathrm{compress}$ 为简单拼接,导致 $|o_t|$ 随 $t$ 线性增长,最终超过 $W$。

1.1.3 上下文窗口作为硬约束

上下文窗口预算 $W$ 构成了智能体行为的硬约束:

$$ |o_t| \leq W, \quad \forall t \in \{1, 2, \ldots, H\} $$

违反此约束的后果是:

因此,长程智能体的核心设计挑战在于:如何在满足 $|o_t| \leq W$ 的硬约束下,保持轨迹 $\tau$ 的语义连贯性和决策质量

1.2 Harness 的定义与系统架构

1.2.1 智能体作为复合系统

传统的 LLM 智能体定义聚焦于模型本身,即 $\pi: \mathcal{O} \to \mathcal{A}$,从观测空间到动作空间的映射。然而,这种定义忽略了支撑模型在真实环境中运行所需的大量基础设施。

Codex 提出的 Harness(鞍具) 架构将智能体明确定义为复合系统:

$$ \mathcal{A} = (\pi, \mathcal{H}) $$

其中:

1.2.2 Harness 的功能分解

Harness $\mathcal{H}$ 可进一步分解为五个子系统:

$$ \mathcal{H} = (\mathcal{H}_{\text{mem}}, \mathcal{H}_{\text{act}}, \mathcal{H}_{\text{safe}}, \mathcal{H}_{\text{coop}}, \mathcal{H}_{\text{intf}}) $$

其中:

子系统符号核心职责对应模型局限性
记忆管理$\mathcal{H}_{\text{mem}}$状态持久化、上下文压缩、窗口管理模型无内部状态,推理过程无记忆
行动能力$\mathcal{H}_{\text{act}}$工具注册、执行调度、结果回填模型只能生成文本,无法直接操作外部系统
安全边界$\mathcal{H}_{\text{safe}}$沙箱隔离、策略执行、人机审批模型输出不可信,需防护与监督
协作编排$\mathcal{H}_{\text{coop}}$子代理管理、委派协议、身份验证单模型难以处理所有任务类型
人机接口$\mathcal{H}_{\text{intf}}$多形态适配(CLI/TUI/IDE/MCP)模型输出格式与用户界面需求存在鸿沟

1.2.3 系统方框图

┌─────────────────────────────────────────────────────────────────┐
│                        用户与环境交互层                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐            │
│  │  CLI    │  │   TUI   │  │   IDE   │  │   MCP   │            │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘            │
└───────┼────────────┼────────────┼────────────┼─────────────────┘
        │            │            │            │
        └────────────┼────────────┼────────────┘
                     │            │
              ┌──────▼────────────▼──────┐
              │    人机接口层             │
              │   (消息转换、事件广播)    │
              └──────┬───────────────────┘
                     │
        ┌────────────┼────────────────────┐
        │            │                    │
   ┌────▼────┐  ┌────▼────┐  ┌──────────▼──────┐
   │  会话   │  │  工具   │  │    安全         │
   │  管理   │  │  系统   │  │    边界         │
   └────┬────┘  └────┬────┘  └──────────┬──────┘
        │            │                    │
        └────────────┼────────────────────┘
                     │
              ┌──────▼──────────────┐
              │    上下文管理层      │
              │ (历史、压缩、预算)   │
              └──────┬──────────────┘
                     │
              ┌──────▼──────────────┐
              │    Turn 引擎        │
              │ (采样循环、状态机)   │
              └──────┬──────────────┘
                     │
              ┌──────▼──────────────┐
              │   模型接入层         │
              │ (API协议、流式传输)  │
              └──────┬──────────────┘
                     │
              ┌──────▼──────────────┐
              │   LLM 模型 π        │
              │  (外部服务)          │
              └─────────────────────┘

1.2.4 轨迹生成的形式化描述

在 Harness 架构下,轨迹生成过程可形式化为:

$$ \tau = (o_1, a_1, \ldots, o_H, a_H) = \text{Execute}(\pi, \mathcal{H}, T) $$

其中每一步的观测由 Harness 的上下文组装函数生成:

$$ o_t = \text{ctx}_{\mathcal{H}}(s_{

每一步的动作由模型 $\pi$ 基于当前观测生成,再由 $\mathcal{H}_{\text{act}}$ 执行:

$$ \tilde{a}_t = \pi(o_t), \quad a_t = \mathcal{H}_{\text{act}}(\tilde{a}_t) $$

其中 $\tilde{a}_t$ 是模型的原始输出(文本),$a_t$ 是实际执行的动作(工具调用)。

1.3 形式化建模:部分可观测马尔可夫决策过程

1.3.1 POMDP 定义

长程编码任务可建模为部分可观测马尔可夫决策过程(POMDP),定义为六元组:

$$ \mathcal{M} = (\mathcal{S}, \mathcal{O}, \mathcal{A}, T, Z, R) $$

其中:

1.3.2 上下文窗口作为观测约束

在 POMDP 框架下,上下文窗口预算 $W$ 约束了观测空间:

$$ \mathcal{O}_W = \{o \in \mathcal{O} : |o| \leq W\} $$

实际可用的观测函数 $Z_W$ 被修正为:

$$ Z_W(s, a) = \text{truncate}(Z(s, a), W) $$

其中 $\text{truncate}: \mathcal{O} \times \mathbb{R} \to \mathcal{O}_W$ 将过长的观测截断至长度 $W$。截断策略包括:

1.3.3 信念状态与记忆管理

智能体在 POMDP 中的决策基于信念状态(belief state)$b_t \in \Delta(\mathcal{S})$,即对真实状态的概率分布。理想情况下:

$$ b_{t+1}(s') = \eta \, Z(o_t \mid s', a_t) \sum_{s \in \mathcal{S}} T(s' \mid s, a_t) b_t(s) $$

其中 $\eta$ 是归一化常数。然而,在 Codex 的实现中,信念状态通过确定性的记忆管理而非概率推理来近似:

$$ b_t \approx \text{BeliefFromHistory}(\tau_{

这种近似牺牲了理论上的概率保证,但获得了工程上的可控性和可解释性(见第 13-19 章)。

1.3.4 决策策略

智能体的决策策略 $\pi: \mathcal{O} \to \Delta(\mathcal{A})$ 将观测映射到动作分布。在 Harness 架构下,实际执行的策略是:

$$ \pi_{\mathcal{H}}(o_t) = \mathcal{H}_{\text{act}} \circ \pi \circ \mathcal{H}_{\text{mem}}(o_t) $$

这表明:观测先经过记忆管理处理,再由模型生成决策,最后由行动层执行。这一管道使得模型本身只需关注"给定历史,生成下一个动作",而将复杂性外包给各子系统。

1.4 核心矛盾的四重分解

Codex 的设计本质上是对长程智能体面临的四重核心矛盾的系统化应对。每一重矛盾对应 Harness 的一个或多个子系统,也对应后续章节的深入剖析。

1.4.1 第一重矛盾:记忆有限性

矛盾表述:任务所需信息量 $\mathcal{I}_T(H)$ 远超上下文窗口 $W$,而模型的推理质量与上下文完整性正相关。

形式化

$$ \begin{cases} \mathcal{I}_T(H) \gg W \\ \text{Quality}(\pi(o_t)) \propto \text{Completeness}(o_t) \end{cases} $$

Harness 解法:双层压缩机制

预算约束不等式

$$ \sum_{i=1}^{n} \text{tokens}(\text{item}_i) + \text{tokens}(\text{base\_instructions}) \leq W - \text{output\_budget} $$

其中 output_budget 是为模型生成回复预留的 token 空间。

1.4.2 第二重矛盾:过程连续性

矛盾表述:长任务必然面临中断(用户主动停止、系统崩溃、网络故障),但任务语义要求"从中断处恢复"而非"从头开始"。

形式化:令 $\tau = (o_1, a_1, \ldots, o_k, a_k, \ldots, o_H, a_H)$ 为完整轨迹,中断发生在 $k$ 步。恢复要求:

$$ \text{Resume}(\tau_{\leq k}, \text{interrupt\_state}) \to \tau'_{>k} \approx \tau_{>k} $$

即恢复后的后续轨迹 $\tau'_{>k}$ 应尽可能接近未中断的轨迹 $\tau_{>k}$。

Harness 解法:事件溯源与 Rollout 持久化(第 17 章)

1.4.3 第三重矛盾:行动风险性

矛盾表述:智能体需要执行真实、不可逆的操作(文件修改、系统命令、网络请求),但模型的输出不可信,且错误操作的代价高昂。

形式化:定义风险函数 $\text{Risk}: \mathcal{A} \to \mathbb{R}_{\geq 0}$,衡量动作的潜在危害。智能体应满足:

$$ \sum_{t=1}^{H} \text{Risk}(a_t) \leq \text{Risk}_{\text{budget}} $$

且存在高风险动作集合 $\mathcal{A}_{\text{high}}$,要求人工审批:

$$ a_t \in \mathcal{A}_{\text{high}} \implies \text{HumanApproval}(a_t) = \text{true} $$

Harness 解法:纵深防御体系(第 27-32 章)

1.4.4 第四重矛盾:注意力稀缺性

矛盾表述:模型的 token 预算有限,但并非所有历史信息同等重要——需要将注意力分配给最相关的内容。

形式化:定义信息价值函数 $V: \text{HistoryItem} \to \mathbb{R}$,衡量历史条目对当前决策的贡献。上下文组装应满足:

$$ \text{ctx}_H(s_{

其中 $\text{TopK}$ 返回价值最高的 $K$ 个条目,$K$ 由窗口预算 $W$ 决定。

Harness 解法

1.5 报告结构路线图

本节建立了长程智能体的形式化问题框架。后续章节将围绕四重矛盾展开,系统剖析 Codex 的设计原理:

章节标题对应矛盾核心内容
第2节核心会话循环与决策引擎(总控)Turn 引擎状态机、采样循环、流式交互(对应 Ch 07-12)
第3节长程上下文工程记忆有限性双层压缩、Rollout 持久化、预算追踪、窗口管理(对应 Ch 13-19)
第4节工具系统与行动能力行动风险性工具注册、执行调度、审批流、安全边界(对应 Ch 20-32)
第5节多智能体协作与接口层注意力稀缺性子代理委派、上下文隔离、多形态适配(对应 Ch 33-39)

各节既相对独立,又通过 Harness 架构的统一框架相互关联。读者可按序阅读,也可根据研究重点选择特定章节。

本节符号表

符号含义首次出现小节
$\mathcal{I}_T(n)$任务 $T$ 执行到第 $n$ 步所需的信息总量1.1.1
$W$上下文窗口预算(token 上限)1.1.1
$H$任务视界长度(总步数)1.1.1
$o_t$第 $t$ 步的观测(上下文窗口内容)1.1.2
$a_t$第 $t$ 步的动作(工具调用或文本输出)1.1.2
$\tau$完整轨迹 $(o_1, a_1, \ldots, o_H, a_H)$1.1.2
$\mathrm{compress}(\cdot)$上下文组装函数1.1.2
$\mathcal{A}$智能体系统1.2.1
$\pi$核心 LLM 模型1.2.1
$\mathcal{H}$Harness(鞍具)系统1.2.1
$\mathcal{H}_{\text{mem}}$Harness 记忆管理子系统1.2.2
$\mathcal{H}_{\text{act}}$Harness 行动能力子系统1.2.2
$\mathcal{H}_{\text{safe}}$Harness 安全边界子系统1.2.2
$\mathcal{H}_{\text{coop}}$Harness 协作编排子系统1.2.2
$\mathcal{H}_{\text{intf}}$Harness 人机接口子系统1.2.2
$\text{ctx}_{\mathcal{H}}(\cdot)$Harness 的上下文组装函数1.2.4
$\mathcal{S}$POMDP 状态空间1.3.1
$\mathcal{O}$POMDP 观测空间1.3.1
$\mathcal{A}$POMDP 动作空间1.3.1
$T(\cdot)$POMDP 状态转移函数1.3.1
$Z(\cdot)$POMDP 观测函数1.3.1
$R(\cdot)$POMDP 奖励函数1.3.1
$b_t$第 $t$ 步的信念状态1.3.3
$\text{Risk}(\cdot)$动作风险函数1.4.3
$V(\cdot)$历史条目信息价值函数1.4.4
← 返回首页下一节 →