背景
自从大模型热度起来之后，大家都开始尝试使用大模型做很多事情，除了单纯的聊天，也用它来重构工作流，替代一些之前人工处理的事情，Agent的概念也就被重新提起，各种代码开发、原型设计、小说生成、AI短剧等各行各业的Agent横空出世，Agent的技术架构也在快速演进。从最初的单Agent的架构，到现在遍地的多Agent架构。在快速变化的过程中想写下自己的思考。
为什么会有Agent
技术原理上，由于大模型是根据公网海量数据预先训练的，没法感知实时/私有的信息，也没法操作我们的系统，而要做成一些事情，就要想办法补足这部分内容，于是就有了function call、RAG、MCP、Skills这些技术，让大模型可以获取实时/私有信息、操作我们的系统。又因为很多事情需要连贯性的上下文，而大模型的调用是无状态的且上下文窗口是有限的，于是又在记忆上做了很多管理：长期记忆、短期记忆、记忆归纳自我迭代等。整个包含了大模型、记忆、实时/私有知识、工具的系统我们就可以称为Agent，它可以帮我们完成一类事情。
单Agent和多Agent
前面解释了什么是Agent，那么多Agent其实也很好理解，如果把单个Agent看做是一个人，那么多Agent就是一个团队。多Agent之间其实和人一样，要么是上下级关系，某些Agent指挥其他Agent干活；要么是分工不同，某些Agent复杂读取数据，整理信息，某些Agent生成图片/视频，各自干不同的活；要么是一个Agent干活慢，多个Agent同时干，可以加速干完某些事。无论是哪种组织形式，都是多Agent系统。
为什么要这么做呢？我认为有几个原因：
单个Agent上下文是有限的（模型限制），进行职责拆分，那么就是变相提高这个上限，能做更多的事情。各个阶段模型需要感知的信息不同，也可以避免无效信息对模型行为的影响
参考传统软件的上拆分的优点，拆分后每个Agent可以单独优化/迭代，架构更清晰，每个Agent可以单独提供服务、复用，每个Agent更好维护
有优点也就有缺点，软件行业没有“银弹”，更多的是选择。
变成多Agent之后，消耗变得更大，因为和人一样，会有“沟通成本”。传话游戏里，每经过一次传话，信息只可能丢失，不可能增加。
结果可能变得更不可控，由于技术实现原因，大模型的输出结果是具有
随机性的，那么引入多Agent这种随机性大概率是会被放大的
结语
其实作为技术，单Agent和多Agent和当初的单体架构和 微服务架构 如出一辙，很多系统其实很简单，硬拆成微服务架构，只是徒增了系统的复杂度、提高了服务之间通信的成本和维护的成本。那么当前的多Agent架构我认为也是一样的，如果单个Agent能很好的解决，那么就不必要用多Agent架构来炫技，除非是单Agent没法解决的：
例如上下分太大需要拆分，否则模型无法运行；
不同阶段要做的事情差异很大，需要使用不同的模型、参数、上下文等。
总之，适合的才是最好的。
