本章关键词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 AgentAI 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 CallingAgent之所以能够执行任务关键原因之一就是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 }然后结果重新交给LLMTool 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 RAGAgent并不意味着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 100Agent判断SKU001 → 需要补货 SKU002 → 需要补货 SKU003 → 正常然后用户继续“那就帮我创建补货任务。”Agent用户确认 ↓ 权限检查 ↓ 创建补货任务Tool ↓ WMS API ↓ 返回任务号 ↓ AI反馈最终已创建2个补货任务 SKU001 → 补货任务 RT20260905001 SKU002 → 补货任务 RT20260905002这已经不是简单的AI问答。而是AI参与真实业务流程。十四、Agent ERPERP同样可以提供大量Tools。例如采购订单查询 销售订单查询 供应商查询 物料查询 库存查询 财务数据查询 采购申请创建例如用户“帮我查询最近30天采购金额最高的10家供应商。”Agent可以理解问题 ↓ 确定时间范围 ↓ 调用采购数据Tool ↓ 获得数据 ↓ 排序 ↓ 生成报告如果进一步连接RAG采购制度 实时采购数据 Agent就可以回答“为什么这个供应商不能直接下采购订单”十五、Agent CRMCRM场景同样非常适合Agent。例如客户查询 ↓ 商机查询 ↓ 客户历史跟进 ↓ 合同查询 ↓ 生成客户分析用户“帮我整理一下这个客户最近的销售情况。”Agent查询客户 ↓ 查询商机 ↓ 查询订单 ↓ 查询跟进记录 ↓ 汇总 ↓ 生成客户画像进一步“帮我给这个客户创建一次跟进任务。”Agent可以调用CRM API ↓ 创建跟进任务 ↓ 返回任务结果十六、Agent不是“无限自由”的AI企业环境下不能让Agent想干什么就干什么。例如查询库存可以自动执行。但是删除订单 修改财务数据 创建付款 删除客户 调整库存可能必须人工确认因此企业Agent应该设计低风险操作 ↓ 自动执行 中风险操作 ↓ 权限检查 高风险操作 ↓ 人工确认 ↓ 执行十七、Human-in-the-Loop这就是人在回路中。例如用户 “帮我把SKU-10086库存增加1000件。”Agent不能直接执行。应该Agent ↓ 生成操作计划 ↓ 发现这是高风险操作 ↓ 要求用户确认提示即将执行 仓库WH01 SKUSKU-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 ↓ COMPLETEDAgent需要知道当前任务处于什么状态。因此可以设计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 4Agent目标 ↓ AI自主判断下一步 ↓ 选择Tool ↓ 执行 ↓ 根据结果继续判断简单来说Workflow 路线提前规划好 Agent 根据现场情况动态决定路线二十五、什么时候用Workflow如果业务流程非常固定订单创建 ↓ 订单审核 ↓ 库存检查 ↓ 出库 ↓ 发货就适合Workflow。如果问题变化很大“帮我分析一下这个客户为什么最近订单下降。”可能需要Agent动态决定查询客户 ↓ 查询订单 ↓ 查询销售趋势 ↓ 查询历史记录 ↓ 分析原因因此实际企业应用往往是Agent Workflow二十六、企业级Agent整体架构可以把完整架构设计成在外层再增加Authentication Authorization Guardrails Evaluation Audit Log Monitoring形成企业级架构。二十七、FDE如何做一个最小Agent建议不要一上来做超级企业AI Agent而应该先做一个Agent 三个Tools。例如WMSTool 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库存低于多少需要补货 它现在是否需要补货”AgentRAG ↓ 获得安全库存规则 Tool ↓ 获得实时库存 LLM ↓ 综合判断二十九、第三阶段加入执行能力最后加入create_replenishment_task()架构变成Agent │ ├── RAG ├── 查询库存 ├── 查询订单 ├── 查询库位 └── 创建补货任务这样查询 ↓ 分析 ↓ 决策 ↓ 执行就完整了。三十、FDE Agent项目开发流程一个真实项目可以按照其中最重要的一步是确定Agent场景。不是所有业务都需要Agent。三十一、什么场景适合Agent非常适合复杂查询 跨系统查询 多步骤任务 异常处理 业务分析 智能客服 运营助手 销售助手 仓库助手 IT运维助手例如“帮我分析这个订单为什么没有发出去。”可能需要查询订单 ↓ 查询库存 ↓ 查询拣货任务 ↓ 查询波次 ↓ 查询异常日志 ↓ 综合分析这就是典型Agent场景。三十二、什么场景不适合Agent如果流程非常简单查询订单 ↓ 返回订单直接API就可以。如果流程高度固定A ↓ B ↓ C ↓ DWorkflow通常更加稳定。如果只是企业知识问答制度问题 ↓ 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 ToolTool Schema如何设计Function Calling完整流程GET / POST / PUT / DELETE如何封装数据库查询ToolWMS库存查询ToolERP订单查询ToolCRM客户查询ToolTool权限控制Tool参数校验Tool错误处理Tool超时与重试Tool审计日志Agent多Tool协作企业系统集成实战最终形成这一步将真正把FDE从“AI应用开发”带入“企业AI系统集成”。