这两年我做后端架构最明显的一个感受是CRUD不香了。不是说增删改查没用了而是当业务方张口就是“能不能让AI帮我做数据分析”“能不能根据用户行为自动生成方案”时你再拿一套标准的Controller-Service-DAO三段式去应付就会发现根本兜不住。传统的CRUD接口解决的是“数据怎么存取”而AI原生架构要回答的是“能力怎么组织、模型怎么参与、流程怎么流转”。2026年的后端开发核心战场已经从“写接口”转移到了“搭系统”——把大模型、知识库、工具调用、人工审核、第三方服务串成一个按需运转的编排体系。这篇文章我不聊概念包装就结合自己近两年在业务系统里做AI原生改造的实战经验讲讲为什么CRUD会内卷、AI原生架构到底怎么落地、服务编排在中间扮演什么角色以及从传统后端切过来最容易踩的坑。适合正在做后端开发、又对AI方向焦虑的朋友参考。1. 先聊聊CRUD为什么让人“卷”得没意义1.1 你以为你在做业务其实你在做数据搬运我刚入行那几年做的所谓“业务系统”拆开来看大概就是建表、写接口、前端对接、联调。用户表的增删改查订单表的增删改查审批流的增删改查。哪怕系统听起来很复杂——比如供应链、订单中心、风控后台——本质都在做同一件事把一个状态机的数据从一个存储搬到另一个展示。这带来的问题不是技术难度大而是价值密度太低。当你花了三天时间调通一个列表页的分页参数或者为了一个状态位的流转跟前端扯皮一整天你会发现你的产出和几年前没有任何区别。更尴尬的是这些活儿的复杂度不取决于你的能力而取决于业务方有多少张表要维护。做久了人会变成“接口生成器”。1.2 CRUD内卷的三种典型形态我在各个技术社群看人讨论“后端内卷”总结下来就是三种形态同一个功能反复造轮子每个新项目都在写用户登录、权限校验、导入导出、日志上报。这些能力早就该沉淀成平台或者SDK但很多团队还是每个服务各写一份因为“历史包袱太重”。在无意义的地方比性能明明一条SQL就搞定的事非要拆成三个微服务走消息队列美其名曰“异步化、解耦”最后定位一次问题要翻五个服务日志。在低价值的需求上拼加班业务方要一个报表你花一周写定时任务、清洗脚本、导出逻辑。结果报表上线三天业务方说“口径变了”。这些形态的共性是什么大家都在做“数据管理”的事但没人做“业务增量”的事。系统能跑但是不能自己思考、不能自己决策、不能根据上下文自动调整流程。这种系统做得再多也只是把人的手工操作搬到了网页上。1.3 为什么说AI原生是后端的出口后端开发者的优势从来不是“会写接口”而是理解业务全链路、掌握数据流转、懂得系统稳定性。这三样能力恰恰是AI落地最缺的。你把一个大模型API接进来很容易但要让它在真实的业务闭环里稳定运行就需要有人设计数据缓存策略、设计模型调用失败后的降级方案、设计用户反馈回流机制、设计AI输出与现有业务数据的校验逻辑。这些事情天然就是后端工程师该干的。所以2026年前后端开发的转向不是“不做CRUD”了而是在CRUD之上叠加一层“智能决策自动化编排”。CRUD变成底座底座之上是服务编排编排里嵌着模型调用和工具调用。这个转变才是告别内卷的真正出口。2. AI原生架构先别急着调API把骨架搭对2.1 常见误区把“外挂式AI”当成AI原生我见过很多团队搞AI改造第一步是让后端在原有接口里硬塞一个“智能助手”方法前端弹个对话框后端调一次大模型接口把返回结果原样渲染。这种做法的本质是“给传统系统加了一个牙签”——AI像一个独立的外部服务和业务逻辑没有任何数据层面的深度结合。外挂式AI有几个通病一是不了解上下文模型只能根据你传的那一小段Prompt做判断看不到用户历史、业务规则、实时数据二是输出不可控模型随口给出答案但答案涉及业务敏感数据时没人校验三是无法参与业务流程AI识别出这是一个投诉单但不能自动创建工单、不能自动触发退款审核、不能调用内部系统去查询订单状态。真正的AI原生架构至少要让AI成为业务系统的一等公民——它不再是“边缘的聊天窗口”而是流程节点本身和数据库、消息队列、第三方服务一样可以被编排、被监控、被降级。2.2 AI原生设计的三个关键原则我在做架构方案时会坚持三条原则算是给团队定的“铁律”模型输出必须过校验任何大模型返回的JSON都要经过结构化校验和业务规则校验。模型说“用户满足退款条件”不算数要去查订单状态、查售后策略两厢一致才算数。可被编排是硬要求所有AI能力意图识别、信息抽取、内容生成都要封装成可独立调用的服务并且能被工作流引擎触发。禁止把AI调用硬编码在业务代码里否则每加一个场景就要改代码发版。数据回流才有价值每次AI的输入、输出、用户反馈、人工修正结果都要落到可检索的存储里。这些数据既是评测集也是后续微调、提示词优化的基础。2.3 一张表看清AI原生系统的分层实践下来我习惯把一个AI原生后端系统拆成五个层面。很多团队之所以乱就是因为所有逻辑都搅在一起根本没有分层。层级职责典型组件接入层统一API出入口鉴权、限流、协议转换BFF、API Gateway编排层定义业务流程串联AI与工具调用管理状态Temporal、LangGraph、自研DSL模型服务层统一管理模型路由、Prompt、上下文、降级策略模型网关、Prompt模板引擎数据与知识层业务数据、向量检索、知识图谱、事实库PostgreSQL、Milvus、Redis可观测与反馈层链路追踪、日志、评测、人工反馈回流OpenTelemetry、Langfuse、ClickHouse这套分层的好处是每一层都能独立演进。你换模型厂商时只动模型服务层业务流程变了只动编排层增加知识来源只动数据层。系统不会因为一个环节的变化而推倒重来。2.4 别让模型直接碰核心数据这条我特别想强调。很多后端同学一听到“AI原生”就巴不得把数据库连接串口直接丢给模型让大模型自己写SQL查询。听起来很美做起来很危险。无论是让模型自己写SQL还是把全量业务数据塞进上下文都会引发三方面问题权限失控模型没有数据权限概念、上下文爆炸业务数据量远超模型窗口、事实错乱模型会一本正经地编造不存在的订单号。所以我在实践中的底线是模型永远不直连数据库。模型负责“理解意图、拆分任务”真正取数、写库、调用第三方全部通过工具函数的编排完成。模型输出的是“我想查用户最近三个月的订单并判断是否有退款记录”系统会通过一个查询工具去Agent那里拿到真实数据再和模型的判断做交叉核验。这个过程既给了AI“眼睛”又没把“手”伸进核心数据。3. 服务编排把碎片化AI能力织成业务闭环3.1 为什么2026年服务编排重新变热服务编排不是一个新词早期的ESB、微服务时代的Orchestration都提过。但2026年它重新回到舞台中央根本原因是AI能力天然碎片化必须靠编排组装成业务闭环。过去一个业务流程是“调用接口A→判断返回结果→调用接口B”节奏是固定的、状态机是明确的。现在多了一个“不确定节点”——大模型。同样一个输入模型今天可能给你意图A明天可能是意图B模型可能中间还要反问澄清还可能给出一个需要人工确认的结果。你不用编排引擎去管理这种带分支、有不确定性、可中断恢复的流程业务代码马上会变成一坨加满if-else、又叠加异步回调的意大利面。服务编排在这里的核心价值我总结成四点流程状态持久化流程跑到一半机器重启能恢复而不是从头开始、人工介入的标准化AI判断低置信度时挂起等人审核后继续走、分支条件可视化业务说改流程时不用你逐个翻译成代码、失败重试与降级控制模型超时了走规则兜底而不是直接报错给用户。3.2 编排引擎选型吃透两种流派市面上可选的编排方案大致分两类一类是“工作流派”代表是Temporal、Camunda一类是“Agent派”代表是LangGraph、Dify。两者经常被人搞混但定位差异很大。维度Temporal / CamundaLangGraph / Dify核心定位通用业务工作流与状态编排面向LLM的智能体任务编排状态持久化原生持久化支持长时间运行可持久化但通常围绕对话/任务上下文人工介入支持信号机制成熟支持但与业务系统集成成本略高适用场景订单处理、审批流、对账、工单流转多轮对话、Agent规划、RAG问答链后端友好度高天生面向工程师中等更偏AI应用层我们团队的实际做法是以Temporal为业务编排底座把大模型调用包装成标准Activity。这种组合最灵活——你可以在一个订单售后流程里先用LLM Activity做意图分类再根据分类结果走不同的普通Activity查库存、发退款、通知仓管整套流程享受Temporal的重试、超时、信号机制同时AI部分依然是可插拔的。如果你们的场景更像“多轮对话工具调用”的智能体而不是“有明确节点的业务流转”那LangGraph这类方案会更顺手。它擅长把“让模型自己决定下一步调用什么函数”的循环控制做得自然配合ReAct模式的工具调用可以快速搭出智能体。3.3 一套典型的“AI编排”流程长什么样我用一个例子直观说明售后工单自动分类与处理。传统做法是用户提交工单→后端写死if用户留言包含“退款”则走退款分支→否则转人工。这套规则在真实场景里非常脆弱用户写的可能是“钱还没到账怎么办”里面没有“退款”两个字但是你我都知道他是要退款。有了AI原生编排后同样的业务会变成这样用户提交工单进入Temporal工作流。第一个Activity调用大模型做意图识别和关键信息抽取这是退款诉求涉及的订单号是哪个用户情绪是否激烈。工作流根据模型输出走条件分支若识别为退款且命中自动退款策略则调用退款系统Activity自动执行若识别为退款但金额超过阈值进入“等待人工确认”状态工作流挂起若模型置信度低于阈值同样挂起转人工。人工在审核后台操作后通过Signal向Temporal工作流发送“通过/驳回”指令流程继续。整条链路的每个节点输入输出都记录到可观测系统。这个流程用传统硬编码也能写但你会面对一堆状态流转的噩梦Process挂了怎么办人工审核时机器重启了状态丢没丢模型调用重试会不会导致重复退款这些Temporal都替你解决了。3.4 编排粒度别把项目变成一个巨型状态机服务编排最怕的是矫枉过正。我一朋友接手一个项目接手时发现团队把“用户登录”都包装成了Temporal工作流注册、登录、改密码各自一个Workflow跑起来比同步秒开还慢。我的经验是编排要用于“值得被记录状态、可能中断、需要长时间运行”的流程。对于一次HTTP请求能完成的简单操作直接同步调用是最高效的。什么算复杂流程涉及多个系统、有回滚诉求、需要等待外部事件、且执行时间超过秒级。满足两三条以上才值得上编排。小接口硬嵌工作流只会让链路变长、问题排查变难、性能测试数据变得不好看。4. 落地实操怎么把一个传统CRUD项目改造成AI原生编排体4.1 三阶段改造路线图真正动手改造别想着一步到位。我推荐分三个阶段走每个阶段都有明确的交付物既能让团队逐步上手也能让业务方直观看到价值第一阶段单点AI嵌入。选一个高频、痛点明显的场景比如工单分诊、商品描述生成把模型调用封装成工具服务挂到现有系统旁边。这个阶段的目的是打通“模型调用结构化输出业务落库”的基本链路顺便积累第一批线上真实数据。第二阶段引入编排层。把第一阶段的功能迁移到Temporal或其他引擎里把AI调用、人工审核、第三方系统调用统一定义成Activity。此时系统开始具备“流程可恢复、人工可介入”的能力AI才真正成为流程的一部分。第三阶段构建AI原生生态。建立模型网关统一管理多个模型的路由和降级建设知识库服务把FAQ、商品信息、售后政策向量化完善反馈回流机制每次模型的成功和失败都被量化。走到这一步才算“AI原生”而不是“接了个AI”。4.2 核心代码示例TemporalLLM Activity我直接给一段可参考的Go语言代码展示在Temporal工作流里编排大模型调用的核心逻辑。// LLM意图识别Activity func LLMIntentActivity(ctx context.Context, req IntentRequest) (*IntentResult, error) { messages : []Message{ {Role: system, Content: systemPrompt}, {Role: user, Content: req.Msg}, } resp, err : model.Chat(ctx, model.ChatRequest{ Model: qwen-plus, Messages: messages, Tools: []ToolDef{refundToolDef, complaintToolDef}, }) if err ! nil { return nil, err } return parseIntent(resp) // 强制JSON结构化解析 } // 售后工单工作流 func AfterSaleWorkflow(ctx workflow.Context, order AfterSaleOrder) error { ctx workflow.WithActivityOptions(ctx, workflow.ActivityOptions{ StartToCloseTimeout: 2 * time.Minute, RetryPolicy: temporal.RetryPolicy{ MaximumAttempts: 3, InitialInterval: time.Second, BackoffCoefficient: 2.0, }, }) var intent IntentResult if err : workflow.ExecuteActivity(ctx, LLMIntentActivity, IntentRequest{Msg: order.UserMsg}).Get(ctx, intent); err ! nil { // AI识别失败时走兜底策略转人工而不是直接报错 var err error err workflow.ExecuteActivity(ctx, HumanReviewActivity, order.ID).Get(ctx, nil) return err } switch intent.Type { case refund: if intent.Score 0.75 { // 低置信度挂起等人工通过Signal恢复 selector : workflow.NewSelector(ctx) selector.AddReceive(ctx.Done(), func(_ workflow.ReceiveChannel, _ bool) {}) } else { var refundErr error err : workflow.ExecuteActivity(ctx, RefundActivity, RefundReq{ OrderID: order.ID, Amount: intent.Amount, }).Get(ctx, refundErr) return err } default: // 其他意图转正常流程 workflow.ExecuteActivity(ctx, NormalProcessActivity, order.ID).Get(ctx, nil) } return nil }这段代码有两个关键点值得注意。一是超时和重试一定要配置AI调用比普通接口更不稳定超时时间不要太紧但也不能无限等通常StartToCloseTimeout给2~5分钟比较合理。二是低置信度要转人工不要硬着头皮自动化宁可让人多看一眼也不要让一个错误模型判断把订单搞出问题——AI失误的代价远大于它省下的那点人力。4.3 服务化封装AI能力不要散落在各处在落地过程中我还建议搞一个独立的“AI服务层”模块而不是在业务服务里各写各的模型调用。这个模块统一提供能力比如intent_classify(text)意图识别返回类型和置信度。entity_extract(text, fields)关键信息抽取输入为用户留言输出订单号、商品、金额等字段。doc_generate(text)根据模板生成内容。vector_search(query, topK)在知识库中检索相关文档。每个能力内部做模型调用、超时控制、重试、输出校验、异常降级。业务侧只需要通过RPC或HTTP调用这个模块业务代码里不允许出现任何openai或model.Chat的直接引用。这么做的好处是哪天从这家模型切到那家模型或者同一能力不同场景要用不同模型都只需要在服务层内部路由处理不会引发全局改造。4.4 可观测性AI系统的调试比传统系统难一个量级传统后端排查问题看日志看调用链就够了。AI原生系统多了一个不确定性因素模型为什么这么回答你没法在断点里看到模型的推理过程只能依赖外部观测。所以我在每个AI项目里都会强制接入两层观测。第一层是链路追踪用OpenTelemetry把一次AI原生请求的全过程串起来——入口参数、各Activity耗时、模型输入输出、最终返回结果。第二层是专门的大模型观测比如Langfuse或者自建的一套Prompt摘要表记录每次模型调用的模型名、输入Token成本、输出Token成本、响应时长、结构化解析是否成功。这套数据不仅能定位问题还能积累成评测集每次调Prompt或换模型时跑一遍历史样本防止回归。5. 常见问题排查与避坑实录5.1 模型幻觉它说“已退款”系统没退这个问题我遇到太多次了。模型基于训练数据和Prompt上下文生成内容它本身没有任何“执行”能力也不会感知真实系统状态。当它说“您的退款已处理”时如果后端真的把这个输出直接展示给用户就出大事了。解决办法也很简单先执行后反馈。模型要展示任何业务结果后端必须先从业务系统查询真实状态再基于真实状态写回复。模型可以做语言组织但事实必须由系统供给。我们内部有个“事实校验Activity”的约定AI生成文案中涉及的所有业务编号、金额、状态都必须到库里验一遍才能下发。血的教训告诉我这一步不能省宁可在体验上慢一两秒也不能误导用户。5.2 编排过度设计流程没跑起来状态先乱成了一锅粥前文提过登录都上工作流的极端案例。更常见的是团队刚引入Temporal时不熟悉信号和超时模型把业务状态重复存在工作流里和业务库里两边不同步导致工作流恢复的时候读到脏数据。我的建议是明确职责边界避免双写状态。工作流负责“流程的进展”业务库负责“业务的真实状态”。工作流恢复时直接查业务库最新状态决定下一步而不是工作流内部自己维护一套业务状态副本。AB实验、试错、逐步推广都不要一上来全量流量跑编排先拿10%试运行看看稳定性再扩量。5.3 成本失控天天调大模型的账单吓人大模型调用是按Token计费的很多后端在用的时候还停留在“本地查库免费”的思维里动不动就把全量参数塞进Prompt一次分析请求烧掉几万Token。控制成本的方法无非几条一是加缓存相同的用户输入和上下文短期内直接命中缓存不要重复调模型二是用路由策略简单问题走小模型或者规则复杂问题才走大模型三是控制上下文长度做知识库检索时按相关性截断只送Top-K片段而不是整篇文档四是窗口打包用户在一个短会话内的请求合并成一条Prompt减少重复系统提示词。这几板斧下来账单至少能砍掉60%。5.4 组织协作后端、算法和产品最容易在编排层打架我们团队早期做过一件蠢事产品想调整流程分支但流程定义散落在代码里只能找后端改算法想优化Prompt但没有独立的提示词版本管理只能在后端代码里加字符串。最后大家互相甩锅效率极低。更合理的方式是把编排定义可视化、配置化。Temporal虽然强但它的工作流定义毕竟还是代码高频调整的分支策略和Prompt模板尽量抽到配置中心或规则引擎里让产品和运营也能在平台界面上调整阈值、开关、文案模板。后端把“复杂状态控制”掌握好把“业务可以灵活配置的部分”交出去这样团队边界清晰流程迭代也不再依赖一堆if-else改代码。这一点上踩过几次坑之后我现在的习惯是每一次AI原生改造都要先问团队一个问题——“这个流程里哪些决策是业务希望随时调整的”如果是那么这部分逻辑就不要硬编码进Workflow要把它变成可配置的参数或者规则片段。让技术复杂度留在能掌控状态的那一层把业务灵活度放在能即时响应那一层。我自己这几年最大的收获就是理解了后端开发者的价值不在于把AI接口调通而在于把AI稳稳地编织进业务的每一个流程节点里哪怕模型“胡思乱想”了系统的骨架也依然稳定。如果你正打算从传统CRUD项目切入AI原生改造我个人的建议是先别急着上一套宏大架构找一个下周就能上线的单点场景跑通闭环再谈编排、再谈平台化。方向对了剩下的就是时间问题。
