最近在做一个AI客服系统的升级项目团队里关于技术选型的讨论特别热烈。核心争议点就是到底该用“工作流”还是“智能体”来构建我们的AI客服大脑这听起来像是个二选一的问题但实际落地时需要考虑的因素远比想象中复杂。今天就把我们调研、踩坑和最终决策的过程梳理一下希望能给面临同样选择的你一些参考。1. 背景与痛点为什么传统客服系统不够用了在引入AI之前我们的客服系统主要依赖规则引擎和人工坐席。规则引擎处理一些“如果...那么...”的固定流程比如查询订单状态、重置密码。这种模式有几个明显的痛点规则爆炸业务稍微复杂一点规则数量就呈指数级增长维护起来简直是噩梦。僵硬死板用户稍微不按预设路径走系统就“卡壳”了必须转人工。成本高昂简单重复的问题依然消耗大量人力坐席人员疲于应付基础咨询。引入大语言模型LLM后我们看到了曙光。AI能理解自然语言似乎能解决所有问题。但很快新挑战来了直接让一个“万能”的AI模型处理所有客服请求效果并不稳定。它可能在某些问题上对答如流但在需要精准执行步骤比如退换货流程或查询实时数据比如库存时就开始“胡言乱语”或效率低下。这就引出了我们的核心议题如何“驾驭”AI的能力让它既灵活又可靠工作流和智能体是两种主流的架构思路。2. 技术方案对比工作流 vs. 智能体简单理解你可以把“工作流”看作是一张精心设计的地铁线路图而“智能体”更像是一个拥有地图和决策能力的专车司机。工作流Workflow方案核心思想将复杂的客服任务分解为一系列预定义的、有序的步骤。每个步骤可能调用一个工具如查数据库、执行一个判断如验证用户身份或生成一段固定回复。优点确定性高流程固定输出稳定可控非常适合标准化、合规性强的业务如金融开户、售后理赔。响应速度快步骤明确无需多次思考决策通常延迟更低。可维护性直观流程可视化非技术人员也能理解修改流程就像调整流程图。缺点灵活性差无法处理流程外的用户请求容易陷入“对不起我不理解”的循环。设计成本高需要预先穷举所有可能的对话路径设计工作量大。智能体Agent方案核心思想赋予AI一个“大脑”规划能力和一套“工具”执行能力。AI根据用户目标自主规划步骤、选择工具、执行并评估结果直到完成任务。优点灵活性极强能处理非预设的、复杂的、多步骤的查询例如“帮我比较一下产品A和B的优缺点然后告诉我哪个更适合户外旅行”。泛化能力好面对新问题有可能通过组合已有工具来解决具备一定的创造性。开发更聚焦开发者主要精力放在提供丰富、可靠的工具上路由逻辑交给AI。缺点不确定性高AI的决策路径可能不稳定有时会绕弯路或调用错误工具。性能开销大每一步都需要LLM进行“思考”调用API导致响应延迟较长Token消耗多。调试复杂出问题时需要分析AI的整个思考链Chain-of-Thought定位问题根源比较困难。3. 核心实现用Python代码看差异理论说再多不如看代码直观。我们用一个经典的“查询订单并计算退货资格”场景来对比。工作流实现示例使用简单状态机class RefundWorkflow: 一个简单的退货资格校验工作流 def __init__(self): self.state START self.order_info None def execute_step(self, user_input: str): 根据当前状态执行步骤 if self.state START: # 步骤1请求订单号 return 请输入您的订单号。 elif self.state AWAIT_ORDER_ID: # 步骤2查询订单 self.order_info self._query_order(user_input) if not self.order_info: return 未找到该订单请确认订单号是否正确。 self.state CHECK_TIME # 进入下一步 return self.execute_step() elif self.state CHECK_TIME: # 步骤3检查下单时间是否在7天内 days_passed self._calculate_days(self.order_info[create_time]) if days_passed 7: self.state CHECK_STATUS else: self.state FAIL_TIME return self.execute_step() elif self.state CHECK_STATUS: # 步骤4检查订单状态是否为“已收货” if self.order_info[status] delivered: return 恭喜您的订单符合退货条件 else: return 抱歉您的订单状态为{}暂不支持退货。.format(self.order_info[status]) elif self.state FAIL_TIME: return 抱歉您的订单已超过7天退货期不符合退货条件。 def _query_order(self, order_id): # 模拟查询数据库 mock_db {ORD123: {create_time: 2023-10-20, status: delivered}} return mock_db.get(order_id) def _calculate_days(self, create_time): # 简化计算 return 3 # 使用工作流 workflow RefundWorkflow() print(workflow.execute_step()) # 输出请输入您的订单号。 workflow.state AWAIT_ORDER_ID print(workflow.execute_step(ORD123)) # 输出恭喜您的订单符合退货条件智能体实现示例使用LangChain框架思路from langchain.agents import Tool, AgentExecutor from langchain.llms import OpenAI from langchain.agents import initialize_agent from langchain.chains import LLMChain from langchain.prompts import PromptTemplate # 1. 定义工具函数 def query_order_tool(order_id: str) - str: 根据订单号查询订单详情 mock_db {ORD123: {create_time: 2023-10-20, status: delivered, product: 手机}} order mock_db.get(order_id) return str(order) if order else 订单不存在 def check_refund_policy_tool(order_info: str) - str: 根据订单信息判断是否符合退货政策 # 这里可以解析order_info字符串实现业务逻辑 # 简化版假设总是返回一个分析结果 return 分析完成订单在7天内且状态为已收货符合退货条件。 # 2. 将工具封装 tools [ Tool( nameOrderQuery, funcquery_order_tool, description根据订单号查询订单的创建时间和状态。输入应为订单号。 ), Tool( nameRefundPolicyChecker, funccheck_refund_policy_tool, description检查订单是否符合退货政策。输入应为订单信息字符串。 ) ] # 3. 创建LLM和智能体 llm OpenAI(temperature0) # temperature0使输出更确定 agent initialize_agent( tools, llm, agentzero-shot-react-description, # 一种简单的智能体类型 verboseTrue # 开启verbose可以看到智能体的思考过程 ) # 4. 执行任务 result agent.run(用户想退货订单号是ORD123请帮他判断是否符合条件。) print(result)代码解读工作流代码是命令式的我们明确写出了“第一步干嘛第二步干嘛”。流程完全由代码控制。智能体代码是声明式的我们只提供了工具Tool和任务描述由LLM自己决定先调用哪个工具、后调用哪个工具。verboseTrue时你会看到它类似“我需要先查询订单详情然后检查政策”的思考过程。4. 性能考量并发、延迟与成本在真实生产环境性能是硬指标。并发处理工作流由于逻辑简单多为内存计算和数据库查询可以轻松通过异步Async和多实例横向扩展来应对高并发。每个会话状态可以放在轻量级存储如Redis中。智能体瓶颈在于LLM的API调用。无论是使用云端API还是自部署模型其吞吐量和响应时间都有限。需要设计复杂的排队、限流和缓存策略。一个技巧是将智能体的“思考”步骤规划与“执行”步骤调用工具异步化思考可以稍慢但工具执行要快。响应延迟Latency工作流延迟主要来自网络I/O查库、调接口。通常可以在100-500毫秒内完成。智能体延迟 LLM思考时间 工具执行时间 可能的多次往返。一次简单的任务也可能需要2-5秒对于实时对话体验是挑战。解决方案对常见、固定的任务可以将其“降级”为工作流绕过智能体的规划环节。成本工作流成本主要是基础设施和开发人力。智能体成本大头是LLM的API调用费用按Token计费。复杂的思考链会消耗大量Token。优化方向精心设计提示词Prompt以减少不必要的思考对工具描述进行压缩缓存相似的思考结果。5. 避坑指南生产环境中的血泪教训不要试图用一把锤子敲所有钉子最成功的架构往往是混合的。我们的策略是高频、标准化、强规则的场景用工作流低频、复杂、探索性的场景用智能体。在网关层就做好路由。智能体的工具设计是关键工具要“小而专”功能边界清晰。一个“万能查询工具”不如“查订单工具”、“查物流工具”、“查政策工具”三个组合起来可控。工具函数的错误处理必须健壮返回格式要规范。为工作流设计优雅的退出机制当工作流无法理解用户输入时不能直接报错。应该设计一个“升级”机制比如连续失败N次后将对话历史和当前状态传递给智能体接手。状态管理是生命线无论是工作流还是智能体都需要维护对话状态Session State。一定要使用外部存储如Redis并设计好会话过期和清理策略避免内存泄漏。可观测性Observability必须前置给智能体的每一步思考、每一次工具调用都打上详细的日志和度量指标Metrics。这样当用户说“AI答错了”时你才能快速回溯是工具返回数据错了还是LLM理解错了或者是提示词有问题。Prompt不是玄学需要版本管理智能体的表现极度依赖提示词。要把Prompt当成代码一样管理进行版本控制、A/B测试和效果评估。6. 总结与思考如何选择经过几个月的实践我们团队形成了以下选型共识你可以作为一个决策框架选择工作流如果你的业务流程固定变化少如开户、理赔、审核。要求100%准确性和合规性。期望响应速度极快1秒。开发和维护团队更熟悉传统业务系统开发。选择智能体如果你的业务需求多变无法枚举所有对话路径如创意咨询、复杂技术支持。需要连接多个异构系统或数据源来完成一个任务。可以容忍一定的延迟2秒和偶尔的“非最优解”。团队有较强的AI工程和Prompt工程能力。更现实的路径是“混合架构”入口路由用户问题进来后先用一个简单的分类器可以是小模型或规则判断问题类型。分派执行如果是标准问题查订单、查余额走预置的工作流引擎。如果是复杂问题“帮我规划一下旅行行程”则交给智能体处理。兜底与交接工作流处理失败时可以携带上下文求助智能体智能体在发现用户意图是标准流程时也可以主动引导至工作流。最后技术选型没有银弹。“工作流”和“智能体”本质上是“确定性”与“不确定性”的权衡。从高度确定的工作流开始逐步在需要的地方引入智能体的灵活性可能是一条更稳妥的演进路线。最重要的是无论选择哪种都要建立快速验证和度量的闭环让业务效果和数据来驱动架构的演化。希望这篇笔记能帮你理清思路。在实际动手前不妨先用一个最核心的业务场景分别用两种方式快速原型Prototype一下亲身感受它们的差异和优劣这比任何理论分析都管用。