「智能体」这个词被讲得很玄，但落到实处，一个能用的智能体无非四块：一个大模型当大脑、一份知识库当记忆、几个工具当手脚、一套工作流把它们串起来。好消息是，今天用 Dify 这样的开源平台，不写代码也能把这四块拼出来。这篇教程用「企业客服助手」这个最常见的场景，带你从空白搭到能发布，重点讲清楚每一步该配什么、为什么这么配，以及哪些地方最容易翻车。
适用人群与为什么选 Dify
这篇教程适合三类人：产品和运营想快速验证一个 AI 助手值不值得做、不想等开发排期；小团队没有专职算法，但有现成的文档和 FAQ 想让 AI 用起来；以及想搞清楚智能体到底由哪些部件组成的人。前提是你的需求相对标准——答疑、查询、表单收集、内容生成——这类需求用 Dify 开箱即用；如果要深度对接内部复杂系统、对数据合规要求极高，可能最终要走自建。
为什么用 Dify？它是开源的 LLM 应用开发平台，可以自己私有部署（数据不出本地），内置了知识库检索、工具调用和可视化的工作流编排，用拖拽连节点的方式就能搭出应用，不写代码也能上手，需要时又能接 API 嵌进自己的产品。它的应用类型覆盖了「聊天助手、Agent、工作流」几种形态，本文讲的「模型 / 知识库 / 工具 / 工作流」四件套都能在里面一一对上号。下面的步骤你跟着在 Dify 里操作即可。
第一步：想清楚智能体要解决的一件事
最容易失败的智能体，是一开始就想「什么都能干」。正确的起点是把它收窄成一件具体任务。以客服助手为例，先写下它的边界：它负责回答产品功能、价格、退换货政策这三类问题；遇到投诉或下单这类需要人工或系统操作的，它的动作是「收集信息并转人工」，而不是自己硬答。
把这件事写成一段「人设与规则」，这就是后面要填进系统提示词的内容。一个好的设定包含：身份（你是某产品的客服助手）、能力范围（只回答这三类问题）、语气（简洁、礼貌、不夸大）、以及兜底规则（不确定时说不确定并引导转人工，绝不编造政策细节）。这段话决定了智能体的基本盘，值得多花十分钟打磨。
第二步：新建应用，配置大模型与系统提示词
在 Dify 里新建一个应用，先选应用类型——客服这种以多轮问答为主、需要挂知识库的场景，选「聊天助手」或「Agent」即可。接着在模型设置里接入一个大模型：填好对应厂商的 API 密钥，或用你已私有部署的模型。日常问答类场景，选一个响应快、性价比高的主力模型即可；需要更强推理或长文档理解时再换更强的型号。把上一步写好的人设与规则填进系统提示词（System Prompt）框里。
这里有个常被忽略的细节：温度（temperature）参数。客服、查询这类要求稳定、忠于事实的场景，温度调低（比如 0.2 左右），让回答更确定;创意、文案场景才需要调高。配完先在 Dify 右侧的调试预览里随便问几句，确认它的语气和边界符合预期，再往下加东西。先把「光靠模型 + 提示词」的版本调顺，是后面排错的基准。
第三步：挂上知识库，让它答得准
只靠模型，客服助手会凭训练记忆瞎答你的退换货政策。要让它答得准，必须挂知识库。流程是：在 Dify 的「知识库」模块新建一个库，上传你的产品手册、FAQ、政策文档（支持 PDF、Word、网页等），Dify 会自动把文档切片并向量化，再在应用里把这个知识库关联进去。
上传后别急着用，先做两件事。一是检查切片粒度：切得太大，检索会带进无关内容；切得太碎，又会丢上下文。Dify 允许调分段长度和重叠，FAQ 类内容建议按问答对切分。二是在提示词里加一条硬约束：「只根据知识库内容回答政策类问题，知识库里没有的，明确说『这一点我需要帮你转人工确认』，不要自行推测。」这条约束是防幻觉的关键。配完后，专门拿几个知识库里有明确答案的问题测试，确认它真的在引用文档而不是自由发挥。
第四步：加工具，让它能办事
只会答的智能体只是个搜索框，能办事才叫智能体。工具就是它的手脚。客服场景常见的工具有：订单查询（按订单号调用内部 API 返回状态）、表单收集（把用户的投诉内容、联系方式结构化保存）、以及发送通知（触发转人工时通知客服群）。
Dify 提供两类工具：一类是内置工具和市场里的现成工具，搜索引擎、网页读取、发邮件这种直接开即用；另一类是自定义工具，你按 OpenAPI 规范把内部接口的地址、参数和返回格式填进去，Dify 就能让模型按需调用（也支持通过 MCP 接入外部工具）。配置自定义工具时，最重要的是把每个参数描述写清楚——模型靠这些描述决定什么时候调、传什么值。比如订单查询工具，要写明「当用户提供订单号并询问物流或状态时调用，参数 order_id 为用户提供的订单编号」。描述含糊，模型就会乱调或不调。
第五步：用工作流把步骤编排起来
简单场景靠模型自己决定调哪个工具就够了；但稍复杂的流程，需要用工作流把步骤固定下来，避免模型随机发挥。Dify 把这种带固定流程的应用叫 Chatflow / Workflow，以「转人工」为例，理想流程是：识别到投诉意图 → 收集订单号和问题描述 → 写入工单系统 → 通知客服群 → 回复用户「已为你转接，工号 XXX」。
在 Dify 的工作流编辑器里，这是一串可视化节点：开始节点接收输入，问题分类/条件节点判断意图，工具节点调用工单接口，回复节点输出结果。把关键路径做成工作流的好处是结果可预测、可复核，不会因为模型某次「想偏了」而漏掉建单。建议把「必须按固定步骤完成」的流程都收进工作流，把「自由问答」留给模型本身，两者配合最稳。
第六步：调试、发布与持续优化
发布前，用一批真实问题做集中测试，覆盖三种情况：知识库里有明确答案的、答案模糊的、以及完全超范围的。重点看它在「不知道」时是否老实兜底，而不是硬编。Dify 的日志与标注模块能看到每轮对话调用了哪个工具、检索到哪些片段，出错时顺着日志查比盲猜快得多。
测试通过后再发布。Dify 提供独立的访问链接、可嵌入网页的对话窗口，以及一套后端 API，方便嵌进你自己的产品或公众号、APP。上线不是终点：定期翻对话日志，把答错、答偏的问题补进知识库或修提示词，把用户高频却没覆盖的需求加成新工具。智能体是越用越准的，关键在于建立这个「看日志—补内容—再优化」的循环。
常见坑与避坑提醒
第一个坑是「知识库不约束」。挂了库但提示词没写「只根据知识库回答」，模型照样幻觉，等于白挂。第二个坑是「工具描述写得太随意」，导致模型该调不调、不该调乱调，自定义工具的参数说明值得认真写。第三个坑是「全靠模型自动编排复杂流程」，关键业务流程一定要用工作流固定，别赌模型每次都想对。第四个坑是「忽视数据合规」：上传客户数据、对接内部 API 前，确认数据存储和出境规则，敏感场景优先用 Dify 的私有部署版本把数据留在自己服务器。第五个坑是「上线即不管」，不看日志的智能体会一直重复同样的错误。
替代方案与什么时候该自建
无代码平台的优势是快，劣势是受平台能力边界限制：复杂的多智能体协作、对延迟和成本的极致控制、特殊的数据合规要求，可能撞到天花板。当你遇到这些情况，再考虑自建——用 LangGraph、LlamaIndex 这类框架自己写编排逻辑，或基于开源模型私有部署。如果只是想要一个轻量对话机器人、连后端都不想碰，国内大厂的智能体平台（如阿里云百炼、腾讯元器）也能更快发布到各渠道，代价是数据要托管在对方平台、定制深度不如自建。
但顺序很重要：先用 Dify 这类平台把流程和效果验证清楚，确认这个智能体真的有人用、真的解决问题，再投入工程资源自建。很多团队的错误是一上来就自研，花三个月做出一个其实没人用的东西。无代码平台最大的价值，恰恰是让你用几天时间、几乎零成本地验证「这件事值不值得做」。把它当成低成本的验证场，跑通了再决定要不要升级，是最务实的路径。