AI Agent产品从需求分析到落地：方法论、技术选型与实战踩坑

最近帮一个团队做了一套AI Agent产品的推荐方案，从需求分析一路推到落地开发，整个过程走下来比预想的有意思得多。我最大的感受是：绝大多数团队不是卡在技术难以上，而是卡在最开始的需求分析。很多人一听"用AI Agent做产品"，第一反应是打开某个模型聊天界面问"你能帮我做什么"，但真要把一个可用的产品做出来，完全是另一套打法。

这篇文章把我从0到1做AI Agent产品推荐方案的全过程、思考逻辑、技术选型和踩坑记录完整写出来。适合三类人看：准备用AI Agent改造内部流程的产品经理，想从零上手Agent开发的工程师，以及手上有业务场景但不知道从哪一步落地的团队负责人。先说结论：一个能落地的AI Agent产品，60%的功夫在需求分析，20%在架构选型，只有20%在纯编码。下面把这套方法论完整展开。

1. 先把概念盘清楚：Agent、LLM、AI模型到底差在哪？

1.1 三层概念的真实边界

我遇到太多人把这三个词混着用，觉得"AI Agent就是大模型套了层壳"。这是做需求分析前必须掰扯清楚的问题，因为概念层决定需求文档怎么写，也决定后面整个系统的结构。

用个比较接地气的类比：AI模型是发动机，LLM是发动机里的一个主流类型，而Agent是一辆装了发动机、导航、方向盘，还能自己规划路线开到目的地的车。你光有一台发动机，它能转，但不会自己跑；你有了一辆车，才谈得上"完成任务"。

具体拆开说：

• AI模型：指所有经过训练、具备某种智能能力的模型，包括语言模型、图像模型、语音模型、多模态模型。它是把输入转成输出的"函数"，本身没有行动能力。
• LLM（大语言模型）：AI模型中的一个大类，以海量文本训练而来，核心能力是理解和生成自然语言。GPT系列、Claude系列、DeepSeek、通义千问、文心一言都属于这一层。
• AI Agent：以LLM为大脑，但额外具备规划（Planning）、调用工具（Tool Use）、记忆（Memory）、反思（Reflection）能力的系统。它不是一个模型，而是一个"系统"。

很多人理解的"Agent"其实就是"聊天机器人"，这是最大的偏差。聊天机器人是"你问我答"；Agent是"你给我一个目标，我自己拆解步骤、调工具、做决策、产出结果"。比如你让它"帮我整理一份适合新员工的办公设备推荐方案"，它需要：拆解成"了解新员工岗位→查询可采购设备清单→匹配需求→生成推荐理由→输出表格"。这一长串动作里只有一部分是"对话"。

1.2 "DeepSeek属于哪一层"这种问题的标准答案

搜索热词里居然高频出现"DeepSeek是属于哪个"，说明这个概念困惑不是少数人的问题。标准答案很干脆：DeepSeek是一个具体的LLM模型，属于AI模型层。它不是Agent。

但注意一个容易混淆的点：当你在DeepSeek官网的聊天对话框里提问时，那个产品本质上是一个"聊天应用"，里面用了DeepSeek模型，但它依然离Agent有距离，因为它缺了规划、工具调用、记忆这些能力。它更像一个知识面很广、表达很好的专家，但专家坐在那里等你问问题，不会自己去查库存、写邮件、改配置。

反过来，你在自己的系统里调用DeepSeek的API，给它配上商品库查询工具、数据库、审批流程接口，让它根据用户描述自动生成采购推荐方案并提交审批——这个整体就不是"用了个DeepSeek"，而是"以DeepSeek为大脑做了一个AI Agent产品"。

这个区分在工作中的价值是：当你和别人沟通方案时，如果双方把模型和Agent混为一谈，需求很容易偏。比如业务方说"我们就要做个DeepSeek应用"，实际上他要的是"用DeepSeek做大脑，解决产品推荐效率问题"。这两个目标的实现路径完全不一样。前者可能一个对话框就完事，后者要设计数据流、工具链、决策逻辑和人工兜底。

1.3 概念不分清楚，需求分析必然翻车

我在评审一些团队方案时经常看到这种情况：需求文档里写着"接入大模型，实现智能客服"，但完全没有提大模型搞不定的部分由谁负责。比如用户问"我上个月买的设备什么时候能到"，模型不知道物流信息，因为没接物流查询工具；模型不知道这个用户是谁，因为没传用户上下文；模型胡编了一个物流状态，因为没有人告诉它"不知道就承认不知道，然后转人工"。

这些问题不全是模型的锅，就是概念没分清楚导致的。如果把"Agent系统"当成"模型"来设计，需求分析阶段就漏掉两块关键内容：一是Agent需要哪些外部工具来弥补模型的知识盲区，二是哪些环节需要人在回路（Human-in-the-loop）。

所以在进入需求分析之前，我建议团队先做一次统一认知的工作坊，就花半天时间，把三个问题对齐：我们要做的是"对话工具"还是"任务执行系统"？模型的能力边界在哪里？哪些能力需要靠工具和流程补？这一步做扎实了，后面的需求分析才是真正的需求分析，不然就是给模型写提示词大赛。

2. 需求分析做不对，后面全白费：四步拆解法

2.1 先分清用户要的是"聊天"还是"办事"

这是我做需求分析问的第一个问题。对话型需求的交付物是"一段回答"，任务型需求的交付物是"一个成果物"。AI Agent产品绝大多数属于后者，但很多团队按前者的思路去做，结果做出来就是个高级话痨。

拿产品推荐方案举例。用户说"我们部门想采购一批降噪耳机，预算5000左右，主要给经常出差的人用"。如果这是个对话型产品，AI回答"好的，我推荐索尼和Bose两个品牌"就算完成了；但如果这是个任务型Agent产品，用户要的是一份可执行的推荐方案：包含具体型号、价格、参数对比、为什么适合出差人群、最终推荐排序、购买链接或审批所需信息。这里"办事"比"聊天"多了一条完整的动作链。

判断办法很简单：问自己"用户用完这个功能，得到的是一个句子还是一个成果物"？得到成果物的，就是Agent级需求。需求分析阶段如果连这个都没分清，后面做出来的系统不是过度设计就是设计不足。

2.2 把业务动作拆成Agent能力清单

确认是"办事"型需求后，下一步是把业务动作逐层拆成Agent的能力清单。我习惯用一个四步拆法：先描述用户的完整任务，再拆成动作序列，然后把每个动作映射到Agent能力，最后标出哪些动作模型自己做不了，需要挂工具。

以"产品推荐方案Agent"为例，用户的完整任务是"提交需求，得到一份推荐方案"。拆成动作序列：

1. 收集用户需求（预算、场景、规格、偏好）
2. 解析和结构化需求（抽取关键约束条件）
3. 检索候选产品库（本地商品库、供应商数据源）
4. 对候选产品做加权匹配（预算权重、场景权重、评价权重）
5. 生成推荐理由和对比说明
6. 输出结构化方案（表格、清单、购买链接）
7. 记录用户偏好供下次推荐参考

然后做能力映射：

• 动作2和动作5是模型的强项，直接靠LLM完成；
• 动作3靠模型做不了，需要"商品检索工具"或数据库查询能力；
• 动作4如果规则明确，建议用代码实现，不依赖模型判断，因为模型算数不稳；
• 动作7需要"长期记忆"，可以落到数据库或向量库。

把这些写进需求文档，就是Agent的能力清单雏形。这条清单在后面技术选型和架构设计时是核心输入，因为框架、工具链都是围绕它来选的。

2.3 划出边界：哪些事Agent绝不能碰

需求分析不只是设计Agent能做什么，更要写清楚Agent不能做什么。这是很多团队容易忽略的，也是后面最让工程师头疼的地方。

划边界主要看三类事：风险类动作、成本类动作、隐私类动作。对应到产品推荐Agent场景：

• 风险类：Agent可以生成推荐方案，但最终的大额采购审批必须由人工确认。不能让Agent直接调用下单接口完成支付。
• 成本类：推荐逻辑里涉及折扣、优惠、特殊价格时，Agent只能参考现有价格表，不能自行"创造"价格，避免它为了满足用户预算而编一个不存在的折扣。
• 隐私类：Agent可以读取脱敏后的用户历史偏好，但不能直接访问用户的详细身份信息、支付记录。数据权限的最小化原则要写进需求文档。

边界规则必须写在需求文档里，而不是留给开发时临场发挥。我见过一个反例：团队做了一个内部报销Agent，模型可以直接操作财务系统生成报销单，结果在一次测试中模型从对话里抓错了报销金额，好在有审批人拒绝才没造成损失。事后复盘发现，需求文档里根本没写"Agent只能草拟报销单，不能提交免审"。这就是边界缺失的典型代价。

2.4 落到文档和原型：推荐方案的输出形态

需求分析的产出物要具体、可验收。我通常会带着团队输出四样东西：用户故事、Agent行动序列、数据流清单、验收标准表。原型反而不是最着急的，但至少要做一版"对话流程+界面线框"去和业务方对齐。

• 用户故事：按角色写，比如"作为采购专员，我希望Agent根据我填写的预算和场景生成推荐清单，这样我不用手动检索几十个商品"。
• Agent行动序列：用文字描述从用户输入到最终输出的每一步，相当于把2.2的动作序列细化，包含每个动作的输入和输出。
• 数据流清单：列出Agent运行会碰到的数据表、外部接口、字段说明。比如"产品库：包含product_id、name、price、category、rating字段"。这一项容易被忽略，但它是开发阶段和后端对接的重要依据。
• 验收标准：明确"怎么样算做好了"。比如"推荐方案中至少包含3个候选，每个候选带价格和推荐理由；响应时间不超过15秒；用户对推荐结果的满意率（点击采纳/手动修改次数）达到70%以上"。

原型方面，我用过ProcessOn、Figma，也用过最朴素的Word画线框图，核心目的只有一个：让业务方看到"用户会看到什么，Agent会在后台做什么"。方案Agent的原型通常包含一个输入表单、一段对话预览、一个结果展示区域、一个人工确认按钮。有这版原型再进开发，后面返工的概率会少一半。

3. 技术选型的三条路线，按场景选别跟风

3.1 路线A：n8n这类可视化编排工具，先跑通再谈扩展

很多初学者听到"做AI Agent"就以为必须写代码。实际上现在有一批可视化编排工具已经能把Agent原型搭出来，最有代表性的就是n8n。n8n本身是开源的工作流自动化平台，后来集成了AI Agent节点，你可以在界面上拖拽出"用户输入→调用LLM→调用工具→输出结果"的完整链路，节点之间用连线搞定。

我用n8n做过一个产品推荐Agent的原型，半天就通了。做法是：用Webhook节点接收用户输入，丢给LLM节点做意图和参数抽取，再连一个HTTP请求节点去查询商品库，最后让LLM生成推荐文案，把结果返回给前端。整个过程没有写一行业务代码，纯粹靠配置节点。

这条路线适合三类情况：一是验证需求可行性，确认"这个Agent逻辑能不能跑通"，这时候不值得花两周写代码；二是内部工具，数据量不大、流程不复杂，维护成本低；三是团队没有专职后端工程师，业务人员也能改流程。

但它的瓶颈也很明显：复杂条件分支、自定义算法、高并发、精细权限控制在低代码平台上都很别扭，硬塞进去会变得非常难维护。所以我的建议是：用n8n快速验证，验证完了再严肃评估"这个复杂度是否需要换框架"。

3.2 路线B：Agent框架（LangChain等），产品化主力

如果确定要做成产品级应用，主流路线是用Agent开发框架。目前生态最丰富的是LangChain和LlamaIndex，国内也有Coze、扣子这类平台。框架解决的是Agent开发的通用问题：Prompt模板管理、模型调用封装、工具定义与注册、记忆管理、链式调用（把多个步骤串起来）。

拿LangChain举例，它的核心概念是Chain和AgentExecutor。Chain是预定义好的"步骤链"，比如先把用户输入格式化，再调用模型，再把输出解析成JSON；AgentExecutor则更进一步，让模型自己决定调用哪个工具、什么时候结束。这个"让模型决定下一步"的模式，其实就是ReAct（Reason and Act，推理与行动）思路的实现——模型先思考"我需要查一下商品库"，然后执行工具调用，看到结果后再继续思考"现在可以生成了"。

这条路线适合需要定制化开发的场景，比如产品推荐Agent要和公司内部数据库、审批系统、邮件系统对接，这些编排工具做不了太深的定制，而框架的生态组件能帮你省很多对接时间。需要提醒的是：框架不是银弹，它只帮你解决通用问题，你的业务逻辑还是要自己写。很多人以为用了LangChain就等于做好了Agent，其实框架只是骨架，血肉还得自己填。

3.3 路线C：裸调模型API，自己写编排（适合深度定制）

第三条路线是放弃框架，直接在产品代码里调用模型API，自己实现规划、工具调用、记忆管理。也就是说，Agent的每一步都是自己写的代码在控制，模型只负责"智能"的部分。比如你写一个Python服务，用户提交需求后，代码先调用模型API做意图理解，再根据意图去查商品库，把结果拼进提示词再让模型生成推荐。中途没有LangChain帮你管理，也没有现成的工具调用逻辑，一切都是自己实现。

这条路线的优势是可控性最强。你可以针对业务做深度优化，比如自定义缓存策略、精细化的错误处理、精确的Token用量控制，也可以把Agent嵌入到非常复杂的业务系统里，不受框架的设计约束。

代价是工作量最大。光是要做好"模型返回的JSON解析和容错"这一件事，就够一个工程师忙几天。所以我有一个个人的判断标准：如果团队少于两个人，又不需要极致的定制，别轻易选C，直接用框架或者编排工具能把命续住。

3.4 用一张对照表把选型逻辑定下来

我习惯把选型逻辑汇总成一张表，摆在会议室里跟团队和业务方一起看，避免"谁嗓门大听谁"的选型局面。

选型没有绝对的最优解，核心是"团队能长期维护"优先于"技术最先进"。框架再火，没人会写，最后也是灾难。我还是强调：先在n8n上花一天把链路跑通，再决定是继续留在n8n还是迁到框架，别一上来就纠结选型。很多时候，选型的答案是在原型跑完之后自己浮出来的。

4. 一个Agent产品真正值钱的三块：Skill、Memory与MCP

4.1 Skill：把"SaaS能力"做进Agent的封装套路

做Agent产品里经常听到一个词叫Skill，理解它的价值是Agent架构设计的关键。我把Skill通俗地翻译成"技能包"：一个Skill就是Agent完成某一类任务的可复用能力，它通常包含技能描述、所需的工具列表、调用流程、输出格式。

举个例子，产品推荐Agent里有"生成推荐方案"这个Skill，它的技能描述是"根据用户需求和数据库中的产品信息，生成排序后的推荐列表和推荐理由"；它依赖的工具是"商品检索工具"和"价格查询工具"；它的输出格式是"一个JSON结构，包含候选列表、推荐理由、总价"。模型中控通过理解用户的意图，把任务分发给对应的Skill。

Skill的价值在于模块化和复用。你今天给Agent加了"员工入职推荐"这个Skill，明天换一个场景做"年终礼品推荐"，不需要重写底层，只需要复用商品检索和推荐生成两个Skill，加一条新的意图路由规则就好。这也是为什么我说：真正值钱的不是"接了个大模型"，而是沉淀下来的Skill体系。它才是Agent的核心资产。

4.2 Memory：短期、长期、程序性记忆的落地取舍

热词里高频出现"skill memory mcp"，说明大家已经意识到记忆是Agent的核心组件。Agent的记忆通常分三种：短期记忆、长期记忆、程序性记忆。

• 短期记忆：就是当前对话里的上下文。它存在内存里，对话结束就丢。这个最基础，所有Agent都该有。
• 长期记忆：跨会话持久化的信息。比如产品推荐Agent在两个月前帮你推荐过一批办公设备，下次你再来找它推荐，它记得"这位用户上次选了商务风格，预算中等"，能显著提升推荐的个性化程度。落地方式一般是用向量数据库存用户偏好，再通过相似度检索把相关记忆拉回上下文。
• 程序性记忆：Agent遵守的规则和流程。比如"预算不足时不允许推荐超出预算30%以上的产品""如果用户没有明确需求，先询问再推荐"。

我的落地取舍原则是：第一版只做短期记忆，加上少量必要的长期记忆（用户ID、关键偏好字段），不要一上来就搞复杂的向量库和语义检索。很多团队在原型阶段就把记忆库建得特别重，结果发现模型根本还没跑起来，记忆架构先拖慢了开发进度。等核心链路稳定了，再逐步加深长期记忆的复杂度。另外，长期记忆一定要设计"遗忘机制"——给用户提供手动清除偏好或关闭个性化推荐的入口，不然Agent的"记性好"也可能变成用户眼中的"被监视"。

4.3 MCP：为什么它正在变成Agent时代的"USB-C接口"

MCP的全称是Model Context Protocol，就是"模型上下文协议"。简单说，它定义了一套统一的标准，让Agent通过这个协议去连接外部的数据源和工具。有了MCP，你不需要为每个数据源（数据库、ERP系统、表格、API）单独写一套集成代码，只要对方提供了MCP服务器，Agent就能直接"插上"使用。

它最好的类比就是USB-C接口。以前不同的设备有不同的充电线，现在一个USB-C口能充手机、笔记本、耳机。MCP的意义也是统一的接口标准，让工具生态形成合力。现在很多主流Agent框架和模型服务端都原生支持MCP，这意味着你定义一个工具调用，形式和复用成本都大幅降低。

在产品推荐Agent里，MCP可以在下面几个场景发挥作用：商品数据源MCP（代理访问商品库）、价格策略MCP（读取价格规则）、备忘录MCP（记录用户偏好）。通过统一协议接入，Agent可以做到"我今天接SQL数据库，明天换一个API数据源，改一行配置就能切换"。

但MCP也不是万能药，它引入了接口抽象层，多一层就会多一些复杂度和潜在故障点。我的建议是：小规模原型阶段不要强上MCP，直接写工具函数最干脆；但当你的Agent要接外部工具和数据源的数量超过三四个，或者你预见到未来会频繁扩展工具，就应该在架构设计时把MCP纳入标准层。

4.4 一个我屡试不爽的默认Agent架构

综合上面这些组件，我给大多数"推荐方案类"Agent产品设计了一套默认架构，基本可以拿来即用，按需调整：

用户交互层（前端表单 / 聊天窗口，负责收集需求） → Agent核心（意图路由：决定用哪个Skill / 是否需要追问） → Skill管理层（技能包的注册、调度、执行） → 工具层（通过MCP或直接函数调用访问商品库、数据库、推荐规则） → 模型调用层（LLM负责推理、生成解释、处理模糊需求） → 结果校验层（校验输出格式、价格合理性、是否超额） → 记忆存储层（短期对话缓存 + 长期偏好存储）

这套架构里最关键的是结果校验层。我始终坚持一个原则：LLM的输出不能直接用，必须经过一层校验。原因很简单，模型生成的内容可能存在格式错误、事实编造、越界推荐。校验层可以做规则判断（价格是否在预算内）、格式解析（JSON是否符合schema），必要时再丢回给模型做一次"自我修正"。加了这层以后，整个Agent的稳定性能上一个量级，这部分我在踩坑章节会再展开。

这个架构适合大多数"推荐方案"类产品，简单清晰，也方便团队并行开发。遇到具体瓶颈时再改局部，不要一上来就挑战复杂架构——先让它跑起来，再让它变聪明。

5. 落地开发四阶段：从原型到能上线的增量路径

5.1 阶段一：需求确认与交互原型（别急着写代码）

我在这个阶段吃过亏。以前带项目时，需求文档写到一半，开发同学就忍不住去配环境、跑Demo了，结果原型做出来给业务方一看，完全不是那么回事。现在我会强制团队进入两周的"原型确认期"，这个阶段不允许写业务功能代码。

具体动作是把需求分析阶段的成果转成交互原型。对于产品推荐Agent，我会做一个最简单的可点击Demo：用户填一个表单（预算、场景、人数），点击提交，看到模拟的"Agent正在分析"过程，然后展示一份假数据生成的推荐结果。哪怕后台没有接任何模型和真实数据，就靠前端写死的数据，也能完成一次认知对齐。

这个原型最重要的作用是让业务方在"看到界面"之后提出真实的修改意见：他们可能会说"推荐结果里要加个总价""要能看到被排除的候选产品及原因""要有导出功能"。这些都是早期能拦住、后期改起来很贵的需求变动。原型确认以后，剩下的开发才值得投入。

5.2 阶段二：最小闭环——先打通一条端到端路径

原型确认完，开发阶段第一件事不是把需求文档里所有功能都实现，而是打通一条最小闭环路径。这条路径必须从用户输入开始，到模型调用工具、返回结果，到最终展示在界面上，完整走通。中间可以做得粗糙，但链路必须是真链路。

具体到产品推荐Agent，最小闭环可以这样定：用户输入"预算5000，需要降噪耳机，给经常出差的人用"→Agent调用商品库工具查询符合基本条件的耳机→把候选返回给模型→模型生成三个推荐选项和一个理由→前端展示。这个闭环不需要覆盖所有产品类别，不需要长期记忆，不需要复杂的权限体系，只需要"通了"。

为什么要先做这一条路？因为这条路径会暴露整个系统最底层的连接问题：API参数对不对、工具返回的结果模型能不能解析、输出格式前端能不能渲染、延迟用户能不能接受。这些问题在你做十条技能路线时会被放大十倍，但在一条最小闭环里调试，成本是最低的。走完这一步，整个团队心里就有底了。

5.3 阶段三：工程化加固——错误处理、重试、日志与人工复核

最小闭环跑通后，进入工程化阶段。这一步决定Agent能不能真正"住在"生产环境里，而不仅是Demo。DLI do list排序大概是这样的：

• 格式稳定：模型返回的JSON要经过schema校验，字段缺失就自动触发一次重试。我会在代码里定义一个Pydantic模型或JSON Schema，把"推荐方案"的字段固定好，模型输出解析失败就重试，重试两次还失败则返回一个兜底文案并人工告警。
• 工具调用异常处理：商品库查询超时、返回空、接口报错，每一种情况都要有对应处理策略。空结果就明确告诉用户"暂时没有匹配产品"并引导放宽条件；超时就重试并降级为模糊查询。
• 日志全链路：每次请求记录用户输入、模型输出、工具调用的耗时、Token用量、失败原因。这不仅是排查问题的手段，也是后续优化成本和质量的数据基础。
• 人工复核入口：在界面上提供"人工建议"或"有误反馈"按钮，用户点了之后，这条记录进入人工处理队列。对Agent产品来说，有人兜底是长期信任的关键。

工程化阶段的密集工作看似枯燥，但Agent产品的稳定性差别基本就在这里拉开。我见过不少同类项目，Demo惊艳，一上生产就崩，原因都是这几个点没做扎实。

5.4 阶段四：上线验收——定义"推荐准不准"才算数

最后是验收。Agent产品的验收不能只看"能不能跑通"，因为"跑通"和"做得好"是两个层次。我做产品推荐Agent时，验收指标会从下面几个维度收集：

上线方式上，我强烈建议灰度：先让10个左右的内部用户用一周，重点收集"推荐结果明显不合理"的cases，根据问题收敛后再扩大范围。灰度期不要急着宣传功能多强大，而是建立问题反馈通道，哪怕是一个简单的表单收集页也行。

这一步的核心是让"好"变得可衡量。没有指标的Agent功能上线后就是一个无底洞，业务方说"感觉不太好"，但你说不出具体哪里不好、改没改。有了指标，优化才有方向。

6. 实测踩坑记录：这些问题我在真实项目里都撞过

6.1 上下文窗口不是"塞得越多越聪明"

第一次做推荐Agent时，我犯过一个教科书级别的错误：为了让模型知道更多产品，我把商品库里几百个商品数据全部塞进了系统提示词（System Prompt）里。第一版跑下来，模型生成的推荐又慢又差，经常忽略掉真正合适的选项，反而被冷门产品带走。

后来想明白了：大模型的注意力是有限的，海量信息塞进上下文，它会"看不过来"，而且长上下文显著推高Token成本和延迟。正确的做法是先让工具做粗糙的预筛选，只把最相关的Top 10到20个候选产品拼进提示词，让模型在精挑过的池子里做判断。我改完以后，推荐准确率明显上升，响应时间也从20多秒降到了8秒左右。

经验是：把上下文的宝贵空间留给精选信息，不要让模型当搜索引擎。该用检索工具的地方，绝不用提示词硬塞。

6.2 模型调用工具的结果必须有一道校验层

真实踩过的最疼的坑，是模型调用工具时参数格式不稳定。比如商品库工具需要product_id，模型有时候返回字符串"123"，有时候返回整数123，有时候干脆返回一个"id_123"的字段名，类型对不上、参数对不上，工具调用就直接失败了。一开始没做校验层，结果整个Agent经常在用户面前报错，体验非常差。

后来我加了统一校验层：所有工具入参都定义JSON Schema，模型输出后先做Schema校验，失败就带错误信息重试一次；重试仍然失败，就降级处理，让模型基于已有上下文直接输出推荐结果并加一句"当前数据不完整，建议人工复核"。加了这层，工具调用的失败率从18%直接降到2%左右。

这件事给我的教训是：不要信任模型输出格式，要把"模型是概率系统"当作前提来做容错设计。做Agent开发和传统编程最大的不同就是，传统函数调用是确定的，而模型随时可能给出非标准输出。没有这一道防线，整个系统就是站在沙子上。

6.3 Skill不是越多越好，没有路由迟早变傻

我们曾经给Agent加了很多Skill：商品推荐、原因解释、价格对比、备货查询、供应商评分……加的过程很爽，但用起来问题出现了——模型经常选错工具。用户只是问"帮我看看这个产品还有没有货"，模型却调用了"商品推荐"Skill，答非所问。

原因很简单：Skill多了之后，模型对每个Skill的触发条件变模糊，路由就容易出错。后来我们把Skill体系做了优化：给每个Skill写清晰的"适用场景"描述，规定"只有用户询问库存时才调用备货查询Skill"；同时在模型调用前加了一步意图粗分类，可以用小模型或规则判断用户问题的大类，再决定路由到哪一组Skill。

从这件事情我总结了一个经验：技能库宁缺毋滥。每加一个Skill，都要问自己"这个场景出现的频率有多高？不引入它能用现有能力硬扛吗？"如果答案不够坚定，就先不留，等真实用户需求验证了再补。

6.4 Token成本失控，比你想的来得更快

Agent产品最大的隐性成本不在服务器，而在Token。很多人有个错觉：我的模型API单次调用很便宜，几厘钱而已。但Agent不是单次调用，而是多轮循环：意图识别一次、工具调用解析一次、结果生成一次、失败重试再几次。一个简单的推荐任务，背后的Token消耗可能比看起来多5到10倍。

我们做过统计，一个内部Agent平均每次任务消耗1万2千多的Token，一天2万次调用，月度账单让老板直接喊停。后来开了三味药：一是加缓存，相同或相似的用户问题直接命中缓存结果，不重复调用模型；二是用小模型做前置分类，把"意图识别"这类低难度任务从主力大模型里挪出去；三是限制Agent的最大迭代轮数，防止它陷入循环推理。做完这三件事，成本降了将近一半。

成本控制必须前置到设计阶段，不能等上线后救火。我现在的习惯是：在需求分析时就会估算每次任务的Token用量，乘上预估调用量，提前把月度成本模型算给业务方看。一个能说话的运营数据，比事后的账单有说服力得多。

6.5 我现在带项目沉淀下来的落地习惯

踩过这些坑之后，我现在带Agent产品项目已经形成了一套固定习惯，分享出来可能对你有参考价值：

第一，需求分析阶段必须产出"能力清单"和"边界清单"，缺一不可，这两份东西后面所有技术决策都围着它们转。第二，先用n8n或原型工具花一天到三天做真实链路验证，不急着选框架，链路的可行性比选型更优先。第三，架构里永远预留结果校验层和人工复核入口，没有了这两样，Agent产品不敢谈上线。第四，从第一天就开始记日志和打造成本指标，等到出问题再补，历史数据已经丢了。

我仍然相信，AI Agent是这波技术浪潮里少数能把"大模型能力"真正转化为"业务价值"的载体。但能不能转化，不取决于模型选得多强、框架选得多潮，而取决于你有没有把需求分析做透、在落地时把细节兜住。希望这篇文章能帮你少走一些我走过的弯路。