huaAgentStudyAgent

外观

zmh.life

01 · Agent System 是什么？它如何工作？ - Fundamentals ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：概念定义、系统边界与工程判据研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent System 如何定义与识别？一个或多个 Agent 如何依托任务、执行引擎、状态、工具、编排与系统控制完成工作？如何建立系统构成、运行机制、系统类型、完整性与架构原则的统一分析框架？

专题导读 ​

本章属 Agent System。Agent System 的定义决定了研究对象的边界：若把它等同于多 Agent 协作，会遗漏大量实际运行的单 Agent 应用；若把所有 LLM 调用都归为 Agent System，又会失去分析执行控制、行动反馈和状态管理的能力。本篇建立可操作的工作定义，并通过边界案例检验判据，而不是声称存在唯一的行业标准。

研究重点是区分 Agent 的决策职责与软件系统的执行职责，分析逻辑、信任、运行和状态边界，解释 Task、Run、Step 等对象如何支撑系统识别。结论为下一篇组件拆分提供前提；文中的判据是研究工具，必须接受反例检验。

一、章节定位：从 Agent 行为进入系统运行 ​

「02 · Agent」回答智能体怎样围绕目标组织信息、选择行动、利用反馈并约束行为。「03 · Agent System」则研究这些行为怎样成为真实软件系统中可以启动、执行、暂停、观察、恢复和交付的任务。研究对象从 Agent 的行为逻辑转向 Agent 及其运行依赖构成的系统整体。

一个研究助理 Agent 可以决定下一步检索什么资料，但系统还必须处理任务 ID、并发运行、模型请求、工具权限、执行记录、状态保存、用户取消、失败恢复和结果交付。模型能输出工具调用意图，不等于工具已经被执行；Agent 能生成计划，不等于计划可以在系统故障后可靠恢复。上述差别是本章的出发点。

本章以六个递进问题组织研究：定义边界 → 核心构成 → 运行机制 → 系统类型 → 完整性与成熟度 → 架构原则。这一顺序先确定研究对象，再解释构成和行为，最后形成判断与设计能力。六篇专题都允许深入机制、源码和最小实验，并非“导读只讲概念、后续才讲工程”的割裂安排。

二、工作定义与必要边界 ​

本知识库采用如下工作定义：Agent System 是围绕一个或多个 Agent 的目标导向任务，将其决策与行动机制同执行控制、运行资源、状态与外部交互组织为可工作的软件系统。 系统可采用单进程或分布式部署，可包含固定工作流或动态决策；不要求多个 Agent、长期记忆、独立消息队列、可视化管理界面或专用 Agent 框架。

定义中的关键不在组件数量，而在可识别的系统职责：①存在需要被执行的任务与相应 Agent 行为；②有实际承载模型/规则决策和行动执行的运行机制；③能与必要的模型、工具或环境交互；④有足以解释执行进展与结果的状态或反馈；⑤有与任务风险相匹配的控制和结束条件。这五项是本章提出的分析判据，不是业界统一的合规标准。低风险的短任务可以在内存中完成，长期或高风险任务才需要更强的持久化、审批、隔离与审计。

需要同时避免两个极端：一是将任何调用 LLM 的应用都称为 Agent System；二是要求只有包含编排器、消息队列和多个 Worker 的系统才算 Agent System。应先辨认 Agent 的目标与行动机制，再判断支撑它的系统边界。

2.1 与相邻概念的区别 ​

概念主要研究对象与 Agent System 的关系不能据此单独判定
AI Model计算输入并生成输出的模型可为 Agent 提供决策或生成能力使用 LLM 就是 Agent System
Agent目标、信息、决策、行动、反馈和行为约束系统承载的一个或多个行为主体一个 Agent 必须是独立进程
Agent Runtime / Engine驱动 Agent 执行的运行时机制通常是 Agent System 的核心部分有 Runtime 就具备完整工程治理
Agent Harness围绕执行的工具、上下文、控制和验证机制可与 Runtime 重叠，亦可成为系统子集Harness 与 Agent System 永远同义
Workflow Engine任务依赖、步骤调度和执行恢复可作为 Agent System 的编排基础有工作流就一定存在 Agent
Multi-Agent System多个 Agent 的交互或协作Agent System 的一种组织形式Agent System 必须多智能体
Agent Platform可复用的创建、配置、发布和管理能力可以在 Agent System 上形成平台化服务有 Web UI 就是平台

Harness 的特别说明： 不同技术生态对 Harness 的使用范围并不一致。部分官方技术文档将它定义为管理执行循环、模型调用、工具路由、审批、追踪和恢复的控制机制；因此不能以词面断言 Harness 一定比 Agent System 小。研究时应依据实际项目的模块职责与信任边界判断。[S1][S2]

三、系统整体的三个观察视角 ​

同一个 Agent System 可以从逻辑职责、执行过程、工程质量三个角度理解。这三种视角相互补充，不应混为一张静态组件图。

3.1 逻辑职责：系统需要负责什么 ​

职责要回答的问题可能的实现形式
任务契约要做什么、何时算完成Task、输入/输出 Schema、验收条件
Agent 决策下一步采取什么行动模型、规则、混合策略
执行控制谁执行、能否执行、何时停止Runner、Runtime、权限门禁、预算限制
外部交互如何访问模型、工具和环境Adapter、Tool Gateway、Sandbox
状态与反馈当前进度是什么、结果如何进入后续决策内存状态、事件日志、Checkpoint、数据库
协调与交付如何分配工作、管理依赖并交付结果Scheduler、Workflow、API、通知服务

这些是功能职责，而非必须各自部署的服务。一个单进程程序可以承担多项职责；复杂系统可以将它们拆分为多个服务。职责拆分是否合理，应以故障边界、权限边界、吞吐需求与维护成本验证。

3.2 执行过程：任务怎样真正推进 ​

text
用户 / 外部事件
      │
      ▼
接收任务与校验输入 ──→ 创建任务标识与初始状态
      │
      ▼
选择执行策略 / 分配执行资源
      │
      ▼
┌────────────── Agent Runtime ──────────────┐
│ 装配当前上下文与任务状态                    │
│             ↓                              │
│ 模型或规则生成下一步决策                    │
│             ↓                              │
│ 验证权限、预算、参数和审批条件              │
│             ↓                              │
│ 执行工具 / 交接 Agent / 生成结果             │
│             ↓                              │
│ 记录反馈、错误、事件与状态变化              │
│             ↓                              │
│ 继续 / 等待 / 重试 / 失败 / 终止             │
└───────────────────────────────────────────┘
      │
      ▼
结果校验、交付与归档

这是一种参考运行路径，并非固定执行顺序。例如，审批会让执行暂停，外部事件可能重新唤醒任务，多个步骤可能并行，调度器也可能不参与短任务。运行时真正重要的是能够追踪：谁拥有控制权、什么事件推动状态变化、哪些操作产生外部副作用、何时允许重试、何时应当终止。

3.3 工程质量：运行起来不等于运行可靠 ​

Agent System 的功能构成与质量保障需要分开研究。能调用工具不代表调用经过授权；能写入数据库不代表恢复正确；能重试不代表不会重复发邮件；能输出日志不代表可以重建任务的因果链。系统级可靠性、安全、可观测性、状态一致性、资源控制和运维能力将在本领域第三章 Engineering & Governance 深入展开。本章先建立质量维度及其与架构的联系，不提前展开十二篇工程专题。

四、运行机制中的五条关键技术分界线 ​

4.1 决策与执行分离 ​

模型或 Agent 可以提出 search(query) 的调用意图，但可信执行器负责检查工具是否存在、参数是否符合 Schema、调用是否获授权、超时与失败如何处理，并将结果以结构化反馈返回。模型输出不应直接等同于已授权的系统操作。OpenAI Agents SDK 的运行文档明确将模型输出检查、工具执行、Agent 交接与最终结果组织在 Runner 循环中。[S3]

4.2 任务状态与对话记忆分离 ​

对话消息可能只是执行状态的一部分。完整任务状态还可能包括步骤进度、待审批动作、工具调用标识、检查点、错误、预算和最终交付物。LangGraph 文档将线程级检查点与跨线程 Store 区分，说明执行连续性与长期信息存储具有不同语义。[S4] 恢复一段对话并不等于恢复一个带外部副作用的任务。

4.3 任务编排与 Agent 自主决策分离 ​

编排器决定任务节点的依赖、调度与交接；Agent 决策则在被允许的范围内选择下一步行动。两者可以混合：固定的「检索→审核→发布」工作流内部，某个研究节点可动态选择搜索策略。官方 Agent 编排文档区分了交接后由专家 Agent 接管与管理者调用专家作为工具两种控制权模式。[S5]

4.4 重试与业务幂等分离 ​

网络请求失败或 Worker 崩溃后，系统可能重新执行某项操作。但对于发邮件、扣费、修改生产数据等操作，重复执行可能产生不可逆后果。Temporal 的官方文档将工作流历史、Activity、超时和重试分开建模，体现了可靠执行必须面对外部副作用的现实。[S6][S7] 因此不能把「有 Retry」写成「保证恰好执行一次」。

4.5 逻辑架构与部署架构分离 ​

逻辑上可以区分任务服务、运行时、工具网关和状态存储，部署时却可能全部在一个进程中。反之，同一个逻辑 Runtime 也可能运行在多个 Worker 上。架构研究必须分别说明职责边界、数据边界、信任边界、故障边界、部署边界，而不能用一个层级图替代所有解释。

五、六篇专题的研究任务与深度分工 ​

01 · 什么是 Agent System？ - Definition & Boundaries ​

核心目标： 给出可操作的定义与识别方法，说明什么是 Agent System、什么不是，以及边界如何随研究视角变化。

重点问题： Agent 与系统如何区分；单 Agent 是否可以构成系统；Agent Harness、Runtime、Workflow Engine、Multi-Agent System、Agent Platform 各自的技术边界；如何判断系统责任与外部依赖。应形成的成果： 术语表、边界判定树、正反案例、典型反例及边界争议说明。避免重复： 不在此完整展开六层技术组件。

02 · Agent System 由什么构成？ - Core Components ​

核心目标： 识别完成任务所需的最小职责、可选能力与典型组件，以及组件之间的接口契约。

重点问题： Task、Agent Definition/Instance、Runner、Tool Adapter、Model Adapter、State Store、Scheduler、API 等对象的关系；哪些是必要职责，哪些依任务引入；组件与能力如何区分。应形成的成果： 逻辑组件图、职责矩阵、最小系统与扩展系统对照、关键接口示意。避免重复： 不将工程治理十二项全部列为最小必备组件。

03 · Agent System 如何运行？ - Execution Mechanism ​

核心目标： 从一次真实任务的生命周期解释控制流、数据流、状态流和失败路径。

重点问题： 创建、调度、启动、模型决策、工具调用、反馈、暂停、审批、恢复、完成与失败；执行事件与状态机；并行、异步和外部回调；终止与取消语义。应形成的成果： 时序图、状态转换表、正常/异常执行轨迹、可复现的最小状态机实验。避免重复： 不替代 L4 Runtime 的源码级实现研究。

04 · Agent System 有哪些类型？ - System Types ​

核心目标： 建立多维分类法，而非用单一标签列举框架。

分类维度建议： Agent 数量（单/多）、控制方式（固定工作流/动态决策/混合）、协作拓扑（集中/分布）、运行方式（同步/异步/事件驱动）、状态持久性（短暂/持久）、部署方式（单体/分布式）、人类介入程度。应形成的成果： 多维分类矩阵、典型架构对照、选型边界与反例。避免重复： 多 Agent 不等于分布式，事件驱动不等于自主 Agent。

05 · 怎样才算完整的 Agent System？ - Completeness & Maturity ​

核心目标： 区分概念成立的最低条件、面向任务的功能完整性，以及面向实际运营的工程成熟度。

建议的分析维度： 任务契约、可执行性、状态与结果可解释性、权限与风险匹配、故障处理、可观测性、测试证据、部署与运维。可提出「原型 - 可验证应用 - 受控生产 - 规模化运营」的研究性成熟度阶梯，但不应冒充通行标准，也不能把分布式、多 Agent、复杂审批当作所有场景的硬性门槛。应形成的成果： 场景化检查表、成熟度判定说明、验收证据矩阵。

06 · 如何理解 Agent System 的架构？ - Architecture & Design Principles ​

核心目标： 将前五篇形成的对象、机制与约束转化为系统设计原则。

重点问题： 职责与控制权边界、信任与权限边界、状态所有权、故障隔离、可恢复性、可观测性、扩展性与成本；单体/服务化、同步/异步、集中/分布、单 Agent/多 Agent 的选择依据。应形成的成果： 参考架构、关键设计决策记录（ADR）、架构评审问题清单与场景化选型。避免重复： 不把六层技术架构写成唯一正确的部署方式。

六、贯穿案例：技术研究任务的系统化执行 ​

沿用前一领域的「研究助理 Agent」，任务是研究某项技术，收集证据、比较方案并生成报告。本章增加三个系统级条件：任务可能持续较长时间；用户可以在审核前暂停或修改要求；工具和模型调用可能失败。 这三个条件足以暴露执行、状态、控制和恢复之间的关系，不必一开始引入多个 Agent。

6.1 最小系统方案 ​

一个应用进程提供 POST /tasks 接口创建任务，内部 Runner 调用研究 Agent、模型与检索工具，使用任务记录保存当前状态，并通过 GET /tasks/{id} 提供进度和结果。任务可以先串行执行。若任务短暂、低风险，内存状态也可用于教学实验，但进程重启后会丢失进度，应明确说明这一限制。

6.2 增强系统方案 ​

当任务需要中断恢复与审批时，可引入持久化状态、检查点、待审批动作记录和恢复接口。当并发任务增加时，可引入任务队列与 Worker。当任务包含检索、分析、审核等可分离职责时，可考虑工作流编排或多 Agent 协作。每次增强都应说明新增能力解决的实际问题、引入的复杂性和新的失败模式。

6.3 一次具体的故障场景 ​

研究 Agent 已调用搜索工具并取得结果，但在保存任务状态之前进程崩溃。恢复后系统无法仅凭内存判断搜索是否成功，可能重复调用。若是只读检索，重复执行主要带来成本与延迟；若换成「发布报告」或「发送通知」，重复操作就可能造成业务问题。此时需要考虑调用标识、操作幂等、检查点时机和外部系统的确认语义。这说明「任务恢复」是一个跨越 Agent Engine、State Management 和 Reliability 的系统问题，而非简单的文件读写。

6.4 用案例串联六篇专题 ​

专题在研究助理系统中要回答的问题可验证证据
Definition & Boundaries哪些行为属于 Agent，哪些属于系统？系统边界图、职责说明
Core Components最小系统需要哪些接口和状态对象？组件图、接口契约
Execution Mechanism一次任务如何启动、暂停、恢复、终止？状态轨迹、时序图
System Types为什么选单 Agent + 工作流，而非多 Agent？对照实验或决策记录
Completeness & Maturity该系统能否用于真实业务？缺什么证据？场景验收矩阵
Architecture & Design Principles怎样在风险、成本、复杂度之间取舍？ADR、故障场景评审

七、真实技术体系的对照研究 ​

本章不将框架名称当作系统类型，而是把公开技术实现作为检验概念的样本。以下事实依据检索到的官方资料；它们用于说明设计空间，不构成当前版本的性能排名或完整源码审计。

技术体系官方文档可确认的机制对本章的研究价值本章不据此推断
OpenAI Agents SDKAgent 运行循环、工具调用、Handoff、Guardrails、Tracing；应用拥有部署和服务集成的控制权 [S2][S3]区分 Agent 定义、Runner、工具执行与控制权不推断其自动解决所有持久化和分布式可靠性问题
LangGraph图状态、检查点、线程持久化、恢复及人类介入等能力 [S4][S8]研究状态驱动执行与可恢复工作流不把 Checkpoint 等同于外部操作恰好一次
Microsoft AutoGenAgentChat、Teams、Core 事件驱动模型和多 Agent 协作模式 [S9][S10]研究 Agent 协作、消息与执行拓扑不认为多 Agent 必然优于单 Agent
TemporalWorkflow/Activity、事件历史、任务队列、Worker、重试和恢复 [S6][S7]对照成熟工作流系统中的持久执行语义不将通用工作流引擎本身认定为 Agent

上述对照揭示一个重要事实：Agent System 的技术实现可以复用传统工作流与分布式系统能力，也可以采用面向 Agent 的专用运行时；具体方案由任务约束决定。

八、章节研究方法与验收要求 ​

本章六篇专题采用「概念 → 机制 → 架构 → 真实实现 → 工程验证 → 评价」的研究路径，但应根据专题性质调整篇幅。概念边界专题重点检验定义是否具有区分力；执行机制专题重点检验状态与事件能否闭环；系统类型专题重点检验分类是否相互独立；架构专题重点检验设计决策能否解释成本与风险。

每篇研究至少回答四个问题：研究对象是什么；内部机制如何工作；有哪些代表性实现和替代路线；如何证明结论成立。 涉及具体 API、源码、版本行为时需注明来源与版本。实验必须区分模拟数据、单元测试、集成测试和真实外部环境验证，不能用前者冒充后者。

建议使用以下统一验收标准：

  1. 定义清晰： 关键术语具有操作性，边界与反例明确。
  2. 机制完整： 能解释任务、控制、数据、状态和反馈的因果关系。
  3. 架构可读： 图示与文字一致，明确组件职责和系统边界。
  4. 真实依据： 重要框架事实有官方资料或可定位源码支撑。
  5. 实验可信： 运行结果可复现，测试环境、限制和未验证项清楚。
  6. 工程判断： 能解释技术方案何时适用、何时失效以及代价。
  7. 领域衔接： 与 Agent、Technical Architecture、Engineering & Governance、Agent Platform 的研究分工明确。

本章节概述本身不包含需要调用外部 API 的运行实验；因此没有声称完成框架集成测试或生产验证。

九、章节完成后应具备的能力 ​

完成六篇专题后，读者应能够判断某个应用是否具有 Agent System 的特征；区分 Agent、Harness、Runtime、Workflow Engine、Multi-Agent System 和 Platform；从逻辑职责、运行过程与工程质量三个角度绘制系统架构；解释任务如何从请求进入执行循环并形成状态变化；比较单 Agent、多 Agent、工作流驱动和事件驱动架构；提出符合任务风险与规模的完整性要求；识别状态丢失、重复执行、权限越界、工具失败和控制权混乱等典型问题；并能够给出有依据的系统架构选择。

这里的「掌握」不是记住六篇专题名称，而是能够面对真实项目，说明为什么需要某个系统机制、它由谁负责、怎样工作、失败后会发生什么，以及如何验证其有效性。

十、与后续章节的衔接 ​

第一章 Fundamentals 建立 Agent System 的整体对象、机制和架构判断。第二章 Technical Architecture 将沿六个技术层级继续深入：L1 Infrastructure、L2 Platform Services、L3 Model Services、L4 Agent Engine、L5 Orchestration & Collaboration、L6 Application。第三章 Engineering & Governance 则从 可观测性、安全、评价、状态、配置、人工介入、可靠性、资源、数据、测试、部署 和 治理 等十二个维度研究系统级质量保障。

学习路径建议为：01 Definition & Boundaries → 02 Core Components → 03 Execution Mechanism → 04 System Types → 05 Completeness & Maturity → 06 Architecture & Design Principles。阅读第二章时，重点将本章的职责图映射为真实组件与接口；阅读第三章时，重点将本章的故障场景转化为可执行的工程约束与验证用例。

十一、核心结论与研究说明 ​

Agent System 的关键不是 Agent 数量，也不是使用了多少框架，而是能否把 Agent 的目标导向行为组织成具有明确任务、执行控制、状态反馈和必要运行保障的软件系统。Agent 研究「为何行动」，Agent System 研究「如何承载和保障行动」，Agent Platform 研究「如何将这些能力提供为可复用、可管理的产品服务」。

本章的定义、五项判据、三种观察视角及成熟度建议属于本知识库的综合性研究框架，不代表行业唯一标准。技术样本来自公开官方资料，尚未在本篇执行源码级全量审计或实测对比。后续专题需要在具体问题上继续深入，并对验证边界作明确记录。

十二、资料依据与进一步研究入口 ​

以下资料用于交叉核对运行时、编排、状态和可靠性等概念。文中 [S#] 对应本节资料。检索日期为 2026 年 10 月 28 日；官方文档可能随版本更新，后续专题需重新核查。

补充研究：定义判据的反例检验与边界决策 ​

定义性特征与操作性判据 ​

“围绕 Agent 的目标导向行动建立可执行软件系统”是本文采用的工作定义；Task/Run/Step、事件记录和状态机是用于观察系统的工程对象，并非所有实现都必须具备同名类或数据库表。检验一个系统时，应观察其是否存在可辨认的任务目标、由 Agent 参与的行动选择、由可信软件层落实的执行、反馈进入后续处理，以及可辨认的完成或失败条件。不要把某一种实现结构当作定义。

边界案例与判定条件 ​

  • 单次 LLM 文本生成 API：只有固定输入输出、没有环境行动或后续反馈循环时，通常应归为模型应用，而非本文研究的 Agent System；若其后接执行控制与行动反馈，则需按完整链路重新判断。
  • 固定脚本工作流：即使包含模型调用，若所有行动顺序均由代码预定、模型仅生成内容，首先属于工作流系统；若某个节点委托 Agent 根据观察选择行动，整体可同时具有工作流和 Agent System 特征。
  • 无持久化的本地 Agent：若能接收任务、选择行动、执行并利用反馈，仍可能满足工作定义；缺少持久化影响恢复能力，不自动否定其存在。
  • 多个角色提示词：角色数量不是 Agent 数量的可靠代理；若只有一次模型生成、没有独立执行或协作机制，不能仅因提示词出现多个角色就断言为多 Agent System。

边界判定记录 ​

建议对争议项目记录三类证据：运行轨迹中的实际行动与观察、执行控制所在代码边界、任务终止与错误的实际处理。若只有宣传文案或架构示意图，结论应标为“待验证”，而不是强行二分。

研究结论 ​

本篇的核心判断应与研究范围和证据强度共同理解：系统架构的合理性取决于任务契约、风险条件和可验证的执行机制，不能仅由组件数量、架构复杂度或概念分类推断。

附录 A：参考文献与原始资料 ​

参见正文原始资料引用。

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

  • **研究基准日期：**2026 年 10 月 28 日。
  • **本次修订检索状态：**未新增实时网页检索；保留原文来源及其原有核验声明，不将旧资料冒充重新核验的最新版本。
  • **本次修订验证状态：**原文所列的官方来源与核验日期予以保留；本次修订未重新进行联网检索，新增的技术分析属于概念论证与工程设计建议。
  • **结论适用范围：**定义、组件划分、架构选型及成熟度分级均需结合任务目标、风险等级、实际框架版本与目标环境进行核验。
  • **实验声明：**本次修订不宣称新增实验已经通过；历史文档中的运行或测试表述仅代表原文所述范围，需由独立可重现的执行记录支持。