> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/agentic_ai_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/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/01_paradigm/1.5_agentic_workflow.md).

# 1.5 智能体工作流

智能体工作流（Agentic Workflow）是一类重要的 AI 应用范式。与传统的单次推理不同，它强调将 AI 能力组织成可控、可观测、可迭代的工作流程。

## 1.5.1 什么是智能体工作流

智能体工作流是一种让 AI 系统以 **迭代、自主、目标导向** 的方式完成复杂任务的工作模式。**核心特征**：

* **迭代式执行**：不是一次生成最终答案，而是多步骤逐渐逼近目标
* **自主决策**：AI 自主决定下一步行动，而非完全由用户控制
* **工具集成**：无缝调用外部工具和服务
* **状态管理**：维护执行过程中的中间状态

## 1.5.2 与传统提示词模式的区别

| 维度   | **传统提示词**     | **智能体工作流** |
| ---- | ------------- | ---------- |
| 交互模式 | 单次请求-响应       | 多轮迭代执行     |
| 控制权  | 用户完全控制        | AI 自主决策    |
| 执行时间 | 毫秒～秒级         | 秒级～分钟级     |
| 能力边界 | 模型内在知识        | 工具扩展后的能力   |
| 结果质量 | 依赖 **提示词** 质量 | 可通过迭代改进    |

## 1.5.3 典型的智能体工作流模式

根据所处理任务的特点，典型的智能体工作流模式包括：`规划-执行模式`、`ReAct 模式`、`反思-改进模式`、`层级协作模式` 等。

先看一个总览图，可以把这四类模式放在同一坐标系里理解：它们的差异不在“会不会调用模型”，而在“如何组织决策、反馈与角色分工”。

![工作流模式总览图](https://3128901766-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1MfY54KEA2QaKRoz2bLp%2Fuploads%2Fgit-blob-0a4129ff5b90f2a57d0d702f6e60bffcbe9ea38a%2Fagentic-workflow-patterns-overview.svg?alt=media)

图 1-4：典型智能体工作流模式总览

### 规划-执行模式

智能体会先制定完整计划，然后逐步执行，直到达到目标。这个模式通常用于结构化任务、可预测的工作流程。

```
用户目标
    ↓
[规划阶段] 生成任务步骤列表
    ↓
[执行阶段] 逐步执行每个步骤
    ↓
最终结果
```

**适用场景**：结构化任务、可预测的工作流程

### ReAct 模式

ReAct（Reasoning + Acting）是推理和行动交替进行的模式。智能体在“思考”和“行动”之间交替，根据观察结果动态调整策略，直到达到目标。这种循环使智能体能够在不确定的环境中逐步逼近解决方案。

ReAct 模式的完整理论、代码示例与提示词模板详见[第 2.3 节：ReAct：推理与行动的统一](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/02_reasoning/2.3_react.md)。

**适用场景**：探索性任务、需要动态调整的场景

### 反思-改进模式

智能体会在执行后进行自我评估和改进，这个模式通常用于需要质量把控的任务。

```
初始方案 → 执行 → 评估结果 → 反思问题 → 改进方案 → 重新执行
```

**适用场景**：代码编写、内容创作等需要质量把控的任务

### 多智能体协作模式

多个专业化智能体分别担任不同角色，协同完成任务。这个模式通常用于复杂项目、需要多种专业技能的任务。

```
用户需求
    ↓
[协调者智能体] 分配任务
    ↓
[研究智能体] ←→ [写作智能体] ←→ [审核智能体]
    ↓
整合输出
```

**适用场景**：复杂项目、需要多种专业技能的任务

## 1.5.4 实践案例

以下是几个典型的智能体工作流应用案例，展示了上述模式在实际产品中的落地。前 3 个案例用于说明“产品形态如何对应工作流模式”，后 2 个案例则用于说明企业实践中常见的治理与落地权衡。除非特别注明来源，下面的企业案例都只作为示意性场景，不应理解为可审计的行业统计。

### 案例一：交互式产物视图

一些交互式界面会将“产物”与“对话”并列呈现，常见地采用 **反思-改进模式**：先生成一个可见的中间结果，再围绕这个结果反复修订。

* **即时预览**：生成代码后立即渲染展示
* **迭代改进**：用户可以要求修改，智能体理解上下文逐步完善
* **工具集成**：支持 HTML/CSS/JS、React、Mermaid 图表等

### 案例二：AI 原生 IDE

现代 AI IDE 的代码编辑工作流常结合 **规划-执行模式** 与 **反思-改进模式**：先理解代码库和修改范围，再逐步编辑并在验证失败时回退或修正。

```
1. 用户描述需求
2. 智能体分析代码库
3. 生成修改计划
4. 逐文件编辑
5. 自动验证（运行测试、检查类型）
6. 必要时自动修复问题
```

### 案例三：自主软件开发智能体

自主软件开发智能体常综合运用 **ReAct** 模式和 **多智能体协作** 模式：既要在不确定环境中动态决策，也要把计划、实现、测试拆给不同角色。

* 完整的开发环境访问
* 自主执行 git 操作
* 运行测试并修复问题
* 与用户进行异步协作

### 案例四：企业级智能体生产流程

一个更可信的企业级示意场景是：金融科技团队采用 **层级协作模式** 自动化研报生成与审查。规划智能体拆解结构，多个撰写智能体并行编写，审查智能体基于 RAG 验证合规性。其核心经验通常不是“速度提升了多少”这类脱离上下文的统一数字，而是两点：第一，防止模型幻觉需要强制工具验证；第二，通过分层智能体可以更清楚地切换成本、质量与审核强度的权衡。

### 案例五：跨国软件团队的协作案例

另一个常见示意场景是：SaaS 团队用多智能体工作流（计划→执行→测试）加速跨时区的需求→代码→测试流程。通过 RAG 检索内部知识库确保方案合规，并在关键节点保留人工审批。它真正改善的往往是“等待成本”和“交接摩擦”，而不是某个可以脱离组织背景单独比较的统一 ROI 数字。

## 1.5.5 实现智能体工作流的关键要素

无论采用哪一种工作流模式，真正决定系统是否能稳定落地的，通常不是“提示词是否聪明”，而是状态、控制流与人机交互点有没有被显式设计出来。下面按这三个要素展开。

从工程视角看，这些要素通常会收敛到一个标准的 agent loop：推理器根据目标与状态选择动作，工具执行器与观察处理器持续更新记忆，策略护栏和人工反馈则在关键节点把循环拉回可控边界。

{% @mermaid/diagram content="flowchart LR
classDef core fill:#e6f7ff,stroke:#1890ff,stroke-width:2px,color:#0f172a;
classDef runtime fill:#f6ffed,stroke:#52c41a,stroke-width:2px,color:#0f172a;
classDef guard fill:#fff7e6,stroke:#fa8c16,stroke-width:2px,color:#0f172a;
classDef state fill:#fff1f0,stroke:#ff4d4f,stroke-width:2px,color:#0f172a;

```
Goal["目标与约束<br/>User Goal"] --> Reason["推理器<br/>Reasoner"]
State["状态与记忆<br/>State / Memory"] --> Reason
Reason --> Decide["动作选择<br/>Action Selector"]
Decide --> Tool["工具执行器<br/>Tool Runtime"]
Tool --> Observe["观察处理<br/>Observation Parser"]
Observe --> Check{"继续 / 完成 / 求助"}
Check -- "继续" --> State
Check -- "完成" --> Output["最终输出"]
Check -- "求助" --> Human["人工反馈<br/>Human-in-the-Loop"]
Human --> State
Guard["策略与权限护栏<br/>Policy Guard"] -.-> Decide
Guard -.-> Tool
Guard -.-> Output

class Goal,Reason,Decide,Observe,Output core;
class Tool runtime;
class Check,Human,Guard guard;
class State state;" %}
```

图 1-5：标准智能体循环的核心组件

### 状态管理

以下示例展示一个可跟踪目标、计划、记忆和工具结果的最小状态结构：

```python
class AgentState:
    goal: str                    # 最终目标
    current_step: int            # 当前步骤
    plan: List[str]              # 执行计划
    memory: List[Message]        # 对话历史
    tool_results: Dict           # 工具调用结果
    errors: List[str]            # 错误记录
```

### 控制流

* **循环机制**：直到达成目标或超时
* **分支判断**：根据中间结果调整路径
* **错误处理**：失败时的重试或回退策略
* **终止条件**：明确的完成标准

### 人机交互点

* **审批节点**：关键操作前询问用户
* **信息补充**：缺少必要信息时请求输入
* **进度反馈**：实时展示执行状态

## 1.5.6 最佳实践

把工作流真正搬进生产环境时，需要同时考虑“应当鼓励什么”与“必须限制什么”。下面的建议和禁止项可以看作工作流设计的最小护栏。

### 建议 ✅

* **设置明确的终止条件**：避免无限循环
* **实现渐进式披露**：先执行低风险操作
* **提供取消机制**：用户可随时中断
* **记录完整轨迹**：便于调试和审计

### 禁止 ❌

* **不要过度自主**：重大决策应询问用户
* **不要忽略错误**：每个失败都应该被处理
* **不要无限重试**：设置最大尝试次数
* **不要隐藏过程**：透明度建立信任

***

**下一节**: [本章小结](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/01_paradigm/summary.md)