一个系统为何是 AI 原生？

在应用中添加一次模型调用，并不能说明它已经变成了什么样的系统。一个“总结”按钮、一个文档处理工作流，以及一个会编辑代码库的智能体，可能都基于同一个基础模型；但在每个系统中，这个模型承担的角色却大相径庭。

只有当 AI 原生 这个说法能帮助工程师看清这些差异时，它才是有用的。它应该指向系统设计层面的一种变化，而不是给任何“把文本发给模型”的产品贴上流行标签。

本章提出一个 Fieldbook（工程手册）定义，并给出一组诊断问题。该定义是编辑层面的综合提炼，并非行业标准。章节末尾的来源用于支撑从中推导该定义的架构观察；它们中的任何一个都单独不能按本章的方式定义 AI 原生。

论点

Fieldbook 定义： 一个 AI 原生系统将模型介导（model-mediated）的解释、生成或决策纳入其核心运行行为与系统目的。由于这种行为依赖上下文且具有概率性，周边系统会被刻意设计来提供上下文、约束权限、观测结果、评估质量、从故障中恢复，并在风险或歧义需要时引入人工参与。

这个定义的两部分同等重要：

模型是系统目的或运行契约（operating contract）的必要组成。 它不仅仅是装饰一个在其他方面没有变化的产品。
系统围绕模型行为的特性进行工程化。 它并不假装一个概率性组件能像确定性函数那样工作。

AI 原生并不意味着完全自治（autonomous）。当模型行为是系统解释开放式输入或产生结果的关键时，一个预定义工作流也可能是 AI 原生的。智能体（Agent）是更窄的一种设计：模型还会主导执行路径中的某些部分、工具选择或停止决策。Anthropic 在更广的“智能体系统（agentic systems）”范畴下，也区分了预定义代码路径的工作流，以及由模型动态主导流程与工具使用的智能体（Anthropic, 2024）。

问题

同一个模型在软件系统中至少可以处在三种不同位置：

外围能力（peripheral capability）： 模型在一个边界明确的功能内给出建议或完成转换，而系统其余部分保持不变。
固定工作流内的核心能力（core capability inside a fixed workflow）： 模型负责那些规则无法可行指定的解释或生成；但代码仍决定步骤顺序。
运行期决策者（runtime decision-maker）： 模型从反馈中选择动作、工具或后续步骤，以追求目标。

把这三类系统都称为“AI 原生”会抹掉重要的工程差异。只把第三类称为 AI 原生，则会把 AI 原生系统与智能体系统混为一谈，并排除那些价值依赖模型、但控制流被有意约束的系统。

行业对智能体的定义展示了为何这种区分至关重要。OpenAI 的智能体构建文章排除了那些不由 LLM 控制工作流执行的应用，并将模型驱动的决策以及工具访问视为智能体的核心特征（OpenAI, “A practical guide to building agents”）。Google Cloud 也从目标追求、推理、规划、行动、记忆以及一定程度的自主性来描述智能体（Google Cloud, 2026）。这些描述有助于理解智能体，但并不意味着所有以 AI 为原生设计基础的系统都必须具备自主性。

因此，工程问题就不是“这个应用用了 AI 吗？”而是：

哪些职责进入了模型介导行为，或因为模型介导行为而发生改变——系统的其余部分是否已被设计为能够安全承担这些职责？

心智模型（mental model）

使用两个阈值测试（threshold tests），再配合四个诊断维度（diagnostic dimensions）。

阈值 1：必要性测试（essentiality test）

问：如果把模型移除，并用传统确定性实现替换，会发生什么？

如果系统的核心目的、交互模型（interaction model）和运行模型（operating model）基本保持不变，那么该模型大概率只是一个 AI 增强功能（AI-enabled feature）。
如果移除模型消除了核心价值，或迫使系统在接收输入、做出决策、产生结果的方式上进行根本重设计，那么该系统大概率是 AI 原生。

这是反事实（counterfactual）测试，而不是品牌规则。一个有韧性的 AI 原生系统可能会提供确定性回退（fallback）。优雅降级是良好工程；它并不能证明该模型是外围的。

阈值 2：适配测试（accommodation test）

问：系统是否明确地适配了模型的行为。

AI 原生设计通常会对以下内容给出具体答案：

模型接收的上下文是什么、以及该上下文从哪里来；
哪些输出可以直接使用，哪些需要验证；
模型可以提出或执行哪些动作；
在现实场景与重复试验（repeated trials）中如何衡量成功；
为诊断保留哪些轨迹（traces）与结果（outcomes）；
系统如何停止、如何重试、如何回退（falls back），或如何升级（escalates）；以及
当系统不确定或出错时，最终由谁负责。

一个模型虽然是必要的，却周边没有任何上述适配措施，并不能证明它构成成熟的 AI 原生架构。更可能只是一个未被承认的依赖（dependency）。

四个诊断维度

在两个阈值都满足后，用四个维度描述设计。它们不构成成熟度评分；“越多越好”并不自动成立。

维度	引导性问题	模型决策空间较小的示例	模型决策空间较大的示例
必要性（Essentiality）	系统目的有多少依赖模型能力？	可选的写作建议	研究系统，其主要输出来自模型生成的综合性结论（synthesis）
运行时决策权（Runtime discretion）	哪些决策被交给模型？	将字段抽取到固定数据结构	选择下一步调查并决定何时证据足够
对外部环境的影响范围（Environmental reach）	模型介导行为能够观察或改变什么？	读取一份已经提供的文档	检索外部来源、修改记录，或通过工具执行代码
工程体系的适应程度（Operational adaptation）	工程生命周期在多大程度上考虑了模型行为可能发生变化？	人工抽查	版本化评估、执行过程审查、结果监控、回滚，以及经过校准的人工评审

这些维度说明了两点。第一，即使交给模型的运行时决策权很少，固定工作流仍然可能是高度 AI 原生的设计。第二，系统的自主性越高、能够影响的外部范围越大，就越需要严格的评估与控制；这并不意味着该设计更加原生或更加先进。

设计选项

AI 原生系统可以采用不同的控制结构（control structures）。选择满足任务所需的最小复杂结构。

1. 受限模型能力（Bounded model capability）

模型在确定性产品流程中执行一次语义上困难的操作：解释请求、生成草稿、对开放式案例进行分类，或在表示形式之间进行翻译。

当该操作对系统目的至关重要，并且周边产品围绕其不确定性构建时，这种设计可以是 AI 原生的。以模型介导修订为中心的写作环境可能符合；只增加了一个可选 AI 小功能的传统编辑器大概率不符合。

当任务有清晰边界（clear boundary）、下一步不需要模型判断（model judgment），且在产生后果之前输出可以被审查或验证时，使用这一结构。

2. 预定义 AI 工作流（Predefined AI workflow）

代码决定阶段（stages），而模型在这些阶段中执行一个或多个阶段，或做出其中受限的决策（bounded decisions）。示例包括路由（routing）、提示链（prompt chains）、并行评审（parallel review）以及评估器–优化器循环（evaluator–optimizer loops）。Anthropic 将其记录为可组合工作流模式（composable workflow patterns），并建议仅在能够可度量地改进结果时再增加复杂度（Anthropic, 2024）。

当任务分解能够可靠进行（decomposes reliably）、可审计性（auditability）很重要，并且显式控制（explicit control）比开放式灵活性更有价值时，使用预定义工作流。

3. 智能体系统（Agentic system）

模型基于目标、当前状态以及环境反馈，选择执行路径中的至少一部分。它可能选择工具、修改计划、请求帮助，或决定工作是否已经完成。ReAct 研究模式提供了一个早期的具体例子：将模型推理与获取新环境信息的动作交错进行（Yao et al., 2023）。

当无法以合理成本提前预测所需步骤，并且灵活、由模型决定路径的行为所带来的价值足以抵消更高的延迟、成本、评估难度与风险时，可以使用智能体。智能体控制仍应在确定性限制内运行，例如权限、预算、停止条件、数据结构约束以及人工审批要求。

结构	谁决定路径？	主要优势	主要成本
受限能力（Bounded capability）	应用代码或用户	简单且失效面较小	跨步骤适配能力有限
预定义 AI 工作流（Predefined AI workflow）	应用代码，并带有受限的模型决策	可预测的编排（orchestration）同时保有语义灵活性	更多集成点，且可变性会叠加
智能体系统（Agentic system）	在明确系统约束（explicit system constraints）下的模型	面向开放任务的灵活行动	更难评估（harder evaluation）、更高成本（higher cost），以及错误后果（greater consequence of errors）更大

工具使用（tool use）、记忆（memory）、规划（planning）、反思（reflection）以及多个智能体（multiple agents）都是可选机制。它们并非 AI 原生软件的通用必需项。只有当它们解决了已证明的问题时，才引入它们。

工程承诺

选择一种 AI 原生设计会改变系统必须管理的内容。

上下文成为一等依赖（first-class dependency）

模型行为依赖指令、检索到的信息、对话历史、工具描述、系统状态以及其他被放入其工作上下文的材料。因此，上下文需要明确的归属、来源、规模限制、新鲜度规则、访问控制以及测试。“提示词”并不是一个孤立字符串；它只是更大规模上下文组装过程中的一项输入。

本章不规定特定的上下文架构（context architecture）。它只建立义务：如果行为依赖上下文，那么上下文必须被工程化并可观测（observable），而不是凭运气拼装出来。

输出是证据、提议或决策——而非自动等同事实

系统必须决定：一个输出意味着什么，以及接下来可能发生什么。生成的解释（explanation）可能会带不确定性展示。抽取的字段可能需要模式（schema）与业务规则（business-rule）验证。提出的动作（proposed action）可能需要授权（authorization）。高风险决策（high-risk decision）可能需要人工审查（human review）。

确定性软件在这里仍然至关重要。鉴权（authentication）、授权（authorization）、事务完整性（transaction integrity）、策略执行（policy enforcement）、速率限制（rate limits）以及不可逆动作（irreversible-action）检查不应仅因为“模型能够表达偏好”就把它们委托给模型。OpenAI 的智能体构建文章同样建议在标准安全控制之外叠加分层防护栏（layered guardrails），并在涉及失败阈值或高风险动作时指出人工介入的重要性（OpenAI）。

结果（Outcomes）比流畅的输出更重要

一个看起来合理的回复（plausible response）并不能证明任务成功了。相关结果可能是正确的预订（reservation）、一次通过的代码变更（passing code change）、一个已解决的支持（support）工单，或一项由权威证据支持的决策（decision supported by authoritative evidence）。

智能体评估实践明确区分了这两者：Anthropic 将模型与工具交互的完整轨迹和环境中的最终状态分开，并建议结合自动评估、生产监控与定期的人工校准（Anthropic, 2026）。具体方法因系统而异，但该原则不仅适用于智能体：应该衡量真正重要的效果，而不只是生成了什么文本。

评估进入开发闭环（development loop）

传统测试仍然必要，但精确输出断言（exact-output assertions）很少能覆盖所有可接受的模型行为。团队需要具有代表性的任务（representative tasks）、对结果的检查（outcome checks）、评分规则（rubrics）、当可变性（variability）重要时的重复试验（repeated trials）、回归套件（regression suites），以及对轨迹与真实失败（real failures）的审查。

这并不只对基础模型（foundation models）独有。生产机器学习（production machine-learning）研究早已长期警告：模型行为嵌入在更广泛的数据与软件系统之中。Google 对隐藏 ML 技术债务（hidden ML technical debt）的工作描述了围绕学习组件的系统级维护关注点，例如耦合（entanglement）、反馈回路（feedback loops）、数据依赖（data dependencies）以及外部世界的变化（environmental change）（Sculley et al., 2015）。其后提出的 ML Test Score 提议：对数据、模型、基础设施与生产行为做测试与监控（testing and monitoring），而不是仅把离线模型质量（offline model quality）当作足够条件（Breck et al., 2017）。生成式系统继承这些担忧，并额外带来开放式输出（open-ended outputs）、对上下文的敏感性（context sensitivity），以及通常是多步骤行动（multi-step action）。

责任（Accountability）不能委托给模型

系统仍需要一个负责人（owner）、一个可接受使用边界（acceptable-use boundary）、升级路径（escalation routes）、事件响应（incident response），以及让受影响人寻求纠正（seek correction）的机制。所需的严谨性应与使用场景与可能造成的伤害（possible harm）相匹配。

NIST 的《生成式 AI 风险管理框架画像》（Generative AI Profile）将风险管理、评估、人–AI 角色、反馈与监督视为组织在构建或运行生成式 AI 系统时的全生命周期职责（NIST AI 600-1, 2024）。模型可以参与决策，但无法承担这些决策的组织责任。

权衡（Trade-offs）

AI 原生设计可以把以前难以处理的问题变得可解：

它能在无需枚举每一条规则的情况下，解释非结构化或存在歧义的输入。
它能支持自然语言交互，并以多种形式生成有用产物（artifacts）。
它能把工作流适配到软件编写时未知的上下文。
它能将自动化扩展到那些由判断与例外主导、而固定路径难以覆盖的任务。

这些能力也带来结构性成本（structural costs）：

可变性（Variability）： 等价输入可能不会产生等价行为。
评估负担（Evaluation burden）： 质量往往是多维度的，并且依赖分布（distribution-dependent）。
延迟与成本（Latency and cost）： 额外的模型调用、检索（retrieval）、工具（tools）与审查会增加运行期开销。
安全与隐私暴露（Security and privacy exposure）： 上下文与工具会把模型连接到敏感数据与具有后果的行动（consequential actions）。
变更敏感性（Change sensitivity）： 模型、提示词、工具、策略与检索的改变可能以意想不到的方式相互作用。
运行期歧义（Operational ambiguity）： 流畅的轨迹（fluent trace）可能掩盖了不正确的结果，或是通向正确答案的无效路径（invalid route）。

不要仅因为模型能够完成任务就选择 AI 原生设计。当规则稳定且可经济编码、需要精确可重现性（exact reproducibility）、失败无法被有界化（failures cannot be bounded）、所需证据不可获得，或预期价值不足以证明运行成本（operating cost）时，优先选择确定性软件。

失效模式（Failure modes）

AI 外衣（The AI veneer）

产品添加了一个模型生成的特性，但却把整个架构称为 AI 原生。由于核心系统没有改变，该标签只是掩盖而不是澄清设计。应执行必要性测试，并对该特性做出诚实的说明。

自主性表演（Autonomy theater）

团队认为更多工具、规划、记忆或智能体就意味着系统更加先进。在没有证据表明结果得到改善时，复杂度仍不断增长。应先采用最简单的控制结构；只有在证据支持时，才扩大模型的决策空间。

在确定性承诺后方的概率组件

API 或用户体验承诺精确行为，却暗中依赖未经验证、范围也不明确的模型输出。要么在对外约定中明确说明不确定性，要么在产生实际后果之前加入确定性验证。

评估模型而不是评估系统

团队追踪基准分数或挑选看起来吸引人的回复样本，却没有测试自己的上下文、工具、策略、边界案例与结果。应该在代表真实使用的条件下，把模型及其运行框架作为一个整体进行评估。

仅用文本构建的防护栏（Guardrails made of prose alone）

系统要求模型不要执行危险动作，但却给予它权限与工具去执行。应在鉴权、授权、模式、沙箱（sandboxes）、事务逻辑、预算与审批门槛（approval gates）上强制执行硬边界（hard boundaries）。

无归属的上下文（Context without ownership）

系统在没有来源证明（provenance）与限制的情况下不断累积检索结果、记忆、指令与工具输出。随后不相关的、陈旧的、敏感的或对抗性的材料会在不显眼的方式下塑造行为。应把上下文视为受治理的运行期输入。

把回退当作反证（Treating fallback as disproof）

团队认为确定性回退意味着系统不是 AI 原生，因此会避免优雅降级。原生依赖描述的是系统正常的目的与运行契约，而不是要求在模型不可用时必须完全失败。

行业证据（Industry evidence）

尽管使用的术语不同，相关参考文献汇聚出若干架构层面的观察：

模型控制的执行是智能体的一个有用边界。 Anthropic 与 OpenAI 都区分了模型导向执行（model-directed execution）与更简单的 LLM 集成或预定义工作流。
当推理与反馈与行动相连时，推理会变得“可操作”。 ReAct 展示了基本机制；当前的智能体工程资料进一步增加了工具、停止条件以及人类检查点。
复杂度应当遵循已展示的需求。 Anthropic 推荐使用简单、可组合的模式；OpenAI 则在足够时推荐确定性方案。
生产质量属于整个系统，而非只属于模型。 早期生产 ML 研究强调系统依赖与监控；当前的智能体评估文章则把运行框架、轨迹与环境结果作为一个整体进行评估。
风险与责任覆盖全生命周期。 NIST 将评估、治理（governance）、人类角色与反馈置于组织责任之内，而非仅在模型内部。

Fieldbook 的结论——这些观察定义了一个更广义的 AI 原生设计类别，其中包含但不止于智能体——是我们的综合。若出现更强证据或更有用的区分方式，应对其进行修订。

本手册的判断

在架构或产品评审中使用以下六个问题：

必要性（Essentiality）： 如果模型消失，哪些核心目的或运行行为也会随之消失？
不确定性（Uncertainty）： 哪些结果会变化？系统如何表示置信度、不确定性或分歧？
上下文（Context）： 哪些信息塑造了行为？归谁所有？其来源证明与新鲜度如何得到验证？
权威（Authority）： 模型可以提出建议、做出决策或执行什么？哪些边界在模型之外被强制执行？
反馈（Feedback）： 任务结果、轨迹、失败与用户纠正如何被转化为评估（evaluation）与系统变更？
责任（Accountability）： 谁对运行、审查、升级与补救（remedy）负责？

在回答之后再对设计进行分类：

AI 增强功能（AI-enabled feature）： 模型足够受限且足够可选，使核心系统与运行模型仍基本保持不变。
AI 原生系统（AI-native system）： 模型介导行为是必要的，并且系统被明确地工程化，以应对其上下文依赖性、可变性与后果。
AI 原生的智能体系统（Agentic AI-native system）：系统是 AI 原生的，并且模型还会围绕目标主导一部分执行路径或工具使用。

这些标签用于描述架构，并不用于给产品质量排序。一个小型确定性服务的工程质量完全可能优于复杂的智能体。正确的问题不是系统还能增加多少自主性，而是任务究竟需要把多少决策交给模型，以及外围系统能否负责任地支持这些决策。

清单（Checklist）

模型是否对系统目的至关重要，还是只提供一项范围明确的增强功能？
我们能解释为什么对于该任务，确定性实现不够吗？
我们是否区分了 AI 原生系统与智能体系统，并明确了谁控制执行路径？
我们知道哪些上下文会实质性影响行为，以及它们来自哪里吗？
模型输出是否按其后果大小进行比例化验证（validated in proportion to their consequences）？
权限、预算、停止条件与不可逆动作是否在模型之外被强制执行？
评估是否既衡量真实结果，也衡量输出与轨迹？
重复试验是否反映了该使用场景所要求的一致性？
系统能否在不隐藏失败的情况下停止、重试、回退或升级？
所有归属、监控、事件响应与用户补救是否是明确的？
每增加的一层工作流或自主性是否都展示了可度量的价值？
考虑延迟、成本、安全与评审工作之后，我们仍会选择这种设计吗？

参考文献（References）

以下链接构成本章的主要参考集。每条备注说明该来源支持本章的哪一部分。

Anthropic, “Building effective agents” (2024) — 支持工作流/智能体区分、增强模型构建模块、环境反馈回路、停止条件，以及对简单可组合模式的偏好。访问时间：2026-07-22。
OpenAI, “A practical guide to building agents” — 支持 LLM 集成与智能体之间的边界、模型/工具/指令（instructions）的基础、分层防护栏，以及在失败阈值或高风险动作涉及时的人类介入。该网页未给出发布日期。访问时间：2026-07-22。
Google Cloud, “What is an AI agent?” (updated 2026) — 从追求目标、推理、行动、观察、规划、记忆与自主性来提供另一份行业视角，并给出智能体、助手（assistants）与机器人（bots）之间的区分。访问时间：2026-07-22。
Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models” (ICLR 2023) — 为“将模型推理与执行动作交错以从环境获取信息”的基本机制提供主要实验证据。访问时间：2026-07-22。
Sculley et al., “Hidden Technical Debt in Machine Learning Systems” (NIPS 2015) — 支持将数据依赖、反馈回路、耦合（entanglement）以及环境变化（environmental change）视为围绕学习组件的系统级工程关注点。访问时间：2026-07-22。
Breck et al., “The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction” (2017) — 支持对生产 ML 系统的测试与监控不仅仅基于离线模型质量。访问时间：2026-07-22。
Anthropic, “Demystifying evals for AI agents” (2026) — 支持把模型与运行框架作为整体进行评估，区分轨迹与环境结果，考虑不同运行之间的可变性，并结合自动评估、生产监控与人工校准。访问时间：2026-07-22。
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (2024) — 支持风险管理、评估、人–AI 配置、反馈与监督的生命周期责任归于组织。访问时间：2026-07-22。