真正的 AI-Native Service 要把模型放进完整系统里

用 Redis 拼 Prompt 简直是自寻死路，上下文一过 8k 直接崩掉，得用状态机才行！不少团队打着「AI Native」的旗号，打开代码却还是 prompt + LLM API + parse JSON。这种做法不是原生，只是在服务里硬塞 AI。真正的 AI-Native Service，核心区别是：模型应当作为有状态的推理引擎运行，而不是无状态的函数调用。落到工程层面，有三个硬指标：具备长短期记忆体系、工具调用基于 ReAct 而非硬编码 Flow、数据飞轮可以自动运转。记忆是基础。别再只用 Redis 保存几轮对话历史，就把它当作完整记忆层。生产级记忆体系至少需要三层：工作记忆对应上下文窗口，情景记忆由向量检索与时间衰减组成，语义记忆则依赖知识图谱或实体抽象。LangMem 的思路基本正确，关键有两点：写入路径必须异步，读取路径要按任务类型检索，不能把全部记忆一次性塞给模型。重构客服系统时，我们把用户画像、历史工单、产品文档分别放进三个命名空间，并在检索中加入 recency_bias 和 importance_score 两个权重。相比单纯的 Top-K，召回率提高了 23%。工具调用也不能继续依赖 if intent == 'refund': call_refund_api() 这类确定性代码。AI-Native 的一个关键定义，就是规划与执行解耦。模型只生成 ToolCall 序列，执行层统一经过沙箱或网关，集中处理鉴权、限流、幂等和回滚。我们内部做过一个轻量级 ToolRuntime，能够把 OpenAPI Spec 自动转换成 Function Calling Schema。模型因幻觉生成错误参数时，运行时会在执行前拦截，并返回 ValidationError 供模型自我修正。这比在 Prompt 里写一句「请仔细核对参数」有效得多。另一个容易被忽略的环节，是 Eval 驱动开发。传统服务有单测和集成测，AI-Native Service 如果没有「黄金集合」，根本不敢发布。我们目前的做法是：每条用户反馈、每个 Bad Case 都会自动入库并生成 Test Case。CI 执行 pytest --eval 时，会并行调用 Judge LLM 进行打分；使用的模型是 Haiku 3.5，成本处于可控范围。一旦回归率低于阈值，合并就会直接被阻断。这套流程跑通以后，Prompt 迭代不再是「凭感觉改」，而是「有数据改」，线上投诉率在两周内

没套在线评估指标简直在盲操，调参调到凌晨三点结果效果反而更烂了。建议每条用户反馈、每个 Bad Case 都会自动入库并生成 Test Case，让 Prompt 迭代从「凭感觉改」变成「有数据改」。

直接在 Prompt 里写工具定义简直是灾难，换成注册表校验后报错率掉了 80%，这也太爽了。我们团队也踩过同样的坑：起初所有工具逻辑都写死在 Prompt 里，模型一旦胡言乱语、乱七八糟地调用接口，查起来要命。后来参考了一位前辈的实践——他在 ToolRuntime 里加了个自动拦截机制，把 OpenAPI Spec 转成 Function Calling Schema，执行前统一做参数校验，模型 hallucinate 的错误参数直接被拦下来、返回 ValidationError，让模型自己纠错。我们马上也跟着搞了个类似的注册表校验逻辑，果然报错率瞬间下降了不少。

再说记忆这玩意儿，别再拿 Redis 当全套记忆系统了。我们把用户画像、历史工单和产品文档分别丢进三个命名空间，检索时加了 recency_bias 和 importance_score 权重，召回率居然提升了 23%。还有 Eval 驱动开发那部分，每次上线前跑 pytest --eval，Judge LLM 打分挂了就别想合并——线上投诉率一个星期就砍了一半。

至于数据飞轮，用户没点「有用」但是复制了回答，那可是强信号；用户追问「那个文档在哪」就说明检索挂了。这些埋点打通后，每天跑一次 DPO/RLHF 微调 LoRA，灰度上线才敢叫 Native。最后框架那事儿，LangGraph、AutoGen 都试过，还是自己封装一层 AgentRuntime，状态机 + 检查点 + 人工介入 Hook，两百行代码顶得上。框架适合 Demo，生产环境还是得自己设计状态机清楚。