龙虾服务：大模型中间层架构设计与工程实践指南

1. 龙虾服务到底是个什么东西第一次听到“龙虾服务”这个名字很多人会以为是餐饮外卖或者生鲜配送。其实它是一套把大语言模型能力封装成可调用服务的中间层方案核心目标是让AI从“聊天玩具”变成真正能嵌入业务流程的“超级助手”。你可以把它理解成一个翻译官一边是各种AI模型的原生接口另一边是你自己的应用、脚本、工作流龙虾服务负责把两边对接起来并且加上记忆、工具调用、任务编排这些增强能力。我最初接触这类方案是在帮一个做电商客服的朋友搭自动化回复系统。当时直接用模型原生接口发现几个致命问题对话没有长期记忆每次都要把历史记录重新塞进去模型不能主动查订单、查物流多个任务串行时容易丢上下文。龙虾服务这类中间层就是来解决这些问题的。它把会话管理、上下文压缩、工具注册、任务调度这些脏活累活都包了你只需要关心业务逻辑本身。这套东西适合谁用如果你只是偶尔问问AI问题那直接用网页版就够了。但如果你想把AI接入自己的网站、企业微信、飞书、客服系统或者想让它自动完成“查数据→分析→生成报告→发送”这种多步骤任务那龙虾服务这类方案就非常值得研究。它不要求你是算法工程师但需要你懂基本的API调用和业务流程设计。下面我会从架构思路、核心模块、实操部署、问题排查几个维度把整套东西拆开讲清楚。2. 整体架构设计与核心思路拆解2.1 为什么需要中间层而不是直接调模型直接调用大模型接口有三个绕不过去的坎。第一是上下文窗口限制主流模型虽然标称支持几万到几十万token但实际使用中你把全部历史对话塞进去成本会飙升响应也会变慢。第二是工具调用能力模型本身不能查数据库、不能发邮件、不能操作你的内部系统必须通过外部工具来扩展。第三是多轮任务的状态管理一个“帮我整理上周销售数据并生成周报”的任务涉及查库、计算、格式化、发送多个步骤模型单次输出很难可靠完成。龙虾服务的核心思路就是在这三个坎上各架一座桥。上下文方面它采用滑动窗口摘要压缩的策略近期对话保留原文远期对话用模型自己生成的摘要替代这样既保留了关键信息又把token消耗控制在合理范围。工具方面它定义了一套工具注册协议你用JSON描述工具的名称、参数、返回值服务会自动把工具描述注入到模型提示词里模型决定何时调用、传什么参数。任务编排方面它引入了任务链的概念把一个复杂目标拆成多个子任务每个子任务可以独立调用模型或工具前一个的输出作为后一个的输入。注意中间层不是越厚越好。我见过有人把简单的问答也套上三层编排结果延迟从1秒变成8秒。原则是能用单次调用解决的绝不拆成多步。2.2 核心模块划分与职责边界一套完整的龙虾服务通常包含五个核心模块我按数据流向来说。接入层负责接收外部请求支持HTTP、WebSocket、消息队列三种协议。HTTP适合同步问答WebSocket适合流式输出消息队列适合异步任务。接入层还要做鉴权、限流、请求日志这些是生产环境的基本要求。会话管理层是整套服务的记忆中枢。它维护每个用户或每个会话的上下文栈决定哪些内容保留原文、哪些压缩成摘要、哪些直接丢弃。这里有个关键设计摘要不是简单截断而是让模型自己总结。比如前20轮对话让模型生成一段200字的摘要后续对话把这段摘要放在系统提示词里。实测下来这样比单纯保留最近5轮的效果好很多因为早期的重要信息不会丢。工具注册层管理所有可调用的外部能力。每个工具需要定义名称、描述、参数schema、执行函数。描述写得越清楚模型调用越准确。我踩过的坑是工具描述写得太简略模型经常传错参数类型。后来我把每个参数的示例值都写进描述里准确率明显提升。任务编排层负责把复杂目标拆解成执行计划。最简单的实现是链式编排任务A的输出直接作为任务B的输入。复杂一点的是条件分支根据模型判断的结果决定走哪条路径。再复杂的是循环迭代比如“反复修改文案直到满意度达标”需要设置最大迭代次数防止死循环。模型适配层屏蔽不同模型提供商的接口差异。OpenAI、Claude、国产模型各有各的API格式适配层统一成内部标准格式这样切换模型时上层业务不用改代码。适配层还要处理重试、降级、超时这些容错逻辑。2.3 方案选型自建还是用现成框架市面上已经有一些开源框架可以做类似的事情比如LangChain、Semantic Kernel。那为什么还要自己搭龙虾服务我的经验是框架适合快速验证自建适合深度定制。LangChain这类框架功能很全但抽象层次太多出了问题排查起来很痛苦。有一次线上任务卡住我翻了五层源码才找到是某个回调没触发。而且框架的更新频率很高版本升级经常有破坏性变更。如果你只是做个demo用框架没问题但如果你要长期维护、要接内部系统、要对性能和成本做精细控制自建一套轻量级的中间层反而更省心。自建的核心工作量在三个地方会话存储用Redis或Postgres都行、工具注册一个JSON配置加一个执行器、任务编排一个状态机。我自己的实现大概两千行Python代码覆盖了日常90%的场景。下面我会给出关键模块的实操细节。3. 核心模块的实操要点与配置细节3.1 会话管理滑动窗口与摘要压缩的具体参数会话管理的核心是决定“保留多少原文、压缩多少摘要”。我的配置是这样的最近8轮对话保留原文超过8轮的部分每4轮压缩成一段摘要摘要总长度不超过500字。这个参数不是拍脑袋定的而是根据实际对话长度和模型成本算出来的。假设每轮对话平均100字8轮就是800字。摘要部分最多500字。加上系统提示词300字总输入控制在1600字左右对应大约1200token。按主流模型的价格一次调用成本不到一分钱。如果全部保留原文20轮就是2000字成本翻倍不说模型对早期信息的注意力也会下降。摘要的生成时机也很关键。我试过两种方案实时摘要和批量摘要。实时摘要是每轮对话结束后立刻更新摘要优点是信息最新缺点是增加一次模型调用延迟翻倍。批量摘要是每积累4轮才更新一次延迟低但摘要可能滞后。最终我选了批量摘要因为大多数场景下用户不会在对话第3轮就依赖第1轮的细节。实操心得摘要提示词里一定要加一句“保留所有数字、日期、人名、订单号等关键实体”。我一开始没加结果模型把订单号总结没了导致后续查物流失败。3.2 工具注册如何让模型准确调用外部能力工具注册的难点不在技术实现而在描述设计。模型只能通过你给的文字描述来理解工具能做什么、参数怎么传。描述写不好模型要么不调用要么传错参数。我总结了一个工具描述的模板包含五个要素功能一句话概括、适用场景、参数说明含类型和示例、返回值格式、调用限制。举个例子一个查询订单状态的工具描述是这样的{ name: query_order_status, description: 根据订单号查询订单当前状态。适用于用户询问订单进度、物流信息、是否发货等场景。, parameters: { order_id: { type: string, description: 订单号通常是12位数字例如202405180001, required: true } }, returns: 返回JSON对象包含status字段pending/shipped/delivered和estimated_delivery字段, limitations: 仅支持查询最近90天内的订单 }这个描述里参数示例“202405180001”非常重要。模型看到具体示例后传参准确率从60%提升到95%以上。另外“limitations”字段让模型知道边界避免对超期订单反复调用。工具执行器本身要处理异常。网络超时、数据库连接失败、返回格式错误这些都要捕获并返回结构化的错误信息给模型让模型决定是重试还是告知用户。我见过有人工具报错直接抛异常整个对话就断了。正确的做法是返回{error: 查询超时请稍后重试}模型会自然地转述给用户。3.3 任务编排链式、分支与循环的实现差异任务编排是龙虾服务里最体现“超级助手”价值的部分。我把它分成三个复杂度层级。链式编排最简单适合线性流程。比如“收到用户问题→查询知识库→生成回答→发送”。实现方式就是一个列表每个元素是一个步骤函数前一个的返回值传给后一个。关键点是步骤间的数据格式要统一我通常用字典传递每个步骤约定好读取哪些key、写入哪些key。条件分支适合需要判断的场景。比如“用户要退款→判断订单是否在退款期内→是则走退款流程否则走人工审核”。实现上可以用一个路由函数根据上一步的输出决定下一步执行哪个分支。这里有个坑分支条件不要让模型自由发挥最好用规则引擎先过滤一遍。我试过让模型判断“是否在退款期内”它有时候会把日期算错。后来改成代码判断日期模型只负责提取订单号准确率就上来了。循环迭代适合需要反复优化的任务。比如“生成文案→评估质量→不达标则修改→再评估”。实现时要设置最大迭代次数我一般设3次和退出条件比如质量评分超过阈值。没有退出条件的循环是灾难我踩过一次坑模型陷入自我修改的死循环烧了十几块钱的token才被监控告警发现。3.4 模型适配多模型切换与降级策略模型适配层的价值在容灾和成本优化。我配置了三个模型主力模型用效果最好的备用模型用速度最快的兜底模型用最便宜的。正常情况走主力主力超时或报错自动切备用备用也挂了走兜底。切换逻辑用熔断器模式实现连续3次调用失败熔断60秒期间所有请求走备用。60秒后放一个试探请求成功则恢复主力。这套机制让我在模型服务波动时业务可用性保持在99%以上。成本优化方面我做了请求分级。简单问答比如“今天天气怎么样”走便宜模型复杂任务比如“分析这份销售数据”走贵模型。分级依据是输入长度和工具调用数量输入超过500字或需要调用2个以上工具的判定为复杂任务。实测下来整体成本降低了40%效果没有明显下降。4. 完整部署流程与关键环节实现4.1 环境准备与依赖安装我用的技术栈是Python 3.11 FastAPI Redis PostgreSQL。选Python是因为生态好各种模型SDK都支持选FastAPI是因为异步性能好适合IO密集型的模型调用Redis存会话上下文Postgres存工具配置和任务日志。安装依赖的命令如下pip install fastapi uvicorn redis psycopg2-binary httpx pydantic这里重点说三个依赖的作用。httpx用于异步调用模型接口比requests更适合高并发。pydantic用于定义工具参数的schema自动做类型校验。redis的异步客户端redis.asyncio用于会话存储读写延迟在1毫秒以内。注意不要用同步的Redis客户端否则会阻塞事件循环并发能力直接砍半。我一开始用同步客户端压测时QPS只有50换成异步后到了300。4.2 会话存储的Redis数据结构设计会话数据我用了三个Redis key。第一个是session:{session_id}:messages用List结构存原始消息每条消息是一个JSON字符串包含role、content、timestamp。第二个是session:{session_id}:summary用String结构存摘要文本。第三个是session:{session_id}:meta用Hash结构存元数据比如最后活跃时间、消息计数、当前使用的模型。读取上下文的逻辑是这样的先从meta里判断消息总数如果小于8条直接读全部messages如果大于8条读最近8条messages加上summary。然后把summary放在系统提示词里messages按时间顺序排列。写入时用LPUSH加LTRIM保持列表长度不超过20条超出的部分触发摘要更新。摘要更新的触发条件是消息计数达到4的倍数。更新时取最早4条未摘要的消息拼成文本让模型生成摘要然后追加到现有摘要后面。这里要注意摘要也要控制长度我设了500字上限超过就让模型再压缩一次。4.3 工具执行器的安全隔离工具执行器直接操作内部系统安全隔离必须做好。我的做法是白名单参数校验超时控制三层防护。白名单方面每个工具在注册时就绑定了允许调用的数据库表或API端点执行器只允许访问白名单内的资源。参数校验用pydantic的schema类型不对、必填缺失、长度超限都会在调用前被拦截。超时控制用asyncio.wait_for每个工具调用最多等5秒超时返回错误信息。还有一个容易被忽略的点工具返回结果要脱敏。比如查询用户信息时手机号中间四位要打码身份证号只返回后四位。这些脱敏规则写在工具执行器里不依赖模型判断。我见过有人让模型自己脱敏结果模型有时候会“忘记”把完整手机号输出到对话里。4.4 任务编排的状态机实现任务编排我用了一个简单的状态机。每个任务定义为一个字典包含steps列表和current_step索引。每个step是一个函数接收上下文字典返回更新后的上下文和下一步的索引。task { steps: [step1, step2, step3], current_step: 0, context: {} } def run_task(task): while task[current_step] len(task[steps]): step_func task[steps][task[current_step]] result step_func(task[context]) task[context].update(result) if next_step in result: task[current_step] result[next_step] else: task[current_step] 1 return task[context]这个实现支持条件跳转通过返回next_step和提前结束通过返回next_step为-1。循环迭代通过让某个step返回前一个step的索引来实现配合最大迭代次数检查。任务状态要持久化到Postgres这样服务重启后任务不会丢。我建了一张tasks表字段包括task_id、status、current_step、context_json、created_at、updated_at。每次step执行后更新一次崩溃恢复时从数据库读取状态继续执行。5. 常见问题与排查技巧实录5.1 模型不调用工具或调用错误工具这是最高频的问题。表现是用户问“帮我查订单”模型直接回复“请提供订单号”而不调用查询工具。原因通常是工具描述不够明确或者系统提示词没有强调工具可用性。排查步骤先看工具描述里有没有写清楚“适用于什么场景”。如果只写了“查询订单”模型可能觉得这不是必须调用的。改成“当用户询问订单状态、物流进度、发货时间时必须调用此工具”强制语气能显著提升调用率。然后在系统提示词里加一句“你有以下工具可以使用遇到对应场景时请优先调用工具而不是直接回答”。如果模型调用了错误的工具检查工具名称是否太相似。我有两个工具叫query_order和query_user模型经常搞混。后来改成query_order_status和query_user_profile区分度上来了错误率下降。5.2 上下文丢失导致重复提问用户反馈“我刚说过的订单号它又问一遍”。这是会话管理的问题。排查时先看Redis里messages列表是否正常写入。常见原因是session_id生成逻辑有问题比如每次请求都生成新的session_id那上下文自然就断了。另一个原因是摘要压缩把关键信息压没了。检查摘要文本里是否包含订单号、日期这些实体。如果没有调整摘要提示词明确要求保留实体。我还会在摘要后面附加一个“关键实体列表”把最近提到的订单号、手机号、日期单独列出来这样即使摘要遗漏了实体列表也能兜底。5.3 任务执行到一半卡住任务卡住的表现是状态一直是running但没有任何进展。排查顺序先看任务日志确认最后执行的step是哪个。然后看那个step的输入输出判断是模型调用超时还是工具执行卡住。模型调用超时通常是网络问题或模型服务波动重试一般能解决。工具执行卡住可能是数据库锁或者外部API无响应需要给工具加超时。我遇到过工具里有个requests.get没设timeout外部服务挂了导致整个任务挂起。后来所有工具调用都强制加5秒超时。还有一种情况是循环迭代没有退出。检查最大迭代次数是否生效以及退出条件是否可达。我设的退出条件是“质量评分大于8分”但模型打分一直在7分徘徊导致循环了3次才因为最大次数退出。后来把阈值降到7分循环次数就正常了。5.4 成本突然飙升成本飙升通常有三个原因上下文过长、工具调用过多、循环迭代失控。排查时先看平均每次请求的token消耗如果比平时高50%以上大概率是上下文管理出了问题。检查摘要是否正常触发。我遇到过Redis的LTRIM没生效messages列表无限增长每次请求都把全部历史塞进去。修复方法是加一个定时任务每小时扫描一次所有session把超过50条消息的强制压缩。工具调用过多可能是模型陷入了“反复确认”的循环。比如查订单状态模型先调一次看到结果后又调一次确认。解决方法是在工具返回结果里加一个“已确认”标记模型看到标记后就不会重复调用。5.5 常见问题速查表问题现象可能原因排查方法解决方案模型不调用工具工具描述不明确检查description字段补充适用场景和强制语气上下文丢失session_id变化或摘要遗漏查看Redis messages列表固定session_id摘要保留实体任务卡住工具超时或循环无退出查看任务日志最后step加超时设最大迭代次数成本飙升上下文过长或重复调用统计平均token消耗强制摘要压缩加确认标记工具传参错误参数描述缺示例检查parameters字段补充示例值和类型说明响应延迟高同步调用或模型选型不当压测QPS和P99延迟改异步简单任务走快模型6. 进阶优化与个人实操体会6.1 缓存策略什么该缓存、什么不该缓存模型调用是最大的延迟和成本来源缓存能省不少。我缓存两类东西工具查询结果和常见问答。工具查询结果缓存要设短过期时间比如订单状态缓存30秒。因为订单状态可能随时变化缓存太久会返回过期信息。缓存key用工具名加参数哈希比如tool:query_order_status:202405180001。常见问答缓存适合FAQ场景。用户问“退货政策是什么”如果知识库里有标准答案直接返回缓存不用调模型。缓存key用问题的语义哈希我用的方案是先用一个便宜模型把问题转成向量然后做相似度匹配。相似度超过0.95才命中缓存避免答非所问。不该缓存的是涉及用户隐私的对话和实时性要求高的任务。比如用户说“帮我查一下我的余额”这个绝对不能缓存否则可能把A用户的余额返回给B用户。6.2 监控告警必须盯住的五个指标生产环境我盯五个指标请求量、平均延迟、错误率、token消耗、工具调用成功率。请求量突然下降可能是接入层挂了突然上升可能是被刷了。平均延迟超过3秒要告警用户体验会明显变差。错误率超过1%要查模型服务状态。token消耗异常升高要查上下文管理。工具调用成功率低于90%要查工具执行器。告警渠道我用的是企业微信机器人每个指标设不同阈值。比如延迟告警阈值是3秒错误率是1%token消耗是日环比增长50%。告警信息里带上最近5分钟的详细数据方便快速定位。6.3 我踩过的最大的三个坑第一个坑是没有做请求去重。用户手抖点了两次发送服务处理了两次扣了两次费。后来在接入层加了基于用户ID和消息内容的去重5秒内的相同请求只处理一次。第二个坑是工具执行没有幂等性。有个“发送邮件”的工具模型重试时发了三封同样的邮件。后来给所有写操作工具加了幂等键同一个任务ID只执行一次。第三个坑是摘要更新阻塞了主流程。摘要生成要调模型耗时1-2秒我一开始是同步做的导致每4轮对话就卡一下。后来改成异步任务摘要生成放到后台队列主流程不等它完成。用户感知不到延迟摘要稍后更新也不影响体验。6.4 后续可以扩展的方向这套龙虾服务目前覆盖了问答、工具调用、简单任务编排。后续我打算加两个能力多模态输入和主动触发。多模态就是支持图片和语音输入用户发一张截图服务能识别内容并处理。主动触发是让服务能根据时间或事件自动发起任务比如每天早上9点自动拉取销售数据生成日报。还有一个方向是多Agent协作。现在是一个模型处理所有任务未来可以拆成多个专业Agent比如一个负责查数据、一个负责写文案、一个负责审核它们之间通过消息传递协作。这个复杂度高很多但能处理更复杂的业务场景。我个人在实际操作中的体会是不要追求一步到位。我一开始想做一个全能助手结果什么场景都做不好。后来聚焦在“客服问答订单查询”这一个场景把准确率做到95%以上再逐步扩展。先把一个场景跑通、跑稳比铺开十个半成品有价值得多。另外日志一定要详细每次模型调用、工具执行、任务状态变更都记下来出问题时能快速回溯。我现在的日志表每天新增几万条记录但排查效率提升了十倍不止。