企业官网建设流程全解析

搞AI应用开发的同行应该都有个共同感受：2024年大家都在聊RAG，2025年开始话题全换成了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才真的具备实用性，现在正好处在"模型能力过线、工程化工具开始收敛"的窗口期。

另一个关键变量是MCP（Model 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框架，这也是群里讨论最多的一个话题。我做了一张对比表，方便大家快速对照自己的需求。

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第五季第二期内容密度很高，我把笔记和实际项目经验揉在一起的这些内容，就是至今仍在用的构建方法论。最后再分享一个小技巧：不管用什么框架，先把"状态流转图"画在纸上再写代码，这一步省下来的重构时间，比你想的多得多。