Agent 工程化指南（一）：概念与认知架构 — 智能体到底是什么、怎么思考

一句话定位：打破"套壳 ChatGPT"的刻板印象，建立生产级 Agent 的完整心智模型。读完能判断自己的系统算不算 Agent，并跑起来一个最小 Agent。

1. 引言：凌晨两点的线上告警

凌晨两点，手机震动。监控系统发出告警：订单服务错误率突增至 15%。

传统做法------值班运维工程师被叫醒：

plain 复制代码

① 打开 Grafana 看大盘 → 错误率确实在飙升
② SSH 登录服务器 → tail -f 看日志 → 发现大量数据库连接超时
③ 登录数据库监控 → 发现慢查询堆积
④ 尝试手动 kill 阻塞的 SQL → 没有权限
⑤ 创建紧急工单 → 找 DBA → 等待回复
⑥ DBA 醒来、登录、分析、kill 阻塞 SQL → 服务恢复
⑦ 第二天写复盘报告

总耗时：30-60 分钟（如果 DBA 及时响应的话）。

Agent 做法------凌晨两点，同一个告警：

plain 复制代码

① 监控告警触发 Agent（感知层）
② Agent 读取告警上下文："订单服务，错误率 15%，数据库连接超时"
③ Agent 调用"监控查询 Skill"获取详细指标
④ Agent 调用"日志分析 Skill"分析最近 30 分钟日志
⑤ Agent 判断：根因是数据库锁争用导致连接池耗尽
⑥ Agent 调用"数据库诊断 Skill"，定位到阻塞 SQL
⑦ Agent 生成操作方案，请求人工确认："建议 kill SQL [ID]，确认执行？"
⑧ 值班人员在手机上点"确认"
⑨ Agent 执行 kill，监控错误率恢复
⑩ Agent 自动生成复盘报告

总耗时：5-10 分钟。值班人员只需要做一件事------点确认。

这不是聊天。这不是"帮我想想可能是什么原因"。这是一个自主感知、推理、规划、执行的系统，它接收一个目标（"恢复服务"），然后自己决定怎么做、用什么工具、按什么顺序做，直到目标达成。

这就是 Agent（智能体）。

2. Agent 的正式定义

2.1 一句话定义

Agent 是以大语言模型（LLM）为核心推理引擎，具备感知、推理、记忆和行动能力，能够自主完成多步骤复杂任务的智能系统。 ^[1]

这个定义中每个词的分量：

以 LLM 为核心推理引擎：Agent 的"大脑"是 LLM，不是传统的 if-else 规则引擎。LLM 负责理解意图、做判断、选策略。
感知：Agent 能从多种来源接收信息------用户的对话、系统的告警、API 的返回值、文件的内容。
推理：Agent 能分析信息、做因果判断、选择行动方案。这不只是一次 LLM 调用，而是多轮推理的循环。
记忆：Agent 能记住之前发生过什么（"这个服务上周也出过类似问题"），并在后续决策中利用这些记忆。
行动：Agent 能调用外部工具和 Skill 来改变世界状态------不只是"说"，而是"做"。
自主完成多步骤：Agent 不需要人类告诉它每一步怎么做。它能自己分解任务、规划步骤、处理异常、直到完成目标。

2.2 四个核心特征

上述定义可以提炼为四个核心特征^[1]：

latex 复制代码

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  ① 自主性（Autonomy）                                       │
│     无需人类逐步指令，自己决定下一步做什么                     │
│     人类说"恢复服务"，Agent 自己决定去查日志、查数据库、kill SQL│
│                                                             │
│  ② 反应性（Reactivity）                                     │
│     能感知环境变化并及时响应                                   │
│     API 返回错误 → Agent 换一个策略重试                       │
│     操作后服务恢复 → Agent 停止进一步操作                      │
│                                                             │
│  ③ 目标导向（Goal-Oriented）                                 │
│     围绕最终目标持续工作，不轻易放弃                           │
│     第一次尝试失败 → 反思原因 → 换方案再试                    │
│     不是"一步做不了就算了"，而是"想尽办法达成目标"             │
│                                                             │
│  ④ 持续性（Persistence）                                     │
│     具备记忆，能在长流程中保持状态一致                         │
│     第 1 步查到的信息，第 8 步还能用                          │
│     上一次会话的诊断结论，下一次会话还能参考                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

这四个特征共同定义了 Agent 与传统软件的边界。一个程序如果只满足其中一个或两个（比如只满足"反应性"------对输入做固定输出），它还不是 Agent。只有四个特征同时具备，才是真正的 Agent^[1]。

2.3 Agent 的五层解剖图

对应 Skill 系列中 Skill 的"六大构成要素"解剖图，Agent 也有自己的内部结构。一个完整的 Agent 由五层构成：

latex 复制代码

┌─────────────────────────────────────────────────────────────┐
│                      Agent 解剖图                            │
│                                                             │
│   ┌───────────────────────────────────────────────────┐    │
│   │  ① 感知层（Perception）                             │    │
│   │  用户对话 · 系统事件 · Webhook · 定时触发 · 文件上传 │    │
│   └───────────────────────┬───────────────────────────┘    │
│                           ▼                                 │
│   ┌───────────────────────────────────────────────────┐    │
│   │              ② 大脑层（Brain / Cognition）           │    │
│   │              LLM 推理核心 · 提示策略 · 推理模式      │    │
│   │              （ReAct / Plan-then-Execute / Reflexion）│    │
│   │                                                     │    │
│   │    ┌──────────────┐       ┌──────────────────┐     │    │
│   │    │ ③ 记忆层      │       │ ④ 规划层          │     │    │
│   │    │（辅助子系统）  │       │（辅助子系统）      │     │    │
│   │    │ 工作记忆      │       │ 任务分解           │     │    │
│   │    │ 长期记忆      │       │ 计划生成           │     │    │
│   │    │ 上下文管理    │       │ 动态重规划         │     │    │
│   │    └──────────────┘       └──────────────────┘     │    │
│   └───────────────────────┬───────────────────────────┘    │
│                           ▼                                 │
│   ┌───────────────────────────────────────────────────┐    │
│   │  ⑤ 行动层（Action）                                │    │
│   │  调用 Skill · 调用 Tool · 人机协同 · 输出结果       │    │
│   └───────────────────────────────────────────────────┘    │
│                                                             │
│   大脑层通过以下方式协调各层：                                │
│   读取记忆 → "上周遇到过类似问题"                            │
│   驱动规划 → "先止血、再排查、再修复"                        │
│   下发行动 → "调用数据库诊断 Skill"                         │
│   写回记忆 → "记录这次的诊断结论"                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

需要特别注意的是，五层之间不是简单的"上层到下层"的线性关系。② 大脑层是整个 Agent 的调度枢纽------它在推理过程中向 ③ 记忆层读取历史信息（"这个服务上周也出过类似问题"），将生成的任务计划交由 ④ 规划层管理，根据规划结果向 ⑤ 行动层下达执行指令（"调用数据库诊断 Skill"），并将行动层返回的观察结果写回记忆层，供下一轮推理使用。记忆层和规划层不直接驱动行动层------它们是大脑层的"辅助系统"，为大脑的决策提供信息和约束。

各层的职责：

① 感知层是 Agent 的"感官"，负责从外界接收信息。与 Chatbot 只接收用户输入不同，Agent 的感知来源更多样：系统告警、CI/CD Webhook、定时任务、文件上传、API 调用等。感知层将原始信息转化为 Agent 可以处理的结构化输入。

② 大脑层是 Agent 的"思维中枢"，由 LLM 驱动。它接收感知层的信息，结合记忆层的历史信息，选择合适的推理策略，做出决策------"现在该做什么？"大脑层的核心是推理模式的选择（ReAct、Plan-then-Execute 等），本篇第 5 节会详细展开。

③ 记忆层 和④ 规划层是大脑层的两个辅助子系统。记忆层负责"记住发生了什么"，规划层负责"决定接下来做什么"。记忆为规划提供信息（"上周遇到过类似问题，当时是这样解决的"），规划的结果也会写入记忆（"这次计划分四步走"）。第二篇会深入展开这两个模块。

⑤ 行动层 是 Agent 的"手脚"，负责执行规划层制定的计划。行动层的核心是调用 Skill 和 Tool------这正是 Skill 系列覆盖的内容。Agent 通过行动层与外部世界交互，改变系统状态，获取执行结果。

与 Skill 解剖图的关系 ：在 Skill 系列中，我们把 Skill 解剖为六大要素（Identity、Intent、Contract、Logic、Bindings、Guardrails）。如果把两个解剖图叠在一起看，Skill 的全部内容都位于 Agent 的行动层中。Skill 是 Agent 能力的标准化封装，Agent 通过调用 Skill 来完成具体任务。理解了这一点，两个系列的知识就自然衔接起来了。

3. 概念辨析：Agent ≠ X

"Agent"这个词在技术领域被大量使用，但含义各不相同。在我们继续深入之前，需要把它和几个容易混淆的概念划清边界。

3.1 Agent vs Chatbot（聊天机器人）

Chatbot 是一问一答的对话系统。用户说一句，系统回一句，没有持续的状态，没有自主行动的能力。

plain 复制代码

用户：订单 12345 怎么还没到？
Chatbot：已为您查询，订单 12345 当前状态为「配送中」，预计明天送达。
用户：帮我催一下。
Chatbot：已为您提交催单请求。（调用了一个 API）

看起来 Chatbot 也能"做事"，但它的行为模式是响应式的------用户不说话，它就什么都不做。而且每一轮对话之间没有持续的目标追踪。

Agent 不同。它接收一个目标后，会自主规划和执行一系列步骤，直到目标达成：

plain 复制代码

用户：这批订单的物流都延迟了，帮我处理一下。
Agent：
  → 查询所有延迟订单（调用订单查询 Skill）
  → 分析延迟原因（调用物流分析 Skill）
  → 按原因分类：仓库发货延迟 / 物流商延误 / 地址异常
  → 仓库延迟的 → 自动催促仓库（调用工单创建 Skill）
  → 物流商延误的 → 批量联系物流商（调用物流沟通 Skill）
  → 地址异常的 → 列出清单，请求人工确认
  → 汇总处理结果，回复用户

核心区别：Chatbot 是"你问我答"，Agent 是"你给我目标，我自己搞定"。

3.2 Agent vs Workflow（工作流）

这组辨析在 Skill 系列第一篇中讨论过，但在 Agent 层面值得重新审视。

Workflow 是预定义的固定流程------在设计时就确定了每个节点和路由条件，运行时机械执行^[1]。

latex 复制代码

Workflow：
  告警触发 → 查日志 → 日志中含 "OOM" ?
    ├─ 是 → 重启服务 → 完成
    └─ 否 → 查数据库 → 数据库异常 ?
              ├─ 是 → 切换主备 → 完成
              └─ 否 → 转人工 → 完成

Agent 处理同样的场景：

latex 复制代码

Agent：
  告警触发 → 分析日志 → 发现 OOM 但同时有数据库慢查询
  → LLM 判断：OOM 可能是数据库慢查询导致连接池堆积的连锁反应
  → 先解决数据库问题（根因），而不是先重启服务（治标）
  → 修复数据库后观察 → 服务自然恢复

核心区别：Workflow 走预设路径，Agent 动态决策。面对"OOM + 慢查询"的复合故障，Workflow 只会按预设的"OOM → 重启"走，而 Agent 能判断出真正的根因，做出更优的决策。

3.3 Agent vs Copilot（副驾驶）

Copilot（如 GitHub Copilot、Microsoft Copilot）的定位是人类的辅助工具 ------人类在前面开车，Copilot 在旁边给建议^[2]。

latex 复制代码

Copilot 模式：
  人类写代码 → Copilot 补全下一行
  人类写邮件 → Copilot 建议措辞
  核心：人类 Drive，AI 辅助

Agent 模式：
  人类说"帮我把上周的线上问题都排查一遍并出报告"
  Agent 自己规划、执行、产出结果
  核心：AI Drive，人类监督

核心区别：Copilot 是"人 Drive"，Agent 是"自主 Drive"。Copilot 不会自己决定该做什么，它只在人类的行动轨迹上提供辅助；Agent 接到目标后自己决定该做什么，人类只需要在关键节点做确认。

3.4 Agent vs Skill

这组辨析在 Skill 系列第一篇中有详细论述。核心结论是：

Agent 是雇主，Skill 是员工。 Agent 负责决策（该做什么、按什么顺序），Skill 负责执行（具体怎么做）。

在 Agent 的五层解剖图中，Skill 位于行动层。Agent 通过调用 Skill 来完成具体任务。一个 Agent 可以拥有多个 Skill，同一个 Skill 可以被多个 Agent 复用。

3.5 对比总结表

维度	Chatbot（聊天机器人）	Copilot（副驾驶）	Workflow（工作流）	Agent（智能体）	Skill（技能）
本质	对话界面	辅助工具	自动化流程	自主系统	能力单元
核心驱动	模式匹配	人类主导 + AI 辅助	预定义规则	LLM 自主决策	LLM + 工具调用
多步骤能力	无	单步建议	固定多步	动态多步	固定 + 动态（在能力范围内）
面对未知情况	无法处理	给通用建议	报错/走默认分支	动态调整策略	能力范围内应对，超出报错
状态管理	无状态	无状态（每次独立）	有状态（固定）	有状态（动态）	有状态（单次执行）
自主程度	无	低	无	高	中（在定义范围内）
与人类的关系	人类提问，系统回答	人类行动，系统辅助	人类设定规则，系统执行	人类给目标，系统完成	Agent 调用 Skill

注：上表中 Chatbot、Copilot、Workflow、Agent 是系统级形态 的对比（它们都可以作为独立产品部署），而 Skill 是 Agent 内部的能力组件（它本身不作为独立产品存在）。将 Skill 放入此表，是为了突出它与其他形态的职责边界，而非暗示它们处于同一抽象层级。Skill 作为 Agent 的标准化能力单元，在 Skill 系列中有完整的论述。

3.6 Agent 判定清单

概念辨析回答了"Agent 不是什么"。但一个更实际的问题是：你手头的系统算不算 Agent？

以下是一份判定清单。逐项对照打分，就能判断你的系统处于哪个阶段，以及离一个真正的 Agent 还差什么。

latex 复制代码

┌──────────────────────────────────────────────────────────────┐
│                    Agent 判定清单                              │
│                                                              │
│  ── 基础特征（至少满足 3 项才进入 Agent 评估）──              │
│                                                              │
│  □ 使用 LLM 作为核心推理引擎（不是纯规则引擎）               │
│  □ 能调用外部工具或 API（不只是生成文本）                    │
│  □ 能处理多轮交互（不是一问一答就结束）                      │
│                                                              │
│  ── Agent 核心特征（全部满足 = 基础 Agent）──                │
│                                                              │
│  □ 自主性：能自己决定下一步做什么（不只是按预设流程走）       │
│  □ 反应性：能根据中间结果调整策略（不只是按固定路径执行）     │
│  □ 目标导向：围绕一个目标持续工作直到完成                    │
│  □ 持续性：在多步执行中保持状态（记住之前做过什么）           │
│                                                              │
│  ── 工程化特征（满足越多越成熟）──                           │
│                                                              │
│  □ 有错误处理和重试机制                                     │
│  □ 有人机协同的确认节点                                     │
│  □ 有执行日志和可观测性                                     │
│  □ 有评测和回归测试                                         │
│  □ 有版本管理和灰度发布                                     │
│                                                              │
│  ── 判定结果 ──                                              │
│                                                              │
│  基础特征 < 3 项            → 传统程序或 Chatbot              │
│  基础特征 ≥ 3 项 + 核心特征 < 4 项 → "Agent 原型"            │
│  核心特征 = 4 项            → 基础 Agent                     │
│  工程化特征 ≥ 3 项          → 生产级 Agent                   │
└──────────────────────────────────────────────────────────────┘

用三个实际场景来演示判定过程：

场景 A："我有一个程序，用户输入问题，我调 GPT-4 API 返回回答。"

plain 复制代码

基础特征：
  □ 使用 LLM  ✓
  □ 调用外部工具  ✗（只调了 LLM API，没有调业务工具）
  □ 多轮交互  ✗（一问一答）
  → 满足 1 项，不进入 Agent 评估
  → 判定：Chatbot

场景 B："用户输入'帮我写个 PR 描述'，我先用 LLM 分析 commit diff，再调 GitHub API 创建 PR。"

plain 复制代码

基础特征：
  □ 使用 LLM  ✓
  □ 调用外部工具  ✓（GitHub API）
  □ 多轮交互  ✓（先分析再创建，至少两步）
  → 满足 3 项，进入 Agent 评估

Agent 核心特征：
  □ 自主性  部分满足（流程固定：先分析再创建，不会根据分析结果改变策略）
  □ 反应性  不满足（不会因为 diff 分析结果调整创建 PR 的方式）
  □ 目标导向  ✓（围绕"创建 PR"这个目标工作）
  □ 持续性  ✓（分析 diff 的结果在创建 PR 时被使用）
  → 满足 2.5 项
  → 判定：Agent 原型
  → 差什么：缺少根据中间结果动态调整的能力。
           如果 LLM 分析 diff 后发现有安全漏洞，它应该
           "暂停创建 PR，提示用户先修复漏洞"------这才是自主性和反应性。

场景 C：本文引言中的凌晨告警 DevOps Agent

plain 复制代码

基础特征：
  □ 使用 LLM  ✓
  □ 调用外部工具  ✓（监控、日志、数据库诊断等多个 Skill）
  □ 多轮交互  ✓（多步执行，跨多轮推理）
  → 满足 3 项

Agent 核心特征：
  □ 自主性  ✓（自己决定先查日志再查数据库）
  □ 反应性  ✓（根据日志分析结果调整排查方向）
  □ 目标导向  ✓（围绕"恢复服务"持续工作）
  □ 持续性  ✓（记住日志分析结论，用于后续诊断）
  → 满足 4 项
  → 判定：基础 Agent

如果加上以下能力，则升级为"生产级 Agent"：
  □ 有错误处理和重试  ✓（API 超时自动重试）
  □ 有人机协同  ✓（kill SQL 前请求确认）
  □ 有执行日志  ✓（完整调用链记录）
  □ 有评测  （待建设）
  □ 有版本管理  （待建设）
  → 满足 3 项工程化特征
  → 判定：接近生产级，还差评测和版本管理

判定清单的用途：不仅用于判断自己的系统，也用于规划迭代路径。如果你的系统目前是"Agent 原型"，清单告诉你下一步应该补什么（"增加根据中间结果动态调整的能力"）。本系列后续四篇将覆盖从"基础 Agent"到"生产级 Agent"所需的所有工程化能力。

4. Function Calling：Agent 行动层的核心机制

在进入认知架构之前，需要先理解一个关键的技术机制------Function Calling（函数调用） 。它是 Agent 行动层得以运作的基础^[3][11]。

4.1 什么是 Function Calling

Function Calling 是 LLM 提供商（如 OpenAI、Anthropic）提供的能力，让 LLM 在推理过程中不仅能生成文本，还能决定调用哪个外部函数、传什么参数 ^[11]。

传统 LLM 使用：

plain 复制代码

用户："北京今天天气怎么样？"
LLM："北京今天晴，气温 25°C。"  ← 模型凭记忆回答，可能是幻觉

有 Function Calling 的 LLM：

plain 复制代码

用户："北京今天天气怎么样？"
LLM 决定：需要调用 get_weather 函数
  → get_weather(city="北京", date="today")
外部系统返回：{"temp": 25, "condition": "sunny"}
LLM：根据真实数据回答 "北京今天晴，25°C"

4.2 Function Calling 的工作流程

latex 复制代码

Step 1: 开发者定义可用函数的描述

  functions = [
    {
      "name": "query_logs",
      "description": "查询指定服务的日志",
      "parameters": {
        "service_name": {"type": "string", "required": true},
        "time_range": {"type": "string", "required": true}
      }
    },
    {
      "name": "kill_query",
      "description": "终止指定的数据库查询",
      "parameters": {
        "query_id": {"type": "string", "required": true}
      }
    }
  ]

Step 2: 用户输入 + 函数描述一起发送给 LLM

  用户："订单服务报错了，帮我查查"
  LLM 收到：用户消息 + 两个函数的描述

Step 3: LLM 决定是否调用函数

  LLM 输出：
  {
    "tool_call": {
      "function": "query_logs",
      "arguments": {"service_name": "order-service", "time_range": "last_30min"}
    }
  }

Step 4: 外部系统执行函数，将结果返回给 LLM

  query_logs 的结果：大量连接超时错误日志

Step 5: LLM 基于函数返回结果继续推理

  LLM："日志显示数据库连接超时，我需要进一步查看数据库状态。"
  → 继续调用下一个函数...

这个流程的精髓在于：LLM 负责"决定做什么"，外部系统负责"实际执行"。LLM 不需要知道数据库怎么连接、API 怎么调用------它只需要知道有哪些函数可用、每个函数做什么、传什么参数。

4.3 Function Calling 与 Skill 的关系

在 Skill 系列中，每个 Skill 通过 SKILL.md 定义了它的输入输出契约和执行指令。在 Agent 的运行时中，Skill 被注册为 Function Calling 的可用函数 ^[12]：

latex 复制代码

Skill 注册表                     Function Calling 函数列表
┌──────────────────┐            ┌──────────────────────────┐
│ pipeline-diagnosis│    ───→    │ name: pipeline_diagnosis  │
│ SKILL.md         │            │ description: When a CI/CD │
│ (六要素齐全)      │            │ pipeline build fails...   │
│                  │            │ parameters: {             │
│                  │            │   pipeline_id: string     │
│                  │            │ }                         │
└──────────────────┘            └──────────────────────────┘

Agent 的行动层在每一轮推理中，将所有可用 Skill 的 name + description + input_schema 注册为 Function Calling 的函数描述。LLM 根据这些描述决定调用哪个 Skill、传什么参数^[12]。

5. Agent 的认知架构：它怎么"思考"

LLM 本质上是一个文本生成器------给定输入，生成下一个 token^[3]。但当 LLM 被放在 Agent 架构中、配合合适的推理策略时，它展现出了强大的推理和决策能力。这一节讨论三种主要的认知架构------即 Agent "思考"的方式。

5.1 ReAct：边想边做

ReAct （Reasoning + Acting）是 Yao 等人在 2022 年提出的框架^[4]，是目前最广泛使用的 Agent 推理模式。它的核心思想非常简单：让 LLM 交替进行"思考"（Thought）和"行动"（Action），每次行动后观察结果（Observation），再进行下一轮思考。

用凌晨告警的场景展示一个完整的 ReAct 循环：

plain 复制代码

[感知] 告警：订单服务错误率 15%，数据库连接超时

Thought 1: 订单服务报数据库连接超时。我需要先看看具体的错误日志，
          确认是连接池问题还是数据库本身的问题。
Action 1: 调用"日志分析 Skill"
         → query_logs(service="order-service", time_range="last_30min")
Observation 1: 日志显示 "Connection pool exhausted"，同时有大量
              "Lock wait timeout exceeded" 错误

Thought 2: 连接池耗尽是因为锁等待超时------有 SQL 持有锁时间过长。
          我需要查看数据库当前的锁状态。
Action 2: 调用"数据库诊断 Skill"
         → query_locks(database="order-db")
Observation 2: 发现一条 SELECT 查询已持锁 45 分钟，阻塞了 23 个连接

Thought 3: 找到了根因------一条未加索引的全表扫描查询持有了行锁。
          需要 kill 这个查询来释放锁。但这是生产数据库的操作，
          需要人工确认。
Action 3: 生成操作方案，请求人工确认
         → "建议 kill 查询 [ID: 8837]，该查询已持锁 45 分钟，
            阻塞了 23 个连接。确认执行？"
Observation 3: 用户确认

Thought 4: 用户已确认。执行 kill。
Action 4: 调用"数据库管理 Skill"
         → kill_query(query_id=8837)
Observation 4: 查询已终止，锁释放，连接池恢复

Thought 5: 服务应该已恢复。我需要验证一下。
Action 5: 调用"监控查询 Skill"
         → query_metrics(service="order-service", time_range="last_5min")
Observation 5: 错误率从 15% 降至 0.2%，服务已恢复正常

Thought 6: 服务已恢复。现在生成复盘报告。
Action 6: 生成复盘报告并回复用户

ReAct 的核心优势^[4]：

可解释：每一步 Thought 都展示了 Agent 的推理过程，人类可以理解"它为什么这么做"
可干预：在任何 Thought 之后，人类都可以介入（"不要 kill，先试试加索引"）
灵活：Agent 可以根据 Observation 动态调整策略，不受预设路径限制

ReAct 的局限：

没有全局规划：Agent 是"走一步看一步"，可能在某些情况下绕弯路
循环风险：如果 Thought 总是得不出新结论，Agent 可能在同一组 Action 中反复循环
Token 消耗高：每一轮 Thought + Action + Observation 都消耗 Token，步骤越多成本越高

5.2 Plan-then-Execute：先想清楚再动手

Plan-then-Execute 模式将推理分为两个明确的阶段：先让 LLM 生成完整的执行计划，再逐步执行。

需要区分两个层面的含义：在 Prompting 技巧层面，Wang 等人（2023）提出的 Plan-and-Solve 方法^[5]是一种让 LLM 在单次生成中先输出计划再输出解题步骤的提示策略；在 Agent 系统架构层面，Plan-then-Execute 指的是先生成一个结构化的多步计划（如 JSON 格式的任务列表或 DAG），然后启动一个独立的执行循环逐步消费这个计划，执行过程中可以触发重规划。LangChain 的 Plan-and-Execute Agent、BabyAGI 等系统体现了后一种架构模式^[3]。本文讨论的是后者。

plain 复制代码

[感知] 告警：订单服务错误率 15%

═══════════════════════════════════════
阶段一：规划（Planning）
═══════════════════════════════════════

LLM 接收告警信息，生成完整计划：

Plan:
  Step 1: 查询订单服务的错误日志，确认错误类型
  Step 2: 根据错误类型选择排查路径
    - 如果是数据库相关 → Step 3a
    - 如果是代码部署相关 → Step 3b
    - 如果是外部依赖相关 → Step 3c
  Step 3a: 查询数据库健康状态和锁信息
  Step 4: 执行修复操作（需人工确认）
  Step 5: 验证服务恢复
  Step 6: 生成复盘报告

═══════════════════════════════════════
阶段二：执行（Execution）
═══════════════════════════════════════

Execute Step 1: query_logs(...)
→ 结果：数据库连接超时 → 走 Step 3a

Execute Step 3a: query_db_health(...)
→ 结果：锁争用

Execute Step 4: kill_query(...) [需人工确认]
→ 用户确认 → 执行

Execute Step 5: query_metrics(...)
→ 结果：错误率恢复正常

Execute Step 6: 生成报告

Plan-then-Execute 的核心优势^[3][5]：

全局视角：Agent 在执行前就看到了完整计划，减少了绕弯路的可能
可审核：人类可以在执行前审查计划（"你的计划漏了检查外部依赖，加上"）
效率更高：避免了 ReAct 中反复"试错-观察"的冗余步骤

Plan-then-Execute 的局限：

计划可能过时：如果执行过程中环境变化（比如另一个服务也出了问题），原计划可能不再适用
规划质量取决于 LLM：如果 LLM 的规划能力不够强（比如遗漏了关键步骤），后续执行会受影响
需要重规划机制：当计划不再适用时，需要触发"重规划（Re-planning）"，增加复杂度

5.3 Reflexion：失败了就反思，反思完再试

Reflexion （Shinn 等人，2023 年提出）是一种自我改进的推理模式^[6]。它的核心思想是：当 Agent 执行失败时，不是盲目重试，而是先反思失败原因，将反思结论纳入记忆，再用改进后的策略重新尝试。

plain 复制代码

═══════════════════════════════════════
尝试 1：
═══════════════════════════════════════
Agent 分析日志 → 判断是代码 Bug → 尝试回滚最新部署
→ 回滚后观察：错误率没变，问题依旧
→ 结果：失败

═══════════════════════════════════════
反思（Reflection）：
═══════════════════════════════════════
"我回滚了最新部署但问题没解决，说明这不是最近代码变更引起的。
日志中的错误是数据库连接超时，不是代码异常。
我之前错误地将数据库问题归因为代码 Bug。
下次应该先看错误类型，再判断根因方向。"

═══════════════════════════════════════
尝试 2（带着反思结论）：
═══════════════════════════════════════
Agent 重新分析 → 从数据库方向入手 → 查到锁争用 → kill 阻塞 SQL
→ 观察：错误率恢复
→ 结果：成功

Reflexion 的核心优势^[6]：

自我改进：Agent 能从错误中学习，避免重复犯错
鲁棒性强：面对不确定性和复杂环境，Agent 能通过多轮尝试找到解决方案
适合探索性任务：当没有明确的最佳路径时，Reflexion 让 Agent 通过试错找到答案

Reflexion 的局限：

成本高：每次尝试和反思都消耗 LLM Token，失败次数越多成本越高
可能不收敛：如果 Agent 无法正确归因失败原因，反思可能无效，陷入反复失败的循环
需要失败检测机制：Agent 必须能判断"这次执行是成功还是失败"，有些场景中这并不明确

5.4 三种模式的选择框架

没有万能的推理模式，只有适合场景的模式^[4][5][6]：

维度	ReAct	Plan-then-Execute	Reflexion
核心思路	边想边做	先想后做	做了再改
全局视野	弱（局部决策）	强（全局规划）	中（通过反思积累）
灵活性	高（随时调整）	中（计划固定，重规划有开销）	高（通过反思调整）
Token 成本	中（每步都推理）	可控（按计划执行，无冗余的反思开销；但长流程的绝对消耗不一定低）	高（多次尝试 + 反思）
可解释性	高（每步都有 Thought）	高（计划可审核）	中（反思过程可读）
适用场景	任务步骤不可预知、需要根据中间结果灵活调整	任务结构清晰、步骤可预知	任务难度高、允许试错、有明确的成功/失败判定
DevOps 场景示例	故障诊断（情况复杂，需要边查边判断）	发布保障（流程明确，步骤可预知）	根因定位（可能第一次判断错误，需要反思修正）

实际工程中的常见做法是混合使用：用 Plan-then-Execute 做全局规划，在执行中的某个步骤内部用 ReAct 做局部探索，如果执行失败则用 Reflexion 做反思和重试。这不是三种模式选其一，而是在不同粒度上组合使用。

6. Agent 的系统架构分层

理解了 Agent 的内部认知架构后，我们把它放入更大的系统上下文中。一个生产级 Agent 平台通常分为四层：

latex 复制代码

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│                     触发层（Trigger）                        │
│                                                             │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │ 对话 UI   │  │ API 调用  │  │ Webhook  │  │ 定时任务  │  │
│   │ Slack/IM  │  │ REST/gRPC│  │ 事件推送  │  │ Cron     │  │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                     能力层（Skills）                         │
│                                                             │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │流水线     │  │数据库     │  │安全漏洞   │  │代码搜索   │  │
│   │故障诊断   │  │迁移       │  │扫描       │  │          │  │
│   │Skill     │  │Skill     │  │Skill     │  │Skill     │  │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
│                                                             │
│   （Skill 系列的全部内容）                                   │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                     核心层（Agent 内核）                      │
│                                                             │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │ 推理引擎  │  │ 记忆管理  │  │ 规划引擎  │  │ 执行循环  │  │
│   │ LLM +    │  │ 上下文 +  │  │ 任务分解 +│  │ 感知→推理│  │
│   │ Prompt   │  │ RAG      │  │ 计划生成  │  │ →行动→   │  │
│   │ 策略     │  │          │  │          │  │ 观察     │  │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
│                                                             │
│   （Agent 系列第 2-5 篇的核心内容）                          │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                     基座层（Foundation）                      │
│                                                             │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │ GPT-4    │  │ Claude   │  │ 本地模型   │  │ 模型路由  │  │
│   │          │  │          │  │ (Llama等) │  │ (选择     │  │
│   │          │  │          │  │          │  │  最优模型) │  │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

各层职责：

触发层：Agent 的入口。不同触发方式决定了 Agent 的感知模式------对话 UI 是交互式触发（用户实时对话），Webhook 是事件式触发（系统事件推送），定时任务是时间式触发（Cron 调度）。一个好的 Agent 平台应该支持多种触发方式，让同一个 Agent 能响应不同来源的请求。

能力层：Agent 调用的具体能力单元。这就是 Skill 系列覆盖的全部内容------每个 Skill 都有独立的 SKILL.md、输入输出契约、执行指令和安全约束。Agent 不直接调用底层 API，而是通过 Skill 间接调用，这样 Agent 的核心逻辑与具体的业务实现解耦。

核心层：Agent 的"大脑"。推理引擎选择合适的推理策略（ReAct / Plan-then-Execute / Reflexion）驱动 LLM 工作；记忆管理负责上下文窗口和长期记忆的存取；规划引擎负责任务分解和计划生成；执行循环将感知、推理、行动、观察串成完整的运转流程。

基座层：提供 LLM 能力的底层模型。不同的任务可能需要不同的模型------简单任务用小模型（成本低、速度快），复杂推理用大模型（能力强、但贵）。模型路由机制根据任务特征自动选择最合适的模型。

7. 主流 Agent 框架概览

了解了 Agent 的概念和架构后，一个自然的问题是："用什么框架来实现？"以下是目前主流的 Agent 框架及其设计哲学。本系列不绑定任何框架，讲的是通用原理，但了解框架有助于理解原理如何落地。

时效性说明 ：Agent 框架生态正处于爆发期，上述框架的具体 API、功能特性和设计模式迭代极快（例如 OpenAI 的 Assistants API 正在向 Responses API 演进，新的框架如 OpenAI Swarm 等也在持续涌现）。本节旨在剖析不同框架背后的设计哲学差异（图式编排 vs 平台托管 vs 多 Agent 对话 vs 角色扮演），这些设计哲学相对稳定，但框架的具体实现细节会持续变化。在实际选型时，建议参考各框架最新的官方文档。

7.1 LangChain / LangGraph

LangChain 是目前最流行的 LLM 应用开发框架^[7]。它提供了构建 LLM 应用的基础组件（Prompt 模板、工具调用、链式编排等）。

LangGraph 是 LangChain 的扩展，专门用于构建有状态的、多步骤的 Agent 应用^[7]。它的核心设计思想是将 Agent 的执行流程建模为有向图（Graph）：

latex 复制代码

LangGraph 的核心概念：

  节点（Node）= 一个执行步骤（调用 LLM / 调用工具 / 做判断）
  边（Edge）  = 步骤之间的转移条件
  状态（State）= 在图中流转的上下文对象

示例：
  [接收告警] → [分析日志] → [判断故障类型]
     → 数据库问题 → [查数据库] → [执行修复] → [生成报告]
     → 代码问题   → [查 Git diff] → [建议回滚] → [生成报告]
     → 未知       → [转人工]

LangGraph 的优势在于确定性控制------你可以精确定义 Agent 在每个状态下能做什么、不能做什么，避免 LLM 的"自由发挥"导致不可预测的行为。

7.2 OpenAI Assistants API

OpenAI Assistants API 是 OpenAI 提供的托管式 Agent 框架 ^[8]。开发者不需要自己搭建 Agent 的执行循环，只需定义 Assistant 的角色（System Prompt）和能力（工具列表），OpenAI 平台负责执行。

latex 复制代码

开发者定义：
  - System Prompt: "你是一个 DevOps 工程师..."
  - Tools: [日志查询函数, 数据库诊断函数, ...]

OpenAI 平台负责：
  - 接收用户消息
  - 调用 GPT-4 推理
  - 自动调用工具
  - 将工具结果反馈给 GPT-4
  - 生成最终回复

Assistants API 的优势是开箱即用------不需要管理执行循环、工具调用、上下文传递等复杂逻辑。但它的灵活性受限于平台提供的能力------比如自定义推理策略（如 Plan-then-Execute）就比较难实现。

7.3 AutoGen

AutoGen 是微软研究院开源的多智能体框架^[9]。它的核心设计思想是让多个 Agent 通过对话来协作：

latex 复制代码

AutoGen 的多 Agent 对话：

  UserProxy Agent: "订单服务报错了，帮我查一下"
     ↓
  Coder Agent: "我来写一段查询脚本"
     → 执行脚本，获取日志
     ↓
  Critic Agent: "分析结果表明是数据库锁争用，建议 kill 阻塞 SQL"
     ↓
  UserProxy Agent: "确认执行"
     ↓
  Coder Agent: "执行 kill，结果如下..."

AutoGen 的优势在于角色分离------不同 Agent 承担不同角色（编码、分析、审核），各司其职。这天然适合多智能体协作场景（第三篇会深入讨论）。

7.4 CrewAI

CrewAI 是一个基于角色扮演的多智能体编排框架^[10]。它的设计理念更偏向于将 Agent 比拟为一个"团队（Crew）"中的成员：

latex 复制代码

CrewAI 的 Crew 设计：

  Crew: DevOps Team
    Agent 1: 值班工程师（角色：接收告警、初步排查）
    Agent 2: DBA 专家（角色：数据库诊断和修复）
    Agent 3: 复盘撰写员（角色：生成复盘报告）

  Task 1: 接收告警并初步诊断 → 分配给 Agent 1
  Task 2: 深入数据库排查 → 分配给 Agent 2
  Task 3: 生成复盘报告 → 分配给 Agent 3

CrewAI 的优势在于直观的角色建模------用自然语言描述每个 Agent 的角色和目标，框架自动处理协作逻辑。

7.5 框架对比

维度	LangGraph	OpenAI Assistants API	AutoGen	CrewAI
设计哲学	图式编排（确定性控制）	平台托管（开箱即用）	多 Agent 对话（灵活协作）	角色扮演（直觉建模）
核心抽象	有向图（节点 + 边 + 状态）	Assistant + Thread + Run	Agent + GroupChat	Crew + Agent + Task
单 Agent / 多 Agent	两者都支持	主要面向单 Agent	多 Agent 为核心	多 Agent 为核心
推理策略可控性	高（可自定义每个节点的逻辑）	低（平台控制推理循环）	中（可通过 Prompt 引导）	中（通过角色定义引导）
学习曲线	较高（需要理解图编程）	低（API 调用）	中	低
适用场景	需要精确控制执行流程的生产系统	快速原型和简单 Agent	复杂多 Agent 协作	团队化多 Agent 场景
开源 / 托管	开源	托管（OpenAI 平台）	开源（微软）	开源

框架选择建议 ：如果你是第一次构建 Agent，建议从 OpenAI Assistants API 开始（学习成本最低，但注意其 API 形态可能随平台演进而调整）；如果需要精确控制执行流程，选 LangGraph（它是目前图式编排的主流选择）；如果核心需求是多 Agent 协作，选 AutoGen 或 CrewAI。但不管选哪个框架，理解本系列讲的通用原理都是必要的------框架会迭代更新，但认知架构、记忆管理、规划策略和安全防护的原理不会过时。

7.6 最小可运行 Agent 示例

理论讲了很多，但 Agent 的核心循环到底长什么样？以下是一个不依赖任何框架、用纯 Python + OpenAI API 实现的最小 Agent（约 60 行代码）。它包含了 Agent 的完整核心循环：感知→推理→行动→观察。

python 复制代码

"""
最小可运行 Agent 示例
功能：接收用户问题，自主决定调用哪个工具，直到完成任务。
依赖：pip install openai
"""

from openai import OpenAI

client = OpenAI()

# ── 定义 Agent 的"能力"（Skill / Tool）──

tools = [
    {
        "type": "function",
        "function": {
            "name": "query_logs",
            "description": "查询指定服务在指定时间范围内的日志",
            "parameters": {
                "type": "object",
                "properties": {
                    "service": {"type": "string", "description": "服务名称"},
                    "time_range": {"type": "string", "description": "时间范围，如 last_30min"}
                },
                "required": ["service", "time_range"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "query_metrics",
            "description": "查询指定服务的监控指标（错误率、延迟等）",
            "parameters": {
                "type": "object",
                "properties": {
                    "service": {"type": "string", "description": "服务名称"}
                },
                "required": ["service"]
            }
        }
    }
]

# ── 定义工具的实际执行逻辑 ──

def execute_tool(name, args):
    """模拟工具执行。实际项目中这里会调用真实的 API。"""
    if name == "query_logs":
        return f"[日志] {args['service']} 在 {args['time_range']} 内有大量数据库连接超时错误"
    elif name == "query_metrics":
        return f"[监控] {args['service']} 当前错误率 15%，P99 延迟 8.2s"
    return "未知工具"

# ── Agent 核心循环 ──

def run_agent(user_input):
    messages = [
        {"role": "system", "content": "你是一个 DevOps 工程师。分析问题并调用合适的工具来诊断和解决问题。"},
        {"role": "user", "content": user_input}
    ]

    max_iterations = 10  # 防止死循环的安全限制
    for i in range(max_iterations):
        # ① 推理：LLM 决定下一步
        response = client.chat.completions.create(
            model="gpt-4",
            messages=messages,
            tools=tools
        )
        msg = response.choices[0].message

        # ② 判断：LLM 想调用工具，还是直接回复用户？
        if msg.tool_calls:
            # ③ 行动：执行工具调用
            messages.append(msg)
            for tool_call in msg.tool_calls:
                name = tool_call.function.name
                args = eval(tool_call.function.arguments)  # 生产中应使用 json.loads
                result = execute_tool(name, args)

                # ④ 观察：将工具结果写回上下文
                messages.append({
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "content": result
                })
        else:
            # ⑤ 输出：LLM 生成最终回复
            return msg.content

    return "达到最大迭代次数，任务未完成。"

# ── 运行 ──

if __name__ == "__main__":
    result = run_agent("订单服务报错了，帮我看看什么原因")
    print(result)

这个程序包含了 Agent 的全部核心要素：

latex 复制代码

感知：user_input 接收用户输入
推理：client.chat.completions.create() 调用 LLM
判断：if msg.tool_calls 判断 LLM 是否要调用工具
行动：execute_tool() 执行工具调用
观察：messages.append(...) 将结果写回上下文
记忆：messages 列表就是工作记忆（上下文窗口）
安全：max_iterations = 10 防止死循环

缺少的（后续篇目会补充）：
  长期记忆（第 2 篇）
  规划能力（第 2 篇）
  多 Agent 协作（第 3 篇）
  提示词注入防御（第 4 篇）
  评测体系（第 5 篇）

用 LangGraph 实现同样的功能，代码更短，且多了状态管理和条件路由：

python 复制代码

"""
LangGraph 版最小 Agent (支持读取 .env 配置)
依赖：pip install python-dotenv langgraph langchain-openai langchain-core
"""

import os
from dotenv import load_dotenv

# 加载当前目录下的 .env 文件
load_dotenv()

from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

# 从环境变量读取配置
api_key = os.getenv("OPENAI_API_KEY")
base_url = os.getenv("OPENAI_BASE_URL")
# 新增：从环境变量读取模型名，如果没有配置，默认使用 gpt-4o
model_name = os.getenv("OPENAI_MODEL", "gpt-4o")

if not api_key or api_key == "sk-your-api-key-here":
    print("错误：请在 .env 文件中设置有效的 OPENAI_API_KEY")
    exit(1)

print(f"当前使用的模型: {model_name} | API地址: {base_url or '官方默认'}\n")

# 定义工具
@tool
def query_logs(service: str, time_range: str) -> str:
    """查询指定服务在指定时间范围内的日志"""
    return f"[日志] {service} 在 {time_range} 内有大量数据库连接超时错误"

@tool
def query_metrics(service: str) -> str:
    """查询指定服务的监控指标（错误率、延迟等）"""
    return f"[监控] {service} 当前错误率 15%，P99 延迟 8.2s"

tools = [query_logs, query_metrics]

# 初始化 LLM 并绑定工具
llm_kwargs = {"model": model_name, "api_key": api_key}
if base_url:
    llm_kwargs["base_url"] = base_url

llm = ChatOpenAI(**llm_kwargs).bind_tools(tools)

# 定义推理节点
def agent(state: MessagesState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

# 定义路由
def should_continue(state: MessagesState):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tools"
    return END

# 构建执行图
graph = StateGraph(MessagesState)
graph.add_node("agent", agent)
graph.add_node("tools", ToolNode(tools))
graph.add_edge(START, "agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")  # 工具执行完后回到推理节点

app = graph.compile()

# 运行
if __name__ == "__main__":
    print("Agent 已启动，正在思考中...\n")
    result = app.invoke({"messages": [("user", "订单服务报错了，帮我看看什么原因")]})
    print("\n--- 最终输出 ---")
    print(result["messages"][-1].content)

latex 复制代码

LangGraph 版本的核心优势：

  - 状态管理：MessagesState 自动管理上下文
  - 条件路由：should_continue() 实现了"调工具 or 回复用户"的动态决策
  - 循环控制：图的结构天然限制了执行流程，不会跑飞
  - 可扩展：后续添加记忆节点、规划节点只需 add_node() + add_edge()

读者动手建议：建议先运行纯 Python 版本，理解 Agent 核心循环的本质；再运行 LangGraph 版本，理解框架如何简化状态管理和编排。后续四篇将在这两个版本的基础上逐步添加记忆、规划、多 Agent 协作和安全防护。

8. 本系列路线图

围绕 Agent 的工程化，本系列共分五篇。每篇覆盖五层解剖图中的不同部分：

latex 复制代码

                 Agent 工程化指南系列地图

  ┌──────────────────────────────────────────────────────┐
  │                                                      │
  │             第 1 篇（本文）                            │
  │             概念与认知架构                              │
  │             覆盖：① 感知层 + ② 大脑层                  │
  │                    │                                 │
  │         ┌──────────┴──────────┐                     │
  │         ▼                     ▼                     │
  │   ┌──────────┐         ┌──────────┐                │
  │   │ 第 2 篇   │         │ 第 4 篇   │                │
  │   │ 记忆与    │         │ 安全与    │                │
  │   │ 规划      │         │ 防护      │                │
  │   │          │         │          │                │
  │   │③ 记忆层   │         │ 贯穿全部  │                │
  │   │④ 规划层   │         │ 五层      │                │
  │   └────┬─────┘         └──────────┘                │
  │        ▼                                            │
  │   ┌──────────┐                                     │
  │   │ 第 3 篇   │                                     │
  │   │ 编排与    │                                     │
  │   │ 多智能体  │                                     │
  │   │          │                                     │
  │   │⑤ 行动层   │                                     │
  │   │ + 通信层  │                                     │
  │   └────┬─────┘                                     │
  │        ▼                                            │
  │   ┌──────────┐                                     │
  │   │ 第 5 篇   │                                     │
  │   │ 评测与    │                                     │
  │   │ 生产治理  │                                     │
  │   │          │                                     │
  │   │全部五层   │                                     │
  │   └──────────┘                                     │
  │                                                      │
  └──────────────────────────────────────────────────────┘

各篇与 Agent 五层解剖图的对应：

层级	第 1 篇（本篇）	第 2 篇	第 3 篇	第 4 篇	第 5 篇
① 感知层	定义 + 触发方式	---	多 Agent 消息传递	---	---
② 大脑层	认知架构（ReAct 等）	---	---	推理安全（注入防御）	推理质量评测
③ 记忆层	概念	核心重点	跨 Agent 共享记忆	---	---
④ 规划层	概念	核心重点	多 Agent 编排	死循环防护	轨迹评测
⑤ 行动层	概念 + Function Calling	---	多 Agent 协作	权限控制 + 熔断	端到端评测

9. 小结

本文从凌晨两点的线上告警场景切入，引出了 Agent 的概念------它不是聊天机器人，不是工作流副驾驶，而是一个以 LLM 为大脑、能自主感知、推理、记忆和行动的智能系统。

我们定义了 Agent 的四个核心特征（自主性、反应性、目标导向、持续性）和五层解剖图（感知层、大脑层、记忆层、规划层、行动层），并明确了大脑层作为调度枢纽的中枢地位 。通过与 Chatbot、Workflow、Copilot 和 Skill 的逐一辨析，我们划清了 Agent 的概念边界。Agent 判定清单提供了判断"你手头的系统算不算 Agent"的实用工具。

在技术机制层面，我们剖析了 Function Calling 如何作为 Agent 行动层的核心引擎，让 LLM 能够决定调用哪个工具、传什么参数。

在认知架构层面，我们详细剖析了三种推理模式：ReAct（边想边做，灵活但无全局视野）、Plan-then-Execute（先想后做，全局视角强但缺乏灵活性）、Reflexion（做了再改，能自我改进但成本较高）^[4][5][6]。实际工程中，这三种模式往往在不同粒度上组合使用。

在系统架构层面，我们展示了 Agent 的四层架构（触发层、能力层、核心层、基座层），以及主流框架（LangGraph、OpenAI Assistants API、AutoGen、CrewAI）的设计哲学差异。最后，通过两个可运行的最小 Agent 示例（纯 Python 版和 LangGraph 版），我们把抽象的概念转化为了可执行的代码。

现在，你已经建立了 Agent 的完整心智模型，并且手里有一个能跑的最小 Agent。

接下来的问题是：Agent 的"记忆"和"规划"是怎么工作的？ LLM 怎么在多步推理中记住之前的信息？上下文窗口有限时怎么管理信息？任务太复杂时怎么拆解和规划？------这些 Agent 内核层面的机制，就是下一篇的主题。

下一篇预告：《Agent 工程化指南（二）：记忆与规划 --- 让 Agent "记得住"且"做得对"》

参考来源

Russell, S. & Norvig, P. (2020). "Artificial Intelligence: A Modern Approach", 4th Edition. 人工智能领域的经典教材，第 2 章 "Intelligent Agents" 系统定义了智能体的概念、特征（自主性、反应性、主动性）和架构。本文中 Agent 的四个核心特征（自主性、反应性、目标导向、持续性）源自此书的 Agent 定义框架。参见 aima.cs.berkeley.edu。
GitHub Copilot / Microsoft Copilot 的产品定位 --- Copilot 类产品的设计范式是"Human-in-the-loop"，即人类主导操作、AI 提供辅助。参见 GitHub Copilot、Microsoft Copilot。
Vaswani, A. et al. (2017). "Attention Is All You Need". Transformer 架构论文，奠定了现代 LLM 的基础。LLM 的"next-token prediction"机制源自此架构。参见 arXiv:1706.03762。
Yao, S. et al. (2022). "ReAct: Synergizing Reasoning and Acting in Language Models". 提出了 LLM 中推理（Thought）与行动（Action）交替进行的框架。在知识推理和决策任务中，ReAct 优于纯推理或纯行动模式。参见 arXiv:2210.03629。
Wang, L. et al. (2023). "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models". 提出了"先制定计划再逐步执行"的 Prompting 策略，改进了 Zero-shot CoT 在复杂推理任务中的表现。参见 arXiv:2305.04091。
Shinn, N. et al. (2023). "Reflexion: Language Agents with Verbal Reinforcement Learning". 提出了语言智能体的口头强化学习框架：Agent 通过执行→反思→改进的循环来提升任务表现。发表于 NeurIPS 2023。参见 arXiv:2303.11366。
LangChain & LangGraph --- LangChain 是开源 LLM 应用开发框架，LangGraph 是其扩展，用于构建有状态的、图式编排的 Agent 应用。参见 LangChain 文档、LangGraph 文档。
OpenAI Assistants API --- OpenAI 提供的托管式 Agent 框架，内置代码解释器、文件搜索和函数调用能力。参见 OpenAI Docs: Assistants API。
AutoGen --- 微软研究院开源的多智能体框架，核心设计是通过 Agent 间对话来协作完成任务。参见 GitHub: microsoft/autogen。
CrewAI --- 基于角色扮演的多智能体编排框架，通过定义 Agent 角色和任务来组织多 Agent 协作。参见 GitHub: crewAIInc/crewAI。
OpenAI Function Calling --- OpenAI 官方文档，详细说明了 Function Calling 的工作原理：开发者定义函数描述，LLM 根据用户输入决定调用哪个函数并生成参数，外部系统执行函数后将结果返回给 LLM。参见 OpenAI Docs: Function Calling。
Skill 与 Function Calling 的关系 --- 在 Agent 运行时中，Skill 的 name、description 和 input_schema 被注册为 Function Calling 的函数描述，LLM 通过这些描述来选择和调用 Skill。参见Skill 工程化指南系列第三篇"运行与生效"中的匹配机制章节。