从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 常见问题速查与避坑清单

把项目里反复出现的问题整理成一张表，方便对照排查。

几个独家避坑经验：第一，上线前一定要做压力测试，尤其是并发下的工具调用和模型调用，很多问题只在并发时暴露。第二，给智能体加“紧急刹车”，出问题时能一键切到人工或降级模式，别等修复。第三，日志要能还原完整链路，从用户输入到最终输出，每一步的中间结果都要能查到，否则排查全靠猜。

5. 一些关于团队协作和交付的实话

技术之外，商用智能体项目最容易翻车的地方其实是协作和预期管理。这一块没什么技术含量，但踩坑的人特别多，值得单独说几句。

需求方对智能体的预期往往是“什么都能干”，而实际能力是有边界的。项目启动时就要把能力边界、失败场景、人工兜底方案讲清楚，最好写进交付文档。我见过项目上线后需求方抱怨“它怎么连这个都不会”，一查发现这个需求从来没在范围里定义过。预期没对齐，技术做得再好也是差评。

另外，智能体项目特别需要产品和开发的紧密配合。提示词、工具描述、评测标准这些东西，既不是纯产品也不是纯开发，需要两边一起磨。我的经验是每周固定一次 badcase 复盘，产品看体验、开发看日志，一起决定改哪里。这个机制比任何单方面的优化都有效。

最后说个我自己的体会：商用智能体的价值不在于它多像人，而在于它把一件重复、繁琐、有明确规则的事，稳定地办成了。追求“像人一样聪明”往往会把项目带进无底洞，而追求“把特定任务稳定办好”，才是能交付、能收钱、能持续迭代的正路。我在几个项目里反复验证过这一点——把范围收窄、把边界划清、把兜底做足，效果和口碑反而比那些什么都想做的项目好得多。