企业级Agent系统整体技术架构介绍

一、为什么企业级 Agent 需要分层架构？

随着大语言模型（LLM）技术的发展，Agent 正在从简单的智能对话工具，逐渐发展为能够理解任务、制定计划、调用工具、执行操作并交付结果的智能应用。

例如，一个企业营销 Agent 可以根据用户提出的目标，自动分析市场、搜索行业资料、生成营销方案、撰写公众号文章、制作小红书文案，最后将内容整理为可供团队审核的交付物。

但如果要真正实现这样的系统，仅仅接入一个大模型是不够的。

企业级 Agent 还需要解决很多工程问题：

• 如何统一接入不同的大语言模型？
• 如何让 Agent 使用数据库、搜索引擎和企业业务系统？
• 如何让 Agent 将复杂任务拆分为多个步骤？
• 如何管理对话、任务状态、长期记忆和知识库？
• 如何支持长时间运行、失败重试和中断恢复？
• 如何限制 Agent 的操作权限，防止误操作？
• 如何追踪执行过程、评估结果质量并控制成本？

如果把所有功能都写在一个 Agent 程序中，系统很快就会变得复杂：模型调用与业务逻辑混在一起，工具之间相互依赖，任务状态难以管理，安全策略也很难统一维护。

因此，我们需要通过分层架构，将不同职责的技术组件组织起来。

对于企业级 Agent，可以先采用一个简单容易理解的五层架构：

1. 基础设施与运行环境层
2. 数据与集成服务层
3. 模型与上下文智能层
4. Agent 智能执行与编排层
5. 应用与交互层

五层架构图如下。

除此之外，还需要一个贯穿全部五层的横向治理层，负责安全、权限、可观测性、评估测试、审计、成本和运维。

需要注意，五层的分层架构并不意味着系统只能有五个模块。它只是从整体上归纳职责，实际开发时，每一层还可以继续拆分。

(图片由 AI 生成)

二、企业级 Agent 五层总体架构

1. 第一层 L1：基础设施与运行环境层

这一层解决的问题是：Agent 在什么环境中运行？

Agent 本质上还是运行在计算机上的软件程序。它需要 CPU、内存、网络、文件系统以及其他运行资源。

如果 Agent 需要运行代码、处理文件或执行自动化任务，还需要更加安全的运行环境。

这一层通常包括以下组件：

• 计算资源。 提供云服务器、物理服务器或本地计算资源。对于需要运行大型模型的场景，还可能需要 GPU。

• 容器与 Kubernetes。 容器用于封装应用及其运行依赖，减少不同环境之间的差异。Kubernetes 则可以帮助企业管理容器部署、扩缩容和故障恢复。

• 沙箱环境。 当 Agent 需要执行 Python、JavaScript 或 Shell 代码时，可以通过沙箱限制其能够访问的文件、网络和系统资源，降低错误操作带来的风险。

• 网络与密钥管理。 负责网络访问、服务连接、API 密钥和其他敏感凭证的安全管理。

举个例子：

用户要求 Agent 分析一份 Excel 文件，并生成统计报告。Agent 可能需要读取文件、执行 Python 代码、生成图片和保存报告。这些操作最终都需要依赖底层的计算资源、文件系统和运行环境。

因此，基础设施层为 Agent 提供可靠、安全的运行基础。

不过，实际开发的 V1 版本阶段不一定需要部署 Kubernetes。对于规模较小的应用，可以先使用单机部署、Docker 和受限执行环境，等到出现明确的扩展需求后再升级。

2. 第二层 L2：数据与集成服务层

这一层解决的问题是：Agent 的数据存在哪里？它如何连接外部系统？

Agent 不可能只依赖当前对话中的文字工作。企业中的数据可能分布在数据库、文件系统、业务软件和第三方服务中。

因此，需要建立统一的数据与集成服务。

主要包括以下组件。

• 关系数据库。 保存用户、工作空间、对话、任务、任务步骤、权限配置和执行记录等结构化数据。例如，可以使用 PostgreSQL 或 MySQL。

• 向量数据库。 用于存储向量表示，并根据语义相似度检索相关内容。它常用于知识库问答、文档检索和长期记忆检索。

• 对象存储。 用于保存图片、视频、音频、文档、生成报告等文件。可以使用兼容 S3 的对象存储或企业内部文件服务。

• 消息队列与任务队列。 用于处理异步任务。例如，用户提交一个需要运行十分钟的研究任务后，系统不必让 HTTP 请求一直等待，而是可以将任务交给后台 Worker 执行。

• MCP 与企业业务 API。 用于连接外部工具和业务系统。MCP 提供一种标准化的模型上下文工具与资源连接协议；企业业务 API 则可以连接 ERP、CRM、OA 等系统。

需要特别区分：MCP 并不替代数据库、业务 API 或消息队列。它主要解决 Agent 如何以标准化方式发现和使用外部能力的问题。

例如，一个销售 Agent 需要查询客户资料、分析历史订单并生成跟进建议。它可以通过业务 API 查询 CRM，通过数据库读取业务数据，再将结果交给模型分析。

数据与集成服务层为 Agent 提供访问企业数据和外部能力的基础。

3. 第三层 L3：模型与上下文智能层

这一层解决的问题是：Agent 如何调用模型，以及如何为模型准备正确的信息？

大语言模型是 Agent 的重要组成部分，但模型并不是整个 Agent 系统。

模型负责理解输入、生成内容、提出工具调用请求等；模型之外，还需要一套机制管理模型选择、提示词、上下文和知识。

这一层可以划分为六类主要能力。

• LLM Gateway：模型统一接入网关。

企业可能同时使用不同供应商的模型，也可能在本地运行开源模型。模型网关可以提供统一的调用接口，避免业务代码直接依赖某一个模型供应商。

• Model Router：模型路由。

不同任务对模型能力的要求不同。例如，简单分类可以使用成本较低的模型，复杂分析可以使用能力更强的模型，多模态任务则需要支持图像或音频的模型。

模型路由可以根据任务类型、能力要求、延迟、价格和可用性选择合适的模型。

• Prompt：提示词管理。

提示词用于向模型说明任务目标、输出格式、行为约束和相关背景。企业系统通常需要对提示词进行版本管理、测试和迭代，而不是将所有提示词直接写死在代码中。

• Context Engineering：上下文工程。

上下文工程关注的是如何选择、组织和控制提供给模型的信息。

例如，用户要求分析一份营销计划时，系统可能需要组合用户当前指令、历史对话、项目背景、品牌规范和相关资料，同时避免把无关信息全部塞进模型上下文。

• Memory：记忆管理。

短期记忆通常用于保存当前会话和任务执行过程中的信息；长期记忆则可以保存经过筛选的用户偏好、项目背景和可复用经验。

记忆并不意味着永久保存所有对话。企业系统需要管理记忆的创建、更新、检索、过期和删除。

• RAG：检索增强生成。

RAG 通过检索相关文档，将检索结果提供给模型作为参考，帮助模型利用企业知识库回答问题。

例如，Agent 回答企业内部制度问题时，可以先检索相关制度文档，再基于检索结果组织答案，并提供来源引用。

需要注意，RAG 与 Memory 并不完全相同：RAG 更强调从知识资料中检索相关信息，Memory 更强调保存和使用与用户个性、会话、执行任务有关的语义、状态和经验。两者可以共享底层存储和检索技术。

4. 第四层 L4：Agent 智能体运行与编排层

这一层是整个 Agent 系统的核心，解决的问题是：如何将大模型的"智能理解"转化为真正的任务执行？

普通聊天系统通常只需要接收输入、调用大模型 API 并返回文本。

Agent 系统则需要持续执行一个过程：理解目标、决定下一步行动、调用工具、观察执行结果，再决定继续执行还是结束任务。

这一层主要包括以下组件：

• Agent Runtime：Agent 运行时。

Runtime 是 Agent 执行的控制中心，负责管理任务状态、执行循环、工具调用、事件产生和任务终止等。

它需要明确知道任务当前处于什么状态，以及下一步允许执行什么操作。

• Agent Loop：执行循环。

Loop 是 Agent 持续行动的基本机制。系统将当前上下文发送给模型，根据模型返回的结果决定下一步行动。

如果模型要求调用工具，系统就执行工具，并将结果交回模型；如果模型给出最终答案，系统则结束本轮任务。实际实现还需要最大步数、超时、错误处理和成本限制等机制。

• Planner：任务规划器。

当用户提出复杂目标时，Planner 可以将目标拆分为多个子任务。

例如，"制定一份新品营销计划"可以拆分为市场研究、用户分析、竞品分析、营销策略、内容创作和结果审核等步骤。

对于执行过程中出现的新情况，系统还可以通过 Replanner 调整计划。

• Tools 与 Skills：工具和技能。

Tools 工具是可以被调用的具体能力，例如搜索网页、读取文件、查询数据库和发送通知。

Skill 通常用于封装一套可复用的任务指导、流程知识和工具使用方法，例如"生成小红书营销方案"或"分析销售数据"。

两者的区别在于：

工具侧重可执行操作，技能侧重如何组织和完成某类工作。不同 Agent 框架对 Skill 的实现方式可能不同。

• Workflow：工作流编排。

对于流程相对固定的任务，可以使用工作流定义步骤、依赖、条件分支和失败处理。

例如，先获取数据，再进行计算，最后生成报告。

• Multi-Agent：多 Agent 协作。

对于复杂业务，可以将不同职责分配给不同 Agent。

例如，研究 Agent 负责收集资料，分析 Agent 负责分析数据，写作 Agent 负责生成内容，审核 Agent 负责检查质量。Supervisor 可以负责任务分解、分发和结果汇总，Worker Agent 则负责执行具体任务。

但并不是所有任务都需要多 Agent。简单任务使用单 Agent 往往更容易调试、开发更简单、成本也更低。

这一层将模型的智能能力组织成可执行、可管理、可验证的业务过程。

5. 第五层 L5：应用与交互层

这一层解决的问题是：用户如何使用 Agent，如何查看任务执行过程和最终成果？

企业级 Agent 不应只有一个聊天窗口，还需要围绕任务和业务结果构建完整的交互界面。

常见模块包括：

• Chat 对话界面。 用户可以通过自然语言提出需求，补充背景信息，并与 Agent 持续交流。

• Task 任务中心。 展示任务状态、执行进度、失败原因、执行记录和重试入口。对于长任务，用户可以离开页面后再回来查看结果。

• Workflow 工作流界面。 用于展示复杂任务的执行步骤、依赖关系、分支和运行状态。

• Artifact 产物中心。 保存 Agent 生成的文档、报告、代码、图片和其他成果，使结果可以被预览、编辑、下载或继续加工。

• 企业业务应用。 将 Agent 能力嵌入实际业务，例如营销内容生产、销售辅助、客户服务、数据分析和研发协作。

例如，在一个 AI 内容创作工作台中，用户可以在对话区提出"生成一份新品发布方案"。Agent 在后台执行研究、分析、写作等任务，右侧产物区域则实时展示方案草稿。用户可以继续修改内容，审批后再交付或发布。

因此，应用与交互层不仅负责展示模型回答，更负责将 Agent 的执行过程和最终成果转化为用户可以使用的业务价值。

三、横向治理层：为什么它贯穿全部五层？

前面五层主要回答系统由哪些能力组成，而横向治理层回答的是：这些能力如何安全、可靠、可控地运行？

企业环境中，Agent 可能读取敏感资料、执行外部操作、调用付费模型，甚至修改业务数据。因此，安全和治理不能只在系统上线时补充，而应从架构设计阶段就考虑。

横向治理包含六类能力

1. 安全与权限。

负责身份认证、角色权限、租户隔离、工具授权、策略校验和人工审批。

例如，Agent 可以查询客户信息，但只有获得相应授权后才能修改客户资料。涉及删除数据、对外发送消息或执行付款等高风险操作时，可以要求人工确认。

2. 可观测性。

通过日志、指标和分布式追踪记录任务执行过程，包括模型调用、工具调用、执行耗时、失败原因和资源消耗。

这样，当 Agent 运行失败时，开发人员可以定位问题，而不是只能看到一个"执行失败"的提示。

3. 评估与测试。

通过单元测试、集成测试、任务回归测试和模型评估，检查 Agent 是否正确完成任务。

例如，可以建立一组标准营销任务，评估生成内容的完整性、事实准确性、格式合规性和工具调用正确率。

4. 审计与合规。

记录关键操作、权限判断、人工审批和数据访问事件，便于问题追踪和合规检查。

对于敏感数据，还需要实施脱敏、访问控制、保留期限管理等措施。

5. 成本治理。

统计模型 Token 用量、模型调用次数、任务执行时长和工具成本，并设置预算、配额和告警。

例如，当一个任务持续循环调用模型时，系统可以通过最大执行步数和成本上限阻止无休止消耗。

6. 运维管理。

负责服务健康检查、部署、扩缩容、版本管理、故障恢复和告警。

需要强调的是，治理并不是简单地把六个模块放在图的右侧。它们需要在实际执行路径中生效。例如，权限检查必须发生在受保护的工具执行之前，Tracing 必须贯穿模型调用和工具执行过程。

简化的 5 层和横向治理架构图

简化的 5 层+横向治理的Agent整体架构图，直观理解上面所涉及的技术栈：

四、一次 Agent 任务是如何运行的？

以"分析销售数据并生成经营报告"为例，可以将系统运行过程分为六步。

第一步，用户在应用界面提交任务，系统创建 Task 和对应的 Session，并检查用户权限。

第二步，Runtime 加载任务状态、相关对话历史和业务知识，将它们整理为适合当前任务的上下文。

第三步，Planner 将目标拆分为读取销售数据、计算关键指标、分析趋势和生成报告等步骤。

第四步，Agent 调用模型，根据模型返回的工具调用请求，访问数据库或执行数据分析代码。工具执行前需要进行权限和策略检查。

第五步，Agent 根据工具返回的结果继续推理。如果数据不完整，可以补充查询；如果分析结果不符合要求，可以调整计划或重新执行相关步骤。

第六步，系统验证报告内容，将最终产物保存到存储系统，更新任务状态，并通过事件流通知前端展示结果。

在这个过程中，Runtime 管理执行状态，模型与上下文层提供推理能力，数据与集成层提供业务数据，基础设施层提供运行环境，而横向治理层负责权限控制、审计、追踪和成本管理。

这就是五层架构协同工作的基本方式。

五、如何从五层架构逐步建设企业级 Agent？

对于从零开始开发 Agent 平台的团队，建议采用逐步演进的方式，而不是一次性建设所有组件。

第一阶段：打通最小执行链路。

实现模型调用、Agent Loop、工具注册中心、Session、Task 和基础持久化。先让一个 Agent 能够接收任务、调用工具并返回结果。

第二阶段：增强可靠性。

加入异步任务队列、Worker、超时、重试、取消、暂停恢复、事件流和基础权限控制，让系统可以稳定运行长任务。

第三阶段：建设知识和规划能力。

增加 Memory、RAG、Context Engineering、Planner、Replanner 和结果验证机制，使 Agent 能够处理复杂任务。

第四阶段：扩展企业集成与协作。

接入 MCP、企业业务 API、Workflow 和多 Agent 协作，逐步实现多租户、细粒度授权和统一治理。

第五阶段：完善评估与运营体系。

建设执行追踪、质量评估、成本分析、故障告警和版本管理，让系统能够持续改进。

在工程实现上，五层架构不意味着必须部署五个独立服务。V1 可以采用模块化单体加独立 Worker 的形式，明确模块接口与数据边界；当系统规模、部署需求和团队协作方式发生变化时，再考虑拆分微服务。

六、总结

企业级 Agent 的本质，不是简单地给大语言模型增加一个聊天界面，而是构建一套能够理解目标、组织上下文、执行工具、管理任务状态、协同外部系统并持续交付结果的软件系统。

五层总体架构可以帮助我们从全局理解这一系统：

• 基础设施与运行环境层，解决运行和资源隔离问题。
• 数据与集成服务层，解决数据存储和外部系统连接问题。
• 模型与上下文智能层，解决模型接入、知识检索和上下文管理问题。
• Agent 智能执行与编排层，解决规划、执行、工具调用和协作问题。
• 应用与交互层，解决用户操作、任务管理和成果交付问题。

横向治理层则为整个系统提供安全、权限、可观测性、评估、审计、成本和运维保障。

对于实际开发，最重要的不是追求架构图有多少层，而是让每个模块具有清晰的职责、稳定的接口和可验证的行为。先构建一条可靠的 Agent 执行链路，再逐步增加规划、记忆、工作流、多 Agent 和企业治理能力，通常是更稳妥的工程路径。

当这些能力形成完整体系时，Agent 才能从一个能够回答问题的模型应用，逐渐发展为可以真正参与企业业务流程的智能执行系统。

文章修改发布在 github 上：https://github.com/jiujuan/ai-agent-notebook