企业官网建设流程全解析

最近半年我陆续接触了几个“AI Agent 产品推荐方案”相关的项目，发现一个挺有意思的现象：大家对 Agent 的热情都很高，但在需求分析阶段就很少有人能说清楚，这个 Agent 到底是要替推荐系统干什么活。有人想要一个能聊天的“导购”，有人想要一个自动生成推荐理由的文案器，还有人想要一套“输入一句话就能拿到十个商品”的引擎。需求没对齐，落到开发阶段基本就是一边做一边改。

这篇内容是我自己多次实操后的路径复盘：从接到需求、拆目标、选技术路线、写 Prompt、设计工具调用，到上线前的评测和问题排查，我会把每个环节里容易被忽略的细节都摊开讲。如果你是正在做智能推荐相关产品的 PM、后端或算法工程师，或者你需要给团队规划一套可落地的 Agent 方案，那这篇应该能帮你少走不少弯路。

1. 需求分析阶段：先搞清楚 Agent 到底要解决什么问题

1.1 别急着聊大模型，先量化业务目标

我经历过最典型的一个需求是这样的：某电商业务的负责人过来说，“我们要上一个 AI Agent，用户进来之后它要能像金牌导购一样，几句话就推荐到用户心坎里”。

这个描述听着很美好，但没法直接开发。“像金牌导购”太抽象了，我得反问几个问题：

• 推荐的转化率如果没有提升，那这个 Agent 的验收标准是什么？
• 用户问一句“我周末露营要买什么”，Agent 是要给一整套清单，还是逐一追问预算？
• Agent 推荐的最终结果，是直接展示商品列表，还是进入购物车结算，还是只要把用户留在对话页？
• 如果有 10% 的请求 Agent 自己搞不定，是人工接管还是给一个保守兜底结果？

这些问题问完之后，我们才能把目标拆成可衡量的数字指标。通常我会关注四类指标：

指标定下来之后，再去定义 MVP 范围。千万不要一上来就做“全自动金牌导购”，那意味着你要处理售前、售中、售后、退货、比价等一大堆场景，工程量和效果风险都不可控。我一般建议把 MVP 收窄成“基于用户多轮对话的商品推荐助手”，核心动作只有三个：理解需求、检索商品、给出推荐解释。

1.2 盘点数据资产，算清候选池和时延预算

需求澄清之后，紧接着要做的不是写代码，而是盘点数据。一个 AI Agent 推荐方案到底能不能落地，很大程度上取决于你的数据长什么样。

我先列一个最低限度的数据清单：

• 商品主数据：商品 ID、类目、标题、价格、库存、规格、上架状态。
• 用户行为数据：近 90 天的点击、收藏、加购、下单、搜索记录。
• 用户画像标签：性别、年龄段、城市等级、历史消费档次。
• 实时上下文：当前会话的输入、当前所处的页面、设备类型、时间。

数据缺失的情况很常见。我遇到过一个项目，商品数据里连“适用场景”这种最基础的字段都没有，导致用户问“户外露营装备”时，Agent 只能靠标题里的关键词去猜。后来我们做了一个很笨但有效的补数动作：用大模型给商品标题批量打场景标签，准确率控制在 85% 左右，配合人工抽样校准，才把检索质量提上来。

数据盘点完之后，要估算请求链路的数据量级。这里有一个非常实用的计算办法：

假设你的商品池有 50 万商品，候选召回阶段要筛出 200 个商品给模型评分，然后精排只取 20 个展示。那你的检索服务只需要保证 200 级别候选的召回能力，排序直接交给轻量模型。加上 Agent 对话交互，整条链路的时延预算我给一个参考值：

• 意图识别和槽位提取：建议 300ms 以内
• 候选召回：建议 200ms 以内
• 精排和重排：建议 200ms 以内
• Agent 的 Prompt 组装、工具调用、结果汇总生成文本：这部分是大头，单轮建议控制在 1.5s 到 2s

如果总时延超过 3 秒，用户的对话体验就会明显变差。我们实测下来，用户能接受的 Agent 首响时延大概在 2 秒上下，超过 3 秒后跳出率会显著上升。

1.3 拆解用户场景，画出一张对话流程图

数据盘点之后，我会带着业务方一起拆用户场景。这个环节看起来像是产品经理的事，但开发同学一定要参与，因为很多技术隐患是在场景拆解时暴露出来的。

典型的导购对话流程，我习惯拆成这么几类：

1. 首轮咨询：用户直接说需求，例如“帮我推荐几款适合通勤的背包”。
2. 多轮追问：用户对上一轮结果不满意，补充预算、材质、容量等条件。
3. 对比询问：例如“这款和刚才那款有什么区别？”
4. 纠正需求：用户发现推荐跑偏，重新说明意图。
5. 闲聊与非商品问题：例如“你们有什么优惠活动吗？”这类也需要有兜底。

每类场景都要定义输入、输出、触发条件和异常分支。不要试图用一个 Prompt 覆盖所有情况，我的习惯是给每个场景设计一套独立的处理逻辑，然后用一个轻量的意图分类器做路由。这个路由可以是一个小的微调模型，也可以是结构化 Prompt 输出意图标签，优先保证可控性。

1.4 输出一份能指导开发的需求交接文档

需求分析阶段最后要交出来的东西，不是聊天纪要，而是一份结构化的需求文档。我通常按这个模板写：

这份文档不是为了走流程，而是为了后面做评测集的时候能用上。每一行硬性限制，最终都要变成自动化评测的判定规则。

2. 方案选型：Agent 推荐链路的核心设计与取舍

2.1 三条技术路线，怎么选型？

需求文档定了之后，最烧脑的部分来了：Agent 产品推荐到底该采用什么技术架构？

我把目前常见的路线归纳成三种，放在同一张表里对比：

从我实际落地的经验看，纯 A 太保守，Agent 只是个“翻译器”，业务方会觉得不过瘾；纯 B 对大多数团队来说步子太大，光是稳定性和评测就能耗掉一个季度。我选型的结论是：生产环境优先走 C 路线的增强版，即用一到两个轻量模型做意图理解和内容生成，用推荐引擎和向量检索做候选召回，用规则和显式工具调用做硬约束兜底，Agent 在整个链路中扮演“调度 + 表达”的角色。

这样选的核心原因只有一个：推荐场景里的错误代价很高。一个用户问“千元以下机械键盘”，如果 Agent 因为没有正确解析预算阈值，推荐了一个 1099 元的键盘，用户信任感会直接跌破冰点。这类问题必须靠硬约束解决，而不是靠模型“自觉”。所以我很早就明确了一个原则：凡是能用规则和参数限制的地方，就不依赖模型自觉。

2.2 为什么 Agent 不能直接“编造”推荐结果

有段时间很多团队迷信大模型能直接生成推荐内容，让模型从参数里“回忆”出该推荐什么商品。这种做法在小规模 Demo 里看着很唬人，一上生产就会露馅：

• 模型会一本正经地推荐一个下架或缺货的商品；
• 模型可能记错价格，或者把两个相似商品的特性混在一起；
• 企业对推荐结果有审核和运营要求，模型自由发挥的结果没法过审。

我把这个问题的根源总结为“参数化记忆不可靠”。推荐必须先经过一个真实的候选检索闭环，再交给生成模型组织语言。Agent 可以发挥的地方在于：理解用户约束、组合检索条件、生成推荐理由、判断是否需要追问、以及解释商品之间的差异。至于最终推荐哪些商品，必须来自结构化数据和检索结果的约束。

用一个生活化类比：Agent 不是那个靠脑补给你开药方的医生，而是那个帮你挂号、整理病历、解释医嘱的导诊台。开药方的权力仍然在诊断系统手里。

2.3 记忆与画像设计：短期会话记忆比长期画像更关键

Agent 推荐方案的记忆设计，非常容易做过头。有些团队一上来就规划用户长期画像、跨端行为归一、知识图谱，最后项目卡在画像建设上，Agent 迟迟上不了线。

我自己的排序是：短期会话记忆 > 实时交互上下文 > 长期画像标签。

短期会话记忆指的是用户在这一轮对话里说过的所有条件。比如用户先说“要一个通勤包”，然后又补充“最好深色的，容量 20L 左右”，那这两个条件必须在一个会话窗口里同时生效。实现上就是维护一个槽位表，由模型在每一轮输出中更新，且服务端持久化，而不是依赖模型自己记住。

实时交互上下文指的是用户当前的操作行为，比如此刻正停在某个商品详情页、搜索了某个关键词、把某商品加入购物车。这些信息是最后一次点击最优的强特征。

长期画像标签可以放宽到“只作为粗排阶段的特征”，不需要刻意构建完整画像体系。用现成推荐系统里已有的 user embedding 或标签，在检索阶段参与粗排就够了。

2.4 成本与响应速度预算：按请求精细化设计

大模型推理的成本，在 Agent 推荐方案里是绕不开的。业务方往往先关心效果好不好的问题，但在原型阶段就必须把成本估算清楚。

我一般按单次会话预估 token 消耗。假设系统 Prompt 固定 800 token，每轮用户输入约 50 token，工具调用结果压缩后约 300 token，生成回复约 200 token。那一轮对话的总 token 消耗约在 1350 到 1500 之间。

如果一个用户会话平均 4 轮，每天 10 万次会话，我们按一个主流中档模型的输入端价格估算，一天的模型成本可能会让人倒吸一口凉气。降低成本最有效的几个办法：

• 会话上下文压缩：只保留用户约束槽位和最近两轮对话，不把整段历史所有内容全部喂给模型。
• 缓存命中：用户首轮问题如果和热门问题相似，可以走缓存回复。
• 模型分级：意图分类用小模型，推荐理由生成用大模型，必要时才调用。这个策略能省掉不少成本。
• 候选结果预渲染：高频商品的推荐文案提前离线生成，Agent 直接取用，不实时生成。

成本控制的核心思路是“能离线的地方绝不在线生成，能靠规则的地方绝不靠模型”。

3. 核心实现：从 Prompt 编排到工具调用的工程细节

3.1 系统 Prompt 的设计原则：角色、限制、输出格式

在 Agent 推荐方案里，系统 Prompt 不是写给模型看的“说明书”，而是给整个链路定义的“合同”。如果 Prompt 写得含含糊糊，下游所有环节都会跟着摇晃。

我设计 Prompt 时固定五个要素：

1. 身份与边界：明确 Agent 是商品推荐助手，不是闲聊客服，不回答与购物无关的问题。
2. 核心任务：理解用户需求、调用推荐工具、返回符合约束的商品。
3. 硬性规则：例如“价格不得超过用户预算”“必须返回有库存商品”“不得虚构商品信息”。
4. 输出格式：要求模型输出结构化的 JSON，包含意图标签、已提取约束、候选商品 ID 和推荐理由。
5. 兜底指引：告诉模型如果找不到合适商品，应主动询问用户是否放宽条件，而不是强行推荐。

下面是一个简化版的系统 Prompt 示例：

{ "role": "商品推荐助手", "task": "理解用户购物需求，调用商品检索工具，基于检索结果做推荐", "rules": [ "必须严格遵循用户给出的预算上限", "必须推荐在场内有库存的商品", "不得虚构商品名称、价格、参数", "当检索结果为空时，主动建议用户放宽条件" ], "output_format": { "intent": "推荐|追问|闲聊|无法处理", "constraints": {"关键词": [], "价格上限": 0, "类目": ""}, "candidate_ids": [], "reply": "" } }

很多团队会犯一个毛病：把 Prompt 写得像长篇作文，结果模型总是漏字段或者加戏。我的经验是 Prompt 越长，越要配合强校验。解析完模型输出后，必须做 schema 校验，字段缺失或类型不对就自动重试一次，重试还不行就走兜底。

3.2 工具调用协议：把推荐系统变成 Agent 的“手”

Agent 要靠工具调用去拿真实数据。这里最忌讳的是让模型直接查数据库或调内部接口，因为大模型输出的 SQL 或查询参数不可控，低速查询还会拖垮数据库。

我通常给 Agent 设计一个简单的封装接口，只暴露三到四个参数：

{ "tool": "search_products", "params": { "query": "通勤背包", "category": "箱包", "max_price": 300, "min_price": null, "sort": "default", "limit": 20 } }

检索服务收到参数后，先把非结构化文本 query 转成语义向量做召回，再做规则过滤，最后返回一个压缩后的候选列表。为了让模型不产生幻觉，返回的每个商品只保留关键字段：商品 ID、标题、价格、库存状态、推荐标签，以及一段简短的商品卖点摘要。

工具调用这块有一个很容易被忽视的细节：上下文里的候选数据不能太长。有一次我们把每个商品 50 个字段全部返回给模型，结果模型完全被冗余信息淹没，推荐理由反而写得驴唇不对马嘴。后来我们改成只返回 8 个关键字段，效果立刻改善。工具返回结果也需要做截断，单条商品描述控制在 40 个字以内。

3.3 硬规则兜底：确保推荐结果“不出格”

Prompt 写得再好，模型也有不听话的时候。所以硬规则兜底不能省。我这里说的兜底不是一句“如果出错就返回默认推荐”，而是一整套校验流程：

• 价格校验：模型返回的候选商品价格必须低于用户预算上限，且容差要很小，比如超过 1 元就直接替换。
• 库存校验：实时库存服务是最终裁决者，不能看索引或缓存里的数据。
• 重复过滤：多轮对话中用户拒绝过的商品，需要记忆并在后续推荐中排除。
• 敏感类目过滤：根据平台运营规则，某些类目不能参与特定场景推荐，这类白名单/黑名单必须放在规则层。
• 相关性校验：如果候选商品和用户查询的语义相似度低于阈值，果断不放行。

举个例子，用户问“500 元以内的游戏鼠标”，检索服务返回了三个候选：499 元的有线鼠标、488 元的无线鼠标、529 元的高端款。模型可能出于“优质推荐”的考虑把 529 元的混进来，但硬规则校验会在展示前拦截它。拦截后模型应该重新生成推荐理由，或者告诉用户“500 元以内目前有两款比较合适，另外有一款稍微超预算，您需要看看吗？”

3.4 离线评测：上线前先建一个“对话题库”

Agent 推荐方案不能像传统推荐模型那样只看离线 AUC 或召回率，因为对话质量无法完全靠点击率反映。我的做法是建一个“对话题库”，也叫评测集会。

题库来源于三个渠道：

• 从真实用户搜索日志里抽取高频需求，整理成自然对话语句；
• 业务方提供典型客诉和愿望清单，把这些变成边界用例；
• 我们从需求文档里的硬性限制反推，构造大量“陷阱题”。

评测时每个用例会记录这么几个维度：

评测通过之后，再上线的成功率会高很多。我们内部的经验是，一个 Agent 推荐版本上线前，至少要把题库回归三轮。第一轮跑通主流程，第二轮跑边界和异常，第三轮做多轮对话连贯性测试。跑不完这三轮就上线，上线后大概率要靠 hotfix 续命。

4. 落地开发与问题排查：排期、监控、踩坑实录

4.1 项目排期：四周做出一个可演示的 MVP

把需求和技术路线定了之后，就要排期了。我给一个相对务实的四周 MVP 排期参考：

这个排期可行的前提是推荐引擎本身已经存在，或者至少有一个可用语义检索服务。如果连最基础的搜索接口都没有，那时间要翻倍，因为你需要另外做索引、召回、排序这些底层能力。

四周期限非常紧，砍需求要果断。我给团队定过一个原则：MVP 阶段只做“推荐”和“追问”两类意图，其他闲聊、售后、维权一律转人工客服或走默认话术。这个原则帮我们在排期压力下留住了最核心的用户价值。

4.2 链路打通：一个简化的后端调度示例

前面规划了那么多，最后还是要落到代码上。我习惯用 Python 写调度逻辑，因为和大模型链路配合最方便。下面是一个高度简化的示例，重点是展示“调用工具-校验结果-生成回复”这条主线。

def agent_recommend(user_input, session): # 1. 意图识别 parsed = parse_intent(user_input) if parsed.intent == "闲聊": return default_reply() if parsed.intent == "无法处理": return fallback_reply() # 2. 更新会话槽位 session.slots.update(parsed.constraints) # 3. 调用推荐工具 results = search_products( query=session.slots.get("关键词"), max_price=session.slots.get("价格上限"), category=session.slots.get("类目"), limit=20 ) # 4. 硬规则过滤 filtered = [ p for p in results if p.price <= session.slots.get("价格上限", float("inf")) and p.stock_status == "in_stock" and p.id not in session.rejected_ids ] # 5. 无结果时引导用户放宽条件 if not filtered: return ask_relax_constraints(session.slots) # 6. 生成最终推荐理由 reply = generate_reply(filtered[:5], session.slots) return reply

这段代码是最小骨架，线上还需要补充超时控制、并发限制、日志埋点和降级开关。有两点特别提醒：

• 工具调用必须有超时。我们统一设置 500ms 超时，超时直接走兜底结果，否则大模型会被一直挂住等待。
• 上下文里要显式携带约束条件，不要指望模型在后续轮次里推测。每轮组装 Prompt 时，都会把会话槽位表序列化进去。

4.3 上线前监控：该盯的不是只有接口错误率

传统推荐系统上线，看 QPS、错误率、耗时就够了。Agent 推荐方案远不止这些，因为对话链路是状态化的，故障可能是逻辑层面的，而不是接口报错层面的。

我上线前一定会配置以下几类监控：

其中“无效推荐率”是我最看重的指标。它实际上反映的是模型有没有在认真遵守约束条件。如果这个指标持续偏高，说明 Prompt 或工具交互设计有问题，光提高模型温度或者换大模型解决不了。

4.4 常见问题速查表：我踩过的那些坑

落地过程中有些问题几乎是每个团队都会遇到的，我把它们整理成一张速查表，方便你排障时对照。

这七个问题里，让我印象最深的是否定语义解析。传统的推荐系统通常只会做正向关键词匹配，而 Agent 场景里用户会非常自然地说“不要什么什么”。不处理这类表达，Agent 的体验就显得智商不在线。后来我们专门给意图解析模型加了一个属性排除槽位，同时保留了用户原始文本，在候选召回后做二次语法规则校验，才基本解决。

4.5 实测复盘：一次上线前后的完整记录

最后分享一个具体的复盘案例，帮助你把前文的内容串起来。

当时我们接了一个某跨平台电商的推荐场景，商品池接近 70 万，用户入口在 App 的首页搜索框旁边。第一版 MVP 只做单轮推荐，用户输入需求，Agent 输出 4 个商品卡片和一段推荐理由。实测定点测试时，最大的问题是无效推荐率在 6% 左右，单独看好像不高，但换算到日均 20 万次调用，意味着每天有一万多条推荐结果触碰硬规则。

排查之后发现三大主因：

• 价格单位在输入解析阶段被忽略，用户说“300 元”和“300 块”没有统一归一化；
• 有些商品字段中的促销价和划线价并存，校验模块取了错误的价格字段；
• 库存状态更新滞后，Agent 从候选池检索时看到的库存和最终下单时的实际库存不一致。

这三个问题分别解决：统一数字单位解析、明确价格字段优先级、把库存校验改为在下单前实时查询。调整后无效推荐率降到 1.7%，达到了业务预期。这个案例说明一个道理：Agent 方案的很多问题，最后其实都是数据规范和工程细节的问题，而不是模型能力不够。

我个人在实际操作中的体会是，AI Agent 产品推荐方案本质上是“用自然语言重新组装推荐能力”，难点从来不在某一个模型上，而在数据、规则、评测、监控这几个环节的咬合。如果你也正在做类似的事，建议给自己定一条规矩：先质疑和确认需求，再讨论架构，最后才谈模型参数。把推荐链路看成稳定的底座，把 Agent 看成会说话的前台，项目推进起来会顺畅得多。

最后再分享一个小技巧：把评测题库写成自动化的回归脚本，每迭代一版 Prompt 或者调整一次工具协议，都跑一遍全量题库。这个脚本前期建立要花不少时间，但后期省下的沟通和返工时间远超预期。很多人问为什么自己的 Agent 推荐方案老是上线就翻车，其实就是缺了这一道关卡。