Agentic AI：基于大语言模型的智能体系统

核心定义

Agentic AI 是基于大语言模型构建，通过多步骤工作流完成复杂任务的智能系统。它模仿人类解决问题的自然过程，将复杂任务拆解为多个步骤，通过规划、执行、反思、修正的循环逐步逼近最优解。

关键对比

  • 传统LLM模式：用户输入提示词，模型直接输出结果
  • Agentic AI模式：迭代式多步骤流程，贴近人类"思考→执行→优化"的自然行为

智能体工作流（Agentic Workflow）

本质：基于LLM的应用通过执行多个步骤完成任务的过程，每个步骤可以依赖LLM或者工具协作。

自主性层级（Autonomy Spectrum）

以"撰写黑洞主题文章"为例：

  • 低自主性：确定性流程（步骤由人类预先硬编码），LLM仅负责生成文本，不参与步骤决策。适合容错率低的场景
  • 高自主性：步骤由LLM自主决定，程序员不预设固定流程，LLM主导是否行动、如何执行。部分高自主性的agent可以自主编写新函数、创建新工具。但面临难控制、不可预测的挑战
  • 半自主性：LLM拥有部分决策权限（如选择工具），核心工具需要程序员预先定义，介于前两者之间，平衡灵活性与可控性

Agentic AI核心优势

  1. 突破性能上限，实现之前不可能的任务：Agentic模式（多步骤+反思优化）带来的性能提升甚至超越模型代际升级的差距
  2. 并行化处理，效率远超人类
  3. 模块化设计，灵活替换组件：可替换组件包括工具服务（搜索引擎、信息源）、LLM模型（无需全程使用同一模型，择优而选）

💡 从实际场景中发现结合应用的话需要明确了解业务场景、将过程拆解为多个步骤，融入工作流，了解整个过程中的核心难度。

应用难度影响因素

  1. 流程确定性：有明确、固定步骤还是需要LLM自主规划步骤
  2. 输入模式：仅文本资产（PDF文本、邮件）还是多模态输入（图像、音频或浏览器操作）
  3. 预先可知性：步骤/工具可提前定义还是需要实时决策动态调整

任务分解（Task Decomposition）

为什么需要任务分解

模拟人类执行任务时的步骤，直接一次性生成结果往往肤浅、不连贯，而多步协作可以高质量输出。

任务分解方法论

⚠️ 如果某一步骤效果不好，则将该步骤拆解为更小的子步骤。不能只依赖LLM，还需要结合工具，才能构建更强大的Agentic AI。

任务分解步骤

  1. 观察任务：人类如何完成、有哪些隐含步骤
  2. 初步分解：拆分成几个主要步骤
  3. 评估每一步是否可行：每一步是否可以由LLM或者工具完成，不能需要继续拆解
  4. 迭代优化：初版工作流可能不够好需要多次调整，细化测试直到达到预期效果

工作流设计原则

  1. 简单化：从1-3步的原型设计开始，后续再扩展
  2. 模块化：每个步骤尽量独立，可复用
  3. 容错与反馈：加入检查、评审步骤，避免错误累积
  4. 持续迭代

智能体评估（Evaluation Agentic AI - Evals）

💡 不要一开始就试图构建完美的评估指标

核心方法论

先构建，再观察，后评估

构建前很难预知所有可能出错的地方，最佳实践是：

  1. 先构建初步版本
  2. 手动检查其输出
  3. 寻找希望可以做得更好的地方
  4. 识别低质量输出或常见的错误模式
  5. 构建评估指标追踪错误

量化评估

将识别的错误作为客观指标，用代码精确衡量，便于追踪改进效果。

LLM作为裁判

当评估标准更主观，难以用代码精确判断时，可以使用LLM进行评估。

评估的两大主要类型

  1. 端到端评估：衡量整个智能体最终输出的整体质量
  2. 组件级评估：衡量智能体工作流中单个步骤或组件的输出质量

智能体设计模式

概述

智能体工作流的核心思想是将复杂的任务分解为一系列基础构建模块，然后通过特定的设计模式将这些模块组合、串联起来，构建出可以处理复杂问题的系统。

四大核心设计模式

  1. 反思（Reflection）

    • 模型对自己的输出进行检查、自我/外部评估、改进
    • 反思可以由生成结果的同个模型完成，也可以引入专门的审查者模型

  2. 工具使用（Tool Use）

    • 语言模型可以调用外部工具或函数，扩展自己的功能边界
    • 工具极大增强了模型的能力，使其能够执行实际操作而不仅仅是生成文本

  3. 规划（Planning）

    • 将复杂的任务拆解为可执行的子步骤
    • 意外情况发生时进行实时调整
    • 根据问题类型决定调用函数快速解决还是深度搜索

  4. 多智能体协作（Multi-Agent Collaboration）

    • 协调多个专业AI系统，处理复杂工作流的不同部分

Agentic AI VS 传统AI开发范式

维度 传统AI开发 Agentic AI开发
思维方式 端到端思维，期望模型一次性输出完美结果 系统思维，将复杂任务分解为可管理的步骤
优化策略 陷入"调参"或"等待更强模型"的循环 每个步骤相对简单，错误更容易定位和修复
可评估性 难以评估和优化 可管理、可评估、可优化

反思模式（Reflection）

核心定义

智能体设计模式，通过让AI系统评估和改进自己的输出，实现迭代优化的过程。

重要性

实际数据说明反思带来的能力提升超过模型代际升级的差距。

  • 模型越强，反思效果越好
  • 虽然反思模式需要更多计算资源，但性能提升幅度远超额外成本

反思模式的工作原理

单智能体反思

  • 使用同一个LLM进行生成和反思
  • 优点：实现简单，无需额外模型，保持上下文一致，成本相对较低
  • 缺点：同一个模型可能犯同样的错误，缺乏外部视角

多智能体反思

  • 引入专门的审查者智能体
  • 优点：引入了外部视角，减少盲点
  • 缺点：调用两次不同模型，成本较高

链式反思

多轮反思，每轮关注不同方面。

质量评估指标

客观指标

  • 代码正确率
  • 事实准确率
  • 响应时间
  • 用户满意度

主观指标

  • 逻辑连贯性
  • 表达清晰度
  • 实用性
  • 创新性

工具使用（Tool Use）

核心价值

  1. 突破知识边界：LLM训练数据有时限，无法获取最新信息
  2. 减少AI幻觉
  3. 扩展行动能力
  4. 提升任务完成度

工具分类

  1. 信息获取：搜索引擎、学术搜索、新闻、实时数据（股票、天气、交通）
  2. 计算执行：代码解析引擎、统计分析等
  3. 内容生成：生图工具（DALL-E、Midjourney、Stable Diffusion）
  4. 交互协作：邮件发送、X、Notion、Confluence

工具调用技术机制详解

核心原理

LLM工具调用的本质：模型判断"是否需要调用工具" → 选择哪个工具 → 传递什么参数 → 生成结构化调用指令（JSON） → 应用层执行真实函数 → 结果反馈给模型生成最终回复

LLM工具调用演变：早期模式 → 现代范式

1. 早期模式（2023年6月之前）：Prompt + Regex

典型做法

开发者通过提示词强制模型输出特定格式，再用正则表达式解析：

# 系统提示中指定输出格式
system_prompt = "当需要查询天气时，请输出：CALL: get_weather(city='Beijing')"

# 模型生成自由文本
model_output = "CALL: search(query='LLM 工具调用原理')"

# 应用层用正则提取函数名和参数
pattern = r"CALL:\s*(\w+)\(([^)]+)\)"
match = re.search(pattern, model_output)
# 提取：函数名="search", 参数="query='LLM 工具调用原理'"

主要问题

问题 说明
解析失败率高 模型可能输出多余文字、格式偏差、缺少括号等，导致正则匹配失败
不稳定 不同模型/版本对提示词理解不同，格式容易"漂移"
难以扩展 工具参数复杂时，提示词变得巨大，且无法保证参数类型/结构正确
无类型约束 没有JSON Schema，无法强制参数类型、必填项、枚举值等

2. 现代范式（2023年6月至今）：Function Calling + JSON Schema

OpenAI阶段2：functions参数（2023.6-2023.11）

{
  "model": "gpt-4-0613",
  "messages": [{"role": "user", "content": "上海今天天气如何？"}],
  "functions": [
    {
      "name": "get_weather",
      "description": "查询某地天气",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string", "description": "城市名"}
        },
        "required": ["city"]
      }
    }
  ]
}

模型返回：

{
  "function_call": {
    "name": "get_weather",
    "arguments": {"city": "上海"}
  }
}

OpenAI阶段3：tools参数 + strict: true（2023.11至今）

{
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "搜索一下 LLM 工具调用机制"}],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "search",
        "description": "搜索引擎查询",
        "parameters": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "搜索关键词"
            }
          },
          "required": ["query"]
        },
        "strict": true
      }
    }
  ]
}

模型返回：

{
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "search",
        "arguments": {"query": "LLM 工具调用机制"}
      }
    }
  ]
}

JSON Schema的作用

作用 说明
参数类型约束 强制query为string，避免模型输出数字/布尔值等错误类型
必填项声明 required: ["query"]确保关键参数不缺失
枚举/格式限制 可定义enum: ["cn", "us"]或"format": "email"等
嵌套结构支持 支持复杂对象、数组等嵌套参数结构
模型生成指导 模型根据Schema生成符合结构的JSON，而非自由文本

关键对比：早期 vs 现代

维度 早期（Prompt + Regex） 现代（Function Calling + JSON Schema）
输出形式 自由文本（如CALL: fn(...)） 结构化JSON（tool_calls对象）
解析方式 正则表达式匹配 API直接返回结构化对象，无需解析
可靠性 解析失败率高，格式不稳定 解析失败率接近零，格式稳定
类型约束 无，模型可能输出错误类型 JSON Schema强制类型/必填/枚举等
扩展性 工具复杂时提示词巨大，难以维护 工具定义集中，支持并行调用、多工具链
是否需微调 不需要，但依赖提示词技巧 模型已微调，天然支持工具调用
严格模式 ❌ 不支持 ✅ 支持strict: true，强制匹配Schema
并行调用 ❌ 不支持单响应多调用 ✅ 支持tool_calls数组
代表时间 2023年6月之前 2023年6月OpenAI推出，2023年11月升级

转变的本质

从"用提示词勉强引导模型输出格式" → “模型原生支持结构化API协议”

  • 早期：靠提示词工程 + 正则解析，可靠性低、难以扩展
  • 现代：靠模型微调 + 受约束解码 + JSON Schema，输出天然符合Schema，解析失败率接近零

现代主流LLM API（OpenAI、Anthropic、Google等）已原生支持结构化函数调用，早期自然语言提示 + 正则匹配的方式已被淘汰。

多智能体协作

多智能体架构设计

  1. 层级式协作（Chief Agent）
  2. 对等式协作：协商、投票、辩论
  3. 市场机制协作：任务分配和资源协调建模为经济系统
  4. 混合式协作：不同阶段、不同任务类型、不同环境调整

通信协议与消息传递

多智能体系统需要明确的通信协议来确保信息的准确传递和协调。

角色专业化与智能体设计

多智能体系统的强大来源于智能体的专业化分工：

  • 规划者智能体
  • 执行者智能体
  • 评审者智能体
  • 协调者智能体
  • 领域专家智能体
  • 创意者智能体

反思机制：智能体的自我改进循环

技术实现

1. 单轮反思模式

生成初始响应 → 反思评估 → 基于反思改进

2. 多轮反思模式（循环改进）

单轮不足以生成高质量解决方案，多轮可以避免陷入局部最优。

3. 分布式反思与交叉验证

反思采用分布式形式，由多个智能体从不同角度评估，最后综合评估结果。

委员会评审

  • 减少个体偏见
  • 利用多样化视角
  • 提高评估的全面性和可靠性

辩论式反思

  • 增加了协调成本和计算开销

反思触发机制

基于规则的触发

  • 任务复杂度评分超过阈值时触发深度反思
  • 智能体对自身响应的置信度低于阈值时触发反思
  • 涉及敏感话题时
  • 用户明确要求时

基于学习的触发

使用机器学习模型预测何时需要反思。

自适应触发策略

  • 学习不同触发策略在不同情境下的效果，动态选择最优策略
  • 学习反思的强度——表面还是深度全面，系统需要在这之间平衡

多智能体协作的实践模式

1. 辩论式协作

让多个智能体从不同角度或立场讨论问题，在观点交锋中产生更深入的理解和更优的解决方案。

案例：技术架构决策

2. 流水线式协作

将任务拆分为一系列顺序处理，每个阶段由专业化智能体负责，前一阶段的输出作为后一阶段的输入。

3. 委员会式决策

多个专家智能体独立分析同一问题，通过集体决策机制整合意见，形成最终决策。

辩论式与委员会式的区别

辩论式

  • 目标是提升推理质量和鲁棒性
  • 揭示论点弱点，逼近全局最优解
  • 复杂问题上减轻单一代理的偏见
  • 适合需要多角度推理和探索性分析的情景，例如复杂推理、设计评估等

委员会式

  • 以专家意见为主，通过不同方式来整合观点
  • 更偏向审查与合规性
  • 在需要权威、可追溯的结论与标准化评审的场景更合适
  • 例如代码评审、合规审查、技术标准制定等

挑战与解决方案

挑战1：通信、同步、协调成本超过协作收益

问题表现

  • 通信延迟
  • 网络拥塞
  • 计算资源处理协调消息，而非专注于核心任务
  • 等待时间造成资源空闲

挑战2：产生分歧，难达成共识

问题表现

  • 决策延迟
  • 决策无效

挑战3：系统不稳定

问题表现

  • 反馈循环
  • 级联故障
  • 资源竞争

挑战4：成本控制

问题表现

  • 计算成本
  • 存储成本
  • API调用成本

评估框架与性能指标

1. 任务完成质量

系统输出是否符合要求（相关性、准确性、完整性、创新性等）

测量方法

  • 人工评估
  • 自动评分

2. 协作效率

智能体协作效果和效率（时间、通信开销、协调成本等）

测量方法

  • 系统日志分析
  • 时间戳追踪
  • 量化指标测量

3. 系统鲁棒性

系统应对异常和变化的能力

4. 可扩展性

系统处理更大规模任务或更多智能体的能力

5. 成本效益

系统产出的经济效益（投资回报率ROI - Return on Investment等）

💡 长尾需求：数量庞大、但每个需求单独出现频率极低、个性化强的小众需求。