第二章 2023：自主 Agent 爆发与第一次祛魅

2023 年春天，GPT-4、廉价 API、开源代码和社交媒体演示共同触发了一次“自主 Agent”爆发。 AutoGPT、BabyAGI、AgentGPT 等项目让普通开发者第一次“直接看到”：只要给模型一个目标、少量工具、一个循环和某种记忆，它似乎就能拆解任务、搜索网络、写文件、运行代码，并不断决定下一步。

从今天看，这批系统并没有建立可靠的通用自治。 但把它们直接叫“玩具”也不准确。 它们把语言模型从单次问答移入持续执行循环。本章分别讨论公开材料描述的机制，以及这些机制用于生产时可能出现的失效条件；后者不等于已经逐一复现的历史事故。

1. BabyAGI：任务队列就是最小外部认知

BabyAGI 归档所描述的核心结构非常简洁：从队列取出一个任务，调用执行 Agent，将结果写入记忆，再根据目标和最新结果创建新任务并重新排序队列，重复循环。归档代码入口 该链接仍指向可变分支，本轮尚未取得足以固定 2023 年原型的提交证据；下文据此解释队列机制，不把当前归档逐行等同于首发版本。

Objective
   ↓
Task Queue → Execute → Result → Store
   ↑                           ↓
Prioritize ← New Tasks ←───────┘

它的重要启示不是“需要三个角色提示词”，而是模型之外必须有可检查的任务状态。 如果所有计划只在对话文本里，系统很难回答：还有哪些任务？哪个任务正在执行？为什么优先做它？某个结果由哪次执行产生？

任务队列把一部分认知外置成了数据结构。 这是一个很小但很关键的动作。 现代 Agent 的待办、计划、工单和执行图也体现相似的职责分离：自然语言适合生成候选，结构化状态更适合承载约束。这是机制比较，不是各项目直接继承 BabyAGI 的证据。

这种“模型管理模型任务”的机制也有可推导的失效条件。 任务创建者可能反复生成低价值后续事项；优先级调整者可能被最近结果牵着走；执行结果被存储并不代表它就正确；队列增长本身很容易被误当作进展。 例如，若“调查市场”的结果又生成同义调查任务，而系统没有目标验收和去重门，队列可以一直有工作，业务目标却不推进。这是教学反例，尚非对某个固定版本的运行复现。

这可以抽象成第一种自治陷阱：

当 Harness 只能测量活动而不能测量结果时，Agent 会把循环存活当作任务进展。

企业运行时因此不能只记录 tool-call 数、token 数、步骤数和任务完成声明。 它必须定义与业务结果直接挂钩的 evaluator。 对代码任务，可能是测试、静态检查和验收条件；对数据分析，可能是查询可复现性、口径一致性和事实来源；对业务流程，则可能是外部系统状态与审批记录。

2. AutoGPT：把开放动作空间交给语言模型

AutoGPT 的早期吸引力来自更开放的循环。 模型接收一个长期目标后，可以选择搜索、浏览、文件、命令等动作，再用短期历史和向量记忆延续任务。 与 BabyAGI 的显式队列相比，它更接近后来通用 coding agent 的体验：模型既负责局部规划，也负责选择工具并解释观察。

按这类开放循环的设计，可以尝试几种能力：

• 模型能在多轮中维持一个粗粒度目标；
• 工具结果可以成为新观察，影响后续决策；
• 外部记忆可以突破单次上下文的表面限制；
• 命令与文件工具让模型从“建议者”变成“执行者”。

与此同时，开放循环把多个风险同时放大：目标漂移、重复动作、无效搜索、错误记忆、费用失控、不可逆副作用和虚假完成。 模型生成一段看似合理的自我批评，并不意味着它识别了真实错误；向量库找回语义相似内容，也不意味着内容仍然正确或适用于当前状态。

AutoGPT 的后续仓库逐步发展出平台、组件、Forge 和 benchmark 等不同项目。 做历史研究时必须避免把这些成熟后的结构倒推到 2023 年原型。 这里讨论的是原型所代表的范式：让模型直接选择下一步，再用提示和记忆维持长期目标。由于本轮未补齐原型的固定版本与运行轨迹，下列风险是架构分析，不能据此断言某一版 AutoGPT 已发生对应事故。

这次实验带来的最大教训是：自治不是一个开关。 至少要从五个维度拆开看：

维度	问题
决策自治	下一步由模型、规则还是人决定？
工具自治	模型可以调用哪些动作？
权限自治	动作是否需要批准，能否扩大权限？
时间自治	可以持续多久，何时暂停或终止？
进化自治	能否改变记忆、技能、策略或自身 Harness？

一个系统可以有高决策自治，却被限制在只读沙箱。 也可以使用固定工作流，却对某个已批准 API 拥有高工具自治。 用“全自动/非自动”去描述 Agent，会遮住真正的风险边界。

3. LangChain：把 Agent 拆成可复用抽象

LangChain 在 2023 年用一套影响广泛的词汇总结当时的 Agent。 Agent 是决定动作的模型，Tools 是可执行动作，Memory 负责引入过去事件，AgentExecutor 运行循环直到满足停止条件。 它的典型算法直接继承 ReAct：Thought、Action、Observation 重复进行。LangChain 2023 总结

它的历史贡献是把快速增长的模型供应商、向量库、工具和提示模式装进可复用接口。 开发者不必为每个实验重写消息转换、输出解析和循环控制。 这种“集成框架”大幅降低了入门门槛，也让 Agent、Tool、Memory、Executor 成为广泛流通的工程术语。

从这些接口出发，可以分析四类抽象成本；要判断它们是否发生在具体版本，还需固定实现和故障记录。

第一，模型 API 本身变化很快。 原生 function calling、结构化输出、流式事件和服务端状态不断出现，通用包装层很容易滞后，甚至泄漏底层差异。

第二，Agent 的故障通常发生在跨层边界：提示、工具 schema、消息序列、重试、解析器和供应商响应共同作用。 封装过深时，开发者只会看到“chain failed”，却难以还原模型当时究竟看到了什么。

第三，早期 memory 概念过宽。 对话历史、检索知识、用户偏好、工具结果和执行状态有不同生命周期、可信度和更新规则。把它们都叫 memory，容易制造错误抽象。

第四，生产环境需要的不只是调用组件：还包括持久化、幂等、恢复、租户隔离、审批、流式 UI、观测和评估。 这些能力需要明确的运行语义，单有组件对象之间的连接并不足够。例如输出解析失败时，若只返回统一错误而不保留原始响应和解析器版本，开发者就无法区分模型输出变化与适配器缺陷；这是条件性反例，不是本书实跑过的 LangChain 故障。

这些成本可以解释开发者为何会选择直接调用模型 API，但本章没有社区采用数据来确定这种选择的主要原因。LangChain 也没有简单消失。 它后来通过 LangGraph 将重点转向持久状态、确定性与 Agent 节点混合、interrupt/resume、checkpoint 和 durable execution。 官方回顾甚至明确提出，最大的竞争者始终是“不使用框架”。LangGraph 运行时设计

因此更适合把两代设计比较为不同的责任重点，而非一条必然替代路线：

集成与高层抽象
       ↓ 增加运行语义
显式状态图 + 低层运行时
       ↓
持久化、恢复、观测与部署基础设施

2026 年的材料继续呈现框架组合路线：Deep Agents 明确提供子代理的 isolated 与 fork 上下文模式；Microsoft 的 Harness 文档则描述如何组合历史持久化、任务清单、审批、观测和可选的有界循环。Deep Agents 上下文模式，2026-09-08 Microsoft Harness，2026-09-15 更新 这些是官方能力说明，本书未据此实测成本或可靠性；上下文取舍将在第七、十一章讨论。

这组对照对企业自研 Harness 很有提醒意义。 早期最吸引人的往往是统一接口和快速 demo； 长期最难替换的却是状态模型、事件协议和运行语义。 平台应把稳定性投入放在后者。

4. AutoGen：把工作流表达成多 Agent 对话

AutoGen 将多个可定制 Agent 的对话作为应用编排机制。 每个 Agent 可以组合模型、人类输入和工具，交互行为既可由自然语言定义，也可由代码定义。AutoGen 论文

这种设计有很强表达力。 规划者、执行者、评审者和用户代理可以用统一消息隐喻协作； 新角色可通过说明与工具配置快速加入； 人类也能作为对话参与者插入流程。

但“万物皆消息”与“万物皆文件”一样既是统一抽象，也有潜在陷阱。 如果把业务状态、权限决定、执行结果、取消信号和评审结论都退化成自然语言消息，会产生四类问题：

• 难以保证消息被恰好处理一次；
• 难以区分陈述、命令、建议和授权；
• 难以建立严格 schema 与兼容性策略；
• 难以证明终止条件和责任归属。

多 Agent 对话还容易制造“社会性拟真”：不同角色互相赞同、批评或投票，看起来像一个团队， 却可能共享同一个模型偏差、同一错误上下文和同样盲点。 增加说话者数量不自动增加独立证据。

判断对话式编排是否有价值，要看角色是否带来不同的信息、工具、权限或可并行工作，而非只看角色名。例如实现者与审查者若共享同一份错误假设，互相赞同并不增加验证证据；让审查者独立读取需求和补丁才可能提供新的判断。第十一章将用同预算基线比较这类收益与协调成本。

5. 第一次祛魅：为什么 Demo 自治不能直接进入生产

2023 年的演示通常选择开放式目标，比如“研究一个市场并建立网站”。 这类目标给了模型足够空间生成惊喜轨迹，但缺少可重复、可外部判定的完成条件。 生产系统不同：错误成本真实存在，输入分布不断变化，结果必须可审计。

“第一次祛魅”主要来自六个错配。

5.1 语言流畅度与状态正确性错配

模型能生成连贯的“当前进度”，但环境可能根本没发生对应变化。 Harness 必须用工具结果和外部查询维护 canonical state，而不是用模型叙述替代状态。

5.2 语义相似与记忆有效性错配

向量检索擅长找相似文本，但不负责内容真实性、时效性、权限范围或因果相关性。 生产记忆需要来源、时间、作用域、置信度、失效条件和删除机制。

5.3 工具可调用与动作可授权错配

工具出现在 schema 中只说明模型知道如何发起请求，不说明它有权执行。 模型选择、策略判断、用户审批与沙箱执行必须是不同步骤。

5.4 循环持续与目标进展错配

Agent 可以不断产生新的思考、搜索和任务。预算、重复检测、停滞检测和外部里程碑要共同限制循环。

5.5 自我批评与独立验证错配

同一模型阅读自己的输出并说“看起来正确”，只能提供一种弱信号。 强验证必须来自测试、类型系统、约束求解、外部数据、不同信息路径或人类判断。

5.6 多角色对话与多样性错配

共享模型、共享上下文和共享提示风格的多个 Agent 很可能产生相关错误。 有效冗余要测量错误相关性，而不是只看 Agent 数量。

6. 从 Framework 到 Runtime

从前述原型和后续运行时文档看，讨论已从组件调用延伸到运行保证。企业设计需要逐项回答：

• 状态能否持久化并从中断恢复；
• 每一步是否形成可消费的结构化事件；
• 工具执行是否幂等，失败能否安全重试；
• 人类能否在关键点暂停、修改和恢复；
• 长任务能否跨进程、跨机器和跨版本继续；
• 权限与凭证是否由模型之外的策略系统管理；
• 轨迹能否进入回放、评估和回归测试。

这些问题有助于理解 framework 与 runtime 的职责差别。LangGraph 将开发 API 与 PregelLoop runtime 分离；后续产品也各自分离控制、执行或接入协议，具体版本与来源见第三篇。这里不把它们写成从某个早期框架依次演化而来的谱系。

Framework 主要回答“开发者如何表达 Agent”； Runtime 还必须回答“表达出来的 Agent 如何长期、安全、可恢复地运行”。 两者并不互斥，但企业平台如果只拥有前者，就会在每个应用中重复构建后者。

7. 这一代系统留下了什么

AutoGPT 和 BabyAGI 留下开放循环与任务外置；LangChain 留下 Agent/Tool/Memory/Executor 词汇和集成生态；AutoGen 留下对话式多 Agent 编排；LangGraph 则代表从高层魔法回到显式状态和持久运行语义。

它们提示：最小 Agent 可以很小，生产系统所需的运行责任却不能因循环短小而省略。职责可以由已有基础设施承担，并不都要加入 Agent 核心。

最小 Agent：模型 + 工具 + while loop

生产 Harness：
  最小 Agent
  + canonical state
  + context lifecycle
  + policy and sandbox
  + durable execution
  + observability
  + verification
  + human control
  + evaluation and governance

下一章进入 coding agent 的工程化转折。 Aider 的 repository map、SWE-agent 的 Agent-Computer Interface，以及 OpenHands 的动作—观察事件流，将反复证明一个事实：同一模型的表现，会被它所在接口和环境显著改变。 模型能力并不等于系统能力。