企业官网建设流程全解析

本章关键词：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 ↓ 企业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系统集成”。