AI Agent 完整运行流程
如果从用户发起请求 → Agent 思考 → 调用工具 → 获取结果 → 再次思考 → 最终返回整个过程来看，可以理解成下面这条链路：
👤 用户
│
│ ① 提出任务
▼
┌─────────────────┐
│ ② Agent 接收请求 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ ③ 意图识别 │
│ 用户想完成什么？ │
└────────┬────────┘
│
▼
┌─────────────────┐
│ ④ 获取上下文 │
│ Memory + RAG │
└────────┬────────┘
│
▼
┌─────────────────┐
│ ⑤ LLM 推理 │
│ 分析问题/制定计划 │
└────────┬────────┘
│
▼
┌─────────────────┐
│ ⑥ 判断是否需要 │
│ 调用工具？ │
└───────┬─┬────────┘
否 │ │ 是
│ │
┌───────────┘ └─────────────┐
▼ ▼
┌──────────────┐ ┌────────────────┐
│ ⑦ 直接生成答案 │ │ ⑦ 调用 Tool │
└──────┬───────┘ │ MySQL/HTTP/API │
│ └───────┬────────┘
│ │
│ ▼
│ ┌────────────────┐
│ │ ⑧ 获取执行结果 │
│ └───────┬────────┘
│ │
│ ▼
│ ┌────────────────┐
│ │ ⑨ LLM 再次推理 │
│ │ 分析执行结果 │
│ └───────┬────────┘
│ │
│ 是否完成？
│ ↙ ↘
│ 否 是
│ │ │
│ └──→继续调用Tool│
│ │
└──────────────────────┬──────────┘
▼
┌─────────────────┐
│ ⑩ 生成最终答案 │
└────────┬────────┘
│
▼
👤 用户
一、第一步：用户提出目标
例如：
“帮我分析 MySQL 为什么卡顿。”
这时候用户给 Agent 的不是一个具体 SQL，而是一个目标。
用户目标
↓
分析 MySQL 卡顿原因
二、第二步：Agent 理解用户意图
Agent 首先判断：
这是一个什么问题？
需要什么能力？
是否需要查询外部数据？
例如：
用户：
帮我分析 MySQL 为什么卡顿
Agent：
→ 运维问题
→ 涉及 MySQL
→ 需要实时数据
→ 需要调用 MySQL Tool
这里主要依赖 LLM。
三、第三步：获取 Memory
Agent 会获取当前会话的上下文。
例如之前用户说过：
MySQL 版本：8.0
服务器：Ubuntu
数据库：xxx
Memory：
当前用户
↓
历史对话
↓
任务上下文
这样 Agent 不需要每次重新询问。
四、第四步：RAG 查询知识
如果需要企业内部知识，Agent 可以查询 RAG。
例如：
用户：
按照公司 MySQL 运维规范分析这个问题
Agent：
问题
↓
Embedding
↓
Milvus
↓
查询 MySQL 运维规范
↓
返回相关文档
↓
LLM
这时候 Agent 同时拥有：
Memory = 当前上下文
RAG = 企业知识
LLM = 推理能力
五、第五步：LLM 制定计划
Agent 开始规划：
目标：
分析 MySQL 卡顿
计划：
① 查看当前连接
② 查看运行中的 SQL
③ 查看锁等待
④ 查看慢 SQL
⑤ 查看执行计划
⑥ 综合分析
这就是 Planning。
六、第六步：决定是否调用 Tool
LLM 判断：
“这个问题需要实时查询 MySQL，所以我要调用 MySQL Tool。”
例如：
MySQLTool
↓
SHOW PROCESSLIST
Agent 不需要知道具体 SQL 怎么执行，它只需要知道：
我有一个工具：
query_mysql()
然后调用。
七、第七步：Tool 执行
MySQL Tool 真正执行：
SHOW PROCESSLIST;
然后返回：
Query 1
Query 2
Query 3
...
注意：
真正连接数据库、执行 SQL 的不是 LLM，而是 Tool。
LLM 负责：
“我要查什么”
Tool 负责：
“真正执行”
八、第八步：Agent 获取执行结果
例如 Tool 返回：
发现：
UPDATE person_issue_record
正在等待锁
等待时间：35 秒
Agent 得到这个结果。
九、第九步：Agent 再次推理
这一步非常重要。
Agent 不会看到结果后就结束。
它会继续判断：
发现锁等待
↓
为什么被锁？
↓
需要查阻塞事务
于是再次调用 Tool：
LockTool
↓
查询锁等待
得到：
事务 A
↓
持有锁
事务 B
↓
等待事务 A
Agent 再次分析。
十、第十步：循环执行
这就是 Agent 和普通 AI 最大的区别。
它可能不断循环：
┌──────────────┐
│ LLM │
│ 思考 │
└──────┬───────┘
↓
制定下一步
↓
┌──────────────┐
│ Tool │
│ 执行动作 │
└──────┬───────┘
↓
返回结果
↓
┌──────────────┐
│ LLM │
│ 分析结果 │
└──────┬───────┘
↓
任务完成？
↙ ↘
否 是
↓ ↓
继续执行 最终答案
│
└──────────→ LLM
这就是经典的：
Think → Act → Observe → Think → Act → Observe
十一、第十一步：任务完成
Agent 最终判断：
已经找到问题
例如：
MySQL 卡顿主要原因：
1. UPDATE person_issue_record 存在锁等待
2. 事务 A 长时间未提交
3. 导致事务 B 等待
4. 同时产生大量连接堆积
然后生成用户能够理解的最终答案。
十二、完整实例
把整个流程串起来：
👤 用户
│
│ “帮我分析 MySQL 卡顿”
│
▼
🤖 Agent
│
├─① 理解意图
│ ↓
│ MySQL 运维分析
│
├─② 获取 Memory
│ ↓
│ 获取历史上下文
│
├─③ 查询 RAG
│ ↓
│ 获取企业 MySQL 运维规范
│
├─④ LLM 制定计划
│ ↓
│ 查连接 → 查锁 → 查慢SQL → EXPLAIN
│
├─⑤ 调用 MySQL Tool
│ ↓
│ SHOW PROCESSLIST
│
├─⑥ 获得结果
│ ↓
│ 发现 System lock
│
├─⑦ LLM 再次分析
│ ↓
│ “需要进一步查询锁”
│
├─⑧ 调用 Lock Tool
│ ↓
│ 找到阻塞事务
│
├─⑨ 再次分析
│ ↓
│ “需要检查阻塞 SQL”
│
├─⑩ 调用 SQL Tool
│ ↓
│ EXPLAIN
│
├─⑪ 综合分析
│ ↓
│ 找到根因
│
└─⑫ 返回最终结果
↓
👤 用户
最核心的一张图
如果你要放到技术方案/PPT里，我建议最终使用这一版：
用户
│
▼
┌───────────┐
│ Agent │
└─────┬─────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Memory RAG LLM
│ │ │
│ │ 理解 + 推理
│ │ │
└────────────┼────────────┘
▼
Planning
│
▼
┌───────────┐
│ Tool调用 │
└─────┬─────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
MySQL Redis HTTP
│ │ │
└────────────┼────────────┘
▼
执行结果
│
▼
LLM再次分析
│
┌─────┴─────┐
│ │
未完成 完成
│ │
└──→Tool ▼
最终答案
│
▼
用户
一句话概括运行机制：
用户给目标 → Agent 理解 → Memory/RAG 补充上下文 → LLM 思考和规划 → 调用 Tool 执行 → 获取结果 → LLM 再次分析 → 不满足条件就继续执行 → 满足条件后返回最终结果。
扫一扫
859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
