AI Agent的工程落地checklist:从需求到上线的完整验收标准清单


1. 引入与连接:为什么一份“全链路、可量化、跨角色”的Agent checklist,能帮你避免零售巨头的90%满意度承诺翻车?

1.1 故事引入:一场本该“解放生产力”的AI客服Agent上线灾难

让我们把时间拉回到2023年11月11日大促前一周——那是某中国TOP5连锁快消品集团(以下简称“快消X”)所有技术、产品、运营团队共同期待的日子:历经3个月、投入8位大模型算法专家、12位产品/售后业务专家、15位前后端/运维工程师打磨的“全能售后AI客服Agent”(对外代号“X管家”)终于要全量上线了。

项目启动会上的PPT至今挂在集团内网的数字转型展馆里:

预期目标

  1. 大促期间售后人工坐席分流率≥95%(日常分流率≥85%);
  2. 售后平均响应时间(AHT)从人工的12.7分钟降至3分钟以内;
  3. 用户售后满意度(CSAT)从人工的82分提升至90分以上;
  4. 复杂售后问题(退款金额≥500元、跨店铺/仓库组合退货、跨境物流纠纷)解决率≥25%。

为了确保这个“明星项目”万无一失,集团数字转型部还专门给技术团队加了10%的年终奖预算,前提是“上线前两周灰度测试期的指标达标率100%”。灰度测试选在了日均售后量最少、用户画像最简单的“母婴旗舰店(国内一二线城市会员组)”——测试结果确实漂亮:

母婴旗舰店灰度测试指标(3天,日均售后量217单):

  1. 人工坐席分流率:98.2% ✅
  2. AHT:2.1分钟 ✅
  3. CSAT:96.7分 ✅
  4. 复杂问题解决率:28.3% ✅

11月11日零点,X管家准时全量上线——覆盖快消X旗下国内127家线上旗舰店、32个线下无人售后终端、海外15个亚马逊/Shopee自营店铺,服务人群从一二线城市会员拓展到三四线城市下沉用户、海外留学生。

灾难从11月11日0:17分开始:

  • 下沉用户用方言提问“奶粉喝了拉肚子怎么退?罐底有点点憋”,X管家要么识别成普通话(比如“憋”识别成“必”,弹出“必购清单推荐”),要么识别成部分方言但无法准确理解“憋罐退货”和“食品安全相关腹泻”的组合逻辑——直接把90%以上的下沉用户推给了人工;
  • 海外用户用英文+中文拼音缩写提问“Amazon order #12345,奶粉罐dented a lot,要全额refund,还要free return shipping吗?”,X管家的多模态知识库(当时只对接了中文小红书/知乎的“快消X憋罐处理指南”和英文亚马逊自营的通用规则,没有对接“Shopee快消X专属规则”“快消X跨境物流合作伙伴DHL的破损赔付流程”)直接弹出了中文通用退货政策,海外留学生要么看不懂,要么看懂后和实际情况不符,CSAT从灰度期的96.7分一路暴跌到海外渠道的42分、国内整体的53分;
  • 线下无人售后终端的用户扫描憋罐奶粉的二维码,X管家因为无法识别二维码中的“批次号前缀(区分普通商品和促销赠品)”“门店仓库标识(区分用户是否可以当场换货)”,直接拒绝了所有憋罐奶粉的当场换货请求,导致三四线城市3个门店聚集了近200名愤怒的消费者;
  • 最严重的是系统稳定性问题:大促前三天快消X的电商平台每秒API请求量(QPS)峰值达到了12万次,X管家的核心调度模块(当时只做了单节点Redis缓存,没有做Redis集群的读写分离、没有做熔断/限流/降级的多层级策略)直接在11月11日0:27分宕机了——接下来的3小时里,所有售后请求要么直接返回502 Bad Gateway,要么排队超过1小时,集团CEO的私人助理的手机直接被30多位品牌方总监的投诉电话打爆了。

大促结束后,快消X的数字转型总结大会变成了“X管家项目复盘批判会”:

实际达成指标(大促前三天,国内日均售后量12.7万单、海外日均售后量1.2万单)

  1. 人工坐席分流率:国内21.3%、海外8.7% ❌
  2. AHT:国内18.2分钟(因为大量积压请求涌进人工坐席)、海外27.5分钟 ❌
  3. CSAT:国内53分、海外42分 ❌
  4. 复杂问题解决率:国内0.7%、海外0.1% ❌

最终损失

  • 直接经济损失:品牌形象公关费1200万元、临时招聘兼职坐席费800万元、海外消费者投诉赔偿费500万元,合计2500万元;
  • 间接损失:品牌CSAT排名从快消品类TOP3降到了TOP27、集团数字转型预算2024年被砍了40%、X管家项目组核心成员(2位大模型算法专家、3位前后端架构师)集体跳槽到了竞争对手那里。

这个血淋淋的故事告诉我们什么?
AI Agent不是“搭个大模型接口、加个知识库、写个简单的prompt模板”就能上线的“玩具”——它是一个集大模型推理、知识库检索、工具调用、多轮对话管理、多模态交互、用户画像分析、风控合规、系统稳定性、可观测性、可扩展性于一体的复杂分布式系统,任何一个环节的疏忽,都可能导致整个项目的“全盘皆输”。

那如何才能避免快消X的灾难?答案就是:拥有一份“全链路、可量化、跨角色、覆盖从需求调研到上线后运维的所有关键节点”的AI Agent工程落地checklist


1.2 与读者已有知识建立连接:checklist不是“束缚创新的枷锁”,而是“降低创新试错成本的保险绳”

很多AI从业者(尤其是大模型算法专家和年轻的产品经理)可能会有这样的疑问:

“大模型是一个‘黑箱’,AI Agent的创新空间很大——比如让Agent自己生成prompt、自己迭代工具、自己学习新的业务规则,用checklist会不会束缚住我们的创新?”

我的答案是:checklist不仅不会束缚创新,反而会释放创新的生产力

为什么这么说?让我们回忆一下历史上checklist最经典的应用案例——航空业的“起飞前checklist”。

在20世纪30年代之前,航空业的事故率非常高——每年大约有20%的飞行员会死于飞机事故。当时的飞机制造商波音公司推出了一款新型轰炸机——B-17飞行堡垒,这款轰炸机的性能非常出色(载弹量是之前轰炸机的3倍、航程是之前的2倍),但它的操作也非常复杂——从起飞到降落需要完成超过100个操作步骤。

1935年10月30日,B-17飞行堡垒在一次公开试飞中坠毁了——原因非常简单:经验最丰富的试飞员希尔少校忘记了在起飞前“放下升降舵锁”。这次事故导致波音公司的B-17订单被美国陆军航空队取消了,波音公司面临破产的风险。

后来,美国陆军航空队的一个试飞小组想出了一个“笨办法”——制作一份“起飞前checklist”“飞行中checklist”“降落前checklist”“降落后checklist”,让飞行员在执行每一个关键步骤之前都对照checklist检查一遍。

结果呢?

  • 接下来的2年里,美国陆军航空队使用B-17飞行堡垒完成了超过180万小时的飞行,事故率只有0.002%——远低于之前的20%;
  • 波音公司的B-17订单不仅恢复了,还收到了来自美国陆军航空队、英国皇家空军等多国空军的超过12000架订单,B-17飞行堡垒成为了第二次世界大战中最著名的轰炸机之一;
  • 后来,checklist的应用范围从航空业扩展到了医疗业(外科手术前的checklist)、建筑业(高层建筑施工前的checklist)、软件业(传统软件项目上线前的checklist)等多个领域,都取得了非常显著的效果。

为什么checklist在这些复杂领域里都能发挥这么大的作用?
因为人类的大脑有两个根本的弱点

  1. “记忆力不足”:人类的大脑一次最多只能记住7±2个信息单元——面对B-17飞行堡垒的100多个操作步骤、面对AI Agent的100多个关键验收节点,经验再丰富的专家也可能会忘记某一个重要的步骤;
  2. “注意力分散”:人类的大脑很容易受到外界因素的干扰——比如快消X的技术团队在大促前一周的压力很大,可能会忘记做Redis集群的读写分离测试、忘记做熔断/限流/降级的多层级策略测试、忘记做方言识别的大规模下沉用户测试。

checklist的作用就是把“专家的隐性知识”转化为“所有人都能执行的显性规则”,帮助我们克服大脑的两个根本弱点——降低创新试错成本、提高项目成功率。


1.3 学习价值与应用场景预览

1.3.1 这篇博客适合谁读?

这篇博客是一份**“全链路、跨角色、普适性+定制性结合”的AI Agent工程落地checklist指南**,适合以下人群阅读:

  • 决策层(CEO、CTO、数字转型总监):了解AI Agent工程落地的关键节点和验收标准,合理分配预算和资源,避免盲目跟风;
  • 产品经理:掌握AI Agent产品需求调研、需求定义、需求验证的方法论,确保产品需求符合业务场景和用户需求;
  • 大模型算法专家:了解AI Agent核心模块(推理模块、检索增强生成RAG模块、工具调用模块、多轮对话管理模块、用户画像分析模块、风控合规模块)的验收标准,确保核心模块的性能和质量;
  • 前后端/运维/测试工程师:掌握AI Agent系统架构设计、接口设计、核心实现、测试(功能测试、性能测试、稳定性测试、安全测试、合规测试、用户体验测试)、上线(灰度测试、全量上线)、上线后运维(可观测性、故障排查、性能优化、版本迭代)的全流程方法论和验收标准;
  • 业务专家(比如售后业务专家、客服业务专家、金融业务专家):了解AI Agent业务规则梳理、知识库构建、业务场景测试的方法论,确保AI Agent符合业务规则和业务流程。
1.3.2 读完这篇博客你能学到什么?

读完这篇博客,你将:

  1. 构建AI Agent工程落地的“全链路认知框架”:了解从需求调研到上线后运维的所有关键节点和验收标准;
  2. 掌握AI Agent核心模块的“可量化验收标准”:比如RAG模块的召回率、准确率、F1值、相关性评分,工具调用模块的成功率、准确率、响应时间,推理模块的输出质量、响应时间、稳定性;
  3. 学会AI Agent系统的“全流程测试方法论”:比如功能测试的等价类划分、边界值分析、错误推测法,性能测试的负载测试、压力测试、稳定性测试、容量规划,安全测试的OWASP Top 10漏洞扫描、大模型提示词注入(Prompt Injection)检测、数据泄露检测;
  4. 拿到一份“可直接复用的AI Agent工程落地checklist模板”**:你可以根据自己的业务场景和技术栈对这个模板进行定制;
  5. 了解AI Agent行业的“发展历史、现状和未来趋势”**:避免踩历史上的坑,抓住未来的机会。
1.3.3 这篇博客的核心应用场景有哪些?

这篇博客的checklist模板可以应用于以下AI Agent的工程落地场景:

  • 企业内部AI Agent:比如智能文档问答Agent、智能代码助手Agent、智能项目管理Agent、智能财务报销Agent;
  • To C消费级AI Agent:比如智能客服Agent、智能导购Agent、智能健康咨询Agent、智能学习辅导Agent;
  • To B产业级AI Agent:比如金融风控Agent、智能供应链管理Agent、智能工业运维Agent、智能法律合同审查Agent;
  • 多模态AI Agent:比如结合文本、图像、音频、视频的智能电商售后Agent、结合文本、图像、LBS的智能旅游规划Agent、结合文本、音频、3D模型的智能家装设计Agent;
  • 自主决策与行动的AI Agent:比如结合RAG、工具调用、强化学习的智能炒股Agent、结合RAG、工具调用、机器人操作系统ROS的智能仓储机器人Agent。

1.4 学习路径概览

这篇博客将按照**“知识金字塔构建者”的教学理念,采用“金字塔式知识结构”,从基础层连接层再到深度层最后到整合层**,层层递进地讲解AI Agent工程落地的checklist:

知识层次 对应章节 核心内容
基础层 2. 概念地图
3. 基础理解
什么是AI Agent?AI Agent的核心要素有哪些?AI Agent和传统软件、ChatGPT类对话机器人有什么区别?AI Agent工程落地的关键节点有哪些?
连接层 4. 需求调研与定义checklist
5. 核心模块设计与实现checklist
6. 系统架构与接口设计checklist
7. 全流程测试checklist
8. 上线与上线后运维checklist
各个关键节点之间的关系是什么?各个关键节点的验收标准有哪些?各个关键节点的可量化指标有哪些?
深度层 9. 核心模块的数学模型与算法实现
10. 最佳实践与常见坑点
RAG模块、工具调用模块、多轮对话管理模块的数学模型是什么?核心算法是什么?Python源代码怎么写?AI Agent工程落地的最佳实践有哪些?常见坑点有哪些?如何避免?
整合层 11. 行业发展与未来趋势
12. 整合提升
AI Agent行业的发展历史是什么?现状是什么?未来趋势是什么?如何把这篇博客的知识应用到自己的项目中?如何构建自己的AI Agent工程落地能力体系?

在正式开始讲解之前,让我们先来看一下这篇博客的checklist模板的整体结构(mermaid思维导图):

AI Agent工程落地
全链路checklist

1. 需求调研与定义

1.1 业务需求调研

1.1.1 业务目标与KPI定义

1.1.2 业务场景梳理

1.1.3 业务规则梳理

1.1.4 现有系统/流程/数据调研

1.1.5 利益相关者调研

1.2 用户需求调研

1.2.1 用户画像分析

1.2.2 用户痛点调研

1.2.3 用户需求优先级排序

1.3 需求定义与PRD撰写

1.3.1 产品定位与核心价值主张

1.3.2 功能需求定义

1.3.3 非功能需求定义

1.3.4 验收标准定义(可量化)

1.3.5 PRD评审

1.4 需求验证

1.4.1 MVP(最小可行产品)需求验证

1.4.2 原型设计与用户测试

2. 核心模块设计与实现

2.1 推理模块

2.1.1 大模型选型

2.1.2 Prompt工程

2.1.3 输出质量控制

2.1.4 响应时间优化

2.2 检索增强生成(RAG)模块

2.2.1 数据源梳理与接入

2.2.2 知识图谱/向量库/关系型数据库选型

2.2.3 数据预处理

2.2.4 嵌入模型选型

2.2.5 索引构建

2.2.6 检索策略设计

2.2.7 检索结果重排序

2.2.8 生成与检索的融合

2.3 工具调用模块

2.3.1 工具梳理与定义

2.3.2 工具接入

2.3.3 工具调度策略设计

2.3.4 工具调用结果验证

2.4 多轮对话管理模块

2.4.1 对话状态跟踪(DST)

2.4.2 对话策略选择(DPL)

2.4.3 对话历史管理

2.4.4 对话中断与恢复

2.5 用户画像分析模块

2.5.1 用户数据收集

2.5.2 用户画像标签体系设计

2.5.3 用户画像更新

2.6 风控合规模块

2.6.1 内容安全检测

2.6.2 提示词注入(Prompt Injection)检测

2.6.3 数据泄露检测

2.6.4 业务合规检测

3. 系统架构与接口设计

3.1 系统架构设计

3.1.1 分层架构设计

3.1.2 微服务架构设计(可选)

3.1.3 缓存架构设计

3.1.4 消息队列架构设计(可选)

3.2 接口设计

3.2.1 RESTful API设计

3.2.2 WebSocket API设计(可选,用于实时多轮对话)

3.2.3 API文档撰写

3.2.4 API安全设计

4. 全流程测试

4.1 功能测试

4.1.1 单元测试

4.1.2 集成测试

4.1.3 系统测试

4.1.4 业务场景测试

4.2 性能测试

4.2.1 负载测试

4.2.2 压力测试

4.2.3 稳定性测试

4.2.4 容量规划

4.3 稳定性测试

4.3.1 故障注入测试

4.3.2 熔断/限流/降级测试

4.4 安全测试

4.4.1 OWASP Top 10漏洞扫描

4.4.2 大模型提示词注入检测

4.4.3 数据泄露检测

4.4.4 API安全测试

4.5 合规测试

4.5.1 数据合规测试(GDPR、个人信息保护法PIPL等)

4.5.2 内容合规测试(广告法、行业监管规定等)

4.6 用户体验测试

4.6.1 可用性测试

4.6.2 用户满意度测试

5. 上线与上线后运维

5.1 上线准备

5.1.1 环境准备(开发环境、测试环境、预发布环境、生产环境)

5.1.2 数据准备

5.1.3 灰度测试方案设计

5.1.4 应急预案设计

5.1.5 上线评审

5.2 灰度测试

5.2.1 第一阶段灰度测试(内部员工)

5.2.2 第二阶段灰度测试(种子用户)

5.2.3 第三阶段灰度测试(小部分正式用户)

5.2.4 灰度测试指标监控与评估

5.3 全量上线

5.3.1 全量上线方案设计

5.3.2 全量上线指标监控

5.4 上线后运维

5.4.1 可观测性(日志、指标、链路追踪)

5.4.2 故障排查

5.4.3 性能优化

5.4.4 版本迭代


2. 概念地图:建立AI Agent工程落地的整体认知框架

(本章核心内容要素:核心概念、问题背景、问题描述、问题解决、边界与外延、概念结构与核心要素组成、概念之间的关系:概念核心属性维度对比markdown表格、概念联系的ER实体关系mermaid架构图、交互关系图mermaid架构图、本章小结)

2.1 核心概念

在正式讲解AI Agent工程落地的checklist之前,我们首先需要明确几个核心概念——避免因为概念混淆而导致的项目失败:

2.1.1 什么是Agent?

Agent(代理)是一个非常古老的概念——最早可以追溯到20世纪50年代的人工智能领域(图灵测试其实就是在测试一个“智能Agent”),后来又扩展到了计算机科学、经济学、社会学等多个领域。

不同领域对Agent的定义略有不同,但计算机科学领域对Agent的最经典定义是由Wooldridge和Jennings在1995年提出的:

Agent的定义(Wooldridge & Jennings,1995)
一个Agent是一个处于某个环境中的计算机系统,它具有以下4个核心属性

  1. 自主性(Autonomy):Agent能够在没有人类或其他Agent直接干预的情况下,自主地控制自己的行为和内部状态;
  2. 反应性(Reactivity):Agent能够感知环境的变化,并及时地对环境的变化做出反应;
  3. 主动性(Proactivity):Agent不仅能够对环境的变化做出反应,还能够主动地设定自己的目标,并采取行动来实现自己的目标;
  4. 社会性(Social Ability):Agent能够与其他Agent(或人类)进行交互,通过合作或竞争来实现自己的目标。

为了帮助大家更直观地理解Agent的4个核心属性,我们可以用**“一个住在出租屋里的上班族”**来做一个生活化的类比:

Agent的核心属性 生活化类比(上班族) 说明
自主性 上班族可以自己决定今天早上吃什么、穿什么、什么时候出门 不需要父母或老板直接干预
反应性 如果今天早上下雨了,上班族会带伞;如果今天早上地铁坏了,上班族会改乘公交车或打车 能够感知环境的变化(下雨、地铁坏了),并及时做出反应
主动性 上班族的目标是“今年攒够10万元买房首付”,所以他会主动地找兼职、主动地省钱、主动地学习新技能来提高自己的工资 不仅能够对环境的变化做出反应,还能够主动地设定目标并采取行动
社会性 上班族会和同事合作完成项目、会和房东协商房租、会和朋友一起出去玩 能够与其他人类(或Agent)进行交互,通过合作或竞争来实现自己的目标
2.1.2 什么是大语言模型(LLM)?

大语言模型(Large Language Model,LLM)是一种基于Transformer架构的深度学习模型,它通过在海量的文本数据(比如互联网网页、书籍、论文、代码库等)上进行自监督学习(预测下一个词或掩码词),来学习语言的语法、语义、语用、常识、逻辑推理能力

目前主流的LLM有:

  • 闭源LLM:OpenAI的GPT-4 Turbo、GPT-4o,Anthropic的Claude 3 Opus、Claude 3 Sonnet,Google的Gemini 1.5 Pro、Gemini 1.5 Flash,百度的文心一言4.0,阿里的通义千问4.0,腾讯的混元4.0,字节跳动的豆包4.0等;
  • 开源LLM:Meta的Llama 3 8B/70B,Mistral AI的Mistral Large 2、Mixtral 8x7B/8x22B,Zephyr 7B/14B,Qwen 2 7B/72B,DeepSeek-V2 7B/67B等。

LLM的核心能力有:

  1. 自然语言理解(NLU):能够理解人类的自然语言输入(文本、音频转文本、图像转文本等);
  2. 自然语言生成(NLG):能够生成符合语法、语义、语用的自然语言输出;
  3. 逻辑推理能力:能够进行数学推理、常识推理、因果推理等;
  4. 代码生成与理解能力:能够生成各种编程语言的代码、理解现有代码的功能、调试代码的bug;
  5. 多模态理解与生成能力(比如GPT-4o、Gemini 1.5 Pro):能够理解图像、音频、视频等多模态输入,生成图像、音频、视频等多模态输出。
2.1.3 什么是AI Agent?

AI Agent(人工智能代理)是一种以大语言模型(LLM)为核心大脑,结合感知模块、记忆模块、推理模块、行动模块(工具调用模块)、交互模块智能计算机系统——它能够实现Wooldridge和Jennings提出的Agent的4个核心属性(自主性、反应性、主动性、社会性)。

为了帮助大家更直观地理解AI Agent的结构,我们可以用**“一个配备了智能手机、笔记本电脑、图书馆、社交账号的超级秘书”**来做一个生活化的类比:

AI Agent的核心模块 生活化类比(超级秘书) 说明
核心大脑(LLM) 超级秘书的大脑 负责理解输入、推理决策、生成输出
感知模块 超级秘书的眼睛、耳朵、手 负责感知环境的变化(比如用户的文本/音频/视频输入、天气的变化、股票的变化、日历的提醒等)
记忆模块 超级秘书的笔记本电脑、图书馆、社交账号的聊天记录 负责存储短期记忆(对话历史、当前的任务状态)、长期记忆(用户画像、业务规则、知识库、历史任务记录)
推理模块 超级秘书的逻辑思维能力 负责根据感知到的信息和记忆中的信息,推理决策下一步该做什么
行动模块(工具调用模块) 超级秘书的智能手机、笔记本电脑上的APP 负责执行推理决策的结果(比如订机票、订酒店、查天气、查股票、写邮件、发微信、调用第三方API等)
交互模块 超级秘书的嘴巴、手 负责与用户或其他Agent进行交互(比如用自然语言回复用户、生成图像/音频/视频给用户、调用其他Agent的API等)
2.1.4 什么是RAG(检索增强生成)?

RAG(Retrieval-Augmented Generation,检索增强生成)是一种将检索模块和生成模块结合起来的技术——它的核心思想是:在生成自然语言输出之前,先从一个外部的知识库(向量库、知识图谱、关系型数据库等)中检索出与用户输入相关的信息,然后将这些检索到的信息和用户输入一起作为prompt输入给LLM,让LLM根据检索到的信息生成更准确、更可靠、更有针对性的自然语言输出

RAG技术主要解决了LLM的3个核心痛点

  1. 知识截止日期问题:LLM的训练数据有一个截止日期(比如GPT-4 Turbo的训练数据截止到2023年12月),它无法获取截止日期之后的实时信息(比如今天的天气、今天的股票价格、最新的新闻、最新的业务规则等);
  2. 幻觉问题(Hallucination):LLM有时候会生成一些看起来很合理但实际上是错误的、不存在的信息(比如生成一个不存在的法律条文、生成一个不存在的产品型号、生成一个不存在的电话号码等);
  3. 领域知识不足问题:LLM的训练数据是通用的文本数据,它对某些特定领域的专业知识(比如医学、法律、金融、工业等)的了解不够深入,无法生成准确的专业领域内容。

为了帮助大家更直观地理解RAG技术的工作原理,我们可以用**“一个写论文的学生”**来做一个生活化的类比:

  • 用户输入:论文的题目“RAG技术在AI客服中的应用研究”;
  • 检索模块:学生去图书馆查相关的书籍、去知网查相关的论文、去互联网查相关的新闻和博客;
  • 检索结果:学生找到的与论文题目相关的书籍、论文、新闻、博客;
  • 生成模块:学生根据找到的相关资料,结合自己的理解,写论文;
  • 最终输出:一篇准确、可靠、有针对性的论文。
2.1.5 什么是工具调用(Tool Use)?

工具调用(Tool Use)是指AI Agent根据用户的输入和自己的推理决策,调用外部的工具(比如API、函数、应用程序、机器人等)来执行特定的任务——它是AI Agent实现“自主性、反应性、主动性、社会性”的核心能力之一。

工具调用主要解决了LLM的3个核心痛点

  1. 无法执行实时/动态任务:LLM无法直接执行实时/动态任务(比如订机票、订酒店、查天气、查股票、控制智能家电、控制工业机器人等);
  2. 无法处理复杂计算:LLM的数学计算能力有限(比如计算复杂的微积分、线性代数、统计分析等),它无法直接处理复杂计算;
  3. 无法获取实时/动态信息:虽然RAG技术可以解决LLM的知识截止日期问题,但RAG技术的知识库需要定期更新,它无法获取真正的实时/动态信息(比如用户当前的位置、用户当前的订单状态、智能家电当前的状态等)——工具调用可以通过调用第三方API直接获取这些实时/动态信息。

为了帮助大家更直观地理解工具调用的工作原理,我们可以用**“一个订机票的超级秘书”**来做一个生活化的类比:

  • 用户输入:“帮我订一张明天早上从北京到上海的最便宜的机票,下午6点之前到达上海浦东机场”;
  • 核心大脑(LLM):理解用户的输入,推理决策需要调用“查机票API”;
  • 工具调用模块:调用“查机票API”,传入参数“出发地:北京”“目的地:上海浦东机场”“出发日期:明天”“出发时间:早上”“到达时间:下午6点之前”“排序方式:价格从低到高”;
  • 工具调用结果:“查机票API”返回的符合条件的机票列表(比如最便宜的机票是中国国航CA1234,早上8点从北京首都机场T3出发,上午10点30分到达上海浦东机场T2,价格是580元);
  • 核心大脑(LLM):根据工具调用结果,推理决策需要询问用户是否订这张机票;
  • 最终输出:“我找到一张符合条件的最便宜的机票:中国国航CA1234,早上8点从北京首都机场T3出发,上午10点30分到达上海浦东机场T2,价格是580元。请问您是否要订这张机票?”

2.2 问题背景:为什么现在AI Agent的工程落地变得这么重要?

2.2.1 大语言模型技术的成熟,为AI Agent的工程落地提供了“核心大脑”

在2022年11月OpenAI推出ChatGPT之前,大语言模型技术还不够成熟——比如GPT-3的输出质量不稳定、幻觉问题严重、推理能力有限、响应时间长、成本高,无法作为AI Agent的“核心大脑”。

2022年11月OpenAI推出ChatGPT之后,大语言模型技术取得了爆发式的发展

  • 输出质量:越来越稳定、越来越符合人类的期望;
  • 幻觉问题:越来越少(比如GPT-4 Turbo的幻觉率只有GPT-3的1/10左右);
  • 推理能力:越来越强(比如GPT-4o可以解决复杂的数学推理、常识推理、因果推理问题);
  • 响应时间:越来越短(比如GPT-4o的响应时间只有GPT-3的1/5左右);
  • 成本:越来越低(比如OpenAI在2024年5月把GPT-4 Turbo的输入成本降低了50%、输出成本降低了25%,把GPT-3.5 Turbo的输入成本降低了95%、输出成本降低了92%);
  • 多模态能力:越来越强(比如GPT-4o、Gemini 1.5 Pro可以理解和生成图像、音频、视频等多模态内容);
  • 工具调用能力:越来越强(比如OpenAI的Function Calling API、Anthropic的Tool Use API可以让AI Agent轻松地调用外部工具);
  • 开源生态:越来越完善(比如Meta的Llama 3、Mistral AI的Mixtral 8x7B、Zephyr 7B等开源LLM的性能已经接近甚至超过了某些闭源LLM)。

大语言模型技术的成熟,为AI Agent的工程落地提供了强大的核心大脑——AI Agent不再是“实验室里的玩具”,而是“可以真正应用到实际业务场景中的工具”。

2.2.2 企业数字化转型的深入,对AI Agent的需求越来越迫切

随着企业数字化转型的深入,企业面临的数据量越来越大、业务流程越来越复杂、人力成本越来越高、用户对服务质量的要求越来越高——传统的软件系统和人工服务已经无法满足企业的需求,企业迫切需要一种能够自主处理复杂业务流程、能够24小时不间断服务、能够降低人力成本、能够提高服务质量的智能工具——AI Agent正好满足了这些需求。

根据Gartner的预测:

  • 到2025年,超过60%的企业将在其业务流程中使用AI Agent;
  • 到2026年,AI Agent将处理超过40%的企业内部交互和超过30%的企业与客户之间的交互;
  • 到2027年,全球AI Agent市场规模将超过1万亿美元。

2.3 问题描述:当前AI Agent工程落地面临的核心问题有哪些?

虽然大语言模型技术的成熟和企业数字化转型的深入为AI Agent的工程落地提供了“天时地利人和”,但当前AI Agent的工程落地仍然面临着很多核心问题——这些问题导致了很多AI Agent项目的失败(比如我们开头提到的快消X的X管家项目):

2.3.1 需求层面的问题
  • 业务目标不明确、KPI不可量化:很多企业在启动AI Agent项目时,只是盲目跟风,没有明确的业务目标和可量化的KPI——比如只是说“我们要做一个智能客服Agent”,但没有说“智能客服Agent的人工坐席分流率要达到多少”“AHT要降到多少”“CSAT要提升到多少”“复杂问题解决率要达到多少”;
  • 业务场景梳理不全面、业务规则梳理不清晰:很多企业在梳理业务场景和业务规则时,只是梳理了“正常流程”,没有梳理“异常流程”“边界情况”“特殊情况”——比如快消X的X管家项目只是梳理了“一二线城市会员用普通话提问的正常憋罐退货流程”,没有梳理“下沉用户用方言提问的流程”“海外用户用英文+中文拼音缩写提问的流程”“憋罐退货和食品安全相关腹泻的组合流程”“普通商品和促销赠品的区分流程”“当场换货和线上退货的区分流程”;
  • 用户需求调研不深入、用户需求优先级排序不合理:很多企业在调研用户需求时,只是发放了一些调查问卷,没有进行深入的用户访谈和用户观察——比如快消X的X管家项目只是调研了一二线城市会员的需求,没有调研下沉用户和海外用户的需求;
  • PRD评审不严格、需求验证不充分:很多企业在撰写PRD时,只是产品经理一个人写的,没有邀请业务专家、技术专家、测试专家、用户代表一起评审——比如快消X的X管家项目的PRD只是产品经理和售后业务总监一起写的,没有邀请大模型算法专家、前后端架构师、测试专家、下沉用户代表、海外用户代表一起评审;而且很多企业在需求验证时,只是做了一个简单的原型,没有做MVP测试和大规模用户测试——比如快消X的X管家项目只是做了一个简单的文字对话原型,没有做多模态原型、没有做MVP测试、没有做大规模下沉用户测试和海外用户测试。
2.3.2 技术层面的问题
  • 大模型选型不合理:很多企业在选型大模型时,只是盲目追求“最大的模型”“最先进的模型”,没有考虑自己的业务场景、性能需求、成本预算、合规要求——比如快消X的X管家项目选型了GPT-4 Turbo,但GPT-4 Turbo的成本很高、响应时间有时候不稳定、而且在海外市场的合规要求(比如GDPR)有时候无法满足;
  • Prompt工程做得不好:很多企业在做Prompt工程时,只是写了一个简单的prompt模板,没有考虑prompt的结构、prompt的内容、prompt的示例、prompt的测试和迭代——比如快消X的X管家项目的prompt模板只是简单地说“你是快消X的全能售后AI客服X管家,请回答用户的问题”,没有加入业务规则、没有加入示例、没有做prompt的测试和迭代;
  • RAG模块做得不好:很多企业在做RAG模块时,只是简单地把数据导入到向量库中,没有考虑数据源的质量、数据预处理的质量、嵌入模型的选型、索引的构建、检索策略的设计、检索结果的重排序、生成与检索的融合——比如快消X的X管家项目的RAG模块只是对接了中文小红书/知乎的“快消X憋罐处理指南”和英文亚马逊自营的通用规则,没有对接“Shopee快消X专属规则”“快消X跨境物流合作伙伴DHL的破损赔付流程”“快消X内部的业务规则文档”;而且数据预处理做得不好,没有对数据进行清洗、去重、分块、标注;嵌入模型选型不合理,选型了一个通用的嵌入模型,没有选型一个快消品类的专业嵌入模型;检索策略设计不合理,只是做了简单的向量相似度检索,没有做混合检索(向量相似度检索+关键词检索+知识图谱检索);检索结果重排序做得不好,没有对检索结果进行相关性评分和重排序;生成与检索的融合做得不好,只是简单地把检索结果拼接到prompt中,没有做prompt的优化和LLM的输出质量控制;
  • 工具调用模块做得不好:很多企业在做工具调用模块时,只是简单地接入了几个工具,没有考虑工具的梳理与定义、工具的接入规范、工具的调度策略、工具调用结果的验证、工具调用失败的处理——比如快消X的X管家项目的工具调用模块只是接入了“查订单API”“退款API”,没有接入“查批次号API”“查门店仓库标识API”“查跨境物流合作伙伴DHL的破损赔付流程API”;而且工具调用结果的验证做得不好,没有对工具调用结果的正确性、完整性、及时性进行验证;工具调用失败的处理做得不好,没有做重试机制、没有做降级机制、没有做错误提示;
  • 多轮对话管理模块做得不好:很多企业在做多轮对话管理模块时,只是简单地把对话历史拼接到prompt中,没有考虑对话状态跟踪(DST)、对话策略选择(DPL)、对话历史的管理、对话中断与恢复——比如快消X的X管家项目的多轮对话管理模块只是简单地把最近10轮的对话历史拼接到prompt中,没有做对话状态跟踪,无法准确地理解用户的意图和需求;
  • 系统架构设计不合理:很多企业在设计AI Agent的系统架构时,只是简单地用了一个单体架构,没有考虑分层架构、微服务架构、缓存架构、消息队列架构——比如快消X的X管家项目的系统架构是一个单体架构,而且缓存架构设计不合理,只做了单节点Redis缓存,没有做Redis集群的读写分离、没有做熔断/限流/降级的多层级策略;
  • 可观测性做得不好:很多企业在做AI Agent的可观测性时,只是简单地记录了一些日志,没有考虑日志、指标、链路追踪的结合——比如快消X的X管家项目的可观测性做得不好,在系统宕机后,无法快速地定位故障原因;
  • 安全合规做得不好:很多企业在做AI Agent的安全合规时,只是简单地做了一些传统的安全测试,没有考虑大模型的安全问题(比如提示词注入、数据泄露、内容安全)、数据合规问题(比如GDPR、PIPL)——比如快消X的X管家项目的安全合规做得不好,没有做提示词注入检测,导致黑客可以通过提示词注入获取快消X内部的业务规则文档和用户的个人信息。
2.3.3 测试层面的问题
  • 功能测试做得不全面:很多企业在做AI Agent的功能测试时,只是测试了“正常流程”,没有测试“异常流程”“边界情况”“特殊情况”——比如快消X的X管家项目的功能测试只是测试了“一二线城市会员用普通话提问的正常憋罐退货流程”,没有测试“下沉用户用方言提问的流程”“海外用户用英文+中文拼音缩写提问的流程”“憋罐退货和食品安全相关腹泻的组合流程”“普通商品和促销赠品的区分流程”“当场换货和线上退货的区分流程”;
  • 性能测试做得不充分:很多企业在做AI Agent的性能测试时,只是测试了“低负载情况下的性能”,没有测试“高负载情况下的性能”“峰值负载情况下的性能”“长时间稳定运行情况下的性能”——比如快消X的X管家项目的性能测试只是测试了“母婴旗舰店日均售后量217单情况下的性能”,没有测试“大促期间日均售后量12.7万单情况下的性能”“峰值QPS 12万次情况下的性能”“长时间稳定运行72小时情况下的性能”;
  • 稳定性测试做得不好:很多企业在做AI Agent的稳定性测试时,没有做故障注入测试、没有做熔断/限流/降级测试——比如快消X的X管家项目的稳定性测试做得不好,在核心调度模块宕机后,没有做熔断/限流/降级,导致所有售后请求要么直接返回502 Bad Gateway,要么排队超过1小时;
  • 安全测试做得不好:很多企业在做AI Agent的安全测试时,只是做了传统的OWASP Top 10漏洞扫描,没有做大模型提示词注入检测、数据泄露检测、内容安全检测——比如快消X的X管家项目的安全测试做得不好,没有做提示词注入检测;
  • 合规测试做得不好:很多企业在做AI Agent的合规测试时,没有做数据合规测试、内容合规测试——比如快消X的X管家项目的合规测试做得不好,在海外
Logo

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地,聚焦技能开发、插件实践与部署教程,为开发者提供可直接落地的方案、工具与交流平台,助力高效构建与落地 AI 应用

更多推荐