01 · 什么是 Agent System？ - Definition & Boundaries
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：概念定义、系统边界与工程判据研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：如何给 Agent System 下一个可操作、不过度限定部署形态的定义？怎样识别系统边界、最小成立条件与不同成熟度？它与 Agent、Runtime、Harness、Workflow、Multi-Agent System、Platform 的关系是什么？
专题导读
本篇属 Fundamentals。Agent System 的定义决定了研究对象的边界：若把它等同于多 Agent 协作，会遗漏大量实际运行的单 Agent 应用；若把所有 LLM 调用都归为 Agent System，又会失去分析执行控制、行动反馈和状态管理的能力。本篇建立可操作的工作定义，并通过边界案例检验判据，而不是声称存在唯一的行业标准。
研究重点是区分 Agent 的决策职责与软件系统的执行职责，分析逻辑、信任、运行和状态边界，解释 Task、Run、Step 等对象如何支撑系统识别。结论为下一篇组件拆分提供前提；文中的判据是研究工具，必须接受反例检验。
一、问题从哪里来：为什么必须定义 Agent System？
单独研究 Agent 时，关注的是任务目标、信息、行动决策、工具使用、反馈和行为边界。但当 Agent 需要在真实软件环境中运行，任务必须被接收、启动、追踪、取消、恢复和交付，模型与工具必须经过实际的软件接口，错误和外部副作用也必须被处理。此时研究对象已超出单个 Agent 的行为抽象。
一个常见混淆是：只要有 LLM、工具和循环就称为 Agent System；另一个相反的混淆是：只有部署了多个 Agent、工作流引擎、消息队列与容器集群才算 Agent System。前者忽略 Agent 是否真的承担目标导向的行动决策，后者把生产级实现的复杂度误当成概念成立的条件。
本篇先定义研究对象和系统边界，再说明必要条件、非必要条件、相邻概念、边界识别方法及反例。具体组件、执行机制、系统类型和成熟度分别由本章后续专题深入研究。
二、工作定义：Agent System 是什么？
Agent System 是围绕一个或多个 Agent 的目标导向任务，将 Agent 的决策与行动机制、运行控制、必要资源、状态反馈和外部交互组织起来，形成能够实际执行并结束任务的软件系统。
这个定义包含三个不同层次：
- Agent 行为层：任务有目标；存在可识别的行动选择机制；反馈能够影响后续行为，或支持对执行结果的判断。模型、规则或混合策略都可能参与决策。
- 系统执行层：软件真正接收任务、驱动执行、调用必要资源、处理返回结果和终止；它不只是画在架构图上的能力清单。
- 运行边界层：可以辨认谁负责执行控制、状态和错误处理，哪些操作跨越外部系统或信任边界，什么结果算任务结束。
这里的“系统”并不要求独立微服务。一个 Python 进程可以承载全部职责；也可以把 Runtime、模型网关、工具沙箱、数据库和调度器分布在不同服务。逻辑边界与部署边界不必一致。
2.1 必要判据与不必要条件
下表为本知识库建议的分析判据，不是行业认证标准。
| 判据 | 最小要求 | 典型证据 | 缺失时的疑问 |
|---|---|---|---|
| 目标导向任务 | 有可识别的任务、结果或完成条件 | Task 输入、输出契约 | 只是无目标的模型调用吗？ |
| Agent 行为 | 有能够围绕任务选择或形成行动的机制 | 决策函数、模型工具选择、策略 | 只是固定的数据处理管道吗？ |
| 运行执行 | 有实际驱动模型、规则、工具或环境交互的控制逻辑 | Runner、主循环、事件处理器 | 只有 Agent 配置，没有运行系统吗？ |
| 状态与反馈 | 有足够的信息说明执行结果与后续处理 | 内存状态、返回结果、事件 | 能否知道任务是否完成或失败？ |
| 控制与终止 | 有与风险相称的权限、停止、错误或完成处理 | 超时、终止判断、异常分支 | 是否可能无限执行或无约束操作？ |
非必要条件： 多个 Agent、长期记忆、持久化数据库、分布式部署、消息队列、专用 Agent 框架、可视化 UI、平台化管理后台，以及所有场景都启用人工审批。它们是需求驱动的工程选择，不是定义的充分或必要条件。
特别注意： 固定工作流与 Agent 行为可以共存。系统外层可以预设“检索→分析→审核”，而检索阶段内部由 Agent 根据证据缺口动态决定行动。反之，一个复杂工作流即使使用多次 LLM 调用，也未必包含可辨认的 Agent 行动选择机制。
三、定义中的核心概念：实体、实例、任务、运行与环境
概念清晰度决定系统设计时能否正确划分状态和责任。
| 概念 | 工作定义 | 例子 | 常见误解 |
|---|---|---|---|
| Agent Definition | 描述 Agent 角色、指令、能力和约束的定义 | ResearchAgent v3 | 配置文件就是正在运行的 Agent |
| Agent Instance | 特定任务或会话中的逻辑执行主体 | agent_instance_42 | 实例必须独占一个进程 |
| Task | 目标、输入、交付要求和完成判据 | 研究某项技术 | 一个用户消息必然等于一个任务 |
| Run / Execution | 一次具体任务执行过程及其标识 | run_987 | 一次模型请求就是一次完整运行 |
| Step / Action | 运行中的一步模型判断、工具调用或状态转移 | search(query) | 产生调用意图等于执行成功 |
| State | 支持执行推进、解释或恢复的信息 | 已检索来源、阶段、待审批项 | 所有对话历史都必须持久保存 |
| Environment | 执行所依赖或操作的外部条件 | 文件系统、浏览器、API、沙箱 | 环境必然属于 Agent 自身 |
| Result | 完成、失败、取消或其他终态的可交付记录 | 报告或失败原因 | 只要有自然语言输出就是成功 |
这些对象的关系可以表示为：
Agent Definition ──实例化/配置──> Agent Instance
│
Task ──创建──> Run ──驱动──> Step / Action ──调用──> Environment
│ │ │
├──── 记录 State ◄─┴── Observation ◄──┘
│
└──> Result / Failure / Cancelled / Paused一个 Task 可能经历多个 Run 或恢复阶段，也可能在一次 Run 中涉及多个 Agent。对象映射取决于具体框架。不要将上述概念图误认为所有 SDK 的固定类名或数据库 Schema。
四、系统边界如何划定？四种边界必须分开
“系统包含什么”不能只按仓库目录或进程列表回答。建议至少区分以下四种边界。
4.1 逻辑责任边界
辨认谁负责任务接收、Agent 决策、执行控制、工具调度、状态、终止与结果交付。即使这些职责写在一个文件中，分析时仍应区分。一个运行循环可以调用模型生成工具请求，但是否执行该请求，应由具有相应权限的程序控制逻辑决定。
4.2 进程与部署边界
辨认运行在哪个进程、容器、机器或云服务上，以及跨边界调用的协议和失败模式。部署边界影响延迟、扩缩容和故障隔离，但不能直接定义是否存在 Agent System。
4.3 信任与权限边界
辨认模型输出、用户输入、检索文档、第三方工具和内部状态各自的可信程度。模型生成的命令、URL 或工具参数应视为待校验的数据/请求，不能因为来源于模型就获得执行权限。尤其要区分“允许 Agent 提议操作”与“系统授权实际执行”。
4.4 状态与副作用边界
辨认哪些信息只存在于内存，哪些已持久化，哪些动作改变了外部世界。向外部 API 写入数据、发送邮件或修改仓库可能产生不可自动撤销的副作用。保存一次运行的状态快照，不等于外部副作用能随之回滚。重试和恢复需要独立的幂等、去重或补偿策略。
五、Agent System 与七类相邻概念的严格区分
| 概念 | 核心职责 | 与 Agent System 的关系 | 判断时要问 |
|---|---|---|---|
| AI Model | 将输入映射为输出，可能生成工具调用意图 | 可提供决策与生成能力 | 模型输出是否真正被系统执行与反馈？ |
| Agent | 围绕目标组织决策与行动的逻辑主体 | 是系统承载的行为主体 | 行动由谁选择，依据什么反馈？ |
| Agent Runtime / Engine | 驱动单次或持续的 Agent 执行 | 常是系统核心执行部件 | 任务管理、持久化、治理是否在其职责之外？ |
| Agent Harness | 围绕 Agent 的上下文、工具、控制、验证等执行支撑 | 与 Runtime/System 范围可能交叠 | 项目文档实际把哪些机制纳入 Harness？ |
| Workflow Engine | 按步骤、依赖、事件或状态调度任务 | 可承载 Agent 步骤，也可完全不含 Agent | 是否存在目标导向的 Agent 行动决策？ |
| Multi-Agent System | 多个 Agent 的交互、协作或竞争 | 是 Agent System 的一种重要形态 | 多个 Agent 是否真实协作，还是仅多个独立请求？ |
| Agent Platform | 面向用户/组织提供可复用的创建、配置、发布与管理 | 可以封装多个 Agent System | 是否提供平台级对象、权限、版本和多使用者管理？ |
5.1 Runtime、Harness、System 的包含关系并非固定
不要机械画成 Runtime ⊂ Harness ⊂ System 的行业通用集合关系。某些 SDK 的 Runner 已包含循环、工具执行、会话、追踪和人工审批；某些项目把这整套机制称为 Harness；另一些项目把 Harness 仅用于测试与环境约束。名称并不能替代源码与接口分析。
以 OpenAI Agents SDK 官方文档为例，Runner 会根据模型输出在最终回答、工具调用与 Handoff 之间推进；RunConfig 提供多种运行配置；SDK 还提供会话、追踪和人工介入能力。这是 SDK 所支持的执行机制，不自动意味着采用它的每个应用都已实现生产级持久化、业务授权和故障恢复。 [S1][S2][S3]
5.2 Agent System 与 Workflow 的交集
考虑三个流程：
- 固定工作流： 程序固定依次调用“搜索 API→摘要模型→模板渲染”，无基于目标和反馈的行动选择；更适合称为带 AI 能力的工作流。
- Agent 运行： Agent 根据已获得的资料判断是否继续搜索、选择何种工具，并由运行时执行；符合本知识库 Agent System 的典型研究对象。
- 混合系统： 外层工作流固定审批和交付关口，内部研究 Agent 自主选择资料检索路径；同时具有工作流和 Agent System 特征。
区别不在于是否使用图结构或是否多步，而在于哪些步骤由程序预定，哪些行动由 Agent 在运行时选择，以及控制权如何划分。
六、正例、反例与边界案例
| 场景 | 建议归类 | 理由 | 需补充核查 |
|---|---|---|---|
| 单次 LLM API 摘要 | 模型驱动应用 | 只有一次信息处理，缺乏可识别的 Agent 行动机制 | 是否存在隐藏的动态工具/行动循环？ |
| 固定三步 RAG 问答 | AI 应用/工作流 | 检索与生成流程由程序预设 | 是否根据反馈动态调整检索策略？ |
| 单进程 Agent：模型选择搜索工具，程序校验并执行，返回观察并终止 | 最小 Agent System | 目标、决策、执行、反馈、控制均可辨认 | 失败和终止处理是否明确？ |
| 多个模型并行写不同摘要，程序拼接 | 多模型工作流 | 多模型不等于多 Agent | 是否各自拥有可辨认的任务行动策略？ |
| 研究 Agent + 审核 Agent + 任务编排 + 状态持久化 | 多 Agent System | 具有 Agent 行为与跨 Agent 协作 | 共享状态、失败传播和审核权限如何处理？ |
| 只保存 Agent Prompt、工具清单与角色配置的仓库 | Agent 定义/配置资产 | 尚无可验证的实际运行机制 | 是否有外部 Runner 承载执行？ |
| 提供 Agent Builder、Registry、版本发布和多用户管理的服务 | Agent Platform | 面向复用和管理的产品层能力 | 底层执行系统由谁承担？ |
这些分类是分析建议，不是仅凭一句描述即可作出的最终判决。对真实项目应检查实际执行代码、部署拓扑、任务记录和权限链路。
七、最小 Agent System：以研究助理为例
任务：用户要求比较三种 Agent 执行框架，给出有来源依据的结论。
最小系统可以只包含：任务输入与完成标准、研究 Agent 的决策接口、受限搜索/阅读工具、执行循环、当前运行状态、错误和停止处理、最终结果校验。无需预先建设独立调度集群。
Task(goal, acceptance, limits)
-> Controller/Runner
-> Agent Decision(model/rules)
-> Validate(action, permissions, budget)
-> Execute(tool/environment)
-> Observe(result/error)
-> Update(state)
-> Continue | Pause | Fail | Finish
-> Result + Execution Record一条成功轨迹可能是：
run_created -> model_requested -> action_proposed(search)
-> action_authorized -> tool_started -> tool_succeeded
-> observation_recorded -> model_requested -> final_proposed
-> acceptance_checked -> run_completed一条失败轨迹可能是：
run_created -> action_proposed(write_file)
-> authorization_denied -> error_recorded
-> agent_replanned -> final_proposed -> run_completed重要区分： action_proposed 与 tool_started 之间必须有可信的执行控制边界。模型文本中出现“已保存文件”，不构成文件已保存的证据。必须由执行器的返回、文件系统观察或其他可信结果证明。
7.1 用状态机表达系统生命周期
建议以明确的状态及合法转移理解任务生命周期，例如：
| 当前状态 | 触发事件 | 目标状态 | 必须检查 |
|---|---|---|---|
| CREATED | 启动 | RUNNING | 输入契约、资源配额 |
| RUNNING | 等待人工审批 | PAUSED | 保存待执行动作与审批上下文 |
| PAUSED | 审批通过 | RUNNING | 重新校验授权与条件 |
| RUNNING | 完成验收 | COMPLETED | 结果与证据有效 |
| RUNNING | 不可恢复错误 | FAILED | 错误记录与清理 |
| RUNNING/PAUSED | 用户取消 | CANCELLED | 是否仍有进行中的外部操作 |
表中状态是教学设计方案，不是任何特定 SDK 的原生状态枚举。真实实现需处理并发竞争、幂等状态更新与异步取消。取消请求不保证已经提交的外部副作用可以撤回。
八、真实框架对照：哪些能力属于框架，哪些仍需应用承担？
8.1 OpenAI Agents SDK：Runner 是执行机制，不等于整套业务系统
官方文档说明 Runner 在模型最终输出、工具调用和 Agent Handoff 之间执行循环，并提供最大轮次限制、会话、追踪和中断恢复相关接口。它还记录了与外部持久化工作流技术的集成方向。[S1][S2][S3]
从文档可确认： SDK 能承担大量 Agent 执行职责。不能据此推断： 使用 SDK 就自动解决组织级 RBAC、生产数据库事务、业务幂等、所有工具沙箱、部署高可用和端到端审计。上述职责必须结合应用及其基础设施判断。
8.2 LangGraph：图执行与状态持久化说明“系统”可采用不同控制模型
LangGraph 官方文档将持久化和可恢复执行作为图运行的重要机制，并介绍检查点、线程状态与中断恢复。它说明 Agent System 可以采用图/状态驱动方式，而不必只有单个 while 循环。[S4][S5]
研究启示： 不同框架会将执行状态、任务边界、恢复点和人工交互暴露为不同接口。判断系统能力时，应检查实际恢复语义及副作用约束，不能仅凭“支持 checkpoint”推断任意操作都可以无损重放。
8.3 工具协议与系统边界
MCP 等工具连接协议可以帮助系统发现和调用外部能力，但协议接入不等于系统安全。调用方仍需管理工具来源、授权、参数校验、敏感数据传递及执行后果。工具接口层面的研究应与系统的信任边界共同展开。[S6]
九、系统完整性与工程成熟度：不要混为一谈
“算不算 Agent System”与“能不能生产使用”是两个不同问题。前者是定义与边界问题，后者是成熟度与质量问题。
| 维度 | 最小可工作 | 面向真实业务 | 高可靠/高风险场景 |
|---|---|---|---|
| 执行 | 单进程 Runner | 队列/Worker、任务管理 | 故障隔离、弹性与容量治理 |
| 状态 | 内存与结果记录 | 持久化、检查点 | 一致性、恢复与副作用控制 |
| 权限 | 工具白名单 | 用户/任务授权、审批 | 最小权限、审计、隔离 |
| 观测 | 日志与错误 | Trace、指标、告警 | 端到端关联、审计与 SLO |
| 质量 | 基本用例 | 回归、集成与故障测试 | 系统性风险验证与变更控制 |
上表是需求驱动的成熟度示意，不是固定三级标准。一个低风险、低并发的内部工具可能不需要分布式架构；一个有财务副作用的低并发系统却可能需要严格的权限、幂等和审计。
十、如何判断一个真实项目是否属于 Agent System？
建议采用以下七步研究法：
- 确定任务契约： 输入是什么，完成条件是什么，失败如何表示？
- 定位 Agent 行为： 哪些行动由模型、规则或 Agent 策略选择？哪些步骤固定？
- 追踪执行路径： 从请求入口到 Runner、工具、结果返回，真实代码路径是什么？
- 划定状态边界： 会话历史、任务状态、检查点、外部数据分别在哪里？
- 检查控制权： 谁校验权限、预算、超时、取消和审批？
- 确认系统边界： 哪些模块属于本系统，哪些由第三方 API、框架或平台承担？
- 评价工程成熟度： 在已确认属于 Agent System 的前提下，单独评估可靠性、安全、可观测性与治理。
10.1 可核查的最小证据包
对开源或自研项目，优先收集：架构图与部署说明、入口代码、Runner/调度实现、工具注册与执行代码、状态 Schema、一次成功与失败的执行记录、权限/配置机制、自动化测试。没有证据时，应写“尚未确认”，而不是根据项目名称推断。
10.2 本篇的验证范围
本篇完成了概念模型构建、边界判据、反例分析及官方文档对照；没有执行真实框架的端到端实验，也没有对具体版本源码进行逐行审计。运行时行为和框架内部实现的深入核验将分别在 03 · Execution Mechanism、L4 · Agent Engine、H4 · State Management 等专题开展。
十一、与后续专题的分工
| 后续专题 | 需要在本篇基础上回答的问题 |
|---|---|
| 02 · Core Components | 系统职责怎样拆分为实际组件与接口？ |
| 03 · Execution Mechanism | 任务执行的事件、状态转移和控制流怎样实现？ |
| 04 · System Types | 不同架构如何按决策与协调方式分类？ |
| 05 · Completeness & Maturity | 如何建立需求驱动的完整性和成熟度评价？ |
| 06 · Architecture & Design Principles | 如何按故障、信任、数据和部署边界设计系统？ |
| L4 · Agent Engine | Runner、Runtime、执行循环和实例管理的真实实现是什么？ |
| L5 · Orchestration & Collaboration | 任务图、调度与多 Agent 协作如何落地？ |
| H4 State Management / H7 Reliability | 检查点、重试、幂等与恢复的工程语义是什么？ |
补充研究：定义判据的反例检验与边界决策
定义性特征与操作性判据
“围绕 Agent 的目标导向行动建立可执行软件系统”是本文采用的工作定义；Task/Run/Step、事件记录和状态机是用于观察系统的工程对象，并非所有实现都必须具备同名类或数据库表。检验一个系统时，应观察其是否存在可辨认的任务目标、由 Agent 参与的行动选择、由可信软件层落实的执行、反馈进入后续处理，以及可辨认的完成或失败条件。不要把某一种实现结构当作定义。
边界案例与判定条件
- 单次 LLM 文本生成 API：只有固定输入输出、没有环境行动或后续反馈循环时，通常应归为模型应用，而非本文研究的 Agent System；若其后接执行控制与行动反馈，则需按完整链路重新判断。
- 固定脚本工作流：即使包含模型调用，若所有行动顺序均由代码预定、模型仅生成内容，首先属于工作流系统；若某个节点委托 Agent 根据观察选择行动，整体可同时具有工作流和 Agent System 特征。
- 无持久化的本地 Agent：若能接收任务、选择行动、执行并利用反馈，仍可能满足工作定义；缺少持久化影响恢复能力，不自动否定其存在。
- 多个角色提示词：角色数量不是 Agent 数量的可靠代理；若只有一次模型生成、没有独立执行或协作机制，不能仅因提示词出现多个角色就断言为多 Agent System。
边界判定记录
建议对争议项目记录三类证据：运行轨迹中的实际行动与观察、执行控制所在代码边界、任务终止与错误的实际处理。若只有宣传文案或架构示意图，结论应标为“待验证”，而不是强行二分。
研究结论
Agent System 的核心不在于 Agent 的数量、是否使用专用框架，或是否部署了复杂基础设施，而在于：围绕目标导向的 Agent 行为，存在可识别的实际执行机制、状态反馈、外部交互与系统控制边界。
研究 Agent System 时应坚持四个区分：行为主体与运行系统、逻辑责任与部署形态、系统成立与工程成熟、行动意图与实际副作用。 这些区分将贯穿后续系统组件、执行机制、架构与治理研究。
附录 A：参考文献与原始资料
参考资料与核验入口
以下为官方文档入口；本篇涉及框架能力的陈述仅限于这些资料能够支持的范围。访问日期：2026-10-28。
- [S1] OpenAI Agents SDK, Running agents: openai.github.io/openai-agents-python/running_agents
- [S2] OpenAI Agents SDK, Overview: openai.github.io/openai-agents-python
- [S3] OpenAI Agents SDK, Sessions: openai.github.io/openai-agents-python/sessions
- [S4] LangGraph, Persistence: docs.langchain.com/oss/python/langgraph/persistence
- [S5] LangGraph, Durable execution: docs.langchain.com/oss/python/langgraph/durable-execution
- [S6] Model Context Protocol, Specification: modelcontextprotocol.io/specification
研究说明： 上述资料用于技术事实核验；“五项必要判据”“四种边界”“最小证据包”是本知识库提出的研究工具，不是这些官方文档联合发布的标准。后续如更新具体 SDK 版本或接口，须重新核验相应结论。
附录 B：研究证据与验证声明
- **研究基准日期：**2026 年 10 月 28 日。
- **本次修订检索状态：**未新增实时网页检索；保留原文来源及其原有核验声明，不将旧资料冒充重新核验的最新版本。
- **本次修订验证状态：**原文所列的官方来源与核验日期予以保留；本次修订未重新进行联网检索，新增的技术分析属于概念论证与工程设计建议。
- **结论适用范围：**定义、组件划分、架构选型及成熟度分级均需结合任务目标、风险等级、实际框架版本与目标环境进行核验。
- **实验声明：**本次修订不宣称新增实验已经通过；历史文档中的运行或测试表述仅代表原文所述范围，需由独立可重现的执行记录支持。