一、介绍
Agent非常火，一塌糊涂的火。很多同学都想进来学习，但又不知道如何下手。其实，很多学习的经验都是可以平移过来的。Agent开发除了自身的特点，其本身仍然是一种软件的开发。
要想学好Agent开发，最重要是先要学会看别人优秀的项目及其相关的开发经验，站在别人的肩膀上，看得更高，才可能走得更远。
想到学习Agent，基础是要明白Agent是如何运行的，它的主流的架构是什么？在理解并深入掌握这些架构后，才能够根据实际的应用和自身的技术知识体系来研究是否可以有更好的机制来实现。
二、Agent的架构说明
Agent的火意味着技术的更新变化很快，所以它不会像软件工程那样有着不少标准的东西。很多技术架构可能只是一种事实上的应用主流情况。
对于架构，有过软件架构知识的开发人员很容易明白，不同的思想和角度来看待架构，它们的分类划分是不同的。Agent也是如此。一般来说，Agent可以从三个层面来看待其主流的架构：
- 早期架构
最早期的Agent没有架构可言，就是一堆，有什么需求直接上就可以了。这可以认为是Agent早期的萌芽发展阶段 - 决策控制架构
这种架构其实就是在单Agent体系范畴内的自我发展。它主要包括：ReAct、Plan-and-Execute、Reflexion/ Self-Refine、Tree of Thoughts/LATS、MRKL/Router、Function Calling/Toolformer、RAG Agent/MemGPT几类 - 工作流体系
工作流体系可以认为是在决策控制上进一步发展的结果。它从整体的流程上对Agent的任务处理进行了编排。主要包括：Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer - 多Agent架构
随着面对的需求和应用越来越复杂，单体Agent往往显得有些力不从心。俗话说的好，多生儿子好打架。一个Agent不行自然就会出现多Agent架构。它一般包括：分层多Agnet、协作分工式多Agent、流水式多Agent、辩论式多Agent、blackboard/市场多Agent以及社会模拟多Agent
在实际的生产中，往往和软件开发一样，面对的需求和应用场景复杂多变。不能简单的说哪种架构好与不好。架构的选项与具体的应用场景是密不可分的，同样也和设计者想达到的控制力度息息相关。
特别是面对复杂的应用场景，不是简单的一两层即可解决问题。Agent也会划分多个层次，通过不同层间的事件驱动和并行执行来进行架构间的跳转和执行。至于层内和层间使用哪种Agent架构，就看实际需求和设计者的具体考量了。
三、主流架构分析
上面按不同角度层次给出了主流架构的种类。但在实际应用中，常见和应用较多的一般有以下几种。下面将对其进行分析和说明：
- 早期单体架构
这种架构其实就是Singel Agent的早期阶段。用户通过一个对话框或终端与大模型进行交互，大模型干了所有的活，从对话的接收、思考以及工具调用等再到最后输出。
这种架构的优点就是简单、方便没有太多的中间层和控制层。所以成本低，交互的延迟也比较低。但简单就意味着它面对复杂需求时，就力有所不逮了。上下文的限制、并发等都成为了让人头疼的问题。它只适合早期Agent的开发和Demo的开发 - ReAct
在前面分析过，即Reasoning+Acting。它算是一种内部的自我小循环。其主要的工作方式是循环进行思考-行动-观察反馈结果处理这些步骤，并最终获取最终的输出。
其优势在于其具有一条链式的推理过程，全链路透明可解释；不足之处就是循环消耗了太多的Token、速度慢而且稳定性较差，这就有可能在长流程的任务中积累偏差，导致误差过大。也就是说它不太适合大规模的工程系统 - Plan-and-Execute
这也是目前很多Agent应用者应用的层次。它体现了一种典型的工程化的流程即先计划（拆解任务并编排步骤）再执行（按步骤执行验证结果）。在计划和执行间还可以插入交互机制让其更完善和更准确并最终形成用户认可的可执行的计划步骤。然后执行阶段按照计划阶段的步骤细节一步步的执行。如果出现问题还可以按计划回滚并再次执行。
它的优势在于确定的计划会使执行变得更稳定可控、由于有了计划多长的流程都可以提前规划并自动执行（如遇错回滚）。特别适合于一些流程长的工作，典型的代码生成。但计划性是优点就是缺点，如果面对的需求是动态变化的或者用户的认知有偏差导致计划有问题，那么结果就会出错。计划就意味着灵活性的不足，毕竟现实世界中很多事物是无法提前计划的，而且一些小的任务使用它有些浪费 - Reflexion
反思型Agent架构，它的特点是自己对自己的执行结果进行反思，失败后则进行重试。就和人类一样，想好去执行发现问题考虑为什么出现，然后再按思考去解决。如此循环反复，达到最终的目标。
它的优点在于能自我改进，反思迭代；不足在于需要增加额外的评估思考模块，成本较高。它比较适合于代码开发、写作推理、文案优化等需要反复思考完善的场景 - Multi-Agent
一个Agent不够就多个么，多Agent的特点是需要有一个协调器（orchestrator）用于分配任务到各个Agent，如搜索、代码生成、Review等等。这些Agent共享知识库并在最后进行汇总。
它的优势在于任务拆解浅析各Agent分工合作、降低了上下文污染、效率高及可扩展性好；不足之处在于Agent多了协调的成本过高，而且有可能产生互相冲突，这就需要增加相关的处理机制，加大了成本并且执行时间变长。它适合于对流程要求一致性强及较为复杂的场景 - Router+Skills
这种架构其实是一种很常见的架构，它其实更类似一种决策的处理（有JEV的感觉）。用户输入后，转到Router进行意图识别和判断，并根据判断结果路由到指定的Skill进行执行。所谓的专业事情交给专业的人来干。就是这个意思。
它的优势非常明显，稳定性极强，很难产生幻觉，性能非常高，高可控以及易于对其进行效果评估；缺点就是Skill设计成本过高，需要专业的人员来进行，而且还有可能出现路由冲突。最关键一点，其应用的场景并不是普遍的 - blackboard
这种架构类似于MQ中的发布、订阅机制。它允许多个Agent共享状态空间同时进行读写操作，利用状态的变化进行任务的驱动执行（有点状态机的感觉）。
它的优点在于更好的任务解耦，适合于动态变化的场景；不足在于协调调度复杂。状态控制是一个难点，一但出现问题很难进行追踪。它比较适合于复杂的任务协作场景，如分布式系统 - graph workflow
这个架构在前面也提到过，它可以认为是企业应用的专用架构。普通的应用一般不建议使用。它基于DAG的工作流编排，支持分支选择、并行处理以及回溯、重试等行为。
它的优势在于生产级别的稳定性、支持中断和超长流程；缺点就是太重了。所以它适合于工业级的流程自动化和生产环境，如LangGraph等
在架构说明中提到但没有详细分析的，有兴趣的可以查看相关的资料，此处不再展开。
四、总结
新技术的特点就是新。新意味着发展变化快、更新迭代快。所以不要拘泥当前的分析，这些技术很可能明天天一亮就出现了变化甚至是否定。重点是掌握Agnet自身的特点和其出现的原因、目的。从根源理解Agent技术，再结合软件开发的历史经验以及AI大模型的发展，就可以做到见变不怪了。
最后再提醒一下：正如反复所提到的，没有最好，只有最合适！架构亦是如此！