《Building effective agents》——agent笔记【未完待续】

阅读的是这篇文章：产出大模型Claude的anthropic公司的文章《Building effective agents》 https://www.anthropic.com/research/building-effective-agents

一、什么是agentic系统？workflow和agent的区别是什么？

agentic系统就是：各种可以调用大模型以及多种工具，以预定义的或者自动的流程完成复杂任务的系统

但是agentic系统可以再细分为agent和workflow：

workflow：可以调用大模型和多种工具，但是以一个预先定义好的流程工作的系统。就像工厂流水线一样，有很多步骤，但每个步骤是事先确定的。

agent：也可以调用大模型和多种工具，但是流程是不是预先定义好的，由系统根据每个任务的执行的反馈自动决定下一步做什么。

可见关键区别在于，系统的流程是预先定义好的固定流程，还是可以根据之前步骤的反馈来自动确定下一步的任务。只要是固定的，那不管流程多长多复杂，都是workflow。

LLM（大模型）应用的系统从简单到复杂可以分为如下几个，其中3和4都属于agentic的系统，但每个相邻两层之间的边界有可能是模糊的，每一层也可以作为下一层的组成部分：

1.单次LLM调用

2.block：增强型的LLM系统，比如RAG（先搜索一些问题相关的资料，再把问题和相关资料一起给大模型）

3.workflow

4.agent

二、应该怎么选择要使用什么样的系统？

越灵活的系统，复杂程度越高，消耗token成本和耗时可能都会增加。所以系统绝不是越复杂越好，而是在效果和代价之间进行平衡。一些简单任务，如果只需要结构简单的系统就能满足要求，就不要设计agentic系统。

三、什么时候使用框架？怎么用框架？

1. 首先，什么是框架？就是一些已经打包好的工具，用于开发agentic系统的应用。就好像你通过盒马app买菜，而不是自己到菜市场跑很多个摊位买菜。盒马就相当于一个买菜的框架。

2. 框架有哪些？

文中列举了一些国外的框架。包括langchain的LangGraph等

国内的有一些国内更熟悉的，可视化操作的框架，比如扣子、fastgpt、Dify等等

3. 用框架的优缺点：

优点：适合新手第一次开始上手时，可以忽略很多细节，直接打通一个系统。

缺点：这个框架的代码做了很多复杂抽象的封装，很难debug，也很难改进和定制你想要的功能，要看到底层的提示词都很麻烦。（因为不管怎么封装，最终都是拼成一个提示词文本，调用某个大模型比如gpt、kimi等等）

4. 最后是建议：

如果不是开发人员，只想短暂地体验尝鲜一下，可以用。

但由于上述缺点，开发人员，都建议不要使用框架，任何功能自己写。

就好像你在自己家里给自己做菜，你用盒马买海鲜没问题。如果是一家海鲜饭店的大厨，你进货不会用盒马，你和盒马是同类型的进货商，只是盒马规模比你大，你可以绕过盒马到更上游的渠道进货，选择更多，自由度更大，价格也会更便宜，海鲜也会更新鲜，因为不需要先存到盒马的仓库。

四、构建block、workflow、agent

1.构建block：增强型LLM

1.构建block：增强型LLM——示意图

“增强”就是指，在用户输入问题之外，获得一些额外的有用信息，用于帮助大模型更好的回答问题。

这个额外信息的获取方式有：

1.1.搜索：具体又可以分为：从向量数据库搜索、从互联网搜索等。比如用户问某个新的明星的信息，大模型也许不知道，就需要互联网搜索，然后根据搜索结果回答用户。

1.2.调用工具：比如用户要查询某个景点的出行规划，或者直接问天气，可以调用查询天气的api获得当地天气信息，可以更好地帮用户规划行程。

1.3.记忆：就是从之前的聊天记录中，获得用户的个人信息、偏好，或者已经提供过的信息。比如根据聊天记录，知道用户是阿森纳球迷，用户这次问“我最喜欢的球队今天晚上有没有比赛？”就可以读取记忆，得知，用户问的是“阿森纳今天晚上有没有比赛”，后续可以都互联网搜索，或者某些工具查询该信息。

以下的所有大模型应用，都假设拥有上述3种增强能力。

以下就都属于agentic系统了

2.workflow：链式大模型调用

2.workflow：链式大模型调用——示意图

即一个大模型的输出结果，直接或者加工后作为下一次大模型调用的输入。也可以中间有一个判断节点（gate），根据上一步的结果判断是否要提前结束。

举例：英超球队信息查询系统。

第一次调用大模型，提取用户提到的英超球队名称

gate：判断如果没有提取到任何球队，就结束。如果有，就继续。

第二次调用大模型：将球队名称和用户问题，输入大模型，提取用户想要问球队的什么信息：积分榜排名？还是上一场比赛的结果？还是下一场比赛的时间

第三次调用大模型：查询相关信息之后，生成回答。

文中的例子：用户需要大模型根据要求写一篇文章

第一次调用：生成一个大纲

第二次调用：判断这个大纲是否满足用户的要求

gate：上述判断的结果，不满足就退出，满足就继续

第三次调用：根据大纲写出完整文章

PS问题：为什么不能一次做完，要分步骤。因为大模型还没有那么聪明，一次说太多，容易完成质量下降，漏了一些指令不遵守。人也是一样的。所以最好复杂的任务进行分解，每次完成一个小任务。

适合场景：如果你的场景很简单，也能清晰固定地分成几个子任务，那么这种结构就很合适

3.workflow：路由

3.workflow：路由——示意图

路由，就是问题分类、场景分类、任务分类。

例子：

对一个旅游问答系统，对用户问题进行如下分类：

a.日常闲聊类问题（比如：你好，你是谁？）

b.景点信息查询问题（比如：九寨沟的门票多少钱？）

c.目的地推荐类问题（比如：上海周边2日游，有哪些地方可以去？）

那根据上述3种分类，分别调用不同的大模型block，使用不同的提示词和增强信息去回答，肯定比所有问题混在一起回答更准确。

优点：

(1).每个大模型调用，可以做更专门的事情，写好专门的提示词，调用专门的工具，可以更准确地回答问题

(2).每个分类下问题回答效果不好，可以专门优化这个这个分支上的大模型提示词等，不会影响其它分支的效果

缺点：

(1).分类也有可能出错，增加了一个可能出错的点，而且一旦分类错误，后面就可能答非所问，错得离谱。比如“上海周边2日游，有哪些地方可去”，万一分类错误，分成了景点信息查询，后面大模型可能就会推荐上海城市2日游的旅行社项目信息。之类的。（实际上一般没这么傻，只是举个例子）

适合场景：自然是能尽量避免缺点，又尽量能发挥优点的场景，即你的场景分类很清楚，不容易分类错误，而且每个分类的任务差别很大，合在一起效果很差，分开回答效果提升明显

4.workflow：并行调用

4.workflow：并行调用——示意图

之前的路由，是先用大模型分类，然后在不同的分支上走到最终回答

这个是不做分类，直接分别调用各个分支，产生中间结果，然后由一个大模型来总结各个分支的结果。

并行调用有两种情况：

(1).任务分解：

方法：即回答这个问题，本来就需要获得多个方面的信息，然后汇总在一起回答。

例子：餐厅评价问答系统的例子。分解成3个子任务，分别查询和回答： a.查询餐厅有哪些特色菜并回答； b.查询餐厅环境评价并回答； c.查询餐厅服务质量并回答。 最后从特色菜、环境、服务3个方面汇总成一个完整全面的回答。

文章中的例子1：问答系统：分成2个子任务： a.生成对用户问题的回答； b.问题审核，看有没有非法信息。 最后汇总处理。

(2).投票：

或者问题完全无法事先用路由分类，或者当路由不好设计，很容易分类错误。干脆把用户问题，按照每个分类都回答一遍，最后总结的大模型，再去汇总筛选，哪些是无用的错误分类的信息，哪些是有用的正确分类的信息。

例子1就是前面路由的例子，也可以按并行调用的方法做

文章中的例子：代码问题检查系统。从3个方面入手检查，无法事先确定哪个方面可能会有问题： a.代码安全性 b.代码可读性 c.代码性能 无论哪个方面检查出问题，都可以标记相关的代码块。

优缺点：

优点： a.避免了分类错误导致后面无法挽救，或者有些场景干脆无法事先分类，或者为了完整性，必须每个方面都给出一个回答。 b.如果本身串行的结构，改成并行，速度会加快。而本身分类N选1执行的结构，改成并行都调用，也不会增加时间，只是把最开头的分类过程，替换成结束时的汇总过程。

缺点：如果原来只需要选择一个子任务执行，现在都需要执行，花的成本更多了。

（未完待续）