Agentic AI学习笔记（5）

高自主智能体设计模式

一、规划工作流

高度自主的智能体，无需提前进行硬编码，执行指定步骤的顺序，而是让它更加灵活，自主决定要采取哪些步骤以完成任务。也就是说能够自行决定执行复杂任务所需的工具调用序列。

示例一 客服助理Agent

在本例中，如下工具：

工具名	功能说明	示例用途
get_item_descriptions	获取商品的文字描述或元数据（如名称、款式、材质、颜色、形状等）	当用户说"round sunglasses"时，用它来查出所有带"round"特征的太阳眼镜
get_item_price	查询指定商品的价格	在找到商品后，用它来判断哪些低于 $100
check_inventory	检查商品是否有库存（以及库存数量）	找到圆形眼镜后，查询这些商品是否在库
check_past_transactions	查看用户的历史交易记录（如购买过哪些商品、是否退换货过）	用于客户支持场景，如"我上周买的眼镜有问题"
process_item_sale	处理购买行为，即创建销售订单或执行购买交易	当用户确认要买时，调用这个工具执行交易
process_item_return	处理退货操作	当用户想退货时，用它发起退货请求

• LLM 编写计划 ： 要求LLM根据用户请求返回一个逐步的执行计划，说明应按什么顺序调用哪些工具。

  在本示例一中，流程如下：

  1. LLM 计划调用 get_item_descriptions 来找"round sunglasses"

  2. 根据 Step 1 的输出（找到的产品）

  3. 再调用 check_inventory 查看库存

  4. 对库存中有货的结果

  5. 调用 get_item_price 检查哪些低于 $100

  6. 输出最终结果

• 逐步执行： 按照计划，将每一步的指令和上一步的输出/上下文依次喂给 LLM，让它调用相应的工具并执行。

• 最终输出： 将所有步骤的结果反馈给 LLM，生成最终的用户答案。

规划模式的Agent有许多好处，比如Agent拥有非常丰富的能力，进而扩展了能执行的任务范围。开发者也无需事先编排工具调用的确切序列，提高了系统的灵活性和自主性。

规划模式的Agent系统在流程控制与实际场景上也有些风险点。在运行时，开发者无法预知 LLM 会生成什么样的计划，带来了结果不稳定/出错/越权的风险。目前，规划模式在AI Coding应用中非常成功，但在其他领域仍然处在尝试阶段。

【看到别人推荐的一种Agent框架】Agent框架：来自Huggingface社区的[smolagents](https://huggingface.co/docs/smolagents/index)框架。它代码简洁，抽象程度少，工具开发难度低（只需要一个@tool装饰器），自由程度高，也具有流程跟踪功能，开发者很容易入门，也很方便理解重写其中的一些逻辑，来实现自己定制化的系统。

二、创建并执行LLM规划

让LLM直接讲出自己的任务规划，但自然语言不够清晰和明确，难以被下游代码稳定地解析和执行。所以在本节中，我们要求 LLM比这些简单的高层描述更详细的文字说明，许多开发者会要求LLM以特定格式输入，如结构化格式（如 JSON 或 XML）输出计划。

结构化格式能够清楚地界定计划的步骤、所需工具及其参数，从而允许下游代码更可靠地解析 (parse) 解析计划的具体步骤，以相对清晰且无歧义的方式系统性地、一步一步地执行。

主流的LLM已经非常擅长生成JSON

LLM 会返回一个 JSON 列表，列表中的每个对象代表一个步骤，包含清晰的键值：

* `description` (步骤描述)

* `tool` (要调用的工具名称)

* `arguments` (传递给工具的参数)

这样一来，我们只要接收LLM的字符串输出，转化为JSON格式，并提取参数，执行对应函数即可。这样的解析器编写起来非常方便。

三、结合代码执行

让 LLM 直接编写代码来的效果更好，LLM可以直接用代码来表达计划的多个步骤和工具调用。

在处理复杂的数据查询（如"哪个月份热巧克力销量最高？"）时，如果只提供少量基础工具（如 `获取最大值`、`过滤行`），代理需要极其复杂且冗长的工具调用序列来解决问题。

提出5步计划，每一步都用代码表达出来。

提出4步计划，每一步都用代码表达出来。

若是允许LLM直接执行代码，就能获得下列优势：

• 利用大型库： LLM 得以利用像 Pandas 这样的数据处理库中数百甚至数千个内置函数。

• 高表达能力： LLM 能够编写简洁的代码来表达一个涉及多步骤、复杂逻辑的计划，例如解析日期、按日期排序、过滤、去重、计数。

• 性能更优： 研究表明，在许多任务中，让 LLM 编写代码来采取行动的性能优于让它编写 JSON 或纯文本计划。

这种CodeAgent的形式也有些需要注意的风险点：

• 提示词要求： 明确要求LLM编写代码来解决用户的查询，并以 Python 代码返回结果，通常使用 `````````或`````<code>` 等标签进行分隔。

• 安全问题： 直接运行 LLM 生成的代码存在安全风险，需要考虑使用沙箱 (Sandbox) 等安全执行环境。

利用代码的执行效果更好。"代码即行动"------也就是让语言模型编写代码，并通过代码采取行动的方式，由于让LLM写JSON,再翻译成行动。

先构建一个复杂系统，先会提出一个详细的计划：逐一构建这个软件组件，规划在进行过程中对各组件进行测试，然后形成一张清单，逐条执行，一步一步完成。

规划模式的缺点是难以控制，因为开发者无法预先知道 LLM 会生成什么样的行动序列。尽管如此，放弃一些控制权可以显著增加模型的能力范围，大多数时候这是值得的。

四、多智能体工作流

如果你要执行一个复杂的任务，将复杂任务分解成多个独立子任务，把一个Agent拆成很多次级Agent，并构成一个多Agent系统，即MultiAgent系统。

示例：市场团队

分别构建三个智能体，然后再一起执行

线性计划：依次执行行动，直到结束

背景：你想为夏季做一场营销活动，来推广太阳镜

首先，把这个计划给researcher智能体，它会写出一份报告。

接着，这份报告会发给graphic designer智能体，审查研究者找到的数据，并制作若干可视化图表和视觉方案。

然后，把这些素材交给writer智能体，会把研究结果和视觉方案整合起来，撰写最终的营销报告。

考虑智能体是否能复用，完成更多的营销任务？

交互规划：一个智能体协调其余智能体提供交互

与工具复用是类似的，这里提供了智能体复用。于是，增加了一个智能体"市场经理"，负责协调研究员，平面设计师，以及撰稿人。

提示词设计示例：

在明确了模式后，你将构建一个提示 ，使模型通过编写代码来规划，并随后执行该代码。正如 Andrew 强调的：代码即计划。模型在注释中解释每一步，然后执行它。下面的提示还让模型自行判断请求是只读还是状态变更，并强制安全执行（无 I/O、无网络、仅 TinyDB 查询、变更一致）。

PROMPT = """你是一名高级数据助手。通过编写 TINDYDB PYTHON 代码来制定计划。

数据库模式和示例 (只读):
{schema_block}

执行环境 (已导入/已提供):
- 变量: db, inventory_tbl, transactions_tbl  # TinyDB 表对象
- 助手函数: get_current_balance(tbl) -> float, next_transaction_id(tbl, prefix="TXN") -> str
- 自然语言: user_request: str  # 原始用户消息

规划规则 (关键):
- 从 user_request 派生所有过滤器/参数 (形状/关键词, 价格范围 "低于/高于/之间", 库存提及, 数量, 购买/退货意图)。不要硬编码值。
- 使用 Query() 动态构建 TinyDB 查询。如果 user_request 中没有某个约束，则不要应用它。
- 保持保守：如果意图不明确，请执行只读操作 (演习 - DRY RUN)。

交易政策 (硬性规定):
- 不要创建聚合的多项目交易。
- 如果请求包含多个项目，则为每个项目创建单独的交易行。
- 对于每个项目：
  - 计算其自己的单行总计 (unit_price * qty),
  - 插入一笔该金额的交易,
  - 按顺序更新余额 (balance += line_total),
  - 更新该项目的库存。
- 如果任何请求的项目库存不足，不要更改任何数据；回复 STATUS="insufficient_stock"。

人类可读响应要求 (硬性规定):
- 你必须设置一个名为 `answer_text` (str 类型) 的变量，内容为简短、客户友好的句子 (1-2 行)。
- 这个句子是唯一面向用户的消息。没有数据帧/JSON，没有样板式的免责声明。
- 如果没有匹配项，礼貌地说明情况，并提供一个相近的替代方案 (最接近的款式/价格) 或下一步建议。

行动政策:
- 如果请求明确要求改变状态 (购买/采购/退货/补货/调整):
    ACTION="mutate"; SHOULD_MUTATE=True; 执行更改并写入匹配的交易行。
  否则:
    ACTION="read"; SHOULD_MUTATE=False; 模拟并作为演习 (dry run) 简要说明 (仅在日志中)。

失败与边缘情况处理 (必须实现):
- 不要在 Query.test 中捕获外部变量。将它们作为显式参数传递。
- 始终设置一个简短的 `answer_text`。同时设置一个字符串 `STATUS`，其值为以下之一:
  "success", "no_match", "insufficient_stock", "invalid_request", "unsupported_intent"。
- no_match: 没有项目满足过滤器 → 建议风格/价格最接近的，或邀请客户提供不同范围。
- insufficient_stock: 找到项目但库存 < 请求数量 → 说明可用数量，并提供你能满足的最大数量。
- invalid_request: 无法解析基本信息 (例如 购买/退货 的数量) → 简洁地询问缺失的部分。
- unsupported_intent: 该行动超出了商店的能力范围 → 提供最接近的支持替代方案。
- 在所有情况下，保持乐于助人且简洁的语气 (1-2 句话)。仅在 stdout 日志中放入技术细节 (例如 ACTION/DRY RUN)。

输出契约:
- 仅在这些标签之间返回可执行的 Python (没有额外文本):
  <execute_python>
  # 你的 python
  </execute_python>

代码核对清单 (在代码中遵循):
1) 从 user_request 解析意图和约束 (可用正则表达式)。
2) 渐进式构建 TinyDB 条件；查询 inventory_tbl。
3) 如果是变更(mutate)操作: 验证库存, 更新库存, 插入一笔交易 (新 id, 金额, 余额, 时间戳)。
4) 始终设置:
   - `answer_text` (人类可读的句子, 必需),
   - `STATUS` (参见上面的列表)。
   同时向 stdout 打印一个简短的日志, 例如 "LOG: ACTION=read DRY_RUN=True STATUS=no_match"。
5) 可选: 如果有用的话设置 `answer_rows` 或 `answer_json`，但 `answer_text` 是强制性的。

语气示例 (用于 `answer_text`):
- 成功: "是的，我们有经典款太阳镜，这是一款圆形镜框，售价60美元。"
- 无匹配: "我们目前没有100美元以下的圆形镜框库存，但我们的 Moon圆形镜框有货，售价120美元。"
- 库存不足: "Classic款我们只剩下1副了；我可以为您预留。"
- 无效请求: "我可以处理这个------请问您想购买多少副？"
- 不支持的意图: "我们不能翻新镜框，但我可以推荐类似的新款式。"

约束条件:
- 使用 TinyDB Query 进行过滤。仅在需要时使用标准库导入。
- 保持代码清晰，并使用编号步骤进行注释。

用户请求:
{question}
"""

要点总结

• 让代码成为计划。 遵循 Andrew 的"以代码为行动"理念，让模型编写串联步骤的 Python（过滤 → 计算 → 更新），然后直接运行。

• 避免脆弱的工具拼凑。 不再堆砌小工具或 JSON 计划，而是使用 Python/TinyDB------为模型提供一个熟悉且强大的工具箱，用同一个提示处理多种查询形态。

• 保持执行安全且可见。 在受控命名空间中运行、捕获日志/错误，并查看前/后表------因此你始终清楚变化是什么以及原因。

MultiAgent系统具有以下优势：

任务分解： 像人类团队一样，将复杂任务自然地分解为拥有不同角色和技能的子任务。
专注性： 允许开发者一次专注于构建一个特定角色，就像只需专注于构建最好的"平面设计师智能体"。通常，单个Agent的任务越简单，任务完成的效果就越好。
模块化与复用： 有机会创建可复用于其他应用的通用智能体，就像一个通用的"平面设计师智能体"可以用于营销手册和社交媒体帖子。

五、多智能体系统通信模式

【提示】需要设计不同智能体之间如何通信？

1. 线性通信模式

就像一个市场团队的工作流：研究员 → 平面设计师 → 文案撰写者。每个人只和下一个环节沟通。

线性模式按顺序执行任务，信息单向流动；

• 优点：结构简单、易于理解；

• 缺点：不灵活，出错时难以反馈或修正。

2. 层级式通信模式

有一个"管理员（Manager Agent）"负责协调所有下属Agent。

就像项目负责人依次给研究员、设计师、写手分配任务，收集结果，再整合。

双层模式下，所有通信都经过经理；

• 优点 ：清晰、易于控制、任务协调性强；

• 缺点 ：可能成为瓶颈（manager负担重）。

3. 深度层级式通信模式

一些高级系统会让子Agent自己也拥有下属Agent。

例如"研究员"下面有"网页研究员"和"事实核查员"，"作家"下面有"风格写手"和"引用校对员"。

• 优点：可扩展、模块化、可分层调度；

• 缺点：通信复杂、难以调试、出错难追踪。

4. 全连接（all-to-all）通讯模式

在这种模式下，每个Agent都能随时与其他Agent交流，没有中心，也没有固定顺序。

每个Agent都知道其他Agent是谁，他们可以互相发消息，谁都可以决定何时回复。直到最后大家都"认为任务完成"时，产出最终结果。

特点：高度去中心化、非常灵活、创意性强，但也 难以预测结果。

这种模式适用于容忍一定混乱、追求创造性结果的场景。

四种通信模式总结为下表：

模式类型	结构特征	优点	缺点	适用场景
线性（Linear）	顺序执行，单向通信	简单	不灵活	固定流程任务
双层（Hierarchical）	中心协调	易控制	管理负担	多任务协调
多层（Deep Hierarchy）	子Agent层次化	模块化	复杂	大型系统
去中心（All-to-all）	自由对话	创造性强	不可预测	探索型、生成型任务