企业官网建设流程全解析

说一个我这两年反复遇到的现象：很多团队做Agent，第一版都是“一个超大Prompt + 一堆工具说明”，让大模型自己发挥。Demo阶段确实惊艳，一上真实流量就原形毕露——模型开始胡乱调工具、回答前后矛盾、上下文越聊越乱，最后连问题出在哪都定位不了。折腾几次之后，大家才意识到，Ag ent能不能稳定落地，关键不在模型本身，而在模型外面的那层结构。

这就是Agent工作流架构的意义。我常把Agent工作流架构分成三种基本形态：增强型架构、链式架构、路由式架构。它们不互斥，更像积木，绝大多数线上系统都是三者的组合。这篇文章不聊虚的，直接拆解每种架构解决什么问题、怎么落地、坑在哪，适合正在从“聊天机器人”走向“工程化Agent服务”的开发者参考。

1. 三种架构的本质差异与选型逻辑

1.1 为什么单个Prompt撑不起复杂Agent

先说个本质问题：为什么不能靠一个超大Prompt解决所有问题？

LLM单次调用的上下文窗口不管多大，都是有限的。业务场景里有三个问题绕不开。第一，幻觉控制不了，模型对自己的知识盲区没有感知，你让它处理没见过的售后规则，它大概率编一个听起来合理的答案。第二，工具越多越不可控，你给Agent挂了十个工具，它面对模糊需求时选错工具的概率会指数上升，而且选错了你很难阻止。第三，单次调用的输出是“一锤子买卖”，过程中没法插入校验、没法回头修正、没法在中间环节让规则代码参与决策。

工作流架构存在的意义，就是把这些不可控的“自由发挥”装进一个可控的壳里。模型负责它擅长的事——理解语义、生成文本、抽取信息，结构负责它不擅长的事——流程控制、数据校验、状态管理、异常兜底。搞清楚这个分工，后面所有架构选择就都有了判断依据。

1.2 三种架构分别管什么事

我用三句话概括三种架构的定位。

增强型架构，解决的是“单个Agent能力不够”的问题。它给模型外部装备，比如知识库检索、业务API调用、外部数据库查询，让模型从“凭记忆回答”变成“查完再回答”。典型场景是企业知识库问答助手、接入实时数据的分析机器人。特点是只有一条流程，模型是核心，所有增强手段都在为这一次生成服务。

链式架构，解决的是“一个任务太长太复杂”的问题。它把任务拆成多个步骤，每一步交给一个专门的小Prompt甚至一个小模型，前一步的输出是后一步的输入。典型场景是工单自动处理、文档批量审核、内容生成流水线。特点是流程固定、顺序明确，像工厂流水线一样，每个工位只干一件事。

路由式架构，解决的是“不同请求需要不同处理方式”的问题。它在前端放一个“智能分诊台”，先判断当前请求属于哪类任务，再分发给对应的下游Agent或工作流。典型场景是综合客服系统、多渠道接入助手、企业级Agent网关。特点是上游统一入口、下游分工明确，各管一摊互不干扰。

1.3 选型不是二选一，它们常常组合出现

很多人有个误区，觉得三种架构是竞争关系，要选一个。实际做项目你会看到，真实系统几乎都是混合形态。举一个非常常见的组合：一个客服系统最外层是路由式架构，用户问题进来先判意图；判断为“查订单”的请求会进入一个链式工作流，先查订单状态再生成回复；这个链式流程里的生成步骤可能又用了增强型架构，去检索售后政策库。三层套在一起，每一层解决一个特定问题。

所以别把精力放在“哪个架构天下第一”这种争论上，你应该练的是判断力：当前这个具体的业务环节，卡点到底在哪？是单步回答质量差，多步流程无人编排，还是多种任务混在一起互相干扰？卡点对应哪种架构，就用哪种。这也是这篇博文整体围绕的核心思路。

2. 增强型架构：把LLM变成“什么都会的实习生”

2.1 增强型架构的核心组成：检索、工具、记忆

增强型架构是所有Agent架构里最常见的一种，市面上90%的“Ai助手”本质都是它。它的核心思路一句话：模型还是那个模型，但让它带着装备上场。

第一类装备是检索增强，通常叫检索增强生成。给模型挂一个外部知识库，用户提问后先从知识库里把相关片段捞出来，拼进上下文，模型基于这些片段作答。这解决了大模型对私有数据一无所知的问题，也是企业内部落地最快的方式。

第二类装备是工具调用。给模型开放一批API，比如查天气、查库存、提交工单、读写数据库。模型在对话中自主决定“我现在需要调用某个函数”，把调用参数生成出来，由程序实际执行，再把返回结果交回模型继续生成。这样Agent就从“只能聊天”变成了“能办事”。

第三类装备是记忆管理，包括短期的会话上下文和长期的对用户画像、历史偏好的持久化存储。很多Agent产品卖点里的“懂你”，靠的就是这个模块，跟模型本身关系不大。

三种装备可以单独用，也可以组合。组合时核心难点不在单个装备本身，而在它们之间如何有序协作，这是下面要展开的。

2.2 检索增强与工具调用的落地细节

先说检索增强。很多初版实现就是“把知识库Top K结果全塞进Prompt”，做法没错，但细节决定成败。我常用的套路是：先做语义检索拿到候选，再用重排序模型精确排序，最后设一个相似度阈值，低于阈值的宁可告诉用户“知识库没覆盖到”，也不要让模型硬答。这里最关键的就是阈值，定太高答不上来，定太低胡说八道，一般要用一批真实问题去标定。还有一个容易忽略的点：必须把每条检索结果标注来源，让模型注明“根据某文档”，这样用户能追踪，出错也能定位是检索问题还是生成问题。

工具调用的坑主要在三处。第一，工具描述要写得像让新人用内部系统——说清楚什么时候用、什么时候不用、入参的格式和边界，描述写不好模型就会乱选。第二，入参必须做程序侧强校验，模型生成JSON参数经常出现字段缺失、格式错误，你要在校验层兜住，而不是直接拿错误参数去调API。第三，权限边界要在工具层控制，比如只读类API就绝不能让Agent拿到写权限，这跟人无关，纯粹是系统安全设计问题。

记忆管理上，我见过最多的问题是不分青红皂白把所有历史对话都塞进下次请求，结果令牌爆掉、响应变慢、模型被无关信息干扰。实践中更可靠的做法是异步做对话摘要，每次只保留“摘要+最近几轮原文”，长期画像落到独立的用户存储里按需读取，而不是无脑拼接。

2.3 边界条件：什么时候增强型不够用

增强型架构有一个明显边界：它本质是“单步决策”。模型接收输入、查资料、调工具、产出回复，整个过程是一次性完成的。当业务逻辑本身需要多步推理或多阶段加工时，增强型架构撑不住。

举一个我实际遇到的例子。一个发票审核场景，要求先识别发票类型，再逐项比对合同金额，再检查税率是否一致，最后生成审核结论。如果只用一个增强型Agent一次性做，前面任何一步的识别错误都会直接污染后面结论，而且中间状态不可见，出了问题只能整锅端。这种场景需要的是把审核拆成独立的步骤，每步做完校验再进下一步——这正好是链式架构的用武之地。增强型架构适合“输入明确、输出明确、中间过程不超过一跳”的任务，一旦业务开始要求阶段性检查、分支处理，就该考虑换架构了。

3. 链式架构：把复杂流程拆成一条可控流水线

3.1 链式架构的基本模式：串行与条件门控

链式架构的核心思想是“大事化小，小事化专”。一个复杂任务不要试图一次完成，而是拆成多个简单步骤，每步用一个专门化Prompt处理。这么做有三个直接好处：单步上下文更短，模型注意力更集中；每步输出可以被校验和记录，错误能被及时拦截；不同步骤可以用不同模型，比如抽取用快模型、生成用强模型，性价比一下就上来了。

最基本的实现是串行链，前一步输出作为后一步输入。举个简化例子：

def build_reply_flow(order_data): # 第一步：抽取关键信息 extracted = extraction_step(order_data) # 第二步：检索售后政策 policies = policy_retrieval_step(extracted["issue_type"]) # 第三步：生成回复草稿 draft = generation_step(extracted, policies) # 第四步：质量门控，不合格重新生成 if grammar_and_tone_check(draft) is False: draft = rewrite_step(draft, extracted) return draft

比串行链更进一步的是条件门控，就是在一个步骤后根据结果决定往哪走。比如意图分类步骤后，如果是退货问题走退货流程，是物流问题走物流查询流程。门控的判断可以由代码规则做，也可以交给一个小模型做。关键原则是：能用规则判断就不要用模型，确定性逻辑用代码实现，模型只处理语义层面的不确定性。

3.2 中间Schema设计是链式架构的命门

我见过太多链式项目翻车，原因不在模型，而在中间数据结构一团乱。每步输出如果只是自然语言，下一步再想提取结构化信息就很痛苦，错误会随着链条逐级放大。所以链式架构有个铁律：每步的输出除了给用户看的文本，还必须带一个结构化字段，也就是中间Schema。

例如第一步做信息抽取，输出的结构化字段是：

{ "order_id": "A10001", "issue_type": "refund_request", "risk_flag": false, "summary": "用户申请退款，原因是商品破损" }

下一步拿到这个JSON后，直接用字段做分支判断，或者拼进下一步Prompt，而不是把用户原文再扔给模型让它再提取一遍。这样做的好处是每一步的错误边界非常清楚：抽取错了就在第一步补救，生成跑题了就在第三步补救，不会出现一个错传导到最终输出才被发现。

中间Schema设计有个实操建议：字段要少而精。宁可先只定义三五个关键字段，也不要一开始就搞二十个字段的大JSON，字段越多模型越容易填错，校验成本也越高。先用最少字段跑通链路，再按需扩展。

3.3 失败重试、幂等与可观测性

链式架构里最容易被低估的工程问题是失败处理。链条越长，任何一步失败的概率越高，而且失败会传播。所以你要对每一步定义清楚三类情况：可重试、可跳过、需人工。可重试一般指临时性错误，比如上游API超时、模型接口返回格式错误，这类可以直接重试两到三次，加上指数退避。可跳过指该步骤非关键，比如推荐相关文章失败不影响主流程。需人工是最重要的兜底，当某一步连续失败或校验不通过时，把当前状态完整保留，转给人工处理，而不是在系统里反复空转。

幂等性也容易被忽略。链式工单处理如果在上游接口超时后重试，可能造成同一任务被重复处理。所以要有业务幂等键，比如订单号加流程类型生成唯一键，处理前后检查状态位，保证同一请求只沿流程走一遍。

还有可观测性。链式流程每一步都是独立的，也是天然的日志埋点。我会在每条请求进入时生成一个trace_id，传递到每一步，把所有Prompt、中间输出、延迟、消耗令牌数全部记录下来。有了这套日志，后面排查任何问题都轻松十倍，没有trace_id的链式项目出了问题基本靠猜。

4. 路由式架构：让正确的工作流处理正确的请求

4.1 路由判定：规则、小模型与大模型三种实现

路由式架构解决的是“一条工作流无法应对多样化请求”的问题。它像一个前台分诊台，先判断患者挂哪个科，再引导到对应诊室。这个分诊台也就是路由器，是整个架构的核心。

路由器本身不一定要用大模型，甚至大多数情况下不应该用大模型。我按性价比排序，最推荐先考虑规则路由，关键词、正则、业务字段命中，例如用户消息里含“退款”“退货”就直送售后流程。规则覆盖不了的模糊情况，再考虑用小分类模型，像意图识别微调模型，延迟低、成本小、稳定可复现，适合请求类型比较固定的业务。只有请求极其开放、类别边界模糊的场景，才让大模型来做路由判断，让模型输出一个意图标签和置信度。

一个实际经验是：三者按层叠加。规则命中率最高，优先判断；规则没命中交给小模型；小模型置信度低于阈值，再给大模型兜底判断。这样既能稳住绝大多数常见请求，又不会把成本浪费在简单case上。路由判定耗时越长，用户体验越差，能用规则就用规则，这是性价比的铁律。

4.2 路由器的输入设计与下游契约

路由任务看似简单，做起来容易踩坑的地方在于：路由器该接收什么输入，该输出什么给下游。

输入侧，不要直接把用户全量上下文一股脑丢给路由器。上下文越长，判断延迟越高，无关信息还会干扰分类准确率。我建议整理成结构化输入：用户原始消息、业务标签、会话摘要、用户画像关键字段。特征的目的是让路由器在最短上下文里做出最准的分流，不是把所有信息都传递一遍。

输出侧，关键在于路由器要输出一个标准的路由指令对象，除了目标流程标识，还要附上必要的上下文摘要和置信度。示例如下：

{ "route": "return_flow", "confidence": 0.94, "context_summary": "用户要求退货，订单号AS-20240115，已签收", "original_channel": "app_feedback" }

更重要的是，下游每个工作流都要定义自己的入口契约：它需要哪些字段、字段格式是什么、缺字段怎么办。路由器根据下游契约来组装数据，而不是下游各自从原始对话里自己猜。这样每条分发过去的请求都自带完整上下文，下游Agent不用再向用户重复询问已提供过的信息。

4.3 降级与兜底：路由失败的兜底策略

稳定系统最怕“路由器自信地做了错误决定”。所以路由式架构必须设计降级链。

第一层降级是置信度阈值。路由器判定置信度低于某个值，不要强行分发，直接走默认流程。默认流程可能是通用问答Agent、知识库搜索或者人工客服，取决于业务性质。阈值定多少需要看数据分布，我一般先用历史日志离线统计，找到能让准确率和兜底率平衡的点。

第二层降级是超时保护。路由器调用上游分类模型有超时限制，超时就自动转默认路由，不能让用户无限等待。这个在很多团队里被忽视，直到线上出现长尾响应才发现。

第三层降级是对下游失败的感知。如果路由到了一个下游流程但下游持续报错，路由器需要感知到，考虑把后续同类请求切到备用流程，或者临时改为全部人工处理。这个“路由健康状态”的监控，是架构从能用走向稳定的关键一步。路由式架构的容错能力不在路由本身，而在路由外围这层层降级设计。

5. 三种架构的对比与混用实践

5.1 关键维度对比表

把三种架构放在一张表里对照，很多选型问题会变得清晰：

对照表的重点不是机械背结论，而是定位你当前业务的卡点。如果业务瓶颈是单步回答质量差，上增强型；是流程乱、无校验，上链式；是多类请求混在一起互相干扰，上路由式。真实需求很少只占一格，所以关键在于组合。

5.2 实战中的混合形态：路由加链式加增强

我用一个虚构但很典型的电商售后场景来说明混合架构是怎么落地的。整体设计是一个客服系统，线上流量入口统一——先走路由层。

第一步路由层：用户消息进来，规则检测到“退货”“退款”“发票”等信号，或者分类模型识别出意图。结果决定走售后流程、发票流程还是通用问答。这里用的是顶层路由式架构。

第二步链式层：以退货流程为例，内部拆成四个串行步骤：订单信息抽取、售后政策检索匹配、处理方案生成、最终话术审核。每步之间用JSON传参，每步有独立的校验。这里用的是链式架构。

第三步增强层：政策检索匹配这一步，不是硬编规则，而是先把售后政策文档向量化入库，根据第一步抽取的问题类型做向量检索，再拼进Prompt生成方案。这一步内部又是增强型架构。

三层嵌套下来，每一层只解决自己那个层面的问题，互不越权。这个系统上线后我复盘最大的感悟是：架构不是设计出来的炫技作品，而是被真实业务问题一层层逼出来的必然结构。没有路由，退货和开发票的请求会互相污染；没有链式，多步审核必然错漏百出；没有增强，政策更新后系统还要改代码。三者各自承担了不可替代的责任。

6. 常见问题与排查技巧实录

6.1 高发问题与排查方向

6.2 我的几条核心排查建议

第一条，给每个请求都打上trace_id。这句话我在每个Agent项目里都说，因为它无数次救了排查现场。没有全链路追踪，链式架构出问题基本只能靠肉眼比对多条散落日志，效率极低。有了trace_id，一个问题从路由决策到最终输出，所有环节的开销、结果、模型输出全部串起来，十分钟就能定位。

第二条，先小步验证，再放大规模。我见过最快的翻车方式，是把一个十步链式流程一次性全量上线。正确做法是先只跑通三步核心链路，加足够日志，用小流量试运行，确认每一步的失败率都在可接受范围内，再逐步加步骤、加分支。Agent架构的复杂度必须用渐进式验证来消化。

第三条，区分哪些环节必须用模型、哪些环节其实规则就够了。很多人一旦开始用Agent架构，就不自觉地把所有判断都交给模型。实际做下来你会发现，规则能做的判断又快又稳又便宜，比如格式校验、字段存在性检查、权限控制、状态位判断。把模型留给语义理解、内容生成、信息抽取这些真正需要智能的地方，系统稳定性和成本都会有质的提升。

第四条，始终保留人工接管通道。不管架构多复杂，线上一定有模型处理不了的异常case。设计阶段就要把所有“兜底到人工”的路径留好，不管是链式某步连续失败、路由置信度过低，还是增强型检索不到答案。一个Agent系统敢不敢留人工兜底，反映了你对自己系统的判断是否清醒。那些声称“全自动不需要人”的系统，恰恰是最危险的。

最后说点真心话

做了这么多Agent工作流架构方面的项目，我个人体会最深的一句话是：架构的复杂度应该由业务的不确定性决定，而不是由开发者的兴奋度决定。不要因为某种架构听起来高级就强行引入，也不要在架构选型上追求一步到位。多数线上业务最稳的形态，其实只是一条简单清晰的链路加一个可靠的路由，再加上必要的外部检索和工具接入。先把手写流程跑通，观察哪里真的卡住了，再抽象成架构。很多花里胡哨的设计，最后都会在真实流量的检验下回归到那只必要的三分结构——增强、链式、路由，各自管好自己那一亩三分地。

最后再分享一个小技巧：无论你最后选哪种架构，上线前一定先把“每一步的输入输出日志”和“每一步的失败计数”这两个埋点做好。有了这两样东西，你不需要任何复杂监控平台，光靠滚动日志就能定位九成以上的线上问题。结构是骨架，日志是神经，它们一起才构成一个可维护的Agent系统。