本章关键词： AI Agent、Tool Calling、Function Calling、Tools、Planning、Memory、Workflow、RAG、ERP、CRM、WMS、API、权限、安全

---

一、RAG之后，为什么还需要Agent？

上一篇我们完成了一个企业RAG知识库：

它可以解决一个非常重要的问题：

让AI能够理解企业知识。

例如用户问：

WMS系统中，库存盘点出现差异应该怎么处理？

RAG可以检索：

《库存盘点管理制度》
《盘点异常处理SOP》
《库存调整管理规范》

然后让LLM生成答案。

但是，企业员工接下来很可能会问：

“帮我查询一下SKU-10086现在有多少库存。”

这时候RAG就不够了。

因为：

知识库中的库存数据可能不是实时数据。

真正需要的是：

用户
 ↓
AI Agent
 ↓
调用WMS API
 ↓
查询实时库存
 ↓
返回结果

进一步，用户可能说：

“帮我把SKU-10086的库存调整100件。”

这就不再是：

回答问题。

而是：

执行任务。

这正是Agent解决的问题。

---

二、什么是AI Agent？

AI Agent可以简单理解为：

能够理解目标、决定下一步行动、调用工具、观察结果，并持续执行直到完成任务的AI系统。

普通Chatbot：

用户
 ↓
LLM
 ↓
答案

RAG Chatbot：

用户
 ↓
LLM
 ↓
RAG
 ↓
企业知识
 ↓
答案

AI Agent：

所以可以简单理解：

LLM = 大脑

RAG = 知识

Tool = 手

Agent = 能够使用大脑、知识和工具完成任务的执行者

---

三、Chatbot、RAG和Agent有什么区别？

这是FDE必须理解的一个核心问题。

类型	核心能力	能否访问企业知识	能否调用系统	能否执行任务
Chatbot	对话	❌	❌	❌
RAG	知识问答	✅	通常❌	❌
Tool Calling	工具调用	可选	✅	部分
Agent	自主执行	✅	✅	✅
Workflow	流程执行	可选	✅	✅

可以把它理解成一个逐步升级过程：

Chatbot
   ↓
RAG
   ↓
Tool Calling
   ↓
Agent
   ↓
Workflow
   ↓
企业AI应用

---

四、Agent最重要的能力：Tool Calling

Agent之所以能够执行任务，关键原因之一就是：

Tool Calling。

例如我们给AI提供一个工具：

get_inventory(sku)

工具说明：

名称：
get_inventory

功能：
查询SKU实时库存

参数：
sku

返回：
库存数量

用户：

查询SKU-10086的库存。

LLM判断：

这个问题需要实时库存数据
 ↓
调用get_inventory

生成：

{
  "tool": "get_inventory",
  "arguments": {
    "sku": "SKU-10086"
  }
}

系统执行：

get_inventory("SKU-10086")

WMS返回：

{
  "sku": "SKU-10086",
  "available": 1250,
  "locked": 100
}

然后结果重新交给LLM：

Tool Result
 ↓
LLM
 ↓
自然语言答案

最终：

SKU-10086当前库存：

可用库存：1250件
锁定库存：100件

这就是Tool Calling。

---

五、Function Calling和Tool Calling是什么关系？

在不同AI平台和框架中，经常会看到：

Function Calling
Tool Calling

两者在实际应用中高度相关。

核心思想都是：

让模型输出结构化的工具调用请求，由程序真正执行工具。

例如：

LLM
 ↓
决定调用工具
 ↓
输出结构化参数
 ↓
Application
 ↓
执行函数/API
 ↓
返回结果
 ↓
LLM

需要注意一个关键点：

LLM本身通常并不是直接操作企业数据库。

而是：

LLM
 ↓
提出工具调用
 ↓
应用程序
 ↓
权限校验
 ↓
真正执行API

这对于企业安全非常重要。

---

六、Tool到底是什么？

Tool本质上就是：

AI可以调用的一个能力接口。

例如WMS：

查询库存
查询订单
查询库位
查询SKU
创建入库单
创建出库单
创建盘点任务

ERP：

查询采购订单
查询销售订单
查询供应商
查询物料
创建采购申请

CRM：

查询客户
查询联系人
查询商机
创建跟进记录
查询销售机会

甚至可以是：

天气API
地图API
邮件
Excel
数据库
搜索引擎
企业内部API

因此：

Tool
=
AI可以调用的外部能力

---

七、Tool设计是Agent项目的核心工作

很多人做Agent时，把注意力全部放在LLM上。

实际上企业Agent能否稳定运行，很大程度上取决于：

Tool设计。

一个好的Tool应该：

职责单一
参数清晰
返回结构化
权限明确
错误可控
可审计
可重试

例如不要设计：

do_wms_everything()

而应该拆成：

get_inventory()
get_order()
get_location()
create_count_task()
create_outbound_order()

这样Agent更容易正确选择。

---

八、一个标准Tool定义

例如：

{
    "name": "get_inventory",
    "description": "查询指定SKU在指定仓库中的实时库存",
    "parameters": {
        "type": "object",
        "properties": {
            "warehouse_code": {
                "type": "string"
            },
            "sku": {
                "type": "string"
            }
        },
        "required": [
            "warehouse_code",
            "sku"
        ]
    }
}

这里包含三个重要部分：

Tool Name
Tool Description
Tool Parameters

尤其是：

Description非常重要。

因为Agent需要根据工具描述判断：

“什么时候应该使用这个工具？”

---

九、Agent的基本运行循环

一个简单Agent可以抽象成：

这就是Agent的基本循环。

---

十、Think → Act → Observe

很多Agent架构可以抽象成：

例如：

用户：

“帮我找出库存低于安全库存的SKU，并创建补货申请。”

Agent可能需要：

这就是Agent与普通Chatbot最大的区别。

---

十一、Agent + RAG

Agent并不意味着RAG消失了。

恰恰相反：

Agent + RAG是企业AI非常重要的组合。

例如：

例如：

用户：

“按照公司的库存管理制度，
帮我检查一下SKU-10086是否需要补货。”

Agent需要：

第一步

通过RAG查询：

库存管理制度
安全库存规则
补货规则

第二步

通过Tool查询：

SKU-10086实时库存

第三步

综合判断：

当前库存
+
安全库存规则
+
补货策略

第四步

返回：

SKU-10086当前库存低于安全库存，
建议创建补货申请。

这就是真正的：

知识 + 数据 + 推理。

---

十二、Agent + WMS

对于FDE来说，WMS是非常适合Agent落地的场景。

可以设计：

Tools可以包括：

查询库存
查询订单
查询库位
查询SKU
查询批次
查询库存状态
创建盘点任务
创建补货任务

---

十三、一个完整的WMS Agent案例

用户：

“帮我检查一下A仓库库存不足的商品。”

Agent：

① 查询A仓库库存
        ↓
② 查询安全库存规则
        ↓
③ 计算库存差异
        ↓
④ 找出低于安全库存SKU
        ↓
⑤ 生成结果

例如：

SKU       当前库存    安全库存
--------------------------------
SKU001      80         100
SKU002      30          50
SKU003     500         100

Agent判断：

SKU001 → 需要补货
SKU002 → 需要补货
SKU003 → 正常

然后用户继续：

“那就帮我创建补货任务。”

Agent：

用户确认
 ↓
权限检查
 ↓
创建补货任务Tool
 ↓
WMS API
 ↓
返回任务号
 ↓
AI反馈

最终：

已创建2个补货任务：

SKU001 → 补货任务 RT20260905001
SKU002 → 补货任务 RT20260905002

这已经不是简单的AI问答。

而是：

AI参与真实业务流程。

---

十四、Agent + ERP

ERP同样可以提供大量Tools。

例如：

采购订单查询
销售订单查询
供应商查询
物料查询
库存查询
财务数据查询
采购申请创建

例如用户：

“帮我查询最近30天采购金额最高的10家供应商。”

Agent可以：

理解问题
 ↓
确定时间范围
 ↓
调用采购数据Tool
 ↓
获得数据
 ↓
排序
 ↓
生成报告

如果进一步连接RAG：

采购制度
+
实时采购数据
+
Agent

就可以回答：

“为什么这个供应商不能直接下采购订单？”

---

十五、Agent + CRM

CRM场景同样非常适合Agent。

例如：

客户查询
 ↓
商机查询
 ↓
客户历史跟进
 ↓
合同查询
 ↓
生成客户分析

用户：

“帮我整理一下这个客户最近的销售情况。”

Agent：

查询客户
 ↓
查询商机
 ↓
查询订单
 ↓
查询跟进记录
 ↓
汇总
 ↓
生成客户画像

进一步：

“帮我给这个客户创建一次跟进任务。”

Agent可以：

调用CRM API
 ↓
创建跟进任务
 ↓
返回任务结果

---

十六、Agent不是“无限自由”的AI

企业环境下不能让Agent想干什么就干什么。

例如：

查询库存

可以自动执行。

但是：

删除订单
修改财务数据
创建付款
删除客户
调整库存

可能必须：

人工确认

因此企业Agent应该设计：

低风险操作
 ↓
自动执行

中风险操作
 ↓
权限检查

高风险操作
 ↓
人工确认
 ↓
执行

---

十七、Human-in-the-Loop

这就是：

人在回路中。

例如：

用户：

“帮我把SKU-10086库存增加1000件。”

Agent不能直接执行。

应该：

Agent
 ↓
生成操作计划
 ↓
发现这是高风险操作
 ↓
要求用户确认

提示：

即将执行：

仓库：WH01
SKU：SKU-10086
库存调整：+1000

该操作会修改实际库存。

是否确认执行？

用户：

确认

然后：

权限校验
 ↓
调用API
 ↓
执行
 ↓
记录审计日志

这才是企业级Agent。

---

十八、Agent权限设计

Agent的权限不能等同于系统管理员权限。

应该采用：

用户权限
    ↓
Agent权限
    ↓
Tool权限
    ↓
业务数据权限

例如：

仓库操作员

可以：
✓ 查询库存
✓ 查询库位
✓ 查询订单

不能：
✗ 删除库存
✗ 修改财务数据
✗ 修改系统配置

因此Agent调用Tool之前：

---

十九、Agent Memory：记忆

Agent还需要处理上下文。

例如用户：

“查询一下A仓库。”

Agent：

好的。

用户：

“再看看库存不足的。”

这里的：

“再看看”

依赖前面的上下文。

因此Agent需要保存：

Conversation History
Task State
User Preference
Execution State

可以简单理解为：

Memory
 ↓
让Agent知道
“刚才发生了什么”

---

二十、Agent State：状态

企业任务往往不是一次完成。

例如：

创建采购申请

可能经历：

DRAFT
 ↓
SUBMITTED
 ↓
APPROVED
 ↓
PROCESSING
 ↓
COMPLETED

Agent需要知道当前任务处于什么状态。

因此可以设计：

Agent State

task_id
user_id
current_step
tool_result
approval_status
error
retry_count

这样才能支持复杂任务。

---

二十一、Agent错误处理

真实环境中Tool不可能永远成功。

例如：

WMS API超时
数据库连接失败
权限不足
SKU不存在
库存不足
参数错误

Agent需要处理这些情况。

例如：

例如：

API Timeout
 ↓
Retry
 ↓
成功

如果：

Permission Denied

则不能无限重试。

应该：

停止
 ↓
提示用户权限不足

---

二十二、Agent为什么容易“失控”？

Agent比普通Chatbot复杂很多。

因为它可以：

思考
+
调用工具
+
执行动作
+
继续调用工具

如果设计不好，就可能出现：

无限循环
错误调用
重复执行
错误参数
权限越权
数据污染
成本失控

因此：

Agent必须有边界。

---

二十三、Agent Guardrails

企业Agent应该增加Guardrails。

例如：

还应该限制：

最大执行步数
最大Token
最大调用次数
Tool白名单
API权限
金额限制
数据范围

---

二十四、Agent + Workflow

很多人会问：

Agent和Workflow是不是一样？

不是。

Workflow：

流程预先定义
 ↓
Step 1
 ↓
Step 2
 ↓
Step 3
 ↓
Step 4

Agent：

目标
 ↓
AI自主判断下一步
 ↓
选择Tool
 ↓
执行
 ↓
根据结果继续判断

简单来说：

Workflow = 路线提前规划好

Agent = 根据现场情况动态决定路线

---

二十五、什么时候用Workflow？

如果业务流程非常固定：

订单创建
 ↓
订单审核
 ↓
库存检查
 ↓
出库
 ↓
发货

就适合Workflow。

如果问题变化很大：

“帮我分析一下这个客户为什么最近订单下降。”

可能需要Agent动态决定：

查询客户
 ↓
查询订单
 ↓
查询销售趋势
 ↓
查询历史记录
 ↓
分析原因

因此实际企业应用往往是：

Agent
 +
Workflow

---

二十六、企业级Agent整体架构

可以把完整架构设计成：

在外层再增加：

Authentication
Authorization
Guardrails
Evaluation
Audit Log
Monitoring

形成企业级架构。

---

二十七、FDE如何做一个最小Agent？

建议不要一上来做：

超级企业AI Agent

而应该先做：

一个Agent + 三个Tools。

例如WMS：

Tool 1
get_inventory()

Tool 2
get_order()

Tool 3
get_location()

然后：

用户
 ↓
Agent
 ↓
选择Tool
 ↓
调用API
 ↓
返回结果

先完成：

查询型Agent。

---

二十八、第二阶段：加入RAG

然后加入：

Agent
 ├── RAG
 ├── get_inventory
 ├── get_order
 └── get_location

此时AI同时具备：

企业知识
+
实时数据

例如：

“按照公司制度，
SKU-10086库存低于多少需要补货？
它现在是否需要补货？”

Agent：

RAG
 ↓
获得安全库存规则

Tool
 ↓
获得实时库存

LLM
 ↓
综合判断

---

二十九、第三阶段：加入执行能力

最后加入：

create_replenishment_task()

架构变成：

Agent
 │
 ├── RAG
 ├── 查询库存
 ├── 查询订单
 ├── 查询库位
 └── 创建补货任务

这样：

查询
 ↓
分析
 ↓
决策
 ↓
执行

就完整了。

---

三十、FDE Agent项目开发流程

一个真实项目可以按照：

其中最重要的一步是：

确定Agent场景。

不是所有业务都需要Agent。

---

三十一、什么场景适合Agent？

非常适合：

复杂查询
跨系统查询
多步骤任务
异常处理
业务分析
智能客服
运营助手
销售助手
仓库助手
IT运维助手

例如：

“帮我分析这个订单为什么没有发出去。”

可能需要：

查询订单
 ↓
查询库存
 ↓
查询拣货任务
 ↓
查询波次
 ↓
查询异常日志
 ↓
综合分析

这就是典型Agent场景。

---

三十二、什么场景不适合Agent？

如果流程非常简单：

查询订单
 ↓
返回订单

直接API就可以。

如果流程高度固定：

A
 ↓
B
 ↓
C
 ↓
D

Workflow通常更加稳定。

如果只是企业知识问答：

制度问题
 ↓
RAG
 ↓
答案

也没必要强行使用Agent。

所以FDE应该学会：

不是为了Agent而Agent，而是根据业务复杂度选择技术。

---

三十三、Agent项目最重要的三个问题

FDE做项目时，可以一直问：

第一个问题

AI需要知道什么？

答案可能是：

RAG
数据库
企业知识

---

第二个问题

AI需要做什么？

答案可能是：

Tool Calling
API
Workflow

---

第三个问题

AI能做到什么程度？

答案取决于：

权限
安全
业务规则
人工审批
系统能力

最终形成：

Knowledge
+
Action
+
Permission
=
Enterprise Agent

---

三十四、FDE真正需要掌握的Agent能力

FDE不一定要成为AI算法专家。

但应该能够：

这才是：

FDE Agent工程能力。

---

三十五、从RAG到Agent的完整演进

到这里，我们已经完成了：

可以总结为：

---

三十六、FDE的最终目标不是“做一个Agent”

这是本章最重要的一句话：

FDE不是为了证明自己会做Agent，而是要利用Agent解决真实业务问题。

例如客户说：

“仓库主管每天都要花两个小时检查库存异常。”

FDE应该思考：

最终：

人工检查2小时
 ↓
AI辅助
 ↓
20分钟

这才是FDE真正创造的价值。

---

三十七、FDE Agent完整技术路线

最终可以形成：

外层增加：

Security
Permission
Guardrails
Evaluation
Monitoring
Audit

最终才是完整的企业Agent平台。

---

三十八、本章总结

本章从RAG继续向前一步。

上一篇：

RAG
 ↓
让AI知道企业知识

这一篇：

Tool Calling
 ↓
让AI能够调用企业系统

进一步：

Agent
 ↓
让AI能够自主完成多步骤任务

最终：

构成企业级AI Agent的核心技术体系。

对于FDE来说，最值得记住的是：

---

三十九、下一篇预告

下一篇进入一个非常重要的主题：

《FDE前沿部署工程师实战教程》09 - Agent工具设计：从API到Tool Calling的企业系统集成

我们将进一步解决一个实际问题：

Agent到底如何连接ERP、CRM、WMS、MES？

重点学习：

并进一步实践：

• 如何把REST API变成AI Tool

• Tool Schema如何设计

• Function Calling完整流程

• GET / POST / PUT / DELETE如何封装

• 数据库查询Tool

• WMS库存查询Tool

• ERP订单查询Tool

• CRM客户查询Tool

• Tool权限控制

• Tool参数校验

• Tool错误处理

• Tool超时与重试

• Tool审计日志

• Agent多Tool协作

• 企业系统集成实战

最终形成：

这一步，将真正把FDE从“AI应用开发”带入“企业AI系统集成”。