AI时代最反常识的真相:模型越聪明,工程越难

上周有个同事跟我说，他花了两小时就搭出了一个AI问答系统。输入框、后端接口、一次LLM调用，再套个UI，确实漂亮。他兴冲冲地给我看Demo，说"这不就上线了吗"。

我当时没说话，因为我知道，Demo好看是因为它只面对一个问题：模型能不能回答。而上生产面对的是：数据在哪、权限怎么给、上下文怎么构造、工具有哪些、API怎么划分、状态怎么保存、错了怎么回滚、挂了怎么降级、出了事谁负责。前者是模型能力的问题，后者是系统工程的问题。而真正拦住大多数AI项目从Demo走到落地的，从来不是模型能力。

会调大模型的人很多了。2026年，随便一个实习生都能写出prompt、调通API、让模型给出合理的回答。但能让一个概率模型在一个真实组织里安全做事的人，少得可怜。因为模型负责的是生成概率，数据库负责保存事实，网络负责定义工具的权限和边界。这三者之间有个根本矛盾：概率系统和确定性系统不是同一个物种，硬把它们嫁接在一起，光接口对了不算完，你得保证嫁接的地方不会渗水、不会短路、不会在凌晨三点突然崩掉。

架构要求：不是画个框图就完了

很多人对"架构"的理解是画一张分层框图——前端、后端、模型层、数据库，然后觉得万事大吉。但AI系统的架构不是画图，是写规矩。规矩写得不够细，系统就会在最意想不到的地方出问题。

认证鉴权怎么做。普通系统认的是用户身份，AI系统还要认模型行为。一个Agent要读客户数据，谁授权的？读了多少？读到之后模型会不会在下一轮对话里泄露给另一个用户？这不是加个RBAC就完了。你得在每一层工具调用上加权限检查，而且检查的逻辑不能写在prompt里——prompt是概率，权限必须是确定性代码。具体怎么做？模型拿到用户请求后，意图解析走一层权限网关，工具调用走一层权限网关，返回结果再走一层脱敏网关。三层拦截，任何一层不过都不往下走。这不是画框图能解决的，这是写代码、写规则、写测试。

状态管理怎么做。有人把上下文、历史操作、用户偏好全塞进prompt让模型自己记。prompt是动态的、不可审计的、不可回滚的。出了事你连"当时模型看到了什么"都查不出来。正确做法是状态持久化——每一步操作的输入、输出、决策依据、中间结果全部写进数据库，实时写，不是事后补。Redis存实时状态，MySQL存历史记录，对象存执行证据。每次状态变更1秒内必须落盘。这样你才能做到：崩溃重启后从数据库恢复状态，而不是让模型"回忆"之前干了什么（它会回忆错的）。

幂等性怎么做。同一个问题问两次，模型可能给两个不同回答。如果这个回答触发了写数据库的操作，两次请求就是两条记录。不做幂等设计，AI系统在重试、超时、并发场景下就是一团乱麻。具体做法：给每次Agent操作分配唯一操作ID，同一ID的重复请求只执行一次；写入操作必须走事务边界，要么全部成功要么全部回滚；模型输出作为数据写入前必须过校验层，格式不对直接拦截，不走后续业务逻辑。

Harness：概率引擎必须有一个确定性控制面

上面说的这些规矩，不能靠人每次手动检查，得有一个专门的系统来执行。这个系统叫Harness——模型的外挂控制面。

Harness不是模型本身的一部分，它是一个独立的中间层，夹在模型和业务系统之间。模型负责想，Harness负责管。具体管什么？

第一，执行边界。模型想做什么操作，Harness先检查有没有权限、有没有超出预设范围、有没有触碰到敏感数据边界。通过了才放行，不通过直接拦截，不给模型"先试再说"的机会。

第二，状态调度。模型每一步做完之后，Harness接管状态——不是让模型自己维护上下文，而是由Harness把中间结果持久化、把下一步要做什么写进任务队列、把依赖关系串起来。模型只管单步推理，Harness管全流程编排。

第三，故障恢复。模型调用超时了、幻觉了、格式输出错了，Harness检测到之后不是报个错就完了——它有预设的恢复策略：重试（可配置次数和间隔）、降级（切到备用模型或简化流程）、人工介入（高风险操作挂起等审批）。恢复策略不是事后临时想的，是上线前就写进配置的。

第四，可观测性。每一次模型调用、工具调用、状态变更，Harness都打一条trace。TraceID从请求入口一路透传到最底层，任何一步出了问题，你查trace链路就知道是哪一步、什么输入、什么输出、什么时间点出的事。没有这个，凌晨三点半出了故障你只能靠猜。

第五，审计回滚。每一步操作都留证据——输入参数、模型输出、工具返回值、操作时间戳，全部存进对象存储，哈希校验防篡改。任务失败了，Harness根据证据链定位失败步骤，按预设回滚策略恢复到执行前的状态。步骤级回滚只撤失败的那一步，任务级回滚撤整条链，增量回滚只撤变更的部分。回滚全程也留痕。

说个真实数据：72%上线了Agent的企业都遇到过生产级故障，其中60%来自Agent对外交互的管控缺失，而非模型推理准确率不足。这60%的问题，就是Harness该管但没管住的。

稳定性要求：不是"尽量不出错"，是"出了错必须能兜住"

稳定性这个词容易被误解成"尽量不出错"。但AI系统的稳定性不是追求零故障——概率引擎天然会出错——而是追求出了错之后系统还能兜住。

具体怎么兜？

限流降级。普通接口限流靠QPS，AI接口限流靠Token。一个大模型调用消耗几百到几万个Token，一个Agent任务可能串联5次调用。高峰期50个并发请求，Token预算瞬间烧完。你不做限流，模型就排队；你不做降级，用户就干等；你不做缓存，同样的问法每次都重新算一遍。具体动作：Sentinel做流量控制，Resilience4j做熔断降级（错误率超40%自动断开），主模型不可用时按预设梯队切到备用模型（claude-sonnet-4-6→gpt-4o-mini→deepseek-chat），响应超5秒直接降级返回缓存结果或兜底文案。

幻觉护栏。模型说错了没有校验，说错了直接入库，说错了直接触发业务操作——这是最危险的。具体动作：模型输出→确定性校验→业务执行，三层防线。校验层做什么？格式校验（输出是不是预期的JSON结构）、事实校验（关键数据项是否在数据库里有对应记录）、逻辑校验（操作是否符合业务规则，比如"退款不能超过订单金额"）。校验不过的输出直接丢弃，不进入业务系统。

防假完成。模型说"我做完啦"，你怎么知道它真的做完了？具体动作：四层校验。第一层证据校验——每个步骤的证据链完整性检查，缺失或篡改的判定为假完成。第二层结果复核——独立组件（和执行组件解耦）二次检查执行结果。第三层异常检测——执行时间过长、输出格式异常、接口报错，即使模型返回"成功"也标记可疑。第四层审计校验——任务完成后审计层自动检查步骤条件和目标条件的一致性。

级联故障隔离。一个Agent出错，它的错误输出变成了下一个Agent的输入，下一个接着出错，像多米诺骨牌一样往下倒。具体动作：每个Agent执行在独立沙箱里，工具调用走权限隔离，Agent之间的数据传递必须过校验层。一个Agent崩了，只影响它自己负责的那一步，不会扩散到整条任务链。

【想一下：如果你的AI系统凌晨三点半崩了，你能靠trace链路一分钟内定位到是哪一步出了问题吗？能靠预设降级策略一分钟内切到备用方案吗？能靠证据链和回滚策略五分钟内恢复到上一个稳定状态吗？如果三条答案都是"不能"，你搭的还是Demo。】

程序员的价值在哪

说了这么多具体动作，容易让人觉得"这不就是传统后端工程吗"。对，大部分确实是。但区别在于：传统后端处理的请求是确定性的——同样的输入给同样的输出，错误是二值的（成功或失败）。AI系统处理的请求是不确定性的——同样的输入可能给不同的输出，错误是连续的（置信度从0到1），而且错误会级联传播。

程序员真正的价值，是让一个概率模型以可控、可观测、可回滚的方式去读写确定性系统。这个"让"字背后是一整套工程体系：Harness做控制面，权限网关做边界，状态持久化做记忆，trace链路做诊断，证据链做审计，降级策略做兜底，回滚机制做善后。这些东西没有一个是AI特有的，但每一个都因为AI的概率特性而变得更复杂。

模型是概率引擎，它负责生成。但生成之后的每一步——写入数据库、调用接口、变更状态、触发通知——都需要确定性系统来执行，需要工程师来设计边界、定义规则、搭建护栏。能调API的人搭出来的是Demo，能把概率系统和确定性系统缝合在一起的人搭出来的是生产。这两者之间的差距，不是模型差距，是工程差距。

AI时代的最后一道高墙，从来不是模型能不能想出答案，而是答案想出来之后，怎么让它安全地做事、稳定地做事、出了错还能兜住地做事。

最后，和你分享几点最深的感触：

Demo解决的是"能不能做到"，生产解决的是"做到了之后能不能一直做到"。前者的门槛在模型，后者的门槛在架构和稳定性——不是画框图的架构，是写规矩、写控制面、写兜底策略的架构。

AI时代程序员的角色正在从代码执行者变成目标定义者和验收者。Harness工程体系的本质，就是把"模型想干什么"和"系统允许模型干什么"之间的距离，用确定性代码填满。

如果这篇文章让你想起某个从Demo到上线被工程细节坑惨的项目，欢迎说说你最踩的坑是什么。后续我会持续分享AI系统工程化落地的实战经验，感谢每一个愿意花时间看到这里的你。