本文通过HR简历筛选案例对比分析了Coze/Dify等Workflow平台与AgentSkills两种AI应用开发模式的优劣。Workflow平台流程可见、节点可控、异常易处理适合企业生产环境Skills灵活自然、复用性强但治理难度大。两者本质都是承载业务SOP未来将趋同发展。AI应用竞争的关键在于能否将企业KnowHow转化为可执行的AI系统而非平台选择本身。最近在聊 AI 应用开发平台选择的时候会被高频问到的一个问题Agent 可以通过 Skills 学会一套做事方法那会不会导致Coze、Dify、N8N 这种靠 Workflow 编排的平台死掉这次为了把这个问题说清楚我找一个大家都熟悉的业务场景用两种方式都实现一遍再看它们到底有什么差异。这里我们用 HR 简历筛选为案例假设现在公司有一个需求HR 上传一批简历 系统解析简历内容提取结构化信息 根据岗位拉取评分规则让大模型按标准打分并输出总结 最后把简历信息和评分存储到多维表格中案例虽然简单但是它包含完整业务链路有文件解析、信息提取、模型判断、数据写入、多人协作和后续追踪。既需要 AI 的认知能力也需要系统的执行能力既有灵活判断也有稳定流程下面我们展开来看两种方式的实现路径用 Coze/Dify 会怎么做如果用 Coze、Dify 这类平台来做 HR 简历筛选那肯定是通过拖拉拽节点编排一条 Workflow。这条 Workflow 大概会长这样HR 上传一批简历选择对应岗位判断简历文件类型对 PDF、Word、图片简历做解析提取简历原文从原文中抽取结构化信息根据岗位 ID 拉取评分规则将简历信息和岗位规则一起交给大模型让模型按规则打分并输出总结将候选人信息、评分、总结、风险点写入多维表格返回处理结果给 HR。这就是典型 Workflow 平台的做法他的本质是低代码平台。它会先把任务拆成若干个明确节点再为每个节点配置对应的模型、插件、代码逻辑或接口能力。比如第一个节点是上传简历第二个节点是解析文件第三个节点是结构化抽取第四个节点是拉岗位评分规则第五个节点是模型评分第六个节点是写入多维表格。可以看出这类Workflow平台的核心特征是每个节点的输入和输出都是确定的整体执行流程非常可控我们能看见整个链路运行逻辑、也可以追踪运行日志。并且还能对每个节点做精细控制如果运行过程中出现问题我们能够清晰的定位出是哪一个节点出了问题。比如候选人手机号没写进表格到底是简历解析没提取出来还是结构化字段没映射还是表格字段权限出错Workflow 能很清楚地排查。对于企业而言在真实生产环境更需要的是一套能够长期稳定运行、可维护、可审查的系统。所以从 Coze/Dify 的角度看它追求的是流程看得见节点控得住异常能处理结果能入库权限能管理团队能协作后续能维护。这也是 Workflow 平台的最大价值用 Skills 怎么做现在我们换一种方式用 Skills 的方式来做。这里需要先定义一个 HR 简历筛选 skill把这件事应该怎么做写清楚然后让 Agent 在需要时读取这个 skill再调用相关工具完成任务。用户可以直接对 Agent 说帮我筛选这批 Java 后端岗位的简历 按岗位评分标准打分提取候选人信息 并写入多维表格Agent 接到任务后会先进行意图识别判断这是一个执行型任务需要读取简历文件解析简历内容提取候选人结构化信息拉取岗位评分规则调用大模型评分生成总结写入多维表格。接着它会去匹配相关 skill比如HR 简历筛选 skill这个 skill 可能会这样写name: hr-resume-screening description: 当用户要求批量筛选简历、解析候选人信息、按岗位评分规则打分、生成总结并写入飞书多维表格时使用本 skill。适用于 HR 简历筛选、招聘初筛、候选人评估、岗位匹配、面试推荐和飞书多维表格入库任务。# HR 简历筛选## 使用场景当用户要求“筛选一批简历、按岗位规则评分、写入飞书多维表格”时使用本 skill。不要用于单纯简历润色、求职建议或不涉及候选人评估的任务。## 必要输入- 简历来源文件、文件夹或可访问链接。 - 岗位信息岗位名称或岗位 ID。 - 候选人结果表飞书多维表格链接或app_tokentable_id。 - 岗位规则表默认也是飞书多维表格通过岗位名称或岗位 ID 查询。 - 写入策略权限或字段不明确时先预览再写入。 不要写死飞书 token、app token、table ID、API key 或凭证。优先读取环境变量或用户通过安全方式提供的信息。## 飞书脚本使用scripts/feishu_bitable.py调用飞书多维表格。 凭证读取顺序1. **--tenant-access-token**2. **FEISHU_TENANT_ACCESS_TOKEN**3. **FEISHU_APP_IDFEISHU_APP_SECRET**常用命令python3 scripts/feishu_bitable.py parse-url$BITABLE_URLpython3 scripts/feishu_bitable.py fields --bitable-url$CANDIDATE_TABLE_URLpython3 scripts/feishu_bitable.py search --bitable-url$RULE_TABLE_URL--filter-file rule-filter.json python3 scripts/feishu_bitable.py batch-create --bitable-url$CANDIDATE_TABLE_URL--records-file candidate-records.json python3 scripts/feishu_bitable.py batch-create --bitable-url$CANDIDATE_TABLE_URL--records-file candidate-records.json --dry-runcandidate-records.json可以是字段对象数组也可以是飞书原生{ fields: {...} }结构。执行流程确认上下文简历数量、岗位名称/ID、候选人结果表、岗位规则表。用fields检查候选人结果表字段发现缺字段或类型不匹配时先提示。解析简历PDF/Word 提取文本图片或扫描件在可用时走 OCR解析失败则标记人工复核不编造内容。提取候选人字段姓名、手机号、邮箱、城市、学历、学校、专业、年限、最近公司/职位、核心技能、项目摘要、简历来源、附件链接。用search按岗位名称或岗位 ID 查询评分规则没有规则时停止评分并提示补充规则。按岗位规则评分输出总分、维度分、推荐等级、优势、风险点、关键证据、信息缺失项、建议追问问题。校验输出总分/维度分应为数字模型输出格式错误时重试一次仍失败则标记人工复核。生成candidate-records.json用batch-create --dry-run预览确认后用batch-create写入飞书。返回批处理摘要、候选人结果、飞书写入结果和待人工处理事项。字段映射候选人字段候选人姓名手机号邮箱当前城市最高学历毕业院校专业工作年限最近公司最近职位核心技能项目经历摘要简历来源简历附件链接筛选字段应聘岗位岗位 ID总分维度评分推荐等级候选人优势风险点建议追问问题评分规则版本关键证据信息缺失项处理状态复核原因处理时间推荐取值处理状态已评分、待人工复核、评分规则缺失、解析失败、写入失败。推荐等级强烈推荐、推荐、待定、不推荐。默认分数段仅作展示80 分及以上推荐或强烈推荐60 到 79 分待定60 分以下不推荐岗位规则有阈值时以岗位规则为准。评分原则只按岗位评分规则打分不凭通用印象评分。评分必须给出简短证据不能只给分。不因关键词堆砌给高分要看项目证据、职责和结果。证据不足时明确标记不确定性或待人工复核。不做最终录用决定只提供第一轮筛选辅助。避免歧视性或法律敏感判断只评价岗位相关经历、技能、资质和证据。异常处理简历解析失败处理状态 解析失败或待人工复核保留文件名、附件链接和失败原因。评分规则缺失停止评分报告缺失的岗位名称或岗位 ID。模型输出不合规重试一次仍失败则标记待人工复核。飞书写入失败保留结构化结果报告权限、表格 ID、字段名、字段类型、附件字段或 API 问题。批处理中部分失败继续处理其他简历并分开返回成功、待复核和失败记录。输出格式## 批处理摘要 - 简历总数 - 成功评分 - 已写入飞书 - 待人工复核 - 失败 ## 候选人结果 | 候选人 | 岗位 | 总分 | 推荐等级 | 核心理由 | 处理状态 | | --- | --- | ---: | --- | --- | --- | ## 飞书写入结果 - 成功记录数 - 失败记录数 - 失败原因 ## 需要人工处理 - 规则缺失 - 解析失败 - 字段/权限问题从这个 skill 的实现可以看出这里面其实也是 Workflow只不过是把 Workflow 变成了用自然语言描述把这套业务方法封装成 Agent 可以理解、可以复用的能力包。用户只要启用这个 skillAgent 就知道这件事要按什么逻辑处理孰优孰劣从使用体验上看skill 会比 Workflow 更加灵活。Workflow 的入口通常是先搭好流程再让用户按流程提交任务skill 的入口更像是用户直接交办任务然后 Agent 根据任务内容去匹配合适的方法。比如 HR 临时强调重点看 B 端 SaaS 经验80 分以上推荐面试在 Workflow 里可能要改参数、调规则但在 skill Agent 的模式下Agent 可以先理解这次任务的具体要求再结合 skill 里的做事方法动态执行。但也正因为 Skill 更灵活它的治理难度会更大个人使用时这种灵活性很方便但放到企业生产环境问题就会变复杂评分标准怎么统一执行路径不稳定怎么办简历文件、多维表格、候选人联系方式这些权限怎么控制skill 一旦承载真实业务就不能只看能不能完成任务重点就要回归长期稳定性了而所谓的长期稳定性又要回到 Coze、Dify、AI 表格最核心的特点能不能被审计、被观测、被治理。但是 skill 的优势确实很令人向往灵活、自然、复用性强短板是治理复杂度更高这块需要进一步想办法。其实大家也不用将 Agent Skills 和 Coze/Dify 等 Workflow 低代码平台完全切割开。 因为从本质上看它们其实都在做同一件事承载业务 SOP并让 AI 按照这套 SOP 去执行任务。HR 简历筛选这个案例无论我用 Coze/Dify还是用 Skills最终都要解决这些问题简历怎么解析信息怎么结构化岗位规则从哪里来模型按什么标准打分输出哪些总结结果写到哪里异常怎么处理后续如何协作这些问题不会因为换了实现路径就消失。只不过 Coze/Dify 通过编排功能节点实现Skills 通过自然语言描述实现。但它们底层都在承载业务 SOP这也是很多人容易忽略的点Agent 这类 Skills 体系并不是没有 Workflow它只是把 Workflow 藏进 skill 里了大家应该想想没有 Skills 这套工程机制前Agent 的稳定性是更加糟糕的。比如 HR 简历筛选 skill 里写着先解析简历再提取字段再拉岗位规则再评分再写入多维表格。这是不是 Workflow 吗当然是!所以skill 只不过是 Workflow 的另一种表达方式新瓶装旧酒载体不同了而已。企业怎么选如果是个人使用或者小团队快速验证 Skills 会更有优势。因为它轻、快、灵活交互方式也自然比如一个创业公司 HR只想快速处理一批简历看看哪些候选人值得约面。这个时候用 Skills 可能比搭一整套 Workflow 更快先把业务方法写成 Skills让 Agent 先跑起来再根据结果不断调整。如果放到企业真实生产环境我会更倾向于 Workflow 平台原因也很简单企业生产环境最需要的是系统稳定可控和治理。比如HR 简历筛选在生产环境里会涉及很多严肃问题候选人隐私如何保护简历附件如何存储谁能查看联系方式岗位评分规则谁来维护不同岗位是否使用不同规则模型评分有没有解释依据筛选结果能不能追溯数据是否进入统一系统面试反馈能不能回流规则变更后如何版本管理。这些问题更适合用显性 Workflow 来处理因为 Workflow 更容易被审查也更容易做权限控制、日志记录、异常处理和团队交接。所以我的判断是Skills 不会让 Coze、Dify 这类 Workflow 平台死掉但是会给到它们一些压力这会倒逼 Coze、Dify 这类平台升级并且结合目前 Coze 这边变化来看已经做了很大的变化不再是定位为工作流搭建平台而是通过 AI Coding 的方式来实现 Workflow 的搭建不再需要手动去拖拉拽这些节点来实现流程编排。以后的 Workflow 平台大概率也会往这个方向变化同时也会越来越 Agent 化而 Skills 系统可能也会越来越平台化、可治理化。两边最后会向中间靠拢最重要的是 Knowhow讲到这里我们再更近一步。无论用 Coze/Dify还是用 Agent Skills最终决定 HR 简历筛选效果的都不是工具形态而是岗位评价标准也就是业务 KnowHow。比如高级 Java 后端岗位到底应该怎么打分Java 基础占多少微服务经验占多少高并发经验占多少项目复杂度怎么看简历里只写熟悉 Redis、Kafka但没有项目细节要不要给高分候选人学历一般但项目经历很扎实要不要推荐候选人两年换了三家公司风险怎么计算这些判断标准才是最有价值的。如果没有这套标准Coze/Dify 也只是把流程跑起来Skill 也只是让 Agent 看起来会干活。但如果有了这套标准无论它被写进 Workflow 节点还是被写进 SkillAI 才真正开始承载业务能力。所以我认为AI 应用的竞争表面上是 Workflow、Skills、Agent 的竞争本质上是业务 KnowHow 承载方式的竞争。谁能把企业里的经验、规则、判断标准沉淀下来并让它们在流程里执行、在结果里验证、在反馈里更新谁才有长期价值。结语最后总结一下Workflow、Skills、Agent Runtime本质上都只是 AI 应用的承载层。它们解决的是一件事应该按什么步骤做、什么时候调用模型、什么时候调用工具、结果应该写到哪里、异常应该怎么处理。这些能力很重要但它们还不是 AI 应用最难的部分。真正难的是企业到底有没有一套换句话说今天我们讨论 HR 简历筛选用 Workflow 还是 Skills表面上是工具选择实际上是在回答一个更大的问题你的企业有没有能力把业务 KnowHow 变成可执行、可观测、可迭代的 AI 系统如果没有这个能力换什么平台都只是 Demo。如果有这个能力Coze、Dify、N8N、Skills、Agent Runtime都只是不同阶段的承载层。真正值钱的不是平台而是企业把流程、知识、数据、评价体系持续沉淀下来的能力。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取