Agent

一句话定义

AI Agent（人工智能智能体）是具备自主感知、推理、决策与行动能力的软件实体，其核心是“利用 AI 模型与环境交互，解决用户定义的任务”，通过循环调用大语言模型的认知能力与外部工具的操作能力，实现端到端任务闭环 。

为什么需要 Agent？（核心价值）

• 弥补大模型短板：大模型是“认知天才但无手脚”，Agent 为其赋予工具调用能力（如搜索、计算、操作API），突破纯文本限制

• 超越传统程序：传统程序是“预设逻辑的傀儡”，Agent 具备动态适应能力（根据环境反馈调整策略），处理模糊、开放性任务

• 实现任务自动化：将人类意图（如“整理周报”）转化为可执行动作链，减少重复劳动

四大核心组件（缺一不可）

ReAct、Planning、Graph 等均为 Agent 的实现技术或架构模式，而 Agent 本身是更高层的概念——如同“汽车”是概念，“发动机+变速箱”是实现组件。

Copilot

Copilot（副驾驶）是嵌入具体工作流的 AI 辅助工具，核心定位是 “增强人类效率”而非替代人类。典型产品包括：

• GitHub Copilot：代码补全、注释生成、调试建议（编程场景）

• Microsoft 365 Copilot：在 Word/Excel/Teams 中总结邮件、生成文档、数据分析

• Excel Copilot：表格数据可视化、公式建议

• Copilot for CLI：命令行工具辅助（无需记忆复杂 shell 命令）

核心特点：
✅ 上下文感知：深度理解当前工作环境（如代码文件、Excel 表格）
✅ 人主导，AI 建议：提供选项供人类选择/确认（如“接受此代码建议？”）
✅ 轻量嵌入：无缝集成到现有工具（VS Code、Office 等），降低使用门槛
✅ 场景聚焦：解决单一领域高频痛点（写代码、处理表格、写邮件）

💡 本质：Copilot 是 “有边界的智能助手” ——它在人类设定的框架内提供精准辅助，但不主动发起复杂任务链 。

Copilot 与 Agent 的关系：光谱而非对立

典型场景对比

核心结论

1. Copilot 是 Agent 的“场景化子集”

   • 所有 Copilot 本质都是特定领域的轻量 Agent（如 GitHub Copilot = 代码生成 Agent），但设计上刻意限制自主性以保障安全与可控

   • Agent 是更广义的概念，Copilot 是其在生产力工具中的成功实践

2. 演进趋势：边界正在融合

   • 新一代 Copilot（如 Microsoft 365 Copilot）已支持多步骤任务（“总结会议→生成待办→同步日历”），逐步吸收 Agent 的规划与工具调用能力

   • 反之，企业级 Agent 系统也借鉴 Copilot 的上下文感知与用户体验设计（如 Spring AI Alibaba Graph 的可视化编排）

3. 选择逻辑

   • ✅ 需快速提升单点效率（写代码、写文档）→ 选 Copilot

   • ✅ 需自动化复杂业务流程（跨系统数据整合、多角色协作）→ 选 Agent 框架（如 Spring AI Alibaba Graph）

   • ✅ 未来方向：Copilot 增强为“可控 Agent”，Agent 借鉴 Copilot 的易用性，二者终将统一于“人机协同智能体”范式

🌐 一句话总结：Copilot 是“坐在你副驾的智能助手”，Agent 是“能独自开车抵达目的地的司机”——前者重辅助体验，后者重任务闭环，但技术同源、生态共生。

Skills

一句话定义

Skills（技能）是模块化的“能力扩展包”，通过封装领域知识、工具调用方法与执行流程，赋予通用大语言模型（LLM）解决特定任务的专业能力，本质是“让Agent拥有可复用的专业手脚” 。

关键突破：Skills 将“能力”从提示词中解耦，实现模块化、可复用、可共享的Agent能力构建范式 。

为什么需要 Skills

关键突破：Skills 将“能力”从提示词中解耦，实现模块化、可复用、可共享的Agent能力构建范式 。

核心组成与结构

Skills 通常以文件系统目录形式存在

设计哲学：自文档化（人类可读）、可移植（跨模型/平台）、渐进式披露（按需加载） 。

pdf-processor-skill/

├── SKILL.md          # 核心文件：YAML元数据 + Markdown指令

├── scripts/          # 可执行代码（merge.py, extract_text.py）

├── resources/        # 领域资料（示例PDF、使用指南）

└── requirements.txt  # 依赖环境

工作原理（三阶段）

1. Discovery（发现）
   Agent 启动时仅加载 Skills 的名称与描述，判断何时可能需要该技能

2. Activation（激活）
   当用户任务匹配 Skill 描述时，Agent 读取完整 SKILL.md 指令到上下文

3. Execution（执行）
   Agent 按指令调用脚本/工具，或参考资源生成结果

示例：用户说“合并这两份PDF” → Agent 激活 PDF-Processor Skill → 执行 merge_pdfs.py → 返回合并文件 。

与相关概念的关系

典型 Skills 示例

一句话总结：Skills 是连接通用大模型与垂直领域需求的关键桥梁，让 AI 从“万能但浅薄”走向“专业且可靠”。

ReAct （Reasoning + Acting）

“思考（Reason）→ 行动（Act）→ 观察（Observe）”的动态循环。

就像“边走边问路”——每做一步就看结果、随时调整（比如找钥匙：翻抽屉没找到，立刻换柜子继续找）；

Planning

Agent 先全局分解任务为有序子步骤（常基于思维链 CoT），明确依赖关系后执行，强调“先谋后动”。

像“出门前先看地图”——先把完整步骤理清楚再行动（比如做蛋糕：先列好“买材料→打蛋→烤制”流程，再一步步执行）

CoT（Chain of Thought）

Planning的“分解引擎”

Reflection（反思）

修正错误，若ReAct执行中某步失败，可触发Reflection重新规划该步骤

ReWOO/LLM Compiler

ReWOO（Reasoning Without Observation，无观察推理）

Planning的效率优化变体，ReWOO解耦规划与执行以提升效率；

“写好菜谱再做饭”：Planner一次性生成完整步骤（含变量占位符），Worker执行后由Solver汇总结果，全程无需LLM中途“看火候”

LLM视为编译器，把用户任务“编译”成任务依赖图（DAG），实现子任务的并行调度与执行，大幅提升复杂任务处理速度。

LLM Compiler将计划转为DAG实现并行；

LLM Compiler是ReWOO的进阶，将串行计划升级为并行DAG。

“智能流水线”：LLM将任务“编译”成任务依赖图（DAG），独立步骤自动并行执行（如同时查多家价格），依赖步骤自动等待结果

演进逻辑：ReAct（边做边看）→ ReWOO（写好菜谱再做）→ LLM Compiler（设计智能流水线并行做）

Tool Use（工具使用）

ReAct的“手脚”

核心协同逻辑

Planning 与 ReAct 互补共生

• Planning定“做什么”（战略骨架），ReAct管“怎么做”（战术执行）

• 典型架构：Plan-and-Execute = Planner（生成步骤） + Executor（ReAct循环调用Tool Use执行每步）

• 例：规划上海3日游（Planning）→ 每步查酒店/门票时用ReAct动态调API

CoT 是 Planning 的“引擎”

• Planning依赖CoT将任务拆解为子步骤（如“生成图片”→“检测姿势→渲染”）

• ReAct中“思考（Thought）”步骤也隐含CoT式逐步推理

Reflection 为全链路“兜底”

• 若Planning步骤错误或ReAct执行失败，Reflection触发修正（如代码生成后检查编译错误）

• 使Agent从“一次性工具”升级为“持续学习的智能体”

ReWOO/LLM Compiler 是 Planning 的“效率革命”

• ReWOO：解耦规划与执行，避免中间观察，大幅减少Token消耗（Planning的串行优化）

• LLM Compiler：将Planning的线性步骤升级为DAG，实现并行调度（如同时查多家酒店价格，提速3.6倍）

• 二者保留Planning的宏观结构，但用工程思维优化执行流

Tool Use 是行动基石

• 无Tool Use，Planning/ReAct仅是纸上谈兵；所有“行动（Act）”均需Tool Use实现

• 是ReAct中“行动”步骤、Planning中“执行子任务”的共同载体

Spring AI Alibaba Graph 和 LangGraph

一句话定义
Spring AI Alibaba Graph 是 Spring AI Alibaba 框架的核心模块，将智能体工作流建模为有向图（Graph），通过声明式方式定义节点（Node）与边（Edge）的流转逻辑，实现工作流、多智能体等复杂AI应用的高效编排 。

Spring AI Alibaba Graph 是 “智能体工作流的操作系统” ——它将零散的 AI 能力（LLM、工具等）通过图结构有机整合，让开发者专注业务逻辑设计，而非底层调度细节，显著提升复杂 AI 应用的开发效率与可维护性

设计定位与目标

• 区别于 Spring AI 仅提供底层原子能力（如ChatClient、EmbeddingModel），Graph 模块聚焦 “智能体应用层”抽象，降低开发者构建复杂AI应用的门槛

• 核心目标：让开发者像“搭积木”一样构建智能体工作流，无需手动管理状态流转与节点调度

核心思想

1. 图结构建模：将工作流抽象为节点（执行逻辑）与边（跳转规则）组成的有向图

2. 状态驱动执行：所有数据通过全局状态对象（OverAllState）在节点间传递，确保状态一致性与可追溯性

3. 声明式编程：开发者只需描述“做什么”（定义节点与边），框架自动处理“怎么做”（调度、状态管理、错误处理）

4. 异步优先：原生支持异步执行与流式处理，适配高并发场景

关键组件

工作流程三阶段

1. 构建（Build）：定义OverAllState Schema → 添加Nodes → 添加Edges → 形成StateGraph

2. 编译（Compile）：调用.compile()进行结构校验（如孤立节点检查）、注入运行时配置（如检查点器）

3. 执行（Execute）：传入初始State与配置，框架按图流转执行，自动管理状态传递与持久化

与 LangGraph 的关系

• 继承：设计理念与核心概念（State/Node/Edge）高度借鉴 LangGraph（Python领域智能体框架）

• 增强：
  ✅ Java 原生实现：适配 Spring 生态，支持依赖注入、AOP 等企业级特性
  ✅ 预置节点库：内置大量常用 Node（如工具调用、RAG 节点），减少重复开发
  ✅ 简化 State 定义：通过 KeyStrategy 等机制降低状态管理复杂度
  ✅ 深度集成 Spring AI：无缝调用 Spring AI 的原子能力（ChatClient、Function Calling 等）

典型应用场景

• 多智能体协作（如客服系统：分类→检索→生成→评估）

• 复杂工作流编排（如内容创作：需求分析→生成→质检→发布）

• ReAct 范式智能体（推理-行动循环）

• 数据分析流水线（数据收集→清洗→推理→可视化）

核心价值：将智能体开发从“硬编码串联”升级为“可视化编排”，显著提升开发效率与可维护性，是 Spring AI Alibaba 区别于基础 Spring AI 的关键创新 。

Skills 与 Graph

一句话定调
Skills 是 “能做什么”（封装单一专业能力的积木块），Graph 是 “如何组合做”（定义多能力协作流程的搭建图纸）——二者是 内容与结构、执行单元与调度框架 的互补关系 。

深度协同：Graph 如何调度 Skills

1. Node 即 Skill 容器
   Spring AI Alibaba Graph 中，每个 Node 可设计为调用一个或多个 Skills：

   // 定义“处理PDF"节点，内部激活 PDF-Processor Skill graph.addNode("merge_pdfs", state ->      pdfSkill.execute(state.getFiles()) // Skill 作为 Node 的执行逻辑 );

2. Skills 是 Graph 的“能力基石”

   • Graph 工作流中的操作步骤（如“搜索”“生成报告”）均由对应 Skill 实现

   • 无 Skills 支撑，Graph 仅是空洞流程；无 Graph 编排，Skills 仅是孤立能力包

3. 渐进式开发范式

   • Step 1：构建通用 Skills（如 Brand-Guidelines Skill）

   • Step 2：通过 Graph 将 Skills 组合成垂直 Agent（如“营销内容生成工作流”）

终极总结

• 区别本质：Skills = 能力内容（What），Graph = 流程结构（How）

• 协同价值：Graph 为 Skills 提供 “舞台与剧本”，Skills 为 Graph 提供 “演员与道具”

• 生态趋势：
  ✅ Skills 市场（如 Mulerun）提供标准化“能力积木”
  ✅ Graph 框架（如 Spring AI Alibaba）提供可视化“搭建工具”

• 黄金法则：

  “没有 Skills 的 Graph 是无米之炊，没有 Graph 的 Skills 是散沙一盘”
  二者融合实现 “标准化能力 × 灵活编排” 的乘数效应，是企业级 Agent 应用的核心范式 。