AI Native架构实战：从意图驱动到零信任安全的设计指南

1. 为什么现在要聊 AI Native 架构过去两年我参与过三个从零起步的 AI 项目也接手过两个“传统系统加挂大模型”的改造项目。这两类项目的体感差异非常大前者像在平地上盖房子想怎么设计就怎么设计后者像在老房子里改水电每动一处都要先确认会不会把承重墙敲了。AI Native 架构这个词现在被提得很多但真正落地时很多团队做的其实是“AI-Added”而不是“AI-Native”——系统主体还是原来的业务逻辑只是在某个环节塞了一个 LLM 调用。这两者的区别用一句话概括AI-Added 是把模型当工具AI-Native 是把模型当决策中枢。工具可以随时替换中枢一旦确定整个系统的数据流、状态管理、错误处理、安全边界都要围绕它重新设计。我见过太多项目在架构评审时被问“你的 Agent 挂了怎么办”结果发现整个链路根本没有为“模型会失败”这件事做过设计。这篇文章面向的是准备从零构建 AI 系统的工程师、架构师以及正在做技术选型的团队负责人。我会把 AI Native 架构拆成几个可以独立决策的模块核心设计思路、Agent 与 LLM 的协作方式、零信任安全模型、并发与状态管理、以及实操中真正会踩的坑。每个部分我都会说明“为什么这么选”而不只是“怎么配”。需要提前说明的是AI Native 目前没有一套放之四海皆准的标准架构不同业务场景下的取舍差异很大。我下面讲的是基于多个项目实践总结出的通用骨架具体到你的场景需要根据延迟要求、成本预算、合规约束做调整。2. AI Native 架构的整体设计思路拆解2.1 从“功能驱动”转向“意图驱动”的设计范式传统架构设计的起点是功能列表用户点击按钮系统执行对应逻辑返回结果。整个系统的复杂度体现在分支逻辑和状态流转上。AI Native 架构的起点是意图用户表达一个目标系统理解意图后自主编排能力去完成。这意味着架构的核心不再是“有多少个接口”而是“有多少种可被编排的能力单元”。这个转变带来的第一个直接影响是能力注册机制。在传统系统里新增一个功能就是新增一个接口在 AI Native 系统里新增一个能力需要同时定义它的语义描述、输入输出 schema、调用约束和失败降级策略。因为 LLM 需要根据自然语言描述来决定调用哪个能力描述的质量直接决定了编排的准确率。我试过两种能力注册方式。一种是用结构化的 JSON Schema 描述每个工具另一种是半结构化的自然语言加参数说明。实测下来对于参数复杂的工具JSON Schema 的调用准确率明显更高对于逻辑简单但语义微妙的工具自然语言描述反而更灵活。现在我的做法是两者结合用 Schema 约束参数用自然语言补充使用场景和注意事项。第二个影响是状态管理的重心转移。传统系统的状态主要是业务状态比如订单状态、用户状态。AI Native 系统里多了一层“推理状态”——当前对话历史、已调用的工具链、中间结果、待确认的假设。这层状态的管理难度远高于业务状态因为它是不确定的、可能很长的、而且对上下文窗口有硬性限制。2.2 分层架构与核心组件选型我目前使用的 AI Native 架构大致分为五层从下到上依次是模型接入层统一封装不同 LLM 提供商的接口处理鉴权、限流、重试、降级。这一层的核心价值是让上层不感知具体模型方便做 A/B 测试和成本优化。能力层注册所有可被 Agent 调用的工具和函数包括内部 API、数据库查询、外部服务。每个能力都有独立的描述、参数定义和错误处理。编排层Agent 的核心逻辑所在负责意图理解、任务分解、工具选择、结果聚合。这一层是 AI Native 架构区别于传统架构的关键。状态层管理会话状态、推理中间态、长期记忆。需要同时支持短期上下文和长期知识检索。交互层面向用户的入口可能是对话界面、API 网关也可能是嵌入到现有产品中的智能模块。选型上模型接入层我倾向于自建轻量网关而不是直接用厂商 SDK。原因很简单一旦业务量上来你需要做多模型路由、成本监控、失败重试这些在厂商 SDK 里做会很别扭。网关不需要很复杂一个反向代理加一层适配逻辑就够了。编排层是选型分歧最大的地方。有人喜欢用 LangChain 这类框架有人喜欢自己写。我的经验是如果业务逻辑简单、工具数量少用框架能省不少事如果工具超过二十个、编排逻辑有复杂的分支和循环自己写反而更可控。框架的抽象层在复杂场景下会成为调试的障碍你很难搞清楚到底是你的 prompt 有问题还是框架的某个中间件在捣乱。2.3 为什么“零信任”在 AI 架构里更重要零信任这个词在安全领域已经讲了很多年但在 AI Native 架构里它有新的含义。传统零信任主要解决“谁可以访问什么资源”的问题AI 系统里还要多解决一层“模型生成的指令是否可信”。我踩过的一个坑早期做 Agent 时把工具调用权限直接开放给了模型结果模型在一次对话中连续调用了删除接口虽然最后因为参数校验失败没有造成实际损失但这件事让我意识到模型输出必须经过独立的权限校验层。现在的做法是所有工具调用都要经过一个策略引擎策略引擎根据当前用户身份、会话上下文、调用频率来决定是否放行模型本身没有直接执行权限。另一个零信任的实践是输入输出双向校验。输入侧要防止 prompt 注入输出侧要防止敏感信息泄露。输入侧的校验不能只靠关键词过滤因为绕过方式太多更可靠的做法是限制模型的可用工具集和可访问数据范围从架构上缩小攻击面。输出侧的校验则需要结合业务规则比如涉及金额、权限变更的操作必须经过二次确认。3. Agent 与 LLM 协作的核心细节解析3.1 Agent 的本质一个带记忆的决策循环很多人把 Agent 理解成“会调用工具的 LLM”这个理解不够准确。Agent 的本质是一个带记忆的决策循环观察当前状态决定下一步动作执行动作更新状态再观察。LLM 在这个循环里扮演的是决策函数而不是全部。这个循环的设计有几个关键决策点。第一是循环终止条件。最简单的做法是让模型自己判断任务是否完成但实测下来模型很容易陷入“再确认一下”的循环。更可靠的做法是设置最大步数加显式完成信号模型必须调用一个特定的完成工具才算结束。第二是记忆的粒度。全量保留对话历史会导致上下文爆炸只保留最近几轮又会丢失关键信息。我现在的做法是分层记忆最近三轮完整保留更早的对话压缩成摘要关键事实和用户偏好单独存储并在需要时检索。摘要的生成也要用模型但要用一个更便宜的小模型来做因为摘要任务对模型能力要求不高。第三是工具选择的策略。当工具数量超过一定规模时把所有工具描述都塞进 prompt 会导致选择准确率下降。我试过两种方案一种是先用一个轻量模型做工具粗筛再让主模型在候选集里选另一种是按场景分组根据当前意图只加载相关组的工具。前者适合工具数量多但场景边界模糊的情况后者适合场景清晰的业务。3.2 LLM 调用的工程化处理LLM 调用看起来简单实际上工程化的坑非常多。我整理了几个必须处理的点超时与重试。LLM 的响应时间波动很大同样的 prompt 可能 2 秒返回也可能 30 秒返回。超时设置太短会导致大量重试太长会拖垮用户体验。我的做法是设置分级超时首字节超时 5 秒总响应超时根据任务复杂度动态调整简单任务 15 秒复杂任务 60 秒。重试策略上只对网络错误和 5xx 错误重试对 4xx 错误直接失败因为重试也不会成功。Token 预算管理。每个请求都要预估 token 消耗包括输入和输出。输入侧要在组装 prompt 时就计算超预算要触发压缩或截断输出侧要设置 max_tokens防止模型生成过长内容。我见过一个项目因为没有设置输出上限一次请求消耗了正常情况二十倍的 token成本直接失控。流式输出的处理。对话场景下流式输出几乎是必须的但流式会带来新的问题如何在流式过程中检测敏感内容如何在流式过程中处理工具调用我的做法是流式只用于最终回复工具调用阶段仍然用非流式因为工具调用的参数需要完整解析后才能执行。失败降级。模型服务不可用时要有降级方案。最简单的降级是返回预设话术好一点的降级是切换到备用模型更好的降级是切换到基于规则的兜底逻辑。降级方案要在架构设计阶段就确定不能等出事了再想。3.3 上下文工程比 Prompt 工程更重要的能力Prompt 工程关注的是“怎么写指令”上下文工程关注的是“给模型看什么”。在 Agent 场景下后者比前者重要得多。因为 Agent 的每一轮决策都依赖于当前上下文上下文的质量直接决定决策质量。上下文工程的核心是信息筛选和排序。模型对上下文不同位置的敏感度是不一样的开头和结尾的信息更容易被注意到中间的信息容易被忽略。所以关键指令要放在开头或结尾参考信息放在中间。我通常的组织顺序是系统指令、当前任务描述、相关历史摘要、检索到的知识、可用工具列表、当前用户输入。另一个关键是上下文的动态组装。不同任务需要的上下文不同不能把所有信息都塞进去。我的做法是为每类任务定义上下文模板模板里标明哪些部分是必需的、哪些是可选的、哪些需要动态检索。这样既能保证信息完整又能控制 token 消耗。还有一个容易被忽略的点是上下文的版本管理。当系统指令或工具描述发生变化时需要能够追溯是哪个版本导致了效果变化。我现在的做法是把所有上下文模板纳入版本控制每次变更都记录变更原因和效果对比。4. 零信任安全模型在 AI 系统中的落地4.1 权限边界的设计原则AI 系统的权限设计比传统系统复杂因为调用方可能是人也可能是模型。我的原则是模型永远不直接持有权限所有权限都绑定在用户身份上。模型只是发起调用请求实际执行时用的是当前用户的权限。这个原则听起来简单落地时有很多细节。比如一个查询工具用户 A 只能查自己的数据用户 B 是管理员可以查所有人的数据。模型在调用这个工具时不能自己决定查谁的数据而是要把当前用户身份传给工具由工具内部做权限判断。模型能做的只是决定“要不要调用这个工具”而不是“以什么权限调用”。另一个原则是最小权限加动态授权。默认情况下模型只能调用只读工具涉及写操作的工具需要显式授权。授权可以基于会话也可以基于单次调用。我倾向于基于单次调用因为会话级别的授权一旦被滥用影响面太大。4.2 输入输出的双向校验机制输入侧的主要威胁是 prompt 注入。用户可能在输入里嵌入指令试图让模型执行非预期操作。防御手段有几个层次第一层是输入清洗移除明显的注入模式比如“忽略之前的指令”这类短语。但这层很容易被绕过只能挡住低级的攻击。第二层是指令隔离把系统指令和用户输入用明确的分隔符隔开并在系统指令里强调用户输入只是数据不是指令。第三层是能力限制即使注入成功模型能做的事情也有限因为工具集和权限是受限的。输出侧的威胁主要是敏感信息泄露和有害内容生成。校验机制包括敏感词过滤、PII 检测、输出格式校验。输出格式校验经常被忽略但它很重要——如果模型输出的 JSON 格式不对下游系统可能会解析失败甚至执行错误逻辑。4.3 审计与可观测性AI 系统的审计比传统系统更难因为决策过程是不透明的。你很难解释“为什么模型选择了这个工具而不是那个”。但审计又是必须的尤其是涉及资金、权限、敏感数据的场景。我的做法是记录完整的决策链路每一轮的输入上下文、模型的原始输出、解析后的动作、执行结果、耗时和 token 消耗。这些数据一方面用于问题排查另一方面用于效果分析和优化。记录的量会很大所以需要采样策略——正常请求采样 10%异常请求全量记录。可观测性还包括实时监控。需要监控的指标包括调用成功率、平均延迟、token 消耗趋势、工具调用分布、异常率。这些指标要设置告警阈值比如成功率低于 95% 就告警。我见过一个项目因为没做监控模型服务降级了三天才发现期间所有请求都在走兜底逻辑用户体验极差。5. 并发、状态与性能的实操要点5.1 Agent 并发处理的实际方案“AI Agent 怎么扛并发”是最近被问得很多的问题。我的经验是Agent 的并发瓶颈通常不在模型调用本身而在状态管理和工具调用。模型调用层面大部分厂商都支持较高的并发真正的限制是配额和成本。所以并发方案的核心是排队和限流。我的做法是在模型接入层做令牌桶限流每个用户或每个会话分配一定的配额超出配额进入排队。排队要有优先级交互式请求优先于批处理请求。状态管理层面并发带来的问题是状态冲突。同一个用户可能同时发起多个会话这些会话之间的状态需要隔离。我的做法是用会话 ID 作为状态隔离的键每个会话有独立的状态存储会话之间不共享推理状态。长期记忆可以共享但读写要加锁。工具调用层面并发的问题是下游服务可能扛不住。比如模型同时调用了十个数据库查询数据库连接池可能被打满。解决方案是在能力层做并发控制每个工具设置最大并发数超出则排队或拒绝。5.2 状态存储的选型与设计状态存储的选型取决于状态的生命周期和访问模式。短期会话状态我通常用 Redis因为读写频繁、生命周期短、对持久化要求不高。长期记忆用向量数据库加关系数据库的组合向量库负责语义检索关系库负责结构化查询和元数据管理。状态设计上有个容易犯的错误是状态粒度过细。把每个中间结果都存下来会导致存储膨胀和读写放大。我的做法是只存关键状态当前任务目标、已完成步骤、待确认事项、关键事实。中间的计算过程不存需要时重新计算。另一个问题是状态的一致性。当多个组件同时读写状态时需要明确一致性模型。我的做法是会话状态用乐观锁长期记忆用最终一致性。乐观锁的冲突处理是重试加合并合并策略根据具体状态类型定义。5.3 性能优化的几个关键手段性能优化上我总结了几条实际有效的做法缓存。LLM 调用结果可以缓存尤其是那些确定性高的请求。缓存的键是输入上下文的哈希命中缓存直接返回。缓存要注意失效策略模型版本更新或系统指令变更时要清空缓存。批处理。非交互式场景可以把多个请求合并成一个批次调用提高吞吐量。批处理的难点是结果拆分需要保证每个请求的结果能正确对应回去。模型分级。不是所有任务都需要用最强的模型。意图识别、摘要生成、格式转换这些任务用轻量模型就够了只有复杂推理才用大模型。模型分级能显著降低成本对延迟也有帮助。预计算。一些耗时的操作可以提前计算比如知识库的索引构建、常用查询的结果缓存。预计算的关键是预测哪些内容会被用到这需要结合业务特点做分析。6. 常见问题与排查技巧实录6.1 模型输出不稳定的排查思路模型输出不稳定是最高频的问题。表现可能是同样的输入有时返回正确结果有时返回错误结果或者格式时好时坏。排查时我通常按以下顺序检查先看温度参数。温度过高会导致输出随机性大Agent 场景下温度通常要设得很低甚至为 0。但要注意即使温度为 0由于服务端的批处理等原因输出仍可能有细微差异。再看上下文是否一致。如果上下文里有动态内容比如当前时间、随机 ID那么每次请求的上下文其实是不一样的输出自然不同。排查时要把上下文完整打印出来对比。然后看工具描述是否有歧义。如果两个工具的用途描述有重叠模型可能在不同轮次选择不同的工具。解决方法是让工具描述互斥且明确必要时在系统指令里补充选择规则。最后看模型版本是否变化。厂商可能会在不通知的情况下更新模型导致行为变化。所以生产环境要固定模型版本不要用 latest 这类标签。6.2 工具调用失败的常见原因工具调用失败的原因很多我整理了一个速查表现象可能原因排查方法模型不调用工具工具描述不清晰或与任务不匹配检查工具描述补充使用场景说明调用参数格式错误Schema 定义与模型理解不一致简化 Schema增加参数示例调用不存在的工具工具列表过长导致混淆减少单次加载的工具数量分组加载调用频率过高模型陷入循环设置最大步数增加循环检测工具执行超时下游服务慢或网络问题检查下游服务设置合理超时结果解析失败输出格式不符合预期增加格式校验失败时重试或降级排查工具调用问题时最重要的是保留完整的调用日志。日志要包含模型原始输出、解析后的参数、执行结果、耗时。没有这些信息排查基本靠猜。6.3 成本失控的预防与处理成本失控通常有几个信号单次请求 token 消耗异常高、调用频率异常增长、某个工具被频繁调用。预防措施包括设置单请求 token 上限超出直接拒绝。设置用户级和系统级日配额超出后降级或拒绝。监控token 消耗趋势设置告警阈值。定期分析调用分布找出高消耗的场景做优化。处理成本失控时先定位是哪个环节消耗大。如果是输入侧检查上下文是否过长是否有不必要的检索如果是输出侧检查是否有 max_tokens 设置不当如果是调用频率检查是否有循环调用或异常流量。6.4 实操心得与避坑建议最后分享几条我在实际项目中总结的经验不要过早优化。AI Native 架构的很多决策依赖于实际运行数据过早优化可能优化了错误的方向。先把链路跑通有了数据再做优化。保留人工兜底。无论模型多强都要保留人工介入的通道。尤其是涉及重要决策的场景模型输出要经过人工确认才能执行。版本管理要严格。模型版本、prompt 版本、工具描述版本都要纳入管理每次变更都要记录并做效果对比。我见过因为改了工具描述导致整个 Agent 行为变化的案例没有版本管理根本查不出来。测试要覆盖异常路径。正常路径的测试很容易做异常路径的测试才是关键。模型超时、工具失败、上下文超长、权限不足这些场景都要有测试用例。文档要写决策原因。架构文档里不仅要写“怎么做”更要写“为什么这么做”。半年后回头看你会感谢自己当时记录了决策背景。这个领域变化很快今天的最佳实践可能明天就被推翻。保持学习保持实验但不要为了追新而牺牲稳定性。架构的核心价值是解决问题不是展示技术。