MyNote

外观

什么才算 AI Agent？它与聊天机器人、Workflow 有什么区别 ​

内容摘要：本章不从产品名称判断 Agent，而是抓住一个核心问题：下一步行动由谁决定？ 在此基础上区分聊天机器人、工作流、RPA、Copilot 与自主 Agent，并给出「该不该上 Agent」的工程判断方法。 难度：入门　|　前置知识：01 基础

典型误区

给一个聊天机器人接上搜索接口，或者把固定的「检索 → 生成 → 返回」流程包装成 Agent 类，并不会自动得到 Agent。能调用模型、能调用工具、类名叫 Agent，都不是充分条件。

一、先给结论：Agent 的本质是什么 ​

30 秒回答：AI Agent（Artificial Intelligence Agent，人工智能智能体）是一个目标驱动的闭环系统。大语言模型（Large Language Model，LLM）根据当前状态决定下一步动作，应用代码校验并执行工具，再把执行结果作为新观察交还给模型，直到目标完成或触发停止条件。区分 Agent 与 Workflow（工作流）的关键不是有没有工具，而是控制流由模型动态决定，还是由开发者预先写死。

可以把最小 Agent 记成一个工程等式：

text
AI Agent = 目标 + 模型决策 + 受控工具 + 状态/观察 + 停止条件

观察下面这张图时，先沿外圈箭头走一遍：输入目标后，系统会规划、选工具、执行并检查结果；只有观察结果重新进入下一轮决策，才形成 Agent 的闭环。

AI Agent 目标驱动闭环：从接收目标、规划、选择工具、执行动作到观察结果并更新状态

图 1：AI Agent 不是“会聊天的模型”，而是能在受控工具和状态反馈之间持续决策的目标驱动系统。

图中央的操作者代表应用中的决策与编排职责；外圈的目标卡、地图、工具箱、机械手和笔记本帮助记忆各项能力，左侧气泡表示交互。插画只表达“行动后继续观察”的直觉；它没有画全权限校验和停止分支，精确执行关系见下图。

阅读后文时，重点观察两条路径：

  1. 普通 LLM 应用是「输入 → 生成 → 输出」的单向链路。
  2. Agent 在输出动作后，还会读取工具结果并回到决策节点，形成受约束的反馈闭环。

图中的 LLM 只产生「下一步建议」；真正的权限判断、参数校验、工具执行、预算限制和停止条件都在应用代码中。Prompt 不是安全边界，模型也不是执行器。

二、可操作定义：满足什么条件才算 Agent ​

AI Agent（智能体）：一个以 LLM 为决策核心的系统，它接收一个目标，在一个循环中自主地选择动作（通常是调用工具）、观察结果、并据此决定下一步，直到达成目标或触发停止条件。

判断一个系统是不是 Agent，看它是否同时具备三个特征：

  1. 目标驱动：给的是「目标/任务」，不是「下一句该说什么」。
  2. 自主决策：由模型（而非写死的 if/else）决定下一步做什么。
  3. 闭环行动：能选择并执行动作、读取结果，再把结果纳入下一轮决策。动作可以只是搜索或查询，并不要求修改外部状态。

只满足「能对话」不算 Agent；只满足「按固定步骤执行」是工作流，不是 Agent。判断时不要看产品宣传页，而要查看运行轨迹中是否真的出现了「决策 → 行动 → 观察 → 再决策」。

三、统一辨析：Agent 与相邻概念 ​

用统一维度对比，避免营销话术带来的混淆：

维度聊天机器人 Chatbot工作流 WorkflowRPACopilot自主 Agent
输入一句话触发事件触发事件用户在产品内的操作一个目标
控制流由谁决定通常由应用组织对话开发者预设规则开发者预设规则人 + 模型模型动态选择部分后续动作
是否调用工具可以可按预设规则调用可操作图形界面或接口可以（人主导）通常由模型选择
是否循环迭代可以多轮对话可按代码定义循环可按规则循环通常由人推动根据观察迭代，受停止条件约束
谁做最终决定用户代码代码人Agent（高危时交人）
典型例子FAQ 问答审批流、ETL表单搬运IDE 补全、写作助手自主排障助手

其中，RPA（Robotic Process Automation，机器人流程自动化）通常按预先录制或编排的规则操作图形界面；Copilot 强调由人持续发起、审阅和接受建议。二者可以使用 LLM，但使用了 LLM 不等于控制流已经交给模型。

观察下面的控制光谱时，重点看每一站“谁能改变下一步”：固定传送带表示代码预设路径，带反馈环的操作者表示模型可以依据中间结果选动作，最右侧的门禁则表示自主性越高越需要治理。

从聊天机器人、固定工作流到自主 Agent 的运行时控制权变化与治理要求

图 2：从左到右，运行时控制权逐步从固定代码转向模型；能力增加的同时，审批、权限和审计不能缺席。

这些类别并不完全互斥：Chatbot 描述交互形式，Copilot 强调人机分工，Workflow 和 Agent 更侧重控制方式。聊天界面背后也可以运行 Agent；很多生产系统采用“固定 Workflow + 局部模型决策”就能满足需求。

观察下图时只看横轴：从左到右，运行时控制流逐渐从代码和人转移给模型。

这张图不是能力排行榜。确定性越强，系统越可控、越容易测试；自主性越强，系统越能处理未预设路径，但成本、时延和失败模式也越难预测。大量业务使用确定性 Workflow + 少量模型决策就够了，不要为了「像 Agent」而 Agent。

四、系统组成：模型之外还有什么 ​

观察组件图时先找中央运行时，再沿连接线向外看。大脑只是模型，清单、上下文托盘、工具箱、状态存储、安全门和观测时间线共同组成了可运行的 Agent。

AI Agent 工程组件：模型、指令、上下文、工具、记忆状态、护栏与可观测性围绕编排运行时协作

图 3：模型负责提出决策，外围组件负责提供上下文、执行能力、持久状态、安全约束和运行证据。

手绘图用于建立组件直觉；下面的 Mermaid 图进一步给出组件之间的精确调用方向。阅读时先定位 LLM，再沿着编排层向外看：模型只是一个决策组件，可靠性主要由外围工程系统决定。

图中只有 LLM 是模型，其余都是应用工程。上下文构造决定模型能看到什么，工具层决定它能做什么，权限与审批决定哪些动作允许发生，状态与 Trace（追踪）决定系统能否恢复和复盘。因此，换一个更强的模型并不能替代编排层治理。

五、能力边界：Agent 不能承诺什么 ​

  • 不能保证正确：模型会幻觉，动作会失败，必须有校验与失败路径（15、16）。
  • 不天然安全：它会盲信外部内容与自身输出，安全靠工程约束（14）。
  • 不天然幂等：循环重试可能重复写外部系统，需幂等设计（15）。
  • 成本/延迟不确定：循环步数不定，需设上限与预算（08、18）。

六、选型：什么时候该用 Agent ​

先判断任务路径是否真的需要运行时决策，再判断这份灵活性是否值得承担治理成本：

观察左右两侧的路径形态：左侧输入沿固定传送带经过预设节点，右侧操作者会根据地图和观察结果重新选择工具与路线。

确定性 Workflow 与动态 Agent 的控制流对比：固定预设路径对比基于观察反馈的动态选路

图 4：Workflow 追求可预测的固定路径；Agent 用反馈换取动态适应能力，也因此更难测试和估算成本。

如果任务可以完整画成左侧的固定路径，优先使用 Workflow；只有中间结果会实质改变后续动作时，右侧的 Agent 闭环才有明确价值。

这棵决策树给出的是默认策略：先选择最简单、最确定的实现，只有动态路径带来明确价值时才增加自主性。

适合上 Agent 的信号：

  • 任务步骤因输入而异，无法预先写死流程。
  • 需要动态选择在多个工具/数据源中如何组合。
  • 中间结果会改变后续路径（如排障：先看指标再决定查什么）。

不适合（用确定性工作流更好）：

  • 步骤固定、顺序明确（如「读文件→转换→写库」）。
  • 对可预测性、延迟、成本要求极高，容不得模型飘忽。
  • 高频、低价值、强合规的批量操作。
python
def should_use_agent(steps_fixed: bool, needs_dynamic_tools: bool,
                     high_predictability_required: bool) -> str:
    """一个极简的选型启发式（仅辅助思考，不替代具体评估）。"""
    if steps_fixed and not needs_dynamic_tools:
        return "用确定性工作流（见 09），不需要 Agent"
    if high_predictability_required and not needs_dynamic_tools:
        return "用工作流 + 少量模型节点"
    if needs_dynamic_tools:
        return "考虑 Agent，但务必加校验/审批/预算上限"
    return "先用最简单的方案（单次模型调用或工作流）验证需求"

print(should_use_agent(steps_fixed=True, needs_dynamic_tools=False,
                       high_predictability_required=True))

七、最小案例：从“回答问题”到“完成目标” ​

同一个问题，两种形态的差别就在是否有工具 + 循环：

text
【聊天机器人】
用户：mysql-test-01 现在有没有慢查询？
Bot ：（凭训练知识猜）可能有，请检查 slow_query_log……   ← 可能幻觉

【Agent】
用户目标：排查 mysql-test-01 是否存在慢查询并给出建议
Agent：决定调用 get_slow_queries(instance_id="mysql-test-01")   ← 自主选动作
（应用校验参数→在只读权限内执行→返回真实数据）
Agent：基于真实结果判断，必要时再调 search_docs 找优化建议   ← 依结果迭代
Agent：给出结论并停止                                        ← 停止条件

完整可运行的最小 Agent（含参数校验、超时、循环上限、日志、成功/失败轨迹、单元测试）见 06 工具调用。

八、失败路径：最常见的三种误判 ​

观察下面的风险带：珊瑚色对象表示错误计划、无效参数、重复执行、失控循环和越权访问；绿色对象表示校验、审批、幂等、超时熔断、最小权限与审计。

AI Agent 常见失败路径及工程护栏：错误计划、参数不匹配、重复动作、无限循环和权限过大

图 5：Agent 的风险不是靠更强 Prompt 消除，而要在每个动作边界布置可执行、可验证的工程护栏。

图中的护栏必须由应用代码和基础设施落实。模型可以建议谨慎行动，但不能自行证明参数合法、调用幂等或权限最小。

  • 概念误用：把确定性任务硬做成 Agent，导致不可预测、难测试、成本高。
  • 把编排责任推给模型：期望「写好 Prompt 就安全」，忽视代码级校验与权限。
  • 无停止条件：循环不设上限，模型反复调用工具形成「刷步数」。

九、测试与验证 ​

  • 为「是不是 Agent 场景」写决策记录：列出步骤是否固定、是否需动态工具。
  • 对已上线 Agent，统计任务完成率、平均循环步数、工具调用成功率、人工接管率，判断自主决策是否带来净收益。
  • 回放成功与失败轨迹，断言工具选择、参数、状态转换和停止原因；不能只检查最终文案“看起来是否合理”。

十、安全与权限 ​

Agent 越自主，攻击面越大。任何具备写能力的 Agent 都必须：默认最小权限、高危操作人工确认、外部内容不可信。详见 14 安全、13 HITL。

十一、性能与成本 ​

自主 Agent 的成本与延迟随循环步数增长且不确定。务必设置最大步数、max_tokens、单任务预算上限（18）。

十二、框架差异 ​

  • LangChain create_agent（1.0）、LangGraph（1.0）、OpenAI Agents SDK、CrewAI、AutoGen/Microsoft Agent Framework 对「Agent」的抽象各异，但都逃不开本章的组成模块与边界。选型见 20。

十三、面试复述与迁移练习 ​

1. 面试复述 ​

Agent 与 Workflow 的核心区别是控制流归属。Workflow 的步骤和分支由开发者预先定义；Agent 则由 LLM 根据目标、状态和工具观察动态选择下一步。但模型只负责提出动作，参数校验、权限、执行、预算和审批仍由应用代码负责。生产系统通常先使用确定性 Workflow，只在路径无法穷举且动态决策确有收益的局部引入 Agent。

回答追问时继续展开三个点：为什么需要动态决策、如何约束工具权限、用什么指标证明 Agent 比 Workflow 更合适。

2. 迁移练习 ​

选一个你熟悉的自动化任务，例如 SQL 审核、告警归因或文档问答，完成以下判断：

  1. 写出它的目标、状态、可用工具和停止条件。
  2. 标出哪些步骤完全确定，哪些步骤必须依据中间结果动态选择。
  3. 为每个写操作补充参数校验、最小权限、幂等键和人工审批要求。
  4. 如果去掉 LLM 决策后任务仍可稳定完成，说明它更适合 Workflow，而不是 Agent。

十四、关联章节 ​

检索关键词 ​

Agent 定义 Agent 与聊天机器人区别 Agent 与工作流区别 Copilot RPA 是否该用 Agent Agent 组成模块

官方来源 ​

  • 本章为厂商中立的概念综合，不依赖特定框架。框架对 Agent 的具体定义以其官方文档为准（verified_at: 2026-09-07）。

ICP 备案号待补充 · Gitee 主页

Copyright © 2024-2026 MyNote