# 为什么 Claude Code 能像 Agent 一样工作？

> 很多人第一次用 Claude Code 时会想："这不就是终端里的 ChatGPT 吗？为什么大家说它是 Agent？" 本章拆解"Agent 性"的六个结构条件，以及四种常见误解。

---

## 先破四个误解

| 误解 | 为什么不对 |
|------|----------|
| "因为 prompt 很强所以像 Agent" | Prompt 再好也只能影响一次回复的质量，不能让系统自己持续跑下去 |
| "因为能调工具所以像 Agent" | 调工具的聊天框很多（OpenAI Function Calling、LangChain），但调完一次就停了，不会自动进入下一轮 |
| "因为能开子 Agent 所以像 Agent" | 子 Agent 只是分工机制。如果主循环自己都不是 Agent，开再多子 Agent 也只是在调函数 |
| "因为能跑很久所以像 Agent" | 跑很久只是结果，不是原因。问题是**为什么能跑很久**——是什么结构让它不崩溃、不失控、不丢状态 |

---

## 六个结构条件

Claude Code 之所以能像 Agent 一样工作，是因为它同时满足了**六个结构条件**。缺少任何一个，系统就会退化为某种更简单的东西。

### 条件 1：行动闭环

系统能把"语言意图"变成"真实行动"，并把"行动结果"送回模型做下一步判断。

**核心实现**：`queryLoop()` 的 while(true) 循环——调模型 → 解析工具调用 → 执行工具 → 把结果送回模型 → 循环。这不是一次性的 request-response，而是持续的行动-观察闭环。

> 💡 **通俗理解**：聊天框是"你问我答"——像考试答卷，写完就交了。Agent 是"你指路，我走一步看一步"——像导航，每走一步都会根据路况重新计算。

### 条件 2：可治理的副作用

每个行动（读文件、写文件、跑命令）都经过治理——权限检查、沙箱隔离、hooks 拦截。

**核心实现**：十步权限检查链 + macOS seatbelt / Linux bubblewrap 沙箱 + PreToolUse/PostToolUse hooks。

如果没有治理，Agent 就变成了危险的自动化脚本。治理让 Agent 的行动变得**可控**。

> 💡 **通俗理解**：治理就像**汽车的刹车和安全带**——发动机（语言模型）再强劲，没有刹车就不敢开快。Claude Code 的"治理"不是减速，而是让它敢于在真实世界里放开跑——因为任何动作出问题前都有拦截机会。

### 条件 3：会话持续性

工作可以跨越多轮对话持续存在，不因一次中断而丢失。

**核心实现**：JSONL 会话存储 + File History 快照 + `--continue` 恢复 + Bridge Pointer 崩溃恢复。

如果没有持续性，每次断线就得从头开始——Agent 就变成了一次性的脚本执行器。

> 💡 **通俗理解**：会话持续性就像**游戏的自动存档系统**——你打一局 RPG 不会因为关机就从头开始，游戏自动记住了你刚才走到哪、打到哪、捡了什么。Claude Code 也是如此，每一轮对话、每一次文件修改都被自动存档，断线后 `--continue` 就能从存档点继续。

### 条件 4：任务托管

长时间运行的工作可以被托管——后台执行、状态保存、暂停恢复。

**核心实现**：Task 系统的任务类型可分为两组——**四种常规类型**（本地 Shell 任务、本地 Agent 任务、远程 Agent 任务、Dream 任务／后台记忆整理）和**两种高级模式下才激活的条件型任务**（工作流脚本任务、MCP 监控任务），合计六种；再加上"前后台切换"开关（这些任务可以切到后台跑不占当前屏幕）。

这里**不要被"六种"数字吓到**——它是 Task 系统按"触发时机"做的分类，不是要求读者背下来的词表；重点是"四种常规 + 两种条件型"这个**两段式结构**告诉了你 Task 系统的伸缩方式：主线流程里只用四种，进入高级模式（如工作流脚本、MCP 编排）才额外生出两种条件型。把它当作索引（具体差异详见 Part3 Agent与任务系统完全解析章节）即可。

如果没有托管，Agent 只能在前台同步执行——一旦用户关掉终端，一切结束。

> 💡 **通俗理解**：任务托管就像**快递柜代收**——你不用一直站在门口等快递，但快递柜能帮你"代收"有一个前提：快递员上门时柜子是通电的、格子是空着的、有唯一的取件码——换句话说，**后台的"状态保持能力"才是它能代收的根因**。对应到 Claude Code 的 Task 系统，这个"后台状态"来自 JSONL 会话存档 + File History 快照 + Bridge Pointer（条件 3 的会话持续性），加上 Task 自己跑在一个可以脱离前台 TTY 的执行器里——三者合一让 Task 可以"脱离你的终端活下去"。所以"不用一直等"只是表象，能成立是因为后台有完整的状态保持机制。

### 条件 5：协作控制面

多个 Agent 实例可以协作——分配任务、传递消息、共享结果、协调停止。

**核心实现**：Swarm Leader/Teammate 模式 + Mailbox 文件系统通信 + Coordinator 编排 + ListPeers/SendMessage 跨会话消息。

如果没有协作控制面，多个 Agent 就是多个互不相干的独立进程——无法形成团队。

> 💡 **通俗理解**：协作控制面就像**交响乐团的指挥 + 乐谱**——交响乐团有 100 个乐手，但没有指挥和乐谱，就算把他们全塞进一个音乐厅也演奏不出一首完整的交响乐。指挥告诉每个声部"你什么时候进"（任务分配），乐谱告诉每个人"现在演奏到哪一段"（进度同步），指挥的停拍手势告诉所有人"这里停一下"（协调停止）。协作的关键不是"人数变多"，而是"有指挥、有乐谱、有共同节拍"。Claude Code 的多 Agent 不只是"多跑几个实例"，而是让它们真的能像一支乐团那样协同——Swarm Leader 是指挥，Mailbox 是乐谱共享板，SendMessage 是乐手之间的眼神交流。

### 条件 6：交互插手点

人类可以随时介入——确认权限、提供输入、中断执行、查看进度。

**核心实现**：权限弹窗（Ask 模式）+ Ctrl+C 中断 + `/status` 查看 + Bridge 远程观察 + `claude ps` 进程状态。

如果没有插手点，Agent 就变成了完全自主的黑盒——用户只能等最终结果，无法参与过程。

> 💡 **通俗理解**：交互插手点就像**导航时可以随时改目的地**——导航帮你规划路线、提示你转弯，但你可以随时说"不去 A 了改去 B"，导航立刻重新计算。完全自主的黑盒就像**一上车就锁死方向盘的出租车**——司机替你决定一切，你只能等它停。Claude Code 保留了所有关键决策点让人类可以介入。

---

## 六个条件的关系

> **先说结论再看图**：下面这张图是一个**金字塔**——**底层能力是上层能力的前提**。地基（条件1：行动闭环）必须先打好，才能在上面盖治理层（条件2），再往上才是持续性、托管、协作、人类插手。**缺了底层，上层就不成立**——没有行动闭环就没有副作用可治理（2 依赖 1）；没有治理就不敢让它长期跑（3 依赖 2）；没有持续就没有任务可托管（4 依赖 3）；以此类推。看图的时候请**从最底层往上读**：

```
         ┌──────────────────────────────┐
         │   条件 6：交互插手点          │ ← 人类参与
         │   (权限确认/中断/观察)         │
         └──────────┬───────────────────┘
                    │
         ┌──────────▼───────────────────┐
         │   条件 5：协作控制面          │ ← 多 Agent 协作
         │   (Swarm/SendMessage/Peer)    │
         └──────────┬───────────────────┘
                    │
         ┌──────────▼───────────────────┐
         │   条件 4：任务托管            │ ← 长期运行
         │   (Task/Background/Resume)    │
         └──────────┬───────────────────┘
                    │
         ┌──────────▼───────────────────┐
         │   条件 3：会话持续性          │ ← 跨中断存活
         │   (JSONL/FileHistory/Pointer) │
         └──────────┬───────────────────┘
                    │
         ┌──────────▼───────────────────┐
         │   条件 2：可治理的副作用       │ ← 安全可控
         │   (权限/沙箱/Hooks)           │
         └──────────┬───────────────────┘
                    │
         ┌──────────▼───────────────────┐
         │   条件 1：行动闭环            │ ← 基础能力
         │   (queryLoop/Tool/Result)     │
         └──────────────────────────────┘
```

从下往上看：先有行动闭环（能做事），再有治理（做事不出事），再有持续性（做事不怕断），再有托管（做事可以后台跑），再有协作（多个一起做），最后有人参与（做事的过程人能控制）。

**缺了底层的，上层就不成立。** 没有行动闭环就没有可治理的副作用——因为根本没有副作用可治理。没有会话持续性就没有任务托管——因为 session 一断任务就丢了。

---

## 和其他工具的对比

> ⚠️ **关于对比依据**：下表的评价基于截至 2026 年 4 月公开可查的产品文档和开源代码（Claude Code 基于本书源码分析，LangChain/Cursor/ChatGPT 基于各自官方文档与开源仓库）。竞品产品的具体特性可能在本书发布后快速变化——评价反映的是**当前时点的设计架构**而非永久定论。


| 条件 | Claude Code | 普通 ChatGPT | LangChain Agent | Cursor |
|------|-------------|-------------|-----------------|--------|
| 行动闭环 | ✅ queryLoop | ❌ 单次回复 | ✅ AgentExecutor | ✅ multi-step |
| 可治理副作用 | ✅ 十步权限+沙箱 | N/A* | ⚠️ 基本无 | ⚠️ 简单审批 |
| 会话持续性 | ✅ JSONL+Pointer | ❌ | ❌ | ⚠️ Composer 级别 |
| 任务托管 | ✅ 六种 Task | ❌ | ⚠️ 简单 | ❌ |
| 协作控制面 | ✅ Swarm+Peer | ❌ | ⚠️ 接近 CrewAI 多 Agent 编排的水平 | ❌ |
| 交互插手点 | ✅ 权限弹窗+Bridge | ⚠️ 只有输入框 | ❌ | ⚠️ 编辑器内 |

> **\* "N/A" 的含义**：普通 ChatGPT（指无工具/无 Code Interpreter 的纯聊天模式）在"可治理副作用"维度标 N/A 不是"不足"，而是**这个维度对它不适用**——在该模式下它没有本地项目文件读写和终端命令执行的能力，所以"治理副作用"的概念本身不存在。相反，如果一个 AI 产品**有写路径能力且治理只停留在简单的 yes/no 确认**，那属于"治理不足"（⚠️），而不是完全缺席（❌）——这也是 Cursor 在本表里被标 ⚠️ 的原因；下一行"简单审批"要配合本注脚一起读。
>
> **评级口径**：✅ = 架构内有专门机制并默认生效；⚠️ = 有部分实现但能力受限或覆盖不全；❌ = 公开文档/代码中未见对应能力；N/A = 该维度对产品不适用。

> 💡 **通俗理解**：ChatGPT 是"你问它答的咨询师"，LangChain Agent 是"会查资料的助手"，Cursor 是"嵌在编辑器里的编程搭子"，Claude Code 是"能独立驻场、自带安保、可以远程指挥的项目负责人"。差别不在智力，在**组织结构**。

---

### 下一个问题

**为什么要顺着讲到"权限、压缩、恢复"三件事？** 上面六个条件里，条件 2（可治理的副作用）直接对应**权限**；条件 3（会话持续性）和条件 4（任务托管）之所以能成立，都依赖**压缩**（把越跑越长的上下文控制在模型可消化的窗口内）和**恢复**（断了之后能从磁盘/快照重建状态）这两根底层梁。所以"权限、压缩、恢复"不是凭空蹦出来的新话题，而是**把本章条件 2、3、4 从"为什么重要"展开成"具体怎么做到"的三根支柱**。这正是下一章 **Q27 为什么 Agent 工作台必须有权限、压缩和恢复** 要回答的——你会看到这三根"梁"如何共同支撑起 Agent 工作台的可靠性。
