第 1 章　重新认识 AI Agent

本章目标：建立对 AI Agent 的准确认知，厘清 Chatbot、Copilot、Agent、Autonomous Agent、Coding Agent 之间的边界，理解 LLM 为什么能成为 Agent 的”大脑”，并给出 Agent 的本质定义——Agent = LLM + Harness。这是全书的认知地基。

1.1 一段简短的发展历程：Harness 是怎么被”逼”出来的

要理解”Agent = LLM + Harness”这个公式，理解这个公式需要了解 Agent 是怎么一步步走到今天、Harness 又是怎么被”逼”出来的。

2017  Transformer 提出           → LLM 的"地基"诞生
2020  GPT-3 规模化               → 推理与通用能力涌现
2022  ChatGPT 发布              → Chatbot 时代，LLM 会"聊"了
2023  AutoGPT / BabyAGI         → 自主 Agent 浪潮，也暴露了致命缺陷
2023  Function Calling 普及      → Tool Calling 成为 API 标配
2024  Cursor 等 Coding Agent 崛起 → Coding Agent 开始成熟
2024  MCP 发布                  → 工具从"私有实现"走向"标准协议"
2025  Claude Code 发布          → Coding Agent 工程化
2025  生产级 Agent              → 安全、可观测、评估成为焦点

2017  Transformer 提出           → LLM 的"地基"诞生
2020  GPT-3 规模化               → 推理与通用能力涌现
2022  ChatGPT 发布              → Chatbot 时代，LLM 会"聊"了
2023  AutoGPT / BabyAGI         → 自主 Agent 浪潮，也暴露了致命缺陷
2023  Function Calling 普及      → Tool Calling 成为 API 标配
2024  Cursor 等 Coding Agent 崛起 → Coding Agent 开始成熟
2024  MCP 发布                  → 工具从"私有实现"走向"标准协议"
2025  Claude Code 发布          → Coding Agent 工程化
2025  生产级 Agent              → 安全、可观测、评估成为焦点

一个规律：每一步都在”补上一块能力”，同时也”暴露一个缺口”。下面逐段解释。

1.1.1 2017–2020：LLM 的诞生与规模化

2017 年，Vaswani 等人提出 Transformer（详见 1.4.1），奠定了现代 LLM 的架构地基。此后 OpenAI 沿着 GPT 系列一路扩张：GPT-1（2018）、GPT-2（2019）、GPT-3（2020）。其中 GPT-3 是一个分水岭——当参数规模跨过某个量级后，模型”涌现”出了一些此前小模型不具备的能力：给定几个示例就能完成新任务（few-shot）、能写代码、能做简单的逻辑推理。

这一步的关键认知是：LLM 本身不是为”Agent”设计的，它只是一个被训练来”预测下一个 token”的语言模型。但它足够通用，以至于人们开始设想：能不能让它不只是”回答”，而是”做事”？

1.1.2 2022：Chatbot 时代，以及”推理”可以被外化

2022 年底 ChatGPT 发布，把 LLM 从实验室带进了大众视野。但 ChatGPT 的默认形态是 Chatbot——它只会”说”，不会”做”：不能读文件、不能查数据库、不能执行任何动作。

同一时期，两条学术进展对后来的 Agent 至关重要：

思维链（Chain-of-Thought, CoT，2022 年 Wei 等人）：诱导模型”一步一步思考”，能显著提升复杂推理的正确率。这证明了模型的推理可以被”外化”和”引导”。
ReAct（2022 年 Yao 等人）：把”推理（Reasoning）”和”行动（Acting）”交错起来——模型一边思考，一边调用外部工具、观察结果，再继续思考。这是 Agent Loop 的思想雏形。

这两条线索合在一起，指向同一个方向：一个被精心设计的循环，能让”只会说”的模型开始”学着做”。

1.1.3 2023：自主 Agent 浪潮，与它暴露的”Harness 缺口”

2023 年 3 月，AutoGPT、BabyAGI 相继发布，引爆了”自主 Agent”浪潮。它们的思路极其朴素：给 LLM 一个目标，再给它工具和”规划→执行→反思→再规划”的循环，让模型完全自主地跑下去。

结果很快翻车了：无限循环、上下文爆炸、任务跑偏、成本失控。AutoGPT 常常在一个目标上打转数小时，烧掉大量 token 却一无所获。

这个”翻车”是理解 Agent 架构最宝贵的一课：光有 LLM 和循环，是撑不起一个可靠 Agent 的。 循环之外，还需要一整套基础设施——谁来管理上下文、谁来执行工具、谁来判断”该不该停下”、谁来做权限约束、谁来做状态持久化。这些 AutoGPT 当年几乎都没有。它们不是失败的产品，而是用血的代价证明了：把”裸模型 + 循环”升级成”可靠 Agent”，中间缺的那一层，正是后来被命名为 Harness 的东西。

1.1.4 2023–2025：Tool Calling 与 Coding Agent 的成熟

2023 年年中，OpenAI 在 API 中推出 Function Calling（即 Tool Calling），随后各大模型厂商跟进。这标志着”工具调用”从”用 Prompt 哄模型输出 JSON”的野路子，变成了模型原生支持的正式能力——模型被训练成在需要时输出结构化的工具调用请求，而不是自由文本（详见 1.4.7）。

工具调用一旦标准化，Coding Agent 迅速崛起。2024 年起，Cursor、Cline、Aider 等产品率先成熟；2025 年初，Claude Code 发布，Coding Agent 进入工程化阶段。这些产品把 Agent 带进了真实的软件工程：读代码、改代码、跑测试、看报错、自我修复。编码之所以成为 Agent 的最佳试验场，是因为它有极其丰富的客观反馈信号——编译器报错、测试失败、类型检查——这让 Agent 的”自我纠错循环”真正转得起来，而不像通用 Agent 那样容易空转。

2024 年底，Anthropic 发布 MCP（Model Context Protocol，模型上下文协议），试图把”工具”从每家框架的私有实现，变成可以跨框架复用的标准协议。工具调用从此开始走向”标准化”和”联邦化”。

1.1.5 历史的结论：Agent = LLM + Harness

把这条发展线收拢起来，结论非常清晰：

光有 LLM 和循环，撑不起一个可靠、安全、可控的 Agent。真正让 Agent 落地的，是包裹在 LLM 之外的那套软件系统——它给模型提供上下文、执行模型的工具请求、驱动决策循环、设行动边界、记录行为。这套系统，我们称之为 Harness（运行时框架）。

这就是本书最核心的公式的历史出处：

Agent = LLM + Harness

本节先抛出这个结论，具体定义与拆解放到 1.6 节。下面先补上另一块拼图：Chatbot、Copilot、Agent 之间的能力谱系。

1.2 从 Chatbot 到 Agent：能力的谱系

上一节是”时间线”，这一节是”能力谱系”。时间线讲的是 Harness 怎么被逼出来；能力谱系讲的是 Chatbot、Copilot、Agent 这几个词各自到底差在哪。

“AI Agent”是过去几年技术圈被滥用得最严重的词汇之一。几乎每一个带点 LLM（Large Language Model，大语言模型）能力的产品，都急于把自己标榜为 Agent。但真正理解 Agent 的人，会警惕这种泛化——因为把 Chatbot 叫作 Agent，不仅不准确，还会掩盖两者在架构上的本质差异。

要建立准确认知，沿着一条清晰的能力演进线走一遍：Chatbot → Copilot → Agent → Autonomous Agent → Coding Agent。

1.2.1 Chatbot 是什么

Chatbot（聊天机器人）是 LLM 应用的最原始形态。它的本质是一个 “无状态问答机”：

用户输入一句话 → LLM 生成一句话 → 返回

用户输入一句话 → LLM 生成一句话 → 返回

它的特征非常明确：

单轮为主：每次对话独立，即使有多轮历史，也只是把历史文本拼进上下文，模型本身不产生任何”持久副作用”。
无工具：它只能”说”，不能”做”。它不能读文件、不能查数据库、不能发邮件。
无状态：对话结束后，它不会记住任何事情，也不会改变外部世界的任何状态。
被动响应：它只在你问它的时候才回答，不会主动发起动作。

ChatGPT 早期形态、微信里的各种 AI 客服，都属于 Chatbot。它们的价值在于”对话式信息获取”，局限在于”只能动嘴，不能动手”。

1.2.2 Copilot 是什么

Copilot（副驾驶）是 Chatbot 的一次重要升级。这个词由 GitHub Copilot 普及开来，其核心隐喻是：AI 不是替你做决定的人，而是坐在你旁边帮你一起做的人。

Copilot 的架构特征是：

人主导，AI 辅助：人类是”正驾驶”，掌握方向盘和最终决定权；AI 提供建议、补全、提示。
嵌入工作流：Copilot 深度嵌入某个具体场景——GitHub Copilot 嵌入 IDE，Microsoft Copilot 嵌入 Office。它不是通用的，而是场景化的。
增量式输出：它倾向于”补全下一个 token”，而不是”完成整个任务”。在编码场景，它补全下一行、下一个函数；在写作场景，它补全下一段。
同步协作：AI 的每一次输出都立即呈现给人，人实时审阅、接受或拒绝。

Copilot 的意义在于，它证明了 LLM 可以在真实生产力场景中创造价值，但它仍然受限于一点：它是被动的，它不会自己决定”接下来该做什么”，它只在你给出提示时补全。

1.2.3 Agent 是什么

Agent（智能体）是质的飞跃。Agent 的核心特征是 “自主性”（Autonomy） 和 “工具使用”（Tool Use）：

能使用工具：Agent 不仅能”说”，还能”做”。它可以调用函数、读写文件、执行命令、查询数据库。
能做决策：Agent 面对一个目标，能自己分解步骤、选择工具、判断何时完成。
有循环：Agent 不是一次性的”输入→输出”，而是一个”感知→决策→行动→观察”的循环（Loop）。
有状态：Agent 在任务执行过程中维护状态，知道”我做到哪一步了””上次的结果是什么”。

一个最朴素的 Agent 定义是：

Agent 是一个能够自主地使用工具、通过循环决策来完成目标的软件系统，其中 LLM 充当决策中枢。

注意这个定义里有个关键点：LLM 是”决策中枢”，不是”整个系统”。这句话是全书的基石，后面会反复回到它。

1.2.4 Autonomous Agent 是什么

Autonomous Agent（自主智能体）是 Agent 的加强版，强调 “更少的监督、更长的任务、更独立的决策链”。

一个自主智能体的典型特征：

长时任务：能连续运行几分钟、几小时甚至几天，而不是几秒钟的单次交互。
自我纠错：执行出错时能自己发现问题、分析原因、重试或换策略。
目标导向：给它一个高层目标（”帮我做一个网页”），它自己分解为几十个步骤并逐一完成。
弱监督：人类从”每一步都审批”退化为”关键节点审批”或”事后审计”。

AutoGPT、BabyAGI 是 2023 年自主智能体浪潮的代表。它们试图让 LLM 完全自主地”规划→执行→反思→再规划”，但很快暴露出问题：无限循环、上下文爆炸、任务跑偏、成本失控。这些教训对理解 Agent 架构极其宝贵——它们不是失败的产品，而是用血的代价证明了”光有 LLM 和循环是远远不够的，还需要一整套外围基础设施”（这正是 1.1.3 讲到的”Harness 缺口”）。

1.2.5 Coding Agent 是什么

Coding Agent（编码智能体）是 Agent 在软件工程领域的具体化，也是本书的核心研究对象。它的目标不是”陪聊”，而是 “理解代码、修改代码、运行代码、验证结果”。

一个 Coding Agent 至少具备以下能力：

读代码：能浏览仓库结构、搜索符号、定位函数定义。
改代码：能精确地编辑文件，而不是重新生成整个文件。
跑代码：能执行测试、编译、构建命令，观察结果。
自我修复：看到报错后能分析原因、修改代码、重新运行直到通过。

Claude Code、Cursor、Codex、Cline、Aider 都是 Coding Agent。它们之所以成为 AI Agent 领域的”最佳实践样本”，是因为编码是一个反馈信号极其丰富的领域：编译器报错、测试失败、类型检查，都是客观、即时的反馈。这让 Coding Agent 的”自我纠错循环”能够真正转起来，而不像通用 Agent 那样容易空转。

1.3 Agent 与 Workflow、传统自动化的区别

讲完能力谱系，还有一个边界必须划清：Agent 与”工作流””传统自动化”到底差在哪。这是很多”伪 Agent”产品刻意模糊的地方。

1.3.1 Agent 与 Workflow

Workflow（工作流） 是预先定义好的、确定性的步骤序列：

步骤1 → 步骤2 → 步骤3 → 步骤4

步骤1 → 步骤2 → 步骤3 → 步骤4

Workflow 的执行路径在运行前就已经确定。即使其中某些步骤调用了 LLM，整个流程的控制权仍在外部的确定性代码手中。Anthropic 在《Building Effective Agents》中把这称为 “Prompt chaining” 和 “Routing”，并明确指出它们不是 Agent。

Agent 的关键区别在于：执行路径由模型在运行时动态决定。

面对目标 → 模型自己决定下一步做什么 → 执行 → 观察 → 再决定

模型不是在”执行预设流程”，而是在”动态规划路径”。这是本质区别：

维度	Workflow	Agent
路径	预先确定	运行时动态决定
决策者	外部代码	LLM
灵活性	低（改需求要改代码）	高（改需求改 Prompt）
可控性	高	低
成本	低、可预测	高、难预测

一个实用的工程判断是：能用 Workflow 解决的问题，不要用 Agent。Workflow 更便宜、更可控、更可测试。只有当任务确实需要模型”临场发挥”（比如”帮我排查这个 bug，我不知道问题在哪”）时，Agent 才体现出不可替代的价值。

1.3.2 Agent 与传统自动化

传统自动化（RPA、脚本、CI/CD 流水线）和 Agent 的区别，本质上与 Workflow 的区别同源，但还有一个更深的维度：面对不确定性的能力。

传统自动化假设世界是确定性的：

输入格式固定 → 脚本能处理。
页面结构固定 → 爬虫能解析。
步骤固定 → 流水线能执行。

一旦世界偏离预期——输入格式变了、页面改版了、出现预期外的异常——传统自动化就失败了，需要人介入修复脚本。

Agent 的独特价值恰恰在于处理不确定性：

输入格式不定 → Agent 自己判断该怎么解析。
环境变化 → Agent 自己探索新情况。
目标模糊 → Agent 自己澄清、分解。

所以一句话总结：传统自动化擅长”已知的重复”，Agent 擅长”未知的探索”。 两者不是替代关系，而是互补关系。一个成熟的企业技术栈里，应该是”确定性工作流 + 不确定性 Agent”的组合。

1.4 LLM 为什么能够成为 Agent 的”大脑”

前面我们反复说”LLM 是决策中枢”。但要理解 Agent，必须理解 LLM 到底”会什么”。很多人对 LLM 的理解停留在”它会写文章、会聊天”，这大大低估了它作为 Agent 决策中枢的潜力。这一节从最底层的 Transformer 讲起，逐步解释为什么 LLM 天然具备成为 Agent 大脑的四个关键能力：Reasoning、Structured Output、Tool Calling、Context 处理。

1.4.1 Transformer 基础

2017 年，Vaswani 等人在《Attention Is All You Need》中提出 Transformer 架构，彻底改变了 NLP 的格局。Transformer 的核心贡献是用自注意力机制（Self-Attention）替代了 RNN 的序列递推，从而实现了：

并行化训练：RNN 必须按顺序处理 token，Transformer 可以一次性看到整个序列。
长距离依赖建模：注意力机制让任意两个 token 之间都能直接建立联系，而不受距离衰减的影响。

Transformer 的经典结构是 Encoder-Decoder，但现代 LLM（GPT 系列）只用了其中的 Decoder 部分，形成了”自回归”的语言模型：

输入: [t1, t2, t3, ..., tn]
输出: 预测 tn+1 的概率分布

输入: [t1, t2, t3, ..., tn]
输出: 预测 tn+1 的概率分布

所谓”自回归”，就是模型根据前面所有的 token，预测下一个 token，然后把预测的 token 接上去，再预测下一个。这个看似简单的机制，正是”流式生成”和”逐步推理”的物理基础。

1.4.2 Token

Token 是 LLM 处理文本的最小单位。它不是字符，也不是完整的单词，而是介于两者之间的一种”子词”单元。英文中一个 token 大约是 0.75 个单词（约 4 个字符），中文中一个汉字大约是 1-2 个 token。

Token 有两个极其重要的工程含义，贯穿全书：

Token 是计费单位：API 按输入 token 和输出 token 分别计费。
Token 是上下文容量的度量：模型的 Context Window（上下文窗口）以 token 为单位。所谓”上下文溢出”，本质就是”token 用完了”。

理解 token，是理解 Context Engineering 的第一步。一个合格的后端工程师在写 LLM 应用时，脑子里应该时刻有一本账：当前上下文用了多少 token，还剩下多少 token，每一轮工具调用会吃掉多少 token。

1.4.3 Context Window

Context Window（上下文窗口）是模型一次能”看到”的最大 token 数量。早期的 GPT-3 是 4096，后来的模型扩展到 8K、32K、128K，甚至 1M、2M。

但这里有一个重要认知：Context Window 的扩大，并没有让”上下文管理”这个问题消失。原因有三：

成本：即使窗口有 200K，把 200K token 塞进去，每一次请求的成本和时间都会急剧上升。
注意力稀释：大量研究表明，模型对上下文中部的内容关注度会下降（”Lost in the Middle”现象），把无关内容塞进去反而降低回答质量。
信号噪声比：把几十个无关文件全塞给模型，它反而找不到关键信息。

因此，Context Window 的大小只是”上限”，真正的功夫在于**”往窗口里放什么”**——这正是 Context Engineering（第 6 章）要解决的问题。

1.4.4 Attention

注意力机制（Attention）是 Transformer 的灵魂。它的直觉非常朴素：当模型处理一个 token 时，它应该”重点关注”上下文中与当前 token 最相关的部分。

自注意力（Self-Attention）的计算可以概括为三个矩阵操作：

Q = X · Wq   （Query：我要找什么）
K = X · Wk   （Key：我有什么）
V = X · Wv   （Value：我的内容是什么）

Attention(Q, K, V) = softmax(Q · Kᵀ / √d_k) · V

Q = X · Wq   （Query：我要找什么）
K = X · Wk   （Key：我有什么）
V = X · Wv   （Value：我的内容是什么）

Attention(Q, K, V) = softmax(Q · Kᵀ / √d_k) · V

每个 token 的 Query 和所有 token 的 Key 做点积，得到”注意力权重”，再用这个权重对 Value 加权求和。结果就是：每个 token 的新表示，都是所有相关 token 的加权融合。

对 Agent 架构而言，注意力的意义不在于数学细节，而在于一个认知：模型的每一次输出，都是对”当前上下文”这一整块内容的加权理解。这决定了两个重要结论：

上下文就是模型的全部世界：模型看不到上下文之外的任何东西。你给它的工具描述、文件内容、历史对话，共同构成了它推理的唯一依据。
上下文的质量直接决定决策的质量：塞进无关信息，会稀释注意力；缺失关键信息，会让模型”瞎猜”。

1.4.5 Reasoning

Reasoning（推理）是 LLM 成为 Agent 大脑的核心能力。它指的是模型”从已知推导出未知”的能力：给定一个目标，模型能够分解步骤、分析约束、权衡方案、得出结论。

现代 LLM 的推理能力主要来自两个机制：

规模涌现：随着模型参数和训练数据的扩大，推理能力逐渐”涌现”出来。
思维链（Chain-of-Thought, CoT）：当模型被诱导”一步一步地思考”时，它会产生中间推理步骤，显著提高复杂任务的正确率。这是 2022 年 Wei 等人的重要发现。

CoT 的意义对 Agent 是革命性的：它证明了 LLM 的推理是可以被”外化”和”引导”的。如果一句”让我们一步步思考”就能让模型表现更好，那么一个精心设计的 Agent 循环——”观察→思考→行动→再观察”——本质上就是把 CoT 结构化了。

后续的推理模型（如 o1 系列、Claude 的 extended thinking）更进一步，把”思考过程”内化为模型自身的机制，让模型在给出最终答案前，先进行长时间的内部推理。这直接提升了 Agent 在复杂任务上的表现，但也带来了更高的成本和延迟——这将在第 48 章”Long-running Agent”中详细讨论。

1.4.6 Structured Output

Structured Output（结构化输出）指的是让 LLM 输出符合特定格式（如 JSON）的内容，而不是自由文本。

为什么这对 Agent 至关重要？因为 Agent 是一个软件系统，软件系统需要解析模型的输出来驱动下一步动作。如果模型输出的是一段自由文本”我觉得应该调用读取文件这个工具”，程序很难可靠地解析它；但如果模型输出的是：

{"tool": "read_file", "arguments": {"path": "/src/main.ts"}}

{"tool": "read_file", "arguments": {"path": "/src/main.ts"}}

程序就能立即、可靠地执行。

结构化输出的实现方式主要有三种：

Prompt 约束：在 Prompt 里要求模型”只输出 JSON，不要输出其他内容”。简单，但不够可靠，模型偶尔会”不听话”。
JSON Mode：API 层面提供约束，保证输出是合法 JSON。比 Prompt 约束可靠，但不保证 JSON 的 schema 正确。
结构化生成（Constrained Decoding）：在解码阶段直接限制 token 的采样空间，保证输出严格符合给定的 JSON Schema。最可靠，但实现复杂、有一定性能开销。

一个生产级 Agent 的 Tool Calling 系统，几乎必然依赖结构化输出——因为模型决定”调用哪个工具、传什么参数”这件事，本质上就是一个结构化输出问题。

1.4.7 Tool Calling

Tool Calling（工具调用）是 LLM 从”只会说”进化到”能做事”的关键一跃，也是整个 Agent 架构的支点。

它的工作机制是这样的：模型被训练成在需要调用工具时，不输出自由文本，而是输出一个结构化的工具调用请求（包含工具名和参数）。API 把这个请求返回给调用方（即 Harness），由调用方实际执行工具，再把执行结果作为一条新消息送回模型，模型基于结果继续推理。

用户: 帮我读一下 package.json 的版本号
        ↓
模型输出 tool_call: {name: "read_file", args: {path: "package.json"}}
        ↓
Harness 执行 read_file，得到结果
        ↓
把结果送回模型: "文件内容如下：{...}"
        ↓
模型输出最终回答: "版本号是 2.1.0"

用户: 帮我读一下 package.json 的版本号
        ↓
模型输出 tool_call: {name: "read_file", args: {path: "package.json"}}
        ↓
Harness 执行 read_file，得到结果
        ↓
把结果送回模型: "文件内容如下：{...}"
        ↓
模型输出最终回答: "版本号是 2.1.0"

注意这个过程中的一个关键点：模型本身并没有”读文件”，它只是”请求读文件”。真正执行的是外围的 Harness。 这个区分看似咬文嚼字，却是理解 Agent 安全架构（第 11 章）和”为什么模型不是 Agent”（1.7 节）的关键。

Tool Calling 的具体机制、Schema 设计、错误处理，将在第 2 章和第 7 章深入展开。这里只需要先建立最核心的认知：Tool Calling 是连接”语言模型”和”真实世界”的桥梁。

1.5 一个 Agent 最基本的结构

现在，我们把前面的所有概念拼起来，看看一个 Agent 最基本的结构长什么样。

User
 ↓
LLM
 ↓
Decision
 ↓
Tool
 ↓
Observation
 ↓
LLM
 ↓
Decision
 ...

User
 ↓
LLM
 ↓
Decision
 ↓
Tool
 ↓
Observation
 ↓
LLM
 ↓
Decision
 ...

这个图是整个 Agent 领域的”最小公倍数”。所有的 Agent 框架——无论多复杂——本质上都是这个循环的扩展和加固。

拆开看，这个结构包含六个要素：

User（用户）：提供一个目标或任务。
LLM（模型）：接收当前上下文，做推理决策。
Decision（决策）：模型的输出。它有两种可能——要么是”最终答案”，要么是”调用某个工具”。
Tool（工具）：执行模型请求的动作，接触真实世界。
Observation（观察）：工具执行的结果，作为新信息送回模型。
循环：模型基于新的观察继续决策，直到给出最终答案。

用一个具体的例子走一遍”帮我查一下今天的天气，如果下雨就提醒我带伞”：

User: 查天气并判断要不要带伞
 ↓
LLM: (决策) 我需要调用 weather_query 工具，参数 city=北京
 ↓
Tool: 返回 {weather: "中雨", temp: 18}
 ↓
Observation: 中雨，18度
 ↓
LLM: (决策) 今天有中雨，建议带伞。
 ↓
最终回答

User: 查天气并判断要不要带伞
 ↓
LLM: (决策) 我需要调用 weather_query 工具，参数 city=北京
 ↓
Tool: 返回 {weather: "中雨", temp: 18}
 ↓
Observation: 中雨，18度
 ↓
LLM: (决策) 今天有中雨，建议带伞。
 ↓
最终回答

就这么简单。但请注意，这里已经隐含了三个 Agent 架构的核心问题：

模型怎么知道有哪些工具可用？ —— 需要把工具的描述注入上下文（Tool Discovery）。
工具由谁执行、怎么执行、失败了怎么办？ —— 需要 Tool Runtime。
模型会不会陷入”一直调工具不停下来”的死循环？ —— 需要 Stop Condition 和 Loop 控制。

这三个问题，正是 Agent Harness（Part II）要解决的核心议题。

1.6 Agent 的本质：Agent = LLM + Harness

基于前面的分析，现在可以给出本书对 Agent 的本质定义。

1.6.1 公式的两种写法

本书最核心的公式，一句话：

Agent = LLM + Harness

这个公式告诉我们：一个 Agent，本质上只有两部分——一个负责”想”的 LLM，和一个负责”做”（以及”安全地做”）的 Harness。 LLM 是决策中枢，Harness 是把它变成”会做事的系统”的那套外围软件。

这个公式还有一种展开写法，帮助我们看清 Harness 里到底有什么：

Harness = Context + Tools + Loop + State + Guardrails

把它代回上一个公式，就得到完整形式：

Agent = LLM +（Context + Tools + Loop + State + Guardrails）

为什么要用这两种写法？因为它们回答的是不同层面的问题：

“Agent = LLM + Harness” 是架构视角：它把 Agent 一刀切成”模型”和”模型之外的一切”，直接呼应 1.7 节”模型本身不是 Agent”的论断。
“Harness = Context + Tools + Loop + State + Guardrails” 是实现视角：它列出了 Harness 至少必须包含的五个核心子系统。

注：在第 4 章我们会看到，一个生产级 Harness 其实比这五个子系统更多——还有 Session、Hooks、Subagents、Observability 等。这里先给出”最小集合”，足够建立认知即可。

1.6.2 什么是 Harness

在展开那五个子系统之前，先给 Harness 一个清晰的正式定义。

“Harness”的英文原意是**”马具/挽具”**——套在马身上、用来驾驭它的缰绳和鞍具。这个隐喻极其精准：LLM 是一匹马力强劲、但不受控的马；Harness 就是驾驭它的那套马具。

在 AI Agent 语境下：

Harness（运行时框架）是包裹在 LLM 之外、把它从”只会说”变成”会做”的那套软件系统。它负责：给模型提供上下文（模型能看到什么）、执行模型的工具请求（模型能做什么）、驱动模型的决策循环（模型如何持续推进）、为模型的行动设边界（模型不能做什么）、记录与持久化模型的行为（模型做过什么）。

一句话概括分工：模型负责”想”，Harness 负责”做”，以及”安全地、可靠地做”。

关于 Harness 的完整论述——Model / Agent / Harness 三者的边界、Harness 的九大职责、为什么它比 Prompt 更重要——留给第 4 章。这里先把它的五个核心子系统逐一展开。

1.6.3 Context（上下文）

上下文是模型的”工作内存”。模型的所有决策，都基于它当前看到的上下文。因此，上下文工程（Context Engineering）是 Agent 能力的核心杠杆——同样一个模型，上下文管理得好坏，能力差距可能是数量级的。

上下文不是”把东西堆进去”这么简单，它涉及预算管理、优先级排序、压缩、污染防护等一系列工程问题（第 6 章、第 21 章、第 35 章）。

1.6.4 Tools（工具）

工具是 Agent 的”手和脚”。模型的能力边界，本质上就是工具的能力边界——模型再聪明，如果没有文件工具，它也无法读写文件；没有网络工具，它也无法联网。

工具系统的核心问题：如何定义工具（Schema）、如何发现工具（Discovery）、如何调度工具（Dispatcher）、如何执行工具（Executor）、如何处理工具结果和错误（Result & Error）。这是第 7 章、第 20 章、第 33 章的内容。

1.6.5 Loop（循环）

循环是 Agent 的”心跳”。它把模型的一次次决策串起来，形成一个持续推进的过程。循环的核心问题是：什么时候继续、什么时候停止、出错了怎么办、上下文满了怎么办。

一个有趣的事实是：Agent 的循环代码本身可能只有几十行，但围绕这个循环的所有保护性、增强性代码，可以膨胀到几十万行。这是全书最重要的一个洞察（第 3 章、第 34 章）。

1.6.6 State（状态）

状态让 Agent 从”无记忆的一次性对话”进化为”有记忆的持续工作”。状态包括：会话历史、任务进度、检查点、长短期记忆。

状态的持久化（Persistence）是长任务 Agent（第 48 章）和生产级 Agent（Part VI）的基础。没有状态，Agent 一旦中断就前功尽弃；有了状态，Agent 才能”断点续跑”、才能”过夜执行”。

1.6.7 Guardrails（护栏）

护栏是 Agent 的安全边界。它回答的问题是：这个 Agent 能做什么、不能做什么、什么情况下需要人介入？

护栏包括权限控制（Permission）、沙箱隔离（Sandbox）、人机协作（Human-in-the-loop）、审计日志（Audit）。护栏不是”锦上添花”，而是 Agent 能否进入生产环境的”生死线”（第 11 章、第 39 章、第 51 章）。

1.7 为什么”模型本身”不是 Agent

这是本章最重要的一节，因为它纠正一个流传甚广的误解：“LLM 已经很聪明了，所以 LLM 就是 Agent。”

这个误解之所以有害，是因为它导致人们忽视 Agent 架构中最有价值、也最复杂的部分——外围的软件系统（也就是 Harness）。让我们逐条拆解。

1.7.1 模型不会真正访问文件

当你对一个 LLM 说”读一下这个文件”，它不会真的去读。它能做的，只是输出一段文本，比如”好的，我来读取文件”。真正读文件的是外围代码调用的 fs.readFile。

模型对文件内容的”了解”，完全来自于外围系统把文件内容放进了它的上下文。如果外围系统不放，模型就一无所知。这意味着：

模型对真实世界的全部感知，都是外围系统”喂”给它的。

这个事实对安全架构的启示是巨大的：既然模型只能通过外围系统接触世界，那么安全边界就应该设在外围系统上，而不是指望模型”自觉”。

1.7.2 模型不会真正执行 Shell

同样，模型不会执行任何 shell 命令。当它输出”运行 rm -rf /“，它只是输出了几个字符。真正危险的是：外围系统把这段字符当真，去执行了它。

这就是为什么 Agent 必须有 Permission 系统：模型可以”提议”执行命令，但”是否真正执行”必须由外围系统决定。模型在这里扮演的角色不是”执行者”，而是”提议者”。

1.7.3 模型不会真正修改数据库

模型无法直接连接数据库、执行 SQL、修改数据。它只能输出一段 SQL 文本。真正连接数据库的是外围的数据库工具。

这引出一个重要的架构原则：模型生成意图，系统执行意图。 两者之间的鸿沟，就是 Agent Harness 存在的全部意义。

1.7.4 模型不会真正操作浏览器

浏览器自动化（Browser Automation）是 Computer Use 类 Agent 的核心能力，但模型本身无法点击页面、填写表单。这些操作由浏览器自动化工具（如 Playwright）执行，模型只是输出”点击这个按钮”的意图。

1.7.5 模型不会自动承担权限责任

这是最容易被忽视、也最危险的一点。模型本身没有”责任感”，也没有”法律主体性”。如果 Agent 删除了生产数据库、泄露了密钥、发送了错误的邮件，承担责任的是部署这个 Agent 的人或组织，而不是模型。

因此，一个负责任的 Agent 架构，必须把”权限”和”责任”放在外围系统的显式控制之下：默认拒绝、最小权限、人机审批、全程审计。

小结：真正把模型变成 Agent 的，是 Harness

把以上五点合起来，结论非常清晰：

模型是一个极其聪明的”决策引擎”，但它被”关在”一个只能输入文本、输出文本的黑盒里。真正把模型变成 Agent 的，是外围的软件系统——也就是 Harness。Harness 给模型提供上下文、执行模型的工具请求、为模型的行动设边界、记录模型的行为。

这个结论，是全书所有架构讨论的出发点。它解释了：

为什么需要 Harness（第 4 章）——因为模型需要被”驾驭”。
为什么 Context Engineering 如此重要（第 6 章）——因为模型只能通过上下文感知世界。
为什么 Permission 是不可或缺的（第 11 章）——因为执行动作的责任在人，不在模型。
为什么 Agent Loop 简单而 Harness 复杂（第 3 章）——因为真正的工程难点，都在模型之外。

本章小结

本章建立了五个核心认知，它们将贯穿全书：

发展历程：从 Transformer（2017）到 ChatGPT（2022），从 AutoGPT 的翻车（2023）到 Coding Agent 的成熟（2024–2025）——每一步都在”补能力”，同时也”暴露缺口”。AutoGPT 的教训直接证明了：光有 LLM 和循环不够，还缺 Harness。
能力谱系：Chatbot（会说）→ Copilot（会辅助）→ Agent（会做）→ Autonomous Agent（会自主）→ Coding Agent（会编程）。每个阶段都增加了一个关键能力维度。
Agent 与 Workflow 的区别：路径由谁决定——模型在运行时动态决定的是 Agent，预先写死的是 Workflow。能用 Workflow 的，别用 Agent。
LLM 为什么能当大脑：Transformer + Attention + 自回归生成，赋予了模型推理、结构化输出和工具调用的能力；而 Tool Calling 是连接模型与世界的桥梁。
Agent 的本质：Agent = LLM + Harness，其中 Harness = Context + Tools + Loop + State + Guardrails。模型本身不是 Agent，真正把它变成 Agent 的，是外围的 Harness。

带着这些认知，下一章我们将深入 LLM Application 的基本架构，看看一个”能跑起来”的 LLM 应用到底由哪些组件构成，以及 Tool Calling 在技术层面是如何工作的。