Agent学习笔记-理论篇

AI智能体是具备感知环境、制定计划、执行行动和学习改进能力的自主AI系统。智能体能够理解任务目标、分析当前状态、制定行动策略，并通过API调用、工具使用等方式与外部环境交互完成复杂任务。智能体代表了从被动的问答助手向主动的任务执行者的重要演进。AI Agent并非独立技术，而是完全依赖于大模型LLM技术性能，只是针对特定领域场景下的再次开发封装，所以AI智能体所调用的大模型性能，决定了智能体的性能。

多智能体协作（Multi-Agent） 是指多个 AI 智能体分工合作，共同完成复杂任务。

LLM本质上是封闭的——它无法主动感知环境、调用工具或操作外部系统。这一局限促使行业从“LLM为中心”转向“Agent为中心”。Agent的本质是为LLM这个“大脑”装配了可执行的“躯体”和“感官”，对技术同学也意味着可以将过去需要人工介入的复杂流程实现自动化，帮助业务实现又快又稳的迭代。

AI Agent

AI Agent（智能体） 是一个具备以下三大能力的智能系统：

1. 自主感知：能够理解当前环境和任务需求
2. 自主决策：能够制定执行计划并动态调整
3. 自主执行：能够调用工具完成实际任务

用一句话总结：Agent = LLM（大脑） + 工具（手脚） + 记忆（经验） + 规划（智慧）

本质区别：ChatGPT给建议，Agent帮你干活。

Agent架构

这个架构可以分为四个核心层：

• 第一层：感知层（Perception Layer）

  • 作用：接收并理解用户输入
  • 组件：用户输入 → 大语言模型理解
  • 类比：就像人的耳朵和眼睛

• 第二层：认知层（Cognition Layer）

  • 作用：分析、推理、规划
  • 组件：LLM Brain + 规划模块 + 推理引擎
  • 类比：就像人的大脑

• 第三层：执行层（Execution Layer）

  • 作用：调用各种工具完成任务
  • 组件：工具集（搜索、代码、API等）
  • 类比：就像人的手脚

• 第四层：记忆层（Memory Layer）

  • 作用：存储和检索信息
  • 组件：短期记忆 + 长期记忆
  • 类比：就像人的记忆系统

例：找出2024年诺贝尔物理学奖获得者，并总结他们的主要贡献

步骤1: 用户输入
   → 进入规划模块：识别需要「搜索」和「总结」两个步骤

步骤2: 规划完成
   → 进入推理引擎（ReAct框架）

步骤3: 第一轮思考-行动-观察循环
   Thought: "我需要搜索2024年诺贝尔物理学奖获得者"
   Action: 调用搜索工具search("2024 Nobel Prize Physics")
   Observation: 获得搜索结果→ "John Hopfield和Geoffrey Hinton"

步骤4: 第二轮思考-行动-观察循环
   Thought: "我需要了解他们的贡献"
   Action: 调用搜索工具search("Hopfield Hinton 神经网络贡献")
   Observation: 获得详细信息→ "人工神经网络和机器学习基础"

步骤5: 综合信息
   → LLM整合所有观察结果
   → 生成结构化答案
   → 存入记忆模块（长期记忆）

步骤6: 输出结果
   → 返回完整答案给用户

Agent不是一次性生成答案，而是通过多轮思考-行动-观察的循环，逐步接近最终答案。这就是Agent比传统LLM强大的地方。

Agent的四大组成部分

1. 大脑：LLM

   • 推理：理解任务
   • 生成：生成策略

2. 规划：Planning

   • 拆解：任务拆解
   • 优化：路径规划

3. 记忆：Memory

   • 短期：上下文
   • 长期：知识库

4. 工具：Tools

   • 搜索：Web Search
   • 执行：Code Execution
   • 交互：API Calls

大语言模型（LLM Brain）

LLM是Agent的「大脑」，负责：理解用户意图, 生成推理过程, 决策选择工具, 综合信息输出

规划模块（Planning）

Agent的工作模式。

Plan-and-Execute

先计划后执行。

开始任务 =》规划完整任务列表 =》同步执行任务1、任务2、... =》结果合并 =》任务完成

Plan-and-Execute特点：

• ✅ 高效：只需调用一次LLM规划
• ✅ 可并行执行多个任务
• ❌ 不灵活：难以根据中间结果调整

1. 探索性任务（不知道中间会遇到什么）→ 用ReAct
2. 流程明确的任务（步骤固定）→ 用Plan-and-Execute

ReAct模式

ReAct（Reasoning and Acting）模式是现代Agent系统的核心架构模式，它将LLM与工具集结合起来，实现了 推理-行动-观察 的循环。

第一轮推理 =》 第一轮行动 =》 第一轮反馈
第二轮推理 =》 第二轮行动 =》 第二轮反馈
...
第n轮推理 =》 第n轮行动 =》 第n轮反馈（结束，输出结果）

开始任务 =》思考1 =》行动1 =》观察1 =》思考2 =》行动2 =》观察2 =》... =》任务完成

ReAct特点：

• ✅ 灵活：可以根据中间结果调整计划
• ✅ 适合探索性任务
• ❌ Token消耗大：每一步都要调用LLM

相关应用：AutoGPT, Perplexity, Manus, Cursor, GenSpark

思维链(CoT,Chain of Thought)

通过在提示中加入引导（如 "Let's think step by step"），促使 LLM 显式地生成一系列中间推理步骤，而不是直接输出最终答案。这种将复杂问题分解为有序原子步骤的过程，显著提高了模型在逻辑、数学和规划任务上的准确性。

问题 =》思考1 =》 思考2 =》 思考3 =》 ... =》 答案

特点：

• 只有思考，没有行动
• 适合纯逻辑推理问题
• Token消耗少

在多步推理链（如 CoT）中，早期步骤的微小错误（如计算错误、逻辑前提误判）会被后续步骤继承并放大，导致整个推理链路偏离正确方向，最终得出完全错误的结果。

思维树 (ToT, Tree of Thoughts)

对于解决空间巨大或需要规划的复杂问题，ToT 框架允许 Agent 在思维空间中探索多条可能的路径。它将推理过程建模为一棵树，每个节点代表一个思维步骤。Agent 可以生成多个分支，评估每个分支的潜力，并使用搜索算法（如 BFS 或 DFS）选择最优路径继续探索，支持回溯机制。

思维图 (GoT, Graph of Thoughts)

将推理过程建模为有向图结构，是 ToT 的泛化形式。思维节点（Thought）不仅可以分叉，还可以合并、循环，形成复杂的依赖关系网络。这使得 Agent 能够从多个前序思维中聚合信息，或者在迭代过程中回流到之前的思维节点，适用于需要综合多视角信息或进行迭代优化的复杂问题。

自我反思 (Self-Reflection)

要求 Agent 在生成初步结果或采取行动后，暂时跳出当前任务视角，扮演一个独立的“批评者”角色。它会审视自己的输出是否符合要求、推理是否存在逻辑漏洞、行动是否产生了预期效果，并基于这些评估生成自我批评，进而指导生成改进后的结果或修正后的计划。

Self-Ask

自问自答

主问题 =》 分解 =》 子问题1/子问题2/... =》 回答1/回答2/... =》 整合 =》 最终答案

主问题："iPhone 15的屏幕比iPhone 14大多少？"

Agent自问自答：
Q1: "iPhone 15的屏幕尺寸是多少？"
→ 搜索得到：6.1英寸

Q2: "iPhone 14的屏幕尺寸是多少？"
→ 搜索得到：6.1英寸

Q3: "6.1英寸 - 6.1英寸 = ?"
→ 计算得到：0英寸

最终答案："iPhone 15和iPhone 14的屏幕尺寸相同，都是6.1英寸。"

记忆模块（Memory）

短期记忆（Short-term Memory）

保存当前任务的上下文。

存储内容：当前对话历史，中间步骤的结果，临时变量和状态

短期记忆的挑战：

• Token限制：GPT-4有128K token限制，长对话会超出
• 成本问题：每次调用都要把整个历史发送给LLM

解决方案：使用摘要记忆，自动总结历史对话

长期记忆（Long-term Memory）

存储可复用的知识和经验。

存储内容：用户的个人信息和偏好，历史任务的成功经验，领域知识库，工具使用的最佳实践

使用向量数据库存储和检索长期记忆，RAG

记忆模块的高级技巧

1. 自动清理不重要的记忆：基于重要性评分的记忆管理，让LLM判断是否重要，比如只存储重要度>=7的信息
2. 记忆的时效性管理：给记忆加上时间戳，检索时过滤过期记忆

工具集（Tools）

如果说LLM是Agent的大脑，那工具就是Agent的「手脚」和「超能力」。

通过工具，Agent可以：

• 🔍 搜索互联网
• 💻 执行代码
• 📊 操作数据库
• 🔧 调用API
• 🖥️ 控制电脑

工具的定义

1. 清晰的名称：Agent通过名称快速识别工具
2. 详细的描述：告诉Agent什么时候用、怎么用
3. 标准的输入输出：保证工具能被正确调用
4. 工具要有错误处理机制：当工具调用失败时，Agent能及时发现并处理
5. 工具要有使用日志：记录工具的调用情况，方便调试和优化

方式

• Function Calling: 一种使 LLM 能够与外部系统交互的机制。开发者提供可用函数（工具）的结构化定义（Schema），包括函数名、功能描述、参数列表及其约束。
• Model Context Protocol (MCP)：一种标准化的开放协议，旨在统一 LLM Agent 与外部世界（包括数据源、工具集、或其他 Agent）的交互方式。它定义了一套通用的消息格式和接口规范，使得 Agent 能够以一致的方式发现、连接和操作异构的外部资源，降低了集成复杂系统的难度。
• Claude Skills：一种由 Anthropic 提出的模块专业化机制，允许为模型“安装”特定领域的专家能力包。每个 Skill 是一个独立的文件夹，包含领域知识、工具定义、行为规范和使用说明（通常以 SKILL.md 文件形式存在）。
• 代码解释器 (Code Interpreter / Sandbox)：为 LLM 提供一个安全的、隔离的编程环境（沙箱）。LLM 可以针对计算密集型或数据处理任务编写代码（通常是 Python），并将其发送到沙箱中执行。

Agent的难点

1. 无限循环与任务卡死：Agent可能陷入死循环

• 解决方法：
  • 设置最大循环次数
  • 优化提示词，明确终止条件
  • 实现智能终止判断：根据任务状态和中间结果，判断是否需要终止循环

2. 工具选择错误：Agent可能选择了错误的工具

• 原因：工具描述不清晰，Prompt没有给出使用规则，LLM对任务理解有偏差
• 解决方法：
  • 改进工具描述
  • 添加工具使用示例
  • 实现工具推荐系统：根据任务需求和上下文，推荐合适的工具

3. 上下文窗口溢出：长对话或复杂任务会导致上下文窗口超出限制

• 解决方法：
  • 智能压缩上下文：保留最近4000 tokens，旧的对话总结
  • 分层记忆：
    • 最近3轮，完整保留
    • 中期10轮，保留关键信息
    • 长期，向量检索
  • 动态工具加载：要一次性加载所有工具，根据任务动态选择工具；创建Agent时只加载需要的工具

4. 错误处理与鲁棒性：各种错误会导致Agent崩溃（工具调用失败、API超时、返回格式错误、LLM输出异常）

• 问题描述：各种错误会导致Agent崩溃（工具调用失败、API超时、返回格式错误、LLM输出异常）
• 解决方法：
  • 工具层面的错误处理
  • Agent层面的降级策略
  • 实时监控与告警

5. 成本控制：Agent的成本可能很高

• 问题描述：Agent的成本包括LLM调用成本、存储成本等
• 解决方法：
  • 模型分级使用：根据任务复杂度和成本，选择不同的LLM模型
  • 缓存机制：缓存常用的中间结果，避免重复计算
  • 批处理：将相似任务分组，一次性处理一组任务
  • 设置预算限制：限制Agent的总调用次数和总成本

Workflow Agent

工作流Agent，Plan-and-Execute的工作模式。

工作流式是一种由开发者预先定义任务执行流程的架构模式。Agent 不依赖运行时动态规划，而是严格按照预设的控制流，包括链式、路由、并行或状态驱动等，执行一系列结构化子任务。其核心思想是：将复杂目标拆解为可管理、可监控、可审计的原子步骤，并通过显式编排实现端到端自动化。

LLM的问题：

1. LLM 会有幻觉
2. LLM 只会说，不会做
3. LLM 规划的步骤不靠谱

Workflow Agent功能：

1. 用 RAG 技术构建私有知识库，提升对话能力
2. 用设计者定义好的 Workflow 完成特定任务
3. 过程中使用工具完成 LLM 无法完成的任务
4. 让 LLM 写代码，完成数据处理、数学计算

Workflow Agent 非常适合准确性要求较高的场景

模型提供智能，Agent 保证结果

Multi-Agent

模拟人类组织的协作模式，将复杂任务分解并分配给多个具有不同角色设定、专业技能和工具权限的独立 Agent。这些 Agent 通过预定义的通信协议（如消息传递、共享黑板）和标准作业流程 (SOP) 进行交互和协作，从而实现超越单体智能的群体智能涌现，解决复杂的跨领域问题。

假设你要开发一个完整的软件产品：

单Agent模式：
Agent：「我既要写需求文档，又要写代码，还要测试，还要设计UI...」
→ 能力有限
→ 容易出错
→ 效率低下

多Agent模式：
产品经理Agent：负责需求分析
架构师Agent：负责系统设计
开发Agent：负责编写代码
测试Agent：负责质量保证
UI设计Agent：负责界面设计

→ 专业分工
→ 并行工作
→ 质量更高

多Agent协作模式

• 层级结构（Hierarchical）：管理者Agent负责协调其他Agent，分配任务，监控进度，协调资源。
• 平等协作（Collaborative）：Agents地位平等，可以相互协商和讨论；适合需要多角度思考的复杂问题
• 流水线（Pipeline）：固定的处理顺序，每个Agent专注于流程中的一个阶段，适合有明确步骤的任务

输入 =》 Agent1:预处理 =》 Agent2:核心处理 =》 Agent3:后处理 =》 输出，例：内容创作流水线

多Agent的关键挑战

1. 通信开销：多个Agent之间需要频繁通信，成本和延迟都很高
   • 解决方法：使用结构化消息，Agent直接处理结构化消息，只在必要时调用LLM
2. 死锁和循环依赖：两个Agent互相等待
   • 解决方法：超时和fallback机制
3. 结果冲突：不同Agent给出不同的答案
   • 解决方法：投票或仲裁机制

主流Agent开发框架

Langchain，AutoGen，Dify

LangChain

优势：

1. 丰富的集成：一站式RAG方案
2. 灵活的链式组合
3. 强大的记忆管理

生态最丰富，什么都能接。但抽象层太多了，debug的时候你经常不知道问题出在哪一层。适合快速原型，不太适合需要精细控制的场景。

• LangGraph

LangChain团队出的，专门做Agent的流程编排。比LangChain本身好用——它用图的方式定义Agent的状态流转，对”Agent接下来该做什么”有更直观的控制。

AutoGen

多Agent协作模式，平等协作（Collaborative）

多个Agent同时工作，并行任务

CrewAI

角色扮演框架

定义角色，定义任务，组建团队，顺序执行

Dify

可视化工作流编排

优势：

• ✅ 拖拽式设计，无需代码
• ✅ 内置RAG、Agent、工作流模板
• ✅ 可视化调试和监控
• ✅ 一键部署API

适用场景：快速原型验证，业务人员使用，低代码场景

Coze

Manus

Agent性能优化

1. 提示词工程优化

   • Few-Shot Examples，多问答样例
   • Chain of Thought，引导逐步思考，分解复杂任务
   • 角色扮演，明确角色

2. 工具调用优化

   • 工具描述标准化
   • 工具调用缓存

3. 成本优化策略

   • 智能Token管理：压缩上下文，提取重要消息，保留最近的和最重要的
   • 批量处理

4. 可靠性增强

   • 重试机制
   • 健康检查

5. 调试与监控

   • 调试技巧：记录每一步，钩子记录每次工具调用

Agent的发展趋势

• 更强的推理能力

  • 以处理更复杂的任务
  • 减少对外部工具的依赖
  • 更少的错误和幻觉

• 多模态Agent

  • 图像理解（识别图表、设计UI）
  • 视频分析（剪辑、内容审核）
  • 语音交互（实时对话）
  • 3D环境操作（游戏、仿真）

• 个性化和记忆增强

  • 跨会话的长期记忆
  • 个性化学习（理解用户习惯）
  • 主动建议（不等用户询问）

AI Agent框架

都有哪些主流的AI Agent框架？

• LangChain: 全能型框架，管道式编排与丰富生态
• Qwen-Agent: 轻量级全能选手，工具调用与代码解释器
• LlamaIndex: 数据驱动的 RAG 专家
• AutoGen: 多智能体协作的，微软开源

Q: 编写一个AI Agent框架，需要解决哪些核心问题？

1. LLM适配层（大脑）
2. 工具注册与调度（双手）
3. Context管理（记忆）
4. 控制流编排（中枢）

LLM适配层

大脑的适配层：LLM 统一接口与 Prompt 管理

Model Adapter (适配器模式)：抹平不同模型 (OpenAI, DeepSeek, Qwen) 的 API 差异

框架层做了一个中间层，把统一的指令（如 invoke("你好")）翻译成特定模型的 API 调用。

LLM 统一接口的作用：

• 统一调用方式
• 统一了参数配置（如 temperature）
• 输出格式（统一转为 Message 对象）

Prompt Engineering 工程化：

1. System Message 的动态注入，将人设与上下文解耦
2. 人设 (角色定义) 与任务流程 (上下文指令) 分离，便于复用和维护。

工具注册与调度

双手的标准化：工具注册与调度 (Tool Registry)

各框架提供了不同的工具注册方式：

模式	框架	特点
@tool 装饰器	LangChain	最简洁，docstring 自动解析
@register_tool + 类	Qwen-Agent	显式参数定义，结构清晰
FunctionTool 封装	LlamaIndex	强类型约束，适合复杂工具

Q: LLM 是如何看见工具的？

框架会将 Python 函数的 name、docstring (功能描述) 和 type hints (参数类型) 转换成 JSON Schema 喂给 LLM 。

• LangChain: 也就是 @tool，主要是在使用 Python 原生特性，最符合直觉 。
• Qwen-Agent: @register_tool，使用显式定义，强约束，适合复杂参数 。

Context 管理机制

记忆的存储：Context 管理机制

记忆系统的架构是怎样的？

1. 短期记忆 (Window)
   • 对话历史截断
   • 滑动窗口策略
   • 避免 Token 爆炸
2. 长期记忆 (RAG)
   • VectorStoreIndex 向量索引
   • 文档分块与 Embedding
   • 相似度检索

框架	短期记忆	长期记忆
LangChain	RunnableWithMessageHistory + session_id	需集成 VectorStore
Qwen-Agent	messages 列表手动管理	files 参数加载文档
LlamaIndex	Agent chat() 内置	专业级 VectorStoreIndex

Q: 为什么需要进行Context管理？

LLM 是无状态的，它记不住你说过什么，且 Context Window（上下文窗口）是昂贵的资源。有限注意力的管理。

短期记忆：

• Session ID 很重要，它是多用户并发的基础 。
• 滑动窗口策略——只保留最近 N 轮，防止 Token 爆炸。

长期记忆：

• 这是 RAG 的范畴，利用向量数据库进行相关性检索，而非时间顺序回忆 。

控制流设计 (Orchestration)

中枢的编排：控制流设计 (Orchestration)

复杂的任务不能靠 LLM 一口气说完，需要拆解步骤。

模式	说明	适用场景
管道模式 (Pipeline)	LangChain 的 prompt|llm|parser 链式调用	线性处理流程
单人模式 (Loop)	经典 ReAct 循环：思考 -> 行动 -> 观察	单 Agent 完成任务
多人模式 (DAG)	接力赛：明确的执行顺序	流程化任务 (如投资决策)
多人模式 (Chat)	圆桌会议：自由讨论	开放式协作

LangChain LCEL (LangChain Expression Language) 特点：

• |管道符：直观的链式调用，类似 Unix 管道
• invoke()：统一的调用接口
• 支持流式输出、批处理、异步调用

LangChain管道模式：Prompt => LLM => Parser

ReAct 循环 (Agent模式): Thought思考 => Action行动 => Observation 观察 => Thought思考

控制流的编排：

• Chain (链式)：由于输入确定，输出确定，像工厂流水线（Pipeline）。
• Loop (循环)：即 ReAct 模式（思考-行动-观察-思考），像一个不断试错的实验员，直到任务完成 。
• DAG (有向无环图)：像多人接力赛，有明确的前后依赖关系。

LangChain

LangChain学习笔记

LlamaIndex

Q: LlamaIndex的定位是怎样的？

为 LLM 装上私有数据的最强接口；如果不涉及复杂的多人协作，只是想基于文档问答，它是首选。

LlamaIndex (opens new window)

Index-First 哲学：不同于 LangChain 关注流程，LlamaIndex 关注数据结构。它认为 LLM 应用的核心瓶颈在于如何让 LLM 索引私有数据。

LlamaIndex 的核心优势：

• 一站式文档处理：加载、分块、向量化、索引、检索
• 索引持久化：避免重复创建，快速启动
• 多种检索策略：向量检索、关键词检索、混合检索
• 与 Agent 无缝集成：FunctionTool 封装查询引擎

场景	说明
企业知识库	内部文档、FAQ、操作手册的智能问答
合同审查助手	基于合同文档的条款检索与解读
学术论文分析	论文摘要、引用关系、知识图谱构建
客服机器人	产品手册、服务政策的实时检索回答

Qwen-Agent

Qwen-Agent的定位是怎样的？

阿里开源的agent框架，对 Tool Use 和 Code Interpreter 支持好；轻量、灵活，适合快速构建工具调用型 Agent。

Qwen-Agent (opens new window)

• 指令跟随优化：Qwen-Agent 是专门为 Qwen 模型（及其强大的 Tool Calling 能力）定制的。它不如 LangChain 抽象，但跑得快。
• Code Interpreter (沙箱)：这是它的杀手锏。不同于其他框架只调用外部 API，Qwen-Agent 内置了代码执行沙箱，允许LLM 自己写 Python 代码来画图、做数据分析，自我修正错误 。

Q: Qwen-Agent适合什么场景？

想要快速搭建工具调用型或数据分析型Agent，且不想处理复杂抽象层的开发者。 利用 Qwen-Agent的长文本优势是强项 。

装饰器模式优势：

• @register_tool('name') 一行代码完成注册
• description 自动生成工具描述供 LLM 理解
• parameters 定义参数约束，LLM 自动解析

Qwen-Agent 内置 code_interpreter 工具，可以在沙箱环境中执行 Python 代码

# 创建 Assistant，传入文件列表
bot = Assistant(
    llm=llm_cfg,   # 大模型 => 对应的coze中的模型
    system_message=system_instruction, #系统提示词  => coze中的 人设与回复逻辑
    function_list=tools, #工具列表 =》 对一个 coze中的插件市场（code interpreter + 自定义插件）
    files=files  # 文档文件列表  =》 对应coze中的 知识库（文本）
)
 
bot.run()
query 代表用户的问题
Step1，先从  files里面找到相关的知识  chunks
Step2，system prompt + chunks + tools说明 => LLM进行推理

场景	说明
数据分析	需要运行代码、绑图、生成报表
复杂工具调用链	多个工具协同完成任务
图像处理	生成、编辑、分析图像
文档问答	结合 Qwen 模型的长 Context 优势

AutoGen

AutoGen 是微软开源的多智能体对话框架，用于构建多个 AI Agent 协作完成复杂任务。

它的核心理念是让 Agent 之间通过自然语言对话来协作，而非硬编码的函数调用。

AutoGen (opens new window)

2025 年 10 月起，微软将 AutoGen 置为维护模式——仅修漏洞，不再新增功能；所有新特性都做到 Agent Framework (opens new window) 上。官方文档明确把 Agent Framework 称为下一代 Semantic Kernel 与 AutoGen，鼓励新项目直接迁移

Agent框架对比

维度	LangChain	Qwen-Agent	LlamaIndex	AutoGen
核心定位	全能型框架	轻量工具调用	RAG 数据接口	多Agent协作
工具注册	@tool 装饰器	@register_tool 装饰器	FunctionTool 类	@register 装饰器
RAG 支持	需集成 VectorStore	基础文件读取	专业级向量索引	需自行集成
多Agent	LangGraph 支持	基础支持	需自行编排	原生 GroupChat
代码执行	需集成	内置 code_interpreter	需集成	UserProxyAgent
记忆管理	RunnableWithMessageHistory	messages 列表	Agent chat()	GroupChat 自动
学习曲线	中等	简单	中等	中等
生态完整度	最丰富	阿里生态	RAG 社区	微软生态

Q: 从业务场景的角度，如何选择适合的Agent框架？

• 选 LangChain：如果你要开发通用的 AI 应用，需要灵活控制流程，或者需要切换多种模型。
• 选 LlamaIndex：如果你主要做 RAG（企业知识库），手里有一堆 PDF/Word/Excel 要处理。
• 选 Qwen-Agent：如果你主要用 Qwen 模型，需要做数据分析（Code Interpreter）或处理超长文档（1M Context）。
• 选 AutoGen：如果任务太复杂，一个人（Agent）干不完，需要团队（多角色）吵架/协作才能出结果。

问题记录

智能客服Agent如何设计多轮对话流程？

怎么让模型多聊几轮 => 把一个高不确定性的交互入口，收敛成一个可控、可观测、可回滚的工程系统。

核心是把聊天当成可控的流程而不是闲聊：先划清自动化/人工的边界，按风险分层设计主线；每一轮都带着明确意图——要么收集关键信息、要么调工具校验事实、要么做确认或转人工；用结构化槽位/状态机追踪进度，工具结果为准，记忆只做提示；遇到模糊诉求先收窄范围再给可执行选项，避免一直聊散。这样整条链路可观测、可回滚、失败就早转人工。

如果从零手写一个 AI Agent 框架，底层需要解决哪几个核心架构问题？

• 大脑适配层 (LLM Adapter)：抹平各类大模型（如 OpenAI、通义千问、DeepSeek）的 API 调用规则与 Prompt 格式差异，为上层提供统一标准接口。
• 双手扩展层 (Tool Registry)：实现外部工具的注册与调度。将本地的 Python 函数转化为 LLM 能理解的 Schema，并在模型决定调用时，精准解析参数并执行对应代码逻辑。
• 记忆管理层 (Context Management)：解决 LLM 的无状态痛点与 Token 窗口上限问题。需设计机制管理长短 记忆，比如会话滑动窗口截断、历史记录摘要或向量化存储。
• 中枢编排层 (Control Flow)：负责整个运行生命周期的调度。能够构建线性的处理流水线（Pipeline），或支 持复杂逻辑跳转、错误重试的循环控制（Loop/DAG）。

Q: Tool Registry的作用是什么？

Tool Registry 通常需要把函数的 docstring、参数类型（如 target: str）转成 JSON Schema => 给 LLM 提供 Function Calling；比如：def get_weather(city: str) -> str 会生成 {"name":"get_weather","description":"...","parameters":{"city":{"type":"string"}}}

Q: LLM收到这个JSON之后，做什么处理？

当 LLM 返回要调用 get_weather("北京") 时，框架需要自动拦截这个响应，去 Registry 里拿到真实的 Python 函数并执行；执行完成将结果（如 25度）再次包装成 Tool Message 塞回给大模型让它生成最终的回复。

Q: 上下文管理中进行摘要的作用是什么？

使用 LLM 把长对话进行压缩，比如 10 轮对话压成：用户问天气，助手推荐北京，用户说明天去 => 节省 Token

Q：向量化存储的作用是什么？

向量化存储把历史片段嵌入向量库，跨会话问：上次说的北京天气如何 时 => 可以检索到相关记忆。

Q: 短期记忆和长期记忆的区别是什么？

• 短期记忆可以使用 滑动窗口（比如只保留最近 10 轮对话）或按 Token 长度动态截断，防止爆显存
• 长期记忆可以把历史对话转成 Embedding 存入向量数据库，等用户聊到相关话题时再 RAG 召回。

Q：为什么说Agent 和普通大模型调用的核心区别在于逻辑编排？

Agent会实现经典的 ReAct (Reason + Act) 范式：思考 -> 决定调用工具 -> 执行工具 -> 观察结果 -> 继续思考...，直到得出最终结论才跳出循环（Break）。

自己手写框架时，往往需要设计一个追踪（Tracing）机制，记录每一次 Prompt 拼接了什么、消耗了多少 Token、Tool 执行耗时多久，对于排查 Agent 的幻觉和死循环至关重要。

在 LangChain 等框架中，Agent 底层依赖的 ReAct 范式，其核心运行逻辑和状态机流转是怎样的？

ReAct (Reason + Act) 是一种交替进行推理和行动的机制。模型接收到用户输入后，会进入一个状态机循环：

• Thought（思考）：大模型首先分析当前现状，推理出解决问题的第一步需要做什么。
• Action（动作）：根据思考结果，从已注册的工具箱中挑选一个最匹配的外部工具。
• Action Input（传参）：提取上下文信息，按要求组装参数并喂给选定的工具。
• Observation（观察）：框架执行工具代码，并将真实返回的数据（有效结果或运行报错）带回给模型。

拿到 Observation 后，模型会再次进入 Thought 环节评估进度。这个闭环会不断重试和运转，直到模型判定已收集到充足信息，最终输出 Final Answer 结束流转。

Q: ReAct会进入到死循环么？如何避免死循环？

死循环常见于模型反复调用同一工具 => 无法给出 Final Answer。工程上可设置最大步数（如 10 步）强制终止，或对 连续 3 次相同 Action 做惩罚。工具报错时，Observation 应原样返回异常信息（如 ConnectionTimeout: 请求超时），让模型有机会换策略（比如重试，或者说明「服务暂时不可用」）。

如何根据项目场景在不同Agent框架中做技术选型？

• LangChain（全能型管家）：生态最庞大，适合通用且业务流编排复杂的AI应用。若项目需要灵活编排工作流、频繁切换大模型或对接各类第三方API，它是首选。
• LlamaIndex（数据驱动专家）：企业级 RAG 的主力。当业务核心是解析海量私有文档（如长篇研报、企业知识库）并进行精准问答时，其底层的索引、检索与切分优化优于 LangChain。
• Qwen-Agent（轻量级全能选手）：若业务涉及复杂数据分析（需要运行Python代码解释器）或超长文档处理，且倾向于国内开源生态，开箱即用体验好。
• AutoGen（多智能体协作）：适合单一 Agent 无法搞定的长链路任务。比如需要构建“数据员+分析师+风控官”多角色辩论与协作的复杂业务场景。但不太可控，因为它依赖 LLM 来协调多 Agent 之间的沟通。

LanChain做编排，LlamaIndex做索引。

LangChain 流程优先，关注如何编排复杂的逻辑流（Chain/Agent）。LlamaIndex 索引优先，关注数据结构与检索性能，是私有数据的最强接口 。

Q: 如何看待 AutoGen 等多智能体框架？它与单 Agent 框架的核心区别是什么？

• 核心区别：单 Agent 是一个人完成任务（Loop 模式）；多 Agent 是多角色协作（Round-robin/GroupChat 模式）。
• 优势场景：适合长链路任务，如“数据员+分析师+风控官”通过辩论和接力完成决策。
• 实现细节： AutoGen 支持原生群聊模式，Agent 之间可以自动对话，甚至支持代码执行的闭环（UserProxyAgent）

备注

Agent的一些经验

1. 做Agent的第一步不是写代码，是设计”思考过程”；
2. 工具的粒度要恰当，别拆太细，每个工具用一句话能说清楚它干什么，就是合适的粒度；
3. 工具的描述比工具的实现更重要：输入格式、输出字段、限制条件、明确的错误返回（Agent需要根据错误信息决定下一步怎么办）；
4. System Prompt里要明确定义”做事的流程”，如：

你是一个数据分析Agent。收到任务后：
1. 先分析任务需要哪些数据
2. 使用工具获取数据
3. 如果数据不完整，明确指出缺什么，
   尝试用其他方式获取
4. 拿到足够数据后，进行分析
5. 输出结论时，必须引用具体数据支撑
6. 如果无法完成任务，明确说明原因，不要编造结果

第6条比较重要，Agent默认不喜欢说”我不行”。它宁愿编一个看起来合理的结果，也不愿意承认自己搞不定。必须在prompt里给它”说不”的权限和指引。

5. Few-shot examples要给”完整的思考链”。 不只是给输入和输出，要给中间的推理过程——”我看到了什么→我决定做什么→我为什么这么决定→结果是什么→基于结果我下一步做什么”。
6. 记忆和上下文管理：摘要压缩、分层记忆：

短期记忆：当前对话上下文（最近几步的完整信息）
工作记忆：当前任务的关键状态（结构化数据）
长期记忆：向量数据库存储的历史经验

7. 建测试用例集，不用很大，二三十个覆盖不同场景的case就行。每个case包括：输入、期望的最终输出、以及你认为合理的中间步骤。每次改了prompt或者工具之后，跑一遍这个测试集。不用自动化评估（Agent的输出太灵活了，自动化评估很难做准），人工看就行。记录通过率和典型的失败模式;失败的case要仔细分析：它为什么失败了？是工具用错了？是推理链断了？是幻觉了？还是上下文丢了关键信息？

不同的失败原因对应不同的修复策略：工具用错了→改工具描述或拆分工具、推理链断了→改system prompt或加few-shot、幻觉→加事实校验步骤、上下文丢信息→改记忆管理策略；这个诊断过程比盲目调prompt有效得多。

8. 给Agent设置步数上限，没有上限的Agent可能会陷入无限循环，超过就强制停止，输出当前状态让人介入。
9. 日志要详细；人类兜底机制（在关键决策点加上人工确认的选项）；
10. 先让它在小数据上跑通，别一上来就喂真实的全量数据；用两三条模拟数据把整个流程走通，确认没有逻辑问题，再放量。
11. 成本意识： Agent是真的烧钱，每一步都是一次LLM调用，复杂任务可能跑十几二十步，每步的上下文还越来越长；调试阶段用便宜的小模型，效果验证用好模型。
12. 多Agent协作：理论上，多个Agent分工合作可以处理更复杂的任务。实际上，Agent之间的”沟通成本”极高——一个Agent的输出要成为另一个Agent的输入，中间的格式转换、信息损失、理解偏差，每一环都可能出问题。
13. 长任务的可靠性：Agent跑五步以内通常很稳，跑十步以上就会出现幻觉、遗忘、重复、偏离目标。怎么让Agent在长任务中保持稳定？也许这不是工程能解决的问题，需要模型本身的能力继续提升。也许等上下文窗口到了百万级别、推理能力再上一个台阶，这些问题就自然消解了。

Research Agent

Deep Agent

参考

• 大模型Agent知识从0-1笔记-万字详解版本！ (opens new window)

• 如何设计一个AI Agent系统 (opens new window)