问题不在于它们“不够智能”，而在于它们的工程范式很难同时满足企业级客服的几个核心要求：非线性对话、流畅交互、快速响应、强规则约束、长对话可追溯，以及复杂业务逻辑可调试。
先看 ReAct Agent 。
ReAct Agent 的典型做法，是让大模型在多轮推理中自主决定下一步要做什么、调用什么工具、如何推进任务。它看起来灵活，但放到企业客服里会暴露很多问题：
- 它更像一个黑盒，行为难以完全预测；
- 它每一步都依赖大模型推理，响应慢、成本高；
- 它容易在复杂业务规则、权限校验、API 调用边界上出现幻觉；
- 它也很难像传统工程代码一样被断点调试、复盘和精确追踪。
但企业客服里，很多流程不是“差不多就行”。比如退改签、理赔、售后、开户、审批、工单等场景，往往需要非常明确的规则判断、权限控制、状态流转和外部系统调用。让大模型自由放飞，风险太高。
再看 Workflow Agent 。
Workflow Agent 的思路是把流程固定下来，用节点和连线控制对话。它解决了一部分可控性问题，但代价是交互体验变得死板僵硬。
真实用户不会严格按照流程一步步回答问题。用户可能乱序输入，也可能中途更正信息、补充信息、跳转话题，甚至在一个流程中插入另一个话题。传统 Workflow 很难自然处理这些非线性对话场景，最终往往变成“机器人反复要求用户按格式重来”。
所以，企业级客服真正需要的不是“完全自由的大模型”，也不是“完全僵硬的流程图”，而是一种更白盒、更工程化的对话 Agent 架构：
- 让 LLM 负责它擅长的部分：意图识别、信息抽取和自然语言表达；
- 让代码负责它必须负责的部分：业务判断、权限校验、API 调用和状态管理。
这正是我们做 TeliChat 的出发点。
TeliChat 是一个以代码为中心的、面向企业客服和复杂业务流程的白盒对话 Agent 。它不是让大模型自由放飞的 ReAct Agent ，也不是死板僵硬的 Workflow Agent ，而是用「对话树 + 信息项 + Python 代码」来管理多轮对话状态。
在 TeliChat 中，LLM 不负责决定所有业务逻辑。真正的业务判断、权限校验、API 调用都交给代码完成，并且支持 Python 代码断点调试。这样既保留了大模型带来的自然语言交互能力，又满足企业业务系统对可控、可追溯、可调试的工程化要求。
因此，TeliChat 可以支持更复杂的真实对话场景：用户乱序输入、信息更正或补充、话题跳转或插入，都可以被自然处理。同时，它也能满足长对话、可追溯、可调试等企业级需求，并保持流畅交互体验和快速响应。
如果你正在做退改签、理赔、售后、开户、审批、工单等需要强规则的业务流程，可能会发现：单纯依赖 ReAct Agent 太黑盒、太慢、太贵、太容易幻觉；单纯依赖 Workflow Agent 又太僵硬，难以处理真实用户的非线性表达。
如果你对 Rasa CALM 的 YAML 感到厌烦，或对 Dify 僵硬的回复感到沮丧，或对 Claude Code / OpenClaw 的黑盒感到不满，欢迎试试 TeliChat：
https://telichat.io/zh-Hans/
目前 TeliChat 核心产品暂未开源。GitHub 上开放的是基于 TeliChat 构建 Agent 的示例代码：
https://github.com/hanswang73/telichat
我们更多的思考也整理在博客里：
https://telichat.io/zh-Hans/blog/telichat
我是 TeliChat 的创建者。欢迎大家拍砖。