什么是Agent
一个粗略的解释：Agent就是一个能聊天、能思考、智商250的机器人，有手有脚能够执行具体动作
或者说以下几种概念之一：
-
一个更聪明的聊天机器人
-
一个能够自动去调用工具进行实际操作的
llm -
一个听起来比
workflow更高级的说法
更完善的定义
从工程角度来看，Agent就是一个围绕实现目标/问题持续推进执行任务的系统
具备的能力：
-
接收目标/问题，不是简单的单轮对话，不是简单的输入，Agnet是有上下文工程的，上下文工程+提示词工程形成了记忆层，那么Agent是有记忆功能的，在不撑爆上下文的情况下，都属于这一轮对话
-
根据中间结果决定后续的操作,在需要时调用工具 ，将接收到的目标交给
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 往真实系统推进，顺序最好是：
-
先把目标缩窄
-
明确状态结构
-
给工具调用加异常处理
-
定义结束条件和预算上限
-
增加日志、追踪和人工接管点
而不是：
-
先换更强模型
-
再堆更多 Prompt
-
然后希望系统自己变稳定
后者通常没有用。
小结
Demo 和真实系统的差别，不在于"规模更大"，而在于"约束更多"。
一个 Agent 真正难的部分，往往不是让它第一次成功，而是让它在复杂输入、工具波动、预算限制和失败情况下仍然可控。
这也是为什么学习 Agent 时，不能只学"怎么搭出来"，还要学"为什么它会坏"。