02 · Agent

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：领域总览（覆盖 01 Fundamentals、02 Internal Architecture、03 Development & Practice）
文档类型：领域概述
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 作为一种围绕目标组织决策与行动的计算实体，应如何定义和研究？它与 AI、Agent System、Agent Platform 有何区别与联系？如何从整体行为模型、内部能力机制和工程实现三个层次，建立完整且可验证的 Agent 技术知识体系？

一、领域概述：研究的究竟是什么

Agent（智能体）是人工智能研究中的一个长期概念。在现代大语言模型应用语境下，它通常指能够围绕任务目标，依据当前信息和运行状态，在一定约束条件下选择或发起行动，并利用行动结果推进任务的计算实体。这里的“行动”可以是生成面向用户的结果，也可以是调用搜索、文件、代码、数据库或其他外部接口。模型、规则和程序控制逻辑都可能参与行动决策；是否使用大语言模型、是否调用工具、是否存在多轮循环，均不能单独作为 Agent 的充分判据。

本领域主要研究现代模型驱动型 Agent 的逻辑实体、能力组织和行为实现。所谓逻辑实体，是指能够从任务目标和行为责任的角度被识别的智能体，而不是要求它必须对应一个独立进程、单独部署的服务或某个固定框架对象。一个 Agent 可以运行在普通应用进程中，也可以由模型服务、工具服务、状态存储和执行器协同支持。软件部署形态不直接决定其是否属于 Agent。

研究 Agent 的价值，在于解释从“模型产生一次输出”到“系统围绕目标持续处理任务”之间增加了哪些技术问题。模型可能生成计划或工具调用意图，但任务执行还需要解决行动授权、外部操作、状态更新、结果检查、失败处理以及终止判断。Agent 是这些能力围绕任务目标形成的行为抽象；支撑其可靠运行的基础设施，则可能进一步进入 Agent System 的研究范围。

本领域不预设 Agent 必须具有高度自主性。自主性更适合被理解为在具体行动类别上的决策权限分配：系统可能自主检索资料，却必须在发送邮件、发布内容或修改生产数据之前获得批准。因此，我们既研究 Agent 能做什么，也研究谁允许它做、在什么条件下做、何时必须停止。

本领域最终回答三个层次的问题：Agent 是什么、为什么能够这样行动；其内部能力如何形成和协同；如何把这些机制实现为可运行、可测试的软件。

二、Agent 在全栈技术体系中的位置

《Agent 全栈技术地图》将相关知识组织为四个主要领域。这是研究对象的分层，不是规定产品必须拆成四套系统。

领域	主要研究对象	核心问题
01 · AI	模型、推断、模型工程、知识与检索等基础技术	智能能力从哪里来，如何构建、调用与利用？
02 · Agent	单个智能体的逻辑实体、能力组织和任务行为	如何将基础技术组织为面向目标的决策与行动？
03 · Agent System	支撑智能体运行的软件系统及其工程机制	如何执行、编排、恢复、观察和保障 Agent 的运行？
04 · Agent Platform	可复用的 Agent 创建、运行与管理平台	如何把相关能力组织成可配置、可运营的平台产品？

01 · AI
模型、推断、工具接口与知识技术
              │ 提供基础能力
              ▼
02 · Agent
目标、能力组织、行动选择与行为边界
              │ 需要运行支撑
              ▼
03 · Agent System
执行引擎、编排、状态服务与可靠性工程
              │ 可被平台化
              ▼
04 · Agent Platform
创建、配置、发布、运行、监控与管理

这张图描述主要知识依赖，不表示单向调用链。Agent 可以直接运行于普通应用，不必依赖专门的平台；Agent System 可以只支持一个 Agent，不必包含多智能体协作；平台也可能同时提供模型服务、工作流、工具注册和运行管理等跨领域功能。

划分的关键是研究问题的归属。例如，模型如何生成结构化工具调用属于 AI 模型接口研究；Agent 为什么选择这个工具、如何利用其结果，属于 Agent；运行时如何隔离执行、处理超时与重试，属于 Agent System；如何向多个用户统一配置工具权限和发布版本，则属于 Agent Platform。相同的软件模块可以在不同领域被研究，但问题和抽象层次应当不同。

三、Agent 的整体行为模型

为了避免将 Agent 简化为“LLM + Tools”，本领域采用一个由目标、信息、决策、行动、反馈、状态与控制构成的行为模型。

**目标（Goal）**定义任务要达成什么结果，通常还包括输出要求、完成判据和资源限制。**信息（Information）**包括用户输入、当前上下文、外部证据和可观察环境。**决策（Decision）**依据任务与状态选择下一步行动，可以由模型、规则或混合策略产生。**行动（Action）**将决策转化为外部操作或可交付结果。**反馈（Observation）**记录行动产生的返回值、错误或环境变化。**状态（State）**保存足以支持后续决策的任务进展。**控制（Control）**负责权限、预算、审批、终止和异常处理。

                任务目标与完成条件
                        │
                        ▼
          ┌──── 当前信息与任务状态 ◄──────────┐
          │             │                     │
          │             ▼                     │
          │         行动决策                  │
          │             │                     │
          │             ▼                     │
          │       权限与预算校验              │
          │             │                     │
          │             ▼                     │
          │         执行行动                  │
          │             │                     │
          │             ▼                     │
          └────── 观察结果并更新状态 ──────────┘
                        │
                  满足终止条件
                        ▼
                    交付结果

这是一个分析模型，而不是所有 Agent 都必须逐字实现的固定循环。简单任务可能只产生一次行动；长任务可能在等待审批、定时事件或外部回调时暂停；复杂系统可能采用任务图、计划—执行结构或多层控制。关键在于能够解释行动选择依据什么、由谁执行、结果怎样影响后续行为，以及如何约束和终止。

以研究助理为例，用户要求比较三种技术方案。Agent 可能先检索资料，发现其中一种方案缺少可靠来源后继续检索，再生成对比结论。如果系统只按预先固定的步骤依次执行，研究重点更接近工作流；如果系统能够基于证据缺口动态选择后续行动，就体现了更强的 Agent 式决策特征。两者可以混合使用，不能仅凭产品名称区分。

四、Agent 的整体技术架构：能力、组件与机制

本知识库在 Internal Architecture 中设置十个内部能力研究维度。为了帮助理解其关系，可以将它们归入五组功能职责：

功能层次	研究职责	对应专题
任务与行为定义	确定身份、目标、职责和指令	A1 · Identity & Role；A3 · Instructions
认知与决策	处理信息、推理、规划与选择行动	A2 · Model；A9 · Planning & Reasoning
信息与经验	组织当前上下文、历史信息和外部证据	A4 · Context；A5 · Memory；A6 · Knowledge
行动与复用	调用外部能力、复用专业流程	A7 · Tools；A8 · Skills
权限与约束	限制操作范围、资源和行为	A10 · Permissions & Constraints

以上分层是一种研究视图，不是强制的软件模块清单。Identity 和 Instructions 可能同时存在于指令配置中；Planning 可能由模型与运行时共同完成；Memory 可以由数据库实现，也可能仅包含运行中的短期状态；Skills 也可能表现为可复用的指令、代码和工具组合。不是每个 Agent 都需要十项能力的完整实现。

还必须区分三个不同的技术概念：**组件（Component）**是可识别的软件或技术部分，例如模型适配器、工具执行器和状态存储；**能力（Capability）**是系统在任务中能够表现的行为，例如检索、规划、工具使用和纠错；**机制（Mechanism）**则说明行为怎样发生，例如模型提出工具调用、运行时校验参数、执行器发起请求、结果进入状态并触发下一轮决策。能力并不与组件一一对应，同一种能力也可能通过不同机制实现。

从软件职责角度，一个最小的模型驱动型 Agent 可能需要任务契约、决策接口、行动接口、状态表示以及执行控制。随着需求增长，才逐步加入外部知识、长期记忆、复杂规划、审批、恢复和监控等能力。先从任务所需的行为与约束推导组件，而不是先堆叠十种功能，是本领域重要的工程原则。

特别需要说明：A1—A10 主要组织内部能力研究，不能完整替代运行时架构。执行循环、状态机、检查点、工具调度和外部副作用控制等机制，可能同时涉及 Agent 的行为实现与 Agent System 的运行基础设施。后续专题会依据研究问题划分深度。

五、知识结构：三个章节、二十二篇专题

Agent 领域采用三个章节、二十二篇专题的研究结构：七篇 Fundamentals、十篇 Internal Architecture、五篇 Development & Practice。三章分别对应整体行为模型、内部能力机制、工程实现与验证。

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

本章研究 Agent 作为一个整体的定义、组成、能力、行为机制、类型、设计与生命周期。它不是仅介绍术语的入门目录：对决定 Agent 行为的关键机制，同样会涉及状态变化、接口、代表性研究和最小工程实验。

编号	专题	主要研究问题
01	Definition & Boundaries	Agent 如何定义？如何判断其与模型调用、助手和工作流的边界？
02	Core Components	最小 Agent 需要哪些功能职责？组件如何通过接口协作？
03	Core Capabilities	Agent 的能力如何形成？如何区分可用能力与可靠表现？
04	Execution Mechanism	决策、行动、观察、状态更新与终止如何形成执行过程？
05	Agent Types	不同决策架构、自主程度与执行模式如何分类？
06	Agent Design	如何根据任务契约选择架构、能力和控制边界？
07	Agent Lifecycle	Agent 定义、版本、实例、运行、暂停、恢复和迭代如何关联？

Fundamentals 中的 Core Components、Core Capabilities 与 Execution Mechanism 分别研究构成、行为表现与产生行为的过程，避免将同一个技术问题重复解释为三份功能清单。

5.2 02 · Agent 的能力由哪些部分构成？ - Internal Architecture

本章进一步拆解内部能力的实现机制，关注算法、数据结构、接口、信息流、控制流、技术路线和工程取舍。

编号	专题	主要研究问题
A1	Identity & Role	如何定义 Agent 的身份、职责、任务定位及其作用边界？
A2	Model	模型如何被接入、选择并参与 Agent 的认知与决策？
A3	Instructions	指令如何组织任务、行为规则和约束，如何与其他控制机制协作？
A4	Context	如何装配、选择、更新和压缩当前任务所需的信息？
A5	Memory	如何形成、存储、检索、更新和利用跨步骤或跨任务的信息？
A6	Knowledge	如何获取、评估、组织和使用外部知识与证据？
A7	Tools	如何描述、发现、选择、调用工具并处理执行结果？
A8	Skills	如何封装、选择和复用专业任务流程与能力？
A9	Planning & Reasoning	如何分解任务、形成计划、选择行动并根据反馈调整？
A10	Permissions & Constraints	如何定义、执行和验证权限、预算、审批与行为约束？

这一章与 AI 领域存在技术重叠，但研究角度不同。例如，AI 的 Function Calling 研究模型如何生成符合接口约定的调用意图；Agent 的 Tools 研究调用意图如何进入任务决策、工具选择、结果利用和后续行动。知识检索技术研究如何找到信息；Agent 的 Knowledge 还需研究什么时候检索、证据是否充分以及如何影响任务进展。

5.3 03 · 如何设计、构建和测试 Agent？ - Development & Practice

本章以实际项目为对象，把前两章的研究成果转化为可执行、可验证的工程系统。

编号	专题	主要研究问题
01	Agent Design	如何完成需求分析、任务契约、架构方案和验收标准？
02	Agent Configuration	如何配置模型、指令、工具、状态、能力和运行参数？
03	Agent Implementation	如何实现 Agent 的组件、接口、执行流程和异常处理？
04	Agent Testing	如何测试任务质量、可靠性、权限、安全、成本和失败模式？
05	Case Studies	如何从真实案例中分析技术选型、实现过程与工程取舍？

Fundamentals 的 Agent Design 研究通用设计原理和架构选择依据；Development & Practice 的 Agent Design 则研究具体项目的需求、接口、实现方案与验收。两者同名，但研究任务不同。

三个章节并不是“第一章不写代码、第二章只讲理论、第三章才动手”的分工。前两章可以使用可运行实验解释机制；第三章则将机制集成为具有明确任务、交付物和测试标准的完整项目。

六、贯穿案例：从研究任务到可验证的研究助理 Agent

本领域使用“研究助理 Agent”作为跨章节的贯穿案例。设定用户任务为：研究某项 AI 技术，收集可靠来源，比较主要实现方案，并形成具有来源依据的技术报告。

在 Fundamentals 中，我们判断该系统何时表现出 Agent 特征，研究它需要哪些组件与能力、如何根据证据缺口选择行动，以及如何确定自主程度和终止条件。在 Internal Architecture 中，我们拆解研究角色、模型、指令、上下文、记忆、知识检索、工具、技能、规划与权限等机制。在 Development & Practice 中，我们把这些机制落实为任务契约、接口、状态、执行器、评测样本和工程测试。

一个合理的任务过程可能包括：解析交付要求，检索初始资料，检查来源质量，发现信息缺口，选择补充检索或阅读，形成技术比较，检查结论是否有证据支持，最后输出报告。但这些步骤只是可能的行动路径，不应在未分析任务条件之前直接固化为唯一执行流程。若任务规则稳定，固定工作流可能更可靠；若需要根据新证据调整行动，动态决策机制可能更有价值。

贯穿案例还有一项作用：帮助识别能力的实际边界。例如，“能够搜索”并不等于“能够进行可信研究”；后者还要求来源判断、证据关联、冲突处理、结论核验与可追溯输出。研究和工程验证应当围绕任务质量展开，而不是仅以工具调用成功作为完成标准。

除研究助理外，各专题也会使用编程、浏览器操作、数据分析等 Agent 作对照。不同任务在行动风险、状态复杂度、环境反馈与审批要求方面存在实质差异，不能用单一案例概括所有 Agent。

七、研究边界：Agent 与相邻领域如何分工

领域边界应由研究对象与技术职责确定，而不是由代码仓库、框架名称、是否多 Agent 或是否独立部署决定。

共同技术主题	Agent 领域关注	Agent System 领域关注
行动循环	行动为何被选择，反馈如何影响后续决策	循环如何调度、执行和恢复
工具调用	工具如何扩展行动能力，结果如何被利用	调用如何隔离、限时、重试与监控
状态	哪些任务状态影响 Agent 行为	状态如何持久化、并发更新和恢复一致性
规划	Agent 如何形成和调整行动计划	任务依赖如何被调度、分派和编排
生命周期	定义、版本、实例、运行与状态的逻辑关系	实例如何部署、调度、回收与故障恢复
权限	Agent 可选择哪些行动、何时需要审批	授权如何被统一执行、审计与治理

例如，Agent 的 A5 · Memory 关注什么信息值得记住、如何检索与利用；Agent System 的状态管理更关注执行状态的持久化、并发一致性和恢复。两者可能共用数据库，但信息语义与工程要求不同。

Agent Platform 则进一步研究这些能力如何成为面向用户和开发者的产品：Agent Builder、Registry、版本发布、配置管理、运行管理、控制平面和执行平面等。平台是能力的产品化组织，不是 Agent 成立的必要条件。

此外，Agent 研究与 AI 基础技术保持明确衔接：Model Architecture 解释模型能力基础；Model API、Structured Outputs 和 Function Calling 提供程序接口；Context Window 解释上下文容量约束；Knowledge & Retrieval 提供知识表示与检索机制。Agent 领域研究的是这些技术如何在具体任务中被选择、组合、执行和验证，不重复其全部底层原理。

八、研究方法：机制优先、证据支持、工程验证

本领域沿用《Agent 全栈技术地图》的专题研究规范，并根据研究对象采用六层研究逻辑：

层次	研究重点	核心检验问题
L1 · Concepts	概念、背景、问题与边界	研究对象究竟是什么？
L2 · Mechanisms	技术机制、算法与执行过程	输入怎样转化为输出和状态变化？
L3 · Architecture	组件、接口、数据结构与控制流	各部分如何协作？
L4 · Research	原始论文、代表性框架与技术路线	现有方案解决了什么问题，有何限制？
L5 · Engineering	最小实现、系统设计与实验	能否运行、复现并验证关键机制？
L6 · Evaluation	失败模式、可靠性、成本与取舍	在什么条件下有效或失效？

六层框架用于保证研究深度，不要求每篇文章机械采用同样的标题和篇幅。领域概述负责交代研究路径；专题正文应针对关键机制深入分析输入、处理、输出、状态变化、接口、失败条件和验证方式。

研究结论需要区分四种性质：来自可核验资料的事实、基于资料形成的综合判断、作者提出的设计方案、实际运行验证过的实验结果。引用论文或框架时，应优先研究原始材料与技术实现；未实际验证的接口、版本行为或实验结果，不应写成已验证事实。简化的 Python 演示可以证明特定控制逻辑可运行，但不能替代真实模型、真实工具和生产环境下的可靠性测试。

评估 Agent 时，除了任务完成与输出质量，还应关注行动正确性、证据充分性、权限合规、失败恢复、资源成本和可重复性。具体指标由任务契约和风险条件决定，不存在适用于所有 Agent 的单一综合分数。

九、学习成果：从理解行为到具备工程判断能力

完成本领域三个章节、二十二篇专题后，读者应能建立以下能力：准确解释 Agent 的定义及其与模型调用、助手、工作流的边界；绘制 Agent 的逻辑架构，区分组件、能力和机制；解释任务目标如何经由决策、行动、反馈和状态更新转化为实际执行；分析 A1—A10 各维度的技术职责与依赖；根据任务条件判断采用固定流程、动态 Agent 或混合架构的理由；设计任务契约、行动权限和完成判据；实现具有基本执行控制的 Agent；使用测试和执行记录评价任务质量、可靠性与成本；识别何时需要进一步引入 Agent System 的基础设施。

这里的“掌握”不是能够背诵十个能力名称，而是能够面对一个具体任务，解释为什么需要某种 Agent 架构、哪些机制是必要的、它们如何协作、失败会发生在哪里，以及如何通过证据和测试判断系统是否有效。

推荐阅读顺序为 Fundamentals → Internal Architecture → Development & Practice。已有模型与软件开发基础的读者，可以快速浏览概念部分，但不宜跳过 Execution Mechanism、Context、Tools、Planning、Permissions 与 Testing 等直接影响实际工程判断的专题。对于准备进一步研究 Agent System 或 Agent Platform 的读者，还应特别关注状态、生命周期、执行控制和权限边界。

十、后续研究：从单个 Agent 到系统与平台

完成 Agent 领域后，下一步进入 03 · Agent System：研究运行环境、基础服务、模型服务、执行引擎、任务编排、多 Agent 协作、状态管理、可观测性、可靠性、安全与治理。研究重心由智能体的能力与行为，扩展到支撑其执行的软件基础设施及系统级质量属性。

随后进入 04 · Agent Platform：研究如何将 Agent 创建、配置、发布、运行、监控和管理能力组织为可复用的平台产品，进一步涉及 Builder、Registry、控制平面、执行平面、工作流管理、用户权限、部署与运营。

这条路径并不要求先完成一个复杂 Agent 再建设系统，也不要求所有项目最终都平台化。它提供的是一套可以随任务规模与工程复杂度逐步扩展的知识结构。

领域研究目标

以现代模型驱动型 Agent 为主要研究对象，建立从整体行为模型、内部能力机制到工程实现与验证的完整技术认知。 理解 Agent 如何围绕目标组织信息、决策、行动、反馈、状态与控制；理解模型、指令、上下文、记忆、知识、工具、技能、规划和权限如何协同形成实际能力；能够根据任务需求设计、构建并评估可运行的 Agent，并准确识别其与 AI、Agent System 和 Agent Platform 的技术边界，为后续系统工程与平台架构研究奠定基础。

研究说明

本文为知识体系的领域级组织与研究框架，不是某一 Agent 产品或技术方案的性能评测。文中的功能分层、行为模型与研究边界属于用于教学和工程分析的综合性框架；它们不代表行业存在唯一的标准 Agent 架构。具体算法、框架实现与实验结论，以各专题正文的来源说明和验证记录为准。