为什么ReAct Agents和Workflow Agents在企业客户服务和复杂业务流程中表现不足

问题不在于它们“不够智能”。真正的问题在于，它们的工程范式使得同时满足企业级客户服务的几个核心需求变得困难：非线性对话、流畅交互、快速响应、严格规则执行、长对话的可追溯性以及复杂业务逻辑的可调试性。我们先从ReAct Agents说起。典型的ReAct Agent让大语言模型通过多步推理自主决定下一步做什么、调用哪些工具以及如何推进任务。这看起来灵活，但在企业客服场景中，很快暴露了几个问题： - 它更像一个黑盒，导致其行为难以完全预测； - 每一步都依赖LLM推理，导致响应变慢、成本更高； - 在复杂业务规则、权限检查和API边界方面容易产生幻觉； - 很难像传统工程代码那样精确调试、重放和追踪。 但在企业客服中，许多流程不能以“差不多就行”的方式处理。例如改签退票、保险理赔、售后服务、开户、审批和工单等场景，通常需要明确的规则评估、权限控制、状态转换和外部系统调用。让LLM自由发挥会引入太多风险。现在来看Workflow Agents。Workflow Agents采用不同的方法：它们预先定义流程，并通过节点和边控制对话。这解决了部分可控性问题，但代价是交互变得僵化且不自然。真实用户不会一步步遵循预定义的流程。他们可能不按顺序提供信息、中途纠正自己、添加新细节、跳到另一个话题，甚至在正在进行的流程中插入不同的请求。传统工作流系统难以自然处理这些非线性对话模式。结果往往是机器人反复要求用户重新开始或按固定格式回答。企业客服真正需要的既不是完全自由形式的LLM，也不是僵化的流程图。它需要一种更白盒、面向工程的对话式Agent架构： - 让LLM处理它擅长的事：意图识别、信息提取和自然语言生成； - 让代码处理必须由代码处理的事：业务决策、权限检查、API调用和状态管理。 这正是我们构建TeliChat的原因。TeliChat是一种代码优先、白盒的对话式Agent，专为企业客服和复杂业务流程设计。它既不是让LLM自由运行的ReAct Agent，也不是僵化的Workflow Agent。相反，它通过“ChatTree + InfoItem + Python代码”管理多轮对话状态。在TeliChat中，LLM不负责决定所有业务逻辑。实际的业务决策、权限检查和API调用由代码处理，并支持Python断点调试。这保留了LLM带来的自然语言交互能力，同时满足企业对可控性、可追溯性和可调试性的要求。因此，TeliChat可以支持更复杂的真实对话场景。用户可以不按顺序提供信息、纠正或补充之前的信息、切换话题，或者在现有流程中插入新话题，系统都能自然处理。同时，它支持企业环境所需的长对话、可追溯性、可调试性、流畅交互和快速响应。如果你正在构建具有强规则约束的业务流程，例如改签退票、保险理赔、售后服务、开户、审批或工单，你可能已经发现，纯粹依赖ReAct Agents会使系统过于黑盒、速度慢、成本高且容易产生幻觉。而纯粹依赖Workflow Agents则会让体验过于僵化，无法处理用户实际表达方式。