5 高度自治智能体的模式
高度自治智能体的模式
1. 高度自治智能体的模式
1.1 工作流规划
就像复杂软件系统需要工厂模式、单例模式、依赖倒置等设计模式一样，Agent系统想要实现复杂度与效率并重，也需要设计模式。本节介绍规划（Planning）设计模式——Agent系统高度自主，能够自行决定执行复杂任务所需的工具调用序列，无需事先硬编码。
以一个客服助理Agent为例：目标是回答类似"你们有没有库存中售价低于100美元的圆形太阳眼镜？"这类复杂查询。
客服Agent工作流
系统给LLM提供一套功能工具：
| 工具名 | 功能说明 | 示例用途 |
|---|---|---|
| get_item_descriptions | 获取商品的文字描述或元数据 | 查出所有带"round"特征的太阳眼镜 |
| get_item_price | 查询指定商品的价格 | 判断哪些商品低于 $100 |
| check_inventory | 检查商品是否有库存 | 查询找到的圆形眼镜是否在库 |
| check_past_transactions | 查看用户历史交易记录 | 处理"我上周买的眼镜有问题"类查询 |
| process_item_sale | 处理购买行为 | 用户确认购买时执行交易 |
| process_item_return | 处理退货操作 | 发起退货请求 |
LLM根据用户请求生成逐步执行计划：先调用get_item_descriptions 找"round sunglasses"，再调check_inventory 查库存，然后调get_item_price筛选低于$100的商品，最后输出结果。系统按计划逐步执行，将每步输出作为下一步的上下文。
规划模式的优势很明显：Agent拥有丰富的工具能力，能执行的任务范围广泛；开发者无需事先编排工具调用的确切序列，灵活性和自主性高。
风险在于：运行时无法预知LLM会生成什么样的计划，带来结果不稳定、出错、越权的风险。目前规划模式在AI Coding领域非常成功，其他领域仍在尝试阶段。
经验丰富的开发者可能抽象出三个封装好复杂逻辑的核心工具就能解决问题，而经验不足的开发者容易过度抽象出十几种工具，或索性提供最基本的数据库session——这是极其不安全的。
1.2 创建与执行LLM计划
规划模式中，如何保证LLM生成的计划能被下游代码可靠执行？自然语言不够清晰明确，难以稳定解析。解决方案是要求LLM以结构化格式（JSON或XML）输出计划。
JSON计划示例
开发者在提示词中写明：“你可以访问以下工具，并需要以JSON格式创建一个分步计划”，同时详细描述所需的JSON结构。LLM返回一个JSON列表，每个对象代表一个步骤，包含：
-
description：步骤描述 -
tool：要调用的工具名称 -
arguments：传递给工具的参数
下游代码接收字符串输出，转为JSON格式，提取参数，执行对应函数。这种解析器编写起来非常方便，比解析自然语言可靠得多。
1.3 结合代码执行的规划
让LLM用JSON描述行动已经不错，但更进一步——直接让LLM编写代码来表达计划，效果往往更好。
许多论文表明，同样的工具与参数，让LLM直接编写代码的任务评估分数通常明显高于编写JSON。Huggingface的smolagents框架中的CodeAgent概念正是基于这种思想设计的。
代码执行流程
在处理复杂数据查询（如"哪个月份热巧克力销量最高？"）时，如果只提供少量基础工具（获取最大值、过滤行），Agent需要极其冗长的工具调用序列。对于新的复杂查询（“上周有多少风险交易？”），还需要不断创建新的定制工具，方法脆弱且低效。
允许LLM直接执行代码的优势：
- 利用大型库：LLM能利用Pandas等库中数百上千个内置函数
- 高表达能力：简洁代码即可表达多步骤、复杂逻辑（解析日期、排序、过滤、去重、计数）
- 性能更优：研究表明，LLM编写代码的性能通常优于编写JSON或纯文本计划
需要注意的风险：提示词要明确要求LLM以Python代码返回结果（用代码标签分隔）；直接运行LLM生成的代码存在安全风险，需要沙箱等安全执行环境。
规划模式的缺点是难以控制——开发者无法预先知道LLM会生成什么样的行动序列。但放弃一些控制权可以显著增加模型的能力范围，大多数时候这是值得的。
1.4 多智能体工作流
尽管所有Agent可能基于同一个底层LLM、运行在同一台电脑上，但将复杂任务分解成多个独立角色是一种更有效的开发方法，就像团队协作或多线程/多进程一样。
当一个AI业务系统需要调用十几种甚至几十种工具，在几千字提示词指导下运行，一个典型流程需要七八步才能完成时，把一个Agent拆成多个次级Agent构成MultiAgent系统就十分必要了。
市场Agent拆分
子Agent协作
MultiAgent系统的优势：
- 任务分解：像人类团队一样，将复杂任务分解为拥有不同角色和技能的子任务
- 专注性：开发者一次专注于构建一个特定角色，单个Agent任务越简单，完成效果越好
- 模块化与复用：通用Agent可复用于多种应用，比如"平面设计师Agent"既能做营销手册也能做社交媒体帖子
- 突破上下文限制：每个Agent只负责自己的部分，最终只返回结果；总结Agent不必存储其他Agent的调研过程，规避了128k上下文的限制
- 节约成本：每个Agent上下文更短，更省Tokens；上下文短则回复速度快、延迟低；多个Agent还能并行处理，大幅降低时间成本
通常通过提示词+工具的组合来创建不同Agent。比如市场分析Agent需要告诉LLM它具有市场分析技巧、给它配备网页浏览工具，以便自己做市场调研。
1.5 多智能体系统的通信模式
设计多智能体系统的通信模式同样复杂，组织结构的好坏会极大影响系统的效率与结果。本节介绍四种协作模式。
线性模式（Linear）
顺序执行任务，信息单向流动，像研究员→平面设计师→文案撰写者，每个人只和下一个环节沟通。结构简单易于理解，但不灵活，出错时难以反馈或修正。
双层模式（Hierarchical）
有一个"管理员Agent"负责协调所有下属Agent，像项目负责人依次给研究员、设计师、写手分配任务、收集结果、再整合。
双层模式
所有通信都经过经理，清晰易控制、任务协调性强，但经理可能成为瓶颈。
多层模式（Deep Hierarchy）
子Agent自己也拥有下属Agent。例如"研究员"下面有"网页研究员"和"事实核查员"，“作家"下面有"风格写手"和"引用校对员”。
多层模式
可扩展、模块化、可分层调度，但通信复杂、难以调试、出错难追踪。
去中心模式（All-to-all）
每个Agent都能随时与其他Agent交流，没有中心、没有固定顺序。大家互相发消息，直到都认为任务完成时产出最终结果。
去中心模式
高度去中心化、非常灵活、创意性强，但也难以预测结果，适用于容忍混乱、追求创造性结果的场景。
| 模式类型 | 结构特征 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 线性（Linear） | 顺序执行，单向通信 | 简单 | 不灵活 | 固定流程任务 |
| 双层（Hierarchical） | 中心协调 | 易控制 | 管理负担 | 多任务协调 |
| 多层（Deep Hierarchy） | 子Agent层次化 | 模块化 | 复杂 | 大型系统 |
| 去中心（All-to-all） | 自由对话 | 创造性强 | 不可预测 | 探索型、生成型任务 |
实际生产中，线性与双层模式更常用——对于当前LLM的能力而言，信息在层级间传递会丢失，层级越多信息越匮乏/失真。还有一种对话模式类似去中心的降级版：每次只有两个Agent互相对话，一方执行任务、一方审查，最终交出双方都满意的结果。
1.6 总结
吴恩达教授在本节中回顾了整套课程：Agentic AI能实现以往无法做到的应用场景，关键设计模式包括反思（Reflection）、工具调用（Tool Use）、评估与误差分析、规划（Planning）与多智能体系统（Multi-Agent Systems）。
掌握这些技能后，能在实践中构建创新的Agentic AI应用。同时要记住：如果某项技术能低成本而平滑地提高一个增长期行业的生产力，就一定能大行其道。大模型不会是常青树，但背后有迁移性的思想——复杂系统的编排拆分、工程与科研思维、用新技术特点重建新系统的经验——这些才是值得持续学习的。