从对话式 AI 到 Agent 工程化：我用 FastGPT 搭建工作流的一些实践思考
最近我在做企业内部 AI 助手相关的探索，最明显的感受是：单纯把大模型接到聊天窗口里，已经很难满足真实业务需求了。
很多 demo 看起来很顺滑，用户提问，模型回答。但一进入企业场景，问题马上变复杂：资料分散在 PDF、Word、Excel、内部系统里；同一个问题需要先查制度，再查订单或审批状态；有些问题还要判断是否转人工、是否调用接口、是否记录日志。这个时候，对话式 AI 更像一个入口，真正难的是后面的 Agent 工程化。
一、大模型单打独斗的困境
早期做知识库问答，我通常是把文档切分后做 Embedding，再用 RAG 检索相关片段，最后交给大模型总结回答。这个方案对 FAQ、制度问答、产品说明书检索很有效。
但问题也很明显：
第一，检索不等于理解流程。比如员工问报销进度到哪了，知识库只能回答报销制度，不能知道真实审批状态。
第二，模型容易缺少约束。复杂问题如果没有流程拆解，回答很容易发散。
第三，系统集成成本高。企业里常见的 OA、ERP、CRM、库存系统、物流系统，不可能靠一个聊天框全部解决。
所以我现在更倾向于把 Agent 看成一个系统工程，而不是一个更聪明的 Chatbot。
二、Agent 不只是会聊天，而是会拆任务、调工具、走流程
一个可落地的 Agent，至少要具备几类能力。
首先是反思和判断能力。它需要判断用户意图，比如这是售前咨询、售后问题、订单查询，还是投诉建议。不同问题应该进入不同流程，而不是统一丢给大模型回答。
其次是工具调用能力。比如查物流要调用物流接口，查报销要访问 OA，查客户信息可能要连 CRM。这里的关键不是模型知道答案，而是它知道什么时候调用哪个工具。
再往下是记忆和知识架构。企业知识通常不是一段纯文本，而是大量文档、表格、模板和政策文件。知识库需要支持解析、切分、向量化、检索和更新，否则 RAG 的效果很难稳定。
最后是流程编排。实际业务经常是多步骤的，比如先分类，再检索知识库，再判断置信度，再决定是否调用 API，最后输出结果或转人工。这类链路更适合用 DAG 工作流表达。
三、哪些场景适合先做 Agent 工作流
我个人建议不要一开始就挑战全公司级别的超级助手，可以从边界清晰、数据相对规范的场景切入。
比如代码审查助手，可以把团队规范、常见漏洞规则、提交说明模板放进知识库，让 AI 辅助检查代码风格、接口说明和潜在风险。
比如客服助手，可以先判断问题类型，再检索产品知识库。如果涉及订单或物流，再通过 HTTP 请求调用系统接口。复杂问题则转人工处理。
比如文档分析助手，可以导入合同模板、产品说明、政策文件，让 AI 帮忙提取关键条款、总结差异、生成摘要。
这些场景的共同点是：有明确知识来源，有重复问题，有可拆解流程，也有比较清晰的评估标准。
四、平台选型：为什么我最后更关注 FastGPT
我前后看过几个平台。Dify 的体验比较好，适合研发团队快速做 AI 应用原型，可视化调试也比较方便。Coze 更适合业务部门搭建轻量 Bot，插件生态丰富，适合运营、社群、轻客服等场景。MaxKB 在本地化、国产化、简单知识库问答方面有优势，适合需求相对简单的内网环境。
但如果目标是把 AI 接入企业业务流程，我会更关注几个点：RAG 是否足够专业、工作流是否能表达复杂逻辑、能不能调用外部系统、是否支持私有化部署、后续是否便于维护。
FastGPT 给我的定位更像一个企业级 AI Agent 构建平台，而不只是聊天机器人。它支持知识库问答，可以导入 PDF、Word、Excel、PPT、Markdown 等资料，并完成解析、切分、向量化和整理。用户提问时，系统会基于企业自己的知识库检索，再组织回答。
另外，它的可视化工作流比较适合初中级开发者上手。很多节点可以通过拖拽完成，比如 AI 对话、知识库搜索、问题分类、HTTP 请求、判断器、变量更新、文档解析、定时执行等。对业务流程来说，这种 DAG 编排比单纯写 Prompt 更可控。
还有一点是部署和集成。FastGPT 支持接入 ChatGPT、Claude、DeepSeek、文心一言等模型，也支持通过 API 对接 OA、ERP、CRM、数据库、库存系统、物流系统等。对于对数据安全要求较高的团队，本地化私有部署和 Apache 2.0 开源协议也更友好。
五、我的实践路径：从知识库到第一个客服工作流
我自己的搭建顺序大致分三步。
第一步，先做知识库。把产品说明、常见问题、售后政策、操作手册等文档导入进去。这里不要急着追求全量资料，建议先选一批结构清晰、更新频率低、问题覆盖高的文档。导入后重点测试检索效果，比如问法变化、同义词、长问题、模糊问题是否能命中。
第二步，搭一个最小客服工作流。流程可以很简单：用户输入问题，先做问题分类；如果是产品咨询，就走知识库检索；如果是售后政策，就检索售后文档；如果识别为订单问题，则提示需要查询订单系统或进入后续接口调用流程。这个阶段重点不是功能多，而是让链路跑通。
第三步，加入 API 调用。比如客户问订单物流到哪了，工作流先提取订单号，再通过 HTTP 请求调用物流接口，最后把接口返回结果转成自然语言。员工问报销进度，也可以先识别员工身份和单号，再去 OA 系统查询真实状态。
这个过程里我踩过几个坑。
一个是知识库内容不要太杂。把制度、产品、售后、合同全部塞到一个库里，容易造成检索干扰。更好的方式是按业务域拆分，再在工作流里决定查哪个库。
另一个是 Prompt 不要承担所有逻辑。判断、分支、变量更新、接口调用，尽量交给工作流节点。Prompt 适合描述任务边界和输出格式，不适合承载复杂业务流程。
还有一个是异常分支必须提前设计。接口超时、订单号缺失、知识库无结果、用户问题不完整，这些都要有兜底路径。否则 demo 能跑，生产环境很容易翻车。
六、给初中级开发者的复现建议
如果你刚开始接触 AI Agent，我建议按这个路线练习：
先用 FastGPT 做一个企业制度问答或课程资料问答，理解知识库、Embedding、RAG 的基本链路。
再搭一个包含分类和分支的工作流，理解 DAG 编排的价值。
最后接一个简单 HTTP API，比如查询天气、物流或内部测试接口，练习工具调用。
这样走下来，你会发现 Agent 落地的重点不是模型本身，而是知识、流程、接口和权限的组合。
结语
从我的体验看，FastGPT 比较适合那些想把 AI 从问答工具推进到业务助手的团队。它没有把所有事情都包装成黑盒，而是把知识库、RAG、工作流、API 集成这些关键能力拆出来，让开发者和业务人员都能参与搭建。
当然，Agent 工程化还有很多问题值得继续讨论：复杂流程如何做版本管理？多模型路由怎么设计？RAG 结果如何评估准确率？工具调用失败后如何自动恢复？
如果你也在做 AI Agent 或知识库问答系统，欢迎聊聊你的选型和踩坑经验。
 折叠时空之术】)
