huaAgentStudyAgent

外观

zmh.life

02 · Agent System 是如何构建和运行的？ - Technical Architecture ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：02 · Agent System 是如何构建和运行的？ - Technical Architecture
文档类型：技术架构章节概述与研究导读
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：一个 Agent System 如何从运行资源、基础软件、模型服务、Agent 执行引擎、任务编排与应用接口逐层构建为可工作的软件系统？各层承担什么职责、通过什么契约交互、如何组织控制流、数据流和状态流，又如何依据不同部署规模与可靠性要求进行技术选型和工程验证？

专题导读 ​

本章属 Agent System。Fundamentals 已经回答 Agent System 的定义、构成、运行机制、系统类型、完整性与架构原则。本章进一步把这些概念转换为可实施的软件系统：计算与网络资源如何承载任务，基础服务如何支持身份、配置与存储，模型如何被统一调用，Agent Engine 如何驱动决策与行动，编排层如何协调任务，应用层如何让用户与其他系统安全地使用这些能力。

本章采用 L1 - L6 六层技术架构作为研究和沟通模型，而不是宣称所有 Agent System 必须按六个独立服务部署。一个本地单 Agent 可以将六层的部分职责放在同一个进程中；一个团队级系统也可能把同一职责拆成多个服务。层级的价值在于明确责任、接口、依赖与故障归属，不在于增加技术组件数量。

贯穿案例为“技术研究助理 Agent System”：接收研究问题，调用模型与授权资料工具，保存研究证据，必要时并行开展子任务，最后交付可追溯的研究成果。通过同一个案例观察从个人本地原型到可运维服务的演进，区分最小可用实现与生产级工程约束。六个专题将各自深入技术机制、代表性方案、接口与工程实践；本篇负责建立全章的系统视图、研究问题和共同验证标准，不替代各专题正文。

一、研究定位与章节边界 ​

1.1 本章研究什么 ​

本章聚焦 Agent System 的技术实现结构：部署和运行所需的资源、基础服务、模型接入、Agent 执行、任务协调以及面向用户的能力交付。核心研究对象是“软件如何组织并运行”，而不只是模型能做什么。

需要区分三个视角：

  • 逻辑架构：系统必须承担哪些职责，职责之间是什么依赖关系。
  • 运行架构：请求、决策、工具调用、事件、状态和结果在运行中如何流转。
  • 部署架构：这些职责具体放在哪些进程、容器、主机或云服务中。

三者不能简单一一对应：逻辑上的 Model Services 可以是远程 API，物理上不在自有基础设施内；逻辑上的 Platform Services 也可能只是本地 SQLite、配置文件与日志库。

1.2 与相邻章节的关系 ​

Fundamentals 负责定义和系统级设计判断；本章负责六个技术层的组成、接口和实现机制。后续 Engineering & Governance 则横向研究 Observability、Security、Evaluation、State Management、Configuration、Human-in-the-Loop、Reliability、Resource Management、Data Governance、Testing & Validation、Deployment & Operations、Policy & Governance。横向治理不是“等 L1 - L6 建好再补上”的第七层，而是贯穿所有层的设计约束。

例如，L4 需要保存执行状态，但状态一致性与恢复策略将由 H4 进一步系统研究；L2 提供鉴权与审计支撑，但完整威胁模型与治理机制属于 H2/H12。专题应说明接口与关键机制，并将跨层问题指向后续章节，避免重复铺陈。

二、六层技术架构：职责与边界 ​

层级名称核心责任关键边界
L1Infrastructure计算、进程、网络、存储和隔离提供运行资源，不决定 Agent 策略
L2Platform Services身份、配置、数据、消息及公共支撑服务提供通用能力，不直接代替执行决策
L3Model Services模型接入、请求适配、路由和用量记录提供模型推理，不直接执行外部动作
L4Agent Engine决策循环、上下文组装、工具执行控制管理单次 Agent 运行，不天然负责跨任务编排
L5Orchestration & Collaboration任务依赖、调度、协作、交接与聚合协调执行单元，不取代其内部推理
L6ApplicationAPI、交互、任务提交、结果交付与集成暴露产品能力，不应绕过下层授权

六层是分析框架，不是强制的网络调用链。实际请求可能从 L6 直接触发 L4；L4 调用 L3 并经受控工具网关访问 L2 支持的资源；L5 只在需要复杂任务协调时介入。模型调用也可能经过 L2 的网络代理或凭据服务。不能因为编号顺序就假定每次请求严格穿过六个独立组件。

2.1 L1 · Infrastructure：系统运行在什么环境中 ​

研究 CPU、内存、GPU、进程/协程、容器/虚拟机、沙箱、网络与存储的基础条件；比较本地机器、单机服务器、托管容器和多节点执行环境。重点不是罗列云产品，而是建立负载特征 - 资源需求 - 隔离级别 - 成本 - 故障域之间的关系。对于调用外部模型 API 的系统，模型推理算力通常位于供应商一侧，本地资源仍要承担上下文处理、工具执行、文件处理与并发管理。

2.2 L2 · Platform Services：哪些公共能力需要被复用 ​

研究身份认证与授权、配置与密钥、结构化数据与对象存储、缓存、消息传递、任务队列、服务发现、时间与事件、审计与监控基础服务。应特别区分必需的功能与可选的独立中间件：最小系统可能只需内存状态和文件存储；并发与跨进程恢复要求提升后才可能引入数据库、队列和持久化执行记录。服务的选择应由一致性、可用性、访问控制和恢复要求驱动。

2.3 L3 · Model Services：如何接入并治理模型调用 ​

研究模型提供方适配、消息与工具调用协议、结构化输出、流式响应、重试与限流、路由与回退、用量及成本记录、模型版本与上下文窗口管理。模型产生动作建议，不代表该动作已经获准或执行。 L3 可以规范化模型输出，实际授权和工具副作用必须在可信执行边界落实。模型供应商的响应特性与 API 版本会变化，技术专题需按研究日期核验官方文档。

2.4 L4 · Agent Engine：如何驱动一次 Agent 执行 ​

研究 Agent 定义、Run/Step、上下文构造、推理 - 行动 - 反馈循环、工具调用网关、终止条件、状态更新、暂停/恢复和执行事件。需区分 Agent 的决策逻辑与 Runtime 的执行控制：前者决定“建议做什么”，后者负责“能否做、怎样做、何时停止、留下什么证据”。对于外部副作用，不能仅依赖模型文本来保证权限或幂等。

2.5 L5 · Orchestration & Collaboration：如何组织复杂任务 ​

研究任务图、依赖调度、并发、扇出/聚合、Agent 交接、角色分工、共享状态与消息、失败传播和补偿策略。多 Agent 不是使用编排层的前提：单 Agent 的多阶段任务也可能需要工作流编排；反过来，简单单 Agent 系统不必独立部署编排服务。应比较固定工作流、动态规划、事件驱动和混合编排的复杂度与可控性。

2.6 L6 · Application：如何形成可使用的产品能力 ​

研究用户与系统 API、会话与任务提交、进度展示、人工审批、产物交付、Webhook/SDK、租户与访问边界、前后端职责划分。应用层的重点是把系统能力变成可理解、可调用、可追踪的产品契约，而不是简单等同于网页 UI。无界面但具有稳定 API 的服务同样可以构成应用层。

三、整体架构与跨层交互 ​

3.1 参考逻辑图 ​

mermaid
flowchart TB
    U[用户 / 外部系统] --> A[L6 Application: API / UI / 交付]
    A --> O[L5 Orchestration: 任务协调（可选）]
    A --> E[L4 Agent Engine: Run / Step / Tool Gateway]
    O --> E
    E --> M[L3 Model Services: 适配 / 路由 / 用量]
    E --> P[L2 Platform Services: 状态 / 身份 / 配置 / 数据]
    O --> P
    A --> P
    I[L1 Infrastructure: 计算 / 网络 / 存储 / 隔离] -.承载.-> A
    I -.承载.-> O
    I -.承载.-> E
    I -.承载.-> P
    T[外部工具与数据源] <--> E

图中 L1 的“承载”是部署关系，不代表每次请求都通过 L1 的某个 API；L3 可能是外部模型供应商。实际实现中工具访问应经过可信网关，并对外部资源施加访问限制。

3.2 一次研究任务的端到端路径 ​

  1. 用户在 L6 提交任务，系统验证输入与身份，创建可追踪的任务标识。
  2. 简单任务直接启动 L4；复杂任务由 L5 拆分依赖、分配执行单元。
  3. L4 从 L2 读取授权配置与必要状态，组装上下文，通过 L3 请求模型。
  4. 模型返回内容或工具调用意图；L4 在可信边界校验工具、参数、预算和审批条件。
  5. 工具执行后返回结果，L4 更新运行状态与证据记录；必要时重复决策循环。
  6. L5 汇总多个执行单元的结果并处理依赖失败；L6 展示状态并交付最终产物。

三类流应分开建模：控制流说明谁触发谁、谁有权取消；数据流说明输入、证据、产物和模型上下文如何移动；状态流说明 Task、Run、Step 和审批状态由谁持有及如何恢复。把三者混为一张流程图，会掩盖权限和一致性问题。

3.3 跨层接口的最小契约 ​

契约关键字段主要不变量
Tasktask_id、目标、输入、约束可关联身份和验收条件
Runrun_id、task_id、状态、版本终止原因可解释
ModelRequest消息、模型、工具声明、预算不含未经授权的敏感数据
ToolCallcall_id、工具、参数、身份执行前授权，副作用可追踪
Eventevent_id、run_id、类型、时间事件可关联因果和版本
Artifactartifact_id、来源、校验摘要可追溯到任务和证据

这是一组教学性参考字段，并非统一行业协议。不同框架的实际接口可能不同；后续专题应对照具体 SDK、API 与存储模式解释字段映射。

四、架构的最小实现与演进路径 ​

4.1 最小可运行系统 ​

一个本地研究助理可以采用单进程 Python 应用：命令行接收任务（L6），函数调用执行 Agent 循环（L4），HTTP 客户端接入远程模型（L3），本地文件或 SQLite 保存必要数据（L2），运行于个人电脑（L1）。如果任务不涉及多步骤依赖或多个执行单元，L5 可以只表现为简单的顺序调用，而不需要独立编排器。该系统是否构成 Agent System，仍取决于 Agent 行为和执行机制，而非六层是否各有一个类。

4.2 团队级服务 ​

当任务需要多人访问、持续运行和审计时，可加入服务端 API、持久化任务与执行记录、权限管理、后台 Worker、限流、队列、监控和人工审批。此时首先要解决状态所有权、任务去重、凭据隔离、外部副作用和失败恢复，而不是立即采用微服务。

4.3 多 Worker 与分布式执行 ​

当任务量或隔离需求上升时，可分离 API、调度器、Worker 和持久化存储。新问题包括消息至少一次投递、重复执行、租约与心跳、任务取消传播、分布式追踪和部分故障。部署扩展不自动提升任务质量，且可能增加一致性和运维成本。必须以实际负载、可靠性目标和故障演练结果支持扩展决策。

五、六篇专题的研究任务 ​

L1 · Agent System 需要怎样的运行环境？ - Infrastructure ​

回答运行负载、资源容量、操作系统、容器与沙箱、网络、存储、隔离和部署边界。形成从任务需求推导基础设施方案的能力。已完成的 L1 专题属于本章，位置应排在本章节概述之后。

L2 · Agent System 需要哪些基础软件服务？ - Platform Services ​

研究身份/授权、配置/密钥、数据存储、消息与队列、缓存、事件与时间、基础观测服务。重点回答“何时需要独立服务、接口如何约束、失败由谁处理”，避免中间件清单式介绍。

L3 · Agent System 如何接入和管理 AI 模型？ - Model Services ​

研究模型 API 适配、工具调用协议、结构化输出、流式执行、模型路由、版本、配额、成本与回退。重点分析模型输出与可信执行之间的边界。

L4 · Agent 如何被驱动并持续执行任务？ - Agent Engine ​

研究执行循环、Run/Step、上下文、工具网关、状态更新、终止、暂停与恢复。应给出可运行的最小实现和失败路径测试，并与 Fundamentals 的“运行机制”专题区分：前者解释通用机制，本篇深入具体引擎设计。

L5 · 如何编排任务并组织多个 Agent 协作？ - Orchestration & Collaboration ​

研究任务图、依赖、并发、交接、通信、聚合、补偿与故障传播。比较不同编排策略在复杂度、可控性、成本和可恢复性方面的取舍。

L6 · 如何将 Agent 能力提供给用户和其他系统？ - Application ​

研究 API、UI、会话与任务交付、进度订阅、审批交互、集成接口和用户体验。形成从执行能力到可使用产品的完整接口与状态设计。

六、贯穿案例：技术研究助理的分层实现 ​

阶段 A：个人原型。 用户提交一个研究问题；本地 Runner 通过模型 API 选择检索工具，记录来源并生成 Markdown。目标是验证任务契约、模型调用、工具授权、终止与结果可追溯。应先测正确性和失败路径，而非过早优化吞吐量。

阶段 B：持续运行的研究服务。 多个研究任务需要排队执行，用户能够查看进度、取消任务并恢复中断运行。引入持久化任务状态、后台执行和基础观测，建立工具调用 ID 与副作用记录。重点测试任务恢复、重复请求和权限边界。

阶段 C：多 Agent 研究 Studio。 选题、资料搜集、分析、审查和成稿形成有依赖的任务图。L5 负责阶段调度、审核返工和聚合，L4 负责各 Agent 的内部执行。引入人工审核节点和版本化产物，测试分支返工、并行失败、审批绕过与成本上限。

三个阶段的主要变化不是“模型越来越聪明”，而是任务契约、执行控制、协作复杂度与工程约束不断增强。是否升级应以需求和验证结果为依据。

七、研究方法与技术选型原则 ​

本章后续专题遵循五个共同要求。

  1. 先职责后产品：先定义问题与接口，再比较开源框架、云服务或自研方案；不得用某框架的模块命名替代通用概念。
  2. 先最小方案后扩展：说明最小可行实现，再解释引入数据库、消息队列、编排器、沙箱或分布式部署的触发条件。
  3. 机制与证据对应：官方文档用于确认接口与行为，源码用于解释实现细节，实验用于验证具体环境中的实际表现；三者不相互冒充。
  4. 控制与副作用分离：模型建议、权限决策、工具执行、持久化记录和用户审批必须能在架构中定位责任主体。
  5. 用故障检验架构：除了正常路径，还应检查超时、限流、工具故障、重复消息、执行中断、取消、状态损坏及越权请求。

7.1 技术方案比较的统一问题 ​

每项方案至少回答：它解决什么问题；适用于什么任务规模；引入哪些依赖；状态由谁持有；如何实施授权；如何处理失败和重复执行；如何观测与测试；迁移成本和退出成本是什么。比较应以明确的任务场景和验证条件为前提，避免无条件地推荐“最佳框架”。

7.2 工程验收的最低证据 ​

对于后续涉及代码或系统运行的专题，应说明运行环境、依赖版本、测试输入、执行命令、预期与实际输出、未覆盖路径。若只提供架构伪代码或推演，应明确标为未运行的设计示例。对于官方框架行为，应标明检索日期与相关版本；无法核验时明确保留不确定性。

八、研究结论 ​

Agent System 的技术架构可以从 L1 运行资源、L2 公共服务、L3 模型服务、L4 Agent 执行引擎、L5 任务编排协作和 L6 应用交付六个层次研究。该划分有助于把“Agent 会做什么”转化为“系统由谁负责、如何交互、怎样运行和如何验证”的工程问题。

最重要的架构判断是：逻辑分层不等于物理分布，组件齐全不等于系统可靠，模型能够提出行动不等于行动被授权执行。 系统复杂度应由任务、风险、规模和恢复要求驱动。任何层次的技术选择，都需要结合状态所有权、权限边界、故障模型和可复现证据进行评估。

本章的六篇专题将依次深入运行环境、基础服务、模型接入、Agent Engine、编排协作与应用交付。下一篇为 「L1 · Agent System 需要怎样的运行环境？ - Infrastructure」；该专题此前已经形成 v1.1 文档，可直接作为本章节概述之后的第一篇。

附录 A：参考资料与进一步研究入口 ​

以下列出适合本章后续核对的一手技术资料入口。它们用于支撑相关技术概念和后续专题研究，不表示本篇已逐项实时访问并核对其截至研究日的全部更新。

  1. OpenAI Agents SDK，运行循环、工具、交接与追踪：openai.github.io/openai-agents-python
  2. LangGraph 官方文档，持久化与可恢复执行：docs.langchain.com/oss/python/langgraph/overview
  3. Temporal 官方文档，工作流执行与持久化语义：docs.temporal.io
  4. Model Context Protocol 官方规范，模型与外部能力的交互协议：modelcontextprotocol.io/specification
  5. Docker 官方文档，容器运行与资源隔离：docs.docker.com
  6. Kubernetes 官方文档，工作负载与编排：kubernetes.io/docs
  7. OpenTelemetry 官方文档，分布式追踪、指标与日志：opentelemetry.io/docs
  8. OWASP GenAI Security Project，生成式 AI 应用安全风险：genai.owasp.org

附录 B：研究证据与验证声明 ​

  • 研究性质：本篇是章节概述与技术研究导读，不是具体框架的源码审计、生产架构验收或性能基准报告。
  • 分析框架：L1 - L6 是本知识库用于组织研究的逻辑分层；不宣称为统一行业标准，也不要求所有项目独立部署六层。
  • 架构示例：Mermaid 图、契约字段与三个阶段的研究助理案例属于工程参考设计，未在本篇进行端到端实现验证。
  • 来源状态：文末提供官方资料入口，但本篇未完成逐项实时联网核验；不得将其理解为已核对各项目截至 2026 年 10 月 28 日的最新 API、版本或行为。
  • 测试状态：本篇没有执行 Docker、Kubernetes、真实模型服务、分布式恢复或安全隔离测试，也没有提出未经验证的性能数值。
  • 后续验证：具体实现、测试记录、版本差异与工程证据应由 L1 - L6 各专题补充，并在发生重要技术更新时修订。