1. 从一场Open Day说起为什么“Model Agent Workflow”值得单独拎出来讲网易有道那场AI Open Day周枫抛出的“AI能力竞争正在进入Model Agent Workflow时代”这个判断我在圈子里看到不少人转发。说实话第一眼看到的时候我没太在意因为这两年“XX时代”的说法太多了耳朵都起茧子了。但后来我把这句话拆开结合自己过去一年多折腾Agent项目的经历重新想了一遍发现它其实说中了一个很多人不愿意承认的事实单点模型能力的领先已经很难直接转化成产品体验的领先了。我自己的体感是这样的。2023年那会儿大家比的是谁的模型跑分高、谁的上下文长、谁的中文理解好。到了2024年你会发现一个很尴尬的现象——两个团队用同一个模型API做出来的产品体验能差出十万八千里。一个能帮你把一份财报自动拆成结构化数据、生成图表、再写一段分析另一个只能你问一句它答一句稍微复杂点就胡言乱语。差别在哪不在模型在模型外面那层东西。那层东西就是Agent和Workflow。所以这篇我想聊的不是“有道发布了什么”而是借这个由头把Model、Agent、Workflow这三者到底是什么关系、各自解决什么问题、实际落地时怎么配合掰开揉碎讲清楚。如果你正在做AI应用、正在搭Agent、或者只是想知道为什么自己调API做出来的东西总差点意思这篇应该能给你一些能直接抄的作业。先给个最朴素的类比方便后面展开。把AI应用想象成一家餐厅Model是厨师的厨艺水平。厨艺好菜的上限高。Agent是厨师本人。他得会看菜单、会判断客人要什么、会决定先炒哪个菜、发现盐没了知道去仓库拿。Workflow是后厨的流程规范。谁切菜、谁备料、什么菜先出、什么菜后出、出了问题找谁。厨艺再好的厨师如果后厨流程一团糟出餐照样慢、照样错。反过来流程再顺厨师不会做菜也白搭。这三者是乘法关系不是加法关系。2. Model、Agent、Workflow到底各管什么一次把边界划清楚2.1 Model能力的天花板但不是体验的天花板Model就是大模型本身GPT系列、Claude系列、DeepSeek、Qwen这些。它决定了三件事理解能力、生成能力、推理能力。你给它一段话它能理解到什么程度你让它写东西它能写得多好你让它做逻辑推理它能推多深。但Model有个天然局限它是无状态的。你这次问它“帮我分析这份财报”下次问它“刚才那份财报的第三页讲了什么”它不知道你在说什么。它也没有行动能力它不能自己去查数据库、不能自己发邮件、不能自己调接口。它只能“说”不能“做”。这就是为什么光有Model不够。你调一个再强的模型它本质上还是一个“你问我答”的聊天框。要让它变成能干活的东西必须外面包一层。2.2 Agent让模型从“会说”变成“会做”Agent的核心就一件事给模型装上手脚和记忆。手脚是什么是工具调用Tool Use / Function Calling。模型判断“这个问题我需要查一下数据库”然后它输出一个结构化的调用请求你的代码去执行把结果喂回给模型模型再继续。这一来一回模型就从“只会说”变成了“能做事”。记忆是什么是上下文管理。Agent需要记住之前发生了什么、用户偏好是什么、当前任务进行到哪一步了。这个记忆可以是短期的当前对话也可以是长期的向量数据库里存的历史信息。我自己的经验是Agent最难的地方不是“调工具”而是判断什么时候该调、调哪个、调完怎么用。这其实就是模型推理能力在起作用。模型强判断就准模型弱就会乱调工具、或者该调的时候不调。2.3 Workflow把Agent的“随机应变”变成“可控流程”Agent有个问题它太灵活了。灵活是好事但在生产环境里灵活往往意味着不可控。你让Agent自己决定怎么完成任务它可能这次这么走、下次那么走结果不稳定出了问题也不好排查。Workflow就是来解决这个问题的。它把任务拆成固定的步骤每一步做什么、输入是什么、输出是什么、失败了怎么办全都提前定义好。Agent在每一步里面可以灵活发挥但整体流程是锁死的。举个例子。你要做一个“自动生成周报”的功能纯Agent方案你告诉它“帮我生成周报”它自己去翻聊天记录、翻邮件、翻任务系统然后写出来。灵活但可能漏掉重要信息也可能翻到不该翻的东西。Workflow方案第一步从任务系统拉本周完成的任务第二步从聊天记录里提取关键讨论第三步把前两步的结果喂给模型生成周报草稿第四步人工确认后发送。每一步都是确定的Agent只在第三步里发挥。实际落地的时候大部分靠谱的AI应用都是Workflow为主、Agent为辅。Workflow保证流程可控Agent在关键节点提供智能。2.4 三者的关系一张表说清楚维度ModelAgentWorkflow核心作用提供理解和生成能力让模型能调用工具、有记忆定义任务执行的固定流程解决的问题“能不能听懂、能不能写好”“能不能做事、能不能记住”“能不能稳定、能不能可控”典型形态API调用、本地部署带工具调用的对话循环有向图、状态机、步骤编排失败模式幻觉、理解偏差乱调工具、死循环、跑偏流程僵化、异常处理缺失谁在管模型厂商应用开发者应用开发者/平台这张表我建议你存下来。每次做AI应用卡住的时候对照一下看看是Model的问题、Agent的问题、还是Workflow的问题。大部分时候问题出在后两者但大家习惯性去怪模型。3. 为什么现在才提“Model Agent Workflow”时机到了3.1 模型能力过了及格线瓶颈转移了2023年的时候模型能力是瓶颈。你让它做复杂推理它做不了你让它调工具它调不准。那时候你就算把Agent和Workflow做得再好模型拉胯整体体验也上不去。但现在不一样了。主流模型在理解、生成、工具调用这几个维度上都过了“能用”的及格线。你让一个中等水平的模型去判断“这个问题该不该查数据库”它基本能判断对。你让它根据工具返回的结果继续推理它也能推得下去。瓶颈就从“模型行不行”转移到了“模型外面那层行不行”。这就是为什么现在提Model Agent Workflow而不是一年前。3.2 单点模型能力同质化差异化在应用层还有一个很现实的原因模型能力正在同质化。你用的模型和我用的模型在大部分任务上表现差不多。你跑分高我两分用户根本感知不到。用户能感知到的是什么是“你这个东西能不能帮我把事办了”。而“把事办了”靠的是Agent和Workflow。同样一个模型我把它包成一个能自动整理会议纪要、自动分配任务、自动跟进进度的Agent你把它包成一个聊天框用户体验天差地别。所以竞争的重心必然从Model层转移到Agent和Workflow层。这不是谁的选择是市场规律。3.3 企业落地需要可控性Workflow是刚需我接触过不少想在企业里落地AI的团队他们最担心的不是“模型不够聪明”而是“不可控”。模型胡说八道怎么办调了不该调的接口怎么办流程走到一半卡住了怎么办这些问题纯Agent方案解决不了。你必须用Workflow把流程锁死把异常处理定义清楚把人工确认节点加进去。企业要的不是“智能”是“可靠地智能”。这也是为什么我看到越来越多团队从“纯Agent”转向“Workflow Agent”的混合架构。Workflow负责骨架Agent负责血肉。4. 实操怎么搭一套Model Agent Workflow的架子4.1 第一步选Model别只看跑分选模型这件事我的经验是别只看跑分看你的场景。如果你做的是中文场景的客服、文档处理国产模型在中文理解上往往更接地气。如果你做的是复杂推理、代码生成某些海外模型确实强一些。如果你对数据隐私有要求那就得考虑本地部署。还有一个很多人忽略的点工具调用的稳定性。有些模型跑分很高但工具调用格式经常出错该输出JSON的时候输出一段自然语言你的代码解析不了。这个在实际做Agent的时候是致命的。选模型的时候一定要拿你的真实工具调用场景去测别只看通用跑分。我自己的做法是准备一个“工具调用测试集”包含10到20个典型场景每个场景测“该不该调工具”“调哪个工具”“参数对不对”。跑一遍下来哪个模型能用、哪个不能用一目了然。4.2 第二步设计Agent的工具集和记忆机制Agent的工具集设计有个原则工具要原子化不要大而全。什么叫原子化就是每个工具只做一件事。比如“查订单状态”是一个工具“修改订单地址”是另一个工具“取消订单”是第三个工具。不要做一个“订单管理”工具里面传个action参数决定干什么。为什么因为模型判断“该调哪个工具”比判断“该传什么action参数”容易得多。工具越原子模型调用越准。记忆机制分两层短期记忆当前对话的上下文。这个直接用模型的上下文窗口就行但要注意控制长度太长了会稀释重要信息。长期记忆跨对话的信息。这个一般用向量数据库存需要的时候检索出来塞进上下文。我踩过的一个坑是长期记忆检索出来的东西太多把上下文塞爆了。后来改成先检索、再重排、只取最相关的几条效果好很多。4.3 第三步用Workflow把流程串起来Workflow的编排方式常见的有几种代码编排直接用代码写if-else、循环、状态机。灵活但维护成本高。可视化编排用Dify、Coze这类平台拖拽。上手快但复杂逻辑表达起来费劲。配置化编排用YAML或JSON定义流程。介于两者之间。我的建议是原型阶段用可视化生产阶段用代码或配置化。可视化适合快速验证但一旦流程复杂起来拖拽的图会变成一团乱麻改一个地方牵一发动全身。Workflow设计里最重要的三件事异常处理每一步都要定义失败了怎么办。重试跳过走备用分支终止人工确认节点关键操作发邮件、改数据、付款前面一定要加人工确认。日志和可观测性每一步的输入输出都要记下来出问题的时候能回溯。4.4 一个具体的例子自动会议纪要Agent我拿一个实际做过的项目来串一遍。需求是会议结束后自动生成纪要提取待办事项分配给对应的人并跟进。Model选型中文会议场景选了中文理解好的模型。工具调用稳定性测下来没问题。Agent工具集get_transcript(meeting_id)获取会议转录文本extract_todos(text)从文本提取待办这个其实是模型能力包成工具方便复用assign_todo(todo, person)分配待办send_notification(person, todo)通知负责人Workflow会议结束触发调get_transcript拿转录调extract_todos提取待办对每个待办Agent判断该分配给谁根据历史分配记录和当前上下文人工确认分配结果关键节点调assign_todo和send_notification记录日志设置跟进提醒这个流程里Agent只在第4步发挥判断力其他步骤都是确定的。这样既保证了智能又保证了可控。5. 踩过的坑和排查技巧这些文档里不会写5.1 工具调用格式错误最常见的坑模型该输出JSON的时候输出了一段自然语言或者JSON格式不对你的代码解析不了。这个问题在早期模型上特别常见现在好一些但还是会碰到。排查思路先看模型的原始输出确认是格式问题还是理解问题如果是格式问题在prompt里加few-shot示例明确告诉它输出格式如果还不行考虑用支持结构化输出的模型或者加一层格式校验和重试我的经验在prompt里加一句“如果参数缺失输出空字符串而不是省略字段”能减少很多解析错误。5.2 Agent死循环调工具调上瘾Agent有时候会陷入“调工具-看结果-再调工具”的循环停不下来。常见原因是工具返回的结果没有让模型满意它就一直重试。排查思路设置最大调用次数超过就强制终止检查工具返回的结果是不是模型期望的格式在prompt里明确“如果工具返回结果不理想最多重试一次然后基于现有信息回答”5.3 Workflow卡住异常处理没做好Workflow走到某一步工具调用超时或者返回错误整个流程就卡住了。排查思路每一步都要有超时设置每一步都要有失败分支关键步骤要有重试机制但重试次数要限制我的经验在Workflow设计阶段就画一张“异常处理表”列出每一步可能出的错、对应的处理方式。这个表比流程图还重要。5.4 上下文爆炸记忆检索太多长期记忆检索的时候一下检索出几十条全塞进上下文把窗口撑爆了模型反而抓不住重点。排查思路检索后加一层重排Rerank只取最相关的3到5条对检索结果做摘要而不是原文塞入设置上下文长度上限超了就截断最不相关的5.5 常见问题速查表问题现象可能原因排查方向解决思路工具调用格式错误模型输出不稳定看原始输出加few-shot、用结构化输出Agent死循环工具结果不理想看调用日志设最大次数、加终止条件Workflow卡住异常未处理看卡在哪一步加超时、加失败分支上下文爆炸记忆检索太多看上下文长度加重排、做摘要、设上限分配结果不准模型判断偏差看分配记录加人工确认、补充上下文响应太慢工具调用串行看耗时分布能并行的并行、加缓存6. 这套架构适合谁、不适合谁6.1 适合的场景流程相对固定、但需要智能判断的任务。比如会议纪要、客服工单处理、文档审核、数据录入。这些任务流程是清楚的但中间需要模型的理解和判断能力。对可控性要求高的企业场景。金融、医疗、法律这些领域不能容忍模型胡说八道必须有Workflow兜底。需要多步骤协作的复杂任务。单次模型调用搞不定的需要拆成多步、每步用模型处理一部分的。6.2 不适合的场景纯创意生成。写诗、写小说、头脑风暴这些不需要Workflow直接调模型就行加了流程反而限制发挥。极简的问答。就是简单的“你问我答”没有工具调用、没有多步骤那直接调模型API就够了别过度设计。流程完全不确定的任务。如果任务本身就没法定义清楚步骤那Workflow也编排不出来只能靠Agent硬扛效果往往不好。6.3 一个判断标准我自己的判断标准是如果你能用自然语言把任务步骤写清楚那就用Workflow Agent如果写不清楚那就先别做或者只做纯Agent原型验证。写不清楚步骤说明你对任务本身还没想明白。这时候硬做做出来的东西大概率不可靠。7. 从Open Day看有道的解法一些观察回到有道那场Open Day。周枫提Model Agent Workflow我理解有道的解法大概是这样的Model层有道有自己的模型能力积累特别是在教育场景的中文理解上。这是基本盘。Agent层把模型能力包装成能调用工具、有记忆的Agent。比如在答疑场景里Agent能调用题库、能查知识点、能记住学生的历史问题。Workflow层把教学场景的流程固化下来。比如“诊断-讲解-练习-反馈”这个教学闭环每一步做什么是确定的Agent在每一步里提供智能。这个解法的核心逻辑是用Workflow保证教学流程的科学性用Agent保证个性化用Model保证理解深度。三者缺一不可。我自己的项目虽然不在教育领域但架构思路是相通的。Workflow定骨架Agent填血肉Model提供大脑。这个架构在大部分需要“可靠地智能”的场景里都适用。8. 最后分享几个实操心得第一个心得先做Workflow再加Agent。很多人一上来就想做全自动Agent结果做出来不可控。我的建议是先把流程用Workflow搭起来每个步骤先用规则或简单模型处理跑通了再把需要智能判断的步骤换成Agent。这样风险可控迭代也快。第二个心得工具集宁少勿多。工具越多模型判断该调哪个的难度越大。我见过一个项目有30多个工具模型调用准确率惨不忍睹。后来砍到8个准确率立马上来了。工具不在多在精。第三个心得人工确认节点不是妥协是特性。很多人觉得加人工确认显得AI不够智能。但在企业场景里人工确认是信任的基础。用户知道关键操作有人把关才敢用。而且人工确认的数据可以反过来优化Agent形成正向循环。第四个心得日志比什么都重要。Agent和Workflow出问题的时候没有日志你根本不知道发生了什么。每一步的输入、输出、耗时、状态全都要记。我现在的习惯是日志详细到“模型原始输出”这一层排查问题的时候直接看原始输出比看处理后的结果有用得多。第五个心得别追新追稳。这个领域每天都有新框架、新工具。但生产环境里稳定比新潮重要。我选型的时候优先选文档全、社区活跃、有生产案例的。新东西先在小项目里试验证了再上生产。这套Model Agent Workflow的架构我用了大半年踩了不少坑也总结了不少经验。它不是银弹但在需要“可靠地智能”的场景里是目前我觉得最靠谱的路子。如果你也在做类似的东西希望这些经验能帮你少走点弯路。