> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/claude_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/claude_guide/di-er-bu-fen-gong-ju-pian/03_tools/3.4_orchestration.md).

# 3.4 Agent 编排模式与复杂流程

## 3.4.1 为什么需要编排？

单个工具调用只是原子操作。真实世界的业务场景往往是错综复杂的。 当用户说“帮我策划一次去日本的旅行，并预订性价比最高的酒店”时，这不仅是一个简单的查询，而是一个需要拆解、规划、执行和验证的 **工作流**。

**编排** 是指协调模型与多个工具之间交互的逻辑，确保任务能够按照正确的依赖关系和逻辑顺序高效完成。Claude 强大的推理能力使其天然适合作为这种编排的“大脑”。

## 3.4.2 核心编排模式

### 顺序链

这是最常见的模式，后续步骤依赖于前一步骤的输出。

* **场景**：用户想查询某位员工的最近订单。
* **逻辑**：
  1. `get_employee_id(name='Alice')` -> 返回 “ID\_999”
  2. `get_orders(employee_id='ID_999')` -> 返回订单列表
* **实现**：Claude 会自动识别这种依赖。它会先调用第一个工具，等待结果返回后，再利用结果中的 ID 发起第二次调用。无需硬编码这种顺序，只需提供这两个工具，Claude 的逻辑推理会自动完成“填空”。

### 并行执行：Parallel Execution / Fan-out

当多个子任务之间没有依赖关系时，并行执行可以极大降低延迟。

* **场景**：用户问“比较一下 iPhone 17 和 Pixel 10 的价格”。
* **逻辑**：Claude 会在一次响应中同时发出两个 `tool_use` 请求：
  1. `search_product("iPhone 17")`
  2. `search_product("Pixel 10")`
* **优势**：利用 `asyncio` 等异步机制，应用程序可以同时发起网络请求，总耗时取决于最慢的那个请求，而不是两者之和。

### 路由与分发

对于拥有成百上千个工具的巨型系统，直接把所有工具塞给模型是不现实的。

* **分类器模式**：
  1. **第一步**：使用一个轻量级 Prompt（或微调模型）判断用户意图类别（如“售后”、“销售”、“技术支持”）。
  2. **第二步**：根据类别加载对应的 10 个工具，而非全部 100 个。
  3. **第三步**：让主力模型（如 Claude Sonnet 4.6）进行具体的工具调用。

### 规划—执行

对于需要长视距推理的复杂任务，简单的 ReAct 循环可能会陷入局部最优或死循环。这种模式要求 Model 先生成完整的计划，再逐一执行。

* **场景**：写一个贪吃蛇游戏。
* **逻辑**：
  1. **Plan**: Claude 先列出步骤：1.设计游戏循环 2.处理用户输入 3.绘制图形 4.整合测试。
  2. **Execute**: 按照列表顺序，一次只专注执行一个子任务。
  3. **Replanning**: 如果执行中发现计划不可行（如库版本冲突），则更新剩余的计划。
* **优势**：通过“三思而后行”，减少了盲目试错的 Token 消耗，提高了复杂任务的成功率。

## 3.4.3 复杂工作流：深入 ReAct 循环

Claude 处理复杂任务的核心机制是 **ReAct (Reasoning + Acting)** 循环。

1. **Thought (思考)**：模型分析当前状态，制定下一步计划。
   * *Claude: “用户想订酒店，但我还不知道他的预算，我需要先问用户。或者如果用户已提供预算，我应该调用搜索工具。”*
2. **Action (行动)**：生成工具调用指令。
3. **Observation (观察)**：获取工具执行结果。
4. **Repeat (循环)**：基于新获得的信息（观察），重新思考，直到任务完成。

**自我修正**：如果工具报错（例如“无此相关记录”），Claude 会根据错误信息调整搜索关键词并重试。这种“韧性”是 Agent 区别于传统脚本的关键。

## 3.4.4 人机协作模式

在涉及资金、隐私或产生副作用的操作中，**完全自动化是危险的**。需要在编排中插入“人工确认”环节。

### 交互流程设计：

1. **User**: “给张总转账 1000 元。”
2. **Claude**: 调用 `propose_transfer(amount=1000, recipient="Zhang")`。
3. **App**: 拦截此工具调用。**不直接执行转账逻辑**。
4. **App**: 向用户展示 UI 弹窗：“Claude 想要发起一笔转账，是否批准？”
5. **User**: 点击“批准”。
6. **App**: 这里才真正执行转账 API，并将结果 `{"status": "success"}` 作为 `tool_result` 返回给 Claude。
7. **Claude**: “转账已成功。”

这种模式既利用了 AI 的意图理解，又保留了人类的最终决定权。

## 3.4.5 案例分析：全自动旅行策划师

以下通过一个 Mermaid 时序图，展示一个整合了顺序、并行和人机协作的完整案例。

任务：**“查一下东京明天的天气，如果没有雨，就帮我订一家靠近新宿站的酒店，预算200刀以内。”**

```mermaid
sequenceDiagram
    participant U as "用户"
    participant A as "客户端应用 (App)"
    participant C as "Claude"
    participant T as "工具服务 (Tools)"

    U->>A: 任务指令...
    A->>C: 转发用户消息 + 工具定义

    Note over C: 思考：先查天气。<br>这决定了后续是否订房。
    C->>A: tool_use: get_weather("Tokyo")

    A->>T: 执行查询
    T-->>A: tool_result: "Sunny"
    A->>C: 返回结果

    Note over C: 思考：天气不错。<br>接下来搜索酒店。
    C->>A: tool_use: search_hotels("Shinjuku", max_price=200)

    A->>T: 执行搜索
    T-->>A: tool_result: [Hotel A, Hotel B]
    A->>C: 返回结果

    Note over C: 思考：找到了，但需要用户确认订哪家。<br>或者直接预订最优的（假设策略如此）。
    C->>A: tool_use: book_hotel("Hotel A")

    Note over A: 触发 Human-in-the-loop：<br>检测到敏感操作（预订），拦截执行
    A->>U: 弹出确认框
    U-->>A: 点击"确认"

    A->>T: 执行预订 API
    T-->>A: tool_result: "Success, Order #123"
    A->>C: 返回结果

    C->>A: "已为您预订 Hotel A，订单号 123，祝您旅途愉快！"
    A->>U: 显示最终回复
```

## 3.4.6 状态管理与上下文清洗

在多轮编排中，Context Window (上下文窗口) 很容易被填满。

* **滑动窗口**：仅保留最近的 N 轮对话。但要注意不要切断正在进行的 `tool_use` -> `tool_result` 配对。
* **状态外置**：不要让 Claude 记所有东西。
  * *Bad*: 让 Claude 记住用户的购物车清单。
  * *Good*: 购物车数据存数据库，Claude 只通过 `get_cart()` 查看，通过 `add_to_cart()` 修改。

***

对于更复杂的自动化需求，甚至可以让 Claude 自己写代码来解决问题。

➡️ [程序化执行与代码解释器](/claude_guide/di-er-bu-fen-gong-ju-pian/03_tools/3.5_programmatic.md)