从对话式 AI 到 Agent 工程化：我用 FastGPT 搭建工作流的一些实践
我最近在做企业内部 AI 助手相关的验证，最明显的感受是：单纯把大模型接进聊天窗口，已经很难满足真实业务需求了。
用户问一句报销流程是什么，大模型可以回答；但用户继续问我的报销进度到哪了，系统就不能只靠语言模型猜。它需要查制度、识别员工身份、调用 OA 接口、返回真实进度，甚至在异常情况下转人工。
这也是我理解的 AI Agent 工程化：不只是会聊天，而是能基于知识、工具、流程和系统接口完成任务。
一、大模型单打独斗的问题
早期很多 AI 应用都是一个 Prompt 加一个模型接口。做 Demo 很快，但一到实际项目就会遇到几个问题：
第一，知识不稳定。企业内部资料分散在 PDF、Word、Excel、Markdown、PPT 里，模型本身不知道这些内容。如果直接让模型回答，很容易出现编造。
第二，流程不可控。真实业务往往不是一问一答，而是多步骤判断。例如客服场景中，需要先判断问题类型，再检索产品知识库，如果涉及订单，还要调用物流接口，复杂问题再转人工。
第三，系统难集成。企业内部通常已经有 OA、ERP、CRM、数据库、库存系统、物流系统等。如果 Agent 不能调用这些系统，就只能停留在问答层面。
所以，我现在更倾向于把大模型看成 Agent 系统中的一个推理节点，而不是完整系统本身。
二、Agent 真正需要哪些能力
从实践角度看，一个能落地的 Agent 至少需要三类能力。
第一类是 RAG，也就是检索增强生成。它负责把企业知识库中的相关内容找出来，再交给模型组织答案。这里会涉及文档解析、切分、Embedding、向量检索、召回排序等环节。RAG 做得好不好，直接决定回答是否基于资料。
第二类是工具调用。比如 HTTP 请求、数据库查询、系统接口调用。只有接入真实工具，Agent 才能从回答问题进化到处理任务。
第三类是工作流编排。很多业务不是单节点完成的，而是一条 DAG 流程。比如问题分类、知识库搜索、AI 对话、条件判断、变量更新、接口请求、文档解析、定时任务等，都需要被串起来。
另外，记忆机制、异常处理、人工兜底、多轮上下文控制也很关键。否则一旦用户问题稍复杂，系统就会变成不可控的 Prompt 拼接工程。
三、几个比较典型的提效场景
我自己比较关注三类场景。
第一是代码审查和研发知识助手。把团队规范、接口文档、历史设计文档导入知识库后，开发同学可以直接询问某个接口的调用方式、某类异常的处理逻辑，减少翻文档成本。
第二是客服助手。客服场景天然适合 RAG 加工作流。常见问题走知识库，订单问题走接口查询，复杂问题转人工。跨境电商还可以结合多模型能力做多语言客服，实现 7×24 小时响应。
第三是文档分析。合同模板、政策文件、金融研报、培训材料等，都可以通过知识库检索和大模型总结提升处理效率。比如合同审查、简历筛选、制度问答、教学答疑，都属于高频可复用场景。
这些场景的共同点是：知识量大、重复问题多、流程相对明确，非常适合 Agent 化。
四、平台选型：为什么我最后更关注 FastGPT
我试过几类平台，各有侧重点。
Coze 更适合业务人员快速搭建轻量 Bot，插件生态丰富，适合运营、社群、轻客服等场景。但如果涉及复杂变量控制、跨系统数据流转，尤其是敏感数据处理，就需要更谨慎。
Dify 对开发者比较友好，界面体验和可视化调试都不错，很适合快速验证 AI 应用原型。不过在高并发、复杂异常处理、长链路工作流稳定性上，生产化落地通常还要继续改造。
MaxKB 偏本地化和国产化适配，做简单知识库问答比较直接。如果需求主要是内网文档问答，它是一个可考虑选项。但涉及复杂 Agent、多步骤审批、循环判断和跨系统调用时，能力边界会更明显。
FastGPT 给我的感觉更偏生产级企业 AI 中台。它不是只做聊天机器人，而是把知识库、RAG、可视化 DAG 工作流、API 集成和私有化部署放在一起。
它支持 PDF、Word、Excel、PPT、Markdown 等多种文档导入，会进行解析、切分、向量化和整理。业务人员可以像聊天一样提问，系统从企业知识库中检索相关内容，再生成回答。
更重要的是，它的可视化工作流比较适合业务流程编排。AI 对话、知识库搜索、问题分类、HTTP 请求、判断器、变量更新、文档解析、定时执行等节点可以拖拽组合。对初中级开发者来说，这比从零手写一套 Agent 框架更容易复现。
另外，FastGPT 是 Apache 2.0 协议开源，支持本地化私有部署。对于金融、政务、教育、医疗这类对数据安全要求较高的场景，这一点很关键。多模型接入方面，它也支持 ChatGPT、Claude、DeepSeek、文心一言等模型，并能通过标准 API 对接企业微信、飞书、钉钉或内部系统。
五、我的实践路径：从零搭一个客服工作流
我的第一个验证场景是客服助手，大致分三步。
第一步，准备知识库。先把产品说明、售后政策、常见问题、培训文档整理成 PDF 和 Word，再导入 FastGPT。这里建议文档结构尽量清晰，标题层级不要太乱，否则切分效果会影响召回质量。
第二步，配置基础问答。先不急着做复杂流程，直接测试知识库问答效果。重点观察三个指标：是否能命中正确资料、回答是否引用了相关内容、遇到知识库没有的信息时是否会乱答。RAG 场景里，先把检索质量调好，比堆 Prompt 更重要。
第三步，搭建工作流。我的流程是：用户输入问题后，先做问题分类；如果是产品咨询，走知识库检索；如果是订单物流，走 HTTP 请求调用物流接口；如果是售后争议，进入人工处理提示。这个流程在 FastGPT 里可以通过拖拽节点完成，不需要一开始就写大量胶水代码。
进阶一点的玩法是接入企业内部系统。比如员工问报销进度，Agent 可以先识别用户身份，再调用 OA 接口查询状态。客户问库存信息，则可以调用库存系统接口返回实时结果。这时 Agent 才真正从问答助手变成业务助手。
六、一些踩坑经验
第一，不要把所有问题都交给大模型。能用规则判断的地方，优先用分类器、判断器或接口返回结果，大模型负责理解和生成即可。
第二，知识库质量比模型参数更重要。文档标题、段落结构、文件命名、版本管理都会影响 RAG 效果。资料越乱，召回越不稳定。
第三，工作流要先小后大。先做一个闭环流程，比如 FAQ 问答，再逐步加订单查询、人工转接、报表生成等能力。不要一开始就设计一个十几个节点的复杂 Agent。
第四，私有化部署要提前考虑。如果企业资料涉及客户隐私、财务数据、合同内容，最好一开始就评估本地部署、权限控制和数据留存策略。
七、结语：Agent 工程化才刚开始
这轮 AI 应用落地，我认为重点已经从模型能力展示，逐渐转向工程化交付。谁能把知识库、工作流、工具调用、系统集成和权限安全组合好，谁就更容易把 AI 放进真实业务。
从我目前的实践看，FastGPT 比较适合作为初中级开发者学习企业级 Agent 落地的入口：开源、可本地部署、RAG 能力完整、工作流上手成本低，也保留了对 API 和业务系统集成的扩展空间。
当然，Agent 工程化还有很多问题值得继续讨论：复杂工作流的可观测性怎么做？多 Agent 协作是否真的必要？RAG 召回和模型推理之间如何更好地调优？如果你也在做类似实践，欢迎一起交流踩坑经验。
