从零构建AI智能体：手把手教你搭建简历筛选助手工作流

这次我们来看一个关于“工作流与智能体”的实战案例。对于很多刚接触AI应用开发的开发者来说概念可能很清晰但一到动手环节就卡壳工作流到底怎么搭智能体怎么从想法变成可运行的服务这篇文章不绕弯子直接带你从零开始手把手完成一个工作流与智能体的创建、部署和测试全过程。我们将聚焦于一个具体的应用场景构建一个智能简历筛选助手。这个智能体能够接收一份职位描述和一堆候选人简历自动进行分析、匹配和打分并输出一份筛选报告。整个过程会拆解成清晰的工作流步骤并最终封装成一个可通过API调用的智能体服务。无论你是想快速验证一个AI应用想法还是需要将复杂的业务逻辑自动化这套方法都能直接复用。本文的重点不是空谈架构而是提供可落地的操作指南。你会看到环境如何准备、图形化工具如Dify、Coze和代码化框架如何选择、关键节点如何配置、服务如何启动以及最终如何通过API进行集成和批量处理。我们也会讨论不同方案的硬件门槛、部署复杂度和适用边界。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解本次实战案例所涉及的核心技术栈、工具选择以及它们的能力特点帮助你判断是否适合你的需求。能力项说明与本次案例选择项目类型AI智能体与应用工作流开发核心功能通过可视化或代码方式将大模型能力与业务逻辑如数据处理、条件判断、API调用串联构建可执行的自动化应用。主要工具/平台Dify.AI(开源/云服务)、Coze扣子(云平台)、LangChain(代码框架)。案例以 Dify 开源版为主进行演示。硬件门槛极低。使用云平台Coze无需本地硬件本地部署Dify服务对CPU和内存有基础要求如4核8G但无需高端GPU因为主要调用云端大模型API。启动方式云平台注册即用。本地服务通过 Docker Compose 一键启动推荐或源码部署。是否支持API是。智能体/工作流可发布为HTTP API接口供其他系统调用。是否支持批量任务是。通过API循环调用或工作流内的“循环执行”节点实现批量处理。适合场景1. 快速原型验证PM、创业者2. 内部流程自动化如HR筛选、客服分类3. 为现有系统添加AI能力开发者2. 适用场景与使用边界在开始搭建之前明确你能用它做什么以及需要注意什么可以避免后期走弯路。适合谁用产品经理/业务人员无需编码通过拖拽即可将业务想法转化为可演示、可测试的AI应用原型。全栈/后端开发者快速构建AI功能的后端服务提供标准API集成到现有系统中。AI应用爱好者希望学习当前最流行的AI应用开发模式理解智能体Agent和工作流Workflow的实践。能解决什么问题信息处理与摘要自动阅读长文档、会议纪要提取关键信息。分类与路由根据用户输入内容自动分派给不同的处理流程或部门。决策支持像本次案例一样基于规则和模型分析给出建议或评分。多步骤任务自动化串联检索、推理、生成、审核等多个AI步骤完成复杂任务。不适合什么场景需要极致性能或定制底层模型工作流平台主要调度和编排模型API不适合做底层的模型训练、微调或需要极低延迟的推理。完全离线的环境虽然Dify可以本地部署但其核心能力是调用大模型如GPT、Claude、国产大模型如果完全无法连接外网或内网没有部署大模型服务则无法工作。替代传统企业ERP/OA系统它是AI能力的“加速器”和“粘合剂”而非完整的业务系统。合规与安全边界数据隐私如果处理简历、客户信息等敏感数据务必选择可本地部署的方案如Dify开源版并将服务部署在可控的内网环境中确保数据不泄露。模型选择根据数据合规要求选择合适的大模型供应商。处理国内数据时优先考虑合规的国产大模型API。结果审核AI生成的内容如筛选理由需要人工复核尤其在高风险决策场景中避免完全依赖自动化结果。3. 环境准备与前置条件我们以在本地服务器上部署Dify 开源版为例这是最灵活、可控性最高的方式。如果你只想快速体验可以直接使用 Dify Cloud 或 Coze.cn 跳过部署步骤。本地部署Dify所需环境操作系统Linux (Ubuntu 20.04/22.04 LTS 推荐) 或 macOS。Windows 可通过 WSL2 (Ubuntu) 或 Docker Desktop 运行。Docker 与 Docker Compose这是Dify官方推荐的部署方式。确保已安装Docker Engine 20.10Docker Compose V2.3.3 可以通过以下命令检查docker --version docker compose version硬件资源CPU2核以上。内存至少 4GB推荐 8GB 以上。磁盘空间至少 20GB 可用空间用于存放Dify自身、数据库和缓存。网络能够访问互联网以下载Docker镜像和连接你所选用的大模型API如OpenAI、通义千问、智谱AI等。大模型API密钥这是智能体的“大脑”。你需要提前准备至少一个可用的模型服务API Key。OpenAIgpt-3.5-turbo或gpt-4。国内可选智谱AIChatGLM、百度文心一言、阿里通义千问、月之暗面Kimi等。在Dify的后台可以方便地配置。4. 安装部署与启动方式Dify的安装非常简洁得益于Docker Compose。步骤一获取部署文件在服务器上选择一个工作目录下载官方提供的docker-compose.yaml文件。# 创建并进入一个目录 mkdir dify cd dify # 下载最新的docker-compose配置文件 curl -Lo docker-compose.yaml https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml # 如果你无法访问GitHub也可以手动创建或从其他途径获取该文件。步骤二启动Dify服务使用一条命令启动所有服务包括Web前端、后端API、数据库等。# 在 docker-compose.yaml 所在目录执行 docker compose up -d首次执行会从Docker Hub拉取镜像可能需要几分钟时间。-d参数表示在后台运行。步骤三检查服务状态启动完成后检查容器是否正常运行。docker compose ps你应该看到dify-api、dify-web、redis、postgres等服务的状态均为running。步骤四访问Web界面服务启动后在浏览器中访问http://你的服务器IP:3000。你将看到Dify的初始化设置页面。步骤五初始化配置按照页面引导完成初始化设置管理员账号和密码。进入“模型供应商”配置页面添加你准备好的大模型API例如OpenAI。填入API Key和Base URL如果需要。配置完成后即可进入Dify的主控制台。至此你的本地AI应用开发平台就准备就绪了。整个过程如果网络通畅10分钟内即可完成。5. 功能测试与效果验证构建简历筛选助手现在我们进入核心环节在Dify中创建一个真实的“简历筛选助手”智能体及其工作流。5.1 创建智能体进入创建页面在Dify控制台点击“创建应用”选择“智能体Assistant”。基础设置名称智能简历筛选助手描述根据职位描述自动分析并评分候选人简历。图标可选。配置提示词Prompt这是智能体的“灵魂”。我们需要设计一个清晰的系统指令。你是一个专业的招聘助理。你的任务是根据用户提供的【职位描述】和【候选人简历】对候选人进行匹配度分析。 请严格按照以下步骤和格式输出你的分析结果 1. **提取关键要求**从【职位描述】中总结出不超过5条核心的职位要求如技能、经验、学历等。 2. **简历分析**针对【候选人简历】逐一对照上述关键要求判断候选人是否满足并给出简要证据引用简历中的原文。 3. **匹配度评分**基于满足的关键要求数量给出一个百分制的匹配度分数0-100分。 4. **综合评估与建议**提供一段综合性的评估包括候选人的优势、与职位的潜在差距以及“推荐面试”、“待定”或“不匹配”的初步建议。 输出格式必须是严格的JSON { “job_key_requirements”: [“要求1”, “要求2”, ...], “resume_analysis”: [ { “requirement”: “要求1”, “met”: true/false, “evidence”: “简历中的相关描述” }, ... ], “match_score”: 85, “comprehensive_assessment”: “评估文本..., “recommendation”: “推荐面试” } 现在开始处理用户输入。将上述提示词填入“提示词”区域。在“上下文”设置中可以增加“对话记忆”轮次让智能体记住历史。选择模型与参数模型选择你已配置的模型如gpt-3.5-turbo。参数温度Temperature可以设低一些如0.3使输出更稳定、更遵循指令。保存并预览点击右上角“保存并预览”。在右侧的预览窗格中你可以进行快速测试。输入【职位描述】 职位后端开发工程师 要求1. 精通Java或Go3年以上相关经验。2. 熟悉Spring Cloud或Kubernetes。3. 有高并发系统设计经验者优先。4. 计算机相关专业本科及以上学历。 【候选人简历】 姓名张三 学历计算机科学硕士 工作经验5年Java开发经验主导过某电商平台订单系统重构熟练使用Spring Cloud微服务架构有处理百万日活用户流量的经验。了解Kubernetes但未在生产环境深度使用。预期结果你应该收到一个结构化的JSON输出包含了提取的要求、逐条分析、分数和建议。5.2 创建工作流进阶智能体适合单次交互。但如果我们需要批量处理100份简历或者流程中需要加入“从数据库读取职位”、“将结果写入表格”等操作就需要更强大的工作流。工作流允许你以“节点”和“连线”的方式可视化地编排复杂逻辑。下面我们创建一个增强版的简历筛选工作流。新建工作流在Dify控制台点击“创建工作流”。命名为批量简历筛选工作流。添加并连接节点从左侧拖拽节点到画布并连接它们。开始节点定义输入变量。我们设置两个变量job_description(字符串) 和resume_text(字符串)。知识库检索节点可选如果你上传了公司文化、技术栈文档到Dify知识库可以连接此节点让AI参考更多信息。LLM节点核心将上一步创建的“智能简历筛选助手”的提示词和配置复制到这里或者直接调用该智能体。将job_description和resume_text变量作为输入。代码节点后处理添加一个Python代码节点用于对LLM输出的JSON进行格式化、计算平均分等。例如# 输入是上一个LLM节点的输出假设存储在变量 llm_result 中 import json def main(llm_result: str) - dict: try: data json.loads(llm_result) # 可以在这里添加额外逻辑比如日志记录、分数分级等 score data.get(match_score, 0) if score 80: data[grade] A elif score 60: data[grade] B else: data[grade] C return data except Exception as e: return {error: str(e), raw_output: llm_result}结束节点定义输出变量。将代码节点处理后的结果输出。保存并测试工作流点击右上角“保存”。在测试区输入职位描述和简历文本点击“运行”。观察数据如何流经各个节点并检查最终输出是否符合预期。5.3 发布为API服务无论是智能体还是工作流最终都需要被其他系统调用。发布应用在智能体或工作流的编辑页面点击顶部“发布”。选择发布方式API访问生成一个唯一的API密钥和端点Endpoint。这是最主要的方式。站点嵌入生成一段嵌入代码可以嵌入到你的网站中提供聊天窗口。获取API信息发布后在“应用概览” - “访问API”页面你可以看到API 密钥app-xxxxxx端点地址https://api.dify.ai/v1/chat-messages(云服务) 或http://你的服务器IP/v1/chat-messages(本地部署)文档详细的API调用参数说明。6. 接口API与批量任务获得API后就可以用程序来调用你的智能体了。6.1 单次API调用示例以下是一个Python脚本示例调用我们刚创建的简历筛选助手。import requests import json # 配置信息 - 替换成你自己的 API_KEY app-你的API密钥 # 如果是本地部署BASE_URL改为你的服务器地址如 http://192.168.1.100/v1 BASE_URL https://api.dify.ai/v1 ENDPOINT f{BASE_URL}/chat-messages def screen_resume(job_desc, resume_text): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { inputs: {}, # 工作流可能需要inputs智能体对话一般不需要 query: f【职位描述】\n{job_desc}\n\n【候选人简历】\n{resume_text}, response_mode: blocking, # 同步等待结果 conversation_id: , # 首次调用可为空 user: user_123 # 标识用户 } try: response requests.post(ENDPOINT, headersheaders, jsonpayload, timeout120) response.raise_for_status() result response.json() # 解析AI返回的答案 answer result.get(answer, ) # 我们的提示词要求返回JSON这里尝试解析 if answer: # 有时答案可能包含markdown代码块需要提取 import re json_match re.search(rjson\n(.*?)\n, answer, re.DOTALL) if json_match: answer json_match.group(1) try: structured_data json.loads(answer) return structured_data except json.JSONDecodeError: return {raw_answer: answer} return result except requests.exceptions.RequestException as e: return {error: fAPI请求失败: {e}} # 测试调用 if __name__ __main__: job 后端开发工程师要求Java 3年经验熟悉Spring Cloud。 resume 候选人李四有5年Java开发经验精通Spring Boot和Spring Cloud。 result screen_resume(job, resume) print(json.dumps(result, indent2, ensure_asciiFalse))6.2 批量任务处理对于批量处理上百份简历有几种策略策略A简单循环调用API适用于数据量不大、对速率要求不高的场景。注意添加延时以避免触发速率限制。import pandas as pd import time def batch_screen_from_csv(csv_file_path, job_desc): df pd.read_csv(csv_file_path) # 假设CSV有name, resume_text列 results [] for index, row in df.iterrows(): print(f处理第 {index1} 份简历: {row[name]}) single_result screen_resume(job_desc, row[resume_text]) single_result[candidate_name] row[name] results.append(single_result) time.sleep(1) # 每秒调用一次根据API限制调整 # 可以考虑每处理10条就保存一次防止中断丢失 if (index 1) % 10 0: pd.DataFrame(results).to_json(fpartial_results_{index1}.json, orientrecords, force_asciiFalse) # 保存最终结果 pd.DataFrame(results).to_json(final_screening_results.json, orientrecords, force_asciiFalse) return results策略B利用工作流的“循环”功能如果平台支持一些高级的工作流引擎如n8n、Dify的未来版本支持内置循环节点可以在一次工作流执行中处理一个列表。目前Dify的标准工作流更侧重于单次数据流转。对于批量更推荐在外部用代码调用。策略C异步队列处理对于生产环境应该使用消息队列如RabbitMQ、Redis Queue来解耦。主程序将筛选任务放入队列多个工作进程从队列中取出任务并调用Dify API然后将结果写入数据库。这能提高可靠性和吞吐量。7. 资源占用与性能观察由于我们的智能体主要调用外部大模型API本地Dify服务本身的资源消耗并不高主要压力在网络I/O和请求处理上。本地Dify服务资源占用在空闲状态下Dify的Docker容器组API、Web、DB、Redis大约占用1-2GB 内存。在处理并发请求时内存和CPU使用量会上升需要根据实际并发数进行监控和扩容。性能关键点大模型API延迟这是最主要的耗时环节。GPT-3.5通常响应在2-5秒GPT-4或更长上下文可能需10-30秒。批量处理时总时间 ≈ 简历份数 × 单次API延迟。网络带宽确保部署Dify的服务器与所选大模型API服务之间的网络稳定、低延迟。提示词优化冗长或模糊的提示词会导致模型思考时间Token消耗增加。优化提示词是提升效率和降低成本的最有效手段。监控建议使用docker stats命令实时查看容器CPU、内存使用率。在Dify后台的“日志与审计”中查看API调用耗时和状态。对于自建模型API需单独监控其推理服务状态。8. 常见问题与排查方法在搭建和运行过程中你可能会遇到以下问题。这里提供快速的排查思路。问题现象可能原因排查方式解决方案Dify服务启动失败端口被占用、Docker镜像拉取失败、内存不足。1. 运行docker compose logs查看具体错误日志。2. 检查端口3000、5001是否被占用netstat -tlnp | grep :3000。1. 修改docker-compose.yaml中的端口映射。2. 确保网络通畅可尝试手动拉取镜像docker pull langgenius/dify-web。3. 为Docker分配更多资源。访问Web界面显示“无法连接”或空白页前端服务未启动、反向代理配置错误、防火墙。1. 确认dify-web容器状态docker compose ps | grep web。2. 检查浏览器控制台(F12)网络请求错误。1. 重启web服务docker compose restart dify-web。2. 如果是IP访问确保使用HTTP而非HTTPS除非配置了SSL。3. 检查服务器防火墙是否放行了3000端口。调用智能体无响应或返回空API密钥错误、模型配额不足、提示词导致模型无输出。1. 在Dify控制台“日志与审计”中查看该次调用的详细请求和响应。2. 测试模型API Key是否在别处可用。1. 核对API密钥和模型供应商配置。2. 检查大模型平台余额或调用额度。3. 简化提示词进行测试看是否是复杂指令导致模型“沉默”。工作流运行卡在某个节点节点配置错误、代码节点有Bug、外部API超时。1. 在工作流运行历史中查看每个节点的输入/输出数据。2. 检查代码节点的语法和逻辑错误。1. 逐一检查节点配置特别是变量映射是否正确。2. 在代码节点中添加print或logging语句调试输出会在日志中。3. 为调用外部API的节点设置合理的超时时间。批量处理速度慢同步调用、未利用并发、模型API速率限制。1. 统计单次请求平均耗时。2. 查看模型API平台的速率限制文档。1. 使用concurrent.futures或asyncio实现并发调用注意不要超限。2. 升级到更高性能的模型套餐如有。3. 考虑将非核心步骤如格式清洗放在调用模型之前本地处理。返回结果格式不符合预期提示词中对输出格式的约束力不够。1. 在测试窗格中多次运行观察输出是否稳定。2. 检查模型返回的完整内容是否包含了额外解释。1. 强化提示词中的格式指令如“你必须输出JSON不要有任何其他解释文字”。2. 在代码节点中添加后处理逻辑用正则表达式提取所需的JSON部分。9. 最佳实践与使用建议基于实战经验这里有一些建议能帮你更高效、更稳定地使用工作流和智能体。从简单开始迭代复杂不要试图第一个工作流就做得尽善尽美。先构建一个最小可行产品MVP例如只有“输入-LLM-输出”三个节点。跑通后再逐步加入知识库检索、条件判断、代码处理等复杂节点。提示词工程是关键智能体的效果80%取决于提示词。编写提示词时遵循“角色-任务-步骤-格式”的结构。多进行测试和调整。可以利用Dify的“提示词编排”功能来管理不同场景的提示词。变量命名清晰在工作流中为输入变量、节点输出变量起一个清晰易懂的名字如cleaned_resume_text而非var1这在大工作流中能极大提升可维护性。善用“测试”与“版本”功能Dify允许你保存工作流的不同版本。在做出重大修改前先保存一个版本。任何修改后务必在测试区充分测试各种边界案例。API调用的健壮性重试机制对于网络超时或模型服务暂时不可用返回5xx错误实现指数退避的重试逻辑。限流与熔断如果你需要高频调用在客户端实现限流避免冲垮服务或触发API限制。考虑使用熔断器模式在服务持续失败时暂时停止请求。结果校验对API返回的结果进行有效性校验特别是需要结构化数据时。准备好降级方案如返回错误标识由人工处理。数据安全与隐私本地部署处理敏感数据时Dify开源版本地部署是首选。API密钥管理切勿将API密钥硬编码在客户端代码或提交到Git。使用环境变量或密钥管理服务。输入输出审查避免向模型输入个人隐私信息如身份证号、手机号。对模型的输出内容尤其是对外公开的要进行人工或自动化的合规审查。成本控制大模型API调用是主要成本。监控使用量优化提示词以减少不必要的Token消耗。对于内部工具可以考虑使用性能足够且成本更低的模型如GPT-3.5-turbo而非GPT-4。通过以上步骤你已经完成了一个从零到一的AI智能体和工作流创建、部署和集成全过程。这个“简历筛选助手”只是一个起点你可以将这套方法论应用到客服自动应答、内容审核、智能报表生成、个性化推荐等无数场景中。关键在于将复杂的业务问题拆解成可由大模型理解和执行并通过工作流可靠串联的标准化步骤。