刚接触大模型时，我和很多工程师一样，第一反应是：能力这么强，理所当然应该放到系统最核心的位置。无论是用户输入处理、规则判断，还是关键业务逻辑生成，都希望模型来兜底。但随着模型能力不断提升、调用频率越来越高，我的态度却发生了明显转变——模型越强，我反而越谨慎，甚至刻意避免让它进入核心链路。这并不是对模型能力的否定，而是一次又一次工程实践后的理性选择。
-
核心链路真正需要的是什么
核心链路的价值，从来不在“聪明”，而在确定性、可预期性和可控性。请求什么时候来、什么时候返回、失败时会发生什么，工程上都必须有清晰答案。而大模型在这些维度上天生就不稳定。即便模型本身没有故障，在高并发场景下也会受到限流、排队和调度的影响，一次延迟抖动，就可能放大成整体吞吐的下降。 -
模型能力越强，不确定性也越大
模型输出并不是严格意义上的“计算结果”。即使输入完全一致，输出也可能因为上下文、版本调整或参数变化而不同。在推荐、文案、摘要等辅助场景中，这种不确定性是可以接受的，甚至是优势；但在核心业务流程里，它往往意味着不可控风险。你很难向系统解释“为什么这一次和上一次不一样”。 -
真正棘手的是失败模式
数据库不可用、缓存失效，工程师都知道该怎么处理：降级、兜底、快速失败。但模型调用失败时，很难找到一个等价且稳定的替代方案。更现实的问题是，一旦模型调用被放在同步链路中，它的超时就会直接占用线程资源，把问题从局部放大到全局。 -
从“决策中心”到“边缘能力”的转变
正是经历过几次类似的事故后，我开始有意识地把模型从系统的中枢位置挪开。现在的原则非常明确：
- 核心链路只承担确定性的逻辑
- 模型只参与可以失败、可以被忽略的部分
- 模型结果用于增强体验，而不是决定成败
- 模型可以慢一点，但不能阻塞主流程；模型可以出错，但系统必须继续运行。
- 成熟系统的取舍逻辑
真正成熟的系统设计，往往不是“把最强的组件放在最重要的位置”，而是清楚地知道哪些地方必须稳，哪些地方可以承担风险。模型能力的提升，并没有改变工程世界的基本规律：任何不可控的外部依赖，都不应该成为系统运转的地基。
写在最后
回头看，我反而庆幸当初没有把大模型深度耦合进核心链路。否则，后续的扩容、重构和压测都会变得异常痛苦。模型依然重要，但它更适合作为系统的增强能力存在，而不是支撑整个系统运转的底座。在后续做架构验证和压测时，我通常会使用支持多模型切换的 AI model APIs 供应商（例如 GPT Proto）来模拟不同模型在延迟和失败场景下的表现，提前确认它们不会对核心链路造成致命影响。