AI Agent商品推荐落地指南：从需求拆解到工程踩坑实录

去年我们团队对接了一个零售选品方向的业务需求业务方上来就抛了一句话“能不能搞一个 AI 推荐方案用户随便聊两句就把东西帮他选好。”听起来像是“接个大模型”就能交差但真正拆开以后才发现所谓“AI Agent 产品推荐方案”从需求分析到落地开发中间横着的根本不是模型能力问题而是意图识别、槽位提取、检索召回、推荐理由生成、安全兜底、线上灰度这一整条链路的设计问题。整套做下来我最大的感触是这类项目最难的从来不是写代码而是怎么把“推荐得准”这种模糊的业务语言编译成一个个可设计、可评测、可迭代的工程模块。这篇文章我就把这半年来踩过的坑和验证过的方法完整梳理一遍包括前期需求分析怎么做、技术栈怎么选、核心链路怎么设计、联调测试阶段有哪三个差点翻车的坑。准备规划 Agent 落地但又拿不准第一步该做什么的团队可以直接拿这份思路做参照。1. 立项前先泼盆冷水推荐场景到底适不适合引入 Agent1.1 动手前必须拿到的三个答案我一直坚持一个观点不是所有推荐需求都该上 Agent。立项阶段的第一周我们不做技术方案只做业务调研。三个问题必须问出明确答案。第一个问题用户当前选择商品时真正的痛点是什么是“不知道选什么”还是“知道选什么但找不到匹配的”还是“找到之后不知道怎么比”这三种痛点对应的解法完全不同。如果用户只是不知道怎么比价那做一个筛选工具比 Agent 高效得多如果用户能清楚说出品牌、型号、预算传统搜索框也能解决大半。第二个问题你的领域数据能不能支撑个性化。所谓 Agent 推荐底座其实是“领域知识 用户意图”。业务方有没有结构化的商品属性表有没有用户的历史行为数据有没有品类专家沉淀出的推荐规则这三样至少要占一样否则 Agent 上线之后就是一个更大号的聊天机器人能聊但选不准。第三个问题业务方对推荐错误的容忍度是多少。推荐错了、推了一个用户完全不需要的东西会造成什么后果是会流失一个订单还是会引发投诉甚至合规问题我见过不止一个项目在这里栽跟头——一开始业务方拍胸脯说“错了没关系”上线之后错了三次就翻脸。这个答案直接决定我们要不要加一圈安全护栏也决定整个架构的复杂度。这三个答案拿到之后再判断项目该怎么做。如果三个答案都模糊那这个项目大概率连 Demo 阶段都撑不过去。1.2 两种典型的 Agent 友好场景排除掉不适合的场景之后我总结出两类业务凡是对上号的Agent 推荐的价值非常大。第一类是“信息筛查型”。典型特征是商品池大、规格杂、筛选条件多用户自己翻列表翻到崩溃。比如户外露营装备同一顶帐篷有四五个系列、十几个尺寸、七八种适配场景还有重量、防水指数、搭建方式这些细粒度参数。用户在传统电商列表页里根本没法把这些条件组合起来但是用自然语言说一句“周末两个人去海边露营预算一千五以内要抗风的帐篷”Agent 可以直接把条件解析成结构化查询再按照约束条件逐条筛选。这种场景对推荐召回率要求高对生成式发挥要求低非常适合 Agent。第二类是“深度决策型”。典型特征是客单价高、决策链路长、用户需要“购买理由”。比如商用设备选型、企业培训课程推荐、保险方案咨询。用户不是怕选不到东西而是怕选错东西他需要有人解释“为什么推荐这个”。传统列表页再怎么做详情也很难针对一个人给出动态的对比分析。Agent 能做的是在推荐结果里讲清楚取舍逻辑——你更看重续航所以推荐 A你更看重便携所以推荐 B。这种解释性推荐是传统检索式推荐系统很难做到的。我接触到的案例里凡是这两类场景Agent 的用户留存和推荐采纳率都明显好于传统方案。反向的教训也很多——有的团队把 Agent 套在一个本来就很简单的小商品类目上用户问一句“有没有白色的”Agent 还要绕三个回合才给出结果那体验反而不如一个筛选项来得痛快。1.3 什么场景建议直接放弃 Agent以下三类场景我建议不要硬上。第一简单标品的比价场景。买一箱水、一包抽纸用户只需要价格排序任何多余的对话都是在制造摩擦。第二强规则强合规场景。比如医疗器械推荐、处方相关推荐规则必须明确且有据可查Agent 的自由发挥空间几乎没有。这种情况做一套决策树都比 Agent 可靠还更容易过审计。第三硬实时场景。如果用户等结果的容忍度在几十毫秒级别比如嵌在交易流程里的即时推荐Agent 的多轮推理和 API 调用延迟根本扛不住强行上就是劣化体验。2. 需求分析拆解把“推荐得准”翻译成 Agent 能力清单2.1 四类信息收集与访谈提纲确定场景适合之后我们进入需求分析阶段。方法不复杂核心是四类素材。第一类是业务方访谈。重点问业务流程现状现在用户通过什么方式获得推荐人工客服在推荐时一般会先问哪些问题处理一单咨询平均耗时多久这类问题能帮你还原出“专家推荐”的过程而 Agent 本质上就是把专家推荐流程自动化。第二类是用户侧调研。重点看用户在真实场景里的表达习惯。同样一个需求业务方描述的是“帮用户筛选商品”但用户实际的问法可能是“适合送女朋友吗”“宿舍里能放吗”这种颗粒度差异决定了槽位设计能不能覆盖真实表达。第三类是历史数据。有客服聊天记录的翻客服记录有搜索词的翻搜索日志都没有的话可以去匿名问卷或用户访谈里补。搜索词尤其重要它反映的是用户脑子里最原始的需求描述方式比如“不粘锅哪个牌子好”“带烘干功能的洗烘一体机推荐”这些词天然就是评测集的雏形。第四类是竞品体验。把市面上已经跑起来的类似产品都体验一遍记录它们哪里顺、哪里反直觉。不是为了抄功能是为了在需求文档里写清楚“我们不做什么”。访谈提纲我整理了一个基础版可以直接拿去改用户通常带着什么背景信息来提问他们最常卡在哪个环节现在的人工客服/导购是怎么做推荐的第一步问什么最后怎么收尾有没有用户反复问但始终得不到好答复的问题这类问题排个序。哪些推荐行为是绝对不能出现的比如推荐无货商品、推荐超出预算太多的商品这一步走完需求文档的“背景与痛点”部分基本就齐了。2.2 从用户故事到能力地图我习惯把需求写成标准用户故事的格式“作为一位正在选购 X 的用户我想要描述我的条件和偏好后得到一个符合要求且有解释的推荐方案以便缩短选择时间、提升决策信心。”这句话看着简单但它背后能拆出七八条具体能力。我做了一张“需求描述—Agent 能力”的对应表这是后续产品设计和排期的直接输入用户表达/需求描述Agent 必须具备的能力涉及的技术模块“帮我在预算内推荐合适的”从对话中提取预算数值并转换为查询约束槽位提取、参数校验“预算可以稍微超一点”理解模糊边界支持约束放宽模糊条件解析、追问澄清“适合两个人露营用的”将生活场景映射到品类属性维度场景词典、属性映射“为什么不推荐那款”针对候选集进行对比并生成解释结果排序、对比理由生成“有没有更轻便的”基于上一轮结果做条件迭代多轮状态维护、继承式查询“那算了不买了”识别负面信号结束对话或转入人工情感识别、转人工兜底这张表的价值在于它把业务方口里的“智能”拆成了一个个可开发、可测试、可估工期的具体模块。我们在实际项目里就是拿这张表和业务方对优先级争议一下子小了很多因为大家讨论的不再是“感觉智能不智能”而是“追问澄清”到底算 P0 还是 P1。2.3 量化指标与需求优先级需求分析阶段最后一项工作是定指标和定优先级。没有量化标准的 Agent 项目后期验收一定扯皮。离线指标我建议至少看四类意图识别准确率、槽位提取的准确率和召回率、首轮推荐命中率即第一轮推荐结果里有没有用户最终采纳的商品、推荐理由与推荐结果的一致性。在线指标则看对话完成率用户最终拿到可采纳的推荐的比例、人均对话轮数太低说明废话多太高说明没听懂需求、转人工率、推荐结果点击率。采集这些指标需要提前设计日志埋点尤其是对话轮数和转人工率不埋点在事后根本追溯不到。优先级上我采用 P0/P1 两级就够了。P0 是“没有这个模块系统就跑不起来”的意图识别、槽位提取、召回排序、兜底响应。P1 是“没有也能跑但有它效果更好”的推荐理由生成、个性化排序、多轮追问。别把所有能力都排成 P0否则工期会失控。有一个很现实的心得业务方第一次提的“必须要有”里面至少有两成在真实上线后根本没人用。比如我们当初做过一个“语音播报推荐理由”的需求业务方希望增加与用户的互动感后来统计数据发现使用率不到百分之一。所有的需求都要回到数据面前接受检验。3. 技术选型的三层取舍模型、编排框架、检索底座3.1 底座模型API 与私有化部署的账要算明白需求敲定之后进入技术选型。第一层是底座大模型。我们当时有个原则先确定场景的数据敏感度再决定是接 API 还是私有化部署。如果推荐过程涉及用户个人信息、企业内部的供应链数据那从合规角度基本只能走私有化部署如果只是公开商品数据那调用 API 的成本和迭代速度都有明显优势。从成本角度要算两笔账。一笔是显性的 token 费用。推荐场景的单轮对话往往包含大段上下文用户每说一句系统要把商品候选信息填进上下文让模型生成推荐理由一次对话可能消耗数千甚至上万 token乘以用户量月度成本很快就能超过一台服务器的价格。另一笔是隐性的迭代成本接 API 时升级模型版本很轻松私有化部署一次模型替换等于一次完整工程改造人力投入远大于算力投入。实际选型中我给团队的建议是初期验证直接用 API快速验证“用户能不能接受这种交互方式”验证通过之后再评估要不要换私有化部署重点盯准这三个指标上下文长度是否够用、理解能力是否持平、函数调用function calling能力是否可靠。函数调用这一点要单独说。推荐场景的 Agent 一定会去做工具调用——查商品库、查库存、查价格如果模型在从对话里抽取“查询参数并映射为工具入参”这件事上不稳定后面所有流程都会跟着飘。选底座模型时最好用二十条刻意设计的用例去专门测试这一项而不是看它在通用问答上的得分。3.2 Agent 编排框架自研、开源与低代码的取舍第二层是 Agent 编排框架。摆在我面前的大方向有三个基于开源框架二次开发、自研编排逻辑、用低代码 Agent 平台拖拽配置。我的判断是这样的纯自研适合团队有较强的工程能力且后续要深度定制的大体量项目低代码平台适合快速做验证 Demo或者团队里基本没有算法工程师开源框架二次开发是大部分情况下的均衡解——它的社区生态能帮你省掉大量基础工作同时核心逻辑仍然在自己手里。这里给一个参考路线概念验证期可以直接用一个开源 Agent 编排框架跑端到端的流程看它是否能够稳定完成任务调用与多轮对话管理。等到需求复杂到开源框架的抽象满足不了再逐步把编排逻辑收回到自己代码里。我们当时就是这么做的早期用框架快速搭出原型到后期因为推荐结果的格式化要求特别多开始把关键链路代码抽出来自己做编排框架只保留对话管理部分。从结果看这套混合路线的迭代效率是最高的。3.3 向量检索与混合召回为什么只用关键词是不够的Agent 推荐的检索底座决定了一个问题系统从商品池里“捞”哪些候选给模型去生成结果。传统搜索只做关键词匹配是远远不够的用户表达的是“适合露营用的抗风帐篷”而商品库里的属性字段可能是“前后双叉杆结构”“防风等级 7 级”“适用场景露营/公园”字面上几乎没有重叠关键词检索直接断掉。所以需要向量库。把商品描述、规格参数、适用场景拼成一段文本用 embedding 模型生成向量查询时把用户的问题也向量化通过相似度把商品捞出来。我这里分享一个细节向量化模板一定要按领域精心设计不要把商品名和“发货地、库存状态”这种东西混在一起否则向量空间会被无关信息污染。经验是向量检索一定要配合关键词检索做混合召回。向量检索擅长语义匹配但容易在价格、型号等精确条件上翻车关键词检索在精确属性上稳但覆盖不了模糊表达。两者结果做合并去重再交给排序模块才能保证既找得到又找得准。召回数量上我们的经验是先捞回三十到五十条候选再给排序层太少容易错过太多浪费模型 token 和时间。4. 架构设计与核心数据流转一句话怎么变成推荐结果4.1 从用户输入到推荐结果的主链路架构上我们放弃了“用户问一句模型直接答一句”的最简结构而是设计了一条有状态的处理链路。当用户输入一句“周末想带家人去露营预算一千五左右有什么帐篷推荐”的时候系统内部实际经历的是这样一个过程先判断这句话属于什么意图是推荐请求、条件追加、价栿异议还是闲聊再抽取关键约束场景是“周末露营”人数是“家人”映射为 3 到 4 人预算是一千五左右然后做兜底校验预算数值落在一个允许区间接下来生成查询条件去商品库和向量库做混合召回召回的候选经过排序后被拼接成结构化的候选上下文最后模型基于候选上下文生成推荐结果和理由。这条链路里最关键的设计是拆成了“理解层—检索层—生成层”三段。理解层只负责把自然语言变成结构化意图加参数检索层只负责基于结构化参数去拿候选生成层只负责把候选转成用户能看懂的推荐话术。这样做的好处是每一层都可以独立评测和调优哪一层出了毛病能精准定位而不是对着一个黑盒子挠头。4.2 意图识别与槽位提取把自然语言变成结构化请求意图识别我们采用了两级体系。第一级是粗分类判断用户这句话到底是在求推荐、追加条件、换一批、问理由、闲聊还是表达不满。第二级是细分类只有在确认是推荐意图后才进入槽位提取环节。槽位提取这一环直接决定推荐的准度。推荐场景里高频槽位就那么几个品类、预算、使用场景、使用人数、关键优先级属性、已有意向型号。提取之后不要直接拿去查库先过一层参数校验。比如预算通常表现为“一千五左右”“别超过两千”“一千到一千五”要统一换算成一个区间使用场景要做词典映射露营、野餐、徒步都在同一个场景树下如果条件之间冲突比如“既要轻便又要防风级别最高还要一千以内”系统应该主动追问澄清而不是硬着头皮查库。这里有个真实教训要拿出来说。早期我们把预算这类参数设计成必须精确的整数结果用户说“一千五左右”的时候系统提取出 1500 就直接查库把 1450 和 1600 的商品全过滤掉了。后来改成区间映射把“左右”扩展成上下浮动 10%推荐效果立刻好了很多。模糊表达是对话式推荐的常态别用数据库字段的严谨性去要求用户。4.3 推荐结果的生成与解释性设计排序之后最后一个生成环节决定了用户看到的最终效果。我见过很多团队在这里偷懒直接把候选商品名堆成列表给用户看那跟传统列表页有什么区别呢Agent 的核心价值在于“给结论也给理由”。推荐话术的生成我们让模型严格跟随一个固定框架先说“根据你的需求我优先推荐 X”一句话总结核心匹配点再给一段简短的决策说明讲清楚“为什么是它”价格匹配、场景匹配还是某个决定性属性匹配最后给一个可选的下一步引导比如“如果你想要更轻便的可以试试调高一点预算”。这个框架看起来简单却能让用户感受到这是一个有推理逻辑的推荐。排序逻辑也要在话术里体现。我们把排序权重设为可配置的预算匹配度、场景匹配度、热门度、库存可用性各自有比重。这样测试时会发现用户问“性价比高的”和“口碑好的推荐一下”给出来的排序结果能体现出差异不会总是一套顺序打天下。4.4 安全护栏与兜底策略推荐场景一旦面向真实用户安全护栏就是最后一道防线。我们至少加了四层。第一层是输入侧的安全检查敏感词和恶意指令识别命中后直接触发兜底话术转人工。第二层是参数范围校验预算超过商品库价格上限一百倍之类的数据在进入工具调用前就要拦住。第三层是候选集校验如果最终候选集为空坚决禁止模型自己“脑补”一个商品必须明确告知用户“当前条件下没有匹配的商品是否需要放宽限制”。第四层是输出侧校验对模型生成的推荐结果做商品名和价格的交叉核对防止出现幻觉。整个架构设计里我会优先保兜底策略因为它决定了你的系统在最坏情况下是什么表现。一个知道自己“不知道”的 Agent比一个硬撑着胡说八道的 Agent 可靠得多。5. 落地开发实战从 Prompt 原型到可联调版本5.1 先跑通一个“对话式推荐”的最小闭环我一直建议开发顺序别先碰模型先把整个链路的“骨架”搭出来。具体做法是做一个 mock 版意图识别和槽位提取先用规则和正则顶上商品检索直接查数据库推荐话术先用模板拼出来“用户说一句系统答一句”的最小闭环先跑通。mock 版的最大价值是验证产品交互和链路设计而不是模型效果。交互上用户问十个问题、系统答得生硬没关系只要链路是通的、状态是能维护的后面的模型优化都只是往这个框架里填货。如果这一步发现链路设计有硬伤比如多轮追问之后状态丢了那在 mock 阶段改流程的成本比接完模型再改要低一个数量级。我们当时 mock 版一天半就搭出来了拿给业务方看对方第一次直观感受到“原来你说的对话式推荐长这样”也是在这个阶段把需求里的很多误解提前暴露了。5.2 系统 Prompt 模板与少样本设计链路通了之后再让模型进场第一个深入打磨的是系统 Prompt。注意这里的系统 Prompt 不是写一段“你是一个资深的购物助手”就完事而是要把任务边界、工具逻辑、输出格式、限制规则全部写清楚。我给出一个我们实践下来可复用的模板结构大段内容按“角色定义—任务流程—工具说明—输出格式—禁止项”五个区块组织。你是一位商品推荐助手。你的任务是根据用户的需求从候选商品中选择最匹配的商品并给出推荐理由。 流程要求 1. 先理解用户的意图和约束条件必要时主动追问澄清 2. 查询工具返回候选商品列表基于候选列表生成推荐 3. 推荐结果必须从候选列表中选择禁止编造候选列表之外的商品 4. 如果候选列表为空明确说明没有匹配商品并询问用户是否放宽条件。 输出格式 请严格按照以下结构输出 推荐商品名... 核心匹配点... 决策说明... 可选下一步... 禁止事项 - 禁止编造价格、库存、参数 - 禁止在用户表现出不满时继续强行推荐 - 禁止输出与推荐无关的长篇大论。少样本示例也必须在 Prompt 里放两到三条覆盖“条件满足直接推荐”和“条件冲突需要追问”两种典型情况。模型从示例里学到的格式习惯远比从描述里学到的稳定这是实测下来的结论。5.3 工具调用实现与多轮追问工具调用我们选择了结构化工具定义的方式。要让模型自主决定“什么时候查库、查什么”关键是把工具入参定义得足够明确。一个商品推荐场景的查询工具通常需要提供品类、价格区间、场景标签、排序权重、数量这些入参。开发中一个容易踩的坑是工具入参和对话历史的冲突。比如用户第一轮说“推荐露营帐篷”系统已经发起过一次查询第二轮用户说“换成双人的”如果 Agent 不带上第一轮的品类约束直接只把“双人”作为入参去查库结果就会跑偏。所以工具调用前我们必须把多轮累积的有效约束合并成一份完整的查询参数而不是只基于当前这一句话。多轮追问的触发逻辑也要写死。不是每个模糊条件都要追问而是当某个槽位缺失且对推荐结果影响显著时才追问。比如用户没说预算系统可以先按默认范围推荐同时问一句“如果预算需要控制请告诉我区间”这比直接要求“请提供预算”的体验好很多。5.4 前端交互状态机与流式输出前端交互上不要简单地把 Agent 做成一个聊天窗口。推荐场景需要的是一个带状态的交互页面我建议至少维护四个状态等待输入态用户还没有提问可以展示推荐入口和热门问题处理中状态系统正在解析意图、查库或生成结果这个阶段要有明确的进度反馈不能让用户对着一个空白聊天框发呆追问澄清态系统需要用户补充关键信息展示澄清的选项而不是让用户自由发挥结果展示态推荐结果用卡片承载商品名、价格、理由、点击入口放在固定区域。流式输出在推荐场景里要谨慎用。对于“推荐理由”这种长文本可以逐字展示增加交互感但是推荐商品卡片不要流式卡片必须等完整结果校验通过后再一次性渲染否则用户会看到价格一点点蹦出来体验反而割裂。6. 联调测试与踩坑实录三个差点翻车的坑6.1 评测集构建与离线回归方法没有评测集的 Agent 项目就是裸奔。我们在开发过程中维护了一个标准评测集一百条典型问题覆盖各个品类和各种约束表达另有三十条边界问题专门放“预算没给”“条件互相冲突”“问法有歧义”“包含负面情绪”这类极端情况。离线回归的流程是每次调整 Prompt 或改排序逻辑就用评测集跑一遍全量自动化对比意图准确率、槽位正确率、首轮推荐命中率三个核心指标。这个习惯救了我们很多次有两次改完 Prompt 自以为效果提升了回归一跑才发现首轮命中率掉了好几个百分点立刻回滚才没把问题带上线。边界用例的构建尤其重要。比如用户说“推荐便宜点的”这个“便宜点”是相对上一轮结果而言的槽位提取如果只做绝对值解析就会漏掉这个意图。评测集里这类“非常规但真实”的问题才是 Agent 效果的分水岭。6.2 坑一模型把不存在的属性编得煞有其事上线前最严重的一个坑是模型在生成推荐理由时编造属性。候选商品信息里根本没有“收纳体积”这个参数模型却在推荐理由里写“这款帐篷收纳后体积小巧适合背包出行”。用户照着去对比实物发现完全不是那么回事。排查链路是这样的先看日志确认候选商品确实不包含收纳体积字段再看生成链路发现模型把“背包出行”这个查询条件脑补成了推荐商品应当具备的隐含属性。根因有两层一是候选上下文里缺少字段约束声明二是 Prompt 里没有明确“只能引用已有字段”。修复方案是双管齐下。候选商品拼接进上下文之前统一做一次字段清洗只保留允许被引用的属性字段同时字段名本身要加“不可编造”的语义约束模板里把这一步写得很僵硬“生成理由时只能引用以下字段中的内容。以下字段不存在的属性一律视为未知。”修完之后这类幻觉基本绝迹。也是这次踩坑让我们下定决心加了输出侧交叉校验推荐理由里涉及的关键属性都必须能在商品字段里找到对应值。6.3 坑二多轮对话的上下文污染第二个坑出在多轮对话的状态管理上。我们的 Agent 在第二三轮开始出现“串台”用户第一轮在问露营帐篷第三轮切换成“那车载冰箱有什么推荐”系统推荐结果却还在讲帐篷。排查后发现问题出在历史消息全部堆在上下文里模型无法区分哪些约束是当前有效、哪些是上一轮已经作废的。尤其是“换一批”和“追加条件”这两种表达都会被模型理解成在上一轮基础上做修改加上历史里帐篷的候选信息没有被清除生成结果就被带偏了。修复方案是引入“本轮有效约束快照”机制。每一轮工具调用前系统先根据对话历史生成一张当前有效约束表旧约束自动失效候选上下文也做分区上一轮候选信息对新一轮生成不可见。同时给模型在 Prompt 中加了一条规则“当用户切换话题时所有历史约束作废仅以当前描述进入新查询。”这个改动之后多轮对话的稳定性有了质的提升。6.4 坑三Agent 在工具调用里无限循环第三个坑是整个联调阶段最折磨人的一个。某次测试中模型陷入了“查库存—被告知无货—调整条件—再查库存—再被告知无货”的循环单轮对话发出去几十个工具请求。日志里看模型并没有意识到自己在原地打转。面对这个问题排查后发现它的根因不是模型傻而是工具的结果回传格式太简略模型拿不到“为什么无货”和“什么样的条件有货”只能凭猜调整参数猜错了就再来一轮。修复方案有两步。第一步是在工具返回结果里加“失败原因提示”明确写出“无货是因为预算区间内无满足场景标签的商品请提示用户放宽预算或调整场景”。第二步是在编排层做工具调用次数的硬限制。单轮对话最多允许三次工具调用超过就强制转人工。这个上限设置之后联调效率大幅提升测试的时候也不用担心模型把套餐刷爆。这三个坑有个共同点都不是模型本身能力不够而是工程侧没有给模型足够的约束和反馈。Agent 项目里模型是发动机但方向盘、刹车、仪表盘都得靠工程去补这个认知越早建立后面就少踩一半的坑。写在最后的体会项目收尾的时候我重新翻了翻最初的业务需求文档那句“随便聊两句就把东西选好”还在但背后已经完全不是当初那个简单的设想了。我个人的体会是AI Agent 产品推荐方案能不能成模型选得多前沿只占一部分更大的权重在需求分析是否把边界划清、架构设计是否把链路拆开、工程细节是否把兜底做牢。最后分享一个很实用的小建议从第一天起就给 Agent 建立完整的自评日志每个推荐都记录下“用户原始输入、结构化参数、召回候选、排序依据、最终输出”这五段数据。这套日志不仅是问题排查的依据更是下一轮 Prompt 优化的训练素材。有了它Agent 才真正是可迭代的产品而不是写完之后就再也不敢碰的黑盒子。