写点什么

AI 架构中的 “油水难融” 时刻

作者:Shweta Vohra
  • 2026-03-18
    北京
  • 本文字数:4322 字

    阅读完需:约 14 分钟

软件与 AI 架构

你是否试过把油和水混合在一起?

你可以用力摇晃罐子,让它们看起来融为一体。有那么一瞬间,它们确实混合在了一起,可随后,又会重新分开。

这种化学现象恰如其分地描述了当今软件架构所处的境地。

数十年来,我们的系统从根本上都是确定性的:给定相同的输入,系统会产生相同的输出。即便在向云原生架构转型的过程中这一前提也始终未变。微服务、容器、分布式系统与弹性基础设施提升了复杂度,却没有改变程序执行的本质。新旧架构之所以能够共存,正是因为它们都遵循着确定性规则。

AI 改变了这一基础。

我们如今正在将概率性、非确定性的系统集成到确定性的环境中。这类系统会生成响应、推断意图、动态地选择工具,并依据上下文信号自适应调整。即便输入相似,输出也可能不同,底层的执行路径可能并未在代码中明确定义。

这种矛盾并非源于模型性能,而是源于架构层面的核心假设差异。

本文的核心论点如下:

AI 架构无关工具,而是关于非确定性场景下的意图理解。

在我的新书“Dear Software and AI Architect”中,我深入探讨了这一转变。本文将介绍书中的一个核心观点:将确定性系统与概率性智能融合所带来的架构影响,并带你理解“AI 架构师新的 V 型影响画布(V-Impact Canvas)”。

传统护栏的不足之处

确定性系统中的护栏是明确且静态的。

例如:输入验证强制规范结构,访问控制管控权限,限流机制约束使用频率,API 契约定义边界,工作流引擎固化业务规则。这类控制机制都基于可预测的执行路径与预定义的分支逻辑。

AI 赋能的系统,尤其是那些采用了智能体与工具编排的系统,其运行逻辑截然不同。单个用户请求可能会触发跨多个知识源的检索,模型会整合结构化与非结构化输入中的上下文信息,智能体可从多个工具中自主选择其一,工具的输出会被评估,并用于驱动后续的操作。系统的演进依靠的是动态组合,而非线性推进。

即便每个组件都单独受到约束,组件之间的组合行为仍可能无法被完全预见。智能体可能以工程师并未明确设计的顺序链式调用工具,为某一任务检索出来的上下文信息可能会以意想不到的方式影响后续决策。在组件层面应用的策略约束,往往无法捕捉系统层面出现的风险。

这并不属于传统意义上的故障。系统行为虽处于概率边界内,却可能超出架构的预期范围。

这就是油和水无法真正相融的时刻。

结构层面正在发生哪些变化

当下关于人工智能的讨论似乎暗示着一切都在发生改变,但这并不准确。精准的表述应该是:部分结构性维度正在快速演进,而另一些则依旧稳固。

一个重大变化是决策面的扩展。在确定性系统中,决策树直接编码在逻辑里,工程师可以通过代码路径追踪分支,并推导执行状态。而在 AI 系统中,决策边界分布在模型参数、提示词结构、检索范围与策略约束之间。系统行为由统计推断驱动,而非显式的条件语句,这使得提前枚举所有可能的执行状态变得更加困难。

因此,架构师必须针对新类型的风险做出架构决策。需要防范提示词注入攻击,避免模型指令被覆盖;需要保障上下文完整性,防止跨检索会话污染;需要约束工具滥用,避免产生意外副作用;需要定义故障回退策略,应对概率输出超出可接受范围;纳入评估闭环,确保生成的响应符合架构意图。

可观测性的本质也发生了变化。传统的可观测性关注延迟、错误率、吞吐量和资源利用率,这些指标依然是必要的,但已远远不够。AI 原生系统还需要行为可观测性。工程师与架构师必须能够追踪提示词谱系、识别上下文来源、分析输出差异、检测漂移并校准置信度。系统不仅要在可用性上可观测,更要在决策质量上可观测。

治理已从一项以设计阶段为主的活动转变为持续的运行时学科。

策略必须适应不断演化的模型行为。输出分类层需要在内容对外展示前完成评估,当风险阈值被突破时,必须触发升级机制。模型版本管理需支持安全回滚,且不影响依赖模型的系统。提示词更新则要应对不断出现的边界情况。治理从静态变成了自适应。

依然成立的核心原则

尽管结构复杂性增加,基础原则依然稳固不变。

系统思维变得愈发重要,而不是无足轻重。数据管道、模型推理层、智能体编排框架与遗留集成点之间的依赖关系会形成反馈循环,放大微小的设计缺陷。只孤立看待组件的架构师将会陷入困境,而能理解系统级交互的架构师则能保持高效。

技术沟通具备了战略意义。概率性系统本身带有不确定性,利益相关者必须理解不确定性预算、可接受风险范围与行为方差。架构师必须把模型行为转化为业务影响与合规考量。在我的书中,我将这种能力称为“架构转码”——一项将技术模糊性转化为组织清晰认知的严谨实践。

学习纪律同样至关重要。工具在快速迭代,模型能力持续提升,框架不断更名与扩展。然而,模式识别、情境推理、伦理评估与权衡分析等基础能力仍具备长期价值。以原则为根基的架构师会比只追逐工具的人更能高效适应变化。

架构师的 V 型影响画布

要在非确定性环境中运行,架构意图必须清晰且结构化。AI 架构师 V 型影响画布提供了一个框架,让智能系统与目标和责任对齐。它由三个相互依赖的层次组成:架构意图、设计治理以及影响与价值。

架构意图层定义了不可妥协的原则、可接受的行为偏差与伦理约束,阐明了系统存在的意义,以及绝对不能逾越的边界。在 AI 系统中,意图必须转化为提示词架构、智能体目标框架、策略定义与评估标准。智能体围绕既定目标进行优化,若意图模糊不清,优化便可能产生不良后果。意图是整个系统的稳定核心。

设计治理层负责权衡智能体的自主性。赋予智能体的自主性越高,架构意图就必须定义得越精确。智能体系统通常需要更广泛的上下文访问权限、跨系统可见性和持久记忆能力。这些特性可以提升性能,但也会增加隐私泄露风险与合规复杂度。架构师必须设计上下文边界、记忆分段策略、数据最小化机制、运行时输出过滤器和升级路径。治理由此成为一项架构能力,而非流程化的检查清单。

影响与价值层确保智能行为能够产生可衡量的结果。AI 实验可以做出令人惊艳的演示,但可持续的架构需要具备经济合理性。架构师必须评估决策质量的可量化提升、运营稳定性影响、单次推理成本与业务收益的对比,以及长期信任带来的影响。AI 经济学是动态变化的,推理成本、检索基础设施、模型生命周期管理与合规监管都会改变财务状况。影响必须能够被量化,而非仅凭假设。

让我们通过一个真实的系统设计转型案例来展开说明。

Token 与上下文经济学

在传统系统中,当高级编程语言出现时,核心经济杠杆是硬件——服务器、基础设施采购与供应链决定了架构决策。后来,云计算将这部分成本转为运营支出,由云厂商承担基础设施与弹性扩展的工作。而在 AI 时代,一个全新的架构杠杆已经出现,并直接影响影响与价值层:Token 与上下文工程。这些概念看似简单,却已是当前大语言模型、小语言模型及其他前沿模型运行机制的核心。

举例来说,像 GPT‑4 这类模型的上下文窗口是有限的,即单次可处理的文本量存在上限。新版 GPT‑4 Turbo 支持约 128000 个 token 的上下文。一个实用的近似计算公式:1 个 token ≈ 4 个字符 ≈ 3/4 个单词,这意味着 128000 个 token 大约对应 90000 至 100000 个单词的输入与输出总量。这个容量在整个交互过程中是共享的:系统提示词、用户问题、检索文档、工具返回结果和模型回复,都必须在这一限制内完成。

我们来看一个简单的架构示例。假设一个 RAG 系统向模型发送如下内容:

  • 系统指令:约 1000 个 token

  • 聊天历史:约 2000 个 token

  • 检索到的文档:6 个块 × 1500 个 token = 9000 个 token

  • 用户问题:约 200 个 token

这在模型开始生成答案之前就已经消耗了约 12200 个 token 的上下文。如果响应本身还需要 1000 个 token,那么单次查询的总上下文消耗就达到 13200 个 token。试想扩展到每小时数千次请求的场景,token 用量会直接转化为成本、延迟和模型表现。如果架构师用无关的检索片段、结构混乱的提示词或不合理的上下文配置超载上下文,关键信息就会被稀释,即便模型在技术上持有“正确数据”,也可能给出不准确的响应。

这意味着 AI 架构引入了一门全新的优化学科。正如云架构师需要学会管理计算利用率与存储效率,AI 架构师现在必须设计能够精细调控上下文的系统:检索更少但更相关的文档,总结历史交互,并构建提示词,在有限的 Token 预算内最大化有效信息。试想一下,如果这一切都要为智能体量身设计,那么复杂度又将提升一个层级。

价值总结

架构原则保持不变,但新的抽象层带来了新的实现方式、影响路径与价值杠杆。因此,Token 与上下文工程并非次要的实现细节,它们正逐步成为架构师影响 AI 驱动系统可靠性、成本效益与业务成果的核心机制。

架构师 V 型影响画布将意图、治理与可衡量价值统一为一套连贯的体系。完整的框架与应用案例将在书中展开深入探讨,本文仅为你介绍其概念基础。

过度迷恋工具的风险

行业的发展日新月异,新模型、编排框架和评估工具包不断涌现。业界往往会迫于压力紧跟最新版本,以维持自身竞争力。

然而,采用缺乏架构成熟度的工具只会增加系统脆弱性。频繁切换模型可能导致行为不一致,快速集成框架可能产生治理缺口,缺乏清晰意图的功能扩张则会加剧技术债务。

工具可以加速能力,但无法带来稳定性。稳定性源于清晰的意图与严谨的治理。

遗留集成问题

大多数企业仍在传统遗留环境中运行。确定性工作流、静态合规模型与流程化审批链并非为自适应智能系统而设计。

若将 AI 能力直接叠加在这些系统上,却不重新评估底层设计假设,就会产生冲突。AI 给出的建议可能超出遗留系统的执行范围,智能体可能无法获取完整的历史上下文,合规控制也可能与自适应行为产生矛盾。

架构师与技术管理者必须做出抉择:是通过升级架构意图适配智能系统,还是通过限制 AI 能力适配原有边界。这一决策关乎战略,而非单纯技术。这也让我们回到一个关键问题:我们是否在试图将油和水强行混合?如果答案是肯定的,那就应当及时止步。

从洞察到影响

将确定性系统与概率性智能相结合已不只是一个可选项,而是正在发生的现实。

若缺乏稳定的机制来隔离矛盾、简化运营,这种内在冲突就必然会爆发。

清晰的意图便是这种机制。明确的原则、笃定的目标、自适应的治理与可量化的影响能将非确定性系统锚定在可问责的边界之内。

AI 并未削弱架构责任,反而使其变得更加重要。

架构师正面对一个全新的设计现实:确定性软件系统必须与非确定性智能共存。理解如何将这一变革锚定在清晰意图、有效治理与架构根基之上,将定义下一代 AI 架构师的核心能力。

正如我在书中所写:

架构师须以清晰理念为指引,以场景语境构建架构,在 AI 驱动的工程领域中稳步前行。

工具会不断演进,模型会持续优化。

意图正是将整个系统凝聚在一起的核心力量。你觉得呢?

【声明:本文由 InfoQ 翻译,未经许可禁止转载。】

查看英文原文:https://www.infoq.com/articles/oil-water-moment-ai-architecture/