从Demo到商用：智能体开发的任务编排与评测体系实战

商用智能体开发这两年从“Demo 满天飞”走到“能真正收钱”的阶段中间隔着的坑比大多数人想象的多得多。我前后参与过几个对外交付的智能体项目有给电商做售后自动处理的有给内容团队做选题调研的也有给传统企业做内部知识问答的。这些项目有一个共同点演示阶段都很惊艳上线之后都出过状况。所以这篇东西不打算讲“智能体多厉害”而是把从零到一做一个能商用交付的智能体整个链路上真正需要想清楚的事情拆开讲一遍。如果你正在评估要不要做一个智能体产品或者已经动手但卡在“Demo 能用、上线就崩”的阶段又或者你是产品、开发、运营里任何一个需要参与这件事的角色下面这些内容应该能帮你少走一些弯路。核心关键词会围绕商用智能体、任务编排、工具调用、评测体系、成本控制这几个方向展开这些都是决定一个智能体能不能从玩具变成产品的关键。1. 先想清楚商用智能体和 Demo 的本质差别在哪很多人做智能体的起点是“我有个想法先接个大模型跑跑看”。这个思路做 Demo 没问题但做商用产品会直接翻车。我见过太多团队在演示环境里跑得顺风顺水一上线就被真实用户的输入打穿。差别到底在哪得先掰扯明白。1.1 从“能回答”到“能负责”的跨越Demo 的验收标准是“这个问题它答上来了”商用产品的验收标准是“这个问题它答错了谁来兜底”。这是最根本的区别。演示时你挑的是模型擅长的输入真实用户不会配合你他们会输入错别字、会问边界外的问题、会在一个句子里塞三个意图、会故意试探系统的底线。所以商用智能体设计的第一原则不是“让模型更聪明”而是让系统在模型不聪明的时候依然可控。具体落到设计上就是三件事输入要有兜底校验输出要有置信度判断失败要有降级路径。这三件事在 Demo 里统统可以不做在商用里一件都不能少。我拿一个实际场景举例。给电商做售后智能体用户说“我上周买的那个东西坏了想退”。Demo 阶段模型能识别出退货意图直接走退货流程看起来很完美。但真实情况是用户可能根本没买过、可能已经过了退货期、可能说的是另一个订单、可能“坏了”指的是物流破损而不是质量问题。这些分支如果不在系统层面做校验模型会自信满满地走错流程最后产生真实的资损和客诉。1.2 商用场景下必须提前锁定的四个约束动手之前有四个约束必须先定下来它们会反向决定你的技术选型。约束维度需要回答的问题对设计的影响成本边界单次对话可接受的成本上限是多少决定模型档位、上下文长度、是否做缓存延迟要求用户能忍受多长的响应时间决定是否流式输出、是否并行调用工具准确率底线哪些场景错一次都不能接受决定哪些环节必须人工介入或强校验合规红线哪些内容绝对不能输出决定过滤层的位置和强度这四个约束里成本边界最容易被低估。一个智能体如果每轮对话都带完整历史上下文、都调用最贵的模型、都做多轮工具调用单次成本可能是几毛甚至几块。日活一千、人均十轮一天就是几千块。这个账必须在动手前算清楚而不是上线后看着账单傻眼。1.3 一个容易被忽略的定位问题智能体不是聊天机器人很多需求方张口就是“我要一个能聊天的智能体”这个表述会把你带偏。聊天机器人以对话为中心智能体以任务完成为中心。用户不在乎它聊得好不好在乎的是“我的事办成了没有”。这个定位差异会直接影响架构。以任务为中心你就需要明确的任务状态机、清晰的工具边界、可验证的完成标准。以对话为中心你会把精力花在话术打磨上最后发现用户要的是结果不是陪聊。我在项目里踩过这个坑早期花大量时间优化回复的语气和措辞上线后用户反馈最多的却是“它老是问我一堆问题才肯办事”。后来把交互改成“能自己查的先查、能自己做的先做只在关键决策点确认”满意度立刻上来了。2. 架构设计把智能体拆成能各自负责的模块商用智能体的架构不能是“一个大模型包打天下”那样既不可控也不可维护。合理的做法是拆成几个职责清晰的层每层都能独立测试、独立替换。这一章讲的就是这套分层怎么划、每层负责什么、层与层之间怎么约定接口。2.1 分层拆解接入层、编排层、能力层、数据层我习惯把商用智能体拆成四层这个划分方式在多个项目里验证过比较好落地。接入层负责和用户打交道包括渠道适配网页、App、企业IM 等、会话管理、输入预处理纠错、意图初判、敏感词过滤。这一层的核心职责是“把脏输入洗干净再往里送”别让乱七八糟的东西污染后面的逻辑。编排层是整个智能体的大脑负责意图识别、任务规划、工具调度、状态管理。这一层不直接调用大模型做具体任务而是决定“这个请求该走哪条路、调哪些工具、按什么顺序调”。它更像一个调度中心而不是执行者。能力层是具体干活的模块包括大模型调用、检索、各类工具函数查订单、发邮件、算数据等。每个能力都是一个独立的、可测试的单元编排层通过统一接口调用它们。数据层负责存储会话历史、任务状态、知识库、日志。这一层看起来最不起眼但商用系统里出问题最多的往往是它——状态丢了、历史串了、检索召回不准都会直接表现为“智能体变笨了”。提示分层的目的不是画好看的架构图而是让每一层都能被单独替换和单独测试。如果你的编排层和模型调用耦合在一起换模型时就得改一大片代码这在商用迭代里是灾难。2.2 编排层设计状态机比“自由发挥”靠谱得多编排层最容易犯的错是让模型自由决定下一步做什么。这种方式在简单任务上很灵活但一旦任务有多个步骤、有分支、有失败重试模型就会开始“幻觉式规划”——编造不存在的步骤、跳过必要的校验、在循环里打转。我的做法是用显式状态机约束任务流程。每个任务定义清楚有哪些状态、状态之间怎么流转、每个状态允许调用哪些工具。模型的作用是在每个状态内做判断和生成而不是决定整个流程怎么走。举个退货场景的状态机简化版状态待识别解析用户诉求判断是否为退货意图状态待校验调用订单查询工具校验订单存在性、时效性状态待确认向用户确认退货原因和退款方式状态执行中调用退货接口处理结果状态已完成/已转人工终态每个状态内模型可以灵活处理用户的表达但不能跳出状态机。用户在校验阶段突然问别的系统会先记录这个旁支问题等主任务完成后再处理而不是被带跑偏。这个设计让整个流程的可预测性大幅提升也方便做埋点和监控——每个状态的转化率、停留时长、失败原因都能单独统计。2.3 工具调用的边界设计什么该给模型什么不该给工具调用是智能体能力的来源也是风险的主要来源。给模型太多工具它会乱调给太少它办不成事。边界怎么划我总结了几条经验。第一写操作和读操作分开授权。查询类工具可以相对宽松地给因为错了顶多返回无用信息写入类工具下单、退款、发消息必须加严格的前置校验和二次确认不能让模型直接触发。第二工具粒度要适中。太细比如“查订单号”“查订单状态”拆成两个工具会导致模型频繁组合调用增加出错概率太粗一个“处理售后”工具包办一切又失去了可控性。我的经验是按“一个完整的业务动作”来切比如“查询订单详情”是一个工具“提交退货申请”是另一个。第三每个工具都要有明确的失败语义。工具返回的不只是成功结果还要有结构化的失败原因参数错误、权限不足、业务规则不满足、系统异常编排层根据失败类型决定是重试、换路径还是转人工。很多项目在这里偷懒工具失败就返回一句“操作失败”模型拿到这种模糊信息只能瞎猜最后给用户的回复驴唇不对马嘴。2.4 上下文管理别把整个对话历史一股脑塞进去上下文管理是成本和效果的双重关键点。新手最常见的做法是把全部对话历史拼进 prompt简单粗暴。问题是 token 成本随轮次线性增长而且长上下文里模型对关键信息的注意力会下降出现“前面说过的它忘了、中间无关的它记住了”的情况。我的做法是分层上下文短期上下文保留最近几轮原始对话中期上下文用摘要压缩每几轮做一次摘要保留关键实体和决策长期上下文只保留结构化的任务状态和用户画像。拼 prompt 时按需组合而不是全量拼接。具体到参数上我一般把单次请求的上下文控制在模型窗口的 30% 到 50% 之间留出足够空间给工具返回结果和生成内容。超过这个比例就触发摘要压缩。这个阈值不是拍脑袋是实测出来的——超过 50% 之后响应质量和速度都会明显下降而成本还在涨。3. 核心能力实现模型选型、提示工程与工具落地架构搭好之后真正决定效果的是这一层的实现细节。这一章讲三个最核心的部分模型怎么选、提示怎么写、工具怎么落地。每一块都有大量实操细节也是踩坑最密集的地方。3.1 模型选型不是越贵越好是匹配才对模型选型要按任务分层而不是全系统用一个模型。我的常规做法是分三档任务类型模型档位选择理由意图识别、简单分类小模型/轻量模型任务简单、调用频繁用大模型是浪费多步推理、复杂生成主力大模型需要较强理解与生成能力兜底、争议处理最强模型低频但要求高值得花这个钱这个分层能显著压低成本。实测下来把意图识别这类高频简单任务切到轻量模型整体成本能降一半以上而效果几乎无损。关键是你要先有评测集能验证“切了之后效果没掉”否则不敢切。选型时还要看几个容易被忽略的指标首 token 延迟影响流式体验、并发限制影响高峰期可用性、结构化输出稳定性影响工具调用可靠性。最后这个尤其重要很多模型在自由生成时表现很好但要求它输出严格 JSON 时就开始出错而工具调用恰恰依赖结构化输出。选型阶段一定要拿真实任务压测结构化输出的成功率别等上线才发现。3.2 提示工程把“写 prompt”当成“写接口文档”商用场景的提示词不能是随手写的几句话它更像一份接口文档——要明确输入是什么、输出格式是什么、边界在哪、异常怎么处理。我写生产级提示词一般包含这几个部分角色与职责一句话说清它是干什么的不要长篇大论输入说明告诉它会收到什么结构的数据任务步骤把复杂任务拆成有序步骤逐步引导输出格式严格定义输出结构最好给示例边界与拒答明确哪些情况不处理、怎么回复少样本示例给两到三个典型输入输出对其中输出格式和边界拒答是商用和 Demo 的分水岭。Demo 里模型输出一段自然语言就完事了商用里下游系统要解析这个输出格式一乱整条链路就断。我的习惯是让模型输出 JSON并在提示里明确“只输出 JSON不要任何额外文字”同时在代码层做解析容错——解析失败时先尝试修复修复不了走降级而不是直接抛异常。注意提示词要版本化管理。每次改动都记录版本号、改动原因、评测结果。我见过团队改提示词改出回归问题却因为没版本记录而无法回滚只能一行行对比找差异非常痛苦。3.3 工具落地从函数签名到错误处理的全链路工具不是写个函数就完事它是一份要和模型“沟通”的契约。一个合格的商用工具实现要包含这几块清晰的函数签名和描述。模型靠描述来决定调不调、怎么调描述写得含糊模型就会乱调。描述里要写清楚这个工具做什么、什么情况下用、参数含义、返回什么。参数名要语义化别用arg1、data这种。参数校验与容错。模型生成的参数不一定合法工具入口必须做类型校验、范围校验、必填校验。校验失败返回结构化错误告诉模型哪里错了让它有机会重试。超时与重试。外部依赖随时可能慢或挂工具必须设超时超时后按策略重试或降级。重试要有次数上限和退避别把下游打垮。幂等设计。写操作类工具必须支持幂等防止模型重试导致重复执行。用一个请求 ID 做去重是最简单的做法。可观测性。每次工具调用都要记录入参、出参、耗时、成功失败。这些日志是排查问题的命根子上线后你会发现大部分“智能体犯傻”的问题根子都在某个工具返回了意料之外的东西。3.4 检索增强知识库不是“传上去就能用”如果智能体需要基于私有知识回答检索增强是绕不开的。但很多人以为把文档传进向量库就完事了实际效果往往很差。问题出在检索质量上而检索质量取决于几个容易被忽略的环节。文档切分策略。切太大检索精度低切太小上下文不完整。我的经验是按语义切分每块控制在几百字并保留一定的重叠。对于结构化文档表格、条款要按结构切而不是按字数切。混合检索。纯向量检索对语义相似但字面不同的内容有效但对精确匹配编号、专有名词不敏感。实际项目里我一般用向量检索加关键词检索的混合方案再加重排序召回质量比单一方案稳得多。召回后的处理。检索回来的内容不能直接塞给模型要先做去重、截断、相关性过滤。塞一堆不相关的内容进去模型反而会被干扰生成质量下降。4. 评测、上线与持续运营商用智能体的后半程前面讲的是“怎么把它做出来”这一章讲“怎么证明它行、怎么让它稳定跑、怎么让它越跑越好”。这部分是很多团队最薄弱的地方也是商用和 Demo 差距最大的地方。4.1 评测体系没有评测集就没有商用资格我坚持一个观点没有评测集的智能体不允许上线。评测集是你唯一能客观判断“改了之后是变好还是变坏”的依据。没有它所有优化都是凭感觉改一个地方修好了 A 问题可能悄悄弄坏了 B 问题。评测集怎么建从真实场景出发覆盖几类样本典型正例正常需求占比最大验证基本能力边界样本模糊表达、多意图、信息不全验证鲁棒性对抗样本故意诱导、越权请求、注入攻击验证安全性历史 badcase每次线上出问题都沉淀进来防止回归每类样本要有明确的期望结果和评分标准。评分可以是人工标注也可以用模型辅助评分但要定期人工抽检校准。评测要自动化跑每次改动提示词、换模型、改工具都跑一遍看指标变化。指标上我一般看四个任务完成率办成的比例、准确率办对的比例、拒答准确率该拒的拒了、不该拒的没拒、平均轮次办成一件事要几轮对话。前三个看效果最后一个看体验。4.2 灰度上线与监控让问题在小范围内暴露商用智能体不要一次性全量上线。我的做法是先灰度按用户比例或场景逐步放量每一档观察一段时间再扩大。灰度期间重点盯几个指标任务完成率、转人工率、用户负反馈率、工具失败率、平均响应延迟。监控要细到状态机层面。哪个状态转化率异常、哪个工具失败率高、哪类输入频繁触发兜底这些都要能看到。我遇到过一次线上问题某个工具在特定参数下会超时导致整个任务卡住。因为监控只看了整体成功率没看单工具耗时问题拖了两天才定位到。后来把工具级监控补上类似问题基本能在小时级发现。4.3 成本与性能的持续优化上线只是开始成本优化是长期活。几个我常用的手段缓存。高频相同或相似请求做结果缓存尤其是知识问答类场景命中率能到很高。缓存要设合理的过期和失效策略避免返回过时信息。模型降级。非核心环节用轻量模型核心环节才用大模型。前面讲的分层选型就是这个思路。上下文压缩。前面讲的分层上下文本质就是控制 token 消耗。并行调用。多个独立的工具调用并行发起而不是串行等待能显著降低总延迟。预计算。能提前算好的东西别放到请求时算比如用户画像、常用知识摘要提前准备好。4.4 常见问题速查与避坑清单把项目里反复出现的问题整理成一张表方便对照排查。现象可能原因排查方向回答跑题上下文污染或提示边界不清检查上下文拼接、补充边界约束工具调用失败率高参数校验缺失或描述含糊看工具日志入参、优化工具描述响应越来越慢上下文膨胀或工具串行检查 token 增长、改并行调用同一问题答案不稳定模型温度过高或缺确定性约束降温度、加结构化输出约束该拒答的没拒拒答边界未定义或评测缺失补对抗样本、明确拒答规则成本超预期模型档位过高或缓存缺失做任务分层、加缓存几个独家避坑经验第一上线前一定要做压力测试尤其是并发下的工具调用和模型调用很多问题只在并发时暴露。第二给智能体加“紧急刹车”出问题时能一键切到人工或降级模式别等修复。第三日志要能还原完整链路从用户输入到最终输出每一步的中间结果都要能查到否则排查全靠猜。5. 一些关于团队协作和交付的实话技术之外商用智能体项目最容易翻车的地方其实是协作和预期管理。这一块没什么技术含量但踩坑的人特别多值得单独说几句。需求方对智能体的预期往往是“什么都能干”而实际能力是有边界的。项目启动时就要把能力边界、失败场景、人工兜底方案讲清楚最好写进交付文档。我见过项目上线后需求方抱怨“它怎么连这个都不会”一查发现这个需求从来没在范围里定义过。预期没对齐技术做得再好也是差评。另外智能体项目特别需要产品和开发的紧密配合。提示词、工具描述、评测标准这些东西既不是纯产品也不是纯开发需要两边一起磨。我的经验是每周固定一次 badcase 复盘产品看体验、开发看日志一起决定改哪里。这个机制比任何单方面的优化都有效。最后说个我自己的体会商用智能体的价值不在于它多像人而在于它把一件重复、繁琐、有明确规则的事稳定地办成了。追求“像人一样聪明”往往会把项目带进无底洞而追求“把特定任务稳定办好”才是能交付、能收钱、能持续迭代的正路。我在几个项目里反复验证过这一点——把范围收窄、把边界划清、把兜底做足效果和口碑反而比那些什么都想做的项目好得多。