Agentic AI 学习笔记
简介：
这份笔记记录了我学习吴恩达老师《Agentic AI》课程时的理解和思考。
我会从最基础的“AI Agent”和“Agentic AI”这两个概念讲起，然后围绕 Agentic AI 工作流的四个核心设计模式展开——反思（做完再改）、工具（动手干活）、规划（动脑再干）和多智能体协作（组队群殴） 。整篇笔记和吴恩达老师的讲课一样，没有太多晦涩的理论，而是用大量“人话”和生活里的例子，将这些抽象的能力讲得足够具体、足够接地气。
如果你看完课程后仍有一些疑惑，那希望我这篇笔记，正好能帮到你。如果有任何问题，欢迎来踢我的屁股向我反映问题所在，非常感谢 !O.o!
AI Agent 和 Agentic AI：
前者是一个实体，而后者是一个概念；怎么理解呢？前者相当于是单兵作战，一个能感知环境、进行自主决策并执行的单兵实体，通常只能专注于执行特定的单一的一件事（干好一件事情）；而后者是一种概念或者说架构体系，讲究的是能动性。他们之间的关系很简单，可以理解为多个不同职责的Agent相互协作编排，就组成了Agentic AI系统。当然Agentic AI并不一定是多个Agent，如果单个模型也具备了自主规划、自我反思、自我修正的能力，那也可以说它具备了Agentic能力
Agentic AI 工作流：
吴恩达老师提出的Agentic AI主要有四个关键设计模式：
反思：用agent得出的代码，喂给agent找错误，再将找出来的错误返还回去，继续更新。但如果你本身就可以看出代码的错误的话，那你直接将错误反馈，效果会更好。简单来说“反思”就是将LLM检查自己的输出或者引入外部信息，进行反馈迭代，生成更优输出版本；以上这种事单一Agent的反思，如果多Agent协作的话，可以让一个LLM作为批评Agent，专门进行批评操作
工具使用：Agent可以赋予工具，也就是他们可以调用函数来完成工作。比如查询天气，你给了agent一个查询当地天气的工具，那他就可以调用这个工具来回答你当地天气情况。LLM会根据你的问题来自主决定使用什么工具
规划：前面说到工具使用，而规划就是针对需要使用一系列工具的场景时，Agent会自己规划使用顺序：比如要识别图中人物形象，并生成类似形象的不同性别的图片，这时候Agent就会自己决定，先用图片识别工具，然后再将形象转移，再用图片生成工具生成类似图片；在这个例子中，规划就是一系列api的调用，开发者无需提前硬编码操作其工作流程。具备规划能力的Agent更难以被控制，但是也更加具有实验性
多智能体协作：就像公司招很多人来完成一件事情一样，你也可以用多个Agent来协作完成一个任务，每个Agent担任不同的角色，来完成一个复杂的业务场景：比如在开发中，可以用一个Agent作为策划师，一个Agent来负责执行，一个负责开发，一个负责测试，一个负责运维。
对设计模式的详细了解：
反思：
说白了，Agent 的反思就是模拟人类“复盘”的过程。就像我们写文稿，初稿完成后重读，往往会发现格式不整、用语歧义等问题，进而进行修正。Agent 亦是如此，它生成的第一个版本往往只是“初稿”，通过特定的提示词引导其重新审视，产出的“二稿”通常都会比初稿更优化。如此反复迭代，最终成品必然更贴合需求。
相比于自我查错，引入外部反馈的效果往往更好。正如人类在单一视角下站久了，难免会有盲区。因此，Agent 反思的进阶形态，不应局限于自我修正，更需要引入人类或其他 Agent 来提供多维度的反馈与评价。（就比如这一段内容就是下面内容的反思后的结果）
初稿 说白了，Agent反思就是模拟人类反思自己的输出并寻求改进，我们人类在做事情的时候，比如像我这样写笔记写文稿，总会有一个初稿，写完初稿之后再回过头来读一遍就会发现“哎呀这里格式不是很多”、“哎呀这里用语容易产生歧义”等等，对于Agent而言也是如此，你让他生成的文案或者代码，第一个也是初稿，而将初稿从新改进，用不同的提示词来修饰，它反射出的二稿无论如何多少都是对一搞的优化，如此反复那最终成品必然会更加贴合需求。对于Agent而言，相比于自我查错反思，从外部获得信息来源的效果要好得多，就像我们人类，在同一个角度站久了，难免会忽略其他一些角度的问题，所以Agent的反思更好的情况是需要人或者其他Agent来提供反馈
我们在问答中常常进行的是零样本提示（或单样本提示），与之对应的有双样本提示和多样本提示。什么意思呢？零/单样本提示就是一次问答中只有很少或者没有进行输入输出的示例，在处理复杂逻辑推理或特定领域任务时，零/单样本的表现往往并不稳定，且更容易出现幻觉或格式错误，而双/多样本提示顾名思义就是提供了多种示例，对比于少样本的提示，同一模型在多样本提示下，生成的效能往往比少样本提示高20%左右（当本身完整度高的时候，差距就越小越不明显）
通过修改提示词提升性能：可以通过对同一件事情的不同描述，以及多角度多模态的判定，形成一个判定体系，来测量某些提示词在使用前和使用后的性能变化，通过不断调整提示词来实现性能最大化
就现实情况而言，在零/少样本提示的情况下，不断修改提示词带来的性能收益是有限的的，由图可见，在没有进行反射的情况下，通过修改提示词，在前期的效益很高，但是越往后变化越来越不明显，直到趋近于一个值。而通过加入反思机制，性能相较于未加入是提升一大截，这时候再不断修改提示词，最终趋近值超过无反思机制的百分之三十左右。但效果最好的情况，就是加入反思机制后，采用的反馈来源不再是LLM自身，而是来自外界，这些新的外界资源可以是其他LLM，也可以是其他资料，更可以是人本身提出的反馈意见
工具：
我们人类借助工具能够完成远超徒手的任务，LLM同样能通过使用工具来实现更多的功能。我们使用的工具可能是扳手锤子等，而LLM使用的则是我们提供的工具——方法（有翻译也叫函数）。如果你向自己训练的LLM问现在是什么时候，它会回答你它无法回答，但是你编写了一个方法给到他并允许他使用的话，他就可以调用这个方法，来回答你今天是几月几号。
在这个图中，我们提问LLM前，会给予他这个方法，提问后，他会查看自己的工具集，发现有工具可用，就调用这个方法，得到返回值，再最后输出这个返回值。这里面的关键在于LLM可以自己选择自主决定使用什么工具，是否使用工具。 在以前（其实是不久之前)，LLM还未被训练直接调用工具，这个时候希望LLM通过工具回答的话，需要在提示词里面硬编写出方法名，LLM接收到这个提示词后，才知道自己需要调用这个方法。这种方法明显很笨拙，而现在采用的是现代语法（现代语法在业界通常被称为 Function Calling)
现代语法中，我们提供的工具（写的方法)，一般会自动以一种合适的方式对LLM进行描述，让LLM知道何时调用，比如将方法变成JSON格式的，里面包含方法的所有信息和参数等等，以便LLM理解
其实LLM本身并不会直接调用工具，LLM只会请求你去调用工具，有时候常说LLM调用了啥啥啥工具，这不是技术上的真实过程，只是这样简洁一些（上面说的LLM知道自己调用，其实是错的，真实情况是你通过硬编码进行的调用，他只负责返回结果）
在使用Agent的时候，算加减法我们就写了一个加减法工具，算乘除法我们就写一个乘除法工具，将这些工具交给LLM，但是如果需要开根号呢？还要再写一个工具嘛？那科学计算器上有那么多运算符号，需要每一个都写的话那未免有些麻烦，与其一个一个的实现方法，不如让LLM自己编写并执行代码
比如我们可以在提示词中，写入<execute_python>和</execute_python>，让LLM将答案以Python的方式，用这两个标签包裹，然后输出的结果就是编码并运行后的结果。没有这个标签，一般的LLM都只能生成只能看的代码，有这个标签，生成的代码就会在“沙盒”环境运行，然后将我们需要的运行结果返回给LLM，然后再给我们。这这标签的作用不是给LLM看的，这是给LLM后台看的
这种方法有一定的风险，高度自主的LLM可能会用这种方法产生一些无法挽回的错误，比如 rm * ，然后再和你说对不起，这是一个很愚蠢的错误（说对不起有啥用？！），所以这种形式运行起来的代码，最好在“沙盒”环境下，实际上单行的代码带来的错误并不会很严重，但我们用LLM的时候，大多都会忽略代码的审查这一块，所以最好还是在“沙盒”环境
沙盒环境其实就是一个“隔离的、安全的临时运行空间”。主流的就是Docker容器做沙盒，Python有个conda，Node.js的nvm，这些主要搭建轻量级沙盒环境，有了沙盒环境，即使LLM生成了有问题的代码你没注意，数据丢失和敏感信息泄露的风险也会低很多
MCP （模型上下文协议），最初由Anthropic提出标准，随后逐渐被认可，现在已被许多公司和开发者采用，MCP作为让LLM获得上下文和众多工具的方式，越来越多的开发者开始围绕MCP的生态进行开发维护 MCP试图解决什么问题呢？当你在开发应用中，需要集成第三方数据如GitHub、Google Drive这些的时候，你可能需要编写代码来封装相关API，为你的应用提供相关方法。但不同开发者的业务不同，可能需要访问同一第三方数据，却不能使用已有的API封装，需要自己进行集成，这样来看，每一个数据源都要构建自定义封装，每一个封装都不可复用，那社区就会存在对于统一API有m个（公司/开发者个数）不同封装。而MCP则提出一个标准，让应用来统一访问工具和数据源，这样会让社区工作量大幅度降低
MCP部分的详情可以回看关于具体的学习MCP的笔记
规划：
规划其实就是让Agent学会像人一样“谋定而后动”，做事之前先规划，在执行。如果说之前的反思是“做完再改”，工具是“动手干活”，那规划则就是“动手前先动脑”，当然这三者并不是相互独立的，而是相互叠加的，比如一个规划型 Agent 在每一步执行时都可以调用工具，执行完一步也可能触发反思并调整后续计划。
好回到规划这一块来讲，当LLM面对一个复杂的任务时，比如“帮我策划一次最近五天去长沙的五日游，要包含美食和景点，并生成预算表”，如果直接丢给LLM，它可能会一股脑输出一大段文字，甚至漏掉关键信息，他可能直接会回复你：
“长沙五日游攻略来啦！第一天去岳麓山和橘子洲，记得吃臭豆腐；第二天去省博物馆和太平街，尝尝糖油粑粑；第三天可以去梅溪湖，吃剁椒鱼头；第四天逛逛 IFS 和超级文和友；第五天去开福寺，然后买点酱板鸭返程。整体预算大概 2500 块，玩得开心！”
这不管怎么看都觉得不是很好，虽然这个回复看似完整，但是其中问题不少：它默认了这五天全是晴天，完全没考虑万一有雨怎么办；热门餐厅随便列了，既没确认当前是否在营业，也没提醒是否需要提前排号；最关键的“预算表”更是被一句模糊的总数搪塞过去，机票、酒店、每天吃饭交通分别花多少钱，一概不知。这就是典型的“一步到位”输出——信息没核实，细节大量缺失，看着热闹，实际很难直接照着执行。
当然可能有人要说“哎呀继续问一步步实现不就好了吗？”。这我怎么说呢，能一步到位且效果不错的话，何必多来几遍拉低效率呢？
而有了规划能力的Agent，会先把自己当成一个项目经理，把这个大目标拆解成一个个可执行的小步骤：
- 先调用搜索工具，查一下长沙最近五天的天气和热门景点。
- 根据查到的景点，规划每天的路线，并搜索附近的美食。
- 查询机票和酒店的大致价格。
- 最后把以上信息汇总，生成最终的攻略和预算表。
这就好比我们人类接到大任务，不会上来就埋头苦干，而是先列个大纲或思维导图。规划的核心价值，就是解决LLM在处理长链条任务时容易“顾头不顾尾”、逻辑混乱的问题。它把复杂的“黑盒”变成了一连串清晰的“白盒”步骤，即使中间某一步出错了，我们也知道具体是哪一步的问题，方便修正。
多智能体协作：
说完了反思、工具和规划，现在就来聊Agentic AI的最后一个部分：多智能体协作
如果说前面的反思、工具、规划都是在打造一个现代化超级单兵——让一个Agent变得更会思考、更会使用工具、更会做计划。那么多智能体协作，就是在此基础上再往前走一步：组建一个超级牛逼涵盖多方面的专业队伍。
我们人类在面对极其复杂的项目时，靠单打独斗肯定是不行的。就比如开发一款软件，只有一个人来负责，不是说不能实现，而是成本太高，一个技术人员要自己负责规划负责美术负责测试劈里啪啦的，总时长以及学习的试错成本很高的。而对于一个团队来说就不一样了，团队内部由产品经理来定需求、技术成员写代码、测试员找Bug、设计师画界面、运维负责上线。整体来看试错成本少，开发周期短，最后这个项目的上限也是极高，未来的生命线也是十分健壮。也就是说不管是人类社会还是agent，一个人或一个事物再全能，也很难同时把所有这些角色都做到极致。
而多智能体协作，模拟的就是这种人类社会最根本的智慧——分工与协作。
在多智能体协作这个系统里，不再是只有一个agent在忙活，而是有多个被赋予了不同“角色设定”的Agent在同时或轮流工作。每个Agent都有自己的“人设”、有自己的系统提示词、职责范围，甚至可以使用不同的工具来查询或执行不同范围内的事。
我们还是用软件开发来举例，一个典型的多智能体团队可能是这样运转的：
产品经理Agent：我们将模糊的想法丢给它，比如“我想做一个能记录每日心情的App”。它会把这句话变成一个结构化的需求文档，拆解出“登录注册”、“心情记录”、“数据统计”、“日记导出”等功能模块，然后交给项目经理去分配。
项目经理Agent：它不写代码，也不测Bug，但它是最忙的一个。它从产品经理哪里拿到需求文档，自己制作了一个任务进度表，手里攥着这一张任务进度表，盯着看谁在做什么、完成了多少、有没有卡住。如果工程师和测试员因为一个Bug扯皮了三个来回，它会站出来说：“这个问题先记下来，优先级降低，先做下一个功能，别卡在这儿。”
工程师Agent：从项目经理那里领到任务卡，比如“实现心情记录功能”，就开始调用写代码的工具（或者自己直接生成代码），把功能落地。写完以后，它会主动把代码提交给测试员。
测试员Agent：拿到代码后，它不是简单看一眼就通过，而是会主动设计测试用例——比如“用户连续点了三次心情会怎样？”、“网络断了再恢复，数据还在吗？”。一旦发现Bug，它会带着详细的错误信息把任务退回给工程师，甚至附上“我怀疑是第三行那个循环没写对”这样的建议。
............( 还有一堆就不写了，都差不多类似 )
在这个团队中，每个Agent都在做自己的事，做自己擅长的领域的事，他们合在一起就可以把这样一个软件开发的任务完成的明明白白。就算再差，又能差到那里去呢？这是所有Agent（人）一起看过一起做出来的，就算是猪一起做一件事也能做个七七八八吧
当然这里面的原理，不只是“人多力量大”这么简单。多智能体协作之所以有效，背后有几个关键原因：
- 并行与专精：不同的Agent可以同时开工，而且每个Agent只专注于自己的窄领域，提示词可以写得极其详细和针对，这比让一个Agent脑子里同时装着“搜资料、分析数据、写文章、查格式”要高效且精准得多。
- 减少幻觉：单个LLM容易一本正经地胡说八道，而且自己还意识不到。但在多智能体系统里，工程师的输出会被测试员质疑，测试员的观点会被项目经理否认，产品经理的需求文档还要被项目经理看过挑刺才能使用。这种交叉验证的机制，天然地让事实性错误更难“蒙混过关”。
- “思考”过程可见：就像规划中把agent思考计划的“黑盒”变成“白盒”一样，多智能体协作把“一个大脑的思考”变成了“一群人的公开对话”。我们可以看到产品经理提了什么需求、工程师为什么这样设计、测试员在哪一步发现了Bug。整个决策过程是可追溯、可调试的。
当然多智能体协作也并非全是优点，就像我们在最开始介绍的时候就说了，这里我们来详细讲一下”代价“是什么
首先就是成本：这么多的agent，后面调用的LLM成本得多高？每一次输出被打回就要重新调用，就算是四个agent，来回几轮调用，这样的成本就是指数增长的吗，每次调用都要花费token，真金白银啊token
其次就是耗时长：一个问题单个Agent可能只需要几秒就能回答或给出结果，但在多个Agent之间就不一样，这个结果输出后需要审核，需要给其他Agent看后发表意见，这样的话针对单个问题的时间就乘法增长，针对一个项目那就是指数增长
最后就是集体翻车：刚刚不是说“再差又能差到那里去”对吧，哈哈，方向对了的话确实是这样的，但如果方向错了，多个Agent之间可能会产生“误解”，那完蛋了，他们可能彼此之间陷入死循环，而且因为上下文窗口问题，逐步忘记原来的目标是什么，导致后面变成“闲聊”，那没招了，翻车吧。所以，如何设计一套稳健的协作协议、设置“仲裁者”或“超时机制”来避免这些问题，是多智能体系统设计中最有挑战性的部分
所以，回到一个务实的问题上：什么时候该用它？
在我看来并不是所有任务都值得动用“多智能体团队”，如果任务相对简单、步骤清晰，比如“总结这篇文章”、“写一封回复邮件”、“查一下明天长沙的天气”，那一个配备了工具和反思能力的单Agent就完全够用了。杀鸡不用牛刀。
真正适合多智能体的场景，是那些需要多视角审视、步骤之间有强依赖且容易出错、或者任务本身就需要不同专业能力组合的复杂项目。比如：开发一个软件、撰写一份深度研报、策划一场大型活动、做一套完整的企业战略方案。
总结：
说到底，Agentic AI 并不是什么玄学，它其实就是把我们人类解决问题的底层逻辑，完整地搬到了 AI 身上。 在吴恩达的agentic ai中：工具是 Agent 的“手和脚”，让它从只能陪聊的文科生，变成了能干活、能查数据的实干家；规划是它的“大脑”，让它学会了谋定而后动，把一团乱麻的大任务拆解成井井有条的步骤；反思是它的“自省能力”，让它懂得复盘和纠错，不再一条道走到黑；而多智能体协作则是把这种能力规模化，从打造“超级单兵”进化到了组建“专业特种部队”。
从最开始只会接话的 LLM，到现在的 Agentic AI，我们其实就在做一件事：让 AI 越来越像人一样去思考、去工作。当然，能力越大，责任（和成本）也越大。多 Agent 虽然强大，但烧钱又费时，所以我们在实际用的时候，还是得看菜吃饭——简单的活儿让单 Agent 加个反思就够了，真正难啃的硬骨头，再请出多智能体团队来群殴。
以上，就是我在学习吴恩达老师的Agentic ai的时候写下的学习笔记，愿这份笔记可以帮助你理解Agentic AI，也希望你能从中学习到如何把这些模式组合起来，去解决手头那些真正复杂的实际问题了。
