先说结论普通人要搭一个能用的 AI Agent 工作流真的不用一开始就买 GPT-4、Claude 这类贵模型。用 DeepSeek、Qwen 这类便宜大碗的模型配合 Coze、Dify、n8n 这类编排工具几百块预算就能跑通一整套自动化流程甚至本地部署用不上 GPU 也能搞定一部分。这篇内容就是给你捋清楚“为什么要这么做、工具怎么选、具体怎么搭、会遇到什么坑”我从零到一做了几个月的 AI Agent 工作流把踩过的和验证过的经验都写下来。适合想用 AI 处理日常事务、正在犹豫要不要买贵的 API、或者只是想在家里搞点自动化小项目的普通人。1. 别急着下单先搞清楚 Agent、LLM、模型到底是不是一回事很多人被 AI Agent 这个词唬住了觉得它一定是什么高深不可攀的东西再加上“大模型”天天上热搜一上来就想买最贵的。但你连三者关系都没弄清楚花多少钱都是打水漂。1.1 三者的关系模型是引擎LLM 是大脑Agent 是会干活的机器人先给小白打个比方。模型就像一台发动机它本身不装在任何车上只是提供动力。LLM大语言模型是那种特别会“理解语言、组织语言”的发动机DeepSeek、Qwen、Llama 都属于这个范畴你要问 DeepSeek 属于哪一类它就是 LLM不是 Agent也不是什么单独的神秘存在。那 Agent 是什么呢Agent 是“发动机方向盘传感器控制逻辑”打包好的一辆车甚至可以说是一个会自己开车的司机。它能感知输入能推理判断能调用工具能执行动作能根据结果调整下一步。比如你让它“帮我整理这封邮件提取待办事项然后写一封回复草稿”它不只是生成文字而是拆解这个任务、用模型理解邮件、调日历或邮件工具、最后产出结果。明白了吗很多人以为买了最强模型就等于有了最强 Agent这就像说买了顶配发动机就等于有了无人驾驶汽车一样缺了中间那一大套东西。而大多数普通人的需求根本用不到顶配发动机——一台经济型发动机加一套好的车身控制逻辑反而更实用。1.2 为什么“先别急着买贵模型”是普通人的第一原则我在搭建工作流之前先做了一次成本测试。同样让模型做“提取会议纪要里的行动项并输出为结构化表格”这个任务用几款模型各跑了一次模型输入价格约输出价格约单次任务消耗约单次成本DeepSeek API1元/百万 tokens2元/百万 tokens1500 tokens0.002元左右某国际旗舰模型60元/百万 tokens240元/百万 tokens1500 tokens0.18元左右某次旗舰模型20元/百万 tokens80元/百万 tokens1500 tokens0.06元左右同样是“提取行动项”这种轻量任务贵模型的价格是便宜模型的几十倍但结果质量差距微乎其微。因为这类任务拼的是指令遵循能力不是世界知识储量。便宜的 DeepSeek 在结构化输出、工具调用上已经做得相当好那何必多花钱呢。但这还不是最重要的。最重要的原因在于——你先要用低成本试错。工作流的坑不在模型而在流程设计。你的输入格式会不会变、中间要不要加判断分支、输出要不要接进通知工具、并发会不会触发限流……这些问题只有在跑起来以后才会暴露。你要是咬牙买了贵模型再开始搭等于在练手阶段就给自己烧钱上压力很多人就是这样被劝退的。我个人的建议是第一步全部用便宜模型搭通流程确认业务真的跑顺了、有增量价值了再考虑升级旗舰模型对比效果。有句话叫“先弄脏手再买好工具”放在 AI Agent 上尤其适合。2. 低成本工作流的三条路线Coze、Dify、n8n 怎么选模型选完了下面挑工作流编排工具。这个选择直接决定你是轻轻松松拖拽完成还是被各类节点配置折磨到怀疑人生。2.1 不同段位的人选不同工具市面上的工作流工具其实就三类我试过之后给它们的定位是零代码玩具、半代码平台、全代码自动化。工具适合人群门槛典型能力我的评价Coze扣子完全不会写代码的人很低拖拽搭 Bot、内置大量插件、一键发布到飞书/公众号/微信最适合练手但自定义能力有限重度需求会撞墙Dify愿意碰一点点代码和 API 的人中等可视化编排、知识库、支持私有化部署、模型可自行配置最均衡我日常主力n8n有代码基础、想自动化复杂业务的人较高集成数百个应用、支持代码节点、完全自托管真正的生产力工具但学习曲线陡给普通人的结论很直接如果你是纯小白先玩 Coze半小时就能搭出第一个 Agent如果你想做点正经工作流想接入自己的 API Key想控制成本细节那就直接上 Dify。n8n 更适合已经有明确业务流程、想把 AI 嵌入 CRM、表单、邮件系统的人。顺带一提如果你用过 ComfyUI 搭 AI 绘画的图生图工作流你在 Dify、Coze 里会有一种似曾相识的感觉——一样的节点式连线、一样的模型选择、一样的输入输出链路。底层思维都是相通的把 AI 当成流水线里的一个工序前一步的输出作为后一步的输入。2.2 工作流的核心要素节点、连线、上下文不管用哪个工具工作流的本质都一样——工厂流水线。原始材料从一端进来经过若干个工位每个工位完成一个动作最后从另一端产出成品。我把几个核心节点给你拆开看输入节点工作流的“原料入口”。可以是用户对话框、一个表单、一个网页触发也可以是从邮件、数据库、API 推送过来的数据。输入节点的核心是定义好字段不然下一步模型根本不知道你在说什么。LLM 节点真正的“大脑工位”。这里选择模型、写 Prompt、设置参数。整条工作流的智能程度都取决于这个节点的配置。工具节点模型的“手脚”。模型本身不能发邮件、不能查天气、不能查询数据库但通过工具节点你可以让模型调用外部 API。Dify 和 Coze 都内置了大量现成工具也可以自定义 API 工具。分支节点流水线的“分拣员”。根据模型输出的判断结果决定走哪条路。比如“如果这条评论是负面情绪进入安抚流程否则进入统计流程”。输出节点成品出口。可以返回一段文本、写入数据库、发送到飞书/企微/邮件也可以触发下一个工作流。最容易被忽略的是“上下文”。模型不是仓库管理员它每次调用只看得见你递给它的内容记住你设置的常量、变量和系统指令——就像流水线上的工人只看得到眼前这张工单一样。所以你要主动把上游节点的输出以变量的形式传递到 LLM 节点的 Prompt 里。这一步新手十有八九会漏掉结果就是模型“失忆”答非所问。有了这个基础理解下面我就以 Dify 为例带你完整搭一个简历筛选 Agent从需求拆解到 Prompt 编写到成本测算一次走完。3. 从 0 到 1 搭一个“简历筛选 Agent”的完整实操为什么要选“简历筛选”这个例子因为它太典型了。需求清晰、输入输出明确、有判断逻辑、有实际价值而且任何人看完都能立刻类推到自己手头的场景上——筛选商品评论、筛选工单、筛选问卷答案本质都一样。3.1 场景选择和需求拆解我先说我当时的需求团队每周收到几十份简历初级岗位尤其多HR 忙不过来。我想让 Agent 先做第一轮初筛把明显不合适的筛掉同时给面试官提供候选人的亮点摘要和提问建议。需求拆解成一句话就是给一段简历文字输出三个值——是否通过初筛、评分0-100、推荐理由和面试提问建议。你可能觉得这就完了不真正的需求拆解要细得多。我当时列了一个问题清单简历是纯文本还是 PDF初始阶段先让用户粘贴纯文本PDF 解析属于扩张功能不要第一步就做。“通过初筛”的标准是什么我要把硬性条件写清楚。比如“必须具备 2 年以上后端经验”这种否则模型会按自己的理解瞎判断。输出格式是什么我要求 JSON 结构化输出因为后续要接人处理JSON 方便程序解析。处理不了怎么办比如简历太短、乱码、信息严重缺失要有一个“存疑”分类而不是硬着头皮评分。需求拆解得越细后面写 Prompt 越容易。很多人搭工作流失败不是因为技术而是需求根本没想清楚。3.2 具体配置步骤含 Prompt 模板下面按 Dify 的实际操作顺序说你在 Coze 里也能找到差不多的节点只是名字略有不同。步骤 1新建空白工作流定义输入字段我建了一个名为“简历初筛 Agent”的工作流添加了一个文本类型的输入字段命名为“resume_text”描述写清楚“请粘贴候选人简历的纯文本内容包含教育背景、工作经历、技能列表”。这一步的意义是让模型知道你喂进来的内容是什么不是垃圾数据。步骤 2添加 LLM 节点配置便宜模型在画布上拖入一个 LLM 节点模型选择“DeepSeek”你也可以填自己的 DeepSeek API Key。如果 Dify 自带的模型列表里没有你可以在设置里添加模型供应商填 API Key 就行。关键参数我建议这样配temperature 设为 0.2。这是控制随机性的参数值越大回答越发散、越“有创意”值越小越保守、越稳定。筛选简历是判断任务不需要创作0.2 很合适。如果你做文案生成、头脑风暴类任务可以调到 0.8。max tokens 设为 500 左右。简历评估结果通常不会太长限制 max tokens 可以避免模型啰嗦也省成本。把“resume_text”变量引用到 Prompt 里。这一步就是我前面说的“上下文传递”。步骤 3写一份带格式约束的 Prompt先给你看一版我改过多轮后效果不错的 Prompt 模板可以复制到你的 LLM 节点里你是一位资深技术面试官和 HR 专家。你将收到一份候选人简历文本。任务要求评估候选人是否达到初级后端岗位的初筛标准。硬性标准包括至少有 1 年相关开发经验或优秀应届生熟悉至少一门编程语言Java/Python/Go 任一即可学历大专及以上。输出一个严格的 JSON 对象格式如下不要输出任何其他内容不要用 Markdown 代码块包裹 {passed: true/false, score: 0-100 整数, summary: 两到三句话的候选人亮点概括, risks: 一句话指出潜在风险或疑问, interview_questions: [问题1, 问题2]}如果简历信息明显不足passed 输出 false并在 summary 里注明“信息不足需人工复核”。候选人简历 {{resume_text}}为什么要这样写很多人写 Prompt 就一句话“帮我筛一下这份简历”然后开始抱怨模型给的结果不像样。问题出在你没给它框架。上面这个 Prompt 干了三件事给了角色定位、给了判断标准、给了输出格式。模型不是不知道该怎么筛是你根本没告诉它“筛”的尺子在哪里。步骤 4添加条件分支和输出节点LLM 节点输出的 JSON 里有一个 passed 字段理论上可以接一个“条件分支节点”解析 passed 的值为 true 或 false分别走“进入面试轮”和“暂存待定 ”两条路径。实际搭的时候我发现了一个坑Dify 对 JSON 里的字段提取有时会因为输出格式不稳定而失败。所以我加了一个“代码节点”做后处理用正则把 LLM 输出的 JSON 部分提取出来再解析解析失败就自动归入“存疑”分支。这个兜底逻辑非常重要后面我细讲。步骤 5可选接通知如果你用企业微信或飞书可以在分支末尾接一个“消息发送节点”把评估结果推给 HR 群。这一步不是必须的但跑通以后你会觉得特别爽——来了简历群里自动弹评估报告。3.3 成本测算这样跑一次到底花多少钱这是大家最关心的部分。我实测了一版真实费用不做理论估算给你看实际数字。一份比较详细的简历贴成纯文本之后大约 800~1200 字。按中文计算大概是 800~1500 个 token。加上我上面那套 Prompt 模板系统指令大约占 300 个 token。所以每次调用总输入大约 1800 个 token输出大约 300~500 个 token。用 DeepSeek 的价格来算输入1800 tokens × 1元/百万 tokens ≈ 0.0018 元输出400 tokens × 2元/百万 tokens ≈ 0.0008 元单份简历总成本约 0.003 元也就是说筛选 1000 份简历成本大约是 3 块钱。你要想升级成某个旗舰模型来干这活同样的业务量费用分分钟是几百上千倍的差距但这个活的门槛根本不到需要旗舰模型出手的程度。你说值不值这还没算时间成本。以前 HR 一份简历看过加记录至少 3 分钟100 份就是 5 个小时。现在 Agent 跑完加上人工抽检半小时内结束战斗。这就是低成本工作流的意义——用最小的钱把机械劳动替换掉。4. 本地部署低配电脑也能跑模型说到这里你可能要问既然 API 这么便宜为什么还要折腾本地部署我的回答是本地部署不是省钱用的是保隐私和保命用的。有些数据不能出内网有些业务流程就发生在没有网络的车间里这时候你就需要本地模型。而且本地模型配上低显存的量化方案真的没有你想象中那么遥不可及。4.1 低显存跑模型的量化原理很多人的第一反应是“跑模型不是得几万块的显卡吗”那是“满血旗舰模型”的世界。你的日常任务只需要 7B70 亿参数左右的小模型对显存的需求远没有那么高前提是你得用对量化格式。量化怎么理解你把大模型想象成一本像素极高的摄影画册一张照片几百 MB这对应“全精度模型”。而 4-bit 量化相当于把画册压缩成了清晰度低一些但完全可读的版本——肉眼远看没差别文件体积却小了一个数量级。常见的量化等级对应关系如下量化格式相对体积约效果表现适合场景fp16 / bf16100%最好显存充裕、追求巅峰效果q8_055%几乎无损显存稍紧、质量优先q5_k_m45%损失小大多数人的最佳平衡点q4_k_m35%轻微损失低显存主流选择q2_k25%明显变笨极度紧急不推荐拿一个 7B 模型举例全精度大约需要 14GB 显存。用 q4_k_m 量化之后模型文件大约 4.4GB再加上运行时上下文占用的显存8GB 显存、甚至 6GB 显存都能勉强跑起来。你要是没有独立显卡用 32GB 内存的 CPU“硬跑”也能跑只是慢一些一份短文档的推理可能要几秒到十几秒但对于非实时的任务场景完全够用。4.2 Ollama一条命令搞定本地模型本地部署最省心的方案目前就是 Ollama。它是一个极简的模型运行器把下载模型、加载模型、提供 API 这几件事封装成了几个命令。我当时的做法是安装完 Ollama 之后打开终端执行ollama pull qwen2.5:7b这会把阿里的 Qwen2.5 7B 模型拉到本地。想用量化版的模型也可以拉ollama pull qwen2.5:7b-q4_K_M模型拉取完成后只需要一条命令启动本地 API 服务ollama serve默认端口是 11434。这个服务提供了和 OpenAI 兼容的接口格式所以你可以在 Dify 或是任何支持 OpenAI API 格式的工具里直接把 Base URL 填成http://localhost:11434/v1模型名填qwen2.5:7b工作流里的 LLM 节点就能指向本地模型了。我当时真就这么做过把简历初筛 Agent 的 LLM 节点从 DeepSeek 切换到了本地的 Qwen2.5 7B跑了一批真实简历对比。结果让我有点意外硬性条件判断做得有模有样复杂一点的“风险识别”就差些意思。这也正常7B 的推理能力天花板摆在那里。4.3 本地模型的局限与取舍那是不是所有人都应该本地部署不是。我踩过坑后给你一个非常实用的决策原则什么时候用本地模型数据敏感绝对不能出内网、离线环境可用、任务简单重复关键词提取、文本分类、格式转换、高频低复杂度。什么时候不要用本地模型任务涉及复杂推理、长文本理解、创意生成、需要精确遵循很长的指令时7B 模型很容易露怯。这时候即使贵一点也该调用线上 API。还有一个很实用的混合架构思路工作流先让本地小模型做预处理比如判断这条数据是否敏感、是否属于简单分类如果是简单任务本地模型直接处理到底如果识别出是高难度任务再把它转发给云端强模型。等于把 80% 的廉价劳动留在本地把 20% 的疑难杂症交给专业外援整体成本和效果达到一个很舒服的平衡。5. 常见问题与排查技巧实录搭工作流这事90% 的时间不是在建流程而是在调 bug。我把这几个月遇到频率最高、最有代表性的问题整理成速查表你碰到类似情况可以直接照着查。5.1 模型“输出格式不稳定”怎么办现象你让模型输出严格 JSON它非要给你夹带解释文字、前言和后记甚至用 Markdown 代码块包起来。Dify 解析节点直接报错整个工作流中断。排查思路和解决办法先硬约束后软约束在系统 Prompt 里写明“不要输出任何其他内容不要使用 Markdown 代码块”同时给出一条 JSON 示例。这能解决 80% 的情况。加解析兜底用代码节点处理模型输出用正则把 JSON 提取出来。JSON 可能被包裹在杂讯里正则可以直接找到第一个 “{” 到最后一个 “}” 之间的部分再解析。开结构化输出Dify 和较新的模型 API 都有结构化输出JSON Mode功能在节点里打开模型就会被限制只能输出合法 JSON格式稳定度大幅提升。经验之谈不要指望模型永远不犯错。工作流设计上必须假设“输出可能不干净”代码节点兜底是标配。我见过很多新人的工作流脆弱到只要模型换了个标点就断裂加一层兜底全好了。5.2 API Key 泄露和费用失控如何防现象明明没怎么用账户余额却在掉或者某天突然提醒你欠费了。原因基本是这几类API Key 泄露出去被人盗刷Prompt 设计得太啰嗦导致每次都消耗巨量 token工作流里有死循环或者并发过高比如某个定时任务每小时跑一次每次批量处理大量数据。我的防翻车四件套API Key 只配置在后端环境变量里绝不写进前端或公开仓库。在模型供应商后台设置“月度消费限额”比如先设 50 元跑稳了再往上涨。工作流里对批量任务做“分批延时”避免一次并发几十上百个请求。有专门的日志节点记录每次调用的输入、输出 token 数定期查一次账本。5.3 上下文窗口溢出和前文丢失现象处理很长的一篇文档时模型越到后面越“失忆”或者直接在中间报错“context length exceeded”。原因很好理解模型每一次调用的上下文长度有上限比如 8K、32K、128K。你一股脑把整篇文章塞进去token 数量超过上限就会报错即使不超过模型的长文本注意力也会随长度衰减。处理长文档我推荐分块方案先按一定字符数把文档切成多个片段每个片段分别送入模型处理提取摘要/关键信息最后再让模型基于所有摘要做一次汇总。这相当于让模型先通读各章再开总结会。Dify 和 Coze 里都有“知识库”组件底层就是帮你做切分、向量化、再检索相关片段比手动拼 Prompt 省力得多。5.4 模型幻觉导致业务结果离谱现象筛选简历时把不存在的公司名编成了“知名互联网公司”分析文档时言之凿凿地说出原文里根本没有的结论。模型幻觉无法根除只能从流程上进行约束。我给这个“简历筛选 Agent”加了一套校验逻辑在代码节点里解析出候选人原始简历中的关键实体公司、时间、技能让 LLM 生成的 summary 必须引用这些实体如果引用了未出现的实体则打回重新生成一轮。你可以理解为“让模型自己给自己做证据链核验”。更重要的人机协同原则是AI 做初筛人做终审。尤其涉及招聘、财务、医疗这类不能开玩笑的领域永远留一个“人工复核节点”。这不是保守这是基本职业素养。写在最后的话回看这几个月搭工作流的经历我最深的体会是真正难的不是模型而是“把模糊的需求翻译成固定的流程”。模型从贵的换到便宜的效果反而没什么差别差别全在 Prompt 怎么写、分支怎么设、兜底怎么加、上下文怎么传。所以别急着买贵模型也别急着下单大显卡。先用你手头免费或几块钱就能跑起来的工具把一个真实的小场景打通让 AI 真正顶上一个岗位的活再决定要不要升级装备。最后再分享一个小技巧任何工作流里都建议加一个“人在回路”的确认节点。AI 跑一百次可能一百次都顺利但只要有一次出了离谱结果可能就够你受的。加一个确认步骤不是不信任 AI而是对自己的业务负责。工作流的意义不是取代人是把人从重复劳动里解放出来去做更有判断力的事。等你把第一个工作流跑通你会发现原来 AI 离普通人的生活就这么近。 普通人低成本搭建AI Agent工作流：模型选型与避坑实战指南
先说结论普通人要搭一个能用的 AI Agent 工作流真的不用一开始就买 GPT-4、Claude 这类贵模型。用 DeepSeek、Qwen 这类便宜大碗的模型配合 Coze、Dify、n8n 这类编排工具几百块预算就能跑通一整套自动化流程甚至本地部署用不上 GPU 也能搞定一部分。这篇内容就是给你捋清楚“为什么要这么做、工具怎么选、具体怎么搭、会遇到什么坑”我从零到一做了几个月的 AI Agent 工作流把踩过的和验证过的经验都写下来。适合想用 AI 处理日常事务、正在犹豫要不要买贵的 API、或者只是想在家里搞点自动化小项目的普通人。1. 别急着下单先搞清楚 Agent、LLM、模型到底是不是一回事很多人被 AI Agent 这个词唬住了觉得它一定是什么高深不可攀的东西再加上“大模型”天天上热搜一上来就想买最贵的。但你连三者关系都没弄清楚花多少钱都是打水漂。1.1 三者的关系模型是引擎LLM 是大脑Agent 是会干活的机器人先给小白打个比方。模型就像一台发动机它本身不装在任何车上只是提供动力。LLM大语言模型是那种特别会“理解语言、组织语言”的发动机DeepSeek、Qwen、Llama 都属于这个范畴你要问 DeepSeek 属于哪一类它就是 LLM不是 Agent也不是什么单独的神秘存在。那 Agent 是什么呢Agent 是“发动机方向盘传感器控制逻辑”打包好的一辆车甚至可以说是一个会自己开车的司机。它能感知输入能推理判断能调用工具能执行动作能根据结果调整下一步。比如你让它“帮我整理这封邮件提取待办事项然后写一封回复草稿”它不只是生成文字而是拆解这个任务、用模型理解邮件、调日历或邮件工具、最后产出结果。明白了吗很多人以为买了最强模型就等于有了最强 Agent这就像说买了顶配发动机就等于有了无人驾驶汽车一样缺了中间那一大套东西。而大多数普通人的需求根本用不到顶配发动机——一台经济型发动机加一套好的车身控制逻辑反而更实用。1.2 为什么“先别急着买贵模型”是普通人的第一原则我在搭建工作流之前先做了一次成本测试。同样让模型做“提取会议纪要里的行动项并输出为结构化表格”这个任务用几款模型各跑了一次模型输入价格约输出价格约单次任务消耗约单次成本DeepSeek API1元/百万 tokens2元/百万 tokens1500 tokens0.002元左右某国际旗舰模型60元/百万 tokens240元/百万 tokens1500 tokens0.18元左右某次旗舰模型20元/百万 tokens80元/百万 tokens1500 tokens0.06元左右同样是“提取行动项”这种轻量任务贵模型的价格是便宜模型的几十倍但结果质量差距微乎其微。因为这类任务拼的是指令遵循能力不是世界知识储量。便宜的 DeepSeek 在结构化输出、工具调用上已经做得相当好那何必多花钱呢。但这还不是最重要的。最重要的原因在于——你先要用低成本试错。工作流的坑不在模型而在流程设计。你的输入格式会不会变、中间要不要加判断分支、输出要不要接进通知工具、并发会不会触发限流……这些问题只有在跑起来以后才会暴露。你要是咬牙买了贵模型再开始搭等于在练手阶段就给自己烧钱上压力很多人就是这样被劝退的。我个人的建议是第一步全部用便宜模型搭通流程确认业务真的跑顺了、有增量价值了再考虑升级旗舰模型对比效果。有句话叫“先弄脏手再买好工具”放在 AI Agent 上尤其适合。2. 低成本工作流的三条路线Coze、Dify、n8n 怎么选模型选完了下面挑工作流编排工具。这个选择直接决定你是轻轻松松拖拽完成还是被各类节点配置折磨到怀疑人生。2.1 不同段位的人选不同工具市面上的工作流工具其实就三类我试过之后给它们的定位是零代码玩具、半代码平台、全代码自动化。工具适合人群门槛典型能力我的评价Coze扣子完全不会写代码的人很低拖拽搭 Bot、内置大量插件、一键发布到飞书/公众号/微信最适合练手但自定义能力有限重度需求会撞墙Dify愿意碰一点点代码和 API 的人中等可视化编排、知识库、支持私有化部署、模型可自行配置最均衡我日常主力n8n有代码基础、想自动化复杂业务的人较高集成数百个应用、支持代码节点、完全自托管真正的生产力工具但学习曲线陡给普通人的结论很直接如果你是纯小白先玩 Coze半小时就能搭出第一个 Agent如果你想做点正经工作流想接入自己的 API Key想控制成本细节那就直接上 Dify。n8n 更适合已经有明确业务流程、想把 AI 嵌入 CRM、表单、邮件系统的人。顺带一提如果你用过 ComfyUI 搭 AI 绘画的图生图工作流你在 Dify、Coze 里会有一种似曾相识的感觉——一样的节点式连线、一样的模型选择、一样的输入输出链路。底层思维都是相通的把 AI 当成流水线里的一个工序前一步的输出作为后一步的输入。2.2 工作流的核心要素节点、连线、上下文不管用哪个工具工作流的本质都一样——工厂流水线。原始材料从一端进来经过若干个工位每个工位完成一个动作最后从另一端产出成品。我把几个核心节点给你拆开看输入节点工作流的“原料入口”。可以是用户对话框、一个表单、一个网页触发也可以是从邮件、数据库、API 推送过来的数据。输入节点的核心是定义好字段不然下一步模型根本不知道你在说什么。LLM 节点真正的“大脑工位”。这里选择模型、写 Prompt、设置参数。整条工作流的智能程度都取决于这个节点的配置。工具节点模型的“手脚”。模型本身不能发邮件、不能查天气、不能查询数据库但通过工具节点你可以让模型调用外部 API。Dify 和 Coze 都内置了大量现成工具也可以自定义 API 工具。分支节点流水线的“分拣员”。根据模型输出的判断结果决定走哪条路。比如“如果这条评论是负面情绪进入安抚流程否则进入统计流程”。输出节点成品出口。可以返回一段文本、写入数据库、发送到飞书/企微/邮件也可以触发下一个工作流。最容易被忽略的是“上下文”。模型不是仓库管理员它每次调用只看得见你递给它的内容记住你设置的常量、变量和系统指令——就像流水线上的工人只看得到眼前这张工单一样。所以你要主动把上游节点的输出以变量的形式传递到 LLM 节点的 Prompt 里。这一步新手十有八九会漏掉结果就是模型“失忆”答非所问。有了这个基础理解下面我就以 Dify 为例带你完整搭一个简历筛选 Agent从需求拆解到 Prompt 编写到成本测算一次走完。3. 从 0 到 1 搭一个“简历筛选 Agent”的完整实操为什么要选“简历筛选”这个例子因为它太典型了。需求清晰、输入输出明确、有判断逻辑、有实际价值而且任何人看完都能立刻类推到自己手头的场景上——筛选商品评论、筛选工单、筛选问卷答案本质都一样。3.1 场景选择和需求拆解我先说我当时的需求团队每周收到几十份简历初级岗位尤其多HR 忙不过来。我想让 Agent 先做第一轮初筛把明显不合适的筛掉同时给面试官提供候选人的亮点摘要和提问建议。需求拆解成一句话就是给一段简历文字输出三个值——是否通过初筛、评分0-100、推荐理由和面试提问建议。你可能觉得这就完了不真正的需求拆解要细得多。我当时列了一个问题清单简历是纯文本还是 PDF初始阶段先让用户粘贴纯文本PDF 解析属于扩张功能不要第一步就做。“通过初筛”的标准是什么我要把硬性条件写清楚。比如“必须具备 2 年以上后端经验”这种否则模型会按自己的理解瞎判断。输出格式是什么我要求 JSON 结构化输出因为后续要接人处理JSON 方便程序解析。处理不了怎么办比如简历太短、乱码、信息严重缺失要有一个“存疑”分类而不是硬着头皮评分。需求拆解得越细后面写 Prompt 越容易。很多人搭工作流失败不是因为技术而是需求根本没想清楚。3.2 具体配置步骤含 Prompt 模板下面按 Dify 的实际操作顺序说你在 Coze 里也能找到差不多的节点只是名字略有不同。步骤 1新建空白工作流定义输入字段我建了一个名为“简历初筛 Agent”的工作流添加了一个文本类型的输入字段命名为“resume_text”描述写清楚“请粘贴候选人简历的纯文本内容包含教育背景、工作经历、技能列表”。这一步的意义是让模型知道你喂进来的内容是什么不是垃圾数据。步骤 2添加 LLM 节点配置便宜模型在画布上拖入一个 LLM 节点模型选择“DeepSeek”你也可以填自己的 DeepSeek API Key。如果 Dify 自带的模型列表里没有你可以在设置里添加模型供应商填 API Key 就行。关键参数我建议这样配temperature 设为 0.2。这是控制随机性的参数值越大回答越发散、越“有创意”值越小越保守、越稳定。筛选简历是判断任务不需要创作0.2 很合适。如果你做文案生成、头脑风暴类任务可以调到 0.8。max tokens 设为 500 左右。简历评估结果通常不会太长限制 max tokens 可以避免模型啰嗦也省成本。把“resume_text”变量引用到 Prompt 里。这一步就是我前面说的“上下文传递”。步骤 3写一份带格式约束的 Prompt先给你看一版我改过多轮后效果不错的 Prompt 模板可以复制到你的 LLM 节点里你是一位资深技术面试官和 HR 专家。你将收到一份候选人简历文本。任务要求评估候选人是否达到初级后端岗位的初筛标准。硬性标准包括至少有 1 年相关开发经验或优秀应届生熟悉至少一门编程语言Java/Python/Go 任一即可学历大专及以上。输出一个严格的 JSON 对象格式如下不要输出任何其他内容不要用 Markdown 代码块包裹 {passed: true/false, score: 0-100 整数, summary: 两到三句话的候选人亮点概括, risks: 一句话指出潜在风险或疑问, interview_questions: [问题1, 问题2]}如果简历信息明显不足passed 输出 false并在 summary 里注明“信息不足需人工复核”。候选人简历 {{resume_text}}为什么要这样写很多人写 Prompt 就一句话“帮我筛一下这份简历”然后开始抱怨模型给的结果不像样。问题出在你没给它框架。上面这个 Prompt 干了三件事给了角色定位、给了判断标准、给了输出格式。模型不是不知道该怎么筛是你根本没告诉它“筛”的尺子在哪里。步骤 4添加条件分支和输出节点LLM 节点输出的 JSON 里有一个 passed 字段理论上可以接一个“条件分支节点”解析 passed 的值为 true 或 false分别走“进入面试轮”和“暂存待定 ”两条路径。实际搭的时候我发现了一个坑Dify 对 JSON 里的字段提取有时会因为输出格式不稳定而失败。所以我加了一个“代码节点”做后处理用正则把 LLM 输出的 JSON 部分提取出来再解析解析失败就自动归入“存疑”分支。这个兜底逻辑非常重要后面我细讲。步骤 5可选接通知如果你用企业微信或飞书可以在分支末尾接一个“消息发送节点”把评估结果推给 HR 群。这一步不是必须的但跑通以后你会觉得特别爽——来了简历群里自动弹评估报告。3.3 成本测算这样跑一次到底花多少钱这是大家最关心的部分。我实测了一版真实费用不做理论估算给你看实际数字。一份比较详细的简历贴成纯文本之后大约 800~1200 字。按中文计算大概是 800~1500 个 token。加上我上面那套 Prompt 模板系统指令大约占 300 个 token。所以每次调用总输入大约 1800 个 token输出大约 300~500 个 token。用 DeepSeek 的价格来算输入1800 tokens × 1元/百万 tokens ≈ 0.0018 元输出400 tokens × 2元/百万 tokens ≈ 0.0008 元单份简历总成本约 0.003 元也就是说筛选 1000 份简历成本大约是 3 块钱。你要想升级成某个旗舰模型来干这活同样的业务量费用分分钟是几百上千倍的差距但这个活的门槛根本不到需要旗舰模型出手的程度。你说值不值这还没算时间成本。以前 HR 一份简历看过加记录至少 3 分钟100 份就是 5 个小时。现在 Agent 跑完加上人工抽检半小时内结束战斗。这就是低成本工作流的意义——用最小的钱把机械劳动替换掉。4. 本地部署低配电脑也能跑模型说到这里你可能要问既然 API 这么便宜为什么还要折腾本地部署我的回答是本地部署不是省钱用的是保隐私和保命用的。有些数据不能出内网有些业务流程就发生在没有网络的车间里这时候你就需要本地模型。而且本地模型配上低显存的量化方案真的没有你想象中那么遥不可及。4.1 低显存跑模型的量化原理很多人的第一反应是“跑模型不是得几万块的显卡吗”那是“满血旗舰模型”的世界。你的日常任务只需要 7B70 亿参数左右的小模型对显存的需求远没有那么高前提是你得用对量化格式。量化怎么理解你把大模型想象成一本像素极高的摄影画册一张照片几百 MB这对应“全精度模型”。而 4-bit 量化相当于把画册压缩成了清晰度低一些但完全可读的版本——肉眼远看没差别文件体积却小了一个数量级。常见的量化等级对应关系如下量化格式相对体积约效果表现适合场景fp16 / bf16100%最好显存充裕、追求巅峰效果q8_055%几乎无损显存稍紧、质量优先q5_k_m45%损失小大多数人的最佳平衡点q4_k_m35%轻微损失低显存主流选择q2_k25%明显变笨极度紧急不推荐拿一个 7B 模型举例全精度大约需要 14GB 显存。用 q4_k_m 量化之后模型文件大约 4.4GB再加上运行时上下文占用的显存8GB 显存、甚至 6GB 显存都能勉强跑起来。你要是没有独立显卡用 32GB 内存的 CPU“硬跑”也能跑只是慢一些一份短文档的推理可能要几秒到十几秒但对于非实时的任务场景完全够用。4.2 Ollama一条命令搞定本地模型本地部署最省心的方案目前就是 Ollama。它是一个极简的模型运行器把下载模型、加载模型、提供 API 这几件事封装成了几个命令。我当时的做法是安装完 Ollama 之后打开终端执行ollama pull qwen2.5:7b这会把阿里的 Qwen2.5 7B 模型拉到本地。想用量化版的模型也可以拉ollama pull qwen2.5:7b-q4_K_M模型拉取完成后只需要一条命令启动本地 API 服务ollama serve默认端口是 11434。这个服务提供了和 OpenAI 兼容的接口格式所以你可以在 Dify 或是任何支持 OpenAI API 格式的工具里直接把 Base URL 填成http://localhost:11434/v1模型名填qwen2.5:7b工作流里的 LLM 节点就能指向本地模型了。我当时真就这么做过把简历初筛 Agent 的 LLM 节点从 DeepSeek 切换到了本地的 Qwen2.5 7B跑了一批真实简历对比。结果让我有点意外硬性条件判断做得有模有样复杂一点的“风险识别”就差些意思。这也正常7B 的推理能力天花板摆在那里。4.3 本地模型的局限与取舍那是不是所有人都应该本地部署不是。我踩过坑后给你一个非常实用的决策原则什么时候用本地模型数据敏感绝对不能出内网、离线环境可用、任务简单重复关键词提取、文本分类、格式转换、高频低复杂度。什么时候不要用本地模型任务涉及复杂推理、长文本理解、创意生成、需要精确遵循很长的指令时7B 模型很容易露怯。这时候即使贵一点也该调用线上 API。还有一个很实用的混合架构思路工作流先让本地小模型做预处理比如判断这条数据是否敏感、是否属于简单分类如果是简单任务本地模型直接处理到底如果识别出是高难度任务再把它转发给云端强模型。等于把 80% 的廉价劳动留在本地把 20% 的疑难杂症交给专业外援整体成本和效果达到一个很舒服的平衡。5. 常见问题与排查技巧实录搭工作流这事90% 的时间不是在建流程而是在调 bug。我把这几个月遇到频率最高、最有代表性的问题整理成速查表你碰到类似情况可以直接照着查。5.1 模型“输出格式不稳定”怎么办现象你让模型输出严格 JSON它非要给你夹带解释文字、前言和后记甚至用 Markdown 代码块包起来。Dify 解析节点直接报错整个工作流中断。排查思路和解决办法先硬约束后软约束在系统 Prompt 里写明“不要输出任何其他内容不要使用 Markdown 代码块”同时给出一条 JSON 示例。这能解决 80% 的情况。加解析兜底用代码节点处理模型输出用正则把 JSON 提取出来。JSON 可能被包裹在杂讯里正则可以直接找到第一个 “{” 到最后一个 “}” 之间的部分再解析。开结构化输出Dify 和较新的模型 API 都有结构化输出JSON Mode功能在节点里打开模型就会被限制只能输出合法 JSON格式稳定度大幅提升。经验之谈不要指望模型永远不犯错。工作流设计上必须假设“输出可能不干净”代码节点兜底是标配。我见过很多新人的工作流脆弱到只要模型换了个标点就断裂加一层兜底全好了。5.2 API Key 泄露和费用失控如何防现象明明没怎么用账户余额却在掉或者某天突然提醒你欠费了。原因基本是这几类API Key 泄露出去被人盗刷Prompt 设计得太啰嗦导致每次都消耗巨量 token工作流里有死循环或者并发过高比如某个定时任务每小时跑一次每次批量处理大量数据。我的防翻车四件套API Key 只配置在后端环境变量里绝不写进前端或公开仓库。在模型供应商后台设置“月度消费限额”比如先设 50 元跑稳了再往上涨。工作流里对批量任务做“分批延时”避免一次并发几十上百个请求。有专门的日志节点记录每次调用的输入、输出 token 数定期查一次账本。5.3 上下文窗口溢出和前文丢失现象处理很长的一篇文档时模型越到后面越“失忆”或者直接在中间报错“context length exceeded”。原因很好理解模型每一次调用的上下文长度有上限比如 8K、32K、128K。你一股脑把整篇文章塞进去token 数量超过上限就会报错即使不超过模型的长文本注意力也会随长度衰减。处理长文档我推荐分块方案先按一定字符数把文档切成多个片段每个片段分别送入模型处理提取摘要/关键信息最后再让模型基于所有摘要做一次汇总。这相当于让模型先通读各章再开总结会。Dify 和 Coze 里都有“知识库”组件底层就是帮你做切分、向量化、再检索相关片段比手动拼 Prompt 省力得多。5.4 模型幻觉导致业务结果离谱现象筛选简历时把不存在的公司名编成了“知名互联网公司”分析文档时言之凿凿地说出原文里根本没有的结论。模型幻觉无法根除只能从流程上进行约束。我给这个“简历筛选 Agent”加了一套校验逻辑在代码节点里解析出候选人原始简历中的关键实体公司、时间、技能让 LLM 生成的 summary 必须引用这些实体如果引用了未出现的实体则打回重新生成一轮。你可以理解为“让模型自己给自己做证据链核验”。更重要的人机协同原则是AI 做初筛人做终审。尤其涉及招聘、财务、医疗这类不能开玩笑的领域永远留一个“人工复核节点”。这不是保守这是基本职业素养。写在最后的话回看这几个月搭工作流的经历我最深的体会是真正难的不是模型而是“把模糊的需求翻译成固定的流程”。模型从贵的换到便宜的效果反而没什么差别差别全在 Prompt 怎么写、分支怎么设、兜底怎么加、上下文怎么传。所以别急着买贵模型也别急着下单大显卡。先用你手头免费或几块钱就能跑起来的工具把一个真实的小场景打通让 AI 真正顶上一个岗位的活再决定要不要升级装备。最后再分享一个小技巧任何工作流里都建议加一个“人在回路”的确认节点。AI 跑一百次可能一百次都顺利但只要有一次出了离谱结果可能就够你受的。加一个确认步骤不是不信任 AI而是对自己的业务负责。工作流的意义不是取代人是把人从重复劳动里解放出来去做更有判断力的事。等你把第一个工作流跑通你会发现原来 AI 离普通人的生活就这么近。