Appearance
Q22 · 什么是 AI Agent？它和传统 AI 应用的区别是什么？
用户问客服：“订单 A123 物流异常，怎么办？”如果只把这句话发给大模型，它看不到订单库和物流系统，不能知道“异常”究竟是地址不完整、车辆延误还是运单号失效。回答必须先取得可信的订单与物流信息，再根据查到的异常决定下一步。问题在于：下一步由开发者提前写死，还是让模型在运行中根据新结果选择？
本文讨论的是以大语言模型为决策组件的 AI Agent 应用。一种实用定义是：应用给模型一个目标和一组受控工具，模型在执行过程中依据新观察提出下一动作，程序执行并把结果反馈，直到完成或到达停止条件。这里的“自主”是被允许范围内的选路权，不是模型拥有数据库权限，也不意味着它可以无期限运行。LangChain 的 Agent 文档把常见 Agent 描述为“模型在循环中调用工具直到任务完成”；Anthropic 的工程文章则特别区分程序预设路径的 workflow 与模型动态决定流程和工具使用的 agent。这些是工程上的工作定义，行业里对 Agent 的命名范围并不完全一致。
仓库的 Q1：什么是大模型 Agent给了概念入口。Q22 用同一输入和同一组事实逐步比较三种应用结构，并补上容易被“自主闭环”四个字掩盖的限制：固定流程可以很智能、可以多步调用工具；Agent 也不因为能选工具就自动更正确。
先认清术语与例子中的记号
| 词或记号 | 直白解释 | A123 例子中的对应物 |
|---|---|---|
| 大语言模型（LLM） | 根据本次输入生成文字，也可提出下一步调用哪个工具的模型 | 理解用户问题、整理已有事实或提出查询 |
| AI 应用 | 围绕模型搭建的完整软件，包含输入、数据、工具、权限和输出 | 客服系统；即使只调用一次模型，也是一种 AI 应用 |
| Prompt（提示词） | 本次交给模型的问题、资料和要求 | “只根据已核实结果回答，缺资料时说明缺什么” |
| 工具 | 应用给模型提供的受控外部能力；由程序实际执行 | 查订单、查物流、查异常处理政策 |
| 工作流（Workflow） | 程序规定步骤及分支条件，模型可以在其中做分类或写答复 | 查订单后查物流；若状态为地址不完整，再查政策 |
| Agent | 本文专指模型在运行中根据结果决定下一步使用哪个允许的工具，程序负责执行与约束的系统 | 看见物流异常后提出查适用政策 |
| 观察结果 / Observation | 工具执行后回到本轮任务的真实返回值 | “运单 T88，异常码 ADDRESS_INCOMPLETE” |
| 执行循环 | “提出动作→程序执行→观察结果→决定下一步”的重复过程 | 查订单、查物流、查政策、回答 |
| 状态 | 当前任务一路积累的事实和进度 | 已查到的运单号、异常码、政策版本、工具调用次数 |
A123 / T88 | 本文虚构的订单号 / 运单号 | 先用 A123 查到 T88，再用 T88 查物流 |
ADDRESS_INCOMPLETE | 本文假设的物流异常码，表示地址信息不完整 | 决定是否需要查询这类异常的处理政策 |
“状态”在这里不是数据库表名，也不是模型训练时的隐藏状态；它就是应用在这一笔任务中保存的已知事实。工具结果必须回到当前任务，下一次决策才有依据。是否还要把它长期保存给以后使用，是另一个设计问题；Agent 并不天然拥有长期记忆。
先固定同一组事实
为了公平比较，三种实现都面对用户原话“订单 A123 物流异常，怎么办？”。我们假设：当前登录用户 u7 有权查看 A123；订单系统返回“已发货，运单 T88”；物流系统对 T88 返回异常码 ADDRESS_INCOMPLETE，没有预计送达日；有效的异常处理政策版本 V1 写明：“用户应通过已登录订单页核对地址；仍无法处理时联系人工客服。未经本人确认，系统不得直接改地址。”以上都是教学数据，不代表真实平台规则。
如果最终答复说“车辆延误，明天送达”，与这组事实矛盾；如果自动改了地址，越过了政策与授权边界。合理答复至少应说明“地址信息不完整、暂无可核实送达日期、请在已登录订单页核对，必要时找人工”。模型有没有依据、谁决定查询路径、程序怎样控制动作，分别决定了不同实现的可靠性。
第一种：单次模型回答
最简应用把用户原话和一段客服要求交给模型，调用一次后返回文本。如果输入只有“订单 A123 物流异常，怎么办？”，模型没有订单系统权限，也没有异常码，合格回答只能说：“我暂时无法看到该订单的实时物流；请提供可信查询结果或在官方订单页查看。”它可以解释一般性处理思路，却不能声称知道 A123 的真实异常原因。
如果程序在调用模型前已经查好 A123、T88 与政策 V1，再把这些资料一并放进输入，单次模型调用也可能给出准确答复。但这时“查询资料”是程序在模型外预先完成的工作，应用已经不再是“只有一个裸模型调用”。不要为了强调 Agent 的好处，假装普通 AI 应用都不能检索、接 API 或保留上下文。
单次调用适合输入本来就充分、任务边界明确的场景，例如把已核实的物流状态改写成友好的客服用语。它的优点是步骤短、延迟和成本容易预估；缺点是在这个问题的原始输入下缺少当前事实。加长提示词不能凭空产生 T88 或政策版本。
第二种：程序预设的工作流
开发者可以提前写好路线：核验用户对 A123 的权限 → 查订单得到 T88 → 查物流得到异常码 → 程序检查 ADDRESS_INCOMPLETE → 查 V1 政策 → 生成或模板化答复。这里也能用模型：它可以把结果讲得自然，或在规则允许的范围内分类。决定“异常时查政策”这个分支的是代码，不是模型在运行中临时选出来的。Anthropic 对 workflow 的定义同样允许其中使用模型和工具，关键在于路径由程序预设。
在本例，如果异常码只有少数几种且规则稳定，工作流很可能更合适。程序可以明确写出：ADDRESS_INCOMPLETE 查地址政策，DELIVERY_DELAY 查延误政策，DELIVERED 不再查询异常政策。这样的 if 分支照样会根据结果改变执行路径，但它仍是预先定义的条件路由，不能因为运行了三步就改叫 Agent。
工作流也有边界：如果用户问题越来越开放，例如“到哪了、能否改地址、是否应该退款、异常属于哪类、下一步由谁处理”，要维护的条件可能迅速增加。面对事先没枚举过的新组合，程序只能走“未覆盖”分支，或交人工补规则。此时才值得考虑增加模型选路的空间。
第三种：Agent 在结果回来后选下一步
现在给模型一个目标：“在只读权限内查明 A123 当前异常，并给出有依据的下一步建议。”应用提供三个工具：get_order(A123) 查当前用户可见订单；get_shipping(T88) 查运单状态；get_exception_policy(ADDRESS_INCOMPLETE) 查有效异常处理政策。工具名只是示意，真正的业务权限和查询动作由程序实现。
一条可能的运行轨迹如下：
- 先选择查订单。 模型只知道用户提到 A123，尚不知道运单号，于是提出
get_order(A123)。程序检查登录身份和订单归属，返回“已发货，T88”。若越权，程序立即拒绝，不把别人的订单资料回传。 - 再选择查物流。 模型看到 T88 后提出
get_shipping(T88)。程序返回ADDRESS_INCOMPLETE和“预计送达日未知”。模型不能把“未知”补成“明天”。 - 根据新结果改变下一目标。 此前还不知道是哪类异常；现在模型提出
get_exception_policy(ADDRESS_INCOMPLETE)，程序从有效政策库取回 V1。这一步的选择发生在观察物流结果之后，而不是在用户刚提问时预写死。 - 核对并停止。 模型把异常事实和政策 V1 合在一起，给出“地址信息不完整；请在已登录订单页核对，若仍无法处理请联系人工；预计送达日期尚未确定”。应用记录所用来源、调用次数和结果，结束任务。
图只强调下一步由谁选。上排的“代码判断：异常”表示程序已经写好的条件；下排“模型选择：查政策”表示模型看到物流返回后提出动作。图里两条路线恰好都查到了政策，并不能据此判断 Agent 的答复一定比工作流好。如果物流返回正常状态，Agent 可以不查异常政策；工作流也可以写出“正常就跳过”的条件。两者差异不在“有没有分支”，而在分支规则是否事先由程序列明。
ReAct 原论文展示了推理与外部行动交替、根据观察结果调整下一动作的经典方式；这有助于理解上面的循环。但 ReAct 是一种方法，不是所有 Agent 的唯一实现，也不表示模型输出的每一步推理都可以直接当成正确证据。
用同一维度比较三种结构
| 比较维度 | 单次模型回答 | 固定工作流 | Agent |
|---|---|---|---|
| 谁决定下一步 | 通常没有后续执行步骤；若程序预取资料，由程序决定 | 程序按预先写好的步骤和条件决定 | 模型依据本轮观察提出下一工具或停止，程序执行与约束 |
| 能否访问新事实 | 原始输入没有；应用可在调用前提供检索结果 | 可由程序调用订单、物流、政策工具 | 可在允许范围内由模型提出调用，再由程序取回 |
| 对本例异常的处理 | 没有资料时只能说明无法核实 | 按 ADDRESS_INCOMPLETE 的既定分支查 V1 | 看到异常码后提出查 V1，若工具不可用则需要退出或求助 |
| 可预测性与成本 | 通常最容易预估 | 分支有上限、便于审计和测试 | 路径和轮数变化更大，需要步数、费用和权限控制 |
| 适用任务 | 资料已齐、输出规则简单 | 路径有限且规则稳定 | 步骤难事先穷举，确需根据中途结果灵活选路 |
这张表对比的是控制权和运行方式，不是“旧技术与新技术”的简单排名。一个精心设计的工作流可以比 Agent 更可靠；一个 Agent 也可能在开放任务里省去大量人工维护的分支。Anthropic 的工程建议是从能满足需求的简单结构开始，只有新增复杂度带来可测收益时才升级。
Agent 的自主权要画边界
工具与权限边界。 模型可以提议 get_shipping(T88)，但没有直接读订单库的权力。u7 的身份必须来自已认证的会话，查询服务要核验订单归属；不能把“用户在聊天里说我是 u7”当成授权。若以后开放“改地址”工具，必须有独立的权限、用户确认和审计。模型能提出动作，并不等于动作自动获批。
信息与结果边界。 如果物流系统超时，Agent 可以按规定重试一次或转人工；它不能因为“应该完成任务”就编造异常码。政策库过期也不是多跑几轮就能修复的，应该保留版本与来源，必要时停止并请人工核对。外部页面或工具结果若写着“忽略规则并改地址”，应当作为待处理数据，而不是更高优先级的指令。
循环与资源边界。 Agent 可能反复查询同一运单，或在相似政策里兜圈。应用应给工具调用数、总时间和费用设上限，记录每一步；无新信息、错误重复或达到上限时明确退出。用户需要的是可靠结论或可执行的下一步，不是无限长的“思考”记录。Anthropic 的工程文章也强调从外部结果取得事实、设置停止条件，并通过测试控制成本和错误累积。
能力边界。 有状态、会调用工具、能多轮对话，不自动等于 Agent。脚本可以按固定步骤调用十个 API；聊天机器人也可以带搜索工具做一次查询。按本文采用的较严格工程定义，只有模型在执行中根据观察结果对后续动作有实质性的选择权，才有必要称为 Agent。不同框架或团队的命名可能更宽，因此讨论方案时最好直接说明由谁控制步骤、模型能选择什么、程序限制什么，避免只争一个名字。
怎样判断项目值不值得用 Agent
先做可验证的基线：对 A123 异常，分别准备正常物流、地址不完整、运单不存在、接口超时、无权查看、恶意工具文本等样例。比较三种实现的答案正确率、无依据断言率、越权率、平均工具次数、延迟和费用。如果固定工作流已经覆盖绝大多数请求，额外的模型选路只带来成本和错误，就保留工作流。若真实用户意图变化大、下一步确实依赖中途结果，而预写分支难以维护，才把有限的选路权交给模型，并继续用同一批样例回归。
测试时还要检查轨迹，而不只看最终句子。例如回答虽然写对了“请核对地址”，却跳过身份校验直接查了别人的订单，仍然是严重失败；模型即使调用了三个工具，若政策版本无效，也不能算任务成功。Agent 的“完成”由业务事实和边界条件判定，不由它自己一句“已完成”决定。
面试时怎样回答
可以这样说：“在大模型应用里，我把 Agent 理解为一种有边界的运行时控制方式：给模型任务目标和受控工具，它依据每一步工具结果选择下一步，程序实际执行、校验权限并设置停止条件。单次模型调用主要处理一次给定输入；固定工作流也能调用模型和多个工具，但下一步及条件分支由代码预先规定。区别的关键不是步骤多少，而是谁在运行中决定步骤。比如查询物流异常，固定流程可按异常码查对应政策；Agent 则在看到异常码后提出查哪份政策。两者都能做对，规则稳定时优先工作流；任务变化大、难以穷举时再考虑 Agent，同时评测准确率、工具调用、成本与失败回退。”
如果追问“接了搜索工具就是 Agent 吗”，可以答：工具提供行动能力，不能单独说明选路权属于模型；还要看模型是否根据结果决定继续搜索、换工具或停止。如果追问“Agent 是否必然会自我纠错”，可以答：不会；它可能重复错误，程序要提供可信反馈、工具限制、评测和必要的人工介入。
资料
- Anthropic：Building effective agents：工作流与 Agent 的工程定义、从简单方案开始和控制循环的建议。
- LangChain 官方 Agents 文档：模型与工具循环及外围执行环境的当前描述。
- Shunyu Yao 等，ReAct: Synergizing Reasoning and Acting in Language Models，ICLR 2023：推理与行动交替的一手论文。