AI Knowledge

外观

Agent 核心机制 ​

目录 ​

1. 学习目标 ​

  • 理解 Agent、Tool Calling、Workflow 和普通 LLM 调用的边界；
  • 能解释 Agent Loop、状态、工具、记忆、上下文和终止条件；
  • 能实现一个最小工具调用循环，并识别它与生产实现的差距；
  • 能结合 AI 面试教练项目讲清 Agent 如何规划、执行和追问；
  • 能排查错误工具调用、上下文膨胀和循环无法终止等问题。

2. 面试结论 ​

2.1 30 秒回答 ​

Agent 是一个由模型驱动决策、由运行时管理状态和工具的循环系统。模型根据目标与当前观察选择“直接回答、调用工具、继续规划或结束”，运行时负责执行工具、保存结果、实施权限与终止规则，再把新观察交回模型。Agent 的关键不是 Prompt 更长，而是把概率性决策限制在可观察、可控制、可恢复的执行边界内。

2.2 一分钟复述版 ​

一个完整 Agent 至少包含目标、模型、工具、状态、上下文、记忆、执行循环和终止条件。典型过程是“观察 → 推理/规划 → 选择动作 → 执行工具 → 获得结果 → 更新状态 → 决定继续或结束”。Tool Calling 是结构化动作表达机制，本身既不限制一次还是多个调用，也不自动提供状态、观察反馈和终止循环；Workflow 由代码预先定义路径；Agent 则由运行时组织循环，并允许模型根据中间结果动态选择下一步。实际项目中应由代码掌握权限、预算、重试、幂等和终止权，不能让模型自行决定所有副作用。

3. 面试官为什么问 ​

  • 核心考察点：是否理解 Agent 是系统设计问题，而不只是模型调用；
  • 对应岗位：AI 应用工程师、Agent 工程师、AI 后端工程师；
  • 区分度：能否讲清模型职责与运行时职责，以及确定性和概率性的边界；
  • 项目深挖点：工具如何定义、状态如何持久化、循环如何终止、失败如何恢复；
  • 安全深挖点：谁拥有执行权限，如何防止越权和重复副作用。

4. 概念与边界 ​

4.0 小白先这样理解：会看路况的旅行助理 ​

你让旅行助理安排“明晚到杭州并住进公司协议酒店”。他先查车票，发现高铁停运后再查航班和酒店，依据每次新结果调整下一步，而不是机械执行旧计划。这里，旅行目标是 Goal，助理的大脑是 LLM，查票与订房接口是 Tools，查询结果是 Observation，行程本是 State，反复查看结果再行动就是 Agent Loop；公司的差旅制度和付款确认则由外部运行时把关。

类比边界： Agent 像助理，只能提出下一步，不天然拥有订票、付款或读取全部客户资料的权限。鉴权、预算、参数校验、幂等、人工确认和终止条件必须由确定性代码控制；若路线固定且错误代价高，应优先用 Workflow，而不是为了“智能”强行让模型自由规划。

4.1 Agent 是什么 ​

Agent 是围绕某个目标运行的闭环：模型读取上下文并提出下一步动作，运行时验证并执行动作，再将观察结果反馈给模型，直到满足终止条件。

4.2 Agent 不是什么 ​

  • 不是所有带 System Prompt 的聊天机器人；
  • 不是只调用一次函数的 Tool Calling；
  • 不是固定节点顺序的普通工作流；
  • 不是模型拥有无限权限的自动化脚本；
  • 不是必须由多个模型组成，多 Agent 只是可选组织方式。

4.3 Agent、Tool Calling 与 Workflow ​

形态路径由谁决定是否依赖中间观察适合场景主要风险
普通 LLM 调用代码固定否生成、分类、抽取输出不稳定
Tool Calling模型提出一个或多个结构化工具动作，外层代码决定是否继续可选查询、计算、动作表达参数错误、越权
Workflow代码或 DAG 预定义是稳定业务流程分支维护成本
Agent模型动态选择下一步是开放问题、动态工具组合循环、成本、不可预测
Multi-Agent多个 Agent 协作或移交是明确专长分工协调、上下文和责任边界

4.4 输入、输出与前置条件 ​

  • 输入：目标、用户请求、可用工具、策略、历史状态和环境观察；
  • 输出：最终回答、结构化结果、工具副作用和完整执行轨迹；
  • 前置条件：工具 Schema 清晰、权限可控、终止条件明确、执行可观测；
  • 不适用：步骤稳定、规则明确且错误代价高时，优先使用确定性 Workflow。

教学插图：Agent 与固定 Workflow 的控制边界

Workflow 由代码沿固定路径分支，Agent 动态提出工具动作但受运行时护栏和人工确认约束

替代文本： 左侧固定轨道表示 Workflow 的节点和分支由代码预定义，其中仍可包含模型调用；右侧 Agent 根据目标和 Observation 动态选择 Tool，但动作必须依次通过 Schema、资源权限、预算、重复动作和终止条件检查，高风险工具还需人工确认，工具结果再作为 Observation 返回循环。

读图结论： Workflow 与 Agent 的核心差别是“下一步路径由代码预定义还是由模型根据观察动态选择”，不是“是否使用 LLM”；无论哪种模式，真正的执行权限都属于确定性运行时。

图片是职责边界的视觉类比，不表示 Agent 可以绕过业务状态机。高风险、副作用强且规则稳定的节点应继续使用确定性 Workflow、服务端授权和幂等控制。

5. 原理剖析 ​

5.1 Agent Loop ​

一次循环可以抽象为：

st+1=T(st,at,ot),at∼πθ(a∣st,g)

其中：

  • g 是目标；
  • st 是第 t 步状态；
  • πθ 是模型产生动作的策略；
  • at 是直接回答、工具调用、移交或停止等动作；
  • ot 是工具或环境返回的观察；
  • T 是由代码实现的状态更新函数。

模型负责提出候选动作，运行时负责判断该动作是否允许、如何执行以及是否应继续。

5.2 状态、上下文与记忆 ​

概念作用常见内容主要边界
运行状态保证当前执行可恢复当前步骤、预算、工具结果、错误必须由运行时持久化
模型上下文本轮决策可见信息指令、最近对话、工具 Schema、观察受上下文窗口和噪声限制
短期记忆跨步骤保留工作信息当前计划、临时结论、待办需要压缩和失效
长期记忆跨会话复用用户偏好、稳定事实、经验需要权限、来源和更新策略
外部知识按需检索事实文档、数据库、搜索结果不是未经验证的“模型记忆”

不要把完整日志全部塞回上下文。状态用于恢复，日志用于审计，上下文只保留下一步决策真正需要的信息。

5.3 工具定义与执行 ​

高质量工具应具备：

  • 单一清晰职责；
  • 可验证的输入 Schema；
  • 明确的输出和错误结构；
  • 只读、可逆、不可逆的风险分级；
  • 超时、幂等和审计信息；
  • 对模型友好的名称和描述；
  • 最小权限以及服务端二次校验。

工具描述影响模型“会不会选”，权限校验决定工具“能不能做”，二者不能混为一谈。

5.4 规划模式 ​

  • ReAct：交替进行推理与动作，适合根据观察动态调整；
  • Plan-and-Execute：先生成高层计划，再逐项执行，便于展示进度；
  • Router：先分类，再交给固定专家或 Workflow；
  • Agent as Tool：主 Agent 保留控制权，把子 Agent 当作一个工具；
  • Handoff：将后续控制权移交给另一个 Agent。

规划并非越长越好。简单任务直接执行；长任务才需要显式计划、检查点和重规划。

5.5 终止条件 ​

终止必须由模型信号和运行时硬条件共同决定：

  • 目标满足且输出通过 Schema/规则校验；
  • 达到最大步数、Token、时间或费用预算；
  • 连续动作或观察重复；
  • 工具返回不可重试错误；
  • 需要用户补充输入或批准高风险操作；
  • 运行时检测到越权、注入或策略违规。

5.6 可视化辅助 ​

Agent 概念本身不绑定框架。下面把本文最小 Python 示例与生产参考实现分开：最小栈用于验证循环、结构化动作和硬终止，生产栈还要补持久状态、策略执行、可观测性和恢复。

技术清单 ​

技术点 ID技术点/环节类型采用方案链路职责版本/证据边界
TP-AGENT-LOOP观察—行动循环运行时/框架Python 受控循环；生产可接 OpenAI Agents SDK 等 Agent Runtime组装上下文、调用模型、回灌 Observation，并实施步数与预算终止循环机制与 ReAct 论文一致；具体 SDK API 以项目锁定版本和官方文档为准
TP-AGENT-ACTION结构化工具动作协议JSON Schema Tool Calling + 服务端白名单约束工具名和参数形状，在副作用发生前完成解析与校验Schema 只能约束结构，不能替代资源级授权、业务校验和人工确认
TP-AGENT-STATE状态与恢复存储关系数据库状态快照 + 追加事件/工具结果保存步骤、预算、动作指纹、Observation 和终止原因，支持重启恢复与审计本文代码只使用进程内 State；生产选型需按并发、一致性和保留周期实测

横向选型对比 ​

技术点 ID候选方案优点缺点/代价适用场景不适用场景选择结论与依据
TP-AGENT-LOOPPython 自研受控循环依赖少、控制面清晰、便于理解最小机制Handoff、Trace、恢复和评测能力需自行建设教学、工具少、流程边界明确的原型多 Agent、长任务和生产观测要求高的系统本文最小示例采用，先证明机制再评估框架
TP-AGENT-LOOPOpenAI Agents SDK 等成熟 RuntimeTool、Handoff、Guardrail 和 Trace 等原语较完整引入框架约束、版本升级和供应商接口成本需要快速建设可观测 Agent 服务只有一次模型调用或固定简单流程生产候选；必须用目标任务、权限与恢复测试验证
TP-AGENT-ACTIONJSON Schema Tool Calling参数可机器校验，错误可结构化回灌模型复杂跨字段业务规则仍需代码实现模型需要在受控工具集合中选择动作下游只接受自然语言且无副作用的生成默认选择；Schema 与服务端授权共同生效
TP-AGENT-ACTION自由文本动作 + 正则解析接入快、演示成本低格式漂移、歧义和注入风险高，难以审计一次性无副作用实验写操作、支付、删除和长期运行服务仅作探索备选，生产工具调用不采用
TP-AGENT-STATE关系数据库快照 + 追加事件条件更新、审计和恢复边界清晰Schema、迁移、归档和写放大成本长任务、并发 Worker、需要对账与恢复可丢弃的单进程实验生产默认候选，以状态一致性与恢复演练验收
TP-AGENT-STATE仅进程内内存状态实现简单、单步延迟低崩溃即丢失，无法跨进程恢复或可靠审计教学与短生命周期本地实验外部副作用、长任务和多实例服务仅用于本文最小示例，不作为生产状态源

图：架构｜Agent 运行时的组件边界与依赖

替代文本： 用户目标进入 Agent Runtime；Runtime 组装上下文并调用模型，模型只返回候选动作。结构化动作经过 Tool Registry、Schema、策略和预算检查后才进入工具适配器；状态存储保存步骤、Observation 与终止原因，外部系统结果回到 Runtime，审计与观测组件旁路记录整条链路。

图表加载中…

读图结论： 模型只位于候选动作决策层；循环控制、工具权限、持久状态和真实副作用都属于可审计的确定性运行时。

这张架构图强调静态职责边界：替换模型不应绕过 Policy，替换工具也不应改变状态与终止规则的单一事实源。

图：技术调用流程｜Agent 从目标到终止的核心循环

图表加载中…

替代文本： 模型选择动作，运行时验证工具并更新状态，循环受预算、重复检测和结果校验约束。

读图结论： 模型只是决策者，真正控制权限、状态和终止的是 Agent 运行时。

流程中的拒绝、等待用户和工具错误都会形成新的 Observation；只有输出校验通过或运行时达到明确终止边界，循环才可以结束。

6. 实现与代码 ​

6.1 最小可运行示例 ​

下面使用标准库模拟一个工具调用循环，重点展示状态和终止逻辑，不依赖真实模型 API：

python
from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Any, Callable


def utc_time() -> str:
    return datetime.now(timezone.utc).isoformat(timespec="seconds")


TOOLS: dict[str, Callable[..., Any]] = {"utc_time": utc_time}


@dataclass
class State:
    goal: str
    observations: list[str] = field(default_factory=list)
    steps: int = 0


def mock_model(state: State) -> dict[str, Any]:
    if not state.observations:
        return {"type": "tool", "name": "utc_time", "arguments": {}}
    return {
        "type": "final",
        "content": f"当前 UTC 时间是 {state.observations[-1]}",
    }


def run(goal: str, max_steps: int = 3) -> str:
    state = State(goal=goal)
    while state.steps < max_steps:
        state.steps += 1
        action = mock_model(state)
        if action["type"] == "final":
            return str(action["content"])
        if action["type"] != "tool" or action["name"] not in TOOLS:
            raise ValueError(f"unsupported action: {action}")
        result = TOOLS[action["name"]](**action["arguments"])
        state.observations.append(str(result))
    raise TimeoutError("agent exceeded max_steps")


if __name__ == "__main__":
    print(run("查询当前 UTC 时间"))

6.2 关键实现说明 ​

  • State 与模型消息分开，便于恢复和审计；
  • 工具从白名单获取，不能执行模型任意生成的函数名；
  • max_steps 是运行时硬终止条件；
  • 生产实现还需 Schema 校验、超时、幂等、持久化、权限和观测；
  • 真实模型应返回结构化动作，不能用脆弱的正则解析自由文本。

6.3 边界条件与验证 ​

  • 未知工具：拒绝并生成结构化错误观察；
  • 参数错误：不执行工具，向模型返回可修复字段；
  • 工具超时：按错误类型重试，不能无限重试；
  • 重复动作：比较动作签名和观察，触发重规划或终止；
  • 最终输出：通过 Schema、引用、安全和业务规则校验。

7. 实际项目案例 ​

7.1 示例项目：AI 面试教练 ​

项目接收目标岗位和主题，选择一道题，分析候选人回答，再根据遗漏动态追问。它适合 Agent，因为下一问依赖用户上一轮回答，无法完全预先写死。

7.2 调用链 ​

图：业务时序｜受控 AI 面试教练的一轮决策

替代文本： 用户回答先进入分析工具提取事实点、遗漏和不确定项；Agent Runtime 根据当前状态决定追问、讲解、切换或结束。只有需要外部事实时才检索知识库，评分由确定性量表执行，状态存储在达到轮次、预算或用户停止条件后输出复盘，否则生成下一题。

图表加载中…

读图结论： 模型负责选择追问方向，但事实检索、评分口径、状态更新和终止预算由外层系统控制；这正是 Agent 决策与确定性 Workflow 组合，而不是让模型包办全部流程。

7.3 关键方案 ​

  • Agent 负责根据回答选择追问；
  • 评分规则、最大轮次和通过阈值由代码控制；
  • 检索结果携带来源，模型不能把无来源推测当事实；
  • 每轮只保留结构化摘要和关键证据，避免上下文无限增长；
  • 用户要求停止或切换主题时立即终止当前循环。

7.4 异常处理与验证 ​

失败处理验证
重复提问保存问题指纹并检测相似度固定对话回归测试
评分漂移确定性量表 + 示例锚点 + 双评审同一答案多次评测方差
检索无结果明确证据不足，转人工或基础问题空召回测试集
上下文超长结构化摘要、阶段归档、按需检索长对话压力测试
无限追问最大轮次、主题完成条件、用户退出故障注入测试

该案例是设计方案，不代表已有线上指标或真实用户结果。

8. 方案权衡与常见误区 ​

8.1 何时使用 Agent ​

适合：下一步取决于中间观察、工具组合难以预先枚举、允许在受控范围内探索。

不适合：支付、删除、审批等路径固定且错误代价高的流程。此时使用 Workflow，把模型限制在分类、抽取或建议节点。

8.2 常见误区 ​

  • “接了工具就是 Agent”：缺少循环、状态和动态决策时只是 Tool Calling；
  • “模型负责重试”：重试分类、预算和幂等应由运行时负责；
  • “上下文就是记忆”：上下文是本轮输入，记忆需要持久化、来源和失效；
  • “多 Agent 一定更强”：协作会增加延迟、成本、上下文损失和责任模糊；
  • “模型说完成就完成”：必须经过代码、Schema 或业务验收条件。

8.3 生产风险与诊断 ​

现象常见根因解决方向验证方式
无限循环无硬终止、重复观察、工具错误不可识别步数/预算上限、动作指纹、错误分类注入重复观察和持续失败工具，确认在上限内终止并保留原因
工具选错描述重叠、工具太多、缺少路由精简工具面、命名空间、路由层用带标准工具标签的固定样本计算选择正确率并复查混淆对
参数幻觉Schema 模糊、枚举不完整严格 Schema、服务端校验、错误反馈构造缺字段、越界和非法枚举参数，确认副作用执行前被拒绝
记忆污染未验证内容写入长期记忆来源、置信度、审核、TTL、删除写入冲突和低可信内容，检查检索隔离、过期和删除链路
成本失控长上下文、多轮自我反思、重复工具摘要、预算、缓存、确定性节点运行长会话与重复动作压测，确认 Token、步数和费用门禁生效

8.3.1 故障演练：工具已成功执行但 Agent 因超时重复调用 ​

  • 现象与影响：外部系统已经创建订单或发送消息，但 Agent 只收到超时观察，随后用相同参数再次调用，产生重复副作用。
  • 定位证据：关联 Run ID、step_id、工具参数指纹、业务幂等键、外部请求 ID、服务端审计和状态存储，确认超时发生在执行前还是响应返回阶段。
  • 根因：Runtime 把所有超时都当可重试错误，工具缺少幂等与对账接口，Observation 也没有表达“结果未知”状态。
  • 临时止损：暂停当前 Run 和自动重试，按业务键或外部任务 ID 查询真实状态；必要时转人工补偿。
  • 长期修复：工具契约区分未执行、明确失败、成功和结果未知；写操作使用幂等键，未知状态优先对账，重试由确定性策略和总预算控制。
  • 回归验证：分别注入执行前失败、执行后响应丢失、重复回调和并发同参调用，确认最终副作用唯一且 Agent 能在预算内终止。
  • 防复发：监控重复动作、未知状态、对账和补偿率；高风险工具必须通过幂等、授权、超时和恢复测试才能注册。

9. 面试题与参考答案 ​

9.1 Agent 与 Workflow 的核心区别是什么？ ​

  • 合格答案：Workflow 路径主要由代码预定义，Agent 允许模型根据观察动态选择下一步；
  • 加分项：说明高风险副作用仍应由 Workflow 和权限门禁控制；
  • 常见错误：把“是否调用 LLM”当成两者区别。

9.2 Tool Calling 为什么不等于 Agent？ ​

  • 合格答案：Tool Calling 是动作表达机制，Agent 还需要循环、状态、观察反馈和终止规则；
  • 加分项：举例说明单次天气查询与多步旅行规划的差异；
  • 常见错误：认为调用两个工具就自动成为 Agent。

9.3 Agent 的状态、上下文和记忆有什么区别？ ​

  • 合格答案：状态用于执行与恢复，上下文用于当前推理，记忆用于跨步骤或会话复用；
  • 加分项：提到来源、压缩、TTL、访问控制和遗忘；
  • 常见错误：把全部历史消息直接称为长期记忆。

9.4 如何防止 Agent 无限循环？ ​

  • 合格答案：步数、时间、Token 和费用上限，动作重复检测，目标验收，错误分类；
  • 加分项：区分模型停止信号与运行时硬终止；
  • 常见错误：只在 Prompt 中写“不要循环”。

9.5 多 Agent 的两种常见组织方式是什么？ ​

  • 合格答案：Manager 将子 Agent 当工具；Handoff 将控制权移交给专家；
  • 加分项：比较上下文、责任、回收控制和 Guardrail 边界；
  • 常见错误：按角色数量堆 Agent，却没有清晰接口。

10. 递进追问 ​

  1. 基础概念：一次函数调用和一个 Agent Loop 的最小差别是什么？
  2. 原理细节：工具结果为什么要作为 Observation，而不是直接返回用户？
  3. 实现边界：模型成功调用外部接口但服务在落库前崩溃，如何恢复？
  4. 工程权衡：上下文压缩可能丢信息，如何设计可回溯摘要？
  5. 系统设计：一百个工具如何避免全部注入上下文？
  6. 项目复盘：AI 面试教练为什么某些环节适合 Agent、某些环节必须固定 Workflow？

11. 实践任务 ​

  • [ ] 将最小示例替换为真实结构化模型调用；
  • [ ] 增加两个只读工具和一个需要确认的写工具；
  • [ ] 实现最大步数、动作重复检测和总预算；
  • [ ] 将状态序列化到 JSON，并模拟进程重启后恢复；
  • [ ] 为未知工具、参数错误、超时和重复观察编写测试；
  • [ ] 用 3 分钟讲清 Agent、Tool Calling 和 Workflow 的区别。

12. 相关知识与参考资料 ​

12.1 相关知识 ​

12.2 一手参考资料 ​

以下资料于 2026-07-10 核对：

13. 简明总结 ​

一句话记忆： Agent 是“模型动态决策 + 运行时受控执行”的观察—行动循环。

  • Tool Calling 是动作机制，Agent 还需要状态、循环和终止条件；
  • 模型提出动作，代码控制权限、预算、幂等和最终验收；
  • 状态用于恢复，上下文用于推理，记忆需要来源与失效策略；
  • 动态开放问题适合 Agent，固定高风险流程优先 Workflow；
  • 面试重点是边界、失败恢复和项目证据，而不是框架名。