3、Agent基础：智能体（Agent）核心概念、类型、架构、与RPA/工作流的区别，以及LLM在Agent中的作用

在构建“全额支付Agent智能体”之前，必须先厘清一个根本性问题：我们所说的Agent，与传统的自动化脚本、RPA机器人或工作流引擎到底有什么本质不同？很多团队在项目启动时，习惯性地用“流程编排”的思维去设计智能体，结果做出来的产品只是一个套了LLM外壳的定时任务，既没有体现出推理能力，也无法应对支付场景中千变万化的异常分支。本章将系统梳理Agent的核心概念、类型划分、架构范式，并通过与RPA/工作流的深度对比，帮助你建立正确的智能体设计心智模型。同时，我们也会重点剖析LLM在Agent中扮演的“大脑”角色——它不仅仅是文本生成器，更是决策引擎、工具调度器和自我反思的驱动器。

上图展示了Agent的核心架构闭环。与传统软件组件不同，Agent的每一个动作都不是预先硬编码的，而是由LLM根据当前感知到的信息、历史记忆和目标任务动态生成的。在“全额支付”场景中，这意味着Agent能够理解“用户尝试支付但余额不足”这一状态，并自主决定是调用优惠券核销工具、还是发起分期请求、或是引导用户更换支付方式——而不是像传统工作流那样，在遇到余额不足时直接抛出异常终止流程。

3.1 Agent的核心概念与本质特征

Agent（智能体）在人工智能领域并没有一个统一的定义，但在工程实践中，我们可以将其理解为：一个能够感知环境、做出决策并采取行动以实现特定目标的自主计算实体。这个定义包含四个关键要素：感知（Perception）、决策（Decision-Making）、行动（Action）和目标（Goal）。在支付Agent的上下文中，感知可以是接收支付回调、查询订单状态、读取用户账户信息；决策是判断当前应该走哪条支付路径；行动是调用支付接口、发送验证码、更新数据库记录；目标则是“在合规前提下，以最高成功率完成用户的全额支付”。

Agent的本质特征可以归纳为以下五点，这也是区分Agent与普通程序的分界线：

• 自主性（Autonomy）：Agent在运行时不需要人类逐条指令干预，它能够根据目标自行决定下一步操作。例如，当支付Agent发现用户选择的银行卡已过期时，它会自主查询用户是否绑定了其他有效卡，而不是停下来等待人工处理。
• 反应性（Reactivity）：Agent能够实时感知环境变化并做出响应。在支付场景中，如果第三方支付通道突然返回“系统繁忙”，Agent会立即切换备用通道，而不是机械地重试同一通道。
• 主动性（Proactiveness）：Agent不仅被动响应，还会主动采取行动以达成目标。例如，Agent可以主动检测到某笔订单即将超过支付时效，从而提前发送提醒通知。
• 社会性（Social Ability）：Agent能够与其他Agent或人类进行交互。在复杂的支付系统中，支付Agent可能需要与风控Agent、库存Agent、用户通知Agent协作，共同完成一个完整的交易闭环。
• 推理与规划能力（Reasoning & Planning）：这是Agent与RPA最本质的区别。Agent能够将一个大目标分解为多个子任务，并规划执行顺序。例如，“完成全额支付”这个目标可以被分解为：验证用户身份→检查余额→选择最优支付渠道→执行扣款→确认结果→更新订单状态。

3.2 Agent的类型划分与选型策略

根据不同的维度，Agent可以分为多种类型。在课程实践中，我们主要关注以下三种分类方式，它们直接决定了我们在“全额支付Agent”项目中如何设计系统。

3.2.1 按架构模式划分

类型	核心机制	适用场景	支付场景示例
ReAct模式（推理+行动）	交替进行“思考（Thought）”和“行动（Action）”，观察结果后继续推理	需要多步推理和工具调用的复杂任务	用户支付失败→Agent思考可能原因→调用余额查询工具→发现余额不足→思考替代方案→调用优惠券工具
Plan-and-Execute（规划-执行）	先制定完整计划，再逐步执行，执行中可调整计划	任务步骤明确、但需要整体规划的场景	Agent先规划“支付流程五步走”，然后逐步执行，每步校验结果
Multi-Agent（多智能体）	多个Agent分工协作，每个Agent负责特定领域	系统复杂、需要专业分工的场景	支付Agent负责交易，风控Agent负责审核，通知Agent负责触达用户

3.2.2 按记忆能力划分

Agent是否具备记忆能力，以及记忆的持久性，是另一个重要的分类维度。无记忆Agent（Stateless）每次交互都从零开始，适合简单的单轮查询；有短期记忆Agent（Short-term Memory）能够在一次任务会话中记住上下文，例如记住用户已经选择了“支付宝”作为支付方式；有长期记忆Agent（Long-term Memory）则能将用户的支付偏好、历史失败原因等持久化存储，在下一次交互时直接调用。对于全额支付Agent，我们强烈建议至少实现短期记忆，并逐步引入长期记忆来优化用户体验。

3.2.3 按学习能力划分

初阶Agent完全依赖LLM的预训练知识，不具备在线学习能力；进阶Agent可以通过反馈结果（如支付成功/失败）来调整自己的提示词策略或工具选择逻辑；高阶Agent则能够通过强化学习或微调来持续优化决策模型。在工程实践中，我们通常采用“反馈日志+定期微调”的方式，而不是在线实时学习，以保证支付行为的稳定性和合规性。

3.3 Agent架构范式：从单轮到闭环

一个生产级的Agent架构，远不止“LLM+提示词”那么简单。它需要包含以下几个核心模块，这些模块共同构成了Agent的“操作系统”。

1. 感知模块（Perception Module）：负责将外部环境的原始输入（用户文本、系统事件、API回调）转换为LLM能够理解的结构化上下文。在支付场景中，感知模块需要将“支付回调参数”、“订单状态码”、“用户账户快照”等数据整理成JSON格式的上下文窗口。
2. 记忆模块（Memory Module）：包含短期工作记忆（当前会话的对话历史、中间推理结果）和长期情景记忆（用户历史支付偏好、黑名单信息、常用支付渠道成功率统计）。记忆模块通常使用向量数据库（如Milvus、Chroma）来存储和检索。
3. 规划模块（Planning Module）：这是Agent的“决策中枢”。它接收感知模块和记忆模块的信息，利用LLM的推理能力生成行动计划。规划模块需要定义清晰的“思考模板”，引导LLM按照“目标→现状→差距→方案→选择”的逻辑进行推理。
4. 执行模块（Execution Module）：将规划模块生成的决策转化为具体的工具调用。执行模块需要维护一个“工具注册表”，每个工具都有明确的名称、描述、输入参数和输出格式。LLM通过Function Calling机制选择并调用这些工具。
5. 反思模块（Reflection Module）：在执行完一个动作后，Agent需要观察结果并判断是否达到预期。如果未达到预期，反思模块会触发新一轮的“感知-规划-行动”循环。例如，支付接口返回“余额不足”，反思模块会判断这是否是最终失败，还是可以通过其他工具（如组合支付）来弥补。

这五个模块形成了一个闭环：感知→规划→行动→观察→反思→再规划。这个闭环使得Agent能够在动态环境中持续调整自己的行为，直到达成目标或确认无法达成。

3.4 Agent与RPA、工作流的本质区别

这是本章最核心的对比内容。很多企业已经有了RPA（机器人流程自动化）或工作流引擎（如Airflow、Camunda），他们自然会问：为什么还需要Agent？下面我们从五个维度进行深度对比。

对比维度	RPA（机器人流程自动化）	工作流（Workflow）	Agent（智能体）
决策方式	基于固定规则（If-Then-Else），无推理能力	基于预设分支和条件判断，路径固定	基于LLM动态推理，路径不固定，可实时生成
异常处理	遇到未定义异常即终止，需要人工介入	通过错误捕获跳转到预设异常分支	自主分析异常原因，尝试多种替代方案
扩展性	需要开发人员编写新脚本才能扩展	需要修改流程图并重新部署	通过自然语言描述新能力，LLM自动适配工具
上下文理解	无上下文概念，每次执行独立	有流程上下文，但仅限于预设变量	具备深度语义理解，能处理模糊和隐含信息
学习能力	不可学习，完全静态	不可学习，完全静态	可通过反馈日志和微调持续优化

用一个具体的支付场景来说明：假设用户A在支付一笔1000元的订单时，系统发现其绑定的储蓄卡余额只有600元。RPA的做法是：检测到余额不足→触发“支付失败”分支→发送短信通知用户。工作流的做法是：检查是否有“余额不足”的异常分支→如果有，则跳转到“提示用户更换支付方式”的节点→发送通知。而Agent的做法是：感知到余额不足→思考“用户是否有其他支付方式？是否有可用的优惠券？是否支持组合支付？”→调用工具查询用户的其他绑定卡、查询优惠券账户→发现用户有一张500元额度的信用卡和一张50元优惠券→规划“使用信用卡支付950元+优惠券抵扣50元”的方案→执行组合支付→成功。这就是Agent与RPA/工作流最直观的区别：Agent能够创造性地解决问题，而RPA/工作流只能按照预设路径执行。

3.5 LLM在Agent中的核心作用与实现机制

LLM（大语言模型）是Agent的“大脑”，但它的作用远不止“生成文本”。在Agent架构中，LLM承担了以下四个关键职能：

• 意图理解与任务分解：LLM能够将用户的模糊目标（如“帮我把这笔订单付了”）转化为具体的、可执行的子任务列表。这依赖于LLM强大的语义理解能力和常识推理能力。
• 工具选择与参数生成：通过Function Calling（函数调用）机制，LLM能够从工具注册表中选择合适的工具，并生成符合工具要求的JSON参数。例如，当Agent决定调用“查询用户余额”工具时，LLM会生成{"user_id": "U12345", "currency": "CNY"}这样的参数。
• 结果分析与反思：LLM能够理解工具返回的结果（如“余额不足”或“支付超时”），并基于这些结果进行推理，决定下一步行动。这是Agent闭环中最关键的一环。
• 自然语言交互：Agent需要向用户解释自己的决策过程、询问确认信息或报告执行结果。LLM负责生成这些自然、可读的交互文本。

在实现层面，LLM与Agent的集成通常通过以下代码模式完成（以 Function Calling为例）：

# 定义工具函数
tools = [
    {
        "type": "function",
        "function": {
            "name": "check_balance",
            "description": "查询用户账户余额",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {"type": "string", "description": "用户ID"},
                    "currency": {"type": "string", "enum": ["CNY", "USD"]}
                },
                "required": ["user_id"]
            }
        }
    }
]

# Agent循环
messages = [{"role": "system", "content": "你是一个支付助手，请帮用户完成支付。"}]
while True:
    response = .ChatCompletion.create(
        model="",
        messages=messages,
        tools=tools,
        tool_choice="auto"
    )
    msg = response.choices[0].message
    messages.append(msg)
    
    # 如果LLM决定调用工具
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = execute_tool(call.function.name, call.function.arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(result)
            })
    else:
        # 如果没有工具调用，说明Agent已经完成或需要用户输入
        break

这段代码展示了Agent循环的核心逻辑：LLM在每一步决定是“调用工具”还是“直接回复用户”。当调用工具时，执行结果会作为新的消息反馈给LLM，LLM再基于结果进行下一步推理。这个循环会持续进行，直到LLM认为目标已经达成或无法继续。

3.6 实战案例：构建一个“全额支付”Agent的最小闭环

为了将上述概念落地，我们设计一个简化的“全额支付Agent”案例。假设我们的目标是：用户提交一笔订单，Agent需要确保订单被全额支付，如果余额不足，则自动寻找替代支付方案。

场景设定：用户“张三”在电商平台下单，订单金额为800元。张三的账户中有：储蓄卡余额500元，信用卡额度1000元，平台优惠券50元（满600可用）。

初始现象：用户点击“立即支付”，系统默认使用储蓄卡支付，但余额不足。

Agent执行过程：

1. 感知：Agent接收到支付请求，感知到订单金额800元，默认支付方式为储蓄卡。
2. 规划：LLM推理：“储蓄卡余额可能不足，需要先查询余额。”→调用check_balance(user_id="zhangsan", account="savings")。
3. 行动与观察：工具返回{"balance": 500}。LLM分析：“余额500元，不足以支付800元。需要寻找其他方案。”
4. 再规划：LLM思考：“用户有信用卡和优惠券。优惠券满600可用，可以抵扣50元。那么需要支付750元。信用卡额度1000元，足够。方案：使用信用卡支付750元，同时核销优惠券。”
5. 执行：Agent调用apply_coupon(order_id="O123", coupon_id="C456")，返回成功；再调用process_payment(order_id="O123", method="credit_card", amount=750)，返回支付成功。
6. 反思与总结：Agent确认订单状态变为“已支付”，并向用户发送通知：“您使用信用卡支付750元，优惠券抵扣50元，支付成功。”

结果对比：如果使用传统RPA，流程会在“储蓄卡余额不足”处终止，用户需要手动更换支付方式。而Agent通过自主推理和工具调用，完成了全额支付，且用户无需额外操作。

风险与代价：这个案例中，Agent自主选择了信用卡支付，这涉及用户的信用额度。如果用户不希望使用信用卡，Agent的决策就违背了用户意愿。因此，在实际系统中，Agent在调用信用卡支付前，应该先向用户确认：“检测到您的储蓄卡余额不足，是否同意使用信用卡支付剩余金额？”这就是“安全边界”的重要性。

3.7 常见误区与总结复盘

在设计和开发Agent时，团队容易陷入以下几个误区，需要特别警惕：

• 误区一：把Agent当作万能钥匙。认为只要接入了LLM，所有问题都能解决。实际上，Agent的推理能力受限于LLM的训练数据和上下文窗口，对于需要精确计算的场景（如金额核对），Agent仍然需要依赖外部工具。
• 误区二：忽略工具调用的可靠性。LLM生成的工具参数可能不准确（如日期格式错误、金额精度丢失）。必须在工具调用层增加参数校验和异常重试机制。
• 误区三：没有设计“退出机制”。Agent可能会陷入无限循环（如反复尝试不同的支付方式但都失败）。必须设置最大迭代次数（如5次），超过后自动转人工处理。
• 误区四：忽视安全与合规。支付领域对资金安全、数据隐私有严格要求。Agent的决策日志必须完整保存，且需要定期审计。