第一章 从控制循环到 Agent Runtime

如果把 Claude Code、Codex 或 DeepSeek Harness 的界面都拿掉，剩下的核心其实非常简单：先接收目标，再调用模型，执行模型选择的动作，最后把结果回传给模型。 这样的循环持续进行，直到目标完成或预算耗尽。

目标 → 决策 → 动作 → 环境变化 → 新观察
        ↑                     ↓
        └──────── 反馈 ───────┘

这个循环并不新。控制论研究反馈机制，自动规划研究如何从初始状态到达目标状态，机器人研究感知与行动，BDI 研究信念、目标与承诺，多智能体系统研究任务分配与通信协议。本章用这些工作比较问题结构；除有明确来源的关联外，不据此建立现代产品的直接设计谱系。 现代 Harness 的新意不在于重新发明循环，而在于把一种高能力、概率性、上下文受限、可调用任意软件工具的语言模型放进真实计算环境后，为它补上可靠运行所需的工程结构。

因此，要理解 Harness，最好的起点不是 2023 年的 AutoGPT，而是三个更早的问题。 第一，机器如何形成行动序列？ 第二，一个持续运行的 Agent 如何在变化环境中维持承诺并修正行为？ 第三，多个自治执行者如何分工，而又不依赖全局共享状态？

1. 规划：把目标翻译成动作序列

1971 年的 STRIPS 将规划描述为：在一个世界模型中寻找一串操作，使初始状态经过这些操作后满足目标公式。它把动作表示成具有前置条件和状态效果的操作符，使“怎样完成任务”从一段专用程序转化成可以搜索的状态转换问题。STRIPS 原始论文

用现代 Harness 的语言重写，STRIPS 已经对应了四个熟悉成分：

State        当前环境的结构化描述
Goal         希望满足的终止条件
Action       带前置条件和效果的环境操作
Planner      搜索可行 Action 序列的控制器

现代 coding agent 的文件读取、补丁、命令执行和测试工具，也可以被当成动作。 但是它和经典规划有决定性差异。 经典规划通常假设动作语义明确、状态可知、执行结果近似确定；而软件 Agent 的仓库、依赖、网络服务和人类意图是部分可观测的。 模型可能误解工具说明、生成无效参数，甚至把命令成功退出当作业务目标完成。

这也是为什么现代 Agent 很少只生成一份完整计划然后机械执行。 更常见的是滚动规划：先选一个信息增益高、风险可控的动作；观察真实结果；再更新局部计划。 ReAct 把这种“推理-行动”交替明确写进语言模型轨迹，但核心问题仍是规划与控制中的老问题：当世界模型不完整时，计划只能依据反馈持续修正。

对 Harness 设计者而言，这段历史留下第一条原则：

计划不是事实，而是一个必须持续接受环境证据修正的假设。

这意味着 plan mode 可以帮助形成意图和界定审查范围，但不应成为独立于执行反馈的僵硬工作流。 真正可靠的 Harness 必须保留重新观察、修订计划、撤销局部动作，以及报告不可达目标的通道。

2. 反应与承诺：BDI 的长期遗产

只在每一步对刺激反应的系统容易漂移。 只按预先计划执行的系统又难以适应变化。 Belief–Desire–Intention（BDI）架构试图在两者之间建立实际推理循环。 Agent 根据对世界的信念识别可能目标，并从中形成当前愿望或目标，再选择并承诺某些意图。 新事件到来后，它更新信念，判断现有意图是否仍可行，再决定继续、重规划或放弃。

BDI 的价值不在于要求现代 Harness 一定创建名为 beliefs、desires、intentions 的三个对象。 它真正揭示的是三类经常被聊天记录混为一谈的状态：

• 观察和推断出来的世界状态；
• 用户希望实现但尚未承诺执行路径的目标集合；
• 当前已经投入资源、应跨多个步骤保持一致的执行承诺。

早期 PRS、dMARS 与 AgentSpeak 也发展了计划库、事件触发、元级控制和显式 deliberation cycle。 BDI 综述将其核心贡献概括为：在动态、不可预测环境里平衡主动目标与被动响应，并通过意图表达对未来行为的承诺。BDI 架构综述

这和现代 Agent 的几个常见故障直接相关。

第一，只有对话历史却没有显式任务状态时，模型可能在长会话里忘掉用户到底批准了什么。 第二，计划、待办、执行事实和模型猜测如果用同一种自然语言表示，压缩后很容易互相污染。 第三，出现新消息时，如果 Harness 不区分“补充信息”“优先级变化”“取消请求”和“新任务”，Agent 就可能误放弃或误延续已有承诺。

因此，企业 Harness 至少应在运行时区分：

ObservedState   可追溯到环境或用户消息的事实
Hypothesis      模型尚未验证的解释
Goal            用户或上层系统定义的结果条件
Commitment      已批准并正在执行的目标/约束
Plan            当前可替换的动作建议
ExecutionState  已开始、等待、取消、失败或完成

这里最重要的不是命名，而是不同状态有不同的更新权限和证据要求。 模型可以自由提出假设和计划，但不应自行把假设升级为事实。 也不应把未批准目标升级为承诺。 BDI 为理解这类状态分离提供了比较框架，但本章没有证据证明现代 Harness 的相似分层直接继承自 BDI。

3. 多 Agent：1980 年已经出现的协调税

1980 年的 Contract Net Protocol 研究松耦合节点如何通过协商分配任务。 拥有任务的 manager 发布任务描述，潜在 contractor 根据能力和资源提交方案，manager 再授予合同。 该系统强调没有全局共享数据，也没有单一全局控制。 任务分配必须同时兼顾资源利用与问题求解焦点。Contract Net 原始论文

这与今天的 subagent、agent team 和异步云 Agent 非常相似，但它也提醒我们：多 Agent 从来不是免费的并行计算。 例如，管理者把两个检索子题交给不同执行者，首先要说明各自的输入与交付物。结果返回后，即使两份回答都自称完成，管理者仍需核对来源和冲突，再更新主任务状态。执行者超时、重复交付或越出题目范围时，通信与验收本身就成为工作。

从这个现代教学例子可以看出，委派成本不只是多发几条消息，还包括任务切分、执行者选择、上下文传递、授权、取消和结果合并。第十一章再展开这些运行契约；Contract Net 在这里提供的是协商与分配的参照。

如果拆分收益小于这些协调成本，多 Agent 会更慢、更贵，也更难调试。 这也是为什么“模型能够调用 subagent”不等于系统具备良好的多 Agent 架构。 真正要设计的是委派协议、隔离边界、结果契约、取消传播和合并策略。

现代 coding agent 使用 worktree、独立容器或远程 workspace，不是为了方便并行而已。 它是在物理上减少共享可变状态。 这种隔离与 Contract Net 的松耦合假设可以作结构比较，但两者解决的问题不同：前者约束共享可变状态和执行资源，后者组织任务协商。结构相似不足以证明直接传承，独立 worktree 也不自动带来独立权限或容器级隔离。

4. 从手写控制器到模型控制器

传统 Agent 的策略、计划选择和异常处理通常由规则、搜索算法或专用程序实现。 大语言模型改变的是控制器的表达能力。 它可以读取自然语言目标和非结构化观察，在没有为每种任务都写专用规则的情况下，提出下一动作并生成工具参数。

这带来显著的泛化能力，也引入四种结构性不确定性：

• 语义不确定性：模型可能误解目标、上下文或工具描述；
• 动作不确定性：它可能选择错误工具或构造无效参数；
• 状态不确定性：上下文窗口只包含环境的一部分，并可能在压缩中失真；
• 完成不确定性：模型说“完成”只是一项预测，不是外部世界已经满足目标的证明。

所以，现代 Harness 不能只是把模型接到 shell 上。 它需要用确定性软件包住概率性决策：工具 schema 约束动作形状，权限策略约束可执行范围，沙箱约束副作用，日志记录轨迹，预算限制循环，测试和评估器判断结果，人工审批承接不可自动化的价值判断。

可以把两者的分工写成一条简单边界：

模型负责：提出、解释、比较、生成、诊断
Harness负责：授权、执行、隔离、记录、计量、验证、恢复

这不是说 Harness 中不能有模型评审器，也不是说控制逻辑必须完全固定。 关键是：任何影响安全、资源、归因和进化晋级的决定，都不能只依赖被评对象的单次自我陈述。

5. ReAct：现代最小循环的形成

ReAct 将 reasoning trace 与 action 交替生成。 推理帮助模型维护并调整计划。 动作让模型从外部知识源或环境取得新信息。 新观察再进入后续推理。ReAct

它为现代工具调用 Agent 提供了极具影响力的最小模板：

for step in range(max_steps):
    ticket = budget.reserve_step_or_stop()
    try:
        decision = model(context, read_only_tools, limits=ticket)
        if decision.is_final:
            return candidate_answer(decision.answer)
        call = validate_read_only_call(decision.tool_call)
        observation = execute_in_simulator(call, limits=ticket)
        context.append(observation)
    finally:
        budget.settle(ticket)  # 计入已消耗资源，归还未用预留
return STOPPED_INCOMPLETE

这是说明交替过程的教学伪代码，不是ReAct原始实现。仓库案例入口用明确的模型与工具替身执行过这段控制流，没有运行原论文或供应商Agent。前提是工具仅在只读模拟环境运行，校验失败即拒绝执行；预算辅助函数在调用前预留额度、设置超时，并在异常路径结算。候选回答不代表业务完成，循环耗尽也只表示停止。 它没有回答上下文从哪里来，过长时如何压缩；工具结果是否可信；命令在哪台机器、以谁身份执行；权限是静态还是可临时扩展；进程崩溃后如何恢复；如何取消正在执行的工具；怎样判断模型陷入循环；最终答案需要哪些外部证据；多个用户和 Agent 如何隔离；历史轨迹如何进入评测和进化。

例如，读取文件失败后，模型可以根据错误选择重读；但若动作是发出付款且回执丢失，继续循环并不能判断该不该重试。后者需要外部副作用账本和对账规则。这是从最小循环走向生产运行时必须另行设计的责任，并非 ReAct 论文已经提供的保证。

6. Toolformer、Reflexion 与 Voyager：三种能力迁移

2023 年的几项工作分别说明了 Agent 能力可以迁移到不同位置。

Toolformer 研究了如何通过自监督数据，让模型学习何时调用 API、调用哪个 API、传什么参数，并学会吸收工具结果。Toolformer 它把一部分工具选择能力迁移进模型权重。

Reflexion 不更新权重，而是把任务反馈转成语言反思，保存到情景记忆中，影响后续尝试。Reflexion 它把一部分学习迁移到跨回合上下文。

Voyager 把成功行为保存为可执行技能库，并结合自动课程、环境错误和自验证持续扩充技能。Voyager 它把一部分能力迁移到外部、可组合、可复用的程序资产。

这三种路线构成了理解“Agent 如何进化”的早期坐标系：

能力沉淀位置	典型机制	优点	主要风险
模型权重	训练、微调、强化学习	推理时直接、可泛化	成本高、难回滚、归因困难
运行时记忆	反思、经验摘要、状态图	更新快、无需改权重	污染、过期、检索误配
外部技能	代码、工具、工作流、插件	可审查、可组合、可版本化	供应链风险、接口漂移
当前任务轨迹	retry、search、verify-fix	即时纠错	成本膨胀、循环与自证偏差

这张表按能力保存在哪里分类，不等同于后文的四层进化。后文按修改对象与生命周期区分：当前任务的尝试和修复属于任务内进化；经验与技能复用属于跨任务进化；上下文、工具和工作流配置变更属于 Harness 进化；权重更新属于模型进化。同一技能的生成、复用与发布可能跨越这些层次。 先保留一个重要结论：自我改进不必等同于修改模型，也不必等同于 Agent 任意重写运行时。 最有工程价值的进化，往往是把一次成功中可验证、可迁移的部分，沉淀到风险更低且更易回滚的层级。

7. Harness 的历史不是功能累积，而是责任迁移

回看这条历史线，可以看到 Harness 不是一张越来越长的功能清单。 它更像是责任在模型、控制器、环境与人之间不断重新分配的过程：

经典规划：控制器显式搜索动作序列
BDI：      控制器管理信念、目标与承诺
多 Agent： 协议管理委派与资源协商
ReAct：    模型参与滚动决策与工具选择
Reflexion：经验进入外部记忆
Voyager：  成功行为进入可复用技能
现代 Harness：确定性运行时治理概率性控制器

今天看似全新的问题——上下文工程、subagent、skills、tool schema、self-evolution——确实能在早期 Agent 研究中找到结构相似物。 但结构相似既不等于直接传承，也不等于工程问题已经解决。 语言模型放大了动作空间、任务空间和接口空间。过去可以写死在专用系统里的约束，也必须升级为通用运行时机制。

据此可以理解把 Harness 作为独立责任层的工程理由；这是一种架构解释，不是对各产品形成原因的历史证明。 模型越通用，环境越开放，循环越长时，Harness 承担的责任反而越厚。 它必须让系统知道自己看见了什么、承诺了什么、能做什么、做过什么、是否真的完成，以及从结果中能学到什么。

下一章将进入 2023 年的“自主 Agent 爆发期”：AutoGPT、BabyAGI、LangChain 和 AutoGen 如何把循环、记忆、计划与多 Agent 编排带入大众开发实践，以及这些机制进入生产时需要补齐哪些保证。