用于构建生产级智能体AI系统的九大架构要素
学习九大架构要素——涵盖零信任网络、数据分层以及证据绑定机制——以便构建可审计的企业级智能体AI系统。
无人谈及的演示版与生产环境之间的差距
打造一个周末就能完成的AI智能体原型其实很简单。
将大型语言模型连接到工具调用循环中，再与向量存储系统相连，加上聊天界面，很快就能做出在演示中看起来相当出色的产品。领导层十分满意，工程师们也充满干劲，还有人在白板上写下了“第三季度试点”几个字。
但一旦系统正式上线，现实情况就会显现。几乎所有组织都会以不同的顺序遇到同样的问题：
代理错误地发放了退款金额——因为没有人明确区分人工智能的决策与固定、可执行的逻辑之间的界限。 安全审计阻止了系统上线——因为客户数据被悄悄通过外部嵌入API传输。 合规部门的人询问为何系统数月前会给出特定答案——而且无法重现当时的推理过程。 那个庞大的代理脚本变得无法修改——因为提示工程、业务规则和API集成全都混杂在同一个文件中。 常规重新索引后输出结果发生变化——没人能复现助手上个月的回答。
令人不安的现实是：
选择模型从来都不是难点，真正困难的是围绕该模型构建系统结构。
代理系统并非只是简单地在脚本上叠加一层人工智能功能，它本质上是一个确定性企业级系统，只不过包含了一个概率推理核心——构建此类系统需要与开发支付平台或核心银行基础设施时相同的工程规范。
本系列将详细介绍构建这类系统的完整架构蓝图。它以九项核心设计决策为框架，这些是每个生产级代理平台都必须同时妥善处理的要素，因为一旦其中一项出错，其他项目往往也会随之出现问题。
我们的实际案例：Aurora银行
摘要中讨论的架构往往难以真正落地。因此在本系列内容中，我们会将每个概念置于具体且虚构的场景之中：
Aurora银行是一家拥有4,000名员工的中型零售银行。他们正在推出“Aurora助手”——一个智能平台，其设计目的包括： — 回答员工关于政策与合规性的疑问， — 协助处理贷款业务（检索文件、核实细节、起草决策）， — 管理诸如退款、账户查询及工单分配等客户服务任务。
Aurora在运行过程中面临的限制与大多数现实企业所遇到的问题如出一辙：
- 客户个人数据不得离开银行自身的基础设施。
- 任何自动化决策都需要在监管机构要求时能够给出合理解释。
在继续阅读时请牢记这五项约束——九大核心原则的设立正是为了解决此类限制问题。
五项指导原则
在详细了解各核心原则之前，先理解其背后的理念会有所帮助：
- 应将模型视为众多组件之一，而非整个架构的核心。模型每隔几个月就会更新一次；而架构则需要经受住这种频繁变动的考验。
- 在内部保持概率性推理，但将边界设定为确定性。大语言模型可以自由思考，但其行动必须通过固定代码来执行。
- 确保每个动作都会生成记录。如果无法回放某个决策，日后就无从为其辩护。
- 按信任级别隔离各个组件，并对所有访问请求进行调解。智能体虽然能力强大，但这正是它们具有风险的原因——必须刻意控制这些风险。
- 构建系统时要假设审计即将到来，也要假设会在凌晨3点接到通知。这两者迟早都会发生。
现在让我们逐一探讨每个核心要素——其含义、为何这种特定结构是正确的、相关的图表、具体示例，以及忽略它的后果。
核心要素1 — 逻辑架构：为何六层结构是正确的
这里的问题很简单：该系统的核心构成要素是什么，各层又分别承担什么职责？
一个智能代理平台可划分为六个逻辑层。
为什么是六层，而不是三层或九层？
传统的三层模型——表现层、逻辑层、数据层——忽略了让智能代理系统区别于其他系统的关键要素：任务协调、模型选择、工具集成以及信任边界。而将系统拆分为九个独立部分则容易使那些本应保持关联的功能模块分离。
事实证明，六层是最低限度的层级数量——每个层都有单一的功能、唯一的负责方以及明确的修改理由。你可以通过这样的方式来验证：对于任意一层，它能否独立改变而不迫使其他所有层随之改变？
- 体验层（L1）会不断变化——出现新的界面、新的渠道以及新的前端需求。
- 编排层（L2）会随着每新增一个用例而发生变化。
- 推理层（L3）会在更强大的模型出现时随之改变，因此需要能够在不影响其他部分的情况下被替换。
- 集成层（L4）会在业务接入新系统时发生变化。
- 数据层（L5）会自行缓慢变化，但围绕它的治理规则则会随着法规的演变而调整。
- 治理层（L6）作为贯穿各层的框架而非底层存在，因为身份认证、审计、评估、约束机制以及成本控制都需要覆盖其他所有层，而无法仅局限于架构的最底层。
一个有用的思维模型是餐厅厨房：它被划分为不同的操作区域——烧烤区、炒菜区、糕点区——这样每位厨师都能专注自己的工作，主厨也可以更换某个区域，而无需彻底改造整个厨房。
Aurora的实际应用：由于第二支柱中提到的主权要求，Aurora银行最终需要用自托管的LLM替代外部的LLM。由于推理功能被隔离在独立的层中，这仅需在L3层进行路由配置调整——无需改动任何工具集成，也无需重写提示词。
如果跳过这一步：每一个新用例都会导致那个臃肿且复杂的文件被不断修改。更换模型会变得不切实际。没人能确定审计逻辑究竟位于何处。
要点：层的作用是标记允许发生变更的位置。妥善设计这些层意味着要设计系统的接口，而不仅仅是其各个组成部分。
第二支柱——物理架构：为何自主部署可行
需要回答的问题：系统在物理上运行于何处？有哪些内容——如果有的话——被允许跨越您的边界向外传输？
在此语境下，“自主”意味着模型、数据、嵌入向量以及执行轨迹都保留在您控制的基础设施内部，仅通过一个经过记录和过滤的网关作为与外部世界连接的唯一通道。
为何几年前还不现实的选择如今却可行了？
- 开放权重模型已缩小了差距。如今，Llama 3.x、Qwen 2.5和Mistral等模型可以自行部署，依然能在分类、信息提取、摘要生成以及基于RAG的问答任务中提供接近生产级质量的结果。
- 量化技术降低了成本。4位量化技术使得单块80GB的GPU就能运行参数量达700亿级的模型，而更小的模型所需的硬件资源则更少。
- 推理基础设施已十分成熟。vLLM能够实现连续批处理并具备较高的吞吐量，非常适合生产环境使用；Ollama则很适合开发工作；Kubernetes则可以像管理其他服务一样来调度这些推理任务。
一个重要的细节：选择以本地模型优先并不意味着完全禁止使用外部模型。这意味着任何离开系统边界的调用都需要手动启用，且仅限于特定数据类别，并通过单一网关传输——绝不会因默认设置而自动触发。这就是将出口网关设计成一扇门的原因：一扇有专人把守的门总比二十扇未上锁的窗户更安全。
实际应用中的极光机制：所有敏感信息——客户文档嵌入内容、代理执行轨迹、个人身份信息——都保留在系统边界之内。唯一允许外传的数据是经过匿名处理的市价查询信息，而这些数据也会通过网关传输，网关会记录下每一字节的传输内容。
若忽视这一点：某些SaaS嵌入工具的默认设置会悄悄将客户对话记录发送给第三方供应商。这样一来，您的可观测性平台就会在境外的服务器上存储包含个人身份信息的轨迹数据。安全审查必然失败，项目也随之告终。
核心要点：系统边界是需要您主动决策的要素。如果您不明确做出规定，供应商的默认配置就会替您决定。
第三支柱——C4模型：做好文档管理
问题：如何对系统进行文档记录，以便不同受众能看到他们所需的精确细节程度？
由西蒙·布朗提出的C4模型提供了四种缩放级别——可以将其想象成在地图上平移和缩放。
为什么C4如此适合代理系统？
- 代理系统本身就容易让人困惑。“代理实际上存在于何处？”这个问题没有明确的答案。C4迫使人们更加精确地描述：代理并非图表中的单个方框，而是一组相互交换消息的容器（运行时环境、网关、各种存储模块）。C4会将这些信息展示出来，而非隐藏它们。
Aurora的实际应用：当监管机构要求明确哪些组件可以接触客户的个人身份信息时，Aurora能在下午之内给出答复。该团队展示了标有第4部分中规定的区域标签的容器图，以及代理运行时的组件图——这两者都是直接从当前代码库状态生成的，并与生成它们的代码一同进行版本控制。
缺乏这种规范时的状况：新员工不得不从源代码开始反推架构。审计人员收到的则是已经过时14个月的60页演示文稿。任何关于架构的分歧都会演变成在白板上讨论矩形形状的争论。
要点：文档是你的架构与所有需要依赖它的人之间的接口。C4将这一接口转变为可版本控制、可审核的形式，而非静态的文档。
第四支柱——零信任网络：为何特指五个区域
问题：一旦系统遭到入侵——而最终难免会发生这种情况——该如何控制损失？
零信任意味着绝不给予任何隐含的信任：每一项请求都必须通过mTLS和工作负载身份进行认证，经过策略检查获得授权，并且即使是在不离开自身网络的流量中也要进行加密。对于基于代理的平台，正确的区域划分应分为五个部分：
为何恰好是五个区域？
因为每个边界都必须分隔出真正不同的信任级别——而各种代理引入了传统架构根本无需考虑的信任级别：
- Z1，边缘层——不可信流量首先到达此处。它持续遭受攻击，因此可视为已被入侵。
- Z2，应用层——直接为最终用户提供服务。属于半可信层级。
少于五个区域时，无法打破那些分隔真正不同信任级别的边界。超过五个区域则只会增加额外的屏障，而不会形成新的信任边界。五个正是恰到好处的数字。
Aurora的实际应用：攻击者通过被攻破的网页注入指令，试图诱使研究子代理获取人力资源薪资记录。由于该接口的范围根本不包含人力资源系统，区域策略会直接阻断从Z3到HR的路径。中心节点会记录下此次尝试，而攻击者最终只能得到公开的网页数据。代理虽被操控，但银行的数据依然完好无损。
如果没有这种分区：一个泄露的连接器API密钥就会让攻击者或恶意代理直接无阻地进入整个数据层。
要点：智能体会大幅增加网络内部横向移动的风险。合理的区域划分能让被攻破的智能体从引发关注的漏洞变成一个普通的日志事件。
第五支柱——中心辐射式集成：智能体的理想架构
问题：如何让智能体连接到20多个企业系统，同时避免集成层变得混乱不堪？
答案就是使用一个集成中心，再由经过认证的分支节点围绕其构建。
为什么这对智能体尤为重要？算一算就知道。如果直接将所有系统相连，就需要10个系统乘以8个智能体，即80次独立集成。而通过集成中心路由，则只需10个分支节点加上8次智能体连接——总共仅18条链路。
每一个直接的点对点链接都是凭证被硬编码、日志记录被忽视，以及其行为与系统其他部分逐渐出现差异的隐患点。若这样的链接有80个，那就意味着审计人员有80处无法彻底查看的情况。代理程序只会让状况更糟，而非更好，因为每个新添加的代理都倾向于想要访问所有内容。
通过中心节点实现集中管理，能让您掌控四项至关重要的要素：
1. 认证中介机制——中心节点存储实际的 Salesforce 凭据，而代理仅持有有限权限且可撤销的令牌。撤销一个令牌即可控制对应代理，无需更多操作。 2. 结构映射——“客户”一词在不同系统中的含义可能截然不同，比如在 SAP、CRM 或客服系统中。中心节点会统一处理这些差异，无需让八个独立的代理代码库各自处理。 3. 可靠性——中心节点的速率限制与断路机制可防止某个不稳定的代理引发整个代理群组的连续重试。 4. 统一的审计入口——统一的日志格式，让问题“哪个代理在何时、以何种权限修改了哪条记录？”有唯一的查询途径。
另一个好处是，MCP风格的工具服务器能让各个组件变成可插拔的标准化部件，而非一次性开发的集成代码。
Aurora中的实现方式：将ServiceNow作为第21个系统上线，就相当于构建了一个这样的组件。从第二天起，所有客服人员都能在与其他20个系统相同的认证机制、速率限制及审计追踪体系下使用它。如果采用点对点的集成方式，就需要开展八个独立的集成项目，并进行八次单独的凭证交接。
不采用这种模式的话：每个客服人员都会自己保存Salesforce的密码，根本无法追踪是哪位客服修改了某条客户记录。要添加新工具，则需要整整一个季度的工程开发时间。
要点：该中心对工具而言的作用，就如同主管对员工的作用——提供一个功能完备的统一入口。
第六支柱 — 数据架构：为何需要不同的层级
问题：应如何构建数据结构，才能确保答案可重复生成、记录可按需删除，并使整个流程始终处于可控状态？
答案是采用五个层级，按流程顺序排列：
T0 — 源系统。这些是原始记录系统。你并不拥有它们，且它们会按照自身的时间表自动变更，不会发出任何预警。 T1 — 原始存储区。记录所有数据初次导入时的副本。这是任何重建操作的基准点，除非有明确的保留策略，否则绝不能被编辑或删除。 T2 — 处理过的数据。经过清洗、去重、分块处理，标注了个人身份信息，并附加了数据来源标识。 T3 — 服务层。向量索引、知识图谱、语义缓存——这些都是可重建的组件，需要在时可从T2重新生成。 T4 — 代理生成的数据。对话日志、记忆记录、追踪信息以及生成的输出内容。这一层级仅支持追加数据，很少会提前规划，且通常包含整个系统中最敏感的信息。
为何偏偏是五个层级？
如果这让人联想到常见的奖章式架构——青铜级、银级、金级——那是有意为之；T1至T3层级正是那种早已确立的模式。而代理环境新增的则是两端的两个层级：在数据来源端设置明确边界（即T0级，因为需要详细规定数据接入协议），并在代理输出端设置一个层级（即T4级，因为代理产生的也是数据，同样需要满足相关的存储、隐私和审计要求）。
将数据按层级结构化，能将原本棘手的两个问题转化为常规工作：
1. 可重复性。不必因“我们改变了分块策略，结果答案不同”而陷入危机，只需在夜间将T3从T2重新构建即可。如果模型出现损坏，则可从T1重新生成T2。完全无需重新爬取原始数据源系统。
2. 删除功能。当客户根据GDPR行使删除权时，明确的关联关系意味着可以通过标识符让删除请求按固定路径依次传递到T1、T2、T3和T4，无需手动查找。
所有这些规则背后的原则是：向量索引仅属于缓存，绝非真实数据来源。
Aura中的实际效果：质量保障团队发现，原有的分块逻辑正在悄悄删除表格行。Aura利用修正后的分块工具在夜间重新嵌入了200万份来自T2的文档，无需重新爬取任何源系统，也不用担心历史数据丢失的问题。一个月后，团队就能够重建并对比在修复前后针对同一问题会得到怎样的答案。
如果没有分层机制：向量存储就成了数据的唯一副本。源端的删除操作永远不会传递到下游。像“3月份时助手跟这位客户说了什么？”这样的问题就根本无法得到解答。
核心要点：在设计数据架构时，应考虑到未来可能需要的重建操作以及法律上要求必须执行的删除操作。
第七支柱——智能体设计：为何由子智能体构成的监督者优于单一庞大智能体
问题在于：应如何构建构成系统的智能体“社会”结构？
在实际应用中已被证明有效的模式是协调者-工作者架构：一个监督者负责整体目标，而多组子智能体则各自处理特定的细分任务。
为何划分职责比打造一个装了五十种工具的庞大智能体更好？
1. 上下文很快就会变得模糊不清。当一个智能体需要同时处理五十种工具和没有明确终点的目标时，其性能会明显下降——错误地选择工具、忘记约束条件、失去任务思路。而拥有五种工具且任务范围明确的专家型智能体则可靠得多。 2>其实可以对其进行测试。对于复杂的巨型提示语，没有有效的单元测试方法。但可以为每个子智能体构建专门的评估套件——比如为研究型智能体设计200个测试用例，为写作型智能体设计50个。这样就能让智能体的回归测试变得具体且可重复。 3. 可以设置单一控制点。监督者成为执行预算限制（每项任务最多12步，或0.40欧元）、管理重试次数、触发人工干预以及为所有任务交接设置约束条件的唯一环节。 4. 工作可以并行进行，各部分也可互换。
子代理可以同时运行，且其中任何一个都可以被替换——无论是更强大的LLM、成本更低的模型，还是完全确定性的检索步骤——而不会影响系统的其他部分。
需要强调的是，“子代理”并不意味着“从底层到顶层的全部都是LLM”。在Aurora的架构中，成本计算子代理根本不包含任何LLM——它只是披着代理风格界面的外衣的确定性代码。这为Pillar 8的概念做了铺垫。
实际应用中的Aurora：贷款辅助流程被拆分为研究者（获取政策文件）、审核员（验证文件）、计算器（用简单代码计算还款能力）以及撰写者（起草面向客户的信函）。每个环节都会被独立评估、版本控制并由专人负责。如果模型更换后撰写者的文本风格评分下降，只需调整对应的专业人员，而无需整改整个系统。
跳过这一环节的后果是：最终会得到一个包含七十种功能的庞大代理系统，它偶尔会因为无法解释的原因多次调用退款API——而所有人都因担心出问题而不敢对其进行修改。
核心要点：拆分工作不仅关乎效率，在代理系统中更是可靠性的根本所在。
第8项——确定性与推理：最重要的决策
问题：在系统中，究竟应在何处让概率型人工智能的判断起主导作用，而哪些部分仍需由代码和政策来决定？
这是核心支柱——其他所有要素的存在都是为了支持或落实你在此给出的答案。
指导原则很简单：
大语言模型负责提出建议，确定性系统则负责最终决策。
利用大语言模型处理其擅长的任务：分类、信息提取、草稿撰写、规划。而对于监管要求和合理的工程设计所必需的工作，如验证、资金转移、状态变更、合规性强制执行，则应使用确定性代码。
在实践中，这意味着将工作流程视为状态机，大语言模型仅在特定的、明确列出的决策点上发表意见，其余所有操作均由普通代码处理。
为何这一设计选择会被视为最具决定性的？因为它决定了后续的所有事项：
1. 可靠性——涉及资金处理的路径绝不能出现意外行为。
2. 可审计性——由于决策分支是可枚举的，因此可以列出每一个需要做出判断的节点。
3. 成本控制——无需在那些简单的if语句就能免费处理的任务上浪费资源。
4. 架构一致性——在第七支柱中的监督器负责设置这一边界，第五支柱中的中心节点在工具层强制执行该规则，第四支柱中的区域用于容纳所有故障，而第九支柱中的证据存储则用于事后证明实际发生了什么。
Aurora的实际应用——退款流程：
- 推理区域内的大语言模型：读取客户的邮件并提取结构化字段——
金额：145欧元、原因：货物损坏、情绪：沮丧。此步骤为概率性操作，这并无问题，因为它仅用于填充表格。 - 确定性策略引擎：金额在200欧元以内的可自动批准；200欧元至1,000欧元的会触发基于规则的核查；超过1,000欧元的则需要人工审批。大语言模型无权直接划拨资金——它只能提出一个金额建议，最终由代码决定该金额的处置方式。
这两种极端情况都很危险，正因如此才需要采取折中的方式：
让大语言模型决定一切（“干脆让智能体来处理”），最终只会产生被恶意提示注入的邮件，授权发放5万欧元的退款。而让规则决定一切，则意味着系统连一封普通邮件都无法解析——实际上相当于回到了1995年。
要点：完全依赖大语言模型的自主性只是演示用的把戏；完全基于规则的僵化模式也已过时。实际生产系统需要一份明确记录、详细说明每种模式适用场景的地图——而正确绘制这份地图是设计整个系统时最关键的决定。
第九项原则——证据绑定/引用：为何如此才能通过审计
问题：如何确保所有输出在数月甚至数年后，仍能经得起正在寻找漏洞的审计人员的审查？
每一个事实性陈述都必须与其来源证据相关联，且一旦记录下来，整个决策过程就不得更改：
为何这种做法能通过审计？因为它同时提供了三项保障：
1. 幻觉过滤机制。如果没有引用，那就不算正式发布。当答案生成环节无法附上有效来源时，该输出就会被标记或屏蔽。这样一来，“只需信任模型”这一理念就变成了可执行的机械规则。
2. 完整回放功能。如果有人询问“为什么系统在3月3日会这样响应？”，你可以还原完整的流程——原始问题、检索到的内容、提示词版本、模型版本、生成的答案及其引用依据。无需使用“我们认为”之类的表述，直接呈现实际记录即可。
3. 根本原因的清晰性。当输出结果出现错误时，可以立即确定故障类型：是检索失误（找到了错误的证据）还是推理失误（找到了正确的证据但解读有误）？这两种情况需要完全不同的解决方案，而如果没有确凿的证据作为依据，就无法区分二者。
实际应用中的极光系统：该助手在回答有关处罚条款的问题时，会引用credit_policy_v12.pdf, 第14页, sha256:9f2c…作为依据。后来当政策版本13发布时，之前的回答依然准确反映当时的事实，因为所引用的证据是通过哈希值固定的，而非动态重新获取的。合规审查员可以批准这些回答，因为整个流程可回放、可验证未被篡改，并且有正确的时间戳。
若跳过此步骤：在发生事故或审计时，你唯一的辩护理由就只剩下“模型是这么说的”。这样一来，你就无法区分数据质量问题与推理错误。监管机构会将此类系统视为黑箱——而黑箱系统必然会被关闭。
核心要点：如果系统无法提供依据，就不能将其公开使用。
九大支柱如何相互关联
这九个要素并非独立的清单——它们构成了一个以核心为根基的完整结构：
一旦缺少其中任何一环，其余部分就会开始出现裂痕。若去掉中心辐射层（5），则无法在工具调用层面强制执行确定性原则（8）。若取消数据分层机制（6），证据绑定机制（9）就失去了可依赖的依据。若没有C4文档（3），在审计时甚至无法解释剩余的架构结构。只有将它们作为一个整体来运用——要么九项都保持完整，否则整个体系就会崩溃。
本系列后续内容
接下来的每一篇文章都将进行深入探讨：包括指导原则、相关图表、来自Aurora Bank场景的实际案例、具体的技术选型、需要避免的常见反模式，以及实用的构建检查清单。
最后思考
到2026年，拥有功能强大的模型已不再是竞争优势——API密钥是任何人都能获取的东西。
真正能区分出经久不衰的系统的，是其架构设计。那些成功将智能体系统引入受监管的高风险环境中的团队，正是那些理解了任务本质的团队：他们构建的是一种确定性的企业系统，只不过在其中嵌入了概率推理引擎。
九大支柱，九项决策。必须全部正确地同时完成。
接下来是第一部分：逻辑架构，我们将逐步构建六层结构，明确界定每对层次之间的接口规范，并详细分析那些会导致智能体代码库变得难以维护的错误设计模式。