AI智能体的持续学习指的是智能体不是停留在模型发布时的固定能力上而是在每一次用户使用中积累上下文、修正偏好、沉淀知识从而让后续交互越来越准确。红杉资本Sequoia Capital在一篇题为“Continual Learning: How AI Agents Get Better”的技术观点文章中提出过这个判断真正有价值的 AI 智能体会随着每一次使用不断变好而不是每次都从零开始。这个观点点破了当前 AI 应用的核心差距——很多智能体看似“能对话”但换了一个用户、换了一个场景、隔了一天记忆就消失了。这篇文章不会停留在概念讨论上。我会先拆解 AI 智能体持续学习的几个层次再给出一个可运行的记忆系统骨架包含上下文管理、长期向量记忆、用户偏好提取、反馈数据采集和离线迭代闭环。这样做的目的是让读者不只理解“智能体应该越用越好”这句话而是能知道在自己的项目里到底应该改哪里、加什么表、写什么代码、怎么验证效果。适合阅读这篇文章的读者是有一定 Python 基础、接触过大模型 API、并且正在搭建或维护 AI 智能体的开发者。如果你已经跑通过一个简单的对话机器人但发现它“记不住事”“没有个性”“每次回答都一样”那么这篇文章正好对应你要解决的问题。1. 理解 AI 智能体持续学习的核心命题为什么使用本身就是数据1.1 从静态模型到使用中改进持续学习的定义大模型本身的训练是静态的。一个模型发布时它的知识截止时间、推理风格、指令遵循能力基本固定。要让模型变得更好常规路线是重新训练或微调但这个过程成本高、周期长不适合在每次用户对话后都执行。AI 智能体的持续学习指的是在模型能力不变的前提下通过外围系统把每一次使用过程中的信息保留下来并在后续推理时重新利用。保留的信息包括对话历史、用户偏好、任务结果、纠错反馈、领域知识片段。智能体通过这些信息在同一轮对话中逐步理解复杂任务在跨会话场景中记住用户习惯在系统迭代过程中不断优化提示词、知识库和评估标准。所以持续学习本质上不是“模型自己学会了新知识”而是“系统围绕模型建立了一套数据反馈机制”。这是理解整个主题的关键。1.2 三层持续学习会话内、跨会话、离线迭代持续学习在工程上可以拆成三个层次每个层次的实现方式、时效性和数据来源都不同。层次学习内容时效性典型实现数据来源会话内学习当前任务上下文、用户的临时约束毫秒到分钟级对话消息拼接、上下文截断、临时变量当前会话中的用户输入和工具返回跨会话学习用户长期偏好、历史事实、项目背景分钟到天级长期记忆表、向量数据库、偏好配置文件历史会话、用户手动填写、反馈确认离线迭代提示词、知识库、模型权重天到月级数据清洗、评估集、微调、A/B 测试全部会话日志、反馈记录、线上指标会话内学习解决“你刚才说的那个文件”这类指代问题。跨会话学习解决“用户每次都要重新描述自己的场景”这类效率问题。离线迭代解决“整个系统对一类任务长期表现不佳”这类质量问题。很多团队只做了第一层也就是把所有消息一股脑塞进上下文窗口。一旦上下文超过模型限制就截断、遗忘用户下次再来还是陌生人。这不叫持续学习只能算临时拼接。1.3 为什么简单的会话缓存不能算持续学习最基础的做法是把历史消息存到 Redis 或数据库里下次请求时再取出来拼进 prompt。这种做法确实能实现“对话过程中不失忆”但它有几个明显问题。第一没有信息筛选。所有历史、噪音、无关内容都混在一起既浪费 token又干扰模型判断。用户上个月问过一句无关紧要的问题如果被检索出来反而会影响当前回答质量。第二没有结构化的用户画像。即使记住了上一轮内容系统也不知道用户的行业、角色、偏好、禁忌无法在新任务里主动适配。第三没有反馈信号。用户对回答满意还是不满意哪里需要修正系统完全不知道。没有反馈就没有迭代方向。第四没有离线指标。系统是否真的在变好说不清楚无法支撑后续优化决策。因此持续学习的工程核心不是“存储”而是“筛选、结构化、反馈、迭代”四个动作的闭环。只有把这一整条链路搭起来智能体才谈得上“越用越好”。2. 学习环境与演示项目设计用 Python 搭建一个带记忆的智能体骨架2.1 技术选型说明为了把上面的分层设计落地到一个可以运行的最小项目这里选择一套轻量技术栈。选型原则是容易理解、本地可跑、能够直接替换成生产组件。建议环境如下Python 3.10 或更高版本。FastAPI 作为接口服务方便模拟智能体 HTTP 调用链路。SQLite 存储会话记录、用户偏好和反馈事件。生产环境可替换为 PostgreSQL。向量检索使用 FAISS 或 Chroma。生产环境可替换为 Milvus、pgvector 或云上向量数据库。大模型 API 使用 OpenAI 兼容接口。如果你使用其他模型服务只需要替换调用代码。LangChain 用于组装聊天和记忆逻辑。不用也可以但用它可以减少样板代码。下面所有代码都只做演示实际项目需要结合自己的包名、路径和模型版本调整。2.2 项目结构和依赖创建项目目录mkdir agent-continual-learning cd agent-continual-learning创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate写入requirements.txtfastapi0.115.6 uvicorn0.34.0 openai1.57.4 langchain0.3.14 langchain-openai0.2.14 chromadb0.5.23 pydantic2.10.4 python-dotenv1.0.1安装依赖pip install -r requirements.txt在项目根目录创建.env文件OPENAI_API_KEYyour-api-key OPENAI_BASE_URLhttps://api.openai.com/v1如果你使用的是其他兼容服务把OPENAI_BASE_URL改成你自己的网关地址即可。注意这里没有固定模型名称因为不同服务商、不同项目的模型版本差异较大。落地前要先确认自己使用的模型支持哪些能力以及上下文窗口有多大。2.3 目录结构设计持续学习系统涉及存储、检索、服务、反馈处理不适合把所有代码放在一个文件里。下面这个结构只是一个建议重点是让每一层职责清晰。agent-continual-learning/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置读取 │ ├── memory/ │ │ ├── __init__.py │ │ ├── session_memory.py # 会话内上下文管理 │ │ ├── long_term.py # 跨会话长期记忆 │ │ └── preferences.py # 用户偏好提取与更新 │ ├── feedback/ │ │ ├── __init__.py │ │ └── collector.py # 反馈采集与落库 │ └── llm/ │ ├── __init__.py │ └── client.py # 大模型调用封装 ├── data/ # SQLite 与向量数据存放目录 ├── requirements.txt └── .env学习阶段可以先把部分模块写在同一个文件里减少跳转理解后再拆分。生产环境则建议按目录拆分方便测试和维护。3. 实现三层记忆上下文、长期向量记忆、用户偏好3.1 第一层会话窗口内的上下文管理会话内上下文管理要解决的核心问题是历史消息很多但模型上下文有限不能把所有内容都塞进去。常见的处理顺序是保留系统提示词这部分不可压缩。优先保留用户最近的输入因为当前意图最重要。保留与当前问题最相关的历史片段而不是全部历史。如果历史仍然过长按时间倒序截断并记录截断摘要。下面给出一个最小实现使用 LangChain 的ChatMessageHistory管理会话消息from langchain.memory import ChatMessageHistory from langchain_core.messages import SystemMessage, HumanMessage, AIMessage class SessionMemory: def __init__(self, max_messages: int 20): self.history ChatMessageHistory() self.max_messages max_messages def add_user_message(self, content: str): self.history.add_user_message(content) def add_ai_message(self, content: str): self.history.add_ai_message(content) def build_messages(self, system_prompt: str): messages [SystemMessage(contentsystem_prompt)] recent self.history.messages[-self.max_messages:] messages.extend(recent) return messages这里要注意max_messages的作用。它不是简单截断字符串而是从消息列表中取最近 N 条。这样做能在一定程度上保留当前任务上下文但代价是较早的信息可能丢失。如果需要更精细的控制可以按 token 数截断。LangChain 提供了基于 token 的trim_messages示例from langchain_core.messages import trim_messages trimmed trim_messages( self.history.messages, max_tokens4000, strategylast, token_counterlen, start_onhuman, include_systemTrue, )这段代码的意思是最多保留 4000 token 的消息优先保留靠后的内容并且不能截断系统提示词。start_onhuman表示从一条人类消息开始避免把 AI 回复拦腰截断。3.2 第二层跨会话长期记忆与向量检索跨会话记忆要解决的问题是用户第二天回来智能体还记不记得这个用户是谁、关心什么、之前聊过什么结论。一个常用设计是“用户 记忆条目”结构。每条记忆包含内容、类型、创建时间、最近访问时间、来源会话。为了支持语义检索还要把记忆内容向量化。建表 SQLCREATE TABLE IF NOT EXISTS long_term_memory ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, content TEXT NOT NULL, memory_type TEXT NOT NULL DEFAULT fact, source_session_id TEXT, importance REAL DEFAULT 0.5, created_at TEXT DEFAULT CURRENT_TIMESTAMP, updated_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_memory_user ON long_term_memory(user_id);memory_type可以区分事实、偏好、任务进度、承诺等。importance表示这条记忆的重要程度后续可以参与检索排序。使用 Chroma 做向量检索。初始化import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./data/chroma) embedding_fn embedding_functions.OpenAIEmbeddingFunction( api_keyos.getenv(OPENAI_API_KEY), model_nametext-embedding-3-small ) collection client.get_or_create_collection( nameagent_memory, embedding_functionembedding_fn )写入记忆并向量化def save_memory(user_id: str, content: str, memory_type: str, session_id: str): memory_id f{user_id}_{int(time.time())}_{uuid.uuid4().hex[:8]} # 写入 SQLite 便于结构化查询 cursor.execute( INSERT INTO long_term_memory (user_id, content, memory_type, source_session_id) VALUES (?, ?, ?, ?), (user_id, content, memory_type, session_id) ) conn.commit() # 写入向量库 collection.add( ids[memory_id], documents[content], metadatas[{ user_id: user_id, memory_type: memory_type, created_at: time.time() }] )检索相关记忆def search_memory(user_id: str, query: str, top_k: int 5): results collection.query( query_texts[query], n_resultstop_k, where{user_id: user_id} ) return results[documents][0]这里有一个关键点检索必须按user_id过滤。如果不加过滤所有用户的记忆会混在一起出现“串味”问题。多租户场景下这个过滤条件就是数据隔离的第一道防线。为什么用向量检索而不是直接 SQL 关键词匹配因为用户表达同一件事的方式千差万别。比如用户第一次说“我负责华北区销售”第二次问“我们区域这个月目标是多少”关键词匹配很难把“华北区”和“我们区域”关联起来向量检索可以做到。3.3 第三层用户偏好提取与更新偏好不是用户主动填写的表单而是系统从对话中抽取并随着使用不断修正的结构化信息。比如用户喜欢简洁回答、喜欢用表格、不喜欢术语、需要邮件格式输出这些都是偏好。最简单的方式是让大模型从每轮对话中抽取偏好片段再用结构化输出落到存储中。from openai import OpenAI import json client OpenAI() PREFERENCE_EXTRACT_PROMPT 你是一个用户偏好抽取器。根据以下对话抽取关于用户的长期偏好。 偏好包括表达风格、常用格式、领域背景、禁忌话题、工作习惯。 如果没有明确信息不要猜测。 对话历史 {history} 请输出 JSON格式为 {preferences: [{type: style|format|domain|taboo, content: 描述, confidence: 0.0}]} def extract_preferences(history_text: str) - list: response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: PREFERENCE_EXTRACT_PROMPT.replace({history}, history_text)} ], response_format{type: json_object} ) data json.loads(response.choices[0].message.content) return data.get(preferences, [])抽取出的偏好不要直接覆盖旧值而要做合并。常见策略是新偏好与旧偏好冲突时以最近一次为准。新偏好是对旧偏好的细化时保留更具体的表述。多条同类型偏好同时存在时给每条加confidence用户后续行为会修正它。把偏好合并到系统提示词中智能体就能在后续对话中自动适配。def build_system_prompt(profile: dict) - str: lines [] lines.append(你是用户的 AI 助手。) if profile.get(style): lines.append(f表达风格{profile[style]}) if profile.get(domain): lines.append(f用户领域{profile[domain]}) if profile.get(taboo): lines.append(f避免内容{profile[taboo]}) return \n.join(lines)这里要注意一个风险偏好抽取结果来自大模型本身可能有误。生产环境不要直接把抽取结果当作事实写入长期记忆至少要经过用户显式确认或行为验证。3.4 三层之间的协作流程三层记忆不是独立的而是按请求链路协作。一次完整的带持续学习的请求流程如下接收用户输入从 HTTP Header 或 Token 中解析用户 ID。从 SQLite 读取用户偏好拼入系统提示词。用向量检索查长期记忆中与当前问题相关的内容也放入系统提示词或上下文。再从当前会话历史中截取最近消息。调用大模型生成回答。回答返回后异步抽取新的偏好和记忆写入存储。记录用户反馈更新记忆的重要性和置信度。第 6 步和第 7 步可以异步执行避免拖慢用户请求。这样设计的好处是用户请求延迟不依赖记忆写入速度同时数据仍在持续积累。4. 让每次使用产生数据反馈采集、评估与数据记录4.1 反馈信号采集显式反馈与隐式反馈没有反馈持续学习就是空转。反馈信号分为两类。显式反馈指用户主动表达的态度比如点赞、点踩、纠错、提交修改。这类信号质量高但用户通常不愿意频繁操作所以数量稀少。隐式反馈指从用户行为中推断的信号比如用户是否复制了回答、是否继续追问、是否在回答后立即关闭页面、是否要求重新生成。这类信号数量多但噪音大。在生产项目中至少要把显式反馈完整记录下来。下面是一个反馈事件表CREATE TABLE IF NOT EXISTS feedback_events ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, session_id TEXT, message_id TEXT, feedback_type TEXT NOT NULL, feedback_value INTEGER NOT NULL DEFAULT 0, detail TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP );feedback_type取thumbs_up、thumbs_down、correction等feedback_value可以是1、-1这样的简化分值。反馈采集接口from fastapi import APIRouter from pydantic import BaseModel router APIRouter(prefix/feedback) class FeedbackBody(BaseModel): user_id: str session_id: str message_id: str feedback_type: str feedback_value: int detail: str router.post() def submit_feedback(body: FeedbackBody): cursor.execute( INSERT INTO feedback_events (user_id, session_id, message_id, feedback_type, feedback_value, detail) VALUES (?, ?, ?, ?, ?, ?), (body.user_id, body.session_id, body.message_id, body.feedback_type, body.feedback_value, body.detail) ) conn.commit() return {ok: True}4.2 评估指标从单次调用到任务级质量持续学习要回答的问题不只是“系统有没有在变好”更是“哪些用户在变好、哪类任务在变好、哪次改动导致了变好”。这需要指标分层。第一层是调用级指标。单次问答的用户反馈分、是否包含引用、响应时间、是否超时、token 消耗。第二层是会话级指标。一次会话是否完成用户的目标用户是否反复纠正纠错次数是否下降。第三层是系统级指标。一段时间内整体好评率、用户留存、重复提问率、知识库命中率、任务完成率。用表记录每日指标CREATE TABLE IF NOT EXISTS daily_metrics ( date TEXT PRIMARY KEY, total_sessions INTEGER, total_messages INTEGER, thumbs_up INTEGER, thumbs_down INTEGER, correction_count INTEGER, avg_tokens_per_message REAL, memory_hit_rate REAL );memory_hit_rate表示一次回答引用长期记忆的比例。如果这个值长期很低说明检索链路或记忆写入策略有问题如果过高则要关注是否检索到了无关内容。4.3 数据落库事件与样本的标准化记录日志和记录样本是两件事。日志面向排查样本面向训练和评估。下面是一个标准样本结构{ user_id: user_123, session_id: session_456, timestamp: 2024-11-01T10:15:00Z, input: { query: 帮我总结上周华北区销售数据, retrieved_memories: [ {content: 用户负责华北区销售, score: 0.82} ], context_tokens: 3200 }, output: { answer: 好的根据上周数据……, model: gpt-4o-mini, prompt_tokens: 3400, completion_tokens: 280 }, feedback: { type: thumbs_up, value: 1 } }这样的样本既可以用来做离线分析也可以作为未来微调或强化学习的候选集。注意在生产环境中要对user_id做脱敏处理尤其当对话内容涉及个人信息时。5. 离线迭代用实际使用数据优化系统5.1 数据清洗与数据集构建收集到的原始数据不能直接用于优化。原因有两个一是反馈噪音多用户点踩的原因可能是网络卡顿而不是回答质量差二是同样的请求重复出现会干扰评估结果。清洗顺序建议删除空输入、纯符号输入、明显测试请求。过滤包含个人敏感信息的样本。去重同一个用户对同一问题的重复请求只保留最新一条。对feedback_value0或没有反馈的样本单独存放不进入正负样本集。人工抽检建立评估集。评估集是离线迭代的基础。它应该包含三类样本历史真实请求。人工构造的边界问题。上一轮迭代中回答错误的样本。每次系统变更后在评估集上跑一遍对比回答质量和指标变化。5.2 三种优化路线提示词、RAG、微调离线迭代不一定非要微调模型。资源有限时优先按成本从低到高的顺序尝试。提示词优化成本最低。当一类问题普遍表现不好时改进系统提示词、增加约束条件、加入 few-shot 示例往往能解决大量问题。提示词变更可以结合 A/B 测试验证效果。RAG 优化次之。当系统回答不准确是因为知识不足时扩充知识库、优化分块策略、调整检索 TopK、增加重排模型都能提升回答质量。RAG 优化要注意知识库来源的权威性不要让错误知识进入检索结果。微调成本最高。只有当提示词和 RAG 都无法解决问题且错误有明确模式时才考虑微调。微调需要构建高质量的对话样本集并且要准备回归测试防止模型在其他问题上能力退化。下面是一个回归测试脚本的简化示例EVAL_CASES [ { query: 我上周让你记录的项目截止时间是什么, expected_keywords: [周一, 产品评审], category: memory_retrieval }, { query: 用三句话总结今天的会议纪要, expected_style: concise, category: style }, ] def run_regression(model_name: str) - dict: results [] for case in EVAL_CASES: answer call_agent(model_name, case[query]) ok all(kw in answer for kw in case.get(expected_keywords, [])) results.append({query: case[query], pass: ok, answer: answer}) return results5.3 回归测试与版本化发布持续学习系统最怕“改好了 A 类问题弄坏了 B 类问题”。版本化发布是必要的防线。建议把提示词、知识库、记忆抽取策略、模型名称都作为可配置项变更时走同一套发布流程。示例配置agent_version: 2024.11.01-r1 model: chat_model: gpt-4o-mini embedding_model: text-embedding-3-small prompt: version: v3 template_file: prompts/assistant_v3.txt memory: top_k: 5 similarity_threshold: 0.4 preference_confidence: 0.6发布前检查清单在评估集上跑完整回归确认整体通过率不低于上一版本。抽查 20 条真实用户对话人工判断是否有明显退化。检查存储写入是否异常尤其是向量库和关系库的一致性。新版本开放给 1% 流量观察 24 小时反馈指标后再全量。这样每次变更留下记录哪次变更导致指标变化才能定位到具体原因。6. 生产环境中的常见问题与排查路径6.1 记忆串味不同用户的记忆互相污染这是持续学习系统最典型的错误。现象用户 A 的关键信息出现在用户 B 的回答中。可能原因向量检索时没有按用户 ID 过滤。长期记忆表查询漏写用户条件。多个用户共用同一个会话记录。偏好表主键设计不正确更新时覆盖了其他用户记录。检查顺序复现时先确认请求里解析出的 user_id 是否准确。查看向量检索代码确认是否传入了 where 过滤条件。查看 SQL 查询确认 WHERE user_id ? 是否出现。检查长期记忆表内容看是否已经被错误写入。解决方式每一层记忆访问都必须显式传入用户 ID并把用户 ID 作为查询和写入的强制条件。可以在 SQL 层和代码层双重校验。6.2 反馈数据质量差点踩多但无法定位问题现象系统每天都能收到大量负反馈但不知道应该改哪里。可能原因前端没有把 message_id 和 session_id 传给后端。反馈页面选项太大用户只能点踩无法说明原因。没有把反馈样本和当时的上下文关联起来。数据分析只看了平均指标没有细分用户和任务类型。处理建议前端反馈必须携带消息 ID保证能追溯到完整的请求上下文。给用户提供标签化纠错选项例如“答案太长”“事实错误”“没有引用来源”“没有解决我的问题”。数据平台按feedback_type 任务类型 用户类型做下钻找出集中问题。对集中负反馈的问题类型单独抽取 100 条样本做人工分析。单纯增加一个“点赞/点踩”按钮解决不了问题。反馈设计的目标是让每个负反馈都能对应到一个可操作的优化项。6.3 数据飞轮带来的隐私和合规风险现象团队想用用户对话数据做离线迭代但不确定哪些数据能用、能用多久。处理建议用户对话数据属于用户隐私数据必须先做脱敏或聚合再进入分析流程。在隐私政策中明确说明数据用途尤其是“用于改进模型和智能体”这一点。建立数据保留周期超过周期自动删除或匿名化。提供用户“关闭持续学习”的选项。关闭后不再写入长期记忆不参与离线数据集构建。风险不在数据飞轮本身而在没有边界地收集和保存数据。这里的处理原则是能不用原始数据就不用原始数据能脱敏就脱敏能给用户选择就给用户选择。6.4 常见问题排查清单下面这份排查清单可以直接复制到项目文档中遇到问题按顺序确认。问题现象检查方向确认点长期记忆写入失败存储层SQLite 写入是否报错向量库是否可用用户 ID 是否存在回答不含历史信息检索链路向量检索是否返回结果相似度阈值是否过高记忆是否真的写入用户偏好不生效提示词偏好是否成功拼入系统提示词拼接顺序是否正确反馈记录查不到事件链路前端是否传了 message_id接口是否报错写入是否在事务内离线评估指标波动大评估集评估样本是否太少是否有重复样本人工标注标准是否一致模型回答越来越长提示词或偏好是否有偏好把“详细回答”固化是否缺少长度约束排查的原则是先确认输入再确认存储再确认检索最后才怀疑模型本身。很多持续学习系统的问题不在模型而在数据链路。7. 最佳实践与扩展方向7.1 最小可行闭环先跑通再优化不要一开始就设计庞大的记忆系统和复杂的离线训练平台。先按最小闭环搭起来实现会话级上下文管理。实现一个简单长期记忆表用关键词或向量检索都可以。把用户反馈的点赞/点踩和 message_id 记录下来。每周人工看一次低分回答手动改进提示词。指标稳定后再逐步加入偏好提取、自动评估和策略迭代。最小闭环的价值在于让你先看到“记忆提升体验”这个效果否则团队很快就会迷失在复杂的工程细节里。7.2 从单用户到多租户的扩展演示项目只考虑了单表结构。生产环境如果是多租户产品需要把租户 ID 加入所有记忆表和向量库的过滤条件中。扩展时的关键设计数据库表增加tenant_id字段并在所有查询中作为必填条件。向量集合可以按租户隔离也可以在同一集合中用 metadata 过滤具体取决于数据规模和成本。偏好配置采用“租户默认值 用户覆盖”两层结构。租户可以规定统一风格用户可以在自己层面微调。数据导出和删除也必须按租户维度实现支持“某个租户退出后彻底清理数据”的合规需求。7.3 持续学习的边界什么时候不要自动化持续学习的目标是让系统越用越好但并不是所有环节都适合自动化。适合自动化的环节历史记忆检索、用户偏好抽取、反馈分类、定期评估。需要人工介入的环节知识库内容的审核、高风险问题的回答策略、模型发布前的回归确认、涉及用户隐私的数据处理决策。如果一条记忆重要但不确定不要自动写入长期记忆可以生成一条待确认消息由用户选择“记住”或“不记住”。这种设计虽然多了一次交互但能显著降低错误记忆带来的负面影响。持续学习是一个系统能力不是一个模型能力。判断一个智能体是否真正实现了持续学习可以看三条用户隔一天回来后系统还认不认识这个人系统接收负反馈后能不能定位到具体原因系统每次发版后能不能用数据证明自己变好了。把这三条做到比在概念上争论“模型有没有学习能力”更有价值。