01 · 什么是 Agent？ - Definition & Boundaries

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：01 · Agent 是什么？它如何工作？ - Fundamentals
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 在经典人工智能与现代模型驱动系统中如何定义？如何通过目标、观察、决策、行动、反馈和控制权建立可检验的边界？Agent 与模型、Assistant、Workflow、Automation、RAG、Agent System 及 Platform 的区别如何落到运行协议和工程测试？

专题导读

“Agent”既是经典人工智能中描述环境行动者的宽泛概念，也是当代大模型工程中描述具有一定行动选择权的应用架构的术语。两种语境的外延并不相同：不能要求所有经典 Agent 都使用语言模型或工具调用，也不能因为一个产品自称 Agent，就假定它具有自主规划、持久状态或真实执行能力。

本篇以经典 Agent 理论作为概念基础，以模型驱动型、可执行任务的 Agent作为主要工程对象。研究不止于下定义，而是提出可观察的行为契约、决策权归属模型、环境转换语义和反例测试；进一步比较 Agent 与相邻系统的运行控制方式，给出最小可运行实验，说明“具有 Agent 特征”与“能够可靠完成任务”是两个必须分开的判断。

本文提出的工程判据是用于分析和设计的工作定义，不是学术界或各框架共同采用的强制标准。

一、定义的两个语境：经典智能体与模型驱动型 Agent

1.1 经典 AI：环境中的行动者

在经典智能体理论中，Agent 通过传感器获取环境信息，通过执行器采取行动。抽象的 Agent function 将感知历史映射为行动：

f : P^{*} \to A

其中 P* 表示感知序列集合，A 表示行动集合。Agent program 是实现这一映射的具体程序。环境不仅可能是物理世界，也可能是网页、代码仓库、数据库或模拟器。一个依据温度阈值开关设备的反射式控制器，在这一宽泛意义下可以被研究为 Agent；它不需要大语言模型、长程规划或自然语言接口。

经典理论还区分“理性”与“智能感”：理性关注在给定感知、知识和性能度量条件下，行动是否有助于实现目标，而不是系统是否表现得像人类。Agent 的能力取决于环境可观测性、动态性、行动后果和资源限制，不能仅凭生成文本的流畅度推断。

1.2 软件代理：代表谁执行什么任务

软件 Agent 的研究传统常强调自主性、反应性、主动性及交互能力。这里的“自主”不是单一属性：系统可能能自主选择搜索词，但不能自主发送邮件；可能能持续执行十分钟，但无法跨进程恢复；也可能拥有工具调用权限，却只按固定脚本执行。把这些维度压缩成“是不是自主 Agent”的二元判断，会丢失重要工程信息。

1.3 当代 LLM Agent：模型参与行动选择，运行时负责执行

在现代模型驱动型 Agent 中，模型常承担目标解释、候选行动生成或策略选择；运行时承担参数校验、权限检查、工具执行、状态更新和停止控制。一次模型返回 {"tool":"search","arguments":{"q":"..."}} 只是行动提议，不是外部搜索已经执行的证据。只有执行器发起调用、收到结果并更新可信状态，才形成一次可观察的行动。

典型循环是：获取观察 → 装配当前输入 → 生成候选行动 → 校验 → 执行 → 获取结果 → 更新状态 → 判断是否继续。模型驱动并不要求每一步都由模型决定：许多可靠系统把任务接纳、审批、预算和完成验收保留在确定性程序中。

二、本知识库的工作定义与判定边界

工作定义：Agent 是一个在给定目标、环境与约束下，能够依据观察及内部状态选择行动，并通过执行或发起行动与环境交互、利用结果推进任务的计算实体。

针对本知识库重点研究的模型驱动型 Agent，再附加一个条件：AI 模型在任务理解、行动选择或策略调整中承担实质性决策职责。这个条件只限定本知识库的工程研究对象，不否定规则型、机器人型或其他经典 Agent。

判断时应同时看五个问题：（1）系统追求什么目标，成功如何验收；（2）它能观察什么环境状态；（3）谁在运行时选择下一步行动；（4）行动如何真正影响环境；（5）反馈能否改变后续行为。五者构成分析维度，不能简单转化为“满足五项就取得 Agent 认证”的清单。对于一次性任务，反馈循环可能没有实际重复发生，但系统是否具备反馈驱动的后续行动能力仍可通过其他测试任务检验。

2.1 最重要的判据：运行时决策权

对同一任务，区分三种情况：

固定程序：步骤、分支和工具调用均由程序预先确定；模型最多填写参数或生成文本。
模型辅助工作流：步骤图由程序确定，模型在部分节点选择类别、提取字段或生成内容。
动态 Agent：至少某些关键后续行动及其顺序，由系统依据当前观察在运行时选择，且这种选择能够改变实际执行路径。

三者是工程控制架构，而非价值高低排序。固定工作流通常更可预测、成本更低；动态 Agent 更适合未知路径的任务，但需要更严格的预算、校验和状态管理。某个系统可以在部分任务中表现为工作流，在另一些任务中允许动态行动；因此应评价具体运行配置与任务契约，而不是只评价产品名称。

2.2 不能当作必要条件的属性

长期记忆、多 Agent 协作、RAG、反思、树搜索、联网搜索、自然语言聊天、无限循环、完全无人工干预，都不是所有 Agent 的必要条件。工具调用也不必然指互联网 API：在模拟环境中修改状态、控制机器人或对受限软件环境执行动作，同样可以构成行动。反过来，拥有十个工具、复杂提示词和向量数据库的系统，若所有步骤完全由预先写死的流程决定，仍可能更适合描述为“模型增强工作流”。

三、形式化机制：观察、策略、环境转换与状态

为了让定义具有可检验性，将一次运行抽象为：

o_{t} = O (e_{t}), a_{t} = π (o_{\leq t}, s_{t}, g, c), e_{t + 1} = T (e_{t}, a_{t}), s_{t + 1} = U (s_{t}, o_{t}, a_{t}, r_{t})

其中 e_t 是环境状态，o_t 是可观察信息，s_t 是 Agent 内部状态，g 是目标，c 是约束，π 是行动选择策略，T 是环境转换，r_t 是执行反馈，U 是状态更新。对于语言模型 Agent，π 可以由模型、规则、检索结果和规划器共同实现；T 则由真实工具、模拟器或环境承担，而不是模型文本本身。

这组表达式是用于解释运行机制的分析模型，不要求每个实现都显式维护完整环境状态。实际系统通常只能观察环境的一部分，并可能在工具调用后遭遇延迟、超时、并发修改或结果不确定。

3.1 一次行动的可信执行协议

text

Task / Goal
   ↓
Observation + Authoritative State
   ↓
Decision Policy (model / rules / hybrid)
   ↓
Proposed Action
   ↓
Schema Validation → Permission Check → Budget Check
   ↓
Tool / Environment Executor
   ↓
Verified Observation / Error / Unknown Outcome
   ↓
State Update → Completion Check → Next Decision

这里有三个不同的事实层次：模型建议了什么、执行器尝试了什么、环境实际发生了什么。日志与状态设计必须能区分它们。尤其是外部写操作发生超时后，“模型没看到结果”不等于“操作没有发生”。

3.2 目标、约束与评价函数不能混为一谈

例如任务是“整理三个框架的技术比较报告”。业务目标是产出有来源、覆盖三种框架的报告；硬约束是不得读取未经授权的文件、不得对外发布；优化偏好可能是减少成本和延迟。形式上可以把选择问题写成在允许行动集合 A_allowed(s) 中优化预期效用：

a_{t}^{*} \in \arg max_{a \in A_{a l l o w e d} (s_{t})} E [V (s_{t + 1}, g) - λ C o s t (a)]

该式用于说明目标、成本与硬约束的关系，不代表语言模型会显式求解此优化问题。权限应由可信执行层限制可执行行动，而不能只通过提示词提醒模型。

四、Agent 与相邻技术对象的边界

对象	主要职责	行动路径由谁控制	何时与 Agent 重叠
AI Model	根据输入计算输出	模型本身不负责外部执行	模型被嵌入有行动与反馈的运行系统
AI Assistant	面向用户提供协助的交互角色	可由对话逻辑、工作流或 Agent 控制	Assistant 获得任务级行动选择与执行能力
AI Application	面向用户交付功能的完整产品	产品架构决定	产品内部包含一个或多个 Agent
Workflow	由明确流程图、状态或规则组织步骤	通常由预定义流程控制	节点内允许模型动态选择下一步或子任务
Automation / RPA	自动执行重复操作	通常由规则、触发器或脚本控制	增加基于观察的动态决策与反馈修正
RAG	检索并提供外部知识证据	检索链或应用流程控制	Agent 自主决定是否检索、检索什么及后续动作
Agent System	组织多个执行主体或复杂执行基础设施	编排器及参与 Agent	单 Agent 成为协作系统中的一个执行单元
Agent Platform	管理注册、版本、部署、权限和运行	平台控制面	平台托管 Agent，但平台不等于 Agent 本体

4.1 Agent 与 Assistant：交互形式不是架构判据

一个聊天界面可能仅做问答，也可能在后台启动有状态任务、调用工具、等待审批并恢复执行。相反，一个没有聊天界面的后台任务执行器，也可能是 Agent。因此“是否会聊天”不能判断“是否为 Agent”；应检查它是否拥有可观察的任务决策与行动机制。

4.2 Agent 与 Workflow：不是非此即彼

实践中常见的是混合系统：确定性工作流负责接纳、审批和交付；Agent 子循环负责在不确定的信息环境中决定搜索、读取或修复步骤。判断边界时应定位模型获得了哪些决策权：仅填写固定步骤的参数，与能够根据反馈新增步骤、改变路径，具有不同的运行语义。

4.3 Agent 与 RAG：检索是信息能力，不自动等于行动自主性

固定的“提问→检索 Top-k→生成答案”通常属于 RAG 应用流程。若系统根据证据不足决定重新检索、改变查询、选择数据源、调用验证工具，并根据结果决定是否继续，则表现出更强的 Agent 式控制特征。但不应把“多次检索”本身当作充分条件：多轮检索也可能是固定脚本。

五、边界案例：同一任务的四种控制实现

任务：研究框架 A 与 B，输出一份比较报告。

案例 A：单次模型生成。 用户给出两段介绍，模型直接生成比较文本。没有独立的环境行动环节。它是模型应用，但不是本文重点研究的工具型 Agent。

案例 B：固定 RAG 流程。 程序总是检索 A、检索 B、拼接材料、调用模型生成报告。即使使用三个工具，也仍由预设流程决定路径。

案例 C：有限自主研究 Agent。 系统允许模型根据已获取证据选择继续检索 A、检索 B、核验来源或生成报告。执行器校验行动、维护状态并判断完成条件。它符合本文的模型驱动型 Agent 工作定义。

案例 D：多 Agent 研究系统。 一个研究 Agent 获取资料，另一个审核 Agent 检查证据，编排器决定返工。这里存在 Agent System 层面的协调关系，但并不意味着单个 Agent 必须采用多 Agent 架构。

5.1 一个容易误判的反例

程序写死“先搜索三次、再总结、若失败再搜索三次”，看起来有多轮行动和反馈，但搜索次数与后续路径完全由固定规则决定。它可以是有效的自动化工作流；若研究目标是理解模型驱动的动态行动选择，不宜仅因存在循环就将其归为 Agent。

5.2 另一个容易误判的反例

一个 Agent 接到简单任务后直接回答，没有调用工具。这条单次轨迹不能证明它不是 Agent：系统可能具备在复杂任务中选择工具和处理反馈的能力。应通过任务集合和运行配置评估系统，而非仅看某一次执行是否发生工具调用。

六、自主性的可测量维度

将自主性拆为至少六个维度：目标设定权（谁决定做什么）、计划权（谁决定步骤）、工具选择权（谁决定调用哪个接口）、执行权（谁能真正提交操作）、持续性（是否可在无人逐步指示下继续）、恢复权（中断后谁决定如何继续）。这些维度可以分别授权，且不必同时提高。

例如研究 Agent 可以有较高的搜索计划权和工具选择权，但只有只读执行权；报告发布仍由用户审批。评价自主性时应记录“允许的行动空间”和“实际发生的行动”，避免把提示词中的“你是自主智能体”误当作能力证据。

七、工程实现：最小的动态决策与固定流程对照实验

下面的实验使用 Python 3 标准库，不调用真实 LLM。它刻意将“决策策略”做成可替换接口，用确定性策略演示：固定流程按照预设顺序行动；动态策略依据观察决定下一步。它验证的是控制结构差异，而非语言模型的推理能力。 配套文件 01-Agent-Definition-and-Boundaries-v1.1-demo.py 可直接下载运行：python3 01-Agent-Definition-and-Boundaries-v1.1-demo.py。

python

from __future__ import annotations

from dataclasses import dataclass, field
from typing import Optional, Protocol

@dataclass
class State:
    facts: dict[str, str] = field(default_factory=dict)
    actions: list[str] = field(default_factory=list)
    report: Optional[str] = None

class Policy(Protocol):
    def decide(self, state: State) -> str: ...

class AdaptivePolicy:
    def decide(self, state: State) -> str:
        if "A" not in state.facts:
            return "read_A"
        if "B" not in state.facts:
            return "read_B"
        if state.report is None:
            return "write_report"
        return "finish"

class FixedPolicy:
    def __init__(self):
        self.plan = iter(["read_A", "read_B", "write_report", "finish"])
    def decide(self, state: State) -> str:
        return next(self.plan)

class Environment:
    def __init__(self, available: dict[str, str]):
        self.available = available
    def execute(self, action: str, state: State) -> None:
        if action.startswith("read_"):
            key = action.removeprefix("read_")
            if key not in self.available:
                raise LookupError(key)
            state.facts[key] = self.available[key]
        elif action == "write_report":
            if not {"A", "B"}.issubset(state.facts):
                raise ValueError("insufficient evidence")
            state.report = f"A: {state.facts['A']}; B: {state.facts['B']}"
        else:
            raise ValueError(f"unknown action: {action}")

ALLOWED = {"read_A", "read_B", "write_report"}

def run(policy: Policy, env: Environment, initial=None, max_steps=6):
    state = initial or State()
    for _ in range(max_steps):
        action = policy.decide(state)
        if action == "finish":
            assert state.report is not None, "premature completion"
            return state
        if action not in ALLOWED:
            raise PermissionError(action)
        env.execute(action, state)
        state.actions.append(action)
    raise TimeoutError("step budget exhausted")

if __name__ == "__main__":
    env = Environment({"A": "graph state", "B": "workflow history"})
    normal = run(AdaptivePolicy(), env)
    assert normal.actions == ["read_A", "read_B", "write_report"]

    # 在任务开始前已经有 A 的可信观察；动态策略跳过冗余读取。
    resumed = run(AdaptivePolicy(), env, State(facts={"A": "cached A"}))
    assert resumed.actions == ["read_B", "write_report"]

    fixed = run(FixedPolicy(), env, State(facts={"A": "cached A"}))
    assert fixed.actions == ["read_A", "read_B", "write_report"]

    class UnsafePolicy:
        def decide(self, state): return "delete_files"
    try:
        run(UnsafePolicy(), env)
    except PermissionError:
        pass
    else:
        raise AssertionError("unauthorized action was executed")
    print("4 boundary-mechanism checks passed")

这个示例的关键观察是：当已有 A 的可信资料时，动态策略可以跳过冗余读取，而固定流程仍执行预先安排的动作。这是运行时策略根据状态改变路径的最小证据。它并不证明动态策略一定更优：在真实环境中，缓存可能过期，跳过读取也可能降低准确性。

7.1 工程测试的三个层次

结构测试：是否存在明确的目标、观察、行动选择、执行接口、反馈和可信状态更新。行为测试：改变观察、工具可用性或约束后，系统的行动是否产生可解释变化。质量测试：在任务集上评估完成率、正确率、越权率、重复调用、成本和失败恢复。结构上具有 Agent 特征，不代表质量测试必然通过。

7.2 反事实测试：区分真正决策与表面循环

对相同目标构造两组环境：一组资料完整，另一组缺少关键证据。记录系统是否根据观察改变后续行动。再注入工具错误、权限拒绝、预算耗尽，检查系统是否停止、改选合法路径或明确报告无法完成。若所有输入都走完全相同的固定步骤，则应谨慎使用“动态自主 Agent”标签。

八、架构选择：什么时候不应该使用 Agent

Agent 架构的价值来自对不确定行动路径的适应，而成本来自额外模型调用、不可预测分支、调试困难和执行风险。若任务步骤稳定、输入格式固定、失败后果高且无需开放式探索，优先考虑确定性程序或固定工作流。若任务需要在未知信息环境中选择检索、诊断、修复和验证步骤，动态 Agent 更有理由被引入。混合方案通常具有较好的工程平衡：模型负责开放式判断，程序负责权限、执行、状态和验收。

技术选型应先回答：哪些决策必须在运行时动态作出？哪些决策可以预先编排？哪些行动有外部副作用？是否存在可观察的成功条件？若这些问题无法明确，给系统添加“Agent”标签不会自动改善设计。

九、与 Fundamentals 及 Internal Architecture 的衔接

本篇负责建立定义、边界与判据；《Core Components》研究支撑这些行为的组件职责和接口；《Core Capabilities》研究能力如何形成及评测；《Execution Mechanism》研究循环控制与工具执行；《Agent Types》研究决策架构分类；《Agent Design》研究架构选型与设计方法；《Agent Lifecycle》研究定义、运行与恢复的时间维度。Internal Architecture 则深入 Identity、Model、Instructions、Context、Memory、Knowledge、Tools、Skills、Planning 与 Permissions 的具体技术机制。

本篇不将多 Agent 通信、平台部署或分布式调度作为单个 Agent 的定义条件；这些问题将在 Agent System 和 Agent Platform 中展开。

十、核心结论

Agent 不是某种模型名称、聊天界面或固定组件清单，而是围绕目标、观察、行动选择与环境反馈组织行为的计算实体。经典 AI 对 Agent 的定义很宽；当代模型驱动型 Agent 则通常强调模型在任务决策中的实质作用，以及运行时将候选行动转化为受约束执行的能力。

判断一个系统是否具有 Agent 特征，最有效的方法是考察它的决策权分配和实际执行轨迹：什么由模型或策略决定，什么由程序固定，什么操作真正发生，反馈是否改变下一步，以及系统是否具有可信的停止和权限控制。判断它是否值得采用 Agent 架构，则必须进一步比较动态决策收益与成本、可靠性和风险。

下一篇《Core Components》将在本篇边界判据之上，研究支撑这些行为的组件职责、接口与最小可运行装配。

参考资料与延伸阅读

Stuart Russell & Peter Norvig, Artificial Intelligence: A Modern Approach, 4th ed., 2021。经典 Agent function、环境与理性智能体框架。
Michael Wooldridge & Nicholas Jennings, “Intelligent Agents: Theory and Practice”, Knowledge Engineering Review, 1995。软件 Agent 的自主性、反应性、主动性等经典讨论。
Shunyu Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”, ICLR 2023。交错推理、行动与观察的代表性研究。
Timo Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools”, NeurIPS 2023。模型学习工具使用的研究路线。
Anthropic, Building Effective Agents, 2024。工作流与 Agent 的工程架构区分。
OpenAI, A Practical Guide to Building Agents, 2025。Agent 设计、工具和控制的工程视角。
LangGraph 官方文档，Graph API、Persistence 与 Durable Execution。作为图执行型 Agent Runtime 的后续研究入口。

研究声明

来源与推导：经典 Agent 概念、软件 Agent 特征及 ReAct、Toolformer 等研究方向来自所列文献；本文的五维判据、控制权分层、工程对照表和形式化运行协议是面向本知识库的技术归纳，不是统一行业标准。

验证状态：本次重写未逐项在线核验所有文献、官方文档与 2026 年 SDK 版本。配套 01-Agent-Definition-and-Boundaries-v1.1-demo.py 为不依赖外部服务的最小机制实验；本地四项断言通过时输出 4 boundary-mechanism checks passed，不能据此推断真实 LLM Agent 的任务成功率或安全性。未进行真实模型调用、外部写操作或分布式故障测试。

适用范围：主要面向模型驱动的软件 Agent 的定义与工程边界；机器人、多智能体博弈和复杂自治系统的专门理论不在本篇展开。

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

专题导读 ​

一、定义的两个语境：经典智能体与模型驱动型 Agent ​

1.1 经典 AI：环境中的行动者 ​

1.2 软件代理：代表谁执行什么任务 ​

1.3 当代 LLM Agent：模型参与行动选择，运行时负责执行 ​

二、本知识库的工作定义与判定边界 ​

2.1 最重要的判据：运行时决策权 ​

2.2 不能当作必要条件的属性 ​

三、形式化机制：观察、策略、环境转换与状态 ​

3.1 一次行动的可信执行协议 ​

3.2 目标、约束与评价函数不能混为一谈 ​

四、Agent 与相邻技术对象的边界 ​

4.1 Agent 与 Assistant：交互形式不是架构判据 ​

4.2 Agent 与 Workflow：不是非此即彼 ​

4.3 Agent 与 RAG：检索是信息能力，不自动等于行动自主性 ​

五、边界案例：同一任务的四种控制实现 ​

5.1 一个容易误判的反例 ​

5.2 另一个容易误判的反例 ​

六、自主性的可测量维度 ​

七、工程实现：最小的动态决策与固定流程对照实验 ​

7.1 工程测试的三个层次 ​

7.2 反事实测试：区分真正决策与表面循环 ​

八、架构选择：什么时候不应该使用 Agent ​

九、与 Fundamentals 及 Internal Architecture 的衔接 ​

十、核心结论 ​

参考资料与延伸阅读 ​

研究声明 ​