企业级Agent AI Native架构设计与实践

今天跟大家分享下半个月前，去参加ITPUB举办的【中国系统架构师大会】上做的主题分享《企业级Agent AI Native架构设计与实践》的详细内容。

除此之外，还参加了一个圆桌，探讨了现阶段一些AI发展的观点。

先抛出来会上我的5个最核心的观点：

1、模型能力驱动智能体架构发展，没有成熟的智能体的架构，只有不断精进的智能体架构。

2、工程化思维，除了传统的SDD、TDD、DDD外，Agent时代，我们应该更加注重EDD（Eval-Driven Development）。

3、企业的智能体建设，未来应该朝着APaaS（Agent Platform as a Service）方向去做。

4、Markdown设计文档即代码，企业必须从Vibe Coding转向AI规范化编程，拒绝 “shi 山” 代码。

5、现在企业级Agent AI Native的架构设计，跑不出我提出的“7+2”结构。【7层架构（业务应用层、应用网关层、AI AGENT CORE、AI 网关层、大模型层、知识 & 数据层、基础设施层）+ 2侧横切关注点（可观测性 & 评估、安全治理 & 合规）】。

正文前，首先打个广告，本人写的智能体开发实战书籍《LangChain 1.0 智能体开发实战》已于4月上市开卖，各大电商平台均有发售，618正好有活动，感兴趣的小伙伴可以关注下。

同时也感谢举办方ITPUB和电子工业出版社的支持，会议当天进行了推广和签售。

好了，回归正文，开始核心内容的分享。

一、重新认识 AI Native 架构

1、现在很多人都在做智能体，但是分不清楚什么是AI功能集成，什么是基于AI原生构建的智能体。这里先给大家做一个普及：如果说，你的主体是系统本身，而AI只是作为一个外挂模块，调用模型是无状态的，核心主业务逻辑甚至感知不到AI的存在，那它就是AI功能集成。如果说，你是以AI大模型为核心去驱动你的核心业务流程，那就是AI原生。

所以这二者最核心的一个区别在于：AI集成是「给系统 加 AI 功能」，但AI Native 是「用 AI 重构系统」。

2、那么接下来再来看看，传统的智能体与企业级的智能体，他们的设计标准，有什么不同。传统的智能体，核心是要解决能力有无的问题，智能体的健壮性整体偏弱一些，也就是Harness弱一些，有的时候甚至只是一个MVP阶段的产物，能用就行。但是企业级智能体完全不同，它是要求智能体可以高效、稳定、安全的运行，其任务复杂度、记忆体系、安全性、权限控制等要求，要远高于传统的智能体。

3、企业级智能体的落地，现在行业范式正在经历了三次非常关键的转变，分别是：从上下文工程到驾驭工程，从单体智能体到多智能体，从项目级智能体到平台级智能体。这些关键的转变，主要是为了解决：智能体的可控性不足、可扩展性不足与可治理性不足，这三大问题。

4、所以这次分享的核心主题：企业级智能体AI原生架构。就是要【打造 AI Native 的基础设施，去构建稳定、可扩展、可治理的企业级 Agent 平台，让 Agent 能力可以复用、可以观测、可以规模化运营】。

这一页，我还写了一个公式，相信大家在一些资料中也都见过了，Agent=Model+Harness，所以我们今天分享的内容，也是如何在模型之外去更好的打造智能体的Harness。而心细的小伙伴们可以发现了下面的图中，我又多画了一个箭头，从Harness指向了Model，我个人认为，因为随着模型能力的越来越强，有些原本Harness上需要关注的技术点，都会被模型吞噬。所以智能体的架构，也应该是在持续精进，每次你智能体要换模型的时候，Harness必须都要重新评估一次。

二、企业级 Agent AI Native 架构

1、下面这张图中，左侧部分是从一个完整技术落地的视角，去呈现企业级智能体AI原生架构。但因为在画这张图的时候内容比较多，信息密度很大，整体有些小，所以为了方便大家看清楚，我把它的核心层级抽取成了下面右侧这张架构图。其整体是一个【7层架构+左右两侧2侧横切关注点】的架构设计。

2、先来对这七层架构设计进行详细的说明：

第一层：【业务应用层】。这一层是与智能体交互的终端应用程序，形态上可以是Chatbot，也可以是plugin等形式。

第二层：【应用网关层】。这一层是我们开发传统应用背后的网关层，主要负责流量的集中治理，核心功能包含了负载均衡、路由转发、鉴权等。

第三层：【Agent核心层】。这一层主要是使用各种技术手段构建智能体，例如选用什么智能体框架，用什么方式构建智能体，记忆体系如何设计等。

第四层：【AI网关层】，也可以叫做大模型网关层，它的作用是对大模型的调用进行统一管理，实现语义路由、语义缓存、Token配额等。

第五层：【大模型层】。这一层就是对各类大模型进行集中管理。

第六层：【知识 & 数据层】。给智能体提供各类结构化与非结构化的数据，为智能体提供各类基础数据与所需知识。

第七层：【基础设施层】，提供智能体运行所需的各种底层能力。

3、左右两侧的横切关注点，始终贯穿着上面提到的7层架构：

左侧是【可观测性 & 评估】，除了传统的链路追踪外、我们更要关注跟大模型相关的一些专属指标，例如TTFT、Token用量等。此外，更要注重使用离线评估与在线评估相结合的方式，去评估智能体的输出质量。

右侧是【安全治理 & 合规】，它的作用是要确保智能体的输出可控、不越界、符合企业安全合规要求。

三、核心层设计与技术选型

1、这里我们先看一个非常关键的演进过程，大家现在也都有这个认识：从 Prompt，到 Context，再到 Agent Runtime。

最近几年大家也都能感受到，因为随着模型能力的提升，Prompt写的内容也越来越少，现在单纯掌握如何写好Prompt是远远不够的，重点在于，如何构建完整的上下文体系，优化信息内容，让模型在此刻看到应该看到的内容，既不多，也不少，所以组装好Context是至关重要的一个环节。最后Harness，它优化的是系统工程。整体这三者，是一个层层递进的包含关系。

2、接下来，我们先再来看看与上下文工程密切相关的四层记忆体系。

第一层：【工作记忆】，也就是短期记忆。它存储的是当前会话中任务的中间状态、工具返回值、推理步骤等。这部分是临时的，任务结束就会释放，一般存储在内存、关系型数据库、Key-Value数据库等。

第二层：【情景记忆】，也就是长期记忆。主要是跨会话进行持久化存储。例如历史对话、用户偏好、以及一些任务执行的轨迹等。通常存储在关系型数据库、非关系型数据库、向量数据库等。

第三层：【语义记忆】，长期记忆的一种。这一层可以简单理解为知识库。通常是存储在响量数据库或者结合知识图谱使用。

第四层：【程序性记忆】，也是长期记忆的一种。这一层偏“怎么做”，例如SOP流程、Workflow配置、以及Skill定义等。本质上是把经验沉淀成可执行能力。

3、然后我们重点来说说知识库，现在构建知识库虽然有其他方式，但是主流知识库的实现方式还是以RAG为主。其中去年一个重大的飞跃，是从传统的RAG（Naive RAG 和 Advanced RAG）进化为了更加智能化的RAG（Agentic RAG），本质上是从固定Pipeline方式，变成了动态决策检索的方式，并且这两者往往结合起来使用，使知识库检索更加灵活。最后，如果知识中存在大量的实体关系，可以考虑引入知识图谱，增强检索的推理能力。

4、接下来是智能体架构的推理范式，分别从单智能体架构（Single-Agent）与多智能体写协作（Multi-Agent）这两个方向去考虑。具体内容就不详细说明了，大家可以参考之前写的这篇文章《常见的Single-Agent三种推理范式与Multi-Agent四种协作模式》。下面放一下对应页的PPT截图。

5、接下来是是MCP与Skills，这页内容比较多，主要是流程层面，但是核心思想非常简单，需要有一个注册中心的概念（也可以认为是能力仓库的概念）。本质上，就是需要把业务能力和外部工具统一封装成Skill，注入到能力注册中心，智能体在后续运行过程中，再通过MCP协议进行统一发现和调用。大家可以参照下面的详细流程。

6、接下来是双网关治理，应用网关与AI网关，前面也已经介绍过了，这里我们重点关注下二者如何结合使用的。请求路径上，请求先进入应用Gateway，再做分流：传统API请求走业务服务，与智能体和大模型相关的请求可以进入到AI Gateway进行后续处理。重点关注下民的流程图即可。

7、安全防御层面，通常分为输入侧防御和输出侧防御。

输入侧：除了大家熟知的 Prompt 注入和越狱攻击外，尤其要关注对敏感信息和越权调用问题的处理。

输出侧：最头疼的毫无疑问是幻觉问题，我们只能通过RAG溯源和事实校验等方式来减轻幻觉。最后输出的内容，同样需要进行有害内容、敏感信息、合规性等层面的过滤。

8、可观测性与评估层面，这里重点关注下评估吧。前面也提到过了，重点在于自动化离线评估与在线评估相结合的方式。其中在线评估，可以通过用户线上点赞点踩等显示信号；重试率、放弃率等隐式信号，形成一个持续优化的闭环。

四、落地实战

1、企业智能体落地时，建议遵循下面这三阶段演进：

第一阶段：试点验证阶段，也就是MVP阶段。先把Agent跑通，并且接入必要的链路追踪。

第二阶段：平台化阶段。场景变多时，可以考虑把一些公共的智能体能力抽象成服务，接入 AI Gateway 统一治理，并构建评估流水线。

第三阶段：规模化阶段。使用 Multi-Agent 编排处理复杂流程，使智能体平台成为组织级的基础设施。

2、具体切入时，我总结了这五个步骤：锁定痛点明确、数据可用的场景，比如高频的客服或文档问答。在跑通最小闭环时，千万记得同步接入可观测性，别裸奔就上线了。然后是我最看重的第三步：建立评估基线。一定要把评估集成进 CI/CD，用数据驱动迭代，而不是凭经验调试Prompt。最后通过AI Gateway实现统一治理，并把稳定复用的逻辑沉淀为能力单元，为后续的跨团队复用打好基础。

3、项目案例踩坑说明，这里就不详细说明了。大家可以详细参照下面的PPT截图进行解读。

4、智能体开发框架选型，我把它分成了四个维度，分别是：代码框架、低代码平台、模型厂商SDK、云厂商 Agent 服务。因为现在开发智能体的生态非常繁荣，大家可以根据业务复杂度和团队现状，在灵活性和交付速度之间找平衡，选择合适的AI技术去进行构建。

5、这一章节的最后，总结一下工程实践经验和质量保障层面。现在做AI Native应用，最大的挑战在于它的不确定性，输出结果经常会出现抽卡的现象。所以，我们的工程思维，也必须从传统的测试驱动转向评估驱动（EDD）。例如在开发侧，考虑对Prompt进行版本管理，使用SDD+TDD方式进行开发、测试与评估。在验证侧，做好回归测试门禁，必须跑自动化评估，分数低于基线就直接阻断上线。

五、总结与展望

1、回顾整个企业级Agent的建设，总结了五项核心设计原则：可观测性优先、人机协同分级、评估驱动迭代、协议标准化、渐进式演进。

2、具体落地时，我有三点建议。

首先，锁定一个场景，在数周或几天内跑通最小闭环。无论用Dify也好、LangChain也好，搭建起RAG + 单体Agent，同步接入可观测性。目的是让团队和业务方看到真实的边界，消除那些过高或过低的预期。

其次，建立AI网关。即使只有一个Agent，也要通过AI网关统一调用。把路由、配额和安全护栏做起来，把成本可视化，从一开始就建立起成本和安全的底线意识。

最后，把评估流水线集成进CI/CD。为核心场景建立 50 到 100 条标注用例，配合大模型评判跑自动化评估，分数低于基线就阻断上线，让质量迭代由数据支撑。

3、无论现在企业处于【AI能力集成】、还是【AI原生重构】阶段、又或是已经进入【AI驱动范式变革】阶段。每个阶段都有独立的商业价值，哪怕先做好 Copilot 阶段，效果也已足够显著。AI Native不是推倒重来，而是在已有架构上渐进式生长，我们架构师最大的价值，就是在现在这个AI技术快速变革的时代下，让这个过程可控、可观测、可演进。

（正文完）