从对话式 AI 到 Agent 工程化：我用 FastGPT 搭建工作流的一些实践记录

最近我在做企业内部 AI 助手相关的方案验证，最明显的感受是：单纯把大模型接进来做聊天，已经很难满足真实业务需求了。

早期大家做 AI 应用，通常是前端加一个输入框，后端调用大模型 API，用户问什么，模型答什么。这个模式适合演示，也适合做一些轻量问答。但一旦进入企业场景，问题就会复杂很多。

比如员工问报销进度，模型不能只回答报销制度，还要能查 OA 系统里的真实状态。客户问订单物流，AI 不能只根据知识库解释售后规则，还需要调用物流接口返回实时信息。客服机器人也不是简单回答 FAQ，而是要判断问题类型、检索产品资料、必要时查询订单，复杂问题再转人工。

这就是我最近关注 Agent 工程化的原因。AI 应用正在从对话式 AI，走向能理解资料、调用工具、编排流程、连接系统的 Agent 系统。

 1. 为什么大模型单打独斗不够用

大模型本身很强，但它有几个天然限制。

第一，它不知道企业内部最新资料。员工手册、产品文档、合同模板、培训材料、政策文件，这些内容如果不进入知识库，模型无法稳定引用。

第二，它不能天然访问业务系统。OA、ERP、CRM、数据库、库存系统、物流系统，这些都需要通过 API 或内部接口连接。

第三，它不擅长保证流程可控。真实业务里经常有判断条件、异常分支、变量更新、人工兜底、定时任务。如果全靠提示词硬写，后期维护会非常痛苦。

所以我更倾向于把 Agent 看成一个工程系统，而不是一个更聪明的聊天机器人。

一个可落地的 Agent，通常至少需要三类能力：

反思和规划能力：能根据用户输入拆解任务，判断下一步该检索知识库、调用工具，还是继续追问。

工具调用能力：能通过 HTTP 请求、API 接口、数据库或企业系统拿到真实数据。

记忆和知识能力：能把企业文档解析、切分、Embedding 向量化，再通过 RAG 检索增强生成，让回答尽量基于企业自己的资料。

如果再往工程化走，还需要工作流编排、多租户管理、权限控制、日志追踪、异常处理和私有化部署能力。

 2. 我关注的几个提效场景

这轮实践里，我主要验证了几个比较典型的场景。

第一个是代码审查助手。它可以接收代码片段或需求说明，按照团队规范做初步审查，输出风险点和修改建议。这个场景重点不是替代人工 Review，而是把低级错误和重复检查提前过滤掉。

第二个是客服助手。它先判断用户问题类型，再检索产品知识库。如果是常见售前、售后、使用说明，就直接基于文档回答；如果涉及订单或物流，就调用接口查询；如果问题复杂，再提示转人工。

第三个是文档分析助手。企业里大量资料是 PDF、Word、Excel、Markdown，人工检索效率很低。把这些资料导入知识库后，用户可以直接提问，例如某个政策适用条件是什么，某个产品适合什么客户，某个合同模板里有哪些关键条款。

这些场景的共同点是：不是让 AI 自由发挥，而是让 AI 在资料、流程和系统边界内工作。

 3. 平台选型：为什么我最后更偏向 FastGPT

我之前也看过 Dify、Coze、MaxKB 这类平台。

Dify 的体验比较适合研发团队做 AI 应用原型，可视化调试方便，上手也比较快。如果是验证一个想法，比如内部助手、文档问答、简单客服，它确实很顺手。但在高并发、复杂异常处理、长链路工作流稳定性方面，往往还需要结合业务做二次改造。

Coze 更适合业务部门快速搭建轻量 Bot，插件生态丰富，零代码门槛低，适合运营、社群、营销互动、轻量客服。但如果涉及复杂变量控制、跨系统数据流转，或者企业敏感数据，使用 SaaS 形态时就需要额外考虑安全和合规。

MaxKB 更偏本地化和内网知识库问答，适合预算有限、需求相对简单的场景。如果只是做纯文本问答，它比较直接。但如果要做复杂 Agent、多步骤审批、循环判断、异常处理和系统调用，能力边界会更明显。

我最后在方案验证里更多使用 FastGPT，主要看中三个点。

第一，它的 RAG 能力比较贴近企业知识库场景。PDF、Word、Excel、PPT、Markdown 等资料导入后，可以自动解析、切分、向量化，后续通过知识库检索来回答问题。对于制度问答、产品说明、合同模板、培训资料这类场景，落地路径比较清晰。

第二，它的工作流是可视化 DAG 编排。节点包括 AI 对话、知识库搜索、问题分类、HTTP 请求、判断器、变量更新、文档解析、定时执行等。对初中级开发者来说，这种方式比手写完整 Agent 框架更容易理解，也更适合和业务人员一起讨论流程。

第三，它支持多模型和系统集成。可以接入 ChatGPT、Claude、DeepSeek、文心一言等模型，也可以通过 API 对接 OA、ERP、CRM、数据库、库存系统、物流系统等。再加上 Apache 2.0 开源协议和本地化私有部署能力，对于金融、政务、教育、医疗这类对数据安全要求较高的场景，会更容易推进。

我的理解是，FastGPT 不是单纯做聊天，而是把企业知识、业务流程和系统接口封装成可运行的 AI 应用。

 4. 从零搭建第一个客服工作流

我第一次实践时，没有一上来就做复杂 Agent，而是先做了一个最小可用的客服流程。

第一步，准备知识库资料。把产品说明书、常见问题、售后政策、培训文档整理出来，尽量去掉重复内容和过期内容。这里有个经验：RAG 的效果很大程度取决于原始资料质量。文档结构越清晰，标题层级越稳定，后续检索效果越好。

第二步，导入知识库。FastGPT 会对文档进行解析、切分和向量化。这个过程本质上是把非结构化文档变成可检索的知识片段。后续用户提问时，系统会先做 Embedding 检索，再把相关片段交给模型生成答案。

第三步，搭建基础工作流。我一般会先放一个问题分类节点，把问题分为产品咨询、售后政策、订单物流、其他问题。产品咨询和售后政策走知识库搜索，订单物流走 HTTP 请求接口，其他问题则进入兜底回复或转人工提示。

第四步，处理变量和异常。比如接口查询失败时，不要让模型胡乱回答，而是明确提示暂时无法获取物流状态。再比如知识库没有检索到足够相关内容时，可以让 AI 提醒用户补充信息，而不是生成看似合理但没有依据的内容。

第五步，反复测试。测试问题不要只用标准问法，还要加入口语表达、错别字、模糊提问、多轮追问。很多工作流问题不是出在模型能力，而是出在流程分支没有覆盖到。

 5. 进阶：API 调用才是 Agent 落地的关键

做完知识库问答后，我最大的感受是：RAG 解决的是知道什么，API 调用解决的是能做什么。

比如员工问某个制度，知识库足够了。但员工问我的审批到哪了，就必须查 OA。客户问产品保修多久，知识库能回答。客户问订单现在到哪里了，就要查物流系统。

FastGPT 的 HTTP 请求节点在这里比较实用。它可以把用户输入中的变量提取出来，作为参数传给业务系统，再把返回结果交给后续 AI 节点组织成自然语言。这样 Agent 就不只是回答问题，而是开始参与业务流程。

当然，这里也有一些坑。

接口返回结构要稳定，否则后续节点解析困难。

敏感字段要提前脱敏，不能把无关数据全部暴露给模型。

复杂流程要拆小，不要把所有逻辑塞进一个节点。

知识库回答要设置边界，避免模型在没有资料支撑时自由发挥。

这些问题听起来琐碎，但恰恰决定了 AI 应用能不能从 Demo 走到生产。

 6. 写在最后：Agent 工程化还在路上

如果只是做一个能聊天的机器人，现在门槛已经很低。但如果目标是让 AI 真正进入企业业务，问题就会变成系统工程：知识库怎么维护，流程怎么编排，接口怎么治理，权限怎么控制，异常怎么兜底，数据怎么私有化。

从我最近的实践看，FastGPT 比较适合作为初中级开发者进入 Agent 工程化的起点。它把 RAG、工作流、API 集成、多模型接入这些能力做成了相对直观的可视化配置，同时又保留了面向企业场景的私有化部署和系统集成能力。

当然，Agent 工程化仍然有很多值得继续讨论的问题：复杂工作流应该做到多细的节点拆分？RAG 检索召回率和准确率如何平衡？什么时候应该让模型自主决策，什么时候应该用确定性规则控制？企业内部系统接入后，权限和审计应该如何设计？

如果你也在做 AI Agent、企业知识库或智能客服工作流，可以从一个简单的知识库问答开始，再逐步加入分类、判断、HTTP 请求和人工兜底。不要急着追求复杂，先让每一步可解释、可调试、可复现，这可能比单纯追求模型能力更重要。