Day 23：Agent 基础认知

学习目标

昨天的 Workflow 是”计划好的流程”，今天要进入一个全新的领域：Agent。Agent 是 2024 年以来 AI 应用领域最热门的概念，也是最容易被误解的概念。

今天的目标不是教你写 Agent 代码，而是建立对 Agent 的本质认知。学完这一天，你应该能回答这些问题：Agent 到底是什么？它和聊天机器人有什么本质区别？它和 Workflow 有什么关系？一个 Agent 由哪些核心组件构成？为什么 Agent 会失控？这些问题的答案构成了后续几天学习 Tool Calling、Multi-Agent、安全防护的基础。

核心概念

Agent 的定义

先给一个清晰的定义：Agent 是一个能够感知环境、做出决策、执行动作、并根据反馈调整行为的 AI 系统。

拆开来看。感知环境，意味着 Agent 能获取当前任务的状态和上下文信息。做出决策，意味着 Agent 能根据当前状态判断下一步该做什么，这个判断不是预编程的，而是模型实时推理出来的。执行动作，意味着 Agent 能调用工具、操作数据、与外部系统交互。根据反馈调整行为，意味着 Agent 不是执行完就结束了，它会观察执行结果，判断是否达到了目标，如果没有就调整策略继续尝试。

用一个类比来理解。Workflow 像火车，轨道是提前铺好的，火车只能沿着轨道走，不能偏离。Agent 像出租车，你告诉司机目的地（目标），司机自己决定走哪条路（决策），遇到堵车会绕路（调整），中途可能停下来加油（执行动作），最终把你送到目的地。

这个类比揭示了 Agent 和 Workflow 最根本的区别：Workflow 的执行路径是预定义的，Agent 的执行路径是动态生成的。

再换一个角度。Chatbot（聊天机器人）是”你问我答”，每次对话都是独立的，系统不会主动做任何事。Agent 是”你给我目标，我来完成任务”，它会自己规划步骤、调用工具、检查结果、修正错误。Chatbot 是被动的，Agent 是主动的。

有人会问：Agent 不就是多轮对话加上 Function Calling 吗？这个理解太表面了。多轮对话加工具调用只是 Agent 的实现形式之一，不是 Agent 的本质。Agent 的本质是”目标驱动的自主决策系统”。它的核心不是工具，而是决策能力。

Agent 与 Chatbot 的区别

很多人把 ChatGPT 的对话界面理解为 Agent，这是一个常见的误解。

Chatbot 的特征：用户输入一句话，模型返回一句话。每次交互都是用户主动发起的。模型不会主动问问题、不会主动查资料、不会主动执行任务。Chatbot 是一个”响应式系统”，没有用户输入就什么都不做。

Agent 的特征：用户给定一个目标，Agent 自己决定怎么完成。它会分解任务、选择工具、执行操作、检查结果。整个过程用户可以旁观，不需要逐步指导。Agent 是一个”主动式系统”，有了目标就能自主运行。

举个具体的例子。假设用户说”帮我分析半导体行业的 AI 应用机会”。

Chatbot 模式下，用户需要一步步引导：先问”半导体行业有哪些环节”，模型回答后，再问”每个环节有什么痛点”，模型回答后，再问”哪些痛点可以用 AI 解决”…整个过程用户在驾驶，模型只是副驾。

Agent 模式下，用户给一个目标，Agent 自己完成全部分析。它会先搜索半导体行业资料，然后整理行业结构，再拆解关键岗位，再识别 AI 机会，最后生成报告。用户只看最终结果就行。

但 Agent 不是万能的。Chatbot 的优势是交互灵活、成本可控、用户掌控感强。Agent 的优势是自动化程度高、能处理复杂任务。两者是互补关系，不是替代关系。在实际系统中，很多 Agent 内部嵌套了 Chatbot 的能力来与用户交互。

Agent 与 Workflow 的区别

昨天学了 Workflow，今天学了 Agent，两者的关系需要理清。

最核心的区别在于”谁来决定下一步做什么”。

Workflow 中，流程设计者提前决定了每个步骤。第一步做什么、第二步做什么、条件分支怎么走，全部在设计时就定好了。运行时不需要做决策，只需要按计划执行。

Agent 中，Agent 自己决定下一步做什么。设计者只提供目标、工具和约束，不提供具体的执行步骤。Agent 根据当前状态实时推理出下一步动作。

用一个表格对比：

维度	Workflow	Agent
执行路径	预定义	动态生成
决策方式	按规则流转	模型实时推理
灵活性	低，改动需要重新设计	高，自动适应变化
可预测性	高，行为范围可控	低，行为可能超出预期
调试难度	低，问题定位到节点	高，决策过程复杂
适用场景	标准化流程	需要判断的复杂任务
成本	低，调用次数可控	高，调用次数不确定

实际项目中，Workflow 和 Agent 不是二选一的关系。常见的做法是：大框架用 Workflow 控制主流程，在需要灵活判断的环节嵌入 Agent。比如”行业分析系统”的大流程用 Workflow（昨天设计的），但”AI 机会评分”这一步用 Agent，因为不同行业的评分逻辑差异很大，需要 Agent 根据具体情况灵活调整。

这种”Workflow 包裹 Agent”的架构模式在企业应用中非常实用，它兼顾了 Workflow 的可控性和 Agent 的灵活性。

Goal（目标）

Goal 是 Agent 存在的理由。没有目标的 Agent 就像一个没有目的地的出租车，不知道该往哪里开。

给 Agent 设定目标是一门学问。目标太模糊，Agent 不知道该做什么，可能跑偏。目标太具体，Agent 失去了灵活性，退化成了 Workflow。

好的目标应该包含三个要素：做什么（任务描述）、做到什么程度（完成标准）、不能做什么（约束条件）。

举个例子。给”行业研究 Agent”设定目标：

做什么：分析给定行业的 AI 应用机会，生成一份结构化的分析报告。

做到什么程度：报告必须包含行业概览、5-10 个关键岗位分析、3-5 个核心业务流程分析、至少 5 个 AI 机会点及评分、Top 3 推荐方案。

不能做什么：不要使用未经验证的市场数据、不要推荐超出当前技术能力的方案、不要生成超过 5000 字的报告。

这种结构化的目标描述，英文叫 Goal Specification，是 Agent 设计的第一步，也是最关键的一步。目标定义不清楚，后面所有设计都是空中楼阁。

State（状态）

State 是 Agent 在任一时刻的”记忆快照”。它记录了 Agent 当前知道什么、做了什么、还差什么。

State 通常包含以下信息：原始目标和约束、已经完成的步骤及其结果、当前正在执行的步骤、待完成的步骤、从工具调用中获得的外部信息、中间分析和推理结论。

State 的重要性体现在两个方面。第一，Agent 每次做决策都需要参考当前状态。比如决定下一步调用哪个工具，需要知道已经调用了哪些工具、获得了什么结果、目标还差什么没完成。第二，State 是调试 Agent 的关键线索。如果 Agent 行为异常，查看 State 就能知道它在哪个环节出了问题。

State 的设计要平衡两个需求：完整性和简洁性。太简略了，Agent 缺少决策依据；太详细了，传给模型的上下文太长，增加成本和延迟，还可能干扰模型判断。一个好的做法是对历史步骤做摘要，只保留关键结论，不保留每一步的完整输出。

Memory（记忆）

Memory 和 State 有什么区别？State 是”当前任务的工作记忆”，Memory 是”跨任务的长期记忆”。

打个比方。你在做一个项目（当前任务），手边有笔记本记录当前进度和临时想法，这是 State。你还有过去做过所有项目的经验总结和知识库，这是 Memory。

Memory 在 Agent 系统中分为三类。

第一类是短期记忆，就是当前对话或任务的上下文。相当于你正在做的这件事的即时记忆。短期记忆随任务结束而清除。

第二类是长期记忆，存储 Agent 在历史任务中积累的知识和经验。比如上次分析半导体行业时发现”封测环节的良率数据很难获取”，这个经验可以存入长期记忆，下次分析类似行业时直接参考。长期记忆通常用向量数据库存储，通过语义检索获取。

第三类是工作记忆，是短期记忆和长期记忆的结合。Agent 做决策时，既要看当前任务的状态（短期记忆），也要参考历史经验（长期记忆），两者合并形成工作记忆。

Memory 的价值在于：让 Agent 在处理类似任务时越来越快、越来越好。没有 Memory 的 Agent 每次都从零开始，浪费资源且难以保持一致性。

但 Memory 也是一个设计挑战。存什么、不存什么、怎么检索、怎么避免旧记忆干扰新任务，这些问题都需要仔细设计。初学者可以先不实现 Memory，等基本 Agent 跑通后再加。

Tools（工具）

Tools 是 Agent 与外部世界交互的桥梁。没有工具的 Agent 只能在自己的”脑中”推理，无法获取新信息、无法执行操作、无法产生实际影响。

Agent 常用的工具类型包括：搜索工具（搜索网络、搜索知识库）、数据查询工具（查数据库、调 API）、计算工具（做数学运算、统计分析）、生成工具（生成文档、生成图表）、通信工具（发邮件、发消息）、文件操作工具（读文件、写文件）、系统操作工具（执行命令、管理进程）。

工具设计有两个关键原则。第一，每个工具的职责要单一明确。一个工具做一件事，参数定义清晰，返回格式固定。不要设计一个”万能工具”，参数一大堆，逻辑乱七八糟。第二，工具的描述要准确。Agent 是通过工具描述来决定调用哪个工具的。如果描述不清楚或误导，Agent 就会选错工具。

工具设计还有一个安全维度：权限控制。不是所有工具都应该对所有 Agent 开放。“删除文件”这种危险工具必须限制使用场景。这一点在 Day 27 安全专题里会深入讨论。

Planner（规划器）

Planner 是 Agent 的”大脑前额叶”，负责制定和调整执行计划。

当 Agent 接收到目标后，Planner 首先分析目标，将其拆解成一系列可执行的子任务，然后安排执行顺序。这个过程叫任务规划（Task Planning）。

规划方式大致有三种。

第一种是单次规划。Agent 在开始执行前一次性生成完整的执行计划，然后按计划逐步执行。这种方式效率高，但如果中间出了意外（某个工具返回了意料之外的结果），计划就可能失效。

第二种是逐步规划。Agent 每执行完一步，就根据最新状态重新规划下一步。这种方式灵活性强，能适应变化，但每次规划都要调一次模型，成本较高。

第三种是混合规划。先做一次粗略的全局规划，然后逐步执行时根据实际情况做局部调整。这是实际项目中最常用的方式。

Planner 的质量直接决定了 Agent 的效率。一个好的 Planner 能准确评估每个子任务的难度和依赖关系，合理安排执行顺序，避免走弯路。差的 Planner 可能会让 Agent 反复尝试无效方案，浪费大量 Token 和时间。

Executor（执行器）

Executor 是 Agent 的”手脚”，负责执行 Planner 安排的具体动作。

Executor 的核心工作流程：接收 Planner 的指令、选择合适的工具、构造工具调用参数、执行工具调用、获取返回结果、将结果更新到 State。

Executor 看起来简单，但实际设计中有很多细节要处理。比如工具调用可能失败，Executor 需要处理超时和重试。比如工具返回的数据格式可能和预期不一致，Executor 需要做格式适配。比如某些工具调用是高风险操作，Executor 需要在执行前做确认。

Executor 和 Planner 的协作模式通常是”规划-执行-反馈”循环。Planner 告诉 Executor 下一步做什么，Executor 执行完把结果反馈给 Planner，Planner 根据结果决定下一步。这个循环一直持续到目标完成或判断无法完成。

Reflection（反思）

Reflection 是 Agent 的”自我检查”机制。它让 Agent 能在执行过程中评估自己的行为和结果，发现错误和不足，及时调整。

Reflection 在三个层面发挥作用。

第一个层面是步骤级反思。每执行完一个步骤，Agent 检查这个步骤的结果是否符合预期。比如调用搜索工具后，检查搜索结果是否与当前任务相关。如果不相关，反思原因，可能换个关键词重新搜索。

第二个层面是阶段级反思。完成一个阶段的子任务后，Agent 检查整体进度。比如完成了行业概览和岗位拆解，反思一下目前的分析方向是否正确，是否遗漏了重要信息。

第三个层面是任务级反思。整个任务完成后，Agent 对最终结果做一次全面检查。比如检查报告是否完整、数据是否准确、结论是否合理。

Reflection 是 Agent 智能性的重要体现。没有 Reflection 的 Agent 是”闷头干活不回头看”的工人，可能一路走错都不自知。有 Reflection 的 Agent 是”边做边检查”的细心人，能在过程中发现和纠正错误。

但 Reflection 也有代价。每次反思都要额外调用模型，增加成本和时间。过多的反思还可能导致”过度思考”，Agent 反复纠结不确定的地方，迟迟不能推进。设计时要平衡反思的频率和深度。

Agent 执行循环

把上面的组件串起来，就形成了 Agent 的执行循环。

开始
  |
  v
接收目标 + 约束
  |
  v
初始化 State
  |
  v
+---> Planner：分析当前 State，决定下一步动作
|     |
|     v
|     Executor：执行动作（调用工具 / 生成内容）
|     |
|     v
|     更新 State（写入执行结果）
|     |
|     v
|     Reflection：检查结果，评估进度
|     |
|     v
|     判断：目标是否完成？
|     |--- 否 ---> 回到 Planner（继续循环）
|     |
|     v
|   是
|     |
|     v
+-- 输出最终结果
  |
  v
结束

这个循环有几个关键的终止条件。

第一，目标完成。Agent 判断所有子任务都完成了，输出结果。

第二，达到最大步数。防止 Agent 无限循环。通常设置最大 10-20 步，超过就强制终止。

第三，达到最大成本。Token 消耗超过预算，强制终止。

第四，遇到不可恢复的错误。比如关键工具持续失败，无法继续。

第五，人工干预。外部系统发送终止信号，强制停止。

这些终止条件是 Agent 安全运行的基本保障。没有终止条件的 Agent 就像没有刹车的汽车，极度危险。

概念关系图

Agent 核心架构
|
+-- Goal（目标）
|   |-- 任务描述
|   |-- 完成标准
|   |-- 约束条件
|
+-- State（状态）
|   |-- 已完成步骤及结果
|   |-- 当前步骤
|   |-- 待完成步骤
|   |-- 中间推理结论
|
+-- Memory（记忆）
|   |-- 短期记忆（当前任务上下文）
|   |-- 长期记忆（历史经验知识库）
|   |-- 工作记忆（短期 + 长期合并）
|
+-- Tools（工具集）
|   |-- 搜索工具
|   |-- 数据查询工具
|   |-- 计算工具
|   |-- 生成工具
|   |-- 通信工具
|
+-- 核心循环
    |-- Planner（规划器）-- 决定下一步做什么
    |-- Executor（执行器）-- 执行动作
    |-- Reflection（反思）-- 检查结果
    |
    +-- 循环直到：
        |-- 目标完成
        |-- 达到最大步数
        |-- 达到成本上限
        |-- 遇到不可恢复错误
        |-- 人工干预

Agent vs Chatbot vs Workflow 对比

Chatbot:  用户 ---> 模型 ---> 回复（单步问答）
Workflow: 用户 ---> [节点1 -> 节点2 -> ... -> 节点N] ---> 结果（固定流程）
Agent:    用户 ---> [Plan -> Execute -> Reflect] x N ---> 结果（动态循环）

实战分析

实战任务一：画 Agent 执行循环图

上面的概念关系图中已经给出了执行循环的结构。画图时要注意几个关键点。

第一，标注清楚循环的入口和出口。入口是”接收目标”，出口是”输出结果”和各个终止条件。第二，循环体内标注数据流向。Planner 从 State 读取信息，Executor 把结果写入 State，Reflection 更新 State 中的评估结论。第三，标注外部交互点。Agent 在哪些地方与外部系统交互（调用工具、请求人工确认）。

实战任务二：设计行业研究 Agent

指南要求设计一个行业研究 Agent，定义其目标、工具、状态和输出。

目标定义

核心目标：输入一个行业名称，输出该行业的 AI 应用机会分析报告。

完成标准：报告覆盖行业产业链的至少 3 个环节；识别至少 5 个关键岗位并分析其 AI 机会；识别至少 3 个核心业务流程；推荐至少 3 个 AI 应用场景并给出 ROI 估算；输出格式为结构化 Markdown。

约束条件：不使用虚构的市场数据（如果搜索不到真实数据就标注”数据缺失”）；每个 AI 方案都要标注风险等级和实施难度；总报告不超过 8000 字。

工具清单

这个 Agent 需要以下工具：搜索网络信息（search_web）、查询行业知识库（query_knowledge_base）、计算 ROI（calculate_roi）、生成结构化内容（generate_section）、保存中间结果（save_result）、生成最终报告（generate_report）。

每个工具需要定义：名称、功能描述、输入参数（名称、类型、是否必填、说明）、输出格式。

State 结构

State 应该包含：行业名称、当前分析阶段（概览/岗位/流程/方案/报告）、已完成的分析内容（按阶段组织）、待完成的分析内容、中间发现和待验证的假设、调用的工具记录（用于审计）。

输出结构

最终输出是一份 Markdown 报告，结构为：摘要、行业概览、关键岗位分析、核心流程分析、AI 机会评分表、推荐方案详述、实施路线图、风险提示。

实战任务三：分析 Agent 失败模式

Agent 会以哪些方式失败？这个分析对后续设计防护机制至关重要。

失败模式一：无限循环

Agent 在某个环节反复尝试，始终无法突破。比如搜索工具返回的结果总是不满足要求，Agent 不断换关键词搜索，永远不停。

原因：终止条件不够严格，或者搜索工具的能力不足以满足要求。

失败模式二：目标漂移

Agent 在执行过程中逐渐偏离原始目标。比如要求分析半导体行业，但搜索时发现了一篇关于 AI 芯片的有趣文章，就开始深入分析 AI 芯片市场，忘了原始目标是分析整个半导体行业的 AI 应用机会。

原因：Reflection 不够强，没有定期检查”当前做的事是否还在服务原始目标”。

失败模式三：工具误用

Agent 选错了工具或构造了错误的参数。比如该用”搜索行业知识库”的时候调用了”搜索网络”，或者传入了错误的行业名称。

原因：工具描述不够清晰，或者 Agent 的推理能力不足以区分相似工具。

失败模式四：幻觉放大

模型在某一步生成了不准确的信息，后续步骤基于这个错误信息继续推理，错误越滚越大。比如第一步错误地把”封装测试”说成了”封装设计”，后面所有关于封装的分析都基于这个错误前提。

原因：缺乏事实核查机制，Reflection 没有验证关键信息的准确性。

失败模式五：资源耗尽

Agent 执行了太多步骤，消耗了大量 Token 和时间，最终被强制终止，但什么有用结果都没产出。

原因：任务拆解不合理，或者对某些子任务的难度估计不足，在低价值环节花费太多资源。

当日产物说明

《Agent 执行循环图》

这张图要清晰展示 Agent 的完整执行流程，包括组件之间的数据流和控制流。要求：循环体内部的 Planner-Executor-Reflection 流程清晰可见；终止条件明确标注；外部交互（工具调用、人工确认）在图上有体现。

质量标准：不看文字说明，光看图就能理解 Agent 的运行机制。

《行业研究 Agent 设计》

这个文档包含：目标定义（含完成标准和约束）、工具清单（每个工具的完整定义）、State 结构设计、输出结构设计。这是一份完整的设计文档，可以直接作为后续开发的依据。

质量标准：每个工具的输入输出都有明确类型定义，State 的每个字段都有说明，没有模糊描述。

《Agent 失败模式清单》

这个文档列出至少 5 种 Agent 失败模式，每种模式包含：名称、描述、典型表现、根本原因、预防措施。这份清单在 Day 27 安全专题时还会扩展。

质量标准：每种模式都有真实的场景举例，预防措施是可执行的（不是”小心一点”这种废话）。

常见误区与避坑

误区一：Agent 就是加了个循环的 API 调用

有些人以为 Agent 就是把 API 调用包在一个 while 循环里，每次调用时把上一次的回复追加到对话历史。这种理解严重低估了 Agent 的复杂性。真正的 Agent 需要规划、反思、状态管理、工具选择、错误处理，远比”循环调 API”复杂得多。如果只是循环调 API 而没有智能决策，那不是一个 Agent，那是一个有 bug 的循环。

误区二：Agent 比 Workflow 更高级，应该总是用 Agent

Agent 的灵活性是双刃剑。灵活性意味着不可预测性，意味着更多的出错机会、更高的调试成本、更大的安全风险。如果任务可以用 Workflow 解决，就不要用 Agent。Agent 不是 Workflow 的升级版，而是另一种解决思路。选择哪个取决于任务的性质，不是”高级程度”。

误区三：给 Agent 越多工具越好

工具越多，Agent 的决策空间越大，选择正确的工具就越难。这就像给一个人一百把螺丝刀，他反而不如只有三把的时候拧螺丝快，因为他要花时间选工具。每个 Agent 应该只配备它完成任务所必需的工具。多余的工具不仅增加决策难度，还增加安全风险。

误区四：忽视终止条件

没有终止条件的 Agent 就是一个潜在的无限循环。很多人在设计 Agent 时只关注”怎么让它跑起来”，不关注”怎么让它停下来”。结果 Agent 在某个环节卡住了，不断重试，Token 消耗像流水一样。每个 Agent 都必须设置最大步数、最大成本、超时时间三道防线。

误区五：Agent 不需要人工介入

完全自主的 Agent 在当前技术水平下是不现实的。模型会犯错、工具会失败、判断会偏差。设计 Agent 时一定要考虑在关键节点加入人工确认，尤其是涉及输出给外部客户的场景。不要试图构建一个”无人值守”的 Agent 系统，至少在当前阶段不要。

延伸思考

今天的 Agent 基础认知为后续几天的内容铺好了地基。

明天 Day 24 会深入 Tool Calling，这是 Agent 执行动作的核心机制。今天我们从概念层面了解了工具，明天会深入工具的定义方式、选择策略、权限控制等工程细节。

Day 25 的 Multi-Agent 架构是建立在单 Agent 基础上的。单个 Agent 处理复杂任务时能力有限，把多个专业化的 Agent 组合起来协作，能解决更复杂的问题。但 Multi-Agent 不是简单的”堆人”，它有自己独特的设计挑战：Agent 之间怎么通信、中间结果怎么整合、冲突怎么处理。

Day 26 的 Human-in-the-loop 从今天提到的”人工审核”延伸出去，系统性地讨论在 Agent 执行过程中如何设计人工介入机制。

Day 27 的安全专题会从今天分析的五种失败模式出发，扩展到 Prompt Injection、工具越权、数据泄露等安全威胁，并给出防护策略。

从与 Week 3 的衔接来看，Agent 中的 Memory 组件可以直接用 RAG 系统来实现长期记忆。把 Agent 的历史经验存入向量数据库，每次执行新任务时检索相关经验，就是 RAG 和 Agent 的天然结合点。

还有一个重要的延伸思考：Agent 的评估问题。Workflow 的评估相对简单，每个节点的输入输出都可以单独测试。但 Agent 的行为是动态的，同样的输入可能产生不同的执行路径，怎么评估 Agent 的质量？这个问题在 Week 5 的 Eval 体系里会专门讨论。

自测问题

用自己的话定义 Agent，至少提到三个关键特征。
Agent 和 Chatbot 最本质的区别是什么？举一个具体场景说明。
Agent 和 Workflow 的核心区别是什么？什么场景下应该选择 Workflow 而不是 Agent？
给 Agent 设定目标时应该包含哪三个要素？分别举例说明。
State 和 Memory 的区别是什么？它们各自解决什么问题？
Planner 的三种规划方式分别是什么？各有什么优缺点？
Reflection 在哪三个层面发挥作用？每个层面举一个具体例子。
Agent 执行循环有哪五个终止条件？为什么每个都必要？
“目标漂移”是什么意思？怎么预防？
为什么说”给 Agent 越多工具越好”是一个误区？

关键词

Agent（智能体）：能够感知环境、自主决策、执行动作、根据反馈调整行为的 AI 系统
Goal（目标）：Agent 的任务描述、完成标准和约束条件
State（状态）：Agent 在某一时刻的工作记忆快照，记录已完成和待完成的内容
Memory（记忆）：Agent 跨任务的长期知识存储，分为短期、长期和工作记忆
Tools（工具）：Agent 与外部系统交互的接口，包括搜索、查询、计算、生成等
Planner（规划器）：Agent 的决策组件，负责分析状态并决定下一步动作
Executor（执行器）：Agent 的执行组件，负责调用工具并处理结果
Reflection（反思）：Agent 的自我评估机制，用于检查结果和调整策略
目标漂移：Agent 在执行过程中逐渐偏离原始目标的失败模式
执行循环：Plan-Execute-Reflect 的重复过程，直到目标完成或被终止

MindCarver Blog

MindCarver

探索

Day23-Agent基础认知