什么是 AI Agent：定义、判据与组件

面试中不要只回答「Agent = 大模型 + 工具」。真正需要说明的是：模型是否参与下一步行动的决策，以及运行时如何执行、约束和验证这个决策。

上一篇介绍了 LLM 的基本工作方式、Token、上下文窗口和幻觉问题。本篇继续向上抽象：如果 LLM 只是一个根据输入生成输出的模型，那么一个能够完成多步骤任务的 AI Agent 是如何构成的？

本文重点不是背诵某个框架的定义，而是建立一套可以在面试中反复使用的分析方法：

1. 如何区分 Chatbot、Workflow 和 Agent？
2. Agent 的核心组件分别负责什么？
3. 模型决策、工具执行和安全控制应该由谁负责？
4. 什么场景适合 Agent，什么场景应该优先使用 Workflow？
5. 为什么生产系统通常不是纯 Agent，而是 Agent 与确定性代码的混合体？

一、面试先给结论：什么是 AI Agent？

1.1 推荐回答

AI Agent 是一种以目标为导向、能够感知环境信息、选择行动并根据行动结果持续调整执行路径的软件系统。

在基于 LLM 的 Agent 中，大模型通常负责：

• 理解用户目标；
• 根据当前上下文选择下一步行动；
• 选择工具并生成调用参数；
• 根据工具返回结果决定是否继续；
• 在满足结束条件时生成最终结果。

但需要注意：

模型负责提出决策，运行时负责执行决策。

模型不能直接获得数据库连接、支付权限或操作系统权限。真正的工具调用、参数校验、权限检查、预算限制、重试和审计，都应该由应用程序或 Agent Runtime 负责。

1.2 面试官可能继续追问

追问：Agent 和普通的 LLM 调用有什么区别？

普通 LLM 调用通常是：

用户输入
   ↓
LLM
   ↓
文本输出

Agent 则通常包含一个可以反复执行的闭环：

用户目标
   ↓
理解当前状态
   ↓
模型决定下一步
   ↓
运行时执行行动
   ↓
获取观察结果
   ↓
更新状态
   ├── 目标未完成 → 继续循环
   └── 目标完成或触发限制 → 结束

区别不在于是否使用了某个 SDK，也不在于是否调用了 Function Calling，而在于系统是否具备面向目标的行动与反馈循环。

二、Chatbot、Workflow 与 Agent 的区别

2.1 Chatbot

Chatbot 的核心是对话交互。它可以使用 LLM 生成文本，也可以接入知识库或少量工具，但并不一定具备自主的多步骤执行能力。

典型流程：

用户提问 → LLM 生成回答 → 返回用户

需要注意：Chatbot、Workflow 和 Agent 不是完全互斥的产品分类。一个 Chatbot 内部也可以包含 Workflow 或 Agent。这里讨论的是它们在执行控制方式上的差异。

2.2 Workflow

Workflow 是由代码、状态机或规则明确规定执行路径的流程。

例如：

用户输入
   ↓
LLM 抽取订单号
   ↓
查询订单
   ↓
检查退款规则
   ↓
如果允许退款 → 创建退款
   ↓
生成结果

即使其中每一步都调用了 LLM，只要流程顺序和分支主要由代码预先规定，它仍然是 Workflow。

Workflow 不等于没有智能。它可以在某个节点使用强大的模型，只是流程控制权主要掌握在代码侧。

2.3 Agent

Agent 的典型特征是：模型根据当前目标、上下文和观察结果，参与决定下一步行动。

例如：

用户：帮我处理这个订单的退款问题

模型：
  1. 选择 get_order
  2. 观察订单信息
  3. 选择 check_refund_policy
  4. 观察退款规则
  5. 判断是否需要人工确认
  6. 选择 create_refund 或向用户解释原因

这里的关键不是「模型调用了多少次」，而是后续路径是否会根据模型对当前状态的判断而变化。

2.4 对比表

2.5 一个实用判断：谁决定下一步？

面试时可以直接使用下面的问题：

如果把模型换成一个固定输出的程序，系统的流程是否仍然能够按照预定路径运行？

如果所有步骤、分支和终止条件都已经由代码确定，那么系统更接近 Workflow。

如果模型的输出会决定下一步调用哪个工具、是否继续以及选择哪条路径，那么系统具有 Agent 的特征。

不过，这个判断不是数学上的绝对分类。实际系统经常采用混合模式：

Workflow 骨架
   ├── 固定的数据准备步骤
   ├── Agent 决策节点
   ├── 代码侧权限检查
   ├── 人工确认节点
   └── 固定的结果提交步骤

三、如何准确描述 Agent 的核心特征？

不建议把所有特征都说成「必要条件」。更稳妥的方式是区分三个层次。

3.1 目标导向

Agent 通常不是只负责生成一段文本，而是围绕某个目标持续推进任务。

例如：

• 找出线上故障的可能原因；
• 根据多个数据源生成分析报告；
• 帮助用户完成一个复杂的配置任务；
• 在授权范围内执行一组业务操作。

目标导向并不意味着 Agent 一定能自主完成任务。系统仍然需要定义成功标准、失败处理和人工介入机制。

3.2 动态行动选择

Agent 会根据当前信息选择下一步行动。行动可以是：

• 调用搜索工具；
• 查询数据库；
• 执行代码；
• 读取文件；
• 请求用户补充信息；
• 将任务交给另一个专用模块；
• 结束任务并返回结果。

动态行动选择是区分固定 Workflow 与 Agent 的重要特征。

3.3 观察与反馈

行动完成后，Agent 需要获得结果，并将结果用于后续决策。

Action → Observation → Next Decision

如果工具返回结果没有进入后续上下文，模型就无法可靠地利用该结果。这也是 Agent 实现中经常出现重复调用、参数错误和状态丢失的原因之一。

3.4 外部作用不是必要条件

有些 Agent 会执行写操作，例如创建订单、发送邮件或修改数据库；但也有一些 Agent 只执行读取、检索和分析任务。

因此，不应把「必须能修改外部世界」作为 Agent 的必要条件。更准确的表达是：

Agent 通常通过工具与外部环境交互，工具可以是只读的，也可以包含有副作用的写操作。

对于有副作用的工具，系统必须额外增加权限控制、幂等性、审批和审计机制。

四、Agent 的核心组件

不同框架的命名不完全一致，但一个完整的 Agent 系统通常可以拆成以下组件。

4.1 Model

模型负责理解和决策，但不应被当成可信的业务执行层。

模型可能出现：

• 选择不存在的工具；
• 生成不符合 Schema 的参数；
• 忽略某些约束；
• 根据不完整信息做出判断；
• 重复调用工具；
• 在任务未完成时提前结束。

所以，不能因为模型输出了结构化 JSON，就认为它已经通过了业务校验。

4.2 Prompt 与 Instructions

Prompt 可以描述：

• Agent 的角色；
• 任务目标；
• 可用工具；
• 输出格式；
• 行为约束；
• 失败时的处理方式；
• 需要向用户确认的情况。

但 Prompt 不是权限系统。比如，Prompt 中写着「不能删除数据」，不代表应用层就可以允许模型调用删除接口。

安全边界必须在工具执行层和运行时中强制执行。

4.3 State 与 Context

State 表示任务当前处于什么状态，例如：

{
  "task_id": "T-1001",
  "order_id": "A1001",
  "current_stage": "CHECK_REFUND_POLICY",
  "refund_allowed": true,
  "human_confirmation_required": true
}

Context 则是模型当前能够看到的信息集合。它可能包括：

• 系统指令；
• 用户输入；
• 工具定义；
• 历史消息；
• 工具返回结果；
• 当前任务状态；
• 检索到的相关知识。

State 与 Context 不能简单画等号。状态应当由程序可靠维护，而不是完全依赖模型从长文本中自行推断。

4.4 Memory

Memory 用于保存需要跨轮或跨会话复用的信息，例如：

• 用户明确保存的偏好；
• 已确认的业务配置；
• 历史任务摘要；
• 长期积累的用户资料。

对话历史不等于记忆。记忆系统至少需要考虑：

1. 什么信息值得保存？
2. 谁可以读取？
3. 信息什么时候失效？
4. 新信息与旧信息冲突时怎么办？
5. 用户能否查看、修改和删除？

记忆系统将在第 06 期单独展开。

4.5 Tools

工具是 Agent 访问外部能力的接口。

一个生产级工具通常需要定义：

• 工具名称和描述；
• 参数 Schema；
• 权限要求；
• 读操作还是写操作；
• 是否幂等；
• 超时时间；
• 错误码；
• 重试策略；
• 审计字段。

例如，create_refund 不能只接收一个自由格式的字符串。它应该明确订单号、金额、幂等键和调用方身份，并由服务端重新查询和校验关键业务条件。

4.6 Planning、Execution 与 Observation

这三个部分容易被混在一起：

• Planning：下一步要完成什么，或者如何拆解任务；
• Execution：实际调用工具和执行代码；
• Observation：获取执行结果并更新状态。

它们不一定需要拆成三个独立服务，也不一定需要三个不同的模型。组件拆分的目的，是明确职责边界，而不是为了架构看起来复杂。

4.7 Guardrails

Guardrails 是运行时对模型决策进行约束和检查的机制，常见内容包括：

• 工具白名单；
• 用户和角色权限；
• 参数范围校验；
• 预算和 Token 限制；
• 最大步骤数；
• 超时；
• 重复调用检测；
• 敏感操作人工确认；
• 输出内容审核；
• 审计日志；
• 任务取消与恢复。

一句适合面试的总结：

模型负责提出行动建议，Guardrails 决定这个建议是否允许被执行。

五、Agent Loop：Agent 是怎样运行起来的？

一个简化的 Agent Loop 如下：

初始化任务
   ↓
读取当前 State
   ↓
调用 Model
   ↓
判断模型输出
   ├── Final Answer → 校验并结束
   ├── Tool Call → 校验工具与参数
   └── Invalid Output → 修复、重试或终止
   ↓
执行工具
   ↓
记录结果与 Observation
   ↓
更新 State
   ↓
检查预算、权限和退出条件
   ├── 继续 → 回到 Model
   └── 结束 → 返回结果

5.1 伪代码

def run_agent(task, model, runtime, max_steps=8):
    state = runtime.initialize(task)

    for step in range(max_steps):
        context = runtime.build_context(state)
        decision = model.decide(context)

        if decision.is_final:
            result = runtime.validate_final_answer(decision)
            if result.ok:
                return result
            return runtime.fail("INVALID_FINAL_ANSWER")

        if not runtime.is_allowed_tool(decision.tool_name):
            return runtime.fail("TOOL_NOT_ALLOWED")

        args_result = runtime.validate_arguments(
            decision.tool_name,
            decision.arguments
        )
        if not args_result.ok:
            state = runtime.record_error(state, args_result.error)
            continue

        permission = runtime.check_permission(
            state,
            decision.tool_name,
            decision.arguments
        )
        if not permission.allowed:
            return runtime.fail("PERMISSION_DENIED")

        observation = runtime.execute(
            decision.tool_name,
            decision.arguments
        )

        state = runtime.update_state(
            state,
            decision,
            observation
        )

        if runtime.should_stop(state):
            return runtime.finish(state)

    return runtime.fail("MAX_STEPS")

这段代码表达了一个重要的工程原则：

即使模型决定下一步做什么，工具执行和风险控制仍然必须在代码侧完成。

实际系统中还需要补充超时、取消、重试、幂等、并发控制和持久化等机制。

5.2 退出条件为什么必须是多个？

不能只依赖模型说「任务完成了」。

至少应当考虑：

其中，Model Finished 只能算正常终止信号，不能替代业务层的结果验证。

六、Agent 与 Workflow 的选型

6.1 优先考虑 Workflow 的场景

以下特征通常说明 Workflow 更合适：

• 步骤可以提前枚举；
• 分支条件明确；
• 业务规则稳定；
• 错误代价较高；
• 延迟要求严格；
• 需要强审计和可回放；
• 成本必须可预测；
• 结果容易通过规则验证。

例如，订单退款通常可以设计成：

查询订单
   ↓
校验订单状态
   ↓
校验退款时间窗口
   ↓
校验金额和幂等键
   ↓
高风险场景人工确认
   ↓
创建退款

模型可以帮助理解用户意图或解释业务规则，但关键的退款条件不应该由模型自由决定。

6.2 Agent 更有价值的场景

Agent 更适合以下类型的任务：

• 下一步行动取决于前一步发现的信息；
• 任务路径无法提前完整枚举；
• 工具选择具有探索性；
• 需要根据反馈动态调整策略；
• 目标可以描述，但具体过程不容易固定；
• 任务允许一定的延迟和成本波动；
• 结果可以被评估、校验或由人工审核。

典型例子：

• 多步骤故障排查；
• 研究型信息收集；
• 探索式数据分析；
• 代码问题定位；
• 多来源资料整理；
• 复杂的运维辅助任务。

这并不意味着这些场景必须使用 Agent。应该先评估是否可以通过更简单的规则、检索或 Workflow 解决。

6.3 选型表

不要把表格当成机械规则。一个任务也可能同时具备两边的特征，最终采用混合架构。

七、为什么生产系统通常采用混合架构？

「Agent 最后都会变成 Workflow」是一种便于讨论的概括，但不能作为普遍规律。

更准确的说法是：

在生产系统中，团队通常会把可确定、可验证、风险较高的部分固化为代码，把真正需要动态判断的部分交给 Agent。

原因包括：

1. 降低不可预测的执行路径；
2. 控制成本和延迟；
3. 增加测试与回归能力；
4. 明确权限和审计边界；
5. 降低高风险操作的自由度；
6. 让故障恢复和问题定位更容易。

一个常见的混合架构：

Workflow 外壳
   ├── 接收请求、身份认证        ← 代码
   ├── 加载任务状态              ← 代码
   ├── Agent 分析或规划节点      ← 模型
   ├── 工具权限与参数检查        ← 代码
   ├── 低风险工具执行            ← 运行时
   ├── 高风险动作人工确认        ← 代码 + 人
   ├── 结果验证                  ← 代码 / Evaluator
   └── 持久化与审计              ← 代码

7.1 一个关键取舍

不要追求「所有步骤都由 Agent 决定」，也不要追求「所有步骤都必须写死」。

真正应该问的是：

• 哪些步骤需要灵活性？
• 哪些步骤必须确定？
• 哪些操作可能造成不可逆的副作用？
• 哪些结果可以自动验证？
• 哪些环节必须由人工确认？
• 失败后是否可以恢复和重放？

好的 Agent 架构不是把控制权全部交给模型，而是把适合模型判断的部分交给模型。

八、成本、可靠性与可观测性

8.1 Agent 为什么可能更贵？

Agent 的成本通常来自多个因素：

• 模型调用轮数增加；
• 每一轮需要携带一定的上下文；
• 工具结果不断加入上下文；
• 失败重试和错误修复；
• 规划、执行和评估可能需要额外调用；
• 长任务可能产生较大的输入 Token。

可以使用一个粗略模型理解成本：

总成本
≈ Σ（每轮输入 Token × 输入单价
   + 每轮输出 Token × 输出单价）
  + 工具与基础设施成本

不能简单地说 Agent 成本一定是 Workflow 的几倍。实际成本取决于模型、上下文长度、调用次数、缓存命中率、工具耗时和任务分布。

8.2 可靠性不等于模型能力

即使模型能力很强，也不能单独保证系统可靠。

生产系统需要关注：

• 工具参数是否正确；
• 权限是否正确；
• 任务状态是否一致；
• 是否重复执行副作用；
• 失败后能否重试；
• 重试是否会造成重复扣款或重复发信；
• 是否能够定位是哪一步出了问题；
• 是否有人工接管机制。

因此，可靠性通常是模型能力、运行时设计、工具设计和业务约束共同作用的结果。

8.3 可观测性需要记录什么？

建议至少记录：

task_id
trace_id
user_id / tenant_id
model_name
prompt_version
tool_name
tool_arguments_hash
step_number
input_tokens
output_tokens
latency
tool_result_status
error_code
guardrail_decision
final_status

敏感数据不应无条件写入日志。日志系统需要脱敏、访问控制、保留期限和审计策略。

九、常见面试追问

Q1：用了 Function Calling 就是 Agent 吗？

参考回答：不是。

Function Calling 是模型表达工具调用意图的一种机制。一个固定 Workflow 也可以在每一步使用 Function Calling。

是否属于 Agent，主要取决于模型是否参与动态行动选择，以及系统是否存在面向目标的执行循环。

追问方向：

• Function Calling 的完整执行链路是什么？
• 工具调用参数由谁校验？
• 模型调用不存在的工具怎么办？
• 工具执行结果如何回填上下文？

这些问题将在第 03 期展开。

Q2：Agent 的下一步是不是完全由模型决定？

参考回答：不应该这样理解。

模型可以提出下一步行动，但运行时需要进行工具白名单校验、参数校验、权限检查、预算限制和风险判断。对于高风险操作，运行时可以拒绝模型决策或要求人工确认。

所以更准确的架构是：

模型提出决策
   ↓
运行时校验与约束
   ↓
允许执行 / 拒绝 / 请求人工确认

Q3：为什么不直接使用 Workflow？

参考回答：如果流程可以稳定枚举，Workflow 通常更容易测试、控制成本和保障可靠性。

Agent 的价值主要体现在路径难以提前固定、需要根据中间结果探索和调整的任务中。

实际项目通常会选择混合架构，而不是二选一。

Q4：Agent 是否必须具备 Planning？

参考回答：不一定需要独立的 Planning 模块。

简单 Agent 可以采用逐步决策的方式，每次根据当前状态选择下一步工具。复杂任务可能需要显式计划、计划检查、重新规划和任务分解。

Planning 可以是：

• 模型在一次输出中生成计划；
• 运行时逐步生成下一步；
• 独立的规划模块；
• 状态机与模型决策结合。

是否引入独立 Planner，应由任务复杂度、可解释性和维护成本决定。

Q5：Agent 是否必须有 Memory？

参考回答：不一定。

Memory 主要用于跨轮次或跨会话保存信息。一个短生命周期、单次任务的 Agent 可以只使用当前任务状态和上下文，不需要长期记忆。

但如果系统需要记住用户偏好、历史任务或长期知识，就需要设计独立的记忆机制，并处理权限、冲突、过期和删除问题。

Q6：多 Agent 一定比单 Agent 更好吗？

参考回答：不一定。

多 Agent 会带来额外的通信、状态同步、错误传播和成本开销。只有当职责隔离、上下文隔离、权限隔离或团队维护边界确实带来收益时，才值得拆分。

拆分前应先回答：

• 单 Agent 的上下文是否已经过于复杂？
• 工具和权限是否需要隔离？
• 不同角色是否需要不同的指令和评估标准？
• 多 Agent 的通信成本是否可接受？
• 出错后如何定位和恢复？

十、几个常见错误认识

十一、动手实验

配套代码：

agent-developer-interview/agent-02-what-is-agent

建议将实验拆成三个部分。

11.1 对比固定 Workflow 与 Agent Loop

使用同一个退款场景：

Workflow：
  代码确定查询、校验和退款顺序

Agent：
  模型决定下一步工具，运行时负责校验和执行

观察：

• 两种实现的控制流差异；
• 模型调用次数；
• 工具调用次数；
• 输入和输出 Token；
• 错误处理方式；
• 是否需要人工确认。

实验结果只能说明当前 MockModel、任务和参数下的行为，不能直接外推为所有真实模型的性能结论。

11.2 给 Agent 增加 Guardrails

逐步增加：

1. 最大步骤数；
2. 工具白名单；
3. 参数 Schema 校验；
4. 权限检查；
5. 重复调用检测；
6. 高风险工具人工确认；
7. 任务状态持久化。

比较增加约束前后的：

• 非法工具调用次数；
• 重复调用次数；
• 越序操作次数；
• 任务成功率；
• 平均执行步骤；
• 平均成本。

11.3 修改任务结构

尝试将任务拆成两类：

• 路径固定的订单处理；
• 路径动态的故障排查。

观察什么时候固定 Workflow 更自然，什么时候 Agent Loop 更有价值。

实验的重点不是证明 Agent 或 Workflow 谁更好，而是理解：

任务结构决定控制流设计，风险约束决定模型自主性的边界。

十二、面试速记

什么是 AI Agent？

Agent 是面向目标、能够根据当前状态选择行动，并根据行动结果持续调整执行路径的系统。在 LLM Agent 中，模型负责理解和决策，运行时负责执行、约束和状态管理。

Agent 与 Workflow 的核心区别？

核心区别是控制流的产生方式。Workflow 的执行路径主要由代码、规则或状态机确定；Agent 允许模型根据当前上下文和观察结果参与下一步行动选择。

Agent 的核心组件有哪些？

可以从 Model、Prompt、State、Memory、Tools、Planning、Execution、Observation、Guardrails 和 Evaluator 等方面回答。具体组件是否独立，取决于系统复杂度。

Agent 一定需要 Memory 吗？

不一定。Memory 主要解决跨轮或跨会话的信息复用问题，单次任务 Agent 可以只使用当前状态和上下文。

Agent 一定需要 Planning 吗？

不一定。简单 Agent 可以逐步决策，复杂任务才可能需要显式规划、计划检查和重新规划。

生产系统为什么要有 Guardrails？

因为模型输出具有不确定性，不能直接作为可信的执行指令。Guardrails 用于限制工具范围、校验参数、控制权限、限制成本、检测循环，并在高风险操作前要求人工确认。

什么情况下优先选择 Workflow？

当步骤可以枚举、分支明确、错误代价高、延迟和成本需要稳定控制时，通常优先考虑 Workflow。需要动态探索的部分可以局部引入 Agent。

十三、延伸阅读

站内

• LLM 基础与模型边界：理解模型输出的不确定性，以及为什么不能直接信任模型结果。
• 第 03 期：Function Calling——工具调用协议、参数校验、错误处理与执行链路。
• 第 05 期：上下文工程与压缩——上下文管理、截断、摘要与缓存。
• 第 07 期：Agent Loop 与 ReAct——循环、观察、行动和终止条件。
• 第 09 期：Harness——Agent Runtime 的代码层设计。

站外

• Anthropic：Building effective agents——Workflow 与 Agent 的架构模式。
• Yao et al.：ReAct: Synergizing Reasoning and Acting in Language Models——将推理与行动交替结合的经典工作。
• OpenAI：A practical guide to building agents——Agent 架构、工具和 Guardrails 的工程实践。

十四、一句话总结

Agent 不是简单地给大模型接几个工具，而是让模型参与目标驱动的行动选择，同时由运行时负责状态、执行、权限、预算和风险控制。

面试时最重要的不是背诵「Agent 有哪些组件」，而是能够进一步解释：

• 为什么这个任务需要动态决策？
• 哪些步骤必须由代码控制？
• 工具执行失败怎么办？
• 模型做出危险决策怎么办？
• 如何验证任务真的完成？
• 如何控制成本、延迟和执行风险？

当你能从这些问题展开，才算真正理解 Agent 的工程边界。