Agent Basic 完整篇

什么是Agent

一个粗略的解释：Agent就是一个能聊天、能思考、智商250的机器人，有手有脚能够执行具体动作

或者说以下几种概念之一：

• 一个更聪明的聊天机器人

• 一个能够自动去调用工具进行实际操作的llm

• 一个听起来比workflow更高级的说法

更完善的定义

从工程角度来看，Agent就是一个围绕实现目标/问题持续推进执行任务的系统

具备的能力：

• 接收目标/用户输入的问题，不是简单的单轮对话，不是简单的输入，Agent是有上下文工程的，上下文工程+提示词工程形成了记忆层，那么Agent是有记忆功能的，在不撑爆上下文的情况下，都属于这一轮对话。这个其实就是Memory实现的，在下面会详细讲解

• 根据中间结果决定后续的操作,在需要时调用工具，将接收到的目标交给llm进行思考，总结、压缩、排序上下文，然后拆解任务，明确需要调用的工具交给执行层去执行，执行得到的结果就进入下一轮循环，把该结果、执行的错误信息放到记忆层进行下一轮思考

• 直到实现了目标就不再进行循环，即得到了结束条件就输出结果停止循环

所以，Agent更强并不是模型更强，模型本质上还是市面上比较牛逼的llm，更重要的是执行目标的系统闭环更完整了，就是说他能够更精确完成用户的目标，而且能够进行实际的操作

Agent没有我们想得这么神

在大多数的工程场景下，更应该把Agent看成：一个由llm大模型驱动的、可以根据当前状态/执行结果决定下一步动作该如何执行的任务执行系统

很多使用的Agent并没有我们想得这么高大上，只是比普通的ai聊天机器人多了几个关键的能力

Agent的最小闭环

先看最简单的Agent闭环，不需要考虑复杂框架：

举个例子：分析今天某A股是否存在异常风险

一个最小Agent的工作流程：

• 接收目标：分析A股是否存在风险

• 大模型去读取当前任务目标和已有上下文

• 思考，需要获取什么市场信息

• 调用工具，查询K线走势、成交量、波动幅度、相关新闻

• 返回结果，根据返回结果更新状态

• 信息不足，循环回去，再思考看缺什么，继续补充查询信息

• 信息充足，输出结果，停止循环

核心：围绕目标不断地推进任务执行，Agent你可以认为他只有一个目的，就是精确地实现你的需求

Agent和普通LLM App的区别

普通LLM App通常就是一次响应

Agent他是一个循环，是持续执行的，知道满足目标再停止循环

Agent通常包含什么

一个完善点的Agent通常包含以下部分：

• state：当前任务状态

• Tools：查询、搜索、执行、写入等外部功能

• Memory：会话内或跨会话记忆

• Policy / Guardails：限制不要乱进行操作

• Evaluator：判断结果是否足够好

越接近真实业务需求，这些模块就越重要

有一个坑

市面上现在很多Demo只要实现了大模型调用工具这个功能就自称Agent

但是如果你这个系统：

• 没有明确的状态

• 没有明确且完整的闭环

• 没有明确的结束条件

• 无法根据每一步执行得到的结果去进行调整对下一步进行操作

其实就仅仅是一个内置了很多工具的LLM而已，未必就是一个完整的Agent

判断一个系统是不是Agent

不需要看他用了什么框架、也不需要看他会不会调用工具，就从最基本的概念去看：

• 是否能围绕目标持续推进任务执行

• 是否会根据中间状态的改变而改变下一次操作的行为

• 是否为一个闭环系统，不是一次性生成结果的

总结

Agent的核心是：有手有脚，能够真正做出执行功能

一个真正有价值的Agent，更看重的是系统层面能处理的事情：

• 对任务进行拆解，多步任务

• 感应外部环境的变化从而做出改变

• 调用工具实现工具协作

• 状态更新，改变行为

• 在不确定条件下进行决策预测

workflow和Agent的区别

这个问题是在学习Agent的时候最容易混淆的一个问题之一

至少有三类不同的系统：

• 普通LLM App

• Agent

• WorkFlow

判断标准

普通LLM App

一次输入一次输出

例如：

• 问答助手，deepseek、豆包

• 摘要工具

• 翻译工具

• 结构化信息抽取

问答很直接，但是涉及多步执行的复杂问题就不行了，通常不负责多步执行

WorkFlow

执行路径主要由开发者预先定义好，Agent他是自身是已经定义好了执行路径的，workflow是可以通过用户/开发者来自定义的

举个例子：

• 先检索，再总结，再格式化输出

• 收到工单后，分类、路由、写评价

• 输入简历后，抽取信息、评分、写评价

workflow很有价值，而且在很多业务中workflow就已经足够了

Agent

系统会根据中间状态/中间过程得到的某个结果来决定自己下一步该如何进行任务执行操作

执行路径是由每一次任务执行后得到的结果进行状态更新后去判断的，判断到底走那一条执行路径

真正的区别

在于下一步的执行路径是根据上一步得到的结果来判断的还是说已经确定好了，几乎写死的

workflow的大部分执行路径已经由开发者制定好了那么就可以认为是写死的

而Agent下一步该做什么会由上一步的执行结果来决定，就是系统会在运行的过程中去判断下一步该如何执行

举个例子

分析某个A股今天是否有异常风险

workflow：开发者可能已经提前写好执行流程了：

• 拉取近一周的数据价格

• 拉取成交量

• 拉取相关的新闻

• 拉取走势图

• 把这些统统交给LLM进行总结判断

• 输出风险等级

这个系统一样是将一个目标拆分成多个任务进行多步执行，系统进行多步执行，但是他的路径是基本已经确定了

Agent：

• 先看价格是否正常

• 价格正常就看成交量

• 不正常就直接返回结果

• 成交量正常就看相关新闻消息

• 成交量不正常就直接返回结果

• 查不到相关新闻消息或消息不足就看走势图并且社交媒体上进行查找

• 得到足够的信息后就返回结果

很显然跟workflow的区别是：下一步操作一直依赖于上一步的执行结果，虽然和workflow一样都是分步执行，多步骤实现目标，但是他的路径是很灵活的，并没有写死，这就是典型的Agent行为

为什么在一些业务场景workflow就足够了，不需要用到Agent呢

• 输入稳定(就是输入的目标比较明确)

• 处理步骤固定，不会出现很多分支情况

• 分支数量有限

• 输出结果格式明确

这种场景下使用workflow更便宜，更稳定，更可控

如果非要使用Agent：

• 成本更高

• 延迟更长

• 不稳定

• 调试困难

• 落地麻烦

所以不是说一定要使用Agent，而且不是说Agent越高级越好，需要通过对要实现的目标进行拆分判断到底使用哪个

判断方法

在设计系统前，即在决定使用Agent还是使用workflow前，先想清楚四个问题：

• 任务步骤是否基本固定

• 执行路径是否大多可预先枚举。即执行路径是否已经可以大致确定下来

• 模型是否只负责生成，不负责决定流程，即不需要依赖上一步执行得到的结果

• 是否自已稳定性、可控性、成本，而不在意灵活性

如果基本满足以上条件的话就直接选workflow

• 是否需要根据中间结果来动态选择工具

• 是否需要在信息不足的时候继续探索

• 是否需要围绕目标持续进行任务执行推进，而不是一次性回答

• 是否存在开发环境和不确定决策

如果基本满足的话就直接选择Agent

关系

在实际工程中，Agent和workflow往往是组合关系，而不是对立关系，不是二选一的

常见的方式是：

• 外层用workflow控制主流程

• 某些节点内部用Agent

例如：

• 主流程：接受任务-选择任务类型-调用不同处理模块

• 某个处理模块内部：用Agent做信息探索和多步分析

总结

如果是确定了工作流程的，有确定性流程的，那么就使用wokflow

如果是负责不确定环境下的动态推进那就使用Agent

Agent的核心组成

不要直接就去看框架代码，我们得先进行系统的拆分

否则就是即使你成功跑出了一个Demo，但是你也说不明白他的逻辑：

• 哪部份负责决策

• 哪部份负责保存状态

• 哪部份负责调用工具

• 哪部份负责限制系统乱跑

如果这些问题你弄不清楚，当后面系统复杂了就很难维护了

不要直接去看框架，不要从框架开始，先从细小的模块开始

一个最小但是比较完善的Agent，五脏虽小麻雀俱全的Agent一般都包括：

• Goal：目标

• State状态

• Model模型

• Tools工具

• Memory记忆

• Planner/policy决策逻辑

• Evaluator / Guardrails评估与约束

不是每个Agent系统都要对这些模块进行完整的拆分，但是你的脑子里得有这种图

Goal目标，系统到底在实现什么

目标的定义：用户的需求

• 任务要解决什么问题

• 输出的格式长什么样

• 任务处理到什么程度算完成

如果目标本身不清晰，Agent往往表现：

• 会做很多无关的动作

• 会进行无限探索

• 输出看似很多很努力，但是没有实际有用的内容

所以很多Agent的问题并不是模型不够强，而是目标定义不够清晰

State系统当前处于什么状态

每执行一次得到的结果就会被更新为当前最新的状态，这个状态决定着下一步该如何执行

他可以包含：

• 当前任务输入

• 已完成的步骤

• 已获取的信息

• 中间分析结果

• 下一步待办

• 是否满足结束条件

如果没有明确的状态，系统每次执行就没有明确的依据，没有明确的限制，每次执行都像是从头开始：

• 上下文混乱

• 重复调用工具

• 无法回复执行

• 很难调试

所以Agent框架强调的是维护方便，可维护

Model负责理解、推理和生成

模型本身通常负责下面几类工作：

• 理解任务

• 解释上下文

• 决定下一步动作

• 生成结构化结果，生成最终数据

模型只是Agent的一个核心组件

Tools工具，让Agent获得外部超能力

没有工具的Agent能力边界是非常狭窄的

工具包括：

• 搜索

• 数据库查询

• API请求

• 文件读写

• 代码执行

• 外部系统操作

工具解决的是仅靠模型本身无法实现的事情

因为模型是预先训练好的，他自身是没有办法获取实时数据的，所以通过调用工具就可以知道实时的A股价格

Memory： 让系统不会总是失忆

记忆可以分为两种：用于当前任务过程中的状态延续，例如

• 会话内记忆

  • 已经查询过哪些数据

  • 前面做过哪些判断

  • 当前分析到哪一步任务

• 跨会话记忆，用于长期偏好、历史记录或用户画像，例如：

  • 用户关注哪些风险指标

  • 过去的分析习惯

  • 历史结论和反馈

大多数Agent需要的都是会话内状态的记忆

Planner / Policy决定接下来做什么

就是根据当前最新的状态/上一次执行的结果来决定该次如何执行，走哪一个分支进行任务执行

这也是workflow和agent的最大差别，workflow是不需要去想走哪一个分支的

• 下一步是否需要工具

• 需要哪一个工具

• 是否还需要继续收集信息

• 什么时候停止返回最终结果

在简单系统中这部份可能只是一个prompt

但是在复杂系统中他可能会变成一套显式的状态机、策略函数或图结构

Evaluator / Guardrails防止系统看起来工作，实际上已经失控了

这部份通常会被Demo忽视，所以才导致Demo不稳定，而且真实系统也离不开这个模块

通常负责：

• 检查输出格式是否正确

• 检查证据是否充足，就是是否有足够的信息返回最终结果

• 检查结果是否越权

• 控制成本、稳定性、延迟和工具调用的次数

• 在必要时触发人工接管

如果没有这些约束，Agent就会：

• 一本正经说废话，给出错误结论

• 为了完成任务不断尝试，不断调用工具，甚至重复调用工具，导致时间和成本直接拉爆

所有模块串起来就是

一个典型的Agent系统理解成下面这个执行流程：

Goal :

-> State 系统状态初始化

-> Planner 做出决策，判断下一步要执行什么操作

-> Model 生成动作或参数

-> Tools 执行外部动作

-> State 将执行得到的结果更新为最新状态，作为下一次执行的依据

-> Evaluator 检查结果

-> 继续循环或返回最终结果

这个表格很重要

建议

在进行Agent开发的时候不要急着选什么框架，核心是分析清楚问题：

• 目标是什么

• 状态里面放什么

• 哪些能力需要通过调用工具来实现

• 哪些决策要交给模型处理，哪些决策可以交给代码进行决策

• 什么时候结束循环返回结果，什么情况下导致失败，什么情况需要人工介入

总结

Agent是一套模块化协作的系统

一定要弄清楚模块间的边界关系

为什么Demo一落地就不稳定

很多人第一次跑Agent的时候，都会经历：

• 本地能跑

• 调用工具也正常

• 甚至样例也通过

但是 当你觉得你的系统差不多可以了，当把他放到业务场景后，就会出问题：

• 任务复杂就会乱跑

• 结果不稳定

• 调用工具成本高

• 运行时间不可控

• 一出错就不知道卡在那个地方

因为Demo是独立的，和真实的业务系统关注的问题不在一个level

Demo关注的是能不能动

一个Demo只需要证明：

• 模型能理解任务

• 工具链能接通

• 系统能完成一个示例流程

所以Demo就会偏向于：

• 乐观输出,认为工具调用是允许的，没有权限问题，成本是最低的

• 短链路

• 调用少量工具

• 单次样例成功

所以Demo放到真实的业务系统中可能成功也可能失败，不能证明这个Demo是长期可行的

真实的系统关注的是会不会坏，能不能解决真实问题

• 用户输入是否稳定

• 外部数据是否可靠

• 工具调用是否会失败

• 系统是否会重复做无效动作

• 出错后能不能恢复

• 成本和延迟能否接受

即真实系统追求的是长期稳定，在多数情况下都能保持稳定执行

常见问题1.目标定义模糊

很多Demo的目标的定义都很宽泛：

• 帮我完成xxx任务

• 帮我分析市场风险

• 给出这个研究的结论

说白了就是连prompt都不会写的

那么目标不清晰就会导致：

• 系统不知道执行到什么时候才结束

• 探索的范围一直扩大，不断膨胀

• 输出的标准不稳定

所以想写好一个Demo关键是先明确好目标，把目标写清楚了

常见问题2.状态没有设计

很多Demo就是把所有的信息一口气全都塞进Prompt中，然后不断不断写

短任务/简单任务可以跑，但是长任务/复杂任务就会出问题：

• 中间结果没有结构化保存，那么下一步执行的操作就没有依据了

• 系统会忘记已经完成了什么任务，执行到哪一步了

• 同一个工具会被重复调用

• 执行中断后无法恢复

这也是为什么State是Agent中最核心的一个模块，如果State处理得不好，就会导致整个系统的瘫痪

常见问题3.工具调用会被过度乐观地看待

在Demo中，调用的工具通常会被看待成：

• 一定可用

• 返回格式一定稳定

• 延迟可以接受

• 没有权限问题

但在真实的系统中：

• API会超时

• 数据格式会发生改变

• 权限失败

• 返回结果会为空或部份丢失

如果你设计的系统没有重试、降级、兜底和错误处理，Agent就会很脆弱

常见问题4.把会思考误认为是可执行

模型很擅长生成看似很合理的解释，但这不表示他就真正完成了任务，例如：

• 说自己分析了，但是没哟真正调用工具

• 说证据充分，但实际上信息不足

• 说已经完成了，实际上没满足业务标准

所以在真实系统中不能只看生成的文本，还要看：

• 执行了什么

• 用了哪些数据

• 每步的结果是否可验证

常见断层 5：没有结束条件和预算控制

Agent 一旦进入循环，如果没有明确约束，就可能不断尝试：

• 再查一个数据源

• 再补一次搜索

• 再换一种问法

• 再试一次工具

这在 Demo 里看起来像“努力”，在真实系统里就是：

• 成本失控

• 延迟失控

• 用户体验崩掉

所以一个可用 Agent 必须有预算和边界，例如：

• 最多调用多少次工具

• 最多运行多少轮

• 超过多长时间必须退出

• 证据不足时是否直接转人工

常见断层 6：没有可观测性

如果系统出错了，但你只能看到最终一句“任务失败”，那几乎没法维护。

至少应该能看到：

• 每一轮状态

• 每一步决定

• 每次工具调用

• 错误原因

• 最终退出条件

这也是为什么很多 Agent 框架后面都会补 tracing、logging、checkpoint 这些能力。

一个更现实的做法

如果你想把 Demo 往真实系统推进，顺序最好是：

1. 先把目标缩窄

2. 明确状态结构

3. 给工具调用加异常处理

4. 定义结束条件和预算上限

5. 增加日志、追踪和人工接管点

而不是：

1. 先换更强模型

2. 再堆更多 Prompt

3. 然后希望系统自己变稳定

后者通常没有用。

小结

Demo 和真实系统的差别，不在于“规模更大”，而在于“约束更多”。

一个 Agent 真正难的部分，往往不是让它第一次成功，而是让它在复杂输入、工具波动、预算限制和失败情况下仍然可控。

这也是为什么学习 Agent 时，不能只学“怎么搭出来”，还要学“为什么它会坏”。

Tool Calling入门

往往Agent和普通聊天应用的差别就是从Tool Calling开始的

因为一旦系统可以调用工具，那么就不局限于基于预训练好的知识/基于参数的知识说话了，而是具备外部行动能力

为什么模型需要工具

如果仅仅只有模型，但是不能调用外部工具的话，就不能实现：

• 获取实时数据

• 查询私有数据库

• 读写文件

• 调用内部系统

• 执行代码

• 与外部API进行交互

模型擅长的是理解、推理、生成

工具解决的是访问外部世界和执行实际动作

所以Tool Calling的真正目的是让系统能够有手有脚，真正做出实际的动作

一个简单的心智模型

可以把工具调用理解成：

模型不应该只给出数据，因为有可能这些数据模型都是假装查询出来的，所以模型应该明确说明：

• 调用了什么工具

• 为什么调用这个工具

• 参数是什么

• 执行结果是什么

程序负责：

• 真正执行工具

• 进行参数校验

• 异常处理

• 把结果返回给系统

工具调用不等于随便开放能力

很多新手在做Tool Calling的时候都喜欢把很多能力一次性暴露给模型：

• 搜索

• 文件系统

• shell

• 数据库

• 浏览器

• 写入接口

在Demo阶段看着确实很cool，但是真正落地到实际开发场景中，就会导致：

• 模型选错工具

• 工具重复调用，调用次数失控

• 参数乱填

• 权限过大

• 调试困难

所以在设计工具系统的时候，不是工具越多越好，功能越多越好，而是越清晰越好，明确需要什么工具

一个好的工具至少要满足

• 职责清晰：工具到底在做什么、边界必须明确

• 输入清晰：输入的参数结构要明确、稳定、可校验

• 输出清晰：返回值格式明确，返回值尽量稳定，方便模型和程序继续处理

• 权限清晰：模型权限不能过大，能不能写、能不能删除、能不能执行命令，都要有明确的边界

• 错误可处理：工具失败时要能区分，能知道是哪个地方出错了

  • 参数错误

  • 权限错误

  • 网络错误

  • 数据为空

否则就会导致系统一失败就不知道问题出在哪里

Tool Calling最容易踩的坑

• 模型假装调用过工具：这是最常见的问题，模型会编一个输出结果，而不是老老实实去发起工具请求去调用工具，所以系统需要显式分区：

  • 模型输出普通文本

  • 模型输出工具调用示意图

• 工具接口设计过于宽泛：如果一个搜索工具同时支持十几种模式，但是没有明确字段，这会让模型很难稳定产生出正确的参数

• 工具返回结果太脏：如果工具返回的是超长原始文本、混乱JSON或不稳定的结构，模型后续也会处理得很差

• 没有调用预算：一旦任务进入循环，系统就会不断进行尝试：

  • 再搜索一次

  • 再调用一次

  • 再换一个参数试一试

  如果没有足够的预算和结束条件，就会一直尝试，成本不可控

工具设计的一个建议

在一开始设计的时候不要想着设计一个多强大多万能的工具，核心是可控稳定：

• 围绕具体的任务列出真正需要的能力

• 每个能力做成边界清晰的小工具

• 优化保证输入输出的稳定

• 然后再逐步补全权限控制、异常处理和预算控制

先可控，再强大

总结

Tool Callling是Agent非常关键的一步，因为他让模型从只会说话变为能够行动

但是工具系统不是插件市场，不是说接入的工具越多越好

需要的是：

• 分工明确

• 接口稳定

• 权限明确

• 错误可控

Momery设计模式

这个词在Agent中都要被神化了

很多介绍都说Agent需要记忆、加个memory就更智能了，但事实上不完全正确

重要的是得拆解清楚，不然很容易把几种不同的东西混在一起

• 当前任务状态

• 会话上下文

• 长期偏好

• 外部知识库

他们都和memory有关，但都不是处于同一个层面

先分清楚三类东西

State

就是当前任务执行过程中的结构化状态

例如：

• 当前任务分析到哪一步

• 已经查询过哪些数据

• 中间结果是什么

• 是否满足结束条件

这更像的是每一步的执行记录，而不是记忆

Short-term Memory

当前会话保留下来的上下文

例如：

• 前几轮对话的内容

• 当前用户刚才补充的约束

• 本轮任务中暂时需要保留的信息

它主要服务于当前任务的连续性

Long-term Memory

跨会话的、跨任务仍然有价值的信息，不局限于当前会话，就是不局限于一个会话中

例如：

• 用户偏好

• 历史决策习惯

• 某类任务的长期背景资料

很多系统其实都不需要使用长期记忆

因为很多Agent场景只需要：

• 当前任务状态

• 当前会话上下文

如果一上来就做长期记忆，就会导致：

• 召回了不该召回的信息

• 旧信息会污染当前任务

• 记忆更像逻辑混乱

• 很难知道该忘记什么

所以不要因为Memory很神就直接上长期记忆，要分析清楚目标，分析清楚要实现的功能

设计顺序

通常是：

• 先设计好State

• 再处理会话内上下文

• 最后再考虑是否真的需要长期记忆

所以很多Memory问题本质上是state没设计好导致的

常见的Memory设计模式

模式1.对话窗口保留

最简单的就是保留最近的几轮对话内容/几轮消息

优点：

• 简单

• 上手快

问题：

• 长任务容易撑爆上下文

• 历史信息结构化程度低

模型2.摘要式记忆

把前面内容压缩成摘要，只保留关键结论

优点：

• 节省上下文，使得上下文没有那么容易被撑爆

• 适合长会话长任务

问题：

• 摘要本身失真

• 被压缩掉的内容可能在当前这一次对话中不重要，但是可能在后面是重要的

模式3.结构化存储

把任务进度和中间结果保存在明确字段里

优点：

• 可调试

• 可恢复

• 适合工作流和Agent系统

问题：

• 设计成本高

模式4.检索式长期记忆

把长期信息存到数据库或向量库中，需要时再召回

优点：

• 不必一直把信息都塞入到上下文

• 适合长期积累信息

问题：

• 召回相关性很难永远稳定

• 容易把知识库检索误当成记忆

Memory和RAG不是一回事

这是一个极大的误区

RAG解决的是：

• 如何从外部知识中取到相关的内容

Memory更关注的是：

• 系统应该记住哪些和当前主体任务相关的信息

两者可以结合一起使用，但他们是不一样的

例如：

• 用户偏好更像长期记忆

• 某篇市场研究报告更像外部知识

那就可以Memory+RAG来实现

设计Memory时最应该问的问题

• 这条信息是当前任务状态还是长期信息

• 它需要跨会话保留吗

• 他如果过期了，会不会误导系统

• 他应该完整保留、摘要保留、还是只在需要时检索

如果这些问题弄不清楚就会导致Memory设计不清楚，系统混乱

总结

Memory就是一套信息保留策略

在大多数Agent系统里，更重要的是把State状态设计清楚，比起直接做长期记忆更重要

当我们真正去做Memory的时候，也要区分：

• 当前状态

• 会话连续性

• 长期信息沉淀

Planning/Reflection/RAG

这是一个及其容易混淆的点

很多教程会同时提到：

• planning

• Reflection

• RAG

然后把他们一起包装成高级Agent能力

但是如果不进行拆解清楚的话，就会出现：

• 该用检索的时候去做规划

• 该做自检的时候去补知识库

• 系统真正缺失的是信息，结果你一直让模型，多思考一下

简单定义

• Planning：解决：下一步应该做什么

• Reflection：解决刚才做了什么，做得对不对

• RAG：解决：现在缺什么信息

三者的职责完全不同

Planning：组织执行路径

Planning关注的是任务推进方式，就是该执行哪一个分支任务

例如：

• 先查询价格还是先查询新闻

• 哪些子任务要先执行

• 如果当前信息不足时下一步该用哪个工具

• 整个任务要分几步推进

Planning的本质是：将目标拆解成后续要执行的动作

它关注的是执行的顺序，而不是关注知识内容本身

什么时候需要Planning

当满足下列特征的时候，Planning会很有用：

• 多步任务

• 路径不固定

• 工具很多

• 中间结果会对下一步执行有影响

如果任务短、工具少、路径固定的话就可能不需要显式Planning

Reflection： 检查结果是否靠谱

Reflection：就是反思，更像是一种会看和自我检讨，分析自己的执行结果是否合理靠谱

例如：

• 当前结论是否有证据支持

• 刚才的工具调用是否真正解决了问题，是否是虚假的工具调用

• 输出是否满足目标

• 有没有逻辑跳步或遗漏

Reflection的本质是：

• 不是无脑一直往下执行，而是每一次执行得到结果后停下来分析一下，刚才执行的过程是否正确，是否有出错

什么时候需要Reflection

当任务结果质量很重要，而且模型经常会：

• 过度自信

• 逻辑跳步

• 工具用得不充分

• 输出形式对了但是内容不扎实

这时Reflection就会很有价值

但是Refletion：

• 会增加Token成本

• 执行时间

• 系统复杂度

所以并不是每一次执行都要进行Reflection

RAG：补充外部信息

模型当前不知道，或者上下文没有，但是系统可以通过外部知识中获取

例如：

• 公司内部文档

• 历史研究报告

• 产品说明

• 外部知识库

• 市场资料

RAG的核心是：获取更多相关的信息，使得信息更完善

什么时候需要RAG

如果任务高度依赖外部知识，而且这些知识：

• 不在模型训练数据里

• 不足够新

• 不足够准

• 不适合全部塞进提示词

那么RAG是很有必要的

一个容易混淆的例子

假设任务是：分析某个A股今天的风险

当系统遇到信息不足时，可能有以下三种不同的处理方式：

• Planning：决定下一步去查什么信息

  • 先查价格

  • 再查成交量

  • 再查新闻

• Reflection：检查当前结果/结论是否站得住，证据是否充足

  • 只有价格波动就高风险吗，证据够吗

  • 当前结论是否太片面

• RAG：补回系统缺失的信息

  • 取回历史风控规则

  • 召回某类异常模式说明

不要把缺信息误认为是要多进行思考

如果模型当前缺的是外部知识，你让他Planning是没用的

如果系统当前缺的是结果校验，你补 RAG 也没用。

如果真正缺的是任务拆解，你一直 Reflection 也没用。

所以在设计系统时，应该先判断当前缺的是哪一类能力：

• 缺路径组织

• 缺结果校验

• 缺外部信息

对应地选择 Planning、Reflection 或 RAG。

建议

在开始开发的时候不要把三者都做全了

更合适的顺序一般是：

• 先把任务主流程做通

• 再看是否真的缺外部知识，如果是就用RAG

• 再看是否真的经常输出不稳定，如果是就用Reflection

• 任务复杂到一定程度就需要进行任务拆解，就用Planning增强

总结

你可以再记一遍这三个关键词的职责：

• Planning：安排动作

• Reflection：检查质量

• RAG：补充信息

这三个概念一旦分清，后面看 Agent 框架和系统设计时就不会总觉得它们像一团黑话。

单AgentVS 多Agent

大多数实际项目的第一版基本都是从单Agent做起的

因为：

• 成本低

• 状态更集中

• 调试更容易

• 行为更容易解释

多Agent真正有价值的前提是：任务足够复杂，任务真的存在明确的职责分离，就比如在LLM没爆火前前后端的分离，但是现在还需要吗

单Agent什么时候更合适

• 目标比较单一

• 状态可以集中管理

• 工具集不算特别复杂

• 不需要多个独立视角长期博弈

• 系统首先追求稳定而不是花哨、展示

那么就用单Agent更合适

例如：

• 风险初筛

• 文档问答

• 单任务研究分析

• 工单分类和处理

这类任务往往一个Agent加上合适的工具调用和状态管理就能做好

多Agent真正有意义的场景

• 职责分工明确：例如一个角色收集信息、一个角色审核和裁决，他们的输入和输出、关注点确实是不同的

• 上下文压力大：不同子任务需要不同的上下文，如果硬塞到一个Agent就会导致上下文混乱，又长又乱

• 任务可并行：例如多个独立方向可以同时搜集信息，然后最终汇总到一个中心点

• 需要明确对抗或复核机制：例如一个Agent负责生成方案，另外一个负责找漏洞，第三个负责最终裁决

这样的多Agent才是真正有价值的

多Agent最容易被低估的成本

因为多Agent必然会导致系统复杂度同步上升

一旦进入多Agent，马上就要处理：

• Agent之间怎么进行通信

• 谁维护全局状态

• 谁拥有最终决策权

• 冲突结论怎么解决

• 多轮协作合适停止

• 成本和延迟怎么控制

多Agent不是把单Agent多复制几份者恶梦简单

误区：把prompt分角色就以为自己做了多Agent

例如：

• 同一个模型

• 同一个上下文

• 同一个执行循环

• 只是换了几个system prompt名字

这更像是多角色提示词，不一定真的构成了有意义的多Agent系统

真正拆分成多Agent系统的，通常会有更清晰的：

• 角色边界

• 状态边界

• 输入输出边界

• 协作协议

判断标准

在决定是否上多 Agent 前，先问自己这几个问题：

1. 单 Agent 真的做不好，还是我只是觉得多 Agent 更高级

2. 各角色之间是否有明确且稳定的职责边界

3. 把它们拆开后，系统复杂度增加是否值得

4. 是否真的需要并行、复核或对抗式协作

如果这些问题答不清楚，就先别拆。

演进路径

比起一开始就上多 Agent，更推荐这样做：

1. 先做一个状态清晰的单 Agent

2. 找出真正的瓶颈

3. 只在必要处拆出子 Agent 或子模块

4. 让多 Agent 服务问题，而不是服务演示效果

这样做通常更稳，也更容易长期维护。

总结

多Agent不是升级版皮肤，也不是默认更先进。

你可以先记住一句很实用的话：

如果单 Agent 还没做稳，多 Agent 大概率只会把问题复制并放大。

先把单 Agent 做扎实，再决定哪些地方值得拆分，通常是更成熟的工程路径。

接下来你可以进入：

• learn-langgraph

因为当你真正开始关心状态、节点、分支和协作时，才会需要更强的系统编排能力。