“407智能体”这个名字听起来像个内部项目代号实际上它确实就是一个编号。我接到的需求单恰好是407号需求方在“功能描述”那一栏写了一大段话概括下来就一句能不能做一个智能体把那些重复、琐碎、还需要一点脑子的活接过去。这样的需求在当下不少见。很多人一提“智能体”就联想到全能助理但实际上一个能落地的智能体往往是从一件非常具体的事开始的。这篇文章要讲的是我把一个编号为407的需求做成一个真正能跑起来的智能体的过程。包括它最初怎么立项、架构怎么选、工具怎么接、坑怎么踩以及上线前后我在成本和边界上做的取舍。如果你也在做类似的事——不管你是产品经理、后端开发还是一个人负责一个小项目的全栈这篇文章里的思路和经验应该能帮你少走不少弯路。1. 407智能体的由来一份写着“做个智能体”的需求单1.1 需求单上写的是“智能体”但真实需求是三件具体事拿到需求单的第一天我就约了需求方开了一个半小时的会。需求方是某业务组他们每天要处理大量外部咨询、资料整理、内部答疑听起来事情很多但真正落实到系统里其实就是三类重复劳动第一自动回答常见咨询并且能区分“该回的”和“该转人工的”。比如“发票怎么开”这种问题可以自动回复但“我们公司的合同为什么还没审批”这种涉及具体业务状态的问题得转人工。第二自动把零散记录整理成固定格式的档案。业务组每天会收到各种邮件、语音转文字、群聊里的备注这些内容需要按客户、按项目归入档案。第三自动汇总多个来源的信息生成日报和周报的草稿。以前这件事是组里一个同事每天花一个半小时手动拼的效率很低。这三件事分别对应了问答、抽取、生成三种能力。一旦把“智能体”拆成这三件事技术方案就很清晰了——问答走知识库检索加生成抽取走结构化信息提取生成走模板加模型润色。需求单上的“智能体”只是个含糊的愿望真正落地的是这三件事。1.2 为什么一定要用智能体而不是普通脚本需求方一开始也问过我这些活能不能写脚本一个定时任务不就把日报生成了吗我当时的回答是能但只解决了三分之一。脚本最怕的是输入不固定、步骤不固定、要求不固定。比如抓取数据这种活脚本确实可以干但业务组的邮件里经常会多一句“只取本周的剔除测试数据”脚本下一分钟就懵了因为它不知道“本周”和“测试数据”在业务里是什么意思。而大模型驱动的智能体能理解这句话并且能在不改代码的情况下调整执行方式。它可以把“取数据”这件事拆成“理解时间范围”和“识别测试数据特征”两个小步骤再去调对应的接口。这种能力是传统脚本完全不具备的。所以需求组的判断是这个项目要做的不是一堆自动化任务而是一个能理解人在说什么、能自己安排步骤的数字员工——这就是“407智能体”最早的定义。1.3 团队和周期的现实约束当时我们组只有两个开发还得兼顾其他项目时间窗口大约是四周上线内测版。这个约束直接影响了方案选择。我们没有一开始就去搭一套复杂的智能体平台而是采取了“边攒边用”的策略先调用现成的模型API加上少量代码跑通一个最小闭环。先让业务组用起来再在每个月的迭代中逐步把工具链、知识库、权限管理补上。这四周里前两周是在搭骨架后两周几乎每天都在填坑。后面我讲到的翻车记录基本都是这两周里发生的。2. 407智能体的骨架模块总线式架构与模型选择2.1 没有选择“一个大Prompt搞定一切”的原因不少初次做智能体的人第一步就是写一个超级Prompt把所有规则、背景、例子都塞进去然后希望模型什么都能干。我见过很多这样的Demo看起来很惊艳实际一上生产就崩。为什么崩三个原因第一不好调试。你根本不知道模型到底是根据哪句话做的决定出了问题只能整段Prompt反复改越改越乱。第二上下文迅速膨胀。每轮对话都要把那一大段规则重新算一遍时间长、成本高。第三权限不好控制。一个Prompt里什么都允许模型就什么都敢做包括它不该做的。所以我在设计407智能体时明确了一个原则把大脑和手脚分开。大脑负责判断手脚负责执行大脑不能直接碰系统手脚不能代替大脑做决定。2.2 架构上的四个模块407智能体从逻辑上分成四层入口层负责接收消息。不管消息来自IM、邮件还是网页表单先做格式清洗再做一次意图初判——这个请求到底是咨询、录入、查询还是汇总。决策层是核心由大模型加一个任务规划器组成。模型的任务不是直接输出最终答案而是拆解问题、选择工具、检查工具返回的结果必要的时候再决定是否需要向用户追问。执行层是一组被注册好的工具。工具是智能体的“手脚”包括查知识库、写档案、发提醒、调内部业务API等等。记忆层承担两类存储短期记忆负责当前对话的上下文长期记忆负责业务偏好和项目约定。用表格来看会更清楚模块核心职责失败处理入口层清洗消息、意图初判无法判断时进入人工接待决策层任务拆解、选择工具、校验结果计划冲突时向用户确认执行层调用知识库、业务API等实际工具工具报错时走重试或降级记忆层短期上下文、长期业务知识检索不到时明说不知道这种“模块总线”式的设计最大好处是可替换。后来我们把其中一个轻量模型换成了新版本只改了路由配置其他模块完全没动。2.3 模型选型大而全不是唯一答案很多人以为做智能体一定要用最强的模型其实不是。关键是分级让该便宜的便宜该贵的贵。在407智能体里简单的意图识别和FAQ问答走的是轻量模型速度快、成本低。需要多步推理、工具组合的复杂任务才走强模型。结构化抽取任务则用强约束的模型能力指定输出JSON格式解析不了就重试。举个例子用户问“发票多久能开出来”入口层识别这是FAQ类问题直接走轻量模型加知识库召回整个链路耗时不到两秒。但如果用户问“把上周发的所有邮件里关于发票的段落整理出来并按项目归档”入口层识别这是多步骤任务会交给强模型去做拆解和规划。这个分级策略后来看是407智能体控制成本的关键之一。3. 407智能体的手脚工具注册、函数调用与任务编排3.1 工具的定义与注册机制智能体能不能“干活”首先取决于工具描述写得好不好。模型的优势在于理解自然语言但工具本身是结构化的。两者之间需要一个桥梁就是工具描述。我给407智能体定义工具时严格要求描述里包含四个信息什么时候用、参数怎么填、返回什么、以及可能的失败情况。比如一个查客户信息工具的描述类似这样TOOL_DESCRIPTION { name: query_customer_info, description: 根据客户名称或客户编号查询客户档案信息。当用户询问客户联系人、地址、合作状态时使用。, parameters: { customer_id: {type: string, description: 客户编号格式如CUS-2024-001}, include_contacts: {type: boolean, description: 是否返回联系人列表默认false} }, returns: 返回客户基础信息、合作状态、最近跟进记录。如果查不到客户返回空列表。 }工具描述里面有个细节特别容易踩坑失败情况的说明一定要明确。早期我们没有在描述里写“查不到客户返回空列表”结果模型拿到空列表后以为“这个客户没有信息”直接生成了一句“该客户暂无档案”。这其实是幻觉的变种根子在于工具描述不够清晰。3.2 任务编排从自由发挥到半受控流程智能体跑一个复杂任务的时候完全让模型自由发挥是很危险的。比如整理归档这种流程性强的环节你让模型自己决定顺序它可能先写档案再去拉数据也可能把“归档”理解成“发送邮件”。我的做法是给流程搭一个轻量状态机。把任务分成几个阶段收集输入、查证信息、生成草稿、确认执行。模型可以决定每个阶段怎么完成比如在收集输入阶段选择调用哪个接口但阶段的顺序和跳转条件由状态机控制。这样做的好处是既保留了大模型处理不确定性的能力又让整个执行过程有迹可循——出了任何问题我们能从日志里看到它卡在哪个环节。3.3 工具调用出错的四级兜底工具调用不可能一帆风顺。我遇到过日期解析错误、业务接口超时、知识库检索无结果、权限校验失败等情况。针对这些异常我设计了四级兜底逻辑第一级重试。针对单次超时或偶发网络错误自动重试一次。第二级换工具。比如主知识库查不到自动换到备用的文档引擎再查一次。第三级澄清询问。如果换工具后仍然拿不到数据模型会向用户输出一句“我暂时没查到相关信息你确认一下关键词对不对”而不是自己猜一个答案。第四级转人工。如果整个流程出现超过两次异常直接把会话转入人工处理并附带完整的执行日志。这个兜底逻辑后来成为407智能体“可信赖感”的重要来源。业务组反馈说它至少不会乱给答案了——说不知道然后让人来接手这是可以接受的胡说八道才是不能接受的。4. 407智能体实测翻车录幻觉、上下文漂移与参数格式灾难4.1 三个最典型的翻车现场内测那两周我们记录了大量翻车案例顺手整理成了一张表问题现场表现根因修复办法幻觉明明没有数据模型编造了一个统计数模型没有区分“查到”和“猜的”工具返回加状态字段空结果必须明说上下文漂移对话第七轮时模型忘了最开始说的客户范围多轮上下文被压缩后丢失关键信息关键约束单独存进记忆层每轮调用时重新注入参数格式灾难模型把“项目状态”传成了“已完成”但系统里没有这个枚举值工具描述里的枚举没写全模型自由发挥参数描述里明确枚举模型输出前做预校验这三个问题做智能体的人大概率都会遇到。难的不是解决某个单点而是建立一套让它们不再发生的机制。4.2 一次完整排查“它说完成了但数据库里没有记录”有一次业务组反馈说407智能体回复“档案已归档”但在档案系统里查不到。这是比较严重的信任事故我按日志逐层排查。第一步查执行日志发现工具的确被调用了。第二步看工具入参发现传入的档案ID列表是空的。第三步追上游发现是从邮件主题里提取ID时提取逻辑把“RE: 合同编号CUS-2024-015”里的编号提取错了导致查无结果。第四步原来模型拿到空ID列表后没有意识到“数据源为空”是一种异常反而认为“用户要求归档的档案不存在所以自动跳过”于是直接输出了“已完成”。这个案例的关键教训是模型把“无数据可做”理解成了“任务完成”。修复方法是在工具返回结构里加一个显式的状态位只有状态位是success且写入条数大于0时模型才允许输出“已完成”。4.3 让“状态”成为工具调用的硬约束经过那几次翻车之后我定了一条规矩407智能体里所有工具返回值必须包含status字段取值只能是success、empty、error三者之一。模型只有在success时才能继续执行下一步empty时要向用户反馈“没有找到数据”error时直接走兜底逻辑。规矩定下之后很多以前模糊的判断都有了标准。模型不需要猜“这算不算成功”只需要读状态位。这也是我从那段时间的实践中得到的最重要的经验不确定的东西交给模型去处理但确定性的判断要交给程序去锁定。5. 407智能体上线前的关键配置知识库、记忆与权限边界5.1 知识库搭建从“扔一堆文档进去”到“认真切块”不少朋友搭知识库第一反应是把所有文档直接丢进向量库然后让模型检索。这样做的效果通常很一般因为检索到的片段可能是一大段无关内容或者把多个主题混在一起。我给407智能体搭知识库时做法是先做文档清洗和切块。每个文档按标题层级拆成独立的小块每块控制在几百字以内并且保留元数据比如来源文档、所属类目、更新日期。检索的时候先按类目过滤再走向量召回最后加一层相关性重排只取最相关的一小块给模型。切块这件事听起来简单实际很考验耐心。文档里的表格、嵌套列表、多级标题都需要单独处理。我们花了整整两天清洗文档但上线之后知识库回答质量的提升让这两天非常值。5.2 短期记忆与长期记忆的分工对话式智能体绕不开记忆问题。如果只靠上下文窗口把历史消息全塞进去一是很快会超出长度限制二是模型容易抓不住重点上下文漂移会越来越严重。我采用了“短期记忆加长期记忆”的双层记忆设计。短期记忆里存最近几轮对话的摘要每轮对话结束后自动压缩一次长期记忆只存结构化信息比如用户所在的项目、最近关注的主题、沟通偏好。这些信息不会存原文而是转成字段方便后面调用。关键约束单独放进长期记忆。比如前面提到的上下文漂移问题客户范围这种关键信息从一开始就被放进长期记忆每轮回答前主动注入就不会因为对话太长被模型忘掉了。5.3 权限边界智能体不能什么都干智能体的能力边界必须在设计阶段就划好不能让模型自己判断什么事能做。我根据“变更影响程度”把权限分成三档可自动执行查知识库、整理草稿、生成摘要、解析文档。这些操作只读不写或者写入后可以撤回。需人工确认发外部消息、修改项目状态、创建档案记录。这些操作会影响真实业务智能体只能生成待确认卡片人工点一下确认按钮才能执行。禁止自动执行删除数据、批量导出客户信息、涉及资金或合同状态的变更。这些动作在权限层直接拦截智能体连申请的入口都没有。这套分级规则看起来很简单但非常实用。业务组用了一段时间后甚至说407智能体最让人放心的地方不是它能干多少而是它知道自己哪些不能干。6. 407智能体落地之后的现实问题成本、评估与人工兜底6.1 成本控制别让智能体“烧钱”智能体项目的成本大头几乎都在模型API的token消耗上。刚开始跑内测的时候我们每天的token消耗高得吓人后来通过三级优化才压下来。第一级是缓存。用户问过的FAQ问题答案直接缓存不再重复调用模型。第二级是路由分流。前面说的轻量模型和强模型分级简单问题根本不需要强模型出场成本直接降一大截。第三级是工具返回压缩。工具返回长文本时模型不能全量读取先在工具层做一次摘要再送给模型。我大概算过一个数通过这三项优化407智能体的日均token消耗降到了原来的三分之一而业务组没有感觉到回答质量有任何下降。6.2 怎么评估它“好不好用”智能体的效果评估比传统软件难得多。不是“功能实现了”就完了要看用户在真实场景里愿不愿意用。我建了一个评估集从历史工单里挑了五十条真实记录每条都标注了“期望行为”。每周用这个评估集跑一遍回归统计五个指标正确回答率、召回率、转人工率、平均对话轮数、用户撤销率。转人工率和用户撤销率尤其重要因为它们反映了智能体在真实业务里的“兜底效率”。后来我们给业务组也开放了“点踩”按钮用户对回答不满意的时候可以直接标记这些标记会进入下一轮优化清单。6.3 人工兜底不是妥协而是设计的一部分最后想认真强调一点不要把“必须转人工”看成是智能体没做好。恰恰相反成功的智能体几乎都有清晰的人工兜底路径。407智能体里的转人工方式是当置信度低于阈值、或者连续两次执行异常、或者用户主动要求会话会直接转给人工客服同时把前面所有的上下文和操作日志打包好。人工客服不需要让用户重新讲一遍拿起就能续上。业务组反馈说这套“无缝转接”比智能体本身还受好评。我个人的体会是智能体的价值不是替代人而是把人从重复劳动里抽出来让人只处理真正需要判断力的部分。最后再分享一个小经验。做407智能体这段时间我最大的感受是不要试图让智能体做所有事。它现在能自动处理的也只是起初被拆得足够细的那几件事但恰恰是这几件每天帮团队省下了不少时间。如果下次再有人拿一份写着“做个智能体”的需求单过来我会先跟他聊半小时把“智能体”翻译成一件件具体的事而不是先打开IDE。
