彻底搞懂 AI-Native Service 架构
prompt + LLM API + parse JSON 的三板斧。这不叫原生，这叫硬塞。真正的 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 服务没「黄金集合」根本不敢发版。我们现在的流程：每条用户反馈、每次 Bad Case 都自动入库生成 Test Case，CI 跑 pytest --eval 时并行调用 Judge LLM（我们用的是 Haiku 3.5，成本可控）打分，回归率低于阈值直接阻断合并。这套跑通后，Prompt 迭代从「凭感觉改」变成了「有数据改」，线上投诉率两周砍半。
数据飞轮不是 PPT 概念。关键在于显式采集隐式信号。用户没点「有用」，但把回答复制走了——强信号；用户追问「那个文档在哪」——检索失败信号。把这些埋点打通，每天跑一次离线 DPO/RLHF 微调 LoRA，再灰度上线，这才叫 Native。
别问我用什么框架，LangGraph、AutoGen 都试过，最后还是自己封了层薄薄的 AgentRuntime，核心就两百行：状态机 + 检查点 + 人工介入 Hook。框架是给 Demo 用的，生产环境还是得自己把状态机画清楚。
下一步打算把 Eval 集合按业务场景切分，针对高频 Intent 训练专用 Small Model 做 Routing，把大模型留给真正需要推理的节点，成本再砍一刀。
