摘要在医疗智能系统从“单轮问答工具”向“长期运行的专业代理”演进的过程中系统能力的上限已不再仅由基础模型参数规模决定而越来越取决于它是否具备持续感知环境、沉淀经验、对反馈进行学习、在安全边界内渐进优化的工程能力。传统医疗AI往往是离线训练、静态部署、周期更新的模式模型训练完成后被封装到服务中系统上线后按照既定规则接收输入、输出结果直到下一个版本发布才进行整体替换。这种模式在图像分类、结构化预测、辅助编码等任务中长期有效但在高度动态、强上下文依赖、知识迭代快且责任要求极高的医疗场景中静态系统的局限性正变得愈发明显。理想中的医疗智能体不应只是“会回答”的模型而应是一个可持续运行、能够保留工作上下文、沉淀情景经验、追踪结果反馈、在多模块治理框架下逐步自我优化的系统实体。它需要像临床团队中的助理成员一样在值守过程中理解患者状态变化在与医生和患者的互动中更新记忆在面对新指南、新药物、新证据时完成知识同步并在严格审计与人工监督下形成“可回溯、可解释、可限制”的演化机制。本文围绕“动态记忆、持续运行、自我进化”三个关键能力系统性地扩展一个基于Python技术栈构建的自进化医疗智能体架构。文章不仅介绍模块划分和关键数据流也强调工程实现中的现实问题如何设计短期记忆、长期语义记忆和情景记忆的协同机制如何利用asyncio、消息队列、任务调度和事件驱动范式构建7×24小时可用的运行引擎如何通过在线学习、反馈闭环、模型版本管理、评估网关和热更新体系实现稳定、可控的迭代升级又如何在医疗合规前提下处理隐私保护、解释性、人工兜底、偏差治理和审计追踪等问题。本文面向的读者包括医疗AI架构师、Python后端工程师、MLOps团队、临床信息化研发人员以及正在构建长期运行代理系统的技术负责人。全文遵循“概念—架构—实现—治理—部署—演进”的逻辑展开力图从工程实战视角给出一套能够落地、可扩展、可审计的医疗智能体设计蓝图。1. 引言为什么医疗智能体必须具备“自进化”能力1.1 从静态模型到持续运行代理的范式转移过去几年医疗AI的主要建设路径集中在两个方向一类是面向特定任务的监督学习模型例如糖尿病风险预测、肺结节检测、病理图像分级等另一类是基于大语言模型的医疗问答与病历辅助生成系统。这些系统虽然显著提升了效率但其核心逻辑大多仍停留在“请求—响应”的被动服务模式接收一个输入调用模型推理返回一个结果。系统本身并不会在运行过程中保留稳定的长期状态也不会基于真实世界的反馈对未来行为进行结构化修正。然而医疗工作天然具有长期性、连续性与上下文依赖。一个患者的慢病管理往往跨越数月甚至数年一条临床建议是否有效往往要在后续检验指标、症状缓解程度、医嘱执行情况中才能得到验证一项新临床指南的发布可能立刻改变系统原有的推荐逻辑。如果智能系统不能持续记忆、持续运行、持续更新它就只能成为“每次都重新开始”的工具而无法成为“越用越懂场景”的智能代理。因此我们需要将医疗智能体理解为一种具备以下属性的复合系统状态性系统能够跨轮次、跨会话、跨时间窗口保存和提取上下文。持续性系统不依赖单次调用存在而是作为长期在线服务持续接收事件。演化性系统能够根据反馈、指标、知识变更和策略评估逐步更新自身行为。可治理性系统所有演化行为都处于严格监管之下可解释、可回滚、可审计。1.2 医疗领域为何比其他行业更需要动态记忆在电商、客服、办公等场景中记忆机制主要用于提高对话连贯性或个性化推荐而在医疗场景中记忆本身就是临床质量的重要组成部分。一个医疗智能体如果忘记患者此前对某药物过敏、忘记患者三个月前曾出现相似症状、忘记此前医生明确拒绝某类建议那么它的“智能”不只是体验差而可能直接造成风险。医疗场景中的记忆至少分为三类工作记忆当前会话、当前就诊流程、当前监测周期内最相关的变量。语义记忆通用医学知识、临床路径、药品说明、指南共识、流程规则。情景记忆患者历史案例、关键诊疗节点、系统曾给出的建议与结果、真实反馈与纠偏记录。只有当这三类记忆协同工作时智能体才具备“上下文连续性 知识准确性 经验可迁移性”的综合能力。1.3 “自我进化”不意味着系统可以无约束学习必须强调医疗智能体中的“自我进化”绝不是让系统像消费级推荐算法那样随时自由改写行为规则。医疗系统的演化必须受到强约束不能直接依据未经验证的单条反馈修改关键诊疗逻辑不能让在线学习模块绕过审计直接影响高风险输出不能因为局部人群样本偏差而造成整体策略偏移不能因为知识更新不完整而输出“看起来更近、实际上更错”的建议。因此自进化更准确的定义应是在多层安全网关、人工审核、指标验证、版本控制和回滚机制约束下对系统中的知识、策略、参数和检索行为进行持续优化。1.4 本文的目标与结构本文希望完成三件事第一提出一个完整的医疗智能体分层架构而不是零散地讨论单一技术点。第二以 Python 为核心技术栈给出可操作的模块设计、示例代码与工程实现思路使架构不仅停留在概念层面。第三从医疗治理的现实要求出发把安全、合规、解释、日志、版本与人工介入设计为架构的一部分而不是部署后的附加补丁。接下来的内容将依次展开架构总览、动态记忆系统、持续运行引擎、自我进化模块、核心代码实现、安全合规、部署运维、性能优化、典型场景与未来演进路线。2. 架构总览一个长期在线的医疗智能体应当如何分层2.1 总体设计原则在设计医疗智能体架构时最容易犯的错误是把所有能力都堆进一个“大模型调用函数”中例如输入进入一个 prompt 模板附带若干检索结果模型输出答案最后写日志结束。这种方式短期内实现很快但随着场景复杂度上升会迅速暴露以下问题上下文管理混乱无法明确哪些信息应短期保留、哪些应长期持久化服务进程不可持续调度难以处理异步任务、周期任务和事件回放模型、知识库、规则引擎和反馈链路耦合更新任一模块都可能影响整体稳定性安全策略散落在业务代码中审计和合规检查成本极高。因此一个成熟的架构应当遵循以下分层原则输入感知层与决策层解耦让解析、标准化、结构抽取成为独立阶段。记忆层与推理层分离记忆系统负责状态保持推理系统只在需要时读取与写入。在线运行层与学习更新层隔离实时服务优先稳定学习模块异步运行并受控发布。高风险动作必须经过策略与权限网关尤其是临床建议、用药相关提示和告警触发。所有变化都可追踪包括输入、检索片段、推理路径、版本号、人工反馈与更新记录。2.2 典型模块分解一个完整的自进化医疗智能体至少包含以下模块感知模块负责接收文本、结构化数据、监测指标、设备消息、接口事件并进行标准化处理。决策模块结合规则、检索和模型执行诊断辅助、风险评估、计划生成或问答推理。执行模块负责将结果转化为可交付输出例如医生工作站建议、患者提醒、API 响应、告警通知。动态记忆系统提供短期工作记忆、长期知识记忆与情景记忆的统一读写接口。持续运行引擎基于事件循环、消息队列和任务调度维持系统常驻运行。自我进化模块收集反馈、评估策略、训练新模型、管理版本并执行热更新。治理与审计模块实现权限控制、日志追踪、解释生成、风险分级和人工审批。如果把整个系统视作医院中的一个智能协作角色那么感知模块相当于“接诊与信息接收”决策模块相当于“分析与建议生成”执行模块相当于“沟通与执行”记忆系统相当于“病历、知识库与经验库”持续运行引擎相当于“值班机制”自我进化模块相当于“继续教育与质控复盘”治理模块相当于“医疗伦理与监管制度”。2.3 数据流的关键闭环我们可以把数据流抽象成一个六阶段闭环事件输入例如患者新上传了血糖数据、医生发起药物问答、系统收到新的指南更新通知。上下文组装从短期记忆读取当前会话状态从情景记忆读取患者关键历史从长期知识库进行语义检索。推理与决策结合规则、模型与检索结果生成候选建议。风险控制与解释生成高风险建议增加置信度校验、规则过滤、人工确认需求并补充来源说明。结果执行与记录将最终结果发送到目标端同时写入审计日志与情景记忆。反馈回流与学习医生采纳、修改、拒绝或患者后续结局进入系统成为未来学习信号。这六阶段闭环决定了一个系统是否真的具有“持续认知能力”。如果只有前四步没有后两步那仍然只是一个高级推理接口而不是自进化代理。2.4 为什么 Python 适合这类系统Python 在医疗智能体架构中的优势并不只是“生态丰富”这么简单而是因为它同时覆盖了三个关键层次AI 层拥有丰富的机器学习、深度学习、NLP、LLM、向量检索和解释性工具链服务层具备成熟的异步框架、任务调度、消息队列客户端、Web API 框架和监控集成能力数据层在结构化、半结构化、时序、对象存储、数据湖和流式处理领域都有稳定支持。更重要的是Python 的“胶水语言”特性非常适合连接模型、数据库、调度系统、规则引擎、日志平台和可视化分析工具这使其成为构建医疗智能体原型乃至生产架构的高效选择。3. 动态记忆系统让智能体真正“记住”医疗场景3.1 记忆不是缓存而是系统能力的一部分在很多工程实现中开发者把“记忆”简单理解为会话缓存把前几轮对话存在 Redis下一轮取出来拼进 prompt。这种做法可以提升对话流畅度但远不足以支撑医疗智能体。真正的动态记忆系统应回答以下问题当前任务最需要哪些信息哪些信息应快速遗忘哪些应长期保留长期保留的信息如何被高效检索患者级信息、知识级信息、系统经验级信息如何区分如何避免记忆无限膨胀、污染和冲突因此我们将医疗智能体的记忆划分为三个层次短期工作记忆、长期语义记忆、情景记忆。3.2 短期工作记忆当前任务上下文的高速缓存区短期工作记忆用于存放当前任务窗口内最重要的信息例如患者本次会话中的主诉、补充症状、对系统追问的回答当前监测窗口内的生命体征异常值医生刚刚输入的补充约束例如“患者肾功能不全请避免肾毒性药物”当前正在执行的推理计划与中间状态。这类信息具有三个特点生命周期短通常按分钟到小时计读写频繁要求低延迟过时后不一定需要永久保存但其中一部分应提炼后写入情景记忆。因此短期工作记忆非常适合使用Redis进程内 LRU/TTL CacheFastAPI Redis Session Store在多实例部署下使用共享缓存集群设计短期记忆时要避免一个误区把所有上下文全文堆进去。更好的方式是为短期记忆设计结构化键空间例如session:{session_id}:dialogue_statepatient:{patient_id}:active_monitoringtask:{task_id}:reasoning_plandoctor:{user_id}:current_preferences这样不仅便于过期控制也方便不同模块按需读取而不是全量反序列化。3.3 长期语义记忆医学知识库的可检索抽象层长期语义记忆主要存放相对稳定但会逐步更新的知识内容包括临床指南共识文件药物说明书不良反应信息诊疗路径医院内部流程规范医学教材或权威综述摘要与传统关键字检索相比向量化长期记忆的优势在于它支持语义匹配。当医生问“有糖尿病肾病且伴高钾风险的高血压患者降压药怎么选”时系统不必依赖完全一致的关键词而可以从相关指南片段中召回 ACEI、ARB、肾功能监测、高钾禁忌等语义相关内容。长期语义记忆常见实现包括FAISS本地高性能向量索引适合中小规模和单机原型ChromaDB开发友好适合原型与中等规模系统Milvus / Weaviate / Qdrant更适合生产级向量检索服务混合检索向量检索 BM25 元数据过滤。在医疗场景中长期语义记忆必须特别注意以下几点来源可信知识来源应具备清晰权威性禁止把未经审查的论坛内容与临床指南混入同一检索空间。版本可控指南更新后不能简单覆盖旧内容而应保留版本与生效日期。领域分层药学、影像、慢病管理、护理规范等最好按 collection 或 metadata 分域存储。检索后验证被召回的内容不能直接当作最终答案还要经过规则与模型解释层处理。3.4 情景记忆让系统从真实病例与交互中积累经验情景记忆是最容易被忽视、但最能体现“自进化”价值的一类记忆。它记录的不是通用医学知识而是具体情境中的行为轨迹例如某患者在过去 6 个月中多次血压异常系统曾发出提醒医生调整了用药方案随后血压控制改善某次问答中系统建议做 D-二聚体检查但医生标记该建议不适用于当前病例因为患者近期术后存在特殊背景某类药物提醒在老年患者群体中被频繁拒绝提示规则可能过于激进某版本模型在儿科场景中置信度偏高但错误率上升后续被回滚。情景记忆兼具“病例经验库”和“系统行为日志库”的双重属性。它通常包含以下字段事件时间患者 ID / 脱敏标识输入摘要系统建议证据来源模型版本风险等级医生反馈后续结局归档标签这类数据既可以落在结构化数据库中也可以采用时序数据库或事件存储系统。对于高频监测与连续事件序列例如穿戴设备生命体征数据、用药提醒执行情况、告警次数等时序数据库非常适合对于高价值病例推理链路则可以采用 PostgreSQL / ClickHouse / Elasticsearch 等存储分析组合。3.5 三类记忆的协同机制真正的动态记忆不是三套数据库并列存在而是它们之间存在“流动关系”短期工作记忆中的关键摘要会沉淀到情景记忆长期语义记忆为当前推理提供知识支持情景记忆可反向生成“经验特征”辅助决策模块当长期知识更新时旧情景记忆可被重新解释和标记。一个典型流程如下患者上传三天血糖波动数据进入短期工作记忆决策模块从长期知识库检索到糖尿病管理和胰岛素调整相关内容系统生成“建议进一步评估饮食依从性并关注夜间低血糖”的提示医生采纳并增加饮食教育两周后患者夜间低血糖减少该结果写入情景记忆后续当系统遇到相似模式时可从情景记忆中检索出“曾经有效的干预路径”。这意味着系统不只是从文本知识中学习也从自身的实践轨迹中学习。3.6 记忆写入策略什么时候写、写什么、写到哪里医疗智能体常见的另一个问题是“什么都记”导致后期出现污染、重复和噪声。正确的做法不是让每一次中间计算都持久化而是建立分层写入策略。可参考以下原则短期记忆写入当前任务所需状态与临时上下文生命周期短。长期语义记忆只写入经过审核、结构化切分和质量检查的知识文档。情景记忆写入具有追踪价值的关键交互事件和反馈结果。例如医生与系统的十轮对话不需要全部进入情景记忆但如下内容值得持久化最终建议摘要最终选择的证据来源医生的明确采纳/修改/拒绝标签对患者后续结果具有影响的决策节点人工修正后的正确方案3.7 遗忘机制防止系统“越记越乱”记忆系统如果只会增长而不会整理迟早会成为系统性能与质量的负担。遗忘不是删除能力的缺失而是高质量记忆系统的一部分。医疗智能体中的遗忘机制至少包括TTL 过期适用于短期工作记忆。摘要压缩将长对话或长事件序列压缩为结构化摘要后保存。相似项合并长期知识库中近重复内容聚类去冗余。版本淘汰与归档过时指南和模型输出保留冷存储而非在线热检索。置信度衰减对旧情景记忆的影响力随着时间和外部知识更新而降低。一个成熟系统中的“遗忘”不是简单删除而是从热数据转移为温数据、冷数据或结构化摘要既保证可追溯也避免检索污染。4. 持续运行引擎构建 7×24 小时在线的医疗智能体服务4.1 为什么事件驱动比请求驱动更适合医疗代理医疗代理并不总是“有人调用时才工作”。很多任务是被事件触发的例如患者心率超过阈值新化验结果回传预约到期需要提醒随访系统检测到某模型指标异常每日凌晨需要归档日志、计算质量指标、同步知识库更新。如果把这类系统完全做成同步 Web API那么很多能力会变得笨重、脆弱或难以扩展。相比之下事件驱动架构具有以下优势可自然处理异步输入可以将实时请求与后台耗时任务解耦便于做失败重试、死信队列、削峰填谷更容易构建“常驻代理”而非“调用函数”。Python 的asyncio、aio_pika、FastAPI、APScheduler、Celery等工具链可以很好支撑这类架构。4.2 运行引擎的核心职责持续运行引擎至少应承担以下职责维护消息消费与事件分发管理异步任务与后台作业控制定时任务执行处理失败重试与超时中断跟踪运行态指标与健康状态在不中断服务的情况下配合热更新。因此它本质上是医疗智能体的“操作系统层”。4.3 事件来源的分类系统需要处理的事件通常包括用户事件患者问答、医生指令、人工反馈。设备事件可穿戴设备上传、床旁监护数据、血糖仪数据。业务事件新订单、新化验单、新预约、新住院节点。系统事件知识库刷新、模型版本变更、告警阈值调整。定时事件每日摘要、每周质量报告、每小时缓存整理。不同事件在优先级、时效性、可靠性要求上差异巨大。举例来说心率骤降告警事件必须秒级处理模型评估报告可以分钟级甚至小时级处理历史病例归档可以放在夜间低峰执行。因此消息队列中最好按事件类型拆分路由与优先级而非所有任务共用同一消费管道。4.4 异步架构中的关键设计点使用asyncio并不意味着系统天然高可用。要做到长期稳定运行需要特别注意幂等性消息重复投递时不会造成重复写入或重复告警。背压控制突发事件量过大时要能限流或分级处理。超时与取消长时间推理不能阻塞整个循环。资源隔离高优先级临床任务不应与低优先级维护任务抢占同一资源池。上下文传递trace_id、patient_id、model_version 等要在异步任务间保持可追踪。优雅停机部署更新时允许任务收尾并安全切换。4.5 定时任务与事件任务的分工一个常见误区是把所有任务都挂在调度器里。实际上调度器与消息队列应承担不同角色消息队列处理不可预测、实时触发的事件。调度器处理周期性、固定触发的维护和分析任务。例如适合调度器的任务每 5 分钟检查模型健康指标每小时整理短期记忆垃圾每日同步新的临床文献摘要每周执行回放测试与版本评估。适合消息队列的任务患者刚上传新的心电事件医生对系统建议进行修改外部 EHR 推送新的检验数据设备告警触发紧急处理流程。4.6 为什么医疗智能体需要“会话内同步 系统级异步”的双模式许多任务需要在单次请求内立即给出结果例如医生发起问答时通常希望数秒内返回建议但同一任务的后续处理又适合异步执行例如保存审计记录触发反馈分析更新情景记忆投递随访任务进入质量评估流水线。因此推荐将一次任务拆分为同步主链路最小必要推理与返回。异步副链路补充记录、分析、缓存更新与学习触发。这样既保证用户体验也让系统具备演化能力。5. 决策系统模型、规则与检索如何协同5.1 医疗决策不能只靠一个模型输出在医疗场景中直接让一个大模型“根据上下文自由生成建议”存在明显风险。医学决策往往涉及多个层次事实抽取是否准确检索知识是否可靠当前患者是否满足某规则的前提某建议是否触发禁忌检查输出语气是否符合“建议而非诊断”要求是否需要人工确认。因此更稳健的决策系统通常采用“规则 检索 模型”的混合体系规则层处理禁忌、阈值、流程规范、强约束逻辑检索层提供知识与证据来源模型层进行理解、归纳、对话生成、复杂推理。5.2 决策流水线的推荐顺序一个典型的决策流水线可以按如下顺序执行输入标准化结构化字段解析、单位换算、术语标准化。高风险规则预筛查例如过敏禁忌、危急值告警、年龄/孕期/肾功能限制。上下文拼装读取患者关键情景记忆与本次工作记忆。知识检索从长期记忆中召回候选证据。模型推理生成候选建议和解释草稿。后规则校验检查输出是否违反强约束。风险分级决定是否直接输出、降低置信度或要求人工确认。结果格式化形成适配医生端或患者端的表达。这种顺序可以最大程度减少模型幻觉对最终结果的直接影响。5.3 医疗代理中的规则引擎不是“落后技术”很多团队在引入大模型后倾向于淡化规则引擎认为规则不够智能。然而在医疗场景中规则引擎不是替代模型而是守住底线的装置。例如肾功能不全患者避免某些药物儿童剂量与成人剂量不能混用已记录青霉素过敏则应阻断相关建议化验危急值必须优先进入人工告警流程对患者端输出不能出现确诊式表述。这些约束不是“经验提示”而是不能被模型自由发挥覆盖的边界。5.4 置信度与不确定性表达医疗智能体的成熟度不只体现在“能给出答案”更体现在“知道自己何时不该过度自信”。系统应在输出层显式表达不确定性例如建议级别强、一般、弱证据来源等级结论置信区间或内部置信评分是否缺失关键输入是否建议转人工复核。例如不应输出“患者应立即使用某药物”而应输出基于当前提供的症状、既往史和相关指南片段系统认为该方向具有中等支持度但由于缺少肝肾功能指标与当前用药清单建议由临床医生进一步确认后决定是否采用该方案。这种表达既更符合医疗伦理也便于建立用户信任。6. 自我进化模块让系统在治理框架中持续变强6.1 自我进化的四个层次医疗智能体的“进化”可以发生在多个层级而不是只有模型参数更新一种方式知识层进化新增指南、新药品说明、新流程规则进入系统。检索层进化改进分块、嵌入、召回排序、过滤策略与重排器。策略层进化基于反馈优化提示词、规则阈值、工具调用顺序和风险分级逻辑。参数层进化在线学习、小模型增量训练、PEFT 微调、大模型再训练。其中前 13 层通常风险较低、收益较稳定应该优先完善第 4 层虽然潜力大但也是最需要严格治理的部分。6.2 反馈信号来自哪里如果没有高质量反馈自我进化就会沦为空话。医疗系统中的反馈来源主要有医生对建议的采纳、修改、拒绝患者行为结果如是否按时服药、是否完成复诊临床结局如指标改善、再入院、并发症发生系统运行指标如告警过多、延迟异常、召回片段质量下降专家复盘标注如质控团队对病例推理链的审查。这些反馈不能混为一谈。医生拒绝某建议并不等于该建议绝对错误可能只是当前病例不适用患者没有执行提醒也不意味着提醒内容错误可能是依从性问题。因此反馈采集后必须带有场景标签与上下文。6.3 在线学习适用于哪些模块在医疗架构中最适合在线学习的往往不是高风险的核心生成模型而是风险评分小模型排序模型 / 重排器用户偏好适配器触发阈值校准器告警优先级分类器规则推荐辅助器。这些模块结构相对清晰输入输出边界明确容易用流式学习方法进行逐步更新也更便于监控和回滚。6.4 为什么要把“学习”与“上线发布”拆开许多团队在做在线学习时会误以为模型参数一旦更新就应立即投入实时服务。医疗场景中这是高风险设计。更稳妥的方式是在线或近线地持续吸收反馈并生成候选模型将候选模型登记到模型仓库在离线回放集、对照集和安全测试集中评估通过审批流程后进入灰度或 A/B 测试确认收益稳定后再替换正式版本。也就是说“学习”是候选生成过程“上线”是治理决策过程两者不能混同。6.5 模型版本管理与回滚为何重要在传统软件中代码回滚已经是基本能力在医疗 AI 中模型回滚更应成为基础设施。因为模型错误往往比一般服务错误更隐蔽、更难被立刻发现。如果没有清晰的模型版本管理出现以下问题时几乎无法追责某一天起儿科场景错误率提升到底是哪个版本引入的问题某批患者建议异常激进是否和提示词模板变更有关某类检索召回变差是嵌入模型更新导致还是知识库重建导致因此每次运行中的关键结果都应绑定以下元信息模型版本号Prompt 模板版本号检索索引版本规则包版本知识源版本发布批次与时间6.6 自我进化中的“负反馈”比“正反馈”更有价值很多团队偏爱收集“医生采纳率”因为这是好看的指标。但真正能够推动系统进化的往往是以下高价值负反馈为什么被拒绝被修改成什么样缺失了哪些关键上下文哪一条证据片段误导了模型是召回问题、理解问题、表述问题还是流程问题只有把“错误归因”做细自我进化才有正确方向。否则系统可能只是不断放大表面指标而没有修复根因。7. Python 核心实现从示例代码走向工程化结构7.1 模块化目录设计建议一个原型系统很容易写成单文件脚本但面向生产的医疗智能体应具备清晰目录结构例如medical_agent/ ├── api/ │ ├── app.py │ └── routes/ ├── core/ │ ├── config.py │ ├── logging.py │ ├── security.py │ └── tracing.py ├── memory/ │ ├── short_term.py │ ├── long_term.py │ ├── episodic.py │ └── consolidation.py ├── reasoning/ │ ├── planner.py │ ├── retriever.py │ ├── rule_engine.py │ ├── llm_policy.py │ └── risk_control.py ├── runtime/ │ ├── consumer.py │ ├── scheduler.py │ ├── tasks.py │ └── healthcheck.py ├── evolution/ │ ├── feedback.py │ ├── online_learner.py │ ├── registry.py │ ├── evaluator.py │ └── hot_swap.py ├── observability/ │ ├── metrics.py │ ├── audit.py │ └── alerts.py └── tests/这种结构的好处在于记忆、推理、运行和演化各自拥有独立边界便于权限治理与团队协作。7.2 长期记忆的工程化封装原型代码里直接把向量库对象暴露在全局变量中是可以理解的但在生产中更适合将其封装为服务对象并补充collection 管理metadata 过滤写入校验文档版本追踪失败重试索引重建与快照示例fromdataclassesimportdataclassfromtypingimportList,Dict,Anyfromlangchain.schemaimportDocumentfromlangchain.vectorstoresimportChromadataclassclassRetrievalResult:content:strmetadata:Dict[str,Any]score:float|NoneNoneclassLongTermMemoryService:def__init__(self,vector_db:Chroma):self.vector_dbvector_dbdefadd_documents(self,docs:List[Document])-None:clean_docs[]fordocindocs:ifnotdoc.page_content.strip():continuemetadatadict(doc.metadataor{})metadata.setdefault(status,active)clean_docs.append(Document(page_contentdoc.page_content,metadatametadata))ifclean_docs:self.vector_db.add_documents(clean_docs)defsearch(self,query:str,k:int5,filters:Dict[str,Any]|NoneNone)-List[RetrievalResult]:docsself.vector_db.similarity_search(query,kk,filterfilters)return[RetrievalResult(contentd.page_content,metadatad.metadata)fordindocs]这种封装方式便于后续插入重排器、缓存和审计记录。7.3 短期记忆的结构化管理importjsonimportredisfromtypingimportAnyclassShortTermMemory:def__init__(self,host:strlocalhost,ttl_seconds:int3600):self.clientredis.Redis(hosthost,decode_responsesTrue)self.ttl_secondsttl_secondsdefput(self,key:str,value:Any)-None:self.client.set(key,json.dumps(value,ensure_asciiFalse),exself.ttl_seconds)defget(self,key:str)-Any|None:rawself.client.get(key)returnjson.loads(raw)ifrawelseNonedefappend_dialogue(self,session_id:str,role:str,content:str)-None:keyfsession:{session_id}:dialoguehistoryself.get(key)or[]history.append({role:role,content:content})self.put(key,history[-20:])