搞AI应用开发的同行应该都有个共同感受2024年大家都在聊RAG2025年开始话题全换成了Agent。但真正能把Agent从跑个Demo给你看推到能扛住线上真实流量的团队其实没多少。这期AI Genius第五季第二期请的嘉宾没有讲玄乎的概念反而把Agentic Workflow的工程化路径拆得很细——从模型选型到工具接入从路由设计到兜底评估基本是一条完整的构建链路。我边看边记会后把笔记里跟构建相关的部分单独拎出来结合自己最近在做的几个项目重新整理了一遍。如果你正准备上手Agentic Workflow或者已经在用LangGraph、CrewAI这类框架但总觉得差点意思这篇内容应该对你有用。1. 这期内容到底讲了什么Agentic Workflow不是新瓶装旧酒1.1 从提示词工程到流程即代码的转变以前我们做AI应用核心工作就是调Prompt。一个Prompt解决不了就拆成多个Prompt然后用if-else把它们串起来。这种做法本质上是在做人肉编排——逻辑的走向完全由开发者预先固定LLM扮演的角色只是一个被调用多次的函数每次只负责输出一段文本。Agentic Workflow的思路刚好反过来把决策权交给模型让模型在运行时自己决定下一步调用什么工具、怎么组织已有的信息、什么时候该停下来问用户。这个改变看起来只是架构上的调整实际上对整套开发范式的影响非常深。这期分享花了不小的篇幅讲这个认知转变我特别认同因为我们团队里不少人还停留在提示词越写越长、效果越来越玄的阶段。Prompt不是不重要但在Agentic Workflow里Prompt变成了系统边界说明而不是答案生成器。一个明显的信号是你写的System Prompt里如果还在教模型你应该怎么回答用户大概率还没从传统对话应用里走出来。1.2 编排与自主的边界Workflow和Agent不是二选一嘉宾把Agent和Workflow做了一个非常清晰的区分原话大意是Workflow是预先定义好的路径Agent是模型在运行时动态决策路径。两条路线各有适用场景并不存在谁更高级。举例说明。表单提交的校验逻辑——比如邮箱格式、必填字段、唯一性检查——这类任务就适合用Workflow硬编码每一步都是确定的没有模型介入的必要。但帮用户研究一个陌生行业并输出调研报告这种开放任务就该让Agent自主规划先拆解出行业概况、头部玩家、竞争格局、趋势判断等子问题再选择调用什么搜索工具、按什么顺序阅读结果。很多团队一上来就追求全自主Agent结果效果不可控、成本爆炸、线上事故频发。正确的做法是先想清楚边界哪些环节允许多步推理哪些环节必须走固定流程。这种可控与自主的灰度设计是整期内容里我认为最值钱的一个观点。落到实践上我通常建议把流程分成三层底层确定性操作全部代码化中间层决策点交给LLM最上层才用Agentic Workflow做整体编排。这样即使Agent抽风炸掉的也只是中间层底层数据不会被动到。1.3 为什么现在才值得认真构建Agentic Workflow这里讲的是时机问题。一年前做Agent工具链不成熟模型推理能力也不够很多任务跑起来像无头苍蝇——模型自己都不知道下一步该干嘛。这期分享给出的判断是当主流模型具备了一定的推理和反思能力之后Agent才真的具备实用性现在正好处在模型能力过线、工程化工具开始收敛的窗口期。另一个关键变量是MCPModel Context Protocol这类工具标准的出现。在MCP之前每接一个内部工具都要写一套协议转换做个维基查询工具要写两三百行胶水代码MCP出现之后工具方把能力暴露成统一标准接口Agent框架原生支持接入成本直接下降了一个数量级。这些背景解释了为什么市面上最近几个月冒出来大量Agent产品——不是跟风是基础设施真的够了。如果你还在犹豫要不要投入现在的入场成本比一年前低得多但竞争密度也比一年前高得多。窗口期不会一直开着先跑通一个最小闭环比什么都重要。2. 拆解Agentic Workflow的核心模块模型、工具、记忆、路由与评估2.1 模型层推理能力是地基选型需要分场景模型选型不能只看Benchmark分数更要看在Agent循环里的真实表现。分享里提到一个关键指标工具调用Function Calling的稳定率。有些模型写文章很厉害、对话也很流畅但让它调用工具时容易漏参数、多参数字段、类型搞错导致整个工作流频繁重试体验非常糟糕。建议的做法是准备一套自己的工具调用测试集用真实业务场景里的工具定义跑100次看成功率再决定用哪个模型做底座。这个测试集不需要多复杂最核心的是把生产环境里出现过的工具Schema录进去比如创建工单、查库存、查订单状态这类高频工具。另外还提到了分层部署策略小模型做子任务比如信息抽取、关键词识别、意图粗分类大模型做规划和总结比如任务拆解、工具选择、最终回答生成。这套策略我在实际项目里验证过成本能省40%到60%前提是子任务的边界足够清晰否则小模型会频繁出错。2.2 工具层MCP协议让工具接入标准化的价值工具层是Agentic Workflow能落地的关键。没有工具模型推理能力再强也只是个空谈专家。MCP的价值在于它把工具定义这件事标准化了。工具方只需要实现一个标准接口描述清楚工具能做什么、参数有哪些约束Agent框架就能自动发现和调用。分享里给出了一个经验法则工具定义要小而专一个工具只干一件事描述写清楚它适合解决什么问题、需要注意什么边界不要做一个万能查询工具因为模型对模糊工具的理解和执行都会出问题。我补充一个实际踩过的坑工具描述里的措辞一定要保持中立具体避免使用最佳快速这类形容词。模型不傻但对形容词的理解容易偏差它会倾向于选择描述看起来更厉害的工具而不是更匹配任务的工具。把快速查询用户订单信息改成接受用户ID返回最近90天订单列表含订单号、商品名、金额、状态会精确得多。2.3 记忆层短期上下文与长期记忆的取舍记忆是Agentic Workflow里最容易被低估的模块。很多Demo跑起来效果不错一上生产就失忆——用户前两轮说过的话第三轮模型就忘了。短期记忆本质上是上下文窗口管理。分享里提到Recursive Summarization——对话太长时先让模型把历史总结成摘要再放回上下文避免上下文窗口被原始对话塞满。这套方案的优点是把信息密度做了压缩缺点是摘要会丢失细节。所以更稳的做法是摘要关键原始片段混存批量摘要保留全局脉络关键对话原文单独留档按需取用。长期记忆涉及向量数据库、实体抽取和行为偏好建模。这期没有过度展开向量库而是强调了一个实用原则记忆不是越多越好要设计哪些信息值得记的筛选机制——只记录对后续任务有决策价值的信息比如用户的业务偏好、历史操作习惯、未完成的目标。否则塞进去的全是噪声反而干扰模型判断还增加了每次请求的token消耗。2.4 路由层意图识别与任务分解的设计模式路由是Agentic Workflow的大脑负责决定接下来走哪条路。分享里给出了三种主流路由模式Intent Routing意图路由先让模型判断用户意图属于哪一类再走对应的子流程。适用于意图边界清晰、每个意图对应固定流程的场景。Plan-and-Execute规划-执行先生成步骤计划再逐步执行。适用于多步骤、多工具协作的任务。ReAct循环思考-行动-观察每一步都先思考、再行动、观察结果后决定下一步。适用于需要动态调整策略的任务。三种模式并不互斥实际项目里往往组合使用。比如先做Intent Routing确认用户想干什么再用Plan-and-Execute生成多步骤计划每步执行时用ReAct处理工具返回的意外情况。这个三层组合我在自己的项目里复现过确实比单一模式稳定不少。如果只用ReAct每一步都要模型重新思考一下Token消耗大且路径经常漂移如果只用Plan-and-Execute遇到工具返回意外结果时很难灵活调整。组合之后职责清晰每层只需要做好自己那一件事。2.5 评估层没有评测体系的Agent等于在裸奔这期最后讲了一个很多人忽视的问题你怎么知道你的Agent改好还是改坏了没有评测集和指标就只能靠人工点点点根本谈不上迭代。分享建议即使没有完整的评测平台也至少要建立三样东西Golden Set把过去真实用户里的典型问题收集50到100条覆盖各意图类型和边界情况。自动评估指标任务完成率、平均轮次、工具调用失败率、超时率、无效输出率等。回归机制每次改动都跑一遍Golden Set做对比防止改一个地方坏一片。这个思路是我收获最大的部分之一。我之前做Agent迭代经常是盲改——改了Prompt上线也不知道效果是变好还是变坏只能靠个别用户反馈。后面搭了一个最小评估集情况立刻不一样了。每次改动前先跑基线改完再跑一遍指标上升就留下降就回滚心里踏实非常多。3. 手把手搭一个可运行的Agentic Workflow从需求到落地3.1 选定场景为什么我建议从受限工具集场景练手理论说完了直接进入实操。下面我以一个企业知识库问答工单创建权限检查的客服助手为例带着大家把整个Agentic Workflow跑通。为什么选这个场景因为它有三个非常适合练手的特点工具数量有限只有查知识库、检查用户权限、创建工单三个工具注意力可以集中在编排逻辑上。验收标准清晰用户问知识库问题答得对不对可以直接对照原文判断创建工单字段齐不齐一目了然。包含人工审核环节创建工单是写操作必须走人工确认正好用来练Human-in-the-loop设计。我给新手的建议是不要一上来就做那种工具集特别大、目标特别开放的Agent——比如帮用户完成任何报销流程这种。工具一多模型的工具选择错误率会指数级上升排查问题的时候你会分不清到底是路由错了、工具定义错了还是模型本身不行。3.2 定义工具Schema模型能不能准确选工具全看这一步在Agentic Workflow里工具定义文件Schema是模型在使用工具时的唯一参考。定义得不好再强的模型也会频繁选错工具或传错参数。以创建工单工具为例一个合格的Schema长这样TOOLS [ { type: function, function: { name: create_ticket, description: 创建一条新的客户工单。当用户明确表达需要人工处理、投诉、退款或技术支持时使用。调用前必须确认用户身份和工单类型。, parameters: { type: object, properties: { user_id: { type: string, description: 发起工单的用户ID格式为UA开头8位数字 }, ticket_type: { type: string, enum: [complaint, refund, technical_support, consultation], description: 工单类型必须从枚举值中选择 }, description: { type: string, description: 问题描述需要包含用户原始诉求的关键信息不少于20个字 } }, required: [user_id, ticket_type, description] } } }, # 其他工具定义... ]写工具描述时有个角色代入法想象自己是模型看到一堆工具名和描述能否准确区分并选对如果查知识库和查FAQ两个工具描述相似模型就会随机选一个结果就是效果时好时坏。所以一定要把边界写到像说明书一样清楚——这个工具在什么情况下用、什么情况下不要用、参数有什么约束都要交代明白。另外一个容易踩的细节工具参数的必填项一定要写清楚。如果某个字段有时需要有时不需要建议拆成两个工具而不是把可选逻辑留给模型推断。模型在判断字段是否该填时经常出错尤其是没有明确标注的情况下。3.3 实现路由逻辑用LangGraph做一个可控的Agent工具定义好之后就是Workflow的骨架——路由和状态管理。这里我以LangGraph为例因为它把图的概念做得比较彻底每个节点都是独立函数节点之间通过状态传递信息。核心思路是先做意图路由判断用户想干什么再走对应的子流程。from langgraph.graph import StateGraph, END from typing import TypedDict, Literal class AgentState(TypedDict): user_query: str user_id: str intent: str knowledge_result: str ticket_info: dict need_human_approval: bool def intent_router(state: AgentState) - AgentState: 调用LLM判断用户意图knowledge_base / ticket_creation / general prompt f判断用户问题的意图只能返回以下三类之一 - ticket_creation用户要求开户、投诉、退款、转人工、报障 - knowledge_base用户询问功能、政策、流程等知识性问题 - general以上都不是寒暄或无关问题 用户问题{state[user_query]} # 此处调用你的LLM intent llm_call(prompt).strip() state[intent] intent return state def knowledge_node(state: AgentState) - AgentState: 查知识库工具返回检索结果 state[knowledge_result] search_knowledge_base(state[user_query]) return state def ticket_info_collector(state: AgentState) - AgentState: 从对话中抽取创建工单所需信息 state[ticket_info] extract_ticket_fields(state[user_query], state[user_id]) state[need_human_approval] True return state def route_after_intent(state: AgentState) - Literal[knowledge_node, ticket_info_collector, END]: if state[intent] knowledge_base: return knowledge_node elif state[intent] ticket_creation: return ticket_info_collector else: return END # 构建图 g StateGraph(AgentState) g.add_node(intent_router, intent_router) g.add_node(knowledge_node, knowledge_node) g.add_node(ticket_info_collector, ticket_info_collector) g.set_entry_point(intent_router) g.add_conditional_edges(intent_router, route_after_intent) g.add_edge(knowledge_node, END) g.add_edge(ticket_info_collector, END) app g.compile()这个结构比直接用LangChain的Chain好处在于状态是集中管理的不会在多个链之间传来传去节点是独立的任何一个节点都可以单独调试图的结构让流程的分支一目了然——这就是可控的来源。注意这里我没有让Agent完全自由地决定所有步骤而是先用意图路由锁定方向再走每个方向内相对固定的子流程。这是上生产环境最稳的姿势——自由是逐步放开的不是一开始就放开。3.4 给Workflow加上人工审核闸门Agent不能完全无人值守尤其是涉及写操作的时候。自动创建工单、自动改配置、自动发消息这类动作一旦出错影响就不是一句效果不好能带过的。在设计创建工单流程时我的做法是Agent先把所有需要的信息收集齐生成一个工单草稿然后推送到人工确认界面。人工审核通过后才真正调用工单系统的API。在LangGraph里这个能力叫动态打断。简单说就是在执行到写操作之前让Graph暂停把当前状态导出等外部确认之后再从暂停点继续。# 示例在写入前插入人工审核 # 调用 create_ticket 前先进入 waiting_approval 节点 # 前端展示 ticket_info管理员点确认后恢复执行 from langgraph.types import interrupt def create_ticket_node(state: AgentState) - AgentState: # 先调用中断把工单草稿抛给人工 decision interrupt({ ticket_draft: state[ticket_info], message: 是否确认创建以下工单 }) if decision.get(approved): ticket_id call_ticket_api(state[ticket_info]) state[ticket_id] ticket_id return state这套设计的价值是上线的第一版可以保持读操作自动、写操作人工的保守姿态积累一段时间的数据和信任之后再逐步放开部分高频低风险写操作的自动化。步子迈小一点线上事故就少一点。4. 工具链怎么选LangGraph、CrewAI、AutoGen还是自研4.1 主流框架的适用场景对比这期分享用了不少时间对比主流Agent框架这也是群里讨论最多的一个话题。我做了一张对比表方便大家快速对照自己的需求。框架核心思想适合场景学习曲线主要痛点LangGraph图编排节点边复杂流程控制、需要精细状态管理的生产系统偏高概念多上手慢CrewAI角色化Agent协作多角色多步骤的内容生成任务低复杂分支控制弱AutoGen多Agent对话研究探索、多视角讨论中生产部署复杂Token消耗大自研纯代码编排个性化需求极强、有专门团队维护由团队决定开发维护成本高4.2 我的选择逻辑与理由结合个人经验说我最终把LangGraph作为主力框架。原因有四个第一状态管理是显式的每一次状态更新都有迹可循出问题可以精确回查。这一点在调试阶段节省的时间是惊人的——我这套流程同时用LangGraph和自研各实现过一遍LangGraph在状态流转的可视化上远好于自己写。第二图结构天然支持暂停-恢复适合做人工审核闸门。第三和LangChain生态无缝衔接已有组件可以复用。第四可观测性做得好每一步运行状态都能导出查看这对生产环境的线上问题排查非常关键。但如果只是做一个简单的工具调用增强版助手我反而建议直接自研一个循环不要上框架。因为Agentic Workflow的核心就一个while循环收集信息、调用模型、执行工具、更新状态。在没有多个分支、没有人工审核、没有状态回滚需求的时候框架的重量反而成了负担。4.3 框架解决不了的问题无论选哪个框架都要清楚一件事框架只是脚手架解决不了三类核心问题。模型能力问题是最底层的。推理能力弱的模型什么框架都救不了——它会在路由决策上反复横跳在工具选择上频繁出错。工具质量问题也很关键工具定义模糊、参数约束不清、返回结构混乱再好的编排逻辑也无济于事。评测迭代问题更不必说没有反馈闭环Agent永远停留在偶尔好用的状态。所以选框架要带着我需要在哪个环节获得最大杠杆来判断而不是看哪个社区火就用哪个。框架是给你省事用的不是给你背锅用的。5. 生产环境踩坑实录稳定性、可观测性、成本与安全5.1 最大的坑循环不退出与超时失控Agent自己陷入死循环、一直调用工具不返回这是生产环境遇到的最常见事故没有之一。表现就是用户问了一个问题Agent开始疯狂地查工具、刷新状态、再次查工具迟迟不给最终回答直到超时报错。分享里给出的通用方案是四层防护单步超时每次工具调用设置超时时间比如10秒超过就返回错误。最大轮次上限整个Agent会话最多执行N轮比如6轮超过就强制停止并输出当前进展。重复动作检测检测到同一工具被反复调用且返回结果没有信息增益时强制中断。Token预算兜底设置会话级Token上限超过后自动熔断。我补充一个实际项目里验证有效的做法每轮结束后记录状态变化摘要如果连续多轮状态没有实质性变化就自动触发熔断。比如模型在多轮里都在说让我再查一下用户信息但查到的结果和上一轮一样说明Agent已经迷路了这时候等它自己走出来不如直接中断然后转人工。5.2 成本失控一次Agent对话烧掉上百次调用Agent的Token消耗不是线性增长的是每多一个分支就多一堆Token。分享里讲了一个真实案例某个项目上线后发现单个用户会话平均消耗Token是预估的17倍原因就是模型频繁走错分支、反复重试、输出冗长的中间推理。对策主要集中在四个方面压缩中间步骤要求模型在工具调用之间只输出关键信息摘要不要写大段思考过程。提高路由准确率意图都分错的话后面每一步都在错误的方向上浪费Token。子任务用便宜模型前面提到的分层策略能省非常多。设置会话级Token上限比如单次会话不超过3万Token超过就转人工。这四个对策我实测下来可以省掉一半以上的费用。分享的原话是Agent的Token即成本省Token不是优化问题是存活问题虽然夸张但道理是真的。5.3 可观测性给Agent装一个黑匣子传统应用日志对Agent来说不太够用因为Agent的执行路径是动态的——状态怎么转移、工具怎么调用、Token怎么消耗、模型为什么做这个决策这些都需要记录下来。分享给出的可观测性方案包含四个层次结构化日志每个节点的输入输出都以结构化格式记录方便检索和重放。工具调用明细记录每次工具调用的请求参数与响应摘要最好是完整的请求参数和截断后的响应。Trace树生成一次会话的完整调用链标识哪个节点调用了哪个工具、耗时多少。决策原因记录保存模型在每次路由决策时的理由Reason这是排查问题时最宝贵的信息。我在这个点上吃过亏。有一个线上问题Agent在多个工具之间反复跳转但日志里只有工具名和耗时没有记录模型为什么选这个工具。结果排查了两天最后发现是工具描述里有歧义模型在两个功能相近的工具之间摇摆。如果一开始就记录决策原因这个问题半小时就能定位。5.4 安全与权限Agent能调用不代表该调用安全性是生产环境最容易缺失的一环。Agent作为自动程序如果无限制访问内部系统风险非常大——不是恶意的风险而是模型抽风调了一个不该调的接口这种意外风险。分享里提到最小权限Agent概念Agent启动时获得临时凭证权限范围按任务动态申请审批流贯穿其中。哪怕是读操作也要有IP白名单和审计日志。这套设计在金融、医疗等强合规行业尤其重要。给读者的建议很直接第一版上线强烈建议把所有写操作都走人工确认读操作也要限制范围。比如客服助手的知识库查询只开放指定分类的文档而不是全库查询用户信息只返回当前会话上下文需要的最低字段。宁可多走一步精细化配置也不要让Agent裸奔上生产。6. 从能跑到好用构建Agentic Workflow的三个进阶心法6.1 心法一先有流程再有自主最后才是编排很多团队上来就搭Agent框架工具都没有评测也没有结果一切都在裸奔。我强烈建议的构建顺序是分四步走的第一步先把目标流程手动走一遍记录每一步的输入输出是什么把流程本身搞清楚。第二步把确定性的步骤写成代码这就是一个标准的Workflow不涉及任何模型推理。第三步把需要动态决策的环节替换成LLM调用让模型在特定的决策点发挥作用这是局部Agent化。第四步才用Agentic Workflow把所有模块编排起来形成完整的自主系统。这套顺序的核心优势在于每一步都可验证出问题知道锅在谁那里。如果一上来就直接搭Agentic Workflow模型决策错误、工具调用失败、流程逻辑漏洞混在一起排查成本极大基本无法定位。6.2 心法二Prompt只写行为边界不写具体答案Agent的指令写法跟传统Prompt有本质区别。传统Prompt要写用户问什么你应该怎么回答Agent的System Prompt要写的是你的边界是什么什么情况下必须拒绝什么时候必须求助人工。前者在教话术后者在定规则。分享里举了个例子Agent的System Prompt里写的是如果遇到权限不足立刻停止并请求用户升级权限不要尝试用其他手段绕过。如果你不确定用户的真实意图不要猜测直接向用户确认。这段指令的本质是给模型划定安全边界而不是教它说什么话。我实际试过之后发现这种做法能极大地减少模型自作主张的行为。之前我写的Agent会自己脑补用户指令比如用户问怎么退款它就自动调了退款接口——但用户只是想了解退款政策。把边界写清楚之后这类过度执行的行为明显减少了。6.3 心法三把评估当成一等公民而不是上线前补的作业最后一个心法也是我认为Agentic Workflow能不能持续变好的分水岭——评估。很多人把评估当成上线前补的作业上线之后就再也不看。但Agent是动态系统模型会升级、用户问题会变化、工具接口会调整如果没有持续的评估闭环系统质量就会随之下滑。落地的抓手不需要多复杂最低限度做三件事记录每一个交互样本从第一天开始就把线上真实请求和Agent的响应全部存下来这是最宝贵的语料。每周补充Golden Set从线上样本里挑出有代表性的新情况加入评测集保证评测集和真实分布同步更新。LLM-as-a-judge先粗筛人工再复核先让大模型给每个响应打分排序把明显好和明显差的挑出来人工只审边界模糊的样本效率高得多。这个闭环建立之后Agent质量的提升速度会快得超出你预期。我自己的体会是评估体系建立后的那两周是我做的Agent质量提升最快的阶段比调多少Prompt都管用。因为有了反馈每改一次都知道方向对不对而不是在黑暗里瞎试。这期AI Genius第五季第二期内容密度很高我把笔记和实际项目经验揉在一起的这些内容就是至今仍在用的构建方法论。最后再分享一个小技巧不管用什么框架先把状态流转图画在纸上再写代码这一步省下来的重构时间比你想的多得多。