03 · Agent System
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：领域总览（覆盖 01 Fundamentals、02 Technical Architecture、03 Engineering & Governance）
文档类型：领域概述
版本：v1.0
更新日期：2026 年 10 月 28 日
核心问题：Agent System 作为支撑一个或多个 Agent 执行任务的软件系统，应如何定义和研究？它由哪些技术组件与运行机制构成？如何从系统基础认知、技术架构、工程与治理三个层次，建立完整、可靠、安全、可观测且可验证的 Agent System 技术知识体系？
一、领域概述：研究的究竟是什么？
Agent System（智能体系统）是围绕一个或多个 Agent 的任务执行而组织的软件系统。它将 Agent 的决策与行动能力，同执行引擎、任务管理、模型与工具服务、状态管理、外部环境及必要的工程控制机制结合起来，使 Agent 能够在明确的运行条件和约束下完成任务。
Agent System 的核心研究问题是：
如何将 Agent 的能力组织为可执行、可管理、可观察、可恢复并能够持续改进的软件系统？
在前一个领域 「02 · Agent」 中，我们主要研究 Agent 如何围绕目标组织信息、进行决策、选择行动并利用反馈推进任务。
进入 Agent System 后，研究对象发生了变化。
例如，一个研究助理 Agent 可以根据任务目标决定检索资料、阅读文档和生成报告。但要让它在真实软件环境中稳定运行，还需要解决一系列系统级问题：任务如何创建与调度，执行器如何调用模型和工具，任务状态如何保存，多个 Agent 如何通信与协作，执行失败后如何恢复，权限和资源如何控制，以及如何观察和评估整个执行过程。
这些问题共同构成 Agent System 的研究范围。
本领域主要关注现代模型驱动型 Agent System，但其中许多技术机制并非 Agent 独有。任务队列、工作流引擎、数据库、分布式调度、容器隔离、事件驱动架构和可观测性等技术，早已存在于传统软件工程中。
Agent System 的特殊性，在于这些技术需要支持包含模型决策、动态行动、外部工具调用和不确定性行为的任务执行过程。
1.1 Agent System 不等于 Multi-Agent System
Agent System 可以支持一个 Agent，也可以支持多个 Agent。
单个 Agent 如果需要独立的执行引擎、任务状态管理、工具服务、持久化、监控和恢复机制，同样可以构成完整的 Agent System。
多个 Agent 之间的协作则进一步引入任务分配、消息传递、共享状态、协作协议、冲突处理和结果整合等问题。
因此，Multi-Agent System（多智能体系统）是 Agent System 的一种重要组织形态，但不是 Agent System 成立的必要条件。
1.2 Agent System 不等于 Agent Framework
Agent Framework 通常是帮助开发者构建 Agent 或 Agent System 的软件框架。
它可能提供模型接口、工具抽象、状态管理、执行循环、任务编排和扩展机制。
Agent System 则是一个具体的系统级运行整体，可以使用一个或多个框架构建，也可以采用自研实现。
因此，框架是可能使用的技术手段，系统是实际研究和运行的对象。
1.3 Agent System 不一定需要复杂的分布式架构
一个 Agent System 可以运行在单个进程中，也可以由多个服务、容器和计算节点共同构成。
是否采用微服务、消息队列、分布式任务调度或独立执行集群，应由任务规模、并发要求、可靠性目标和工程成本决定。
系统完整性不等于架构复杂度。
对于简单任务，一个具有明确执行控制、状态管理和失败处理机制的单进程系统，可能比复杂的分布式架构更加合适。
本领域不预设某一种部署方式为标准答案，而是研究不同架构在具体条件下的适用性。
二、Agent System 在全栈技术体系中的位置
《Agent 全栈技术地图》将相关知识组织为四个主要领域。这是一种研究对象与技术职责的划分，不要求实际产品必须拆分为四套独立软件。
| 领域 | 主要研究对象 | 核心问题 |
|---|---|---|
| 01 · AI | 模型、推断、模型工程、知识与检索等基础技术 | 智能能力从哪里来，如何构建、调用与利用？ |
| 02 · Agent | 单个智能体的逻辑实体、能力组织和任务行为 | 如何将基础技术组织为面向目标的决策与行动？ |
| 03 · Agent System | 支撑 Agent 执行任务的软件系统及其工程机制 | 如何执行、编排、管理、恢复和保障 Agent 的运行？ |
| 04 · Agent Platform | 可复用的 Agent 创建、运行与管理平台 | 如何将 Agent System 的能力组织为可配置、可运营的平台产品？ |
四个领域之间的主要知识关系可以表示为：
01 · AI
模型、推理、模型接口与知识技术
│
│ 提供基础智能能力
▼
02 · Agent
目标、决策、行动、反馈与行为边界
│
│ 需要运行支撑
▼
03 · Agent System
执行引擎、任务编排、状态服务
运行基础设施、可靠性与系统治理
│
│ 可以进一步平台化
▼
04 · Agent Platform
Agent 创建、配置、发布、运行
监控、管理与平台运营这张图描述主要知识依赖，不表示严格的单向调用关系。
Agent 可以直接运行在普通应用程序中，不必依赖专门的 Agent Platform。Agent System 可以只运行一个 Agent，也可以管理多个 Agent。Agent Platform 则可能同时提供模型服务、工具管理、工作流、执行引擎和系统治理等跨领域能力。
划分的关键是研究问题的归属。
例如，模型如何生成结构化工具调用请求，主要属于 AI 的 Model Engineering；Agent 为什么选择某个工具、如何根据结果调整行动，主要属于 Agent；系统如何执行工具、隔离环境、管理超时、保存状态和恢复任务，主要属于 Agent System；平台如何让不同用户统一配置、发布和管理工具，则属于 Agent Platform。
相同的软件模块可能在不同领域被研究，但研究对象、技术职责和抽象层次应当有所区别。
三、Agent System 的整体运行模型
为了避免将 Agent System 简化为“多个 Agent + Workflow”，本领域采用一个由任务、执行、协调、状态、资源、反馈和系统控制构成的运行模型。
这一模型用于解释系统如何将任务请求转化为实际执行过程，以及如何在运行中维持可控性和可靠性。
3.1 七个核心运行要素
**任务（Task）**定义系统需要完成的工作，包括输入、目标、输出要求、执行条件、优先级、截止时间和完成判据。
**执行（Execution）**负责将任务转化为实际运行过程，包括 Agent 实例的启动、模型调用、工具执行、状态更新和终止。
**协调（Coordination）**负责组织任务之间、Agent 之间以及不同执行组件之间的关系，包括任务依赖、消息传递、调度、协作和结果整合。
**状态（State）**记录系统运行过程中的必要信息，包括任务进度、执行上下文、阶段结果、检查点和运行状态。
**资源（Resources）**提供执行所需的模型、工具、计算环境、数据存储和外部服务，并受到配额、预算和访问权限的限制。
**反馈（Feedback）**包含执行结果、工具返回、错误事件、状态变化和质量评价，为后续执行、恢复和系统改进提供依据。
**系统控制（System Control）**负责执行约束，包括授权、预算、超时、取消、审批、失败处理和终止判断。
这些要素共同形成 Agent System 的基本运行过程。
3.2 系统运行过程
用户 / 外部系统
│
▼
任务请求
│
▼
任务接收与初始化
│
▼
任务管理与调度
│
▼
Agent Engine / Runtime
│
┌─────────┴─────────┐
│ │
▼ ▼
Agent 决策 系统执行控制
│ 权限 / 预算
│ 超时 / 审批
└─────────┬─────────┘
│
▼
执行模型与工具
│
▼
获取执行结果
│
▼
更新状态与执行记录
│
┌────────┴────────┐
│ │
继续执行 满足终止条件
│ │
▼ ▼
下一轮任务 交付结果在整个执行过程中，系统可能持续使用状态存储、消息队列、模型服务、工具服务和监控系统。
这是一种概念性运行模型，不代表所有 Agent System 都必须采用相同的软件结构。
简单系统可能直接在应用进程中执行任务；复杂系统可能通过消息队列和多个 Worker 分配任务；事件驱动系统可能在等待外部消息时暂停；多 Agent 系统可能通过编排器或协作协议协调多个执行主体。
不同架构的共同问题是：任务由谁控制、执行由谁承担、状态在哪里保存、失败如何处理，以及系统如何判断任务已经完成。
3.3 Agent 决策与系统执行的关系
Agent System 中需要区分两个容易混淆的概念：Agent 的行动决策与系统的执行控制。
Agent 的行动决策回答：下一步应该做什么？
系统的执行控制回答：这个行动是否允许执行、由什么组件执行、使用哪些资源、失败后如何处理？
例如，研究 Agent 决定调用网页搜索工具。这个决策可能由模型根据任务目标产生，但实际执行仍需要系统检查工具权限、验证参数、发起请求、处理超时，并将结果返回给 Agent。
模型产生行动意图，并不意味着外部操作已经发生。
这一边界对于理解 Agent Runtime、Tool Gateway、权限控制和系统可靠性具有基础意义。
四、Agent System 的整体技术架构
本知识库在 Technical Architecture 中设置六个技术层级：
L1 · Infrastructure
L2 · Platform Services
L3 · Model Services
L4 · Agent Engine
L5 · Orchestration & Collaboration
L6 · Application这六个层级用于组织系统能力与技术研究，不要求实际软件严格按照六层部署，也不意味着所有调用都必须逐层经过。
4.1 六个技术层级
| 层级 | 技术领域 | 主要职责 | 典型技术对象 |
|---|---|---|---|
| L1 | Infrastructure | 提供计算、网络、存储和隔离环境 | 服务器、容器、虚拟机、网络、存储 |
| L2 | Platform Services | 提供通用基础软件服务 | 数据库、缓存、消息队列、对象存储、身份服务 |
| L3 | Model Services | 统一接入和管理模型能力 | Model Gateway、API Adapter、Routing、Rate Limiting |
| L4 | Agent Engine | 驱动 Agent 实际执行任务 | Runtime、Execution Loop、Task Runner、State Machine |
| L5 | Orchestration & Collaboration | 组织任务和多个 Agent 的协作 | Workflow Engine、Scheduler、Message Bus、Coordinator |
| L6 | Application | 将系统能力提供给用户和外部应用 | API、Web Application、SDK、Webhook、External Integration |
4.2 技术层级之间的关系
┌──────────────────────────────────────────────┐
│ L6 · Application │
│ 用户界面 / API / SDK / 外部系统集成 │
├──────────────────────────────────────────────┤
│ L5 · Orchestration & Collaboration │
│ 任务编排 / 调度 / Agent 协作 / 消息传递 │
├──────────────────────────────────────────────┤
│ L4 · Agent Engine │
│ Agent Runtime / 执行循环 / 状态机 / 任务实例 │
├──────────────────────────────────────────────┤
│ L3 · Model Services │
│ 模型网关 / 模型路由 / API 适配 / 调用控制 │
├──────────────────────────────────────────────┤
│ L2 · Platform Services │
│ 数据库 / 缓存 / 队列 / 对象存储 / 身份服务 │
├──────────────────────────────────────────────┤
│ L1 · Infrastructure │
│ 计算 / 网络 / 存储 / 容器 / 隔离环境 │
└──────────────────────────────────────────────┘这是一张能力组织图，而不是严格的软件调用栈。
例如，L4 Agent Engine 可能直接访问 L2 的数据库或消息队列；L5 Orchestration 可能调用多个 L4 Runtime；L3 Model Services 可以被 Agent Engine 直接调用，也可以被其他应用服务使用。
在实际系统中，安全、可观测性、配置管理、可靠性和资源控制等能力还会横跨多个技术层级。
因此，本知识库采用两个互补的研究视角：
Technical Architecture 研究系统由哪些技术能力构成，以及这些能力如何协同。
Engineering & Governance 研究如何保障这些能力在真实运行条件下持续满足质量、安全和管理要求。
4.3 技术架构与工程能力的区别
技术组件是系统能够运行的基础，但组件存在并不意味着系统具备相应的工程质量。
例如，系统使用数据库，不代表任务状态能够正确恢复；系统使用消息队列，不代表任务不会重复执行；系统具有日志，不代表能够定位一次 Agent 执行失败的原因；系统配置了工具权限，也不代表所有外部操作都经过可信授权。
因此，研究技术架构时，不能只回答“系统用了什么”，还必须解释“它如何工作、如何验证，以及在什么条件下失效”。
五、知识结构：三个章节、二十四篇专题
Agent System 领域采用三个章节、二十四篇专题的研究结构：
三个章节分别对应系统基础认知、技术实现架构，以及系统级工程质量与治理机制。
5.1 01 · Agent System 是什么？它如何工作？ - Fundamentals
本章研究 Agent System 的定义、组成、运行机制、系统类型、完整性与成熟度，以及整体架构设计原则。
它的任务是建立系统级认知，解释 Agent System 与 Agent、Agent Harness、Workflow Engine、Multi-Agent System 和 Agent Platform 等概念之间的关系。
| 编号 | 专题 | 主要研究问题 |
|---|---|---|
| 01 | Definition & Boundaries | Agent System 如何定义？与 Agent、Harness、Workflow、Platform 的边界是什么？ |
| 02 | Core Components | Agent System 由哪些核心功能职责与技术组件构成？ |
| 03 | Execution Mechanism | 任务如何进入系统、被执行、更新状态并最终完成？ |
| 04 | System Types | 单 Agent、多 Agent、工作流驱动、事件驱动等系统如何分类？ |
| 05 | Completeness & Maturity | 如何判断系统是否完整？不同工程成熟度如何评价？ |
| 06 | Architecture & Design Principles | 如何根据任务、规模和质量要求选择系统架构？ |
本章需要特别区分三个概念：
Core Components 研究系统需要哪些功能职责和技术部分。
Execution Mechanism 研究这些部分如何在运行过程中形成任务执行、反馈和状态变化。
Architecture & Design Principles 研究如何组织组件、划分边界，以及不同设计方案的适用条件。
三者相互关联，但不能重复写成三份组件清单。
5.2 02 · Agent System 是如何构建和运行的？ - Technical Architecture
本章深入研究构成 Agent System 的六个主要技术层级，重点关注具体运行机制、接口协议、数据结构、控制流、状态流、技术路线和工程取舍。
| 编号 | 专题 | 主要研究问题 |
|---|---|---|
| L1 | Infrastructure | Agent System 需要怎样的计算、网络、存储与隔离环境？ |
| L2 | Platform Services | 数据库、队列、缓存、对象存储和身份服务如何支持 Agent 执行？ |
| L3 | Model Services | 如何统一接入、路由、限制和管理不同 AI 模型？ |
| L4 | Agent Engine | Agent 如何被实例化、驱动、执行、暂停和终止？ |
| L5 | Orchestration & Collaboration | 如何组织任务依赖、调度执行并协调多个 Agent？ |
| L6 | Application | 如何通过 API、SDK、应用界面和外部集成提供系统能力？ |
这一章是 Agent System 的核心技术研究部分。
例如，L4 · Agent Engine 不应停留在解释 Runtime 是什么，而应深入研究执行循环、任务状态机、模型与工具适配、执行事件、异常传播、暂停恢复接口以及不同 Runtime 架构的实现差异。
L5 · Orchestration & Collaboration 则应深入研究任务图、调度算法、Agent 通信协议、消息语义、共享状态、任务依赖、协作模式和失败传播机制。
L1、L2 和 L3 也不应重复介绍通用基础设施或 AI 模型知识，而应聚焦这些技术在 Agent System 中承担的具体职责、运行约束和架构选择。
5.3 03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
本章研究 Agent System 的系统级质量属性、运行保障与治理机制。
它不仅关注系统能否完成任务，还关注系统在并发、故障、资源限制、外部副作用和长期运行条件下，能否保持可靠、安全、可观察和可控制。
| 编号 | 专题 | 主要研究问题 |
|---|---|---|
| H1 | Observability | 如何记录、追踪、关联和诊断 Agent System 的运行行为？ |
| H2 | Security | 如何实现身份认证、授权、执行隔离和安全防护？ |
| H3 | Evaluation | 如何评价系统级任务质量、执行效率与可靠性？ |
| H4 | State Management | 如何保存、管理、恢复系统状态并处理一致性问题？ |
| H5 | Configuration | 如何管理配置、环境差异、版本及其生效过程？ |
| H6 | Human-in-the-Loop | 如何实现人工审批、暂停、接管、修改与恢复？ |
| H7 | Reliability | 如何处理重试、幂等、故障隔离和系统恢复？ |
| H8 | Resource Management | 如何管理并发、配额、计算资源、调用成本与预算？ |
| H9 | Data Governance | 如何管理数据访问、存储、保留、删除与生命周期？ |
| H10 | Testing & Validation | 如何开展系统集成、端到端、故障注入和回归验证？ |
| H11 | Deployment & Operations | 如何部署、发布、扩缩容、监控、回滚和运维系统？ |
| H12 | Policy & Governance | 如何制定、执行、审计和持续改进系统治理策略？ |
这一章的十二个专题并非相互独立的功能模块。
例如，H4 · State Management 与 H7 · Reliability 存在直接关系。任务恢复不仅需要保存状态，还需要处理外部操作是否已经执行、重复执行是否安全，以及状态恢复与工具副作用之间的一致性。
H2 · Security 与 H12 · Policy & Governance 也存在联系。Security 研究具体的安全机制及其技术实现，Policy & Governance 则进一步研究策略如何定义、分发、执行、审计和维护。
H3 · Evaluation 与 H10 · Testing & Validation 的分工在于：前者主要研究评价目标、指标、基准和系统质量判断；后者研究如何通过测试环境、测试方法和验证流程获得可靠证据。
各专题应围绕自身的核心技术问题深入研究，避免在每篇文章中重复通用安全、治理和检查清单。
六、贯穿案例：从研究助理 Agent 到完整 Agent System
本领域继续使用“技术研究助理”作为跨章节的贯穿案例，以保持与 「02 · Agent」 领域的研究连续性。
设定用户任务为：研究某项 AI 技术，检索可靠来源，分析主要实现方案，生成具有证据支持的技术报告，并允许用户查看任务进度、提出修改意见或中途暂停。
在 Agent 领域，我们主要研究研究助理如何理解任务、组织上下文、选择工具、判断证据是否充分，以及如何生成最终结果。
进入 Agent System 后，我们进一步研究：如何构建一个能够承载、调度、协调、观察和恢复研究任务的软件系统。
6.1 从单个 Agent 到系统级运行
一个简单的研究 Agent 可能在单个进程中完成检索和报告生成。
但当用户希望同时运行多个研究任务，或要求任务持续数小时、支持中断恢复、人工审批与多 Agent 分工时，就需要进一步考虑系统级能力。
例如，一个研究任务可能包含：
用户提交研究需求
│
▼
任务服务创建 Research Task
│
▼
调度器分配执行资源
│
▼
研究 Agent 开始执行
│
├── 检索资料
├── 阅读与整理证据
├── 分析技术方案
└── 生成研究报告
│
▼
系统记录执行状态与结果
│
▼
质量审核与人工确认
│
▼
报告交付与任务归档如果任务采用多 Agent 协作架构，还可能进一步划分为检索 Agent、分析 Agent、写作 Agent 和审核 Agent。
但这种划分必须根据任务复杂度、协作收益和工程成本决定，不能仅因为任务存在多个阶段，就认为必须创建多个 Agent。
6.2 三个章节如何研究同一个案例？
Fundamentals 研究整个研究系统的定义、核心组件、任务执行机制、系统类型与架构原则，判断单 Agent、工作流或多 Agent 方案分别适合什么条件。
Technical Architecture 研究研究系统如何使用计算环境、数据库、消息队列、模型网关、Agent Runtime、任务编排器和应用接口，并深入解释组件之间的数据流、控制流与状态变化。
Engineering & Governance 研究任务失败后如何恢复、用户如何暂停或接管、如何追踪一次研究任务、如何控制模型调用成本、如何隔离不同任务的数据，以及如何通过系统级测试验证可靠性。
贯穿案例的主要作用，是让抽象的系统架构能够对应具体的工程问题。
例如，“支持任务恢复”不能只意味着数据库中存在一条任务记录，还需要说明：系统在什么时刻保存检查点，恢复时如何判断已经完成的步骤，如何避免重复调用具有副作用的工具，以及恢复后的状态是否仍然满足任务契约。
6.3 不同任务类型的对照研究
研究助理案例并不能覆盖所有 Agent System 的工程要求。
因此，各专题还应根据研究对象引入其他类型的系统作为对照。
| 系统类型 | 典型任务 | 需要重点研究的问题 |
|---|---|---|
| 研究 Agent System | 检索、分析、报告生成 | 长任务、证据管理、状态恢复、质量审核 |
| 编程 Agent System | 仓库分析、代码修改、测试 | 沙箱隔离、文件系统、命令执行、故障恢复 |
| 浏览器 Agent System | 网页操作、表单填写、流程办理 | 动态环境、外部副作用、权限审批 |
| 数据分析 Agent System | 数据查询、计算、分析报告 | 数据权限、查询执行、资源隔离、结果验证 |
| 多 Agent 协作系统 | 任务分工、并行研究、协同交付 | 编排、通信、共享状态、冲突与一致性 |
这些案例的价值在于揭示不同系统的共同机制与差异化约束，而不是建立一套适用于所有场景的固定架构。
七、研究边界：Agent System 与相邻领域如何分工
Agent System 与 AI、Agent、Agent Platform 存在技术交集。
领域边界应依据研究问题和技术职责划分，而不是根据代码仓库、框架名称或部署方式划分。
7.1 Agent 与 Agent System
| 共同技术主题 | Agent 领域关注 | Agent System 领域关注 |
|---|---|---|
| 执行循环 | Agent 如何选择行动并利用反馈 | 执行循环如何被驱动、调度和恢复 |
| 工具调用 | 工具如何参与任务决策 | 工具如何执行、隔离、限时和监控 |
| 状态 | 哪些信息影响 Agent 的后续行为 | 状态如何持久化、同步和恢复 |
| 规划 | Agent 如何分解任务并调整计划 | 任务依赖如何调度和编排 |
| 生命周期 | Agent 定义、实例与行为状态的关系 | 实例如何启动、暂停、恢复和终止 |
| 权限 | Agent 可以选择哪些行动 | 系统如何强制执行授权和审计 |
| 测试 | Agent 的任务质量与行为能力 | 系统的可靠性、集成行为与故障恢复 |
例如，Agent 的 Memory 研究什么信息值得记住、如何检索和利用；Agent System 的 State Management 更关注执行状态的持久化、一致性和恢复。
两者可能使用同一个数据库，但研究的信息语义与工程问题不同。
7.2 Agent Harness 与 Agent System
Agent Harness 是现代 Agent 工程中经常使用的概念，但不同项目和技术社区对其范围并没有完全统一的定义。
在本知识库中，Agent Harness 可以理解为：围绕 Agent 执行过程建立的一组运行支撑与控制机制，用于组织模型调用、工具使用、上下文、执行反馈、约束和验证。
它通常与 Agent Runtime、执行循环、工具网关、上下文管理和测试机制存在密切关系。
Agent System 的研究范围则可以进一步覆盖任务调度、多个 Agent 协作、共享基础服务、系统状态、可靠性、资源管理和运维治理。
因此，两者存在交集，但不应简单视为同义词。
| 比较维度 | Agent Harness | Agent System |
|---|---|---|
| 主要关注 | Agent 的执行支撑与控制机制 | 完整的系统级运行与协作 |
| 常见研究对象 | 执行循环、工具、上下文、约束、反馈 | Runtime、任务服务、编排、状态、基础设施 |
| 典型范围 | 单 Agent 执行环境及其控制机制 | 单 Agent 或多 Agent 的完整运行系统 |
| 工程重点 | 让 Agent 按预期执行并受到约束 | 让任务能够持续、可靠、可管理地运行 |
| 二者关系 | 可以作为系统中的重要组成部分 | 可以包含 Harness 及其他系统服务 |
这种区分是本知识库采用的工作定义，不意味着行业存在唯一标准。
在具体项目中，Harness 也可能包含编排、持久化和运行管理等较大范围的功能，因此实际分析时仍需依据项目的真实架构判断。
7.3 Agent System 与 Agent Platform
Agent System 主要研究系统如何运行。
Agent Platform 进一步研究如何将这些能力组织为面向用户、开发者或组织的可复用产品。
| 比较维度 | Agent System | Agent Platform |
|---|---|---|
| 核心目标 | 执行和保障 Agent 任务 | 提供可创建、配置、运行和管理 Agent 的平台 |
| 主要对象 | Runtime、任务、编排、状态和系统服务 | Builder、Registry、Workspace、控制平面 |
| 主要关注 | 执行机制、可靠性、安全、资源与恢复 | 产品功能、平台管理、用户体验与运营 |
| 使用方式 | 可以作为独立应用的后端系统 | 通常面向多个 Agent、项目或使用者 |
| 技术关系 | 提供运行能力 | 可以复用或封装 Agent System 的能力 |
Agent Platform 不是 Agent System 的必然发展阶段。
一个专门服务于特定业务的 Agent System，可能长期以独立系统形式运行，并不需要建设通用平台。
只有当创建、配置、发布、管理和复用 Agent 的需求达到一定程度时，平台化才可能产生足够的工程与产品价值。
八、研究方法：从技术组件到系统级工程机制
本领域沿用《Agent 全栈技术地图》的深度研究原则，强调机制优先、真实工程依据、可复现验证和明确的技术边界。
研究不应止于解释某种技术是什么，还应尽可能深入其实际运行机制、关键数据结构、算法选择、组件接口、信息流、状态变化、工程实现和局限。
8.1 六层研究逻辑
| 研究层次 | 研究重点 | 核心检验问题 |
|---|---|---|
| L1 · Concepts | 概念、背景、问题与边界 | 为什么需要这种系统能力？ |
| L2 · Mechanisms | 技术机制、算法与执行过程 | 输入如何经过处理产生状态和结果？ |
| L3 · Architecture | 组件、接口、协议与数据结构 | 系统各部分如何协作？ |
| L4 · Research | 原始论文、开源框架与技术路线 | 现有方案如何实现，有何差异？ |
| L5 · Engineering | 具体实现、最小实验与系统实践 | 能否构建、运行、复现并验证？ |
| L6 · Evaluation | 失败模式、可靠性、性能与取舍 | 在什么条件下有效或失效？ |
六层研究逻辑用于保证技术深度，不要求每篇文章机械采用完全相同的标题或篇幅。
不同专题应根据核心技术问题调整研究重点。
例如，Infrastructure 应重点研究执行环境、资源隔离和部署架构；Agent Engine 应重点研究执行循环、状态机、任务实例与运行时机制；Orchestration 应重点研究任务图、调度、通信和协作协议；Reliability 应重点研究故障模型、重试、幂等、恢复和一致性。
8.2 真实工程研究优先
本领域应优先使用官方技术文档、原始论文、开源项目源码和可复现的工程实验作为研究依据。
对于具体框架或系统，应尽可能明确其版本、核心模块、实际接口和运行路径。
例如，研究 Agent Engine 时，可以对比不同框架的执行模型、状态表示、工具调用机制和恢复方式，但不能仅凭框架介绍推断其内部实现。
研究结论应区分四种性质：
**资料事实：**能够由指定文档、论文或源码支持的事实。
**综合判断：**根据多个资料和技术机制形成的分析结论。
**设计方案：**为特定问题提出的架构或工程实现建议。
**实验结果：**在明确环境和条件下实际运行并得到的观察结果。
未实际验证的接口行为、运行结果和性能指标，不应写成已经验证的事实。
8.3 系统级验证不能只看任务是否完成
Agent System 的评价需要同时考虑任务质量和系统行为。
例如，一个研究任务最终生成了正确报告，但执行过程中发生重复扣费、越权访问、状态丢失或无法恢复，仍不能认为系统整体达到了工程要求。
系统级评价可能涉及：
| 评价维度 | 典型研究问题 |
|---|---|
| 功能正确性 | 任务是否按契约完成？ |
| 执行可靠性 | 失败、超时或中断后能否正确处理？ |
| 状态一致性 | 状态与外部操作是否保持合理一致？ |
| 安全与权限 | 是否发生未授权操作或数据访问？ |
| 可观测性 | 能否定位执行过程与失败原因？ |
| 性能 | 延迟、吞吐量和并发能力如何？ |
| 资源效率 | 模型、计算和工具成本是否可控？ |
| 可维护性 | 配置、版本、部署和升级是否可管理？ |
具体指标应由系统的任务契约、风险条件和服务目标决定，不存在适用于所有 Agent System 的单一综合分数。
8.4 实验与工程实践的要求
对于 Agent Engine、Orchestration、State Management、Reliability 等技术专题，应优先设计能够体现真实运行机制的工程实验。
实验可以从最小可运行实现开始，但需要明确其验证目标。
例如，研究任务恢复时，不能仅通过保存和读取 JSON 文件证明系统具备可靠恢复能力，还应考虑执行中断、检查点位置、重复调用、外部副作用和恢复后的状态一致性。
研究消息队列时，不能仅展示消息发送和接收，还应研究投递语义、确认机制、重复消费、失败重试和任务幂等。
模拟实验可以用于解释机制，但不能替代真实服务、真实模型和实际运行条件下的验证。
九、学习成果：从理解 Agent 到具备系统架构能力
完成本领域三个章节、二十四篇专题后，读者应建立以下能力。
9.1 系统认知能力
能够准确解释 Agent System 的定义及其与 Agent、Agent Harness、Multi-Agent System、Workflow Engine 和 Agent Platform 的关系。
能够区分 Agent 的行为决策与系统的执行控制，理解系统运行所需的任务、状态、资源、协调和反馈机制。
9.2 技术架构能力
能够根据任务需求识别必要的基础设施、基础服务、模型服务、Agent Engine、编排机制和应用接口。
能够绘制 Agent System 的逻辑架构、组件关系、数据流、控制流和状态流，并解释不同架构方案的技术取舍。
9.3 工程实现能力
能够理解并实现基本的任务执行、状态管理、模型调用、工具执行和任务编排机制。
能够根据实际需求判断何时需要消息队列、持久化、独立 Worker、执行隔离、分布式调度或多 Agent 协作。
9.4 可靠性与治理能力
能够分析系统在超时、失败、重试、重复执行、资源耗尽和外部服务异常情况下的行为。
能够设计必要的状态恢复、权限控制、人工审批、监控追踪和系统级测试机制。
9.5 技术研究与判断能力
能够阅读真实 Agent System 框架或开源项目，追踪关键实现机制，比较不同架构的适用条件。
能够通过源码、实验和测试证据判断系统设计是否合理，而不是仅凭框架功能或项目宣传作出结论。
本领域所追求的能力，不是能够列举二十四个专题名称，而是能够面对一个具体的 Agent 应用需求，解释它需要怎样的运行系统、为什么选择某种架构、关键技术如何实现、风险在哪里，以及如何验证系统能够可靠运行。
十、后续研究：从 Agent System 到 Agent Platform
完成 Agent System 领域后，下一步进入：
04 · Agent Platform - Agent 平台与应用体系。
研究重点将从系统执行与运行保障，进一步扩展到平台化的创建、配置、管理、发布和运营能力。
例如，在 Agent System 中，我们研究 Agent Runtime 如何执行任务、任务状态如何保存、多个 Agent 如何协作，以及系统如何恢复故障。
进入 Agent Platform 后，我们将进一步研究：用户如何通过 Agent Builder 创建 Agent，平台如何保存 Agent 定义，如何管理版本与实例，如何统一配置模型和工具，如何提供工作空间，以及如何通过控制平面和执行平面管理大量 Agent 任务。
Agent Platform 的研究将分为四个章节：
| 章节 | 研究重点 |
|---|---|
| 01 · Fundamentals | 平台定义、组成、类型、生命周期与设计原则 |
| 02 · Technical Architecture | Control Plane、Execution Plane、Registry、Builder、Runtime Management 等技术架构 |
| 03 · Product Architecture | Agent 创建、配置、工作空间、执行、协作、监控和管理等产品功能 |
| 04 · Engineering & Practice | 平台案例、技术选型、系统设计、开发路线、部署与优化 |
这条研究路径并不意味着所有 Agent System 都必须发展为 Agent Platform。
它提供的是一种从单个 Agent 的能力与行为，逐步扩展到系统运行机制，再到平台化产品体系的知识组织方式。
十一、领域研究目标
以现代模型驱动型 Agent System 为主要研究对象，建立从系统基础认知、技术架构到工程与治理的完整技术知识体系。
理解 Agent System 如何围绕任务组织执行、协调、状态、资源、反馈和系统控制；理解基础设施、基础服务、模型服务、Agent Engine、任务编排与应用接口如何共同支撑 Agent 运行；深入研究可观测性、安全、评估、状态管理、可靠性、资源管理、测试、部署和治理等系统级工程机制。
最终能够根据具体任务需求，设计、构建、分析和评估一个可运行、可管理、可观察、可恢复的 Agent System，并准确识别其与 AI、Agent、Agent Harness 和 Agent Platform 的技术边界，为后续 Agent Platform 的技术架构与产品研究奠定基础。
十二、研究说明
本文是《Agent 全栈技术地图》Agent System 领域的组织与研究框架，不是某个 Agent System 产品或技术方案的性能评测。
文中的七要素运行模型、六层技术架构和领域边界，是为了支持系统学习、技术分析与工程设计而采用的综合性研究框架，不代表行业存在唯一标准的 Agent System 架构。
不同系统可以采用单进程、模块化单体、微服务、事件驱动或分布式架构，也可以使用固定工作流、动态 Agent 或混合执行机制。
具体架构应根据任务需求、运行规模、风险条件、可靠性目标和工程成本选择。
本领域后续各专题将进一步研究具体技术原理、实际框架实现、工程实验和验证方法。涉及特定框架、接口、版本或性能的结论，以专题正文中明确记录的来源和验证结果为准。
本领域的核心研究原则是：以系统运行机制为中心，以真实工程实现为依据，以可复现的验证建立技术判断，而不是以组件数量、框架功能或架构复杂度衡量 Agent System 的成熟程度。