概述

AI Agent（智能体）是以大语言模型（LLM）为决策核心，能够感知环境、调用外部工具、并自主进行多步规划与行动来完成给定目标的一类系统。它的关键特征是”自主性”——你给出目标，由模型自己决定下一步做什么、调用哪个工具、是否继续，直到任务完成。

普通的聊天机器人是”你问一句、它答一句”，一次调用就结束。Agent 则是”你给一个目标，它自己拆解、调用工具、观察结果、再决定下一步”，循环往复直到把事办成。这篇笔记把 agent 的概念、组成、与 workflow 的边界、流行实例，以及在 Dify 平台上的落地方式一并记下来，方便日后选型时快速翻阅。

核心概念

Agent 与普通 LLM 调用的区别

理解 agent，先看它和”直接调一次 LLM”差在哪。核心差别在于谁来决定下一步，以及模型能不能动手做事。

对比项	直接调用 LLM	Agent
交互方式	一问一答，单次调用	给定目标，多轮自主循环
能否动手	只能生成文字	能调用工具（搜索、执行代码、读写文件、调 API）
谁决定下一步	人	模型根据中间结果自己决定
典型形态	ChatGPT 问答	Claude Code 改完整个项目

一句话：给 LLM 装上”手脚”（工具）和一个”自主循环”，它就从问答工具变成了 agent。

核心组成

一个典型 agent 由四块拼成：

LLM（大脑）：理解目标、做推理与规划、决定”下一步该干什么”。它是整个系统的决策中枢。
Tools（工具）：模型本身只会输出文字，办不了实事，所以给它一组工具——搜索引擎、网页抓取、代码执行、shell 命令、读写文件、查数据库、调第三方 API 等。模型通过输出一段结构化的工具调用请求来使用工具，系统执行后把结果再喂回去。
Memory（记忆）：分两层。短期记忆是当前对话上下文（context window 里的内容）；长期记忆是把信息存到外部（如向量数据库），需要时再检索回来——这正是 RAG（检索增强生成）常用的地方。
Loop（控制循环）：把上面三者串起来的调度逻辑，负责”思考 → 行动 → 观察 → 再判断”的反复迭代，并控制何时停止。这是 agent 区别于一次性调用的根本。

控制循环：ReAct 与 Function Calling

agent 的”自主多步”靠控制循环实现。最经典的范式叫 ReAct（Reason + Act，推理与行动交替）：模型先推理（Reason）下一步该干嘛，再行动（Act）调用工具，拿到观察结果（Observe）后判断是否达成目标，没达成就继续循环。

用 Go 伪代码把这个循环写出来，结构一目了然：

// agent 主循环：模型自己决定调哪个工具、循环几轮
func runAgent(goal string, tools map[string]Tool) string {
    messages := []Message{{Role: "user", Content: goal}}

    for i := 0; i < maxIterations; i++ { // maxIterations 是安全阀，防止无限循环
        resp := llm.Call(messages, tools) // 把目标、历史、可用工具一起交给模型

        if resp.ToolCall == nil {
            return resp.Content // 模型认为不需要再调工具，直接给出最终答案
        }

        // 模型决定调某个工具，执行后把观察结果塞回上下文，进入下一轮
        result := tools[resp.ToolCall.Name].Run(resp.ToolCall.Args)
        messages = append(messages, asObservation(result))
    }
    return "已达到最大迭代次数" // 超出上限仍未完成，强制停止
}

ReAct 早期靠”提示词约定 + 解析模型输出的文本”来识别工具调用；后来主流模型原生支持 Function Calling（函数调用），模型直接输出结构化的调用请求（工具名 + 参数），无需再靠文本解析，更稳定。两者解决的是同一件事——让模型”开口要工具”，只是实现机制不同。

Agent 与 Workflow 的区别

这是实践中最容易混淆、也最影响选型的一条边界。判断口诀只有一句：

下一步走哪条路，是人提前写死的，还是模型现场决定的？

路径由模型现场决定 → Agent。没有预设路径，模型自由组合工具、可连续调多次、能自我纠错。
路径由人提前画死 → Workflow（工作流）。流程图是事先连好的固定轨道，模型至多是某个节点里的一个零件。

对比项	Workflow	Agent
路径	人提前画死的固定分支	无预设，模型自由组合
模型角色	流程里的一个节点（如做一次分类）	全程掌舵，决定调几次、调哪些
能否超纲	不能，没画的路走不了	能，可连续调多工具、自我纠错
稳定性	高，可控、省 token、好排错	低，自由度高但易跑偏
适合	路径可穷举的确定性任务	事先无法穷举路径的开放任务

需要点破一个细节：“流程里某个节点用了 LLM 做判断”并不等于 agent。比如用模型做一次”意图分类”再走预设分支，整体结构仍是 workflow——因为岔路口是人画死的，模型只是在固定的几条路里二选一，不能自己开新路。这一点在后文的案例里会具体展开。

流行的 Agent 实例

按用途分类比单纯罗列更有体系。以下均为已成熟、被广泛使用的代表（快速变化领域，具体版本以官方最新为准）。

编程类

Claude Code：命令行 / IDE 里给目标，自主读写整个项目、跑命令、改代码、修 bug。
Cursor：AI 原生代码编辑器，agent 模式可跨文件自主改代码。
GitHub Copilot（Agent 模式）：从行内补全进化到能接管 issue、自主提 PR。
Devin：主打”AI 软件工程师”，端到端独立完成开发任务。
开源代表：OpenHands（原 OpenDevin）、Aider、SWE-agent（常用于刷 SWE-bench 真实 issue 修复基准）。

通用任务及电脑操作类

OpenAI Operator / ChatGPT Agent：自主操控浏览器，订票、填表、下单。
Anthropic Computer Use：让模型像人一样看屏幕、移动鼠标、点击键盘操作电脑。
Manus：通用型自主 agent，主打”给个任务全自动跑完”。

研究及搜索类

Deep Research（OpenAI、Gemini、Perplexity 各有一版）：给一个研究问题，自己多轮搜索、读大量网页、交叉验证后产出带引用的报告。这是 agent 范式里很典型的一类。

开发框架或平台

可以用来自己搭 agent

工具	定位
LangChain / LangGraph	最主流的编排框架，LangGraph 专做有状态的多步 / 多 agent 流程
LlamaIndex	偏检索增强（RAG）+ agent
AutoGen（微软）	主打多智能体协作对话
CrewAI	用”角色分工的团队”隐喻组多 agent
OpenAI Agents SDK / Claude Agent SDK	模型厂商官方的 agent 开发套件
MCP（Model Context Protocol）	Anthropic 提出的开放协议，规范 agent 如何接外部工具与数据源，相当于工具生态的”USB 接口标准”

一个判断供建立选型直觉：目前落地最好、价值最清晰的是”编程类”和”研究/搜索类”——因为这两类任务环境干净、结果可验证（代码能不能跑、引用对不对），agent 不易跑偏；而”自由操作电脑/浏览器”那类潜力最大，但也最不稳定。

Dify 平台

Dify 是什么

Dify 是一个开源的 LLM 应用开发平台，核心卖点是低代码 / 可视化：不用从头写代码，在网页界面上拖拽、配置，就能搭出基于大模型的应用，再一键发布成 API 或网页应用。可以理解成”大模型应用的搭建工作台”，定位类似 LangChain，但形态差别很关键。

对比项	LangChain/LlamaIndex	Dify
形态	代码库（写 Python / JS）	平台 + 可视化界面
门槛	要会编程	拖拽配置为主，低代码
交付	自己部署	内置后台、API、前端页面
适合	开发者深度定制	快速搭原型、团队协作

它通常打包了可视化编排画布、RAG 知识库（上传文档自动切分 + 向量检索）、多模型接入、提示词管理、对话日志监控等能力。同类平台还有 Coze（字节，国内为扣子）、n8n（偏自动化工作流，近年加了 AI 节点）、FastGPT（偏知识库问答）。

Dify 能做出 agent 吗？

能，但不一定——取决于用哪种应用类型。Dify 一般提供几种形态：

应用类型	是不是 agent	说明
Chatbot（对话助手）	否	一问一答，本质是包装好的 LLM 调用 + 提示词
Workflow / Chatflow（工作流）	否（偏 workflow）	在画布上把节点连成固定流程，路径人画死
Agent 模式	是	配一组工具，由模型自己决定调哪个、循环几轮

所以严谨的说法是：Dify 本身是”造应用的平台”，不是 agent；它造出的东西里，只有 Agent 模式是 agent，Chatbot 和固定 Workflow 不是。

Dify Agent 模式配置示例

以”技术资料调研助手”为例：丢给它一个技术问题，它自己上网搜索 + 查内部知识库，综合后给出带依据的回答。在 Dify 里”创建应用 → 选 Agent”，逐项配置：

基础设定

配置项	取值	说明
应用类型	Agent	区别于 Chatbot / Workflow
模型	选支持工具调用的模型	Function Calling 依赖模型能力
Temperature	0.2	调研类要稳，调低
推理模式	Function Calling（模型原生支持时）；否则 ReAct	决定 agent 如何选工具
最大迭代次数	5	循环上限，防止无限调工具烧 token

指令（提示词）——给 agent 定行为准则：

你是一名严谨的技术调研助手。回答技术问题时遵循：
1. 先判断是否需要外部信息；需要时调用搜索工具或检索知识库。
2. 不要凭记忆编造版本号、API 名称，拿不准就去查。
3. 最终回答要分点、给出信息来源。
4. 信息不足时明确说明，不要硬答。

工具（Agent 的手脚）——这是 Agent 模式区别于 Chatbot 的核心：

内置工具：Google Search / Tavily Search（联网搜索）、Web Scraper（抓网页正文）。
知识库检索：把上传的内部文档建成知识库后挂上，agent 按需检索（RAG）。
自定义工具：通过 OpenAPI / Swagger 规范导入公司内部 API。
工作流即工具：把一个 Dify Workflow 封装成工具供 agent 调用。

每个工具都要写清”工具描述”，告诉模型什么时候该用它——这段描述写得好坏，直接决定 agent 调不调对工具，是调 agent 时最需要打磨的地方。

配好后提问”Redis 7 的多线程模型和 6 比有什么变化？”，agent 内部循环（可在调试面板逐步看到）大致是：

迭代1：模型判断需查证 → 调用 Google Search("Redis 7 multithreading changes")
        ← 拿到搜索结果摘要
迭代2：觉得还需细节 → 调用 Web Scraper(权威链接)
        ← 拿到网页正文
迭代3：判断信息足够 → 不再调工具，综合输出带来源的回答

这就是 ReAct / Function Calling 循环在 Dify 里的可视化落地，不用写一行循环代码。

实战：用 Dify 做 WEB 平台问答助手

工作中遇到一个需求：做一个安卓 WEB 端的智能助手，主要用来以问答的形式操作 WEB 平台——用户用自然语言说出要查什么，助手去后台取数并以聊天形式回复。这个功能我用 Dify 来实现。

具体做法是事先在 Dify 中设计好一条流程：用户说出要查什么，先判断查询类型——如果是查 ES 就走 ES 查询工具，如果是查 API 就走 API 查询工具（MCP），最后把查询结果组织成聊天回复发给用户。把它放在这里，正好用来把前面讲的”workflow vs agent”边界落到实处。

示例视频

Android助手演示视频

它属于 workflow 还是 agent

属于 workflow（准确说是 Dify 的 Chatflow），不是严格意义的 agent。

判断依据还是那句口诀——“走 ES 还是走 API 这个岔路口，是谁决定的”。描述里”提前在 Dify 中设计了一个流程“已经给出答案：那条”if 查 ES → ES 工具 / if 查 API → API 工具”的分支，是事先在画布上连好的固定路径。

整条路是人画死的，模型只在”意图判断”节点被调用一次做分类。这正是 workflow 的特征：路径固定，模型是流程里的一个零件。

这里要点破前文埋下的那个细节：哪怕”判断是 ES 还是 API”用了模型，也不等于 agent。区别在于——

	这个助手的 Chatflow	真正的 Agent
模型角色	在指定节点做一次分类（ES 还是 API）	全程掌舵，决定调几次、调哪些、要不要再调
岔路口	人提前画好的两条，模型只能二选一	无预设路径，模型自由组合工具
能否超纲	不能，没画的路走不了	能，可连续调多工具、自我纠错

如何改造成真正的 agent

要跨过这条边界，把”人画死分支”换成”模型现场决定”，改动如下：

换应用类型：从 Chatflow 改建为 Agent 应用。
去掉固定分支：删掉”if ES / if API”那个预设的意图判断与分流节点。
把工具都挂上：将 ES 查询工具和 **API 查询工具（MCP）**两个都直接挂给这个 Agent，不再事先指定谁先谁后。
写好工具描述：给每个工具写清用途，例如”此工具用于查询 ES 日志 / 索引数据””此工具用于查询 XX 业务 API”，让模型据此自行判断该调哪个。
设好迭代上限：配置最大迭代次数，给模型自主多步留出空间（例如先查 ES 发现不够，再去查 API）。

改完之后，”走哪条路”就从”人画死”变成了”模型现场决定”，甚至能自主组合多次查询——这才跨过了 agent 的分界线。

不过要补一句选型判断：这个助手原来的 Chatflow 做法没毛病，在生产里往往更合适。查询场景只有两条路、结果可控，用 workflow 画死反而更稳定、更省 token、更好排错。agent 的自主性在这种确定性场景里是负担而非优势——它真正的价值在于”你事先无法穷举所有路径”的开放任务。不是 agent 就高级，选型要看任务的确定性。

小结

要点	一句话记忆
Agent 是什么	LLM 作大脑 + 工具 + 记忆 + 自主循环，给目标自己多步完成
与普通 LLM 调用的区别	能动手（工具）、自己决定下一步（自主循环）
核心循环	ReAct（推理-行动-观察）/ Function Calling，配最大迭代次数做安全阀
Agent vs Workflow	路径模型现场决定是 agent，人提前画死是 workflow
Dify 的定位	造应用的平台，不是 agent；只有其 Agent 模式产出 agent
选型原则	路径可穷举的确定性任务用 workflow，开放任务才用 agent

延伸方向：MCP 协议如何统一 agent 的工具接入、多 agent（Multi-Agent）协作的分工模式，以及 RAG 与长期记忆的工程实现。

Agent 学习笔记与 Dify 的使用

概述