Agent 速成笔记 · 第 1 章 初识智能体

Agent 速成笔记 · 第 1 章 初识智能体

源：Datawhale《Hello-Agents》第 1 章 ｜ 定位：概念与原理 ｜ 一句话：把「智能体是什么、怎么跑、怎么选范式」一次讲清，并亲手跑通第一个 LLM 智能体。

0. 一章速览（30 秒）

  • 一句话：智能体（Agent）是通过传感器感知环境、自主通过执行器采取行动以达成目标的实体；LLM 时代把它变成了「大模型当大脑 + 工具当手脚 + 感知-思考-行动-观察循环」的通用系统。
  • 本章解决什么问题：先建立概念坐标系（定义、演进、分类、环境建模），再给出最小可运行实现，最后回答工程上最常被问的那句——「这件事该用 Workflow 还是 Agent」。
  • 必须记住的 5 个点：
    • 四要素里自主性才是「智能」的来源，缺了它只是一个自动化脚本；
    • 传统五类智能体是一条被前一代缺陷逼出后一代的阶梯，共同天花板是「依赖人类先验知识」；
    • LLM 带来的质变不是「更快」，而是隐式世界模型 + 涌现能力，于是它能直接吃「高层级、模糊、带上下文」的自然语言指令；
    • 运行机制只有一条主线：Agent Loop；它的工程实现是三行协议 Thought / Action / Observation，终点是 Finish[...]；
    • Workflow 与 Agent 的唯一分水岭是控制流：路径写死的是 Workflow，路径由模型临场决定的是 Agent。

1. 什么是智能体（对应原文 1.1）

1.1 定义与四要素

  • 是什么：智能体是任何能够通过传感器（Sensors）感知其所处环境（Environment），并自主地通过执行器（Actuators）采取行动（Action）以达成特定目标的实体。
  • 四要素逐个拆：
    • 环境：智能体所处的外部世界。自动驾驶汽车面对的是动态变化的道路交通；交易算法面对的是瞬息万变的金融市场。换个环境，设计就得重做。
    • 传感器：感知通道。摄像头、麦克风、雷达，以及各类应用程序编程接口（Application Programming Interface, API）返回的数据流，都是感知能力的延伸——在数字世界里，API 就是感官。
    • 执行器：施加影响的通道。既可以是物理设备（机械臂、方向盘），也可以是虚拟工具（执行一段代码、调用一个服务）。
    • 自主性（Autonomy）：真正赋予智能体「智能」的一项。它不是被动响应外部刺激、也不是严格执行预设指令的程序，而能基于感知 + 内部状态进行独立决策以达成设计目标。
  • 为什么重要：从感知到行动的闭环，构成了所有智能体行为的基础。判断一个东西是不是智能体，只需问一句——它有没有「自主地把感知转成行动、去逼近目标」这个闭环。
  • 工程要点：设计时不要从「我用什么模型」开始，而要从「环境是什么、感知怎么来、行动能改什么、目标怎么衡量」开始——这正是 PEAS 的用途。

1.2 传统智能体：被「缺陷」驱赶的演进线

LLM 热潮之前，研究者已探索了几十年。这五类不是并列选项，而是从简单到复杂、从被动反应到主动学习的阶梯：每一类的局限，恰好是下一类要解决的问题。

类型 核心机制 它回答的问题 缺陷
简单反射（Simple Reflex） 工程师写死的「条件-动作」规则 现在该做什么动作 只依赖当前感知，无记忆、无预测，扛不住需要理解上下文的复杂任务
基于模型的反射（Model-Based Reflex） 内部世界模型（World Model），追踪无法直接感知的部分 世界现在是什么样子 理解了世界，却没有目标，仍不会主动规划
基于目标（Goal-Based） 主动搜索/规划出导向特定未来状态的行动序列 我该做什么才能达成目标 只服务单一目标，而现实目标往往不止一个
基于效用（Utility-Based） 给每个世界状态赋效用值，最大化期望效用 哪种行为带来最满意的结果 效用函数仍需人工设计，本质还是先验知识
学习型（Learning） 性能元件 + 学习元件，用结果反馈修正策略 我怎样从经验中变强 前四类的先验知识问题并未凭空消失，还要付出大量交互与训练代价
  • 怎么运作（这两类值得单独记）：
    • 基于模型的反射靠世界模型获得初级记忆：哪怕摄像头暂时感知不到前方车辆，内部模型依然维持对那辆车存在、速度、预估位置的判断，决策不再只依赖瞬时感知，而是基于更连贯的世界状态。
    • 学习型是双元件结构：性能元件就是前面某一类智能体在做决策；学习元件观察它的行动结果，不断修正性能元件的决策策略。下棋 AI 起先随机落子，赢下一局就得到正向奖励，经大量自我对弈逐渐发现哪些棋路更可能通向胜利——AlphaGo Zero 是这条路径的里程碑。
  • 典型例子速记：恒温器（简单反射）→ 隧道中行驶的自动驾驶汽车（基于模型）→ GPS 导航用 A* 算法规划最优路径（基于目标）→ 要在「到得快、省油、避开拥堵」之间权衡的行程规划（基于效用）→ AlphaGo Zero（学习型）。
  • 共同天花板（本章第一个必背结论）：无论决策逻辑是规则、模型还是效用函数，都依然依赖人类设计师的先验知识。于是有了下一个追问——如果智能体能不依赖预设，而是通过与环境的互动自主学习呢？这条追问同时通向传统路线的终点（学习型）和 LLM 新范式的起点。

1.3 LLM 驱动的新范式：质变点在哪

以 GPT（Generative Pre-trained Transformer） 为代表的大语言模型，正在显著改变智能体的构建方法与能力边界。

维度 传统智能体 LLM 智能体
能力来源 工程师的显式编程与知识构建 海量数据预训练得到的隐式世界模型与涌现能力
行为边界 确定、有边界 更灵活、更通用
可处理的指令 需要被明确规格化 直接处理高层级、模糊、充满上下文的自然语言
  • 为什么这是质变而非提速：传统范式把「怎么决策」写进了代码；LLM 范式把决策内核换成通用的「大脑」，于是核心不再是编写代码，而是引导一个通用的『大脑』去规划、行动和学习。它不必提前穷举规则，因为隐式世界模型已在预训练中吸收了关于世界的常识结构。
  • 三个标志性能力，用一个「智能旅行助手」串起来（原文即用此例）：
    • 规划与推理：把「规划一次厦门之旅」这类含糊目标内在分解为 [确认出行偏好] -> [查询目的地信息] -> [制定行程草案] -> [预订票务住宿]；这是模型驱动的规划过程，不靠外部流程图。
    • 工具使用：识别到信息缺口时主动调用外部工具补全。例如查天气接口拿到「预报有雨」，并把这个结果带入后续规划——倾向推荐室内活动。
    • 动态修正：把用户反馈（如「这家酒店超出预算」）视为新的约束，据此调整后续行动、重新搜索符合新要求的选项。整条「查天气 → 调行程 → 订酒店」的流程会随上下文实时调整。

1.4 智能体的类型：三个互补的分类维度

规范提法是「三个互补维度」——答题时用哪一维，取决于你正在讨论什么问题。

(1) 按内部决策架构分类：直接复用 1.2 的阶梯——反应式 → 模型式 → 基于目标 → 基于效用。该视角由《Artificial Intelligence: A Modern Approach》系统提出。注意：学习能力是可赋予以上所有类型的元能力，不是与它们并列的第五类。

(2) 按时间与反应性分类：核心权衡是反应性（Reactivity）与规划性（Deliberation）之间的平衡。

子类 决策方式 优势 代价 / 缺陷
反应式 感知到行动近乎直接映射，不做或极少做未来规划 速度快、计算开销低 短视，易陷局部最优，难完成多步协调任务
规划式（审议式） 先用世界模型系统探索未来可能性，评估不同行动序列的后果 有战略性、有远见 时间与计算成本高昂，可能错过行动时机
混合式 分层：底层快速反应模块 + 高层审慎规划模块 兼顾即时性与长远目标 架构更复杂
  • 例子对照：反应式——安全气囊必须在碰撞毫秒内反应，高频交易机器人靠反应式决策抓稍纵即逝的机会；规划式——棋手不只算眼前一步，而是预想对手应对并规划后续十几步，故能制定商业计划、长途旅行方案。
  • LLM 智能体属于混合式，且是更灵活的混合：它把宏大任务拆成一串「规划-反应」微循环——思考阶段是审议过程（LLM 分析现状、规划下一步合理行动），行动与观察阶段是反应过程（与外部工具或环境交互并立即获得反馈）。因此既能灵活应对环境即时变化，又能靠连贯步骤完成长期目标。

(3) 按知识表示分类：这是更根本的一维，问的是「智能体据以决策的知识，以什么形式存在」。

范式 知识形态 强项 弱项
亚符号主义（连接主义） 内隐分布在大量神经元中，是从海量数据学到的统计模式 模式识别强、对噪声鲁棒、能处理图像声音等非结构化数据 黑箱不透明；纯逻辑推理弱，易产生看似合理却事实错误的幻觉
符号主义 人类可读符号 + 严格逻辑规则（规则库、知识图谱） 透明可解释，推理步骤可完整追溯，适配金融医疗等高风险领域 脆弱：依赖完备规则体系，任何未覆盖的新情况都可能失灵（知识获取瓶颈）
神经符号主义 两大范式的「大和解」，二者协同 既能像神经网络一样从数据学习，又能像符号系统一样逻辑推理 工程上需自行设计中间符号表示
  • 与卡尼曼双系统的类比（原文给出的理解框架）：系统 1 快速、凭直觉、并行 → 亚符号主义的模式识别；系统 2 缓慢、有条理、基于逻辑 → 符号主义的推理过程；神经符号主义让二者协同工作，正如人类智能也源自两个系统的协同。
  • 为什么说 LLM 智能体是神经符号主义的极佳实践范例：其内核是一个巨大的神经网络（提供模式识别与语言生成能力），而工作过程中它又会生成一系列结构化的中间步骤——思想、计划、API 调用——这些都是明确的、可操作的符号。于是「神经网络的直觉」与「符号的逻辑」在同一个系统里接上了。

2. 智能体的构成与运行原理（对应原文 1.2）

2.1 用 PEAS 把任务环境说清楚

  • 是什么：PEAS 模型 = Performance（性能度量）、Environment（环境）、Actuators（执行器）、Sensors（传感器），是 AI 领域精确描述任务环境的标准四元组。
  • 怎么用：四个槽位分别回答——用什么指标判断它干得好不好（性能度量）；它在什么样的外部世界里活动（环境）；它能施加哪些操作（执行器）；它能看到什么（传感器）。原文即以「智能旅行助手」为例，用 PEAS 对其任务环境做规约。
  • 为什么先做这一步：环境定义不清，后面「要不要加记忆」「要不要容错」「循环边界怎么设」全都变成拍脑袋。设计任何智能体之前，先用 PEAS 把环境说清楚。

2.2 数字环境的四个特性（每个都直接推出设计要求）

  • 部分可观察：旅行助手查航班时，无法一次性获取所有航空公司的全部实时座位信息，只能通过调用航班预订 API 看到它返回的那部分数据。→ 直接要求智能体具备记忆（记住已查询过的航线）与探索（尝试不同查询日期）的能力。
  • 随机性（对应确定性）：按结果可预测性区分确定性/随机性环境。搜索票价时，两次相邻调用返回的价格与余票数量都可能不同。→ 要求智能体能处理不确定性、监控变化并及时决策。
  • 多智能体（Multi-agent）：环境里还有其他行动者——其他用户的预订行为、其他自动化脚本，甚至航司的动态调价系统，都是环境中的其他「智能体」。它们的行动（如订走最后一张特价票）会直接改变你所处环境的状态。→ 对快速响应与策略选择提出更高要求。
  • 序贯且动态：「序贯」意味着当前动作会影响未来；「动态」意味着环境自身可能在智能体决策时发生变化。→ 要求「感知-思考-行动-观察」循环必须能快速、灵活地适应持续变化的世界。
  • 易错点：这四条不是四个名词，而是一组设计需求映射。只背「部分可观察/随机/多智能体/序贯动态」而不写出各自推出的能力要求，基本等于没答。

2.3 Agent Loop（智能体循环）

智能体并非一次性完成任务，而是通过一个持续循环与环境交互，这个核心机制就叫智能体循环（Agent Loop）。

感知 Perception → 思考 Thought → 行动 Action → 环境状态变化 → 新观察 Observation → 回到感知
  • 每一步谁在做、输出什么：
    1. 感知：循环起点。通过传感器（例如 API 的监听端口、用户输入接口）接收环境输入，即观察（Observation）。它既可能是用户的初始指令，也可能是上一步行动引起的环境状态变化反馈。
    2. 思考：核心决策阶段，对 LLM 智能体而言即大模型驱动的内部推理，可细分为两个环节——规划（Planning）：基于当前观察与内部记忆更新对任务和环境的理解，制定或调整行动计划，常包含「把复杂目标分解为更具体的子任务」；工具选择（Tool Selection）：从可用工具库中选择最适合执行下一步的工具，并确定调用所需的具体参数。
    3. 行动：通过执行器执行具体行动，通常表现为调用某个选定工具（如代码解释器、搜索引擎 API），从而对环境施加影响、意图改变环境状态。
    4. 观察反馈：行动引起环境的状态变化，环境随即产生新观察作为结果反馈，又被下一轮感知捕获，形成持续闭环。智能体正是靠重复这一循环，从初始状态向目标状态演进。
  • 工程要点：循环必须有终止条件（原文最小实现把最大循环次数设为 5），否则智能体可能陷入无限自我提示，既烧钱又交付不了结果。
  • 易混点：「思考」不是一步，而是「规划 + 工具选择」两步的合成。

2.4 交互协议：Thought-Action-Observation

在工程实践中，要让 LLM 有效驱动这个循环，需要一套明确的交互协议（Interaction Protocol）来规范它与环境的信息交换。做法是：智能体的输出不再是单一的自然语言回复，而是一段遵循特定格式的文本，同时暴露内部推理过程与最终决策。

字段 含义 谁消费它
Thought: 内部决策的「快照」：以自然语言分析情境、回顾上一步观察、自我反思与问题分解、规划下一步行动 留在上下文里，供人阅读
Action: 基于思考决定施加的具体操作，通常以函数调用形式表示，如 get_weather("北京") 外部解析器（Parser）捕捉并调用相应函数
Observation: 环境返回结果，被感知系统封装成简洁、清晰的自然语言 作为下一轮循环的主要输入 
Thought: 用户想知道北京的天气。我需要调用天气查询工具。
Action: get_weather("北京")
Observation: 北京当前天气为晴，气温25摄氏度，微风。
  • 一段完整交互怎么跑：模型输出 Thought + Action → 解析器捕捉到 Action，调用 get_weather → 工具可能返回一个包含详细天气数据的 JSON 对象 → 感知系统把它处理并封装成一段简洁自然语言，即 Observation → 这段文本反馈给智能体，作为下一轮 Thought 与 Action 的主要输入。
  • 为什么必须封装：原始机器可读数据（如 JSON）通常含 LLM 无需关注的冗余信息，格式也不符合其自然语言处理习惯。感知系统的重要职责就是扮演传感器，把原始输出变成干净的观察。
  • 结束信号：Finish[最终答案]。收集到足够信息后必须以此结束，而不是自由发挥式地宣称完成。
  • 工程要点：该协议把「内部的语言推理能力」与「外部环境的真实信息和工具操作能力」有效结合，是最小可用智能体的全部骨架；上下文里累积的完整 Thought/Action/Observation 轨迹，就是「记忆」最朴素的形态。

3. 5 分钟实现第一个智能体（对应原文 1.3）

任务设定：用户说「帮我查询今天北京的天气，然后根据天气推荐一个合适的旅游景点」。要完成它，智能体必须展现清晰的逻辑规划——先调天气查询工具，把获得的观察作为下一步依据；下一轮再调景点推荐工具，从而得出最终建议。

3.1 最小实现的四件套

  1. 指令模板（system_prompt）：即智能体的「说明书」，由提示工程（Prompt Engineering）设计，必须写清三块——扮演什么角色与总任务、有哪些可用工具（含函数名、参数、用途）、以及严格的输出格式：每次回复必须包含一对 Thought 和 Action；Action 只能是「调用工具 function_name(arg_name="arg_value")」或「结束任务 Finish[最终答案]」二者之一；每次只输出一对；Action 必须同行不换行；收集到足够信息时必须用 Finish 结束。

  2. 工具函数：get_weather(city) 走免费天气服务 wttr.in（请求 JSON 格式 format=j1，从 current_condition[0] 取 weatherDesc 与 temp_C），并格式化成自然语言返回；get_attraction(city, weather) 走 Tavily 搜索 API（search(query, search_depth="basic", include_answer=True)，优先直接采用返回的综合回答 answer，没有再格式化原始结果）。两者都用 try/except 把网络错误与数据解析错误转成可读的错误字符串返回。

  3. 工具注册表：用字典建立「模型说出的函数名」到「真正可执行的 Python 对象」的唯一映射，主循环据此派发。

    available_tools = {
    "get_weather": get_weather,
    "get_attraction": get_attraction,
}

    这段是工具调用的派发入口——没有它，Action 里写出的函数名就没人认领。

  4. LLM 客户端：OpenAICompatibleClient(model, api_key, base_url) 封装 OpenAI SDK，只需 API_KEY / BASE_URL / MODEL_ID 三项。之所以叫「兼容」，是因为 OpenAI、Azure 以及 Ollama、vLLM 等开源模型服务框架都遵循与 OpenAI 相似的接口规范——一套客户端可对接几乎任意后端。

3.2 主循环骨架

prompt_history = [f"用户请求: {user_prompt}"]

for i in range(5):                                   # 最大循环次数，防死循环
    full_prompt = "\n".join(prompt_history)
    llm_output = llm.generate(full_prompt, system_prompt=AGENT_SYSTEM_PROMPT)

    # 模型可能多输出若干 Thought-Action 对，截断到第一对
    llm_output = re.search(
        r'(Thought:.*?Action:.*?)(?=\n\s*(?:Thought:|Action:|Observation:)|\Z)',
        llm_output, re.DOTALL).group(1).strip()
    prompt_history.append(llm_output)                # 把自己的思考也写回历史

    action_str = re.search(r"Action: (.*)", llm_output, re.DOTALL).group(1).strip()
    if action_str.startswith("Finish"):              # 终止信号
        break

    tool_name = re.search(r"(\w+)\(", action_str).group(1)
    kwargs = dict(re.findall(r'(\w+)="([^"]*)"', action_str))
    observation = available_tools[tool_name](**kwargs)     # 执行工具
    prompt_history.append(f"Observation: {observation}")   # 观察回喂，进入下一轮

这段是整个 Agent 的心脏：把历史拼成 Prompt → 让 LLM 产出 Thought/Action → 解析并执行工具 → 把 Observation 追加回历史 → 下一轮。所有「智能」都发生在这一进一出之间。

  • 两个必须照做的工程细节：
    • 截断多余输出：LLM 可能一口气输出多对 Thought-Action，必须用正则截到第一对（关键是向后匹配到 Thought: / Action: / Observation: 或字符串结束为止），否则解析会错位。
    • 解析失败要变成观察，而不是崩溃：解析不到 Action 时，把「错误: 未能解析到 Action 字段，请确保严格遵循格式」作为 Observation 追加进历史并 continue，等于让模型自己看到错误并自我纠正；工具名不在注册表里时返回「错误: 未定义的工具」，而不是抛异常。错误也是一种观察。

3.3 一次成功运行的轨迹（三轮）

  • 循环 1：Thought 判断「首先需要获取北京今天的天气情况」→ Action: get_weather(city="北京") → Observation: 北京当前天气:Sunny，气温26摄氏度。
  • 循环 2：Thought 基于「天气晴朗且温度适中」决定推荐景点 → Action: get_attraction(city="北京", weather="Sunny") → Observation 给出颐和园、长城等晴天推荐。
  • 循环 3：Thought 判断信息已足够 → Action: Finish[今天北京天气晴朗，气温26摄氏度……推荐颐和园或长城……] → 循环 break，任务完成。

这个循环集中演示了四项基本能力：任务分解（把一句话拆成查天气、荐景点两步）、工具调用（按需选择工具并传参）、上下文理解（把上一步的天气带进下一步）、结果合成（把两次观察写成一段完整的人话）。正是循环的不断迭代，把一个模糊的用户意图转化为一系列具体、可执行的步骤，并最终达成目标。

  • 精髓一句话：「工具 + 提示工程」的结合，就是最早的 Agent 框架雏形，也正是当前主流智能体框架（如 LangChain、LlamaIndex 等）的设计精髓。理解了这几十行，后面所有框架都只是在它之上加记忆、加规划、加多智能体。

4. 智能体应用的协作模式（对应原文 1.4）

按智能体在任务中的角色与自主性程度，协作模式分两类：深度融入人类工作流的「工具」，与独立完成高层目标的「协作者」。

4.1 作为开发者工具的智能体

智能体被深度集成到开发者工作流中作为辅助工具，增强而非取代开发者的角色：它自动化处理繁琐、重复的任务，让开发者更专注于创造性的核心工作。

工具 形态 侧重与特色
GitHub Copilot 集成于 VS Code 等编辑器的插件 以代码自动补全闻名（整行甚至整函数块），后经 Copilot Chat 扩展出对话式编程
Claude Code Anthropic 的终端 AI 编程助手 理解完整代码库结构，执行编辑/测试/调试；提供 headless 模式适配 CI、pre-commit hooks、构建脚本
Trae 轻量级 AI 编程工具 分析代码模式给出建议与自动化重构；响应快，适合频繁迭代与快速原型开发
Cursor AI 原生代码编辑器 不是给现有编辑器加 AI，而是设计之初就以 AI 交互为核心，强调让 AI 理解整个代码库上下文
  • 读表方法：Copilot / Claude Code / Trae 是在既有工作流上「加 AI」，Cursor 是「为 AI 重造工作流」——这条分野决定了它们交互深度的上限。

4.2 作为自主协作者的智能体

  • 范式变化：不再手把手指导每一步，而是把一个高层级目标委托给智能体；它像一个真正的项目成员，独立完成规划、推理、执行和反思，直到交付成果。人机关系从「命令-执行」演变为「目标-委托」，智能体从被动工具变成主动的目标追求者。
  • 三代架构范式（从早期 BabyAGI、AutoGPT 到如今成熟的 CrewAI、AutoGen、MetaGPT、LangGraph）：
    1. 单智能体自主循环：以 AgentGPT 为代表的早期范式——一个通用智能体通过「思考-规划-执行-反思」闭环，不断自我提示和迭代，完成开放式的高层级目标。
    2. 多智能体协作（当前最主流，又分三种模式）：角色扮演式对话，如 CAMEL，为两个智能体（例如「程序员」和「产品经理」）设定明确角色与沟通协议，在结构化对话中协同完成任务；组织化工作流，如 MetaGPT、CrewAI，模拟分工明确的虚拟团队，每个智能体有预设职责与 SOP，按层级化或顺序化方式协作，产出完整代码库、研究报告等复杂成果；灵活对话模式，如 AutoGen、AgentScope，允许自定义智能体间的复杂交互网络。
    3. 高级控制流架构：如 LangGraph，侧重提供更强的底层工程基础，把执行过程建模为状态图（State Graph），从而更灵活、更可靠地实现循环、分支、回溯以及人工介入等复杂流程。
  • 工程要点：选架构先看任务结构——开放式探索用单智能体循环；任务可切成明确专业分工用组织化工作流；交互关系复杂、需要人随时叫停或改道，用状态图类框架。

4.3 Workflow 和 Agent 的差异

一句话区分：Workflow 是让 AI 按部就班地执行指令；Agent 是赋予 AI 自由度去自主达成目标。

维度 Workflow Agent
本质 对任务或步骤做预先定义的、结构化的编排，是一张精确的静态流程图 具备自主性、以目标为导向的系统
控制流 在何种条件下、以何种顺序执行哪些操作，全部预先设定 LLM 依托实时信息推理，临场制定并调整计划
举例 费用报销审批：金额小于 500 元直接由部门经理审批，大于 500 元先部门经理再流转财务总监，通过后通知财务部打款 智能旅行助手：拿到「晴朗，微风」后自行推断「晴天适合户外」，再筛出颐和园、故宫、天坛等
代价 可控、可预测，但僵硬 灵活，但结果不确定
  • 判别标准（背这一句就够）：看有没有 if 天气=晴天 then 推荐颐和园 这类写死的规则。路径是工程师预先写死的 → Workflow；路径是模型依据实时信息临场推理决定的 → Agent。 旅行助手若遇到雨天，会自主改推国家博物馆、首都博物馆等室内场所——没有任何显式规则在指挥它。这就是 Agent 的核心价值：基于实时信息进行动态推理和决策。
  • 怎么选（工程决策规则）：规则明确、长期稳定、结果需要可预测可审计（审批、结算、合规检查）→ 选 Workflow，代价低且不会「自由发挥额外动作」；信息高度依赖实时查询、路径无法预先穷举、需要理解并权衡自然语言诉求（研究、咨询、多源信息整合）→ 选 Agent。两者也可混合：用 Workflow 固定主流程与边界，只在其中的不确定环节放进 Agent。

5. 高频考点 & 易错点速查

  1. 自主性是定义的灵魂。只有算力（如一台超级计算机）或只有规则执行，都不构成智能体；必须同时有感知-行动闭环与独立决策。
  2. 五类传统智能体的顺序与各自缺陷是选择题高频点。记忆锚：反射 → 模型 → 目标 → 效用 → 学习；每类缺陷正好逼出下一类；五类共同缺陷是依赖人类先验知识。
  3. 学习能力是「元能力」，可赋予反应式、模型式、基于目标、基于效用中的任意一类，不是第六类架构。
  4. PEAS 四个字母要能默写（性能度量 / 环境 / 执行器 / 传感器），并会代入具体场景做规约。
  5. 数字环境四特性必须与设计要求一一挂钩：部分可观察 → 记忆 + 探索；随机性 → 处理不确定性与监控变化；多智能体 → 快速响应与策略选择；序贯动态 → 循环需快速灵活适应。只背四个词不带推论是最常见的丢分点。
  6. Agent Loop 里「思考」含规划与工具选择两步；观察是下一轮的输入，不是循环的终点。
  7. 协议三字段分工要分清：Thought 留上下文供人看，Action 交解析器执行，Observation 由感知系统封装成自然语言后回喂。
  8. Workflow 与 Agent 的分水岭只有控制流：路径是否写死。不要用「任务复杂不复杂」当判据。
  9. 神经符号主义的对应关系：系统 1 = 亚符号主义（直觉、模式识别、黑箱），系统 2 = 符号主义（逻辑、可解释、脆弱）；LLM 智能体 = 神经网络内核 + 结构化中间符号（思想/计划/API 调用）。
  10. 幻觉的定位：它是亚符号主义/黑箱范式的固有倾向（能识别却说不清理由，且纯逻辑推理弱），不是简单归因为「训练不足」；神经符号主义正是针对这一弱点的融合方案。
  11. 常见坑：不设最大循环次数会陷入死循环；不截断多余 Thought-Action 会导致解析错位；把原始 JSON 直接塞回上下文会引入冗余干扰；工具异常不捕获会让整个循环崩掉——正确做法是把错误也变成 Observation 交给模型处理。
  12. 章末习题考点映射（只到考点层）：① 案例判别 → 定义四要素 + 三个分类维度；② 智能健身教练 → PEAS 建模 + 环境特性分析；③ 售后退款方案 → Workflow 与 Agent 的优缺点与适用边界，以及混合方案的设计；④ 给旅行助手加记忆/备选/反思 → Agent Loop 与上下文的扩展方式；⑤ 系统 1 与系统 2 落地 → 知识表示与神经符号主义；⑥ 局限性三问 → 幻觉成因、不设上限的循环风险、仅用准确率评估是否足够。

6. 与前后章节的衔接

本章输出的是概念坐标系 + 最小可运行骨架：四要素与自主性给出「什么算智能体」的判据，五类演进给出「智能从哪来」的历史答案，LLM 新范式给出全书的立足点，PEAS 与数字环境特性给出建模语言，Agent Loop 与 Thought-Action-Observation 给出实现骨架，Workflow vs Agent 给出选型准则。第 2 章往前追智能体的发展历史，即本章 1.2 那条演进线的展开；后续章节则把这几十行的最小骨架逐项加厚——记忆、规划、工具、多智能体协作等。

7. 课后练习

在线试卷：https://md-quiz-online.app.workbuddy.host/

posted @ 2026-09-28 11:56  测试小罡  阅读(13)  评论(0)    收藏  举报