企业官网建设流程全解析

前言

在大模型应用开发中，Workflow 和 Agent 经常被放在一起讨论。它们都能调用大模型、连接工具并完成任务，因此从最终效果来看，似乎都是“让 AI 干活”。但如果观察任务的执行过程，就会发现两者采用了完全不同的控制方式。

Workflow 更像一条提前设计好的生产流水线：输入从一个节点流向下一个节点，分支条件、执行顺序和异常处理都由开发者预先定义。Agent 则面向一个目标，根据当前环境决定下一步做什么，可能查询资料、调用工具、修改计划，也可能提前结束任务。

Workflow 的核心是预定义流程，Agent 的核心是动态决策。前者优先追求稳定、可控和可复现，后者优先解决路径无法在开发阶段完全确定的问题。

这并不意味着 Workflow 完全没有智能，也不意味着 Agent 可以不受限制地自由行动。一个 Workflow 节点可以调用大模型，一个 Agent 也必须受到工具权限、执行步数和业务规则的约束。理解二者的关键，不是看“有没有调用 LLM”，而是看谁在决定下一步行动。

1. 为什么需要区分 Workflow 和 Agent

传统软件擅长处理规则明确的问题。例如报销审批可以写成“金额小于 5000 元由直属主管审批，否则增加财务审批”；订单系统也可以按照支付、库存、发货等状态依次流转。这类任务的路径在开发阶段已经清楚，使用普通流程引擎就能稳定运行。

大模型出现以后，流程中的某些节点获得了处理非结构化信息的能力，例如总结文本、识别图片、抽取简历字段和生成回复。于是，一个传统流程可以变成 AI Workflow：它的路径仍然由系统规定，只是部分节点由 AI 完成。

然而，旅游规划、复杂检索和故障排查等任务很难事先列出所有步骤。用户的预算、实时天气、机票价格和签证要求会改变下一步动作，开发者无法为每种情况画出完整流程图。这类问题需要系统在运行时观察环境并调整方案，Agent 因此出现。

2. AI Workflow：把智能嵌入固定流程

2.1 Workflow 的本质

Workflow 是一套预先定义的任务编排。它接收输入，让数据按照既定规则经过多个节点，最终产生输出。每个节点通常只负责一种能力，例如调用 LLM、查询数据库、执行条件判断、生成图片或等待人工审核。

一条常见的 AI Workflow 可以表示为：

用户输入 ↓ 参数校验 ↓ 调用 LLM 提取结构化信息 ↓ 条件判断 ── 不满足条件 ──→ 人工处理 ↓ 满足条件 调用图片生成模型 ↓ 内容安全检查 ↓ 返回结果

在 Coze 等可视化平台中，开发者通过拖拽输入、判断、LLM、图片生成和输出节点来构建这种流程。在代码环境中，也可以使用 LangChain 的 Runnable 接口连接不同处理步骤。无论采用图形化界面还是代码，核心思想都相同：节点完成局部工作，边决定数据如何流转。

从图结构看，一个 Workflow 通常由以下元素组成：

• 节点（Node）：执行一次具体操作，是流程的基本工作单元。
• 边（Edge）：连接节点，描述执行顺序和数据流向。
• 状态（State）：保存输入、中间结果、错误信息和最终输出。
• 分支与循环：根据规则选择路径，或在满足条件前重复执行。
• 失败处理：负责重试、降级、超时和人工接管。

这里所说的“固定”是指编排关系固定，不是每个节点的结果都固定。如果某个节点调用了大模型，即使输入相同，输出仍可能受模型版本、上下文和采样参数影响。工程上通常还需要结构化输出、结果校验和低随机性配置来提高稳定性。

2.2 LangChain 中的管道式工作流

LangChain 为 Prompt、模型、输出解析器和工具提供了统一的 Runnable 接口。只要一个组件可以接收输入并返回输出，就能通过pipe()与下一个组件组合。

下面的示例把“主题”依次传给 Prompt 模板、创意模型和字符串解析器：

import"dotenv/config";import{ChatOpenAI}from"@langchain/openai";import{PromptTemplate}from"@langchain/core/prompts";import{StringOutputParser}from"@langchain/core/output_parsers";conststoryPrompt=PromptTemplate.fromTemplate(`请围绕“{topic}”写一个 200 字左右的中文段落。 要求观点明确，包含一个具体应用场景。`);constcreativeModel=newChatOpenAI({// 通过环境变量切换兼容的模型，避免把部署配置写死在业务代码中model:process.env.MODEL_NAME,temperature:0.8,});constoutputParser=newStringOutputParser();constcreativeChain=storyPrompt.pipe(creativeModel).pipe(outputParser);constresult=awaitcreativeChain.invoke({topic:"AI"});console.log(result);

运行示例需要安装以下依赖：

pnpmi dotenv @langchain/core @langchain/openai

这段代码中的每个对象都是一个工作节点。storyPrompt将{ topic: "AI" }转换成模型可以理解的提示词；creativeModel调用大模型并返回消息对象；StringOutputParser再从消息中提取纯文本。invoke()从链的入口启动一次执行，上一个节点的输出会成为下一个节点的输入。

pipe()的含义不是“同时运行”，而是按照连接顺序传递数据。它类似传送带或水管：每一段只处理自己负责的数据，然后把结果交给下一段。

这条链不会在运行时自行插入“搜索资料”或“检查事实”步骤。即使模型认为应该先查询信息，它也没有改变流程的权力。需要新增节点时，必须由开发者修改链条，这正是 Workflow 的控制方式。

2.3 招聘筛选 Workflow 示例

招聘初筛具有明确的输入、处理步骤和输出格式，很适合使用 Workflow。系统可以按照下面的流程处理简历：

PDF 简历 ↓ 解析 PDF 文本 ↓ 提取技能、工作经历、教育经历 ↓ 从岗位知识库检索要求（RAG） ↓ 匹配硬性条件并计算分数 ↓ 排序并生成理由 ↓ 人工复核

第一步负责把 PDF 转成可处理的文本；第二步使用模型或解析规则生成结构化字段；第三步通过 RAG 检索岗位要求，避免只依赖模型记忆；第四步执行企业明确规定的匹配规则；最后输出候选人排名和评分依据，并交由招聘人员复核。

这个流程可能包含条件分支，例如“解析失败则转人工录入”“缺少毕业时间则要求补充材料”。但分支条件仍然由系统预先设计，所以它仍属于 Workflow，而不是 Agent。有判断和循环不等于 Agent，关键在于判断规则由谁制定。

3. Agent：围绕目标动态选择行动

3.1 Agent 的三个核心能力

Agent 接收的通常不是一串完整步骤，而是一个需要完成的目标。为了到达目标，它需要形成“观察、决策、行动、再观察”的闭环。

• 感知环境：理解用户输入、图片、文件、工具列表、历史消息和工具返回结果。
• 规划路径：分析目标并选择下一步行动，必要时拆解子任务、调整顺序或放弃无效方案。
• 执行行动：调用搜索、数据库、代码执行器等工具，把执行结果重新加入上下文，再决定是否继续。

记忆经常被称为 Agent 的另一项能力，但它更准确地说是对状态的管理。短期记忆保存当前任务的消息和工具结果，长期记忆保存跨任务的用户偏好与历史经验。没有可靠的状态，Agent 就无法根据前一步结果调整后续行动。

一个简化的 Agent 循环如下：

constmessages=[userMessage];for(letstep=0;step<MAX_STEPS;step+=1){// 模型不仅生成文字，还可以选择一个已授权工具及其参数constdecision=awaitmodelWithTools.invoke(messages);messages.push(decision);consttoolCalls=decision.tool_calls??[];if(toolCalls.length===0){returndecision.content;// 模型认为信息已经足够，结束任务}for(consttoolCalloftoolCalls){validatePermission(toolCall);// 执行前校验工具、参数和权限constobservation=awaittools[toolCall.name].invoke(toolCall.args);messages.push(toToolMessage(toolCall,observation));}}thrownewError("Agent 超过最大执行步数");

这段代码是用于说明原理的简化伪代码。modelWithTools每轮都能看到目标、历史行动和最新工具结果。如果信息足够，它直接返回答案；如果信息不足，它生成工具调用；工具结果被追加到messages后，模型进入下一轮判断。

Workflow 的下一步通常由代码中的连线决定，而 Agent 的下一步由decision在运行时产生。这是二者最核心的技术差异。

3.2 旅游规划 Agent 示例

假设用户提出：“帮我规划国庆从上海出发的五天旅行，预算 8000 元，希望天气凉爽，不想转机。”这不是一个只靠固定模板就能完成的任务，因为实时价格、天气和用户偏好会共同影响方案。

Agent 可能先搜索符合气候要求的目的地，再查询直飞机票和酒店。如果发现某个目的地机票上涨导致预算超支，它会放弃原方案并查询其他城市；如果目的地临时出现极端天气，它还需要重新规划。另一次执行中，Agent 也可能先检查预算，再缩小目的地范围。

目标：生成满足偏好和预算的五天行程 ↓ 思考：先筛选天气凉爽的候选城市 ↓ 行动：调用天气工具 ↓ 观察：城市 A 有暴雨，城市 B 天气合适 ↓ 思考：检查城市 B 的直飞机票和酒店总价 ↓ 行动：调用机票、酒店工具 ↓ 观察：总价超出预算 ↓ 调整：更换日期或探索城市 C

这种路径无法在开发时完全写死。Agent 的价值正是根据观察结果动态改变下一步。不过，它仍应遵守明确边界：预算不能擅自修改，订票前必须让用户确认，支付工具需要单独授权，搜索轮数也要设置上限。

4. Workflow 与 Agent 的核心区别

4.1 从工程维度进行对比

用一个直观比喻来说，Workflow 像一条路线清晰的高速公路：入口、出口和岔路都提前修好，车辆可以高效到达既定终点。Agent 更像一名知道目的地的司机：它可以根据拥堵、施工和天气调整路线，但必须遵守交通规则、车辆能力和用户要求。

这个比喻强调的是决策方式，而不是能力高低。对于每天重复上万次的发票抽取任务，自主改道并不会带来价值，反而增加成本和风险；对于开放式市场调研，强行画出所有分支又可能让系统极其复杂。

4.2 “确定执行”与“不确定探索”的边界

把 Workflow 概括为“确定的执行”、把 Agent 概括为“不确定的探索”有助于快速入门，但工程实践中需要进一步拆开两种不确定性：

因此，一条包含 LLM 的 Workflow 仍可能生成不同文案，但它始终按照“Prompt → 模型 → 解析器”的顺序执行。相反，一个使用低温模型的 Agent 即使每轮输出很稳定，也仍然可能根据工具观察结果选择不同路径。

判断系统属于哪一种，不要只看它是否使用大模型、是否调用工具，或者是否包含条件判断，而要追问：模型能否根据当前状态自主选择下一项行动？

5. Agent 与 Workflow 如何组合

5.1 用 Workflow 提供骨架，用 Agent 处理开放环节

真实企业应用往往不会在 Workflow 与 Agent 之间二选一，而是组合两者。外层 Workflow 负责稳定的业务阶段、权限和审核，内层 Agent 只处理难以提前定义路径的局部任务。

以招聘系统为例，整体仍然按照固定流程运行，但“补充候选人公开项目背景”可以交给一个受控 Agent：

Workflow：接收简历 ↓ Workflow：解析并脱敏 ↓ Agent：在授权数据源中调研项目经历 ↓ Workflow：校验 Agent 输出格式和证据链接 ↓ Workflow：根据固定评分规则计算结果 ↓ Workflow：提交人工复核

Agent 不直接决定录用结果，也不能访问未授权数据。它只负责搜索路径不固定的调研环节，并把结构化结果交回 Workflow。这样既利用了 Agent 的灵活性，又保留了业务流程的可控性。

更准确的说法是：Workflow 是系统的骨架，Agent 是其中可动态决策的执行单元。Agent 不一定是整个系统唯一的“大脑”，关键业务规则、权限边界和最终责任仍应掌握在确定性代码与人类手中。

5.2 企业落地必须补上的控制机制

Agent 的自主性越高，越需要明确边界。一个可上线的混合系统通常需要以下保护机制：

• 工具白名单：Agent 只能看到并调用完成当前任务所需的工具。
• 参数校验：使用 Schema 检查工具参数，拒绝危险或无效输入。
• 权限隔离：查询、写入、支付和删除使用不同授权等级。
• 预算限制：限制模型 token、工具调用次数、执行时长和总费用。
• 过程记录：保存节点状态、工具参数、工具结果和错误，便于审计。
• 人工确认：付款、发送外部消息、删除数据等高风险动作必须确认。
• 回退策略：模型失败、工具超时或结果置信度不足时转入固定流程。

这些限制不会削弱 Agent 的价值，而是定义它可以安全探索的空间。企业购买的不是一个“想做什么就做什么”的模型，而是一套能在业务责任边界内完成目标的系统。

6. 实际项目应该如何选择

选择方案时，可以先问四个问题：任务步骤能否提前写清楚、错误代价是否可接受、是否需要审计每个环节、环境是否会频繁变化。

一个实用原则是：能用普通代码解决，就先用普通代码；路径固定时使用 Workflow；只有下一步确实需要模型在运行时判断时，才引入 Agent。Agent 会增加评测、监控、安全和成本控制的复杂度，不应该只因为概念热门就成为默认选项。

对于流程性强的工作，例如审批、数据清洗、批量抽取、标准化客服回复，Workflow 通常更合适。对于复杂资料搜索、策略规划、跨工具故障排查等开放任务，可以采用 Agent。大多数成熟系统最终会形成混合架构：确定性代码守住边界，Workflow 编排主流程，Agent 在指定范围内处理变化。

总结

Workflow 与 Agent 的本质区别，不在于是否使用大模型，而在于下一步行动由谁决定。Workflow 在开发阶段定义节点、顺序、分支和异常处理，擅长稳定地执行流程化、重复性任务；Agent 在运行阶段根据目标、当前状态和工具结果动态选择行动，擅长处理路径无法提前穷举的开放问题。

LangChain 的pipe()可以把 Prompt、模型和输出解析器组合成清晰的数据流水线，体现了 Workflow 的节点式编排方式。Agent 则在此基础上增加“观察—决策—行动”的循环，让模型能够选择工具并根据新信息调整计划。但自主性也会带来成本、时延、审计和安全风险，因此必须设置工具白名单、权限控制、执行上限与人工确认。

真正实用的 AI 工程通常会结合两者：用 Workflow 提供稳定的业务骨架和确定性边界，用 Agent 处理少量需要动态探索的环节。这样构建出的系统既能获得大模型的灵活性，也能满足企业对可靠性、可控性和可追踪性的要求。