用 AI Agent 构建自动化工作流

从"按规则执行"到"按意图执行"，自动化工作流正在经历一场范式迁移。

一、引言：当 RPA 遇见大模型

传统的自动化工作流，本质上是一套确定性规则引擎。你告诉系统："如果 A 发生，就执行 B"。RPA（机器人流程自动化）工具如 UiPath、影刀，以及 Zapier、Make 等无代码平台，都是这一范式的代表。它们擅长处理结构化、重复性任务，但面对模糊意图、动态上下文和复杂决策时，往往束手无策。

AI Agent（智能体）的出现改变了游戏规则。Agent 不是简单地"执行指令"，而是理解意图、规划步骤、调用工具、反思修正。它让自动化工作流从"按规则执行"跃迁到"按目标执行"。

本文将从架构设计、实战落地、技术选型三个维度，探讨如何用 AI Agent 构建下一代自动化工作流。

---

二、传统自动化 vs AI Agent 自动化

维度	传统自动化（RPA/规则引擎）	AI Agent 自动化
输入	结构化数据、固定触发器	自然语言、多模态输入、模糊意图
逻辑	预定义规则、if-else 分支	LLM 推理、动态规划、工具调用
适应性	规则一变，流程全改	上下文感知、自主调整执行路径
边界	明确且封闭	开放、可扩展、能处理未知情况
典型场景	数据迁移、定时报表、邮件分拣	智能客服、代码审查、竞品分析、投资决策

举个例子：传统自动化可以帮你"每天早上 9 点把销售数据从 CRM 导出到 Excel 并发邮件"；而 AI Agent 可以帮你"分析上季度所有丢单原因，找出共性问题，并起草一份给销售总监的改进建议"——后者涉及数据查询、统计分析、归因推理、文档生成，每一步都无法用固定规则预先定义。

---

三、AI Agent 工作流的核心架构

一个生产级的 AI Agent 工作流，通常由以下四层构成：

┌─────────────────────────────────────────────────────────────┐
│  交互层 (Interface)                                          │
│  Slack / 钉钉 / 邮件 / Webhook / 语音                        │
└──────────────────────┬──────────────────────────────────────┘
                       │ 自然语言指令
┌──────────────────────▼──────────────────────────────────────┐
│  编排层 (Orchestration)                                      │
│  LangChain / LlamaIndex / Dify / Coze / 自研编排引擎          │
│  负责任务分解、状态管理、循环控制、人机协同                    │
└──────────────────────┬──────────────────────────────────────┘
                       │ 结构化任务
┌──────────────────────▼──────────────────────────────────────┐
│  能力层 (Tools & Skills)                                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │ 代码执行  │ │ API 调用  │ │ 数据库   │ │ 搜索引擎  │       │
│  │ (Python) │ │ (REST)   │ │ (SQL)    │ │ (RAG)    │       │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘       │
└──────────────────────┬──────────────────────────────────────┘
                       │ 执行结果
┌──────────────────────▼──────────────────────────────────────┐
│  记忆层 (Memory)                                             │
│  短期记忆（对话上下文）/ 长期记忆（向量数据库 + 知识图谱）      │
└─────────────────────────────────────────────────────────────┘

3.1 编排层：从 Chain 到 Graph

早期的 Agent 框架（如 LangChain）使用链式结构（Chain）：输入 → LLM → 工具 → 输出。这种线性结构适合简单任务，但面对复杂工作流时，需要**图结构（Graph）**来支持分支、循环、并行和条件跳转。

以 LangGraph 为例，一个典型的审批工作流可以建模为状态图：

from langgraph.graph import StateGraph, END

# 定义状态
class WorkflowState(TypedDict):
    request: str
    analysis: str
    decision: str
    approved: bool

# 构建图
workflow = StateGraph(WorkflowState)

# 添加节点
workflow.add_node("analyze", analyze_request)      # AI 分析请求
workflow.add_node("human_review", human_review)    # 人工审核
workflow.add_node("auto_approve", auto_approve)    # 自动通过
workflow.add_node("reject", reject_request)        # 驳回

# 添加边
workflow.set_entry_point("analyze")
workflow.add_conditional_edges(
    "analyze",
    route_decision,  # 根据风险评分决定路径
    {
        "high_risk": "human_review",
        "low_risk": "auto_approve",
        "invalid": "reject"
    }
)
workflow.add_edge("human_review", END)
workflow.add_edge("auto_approve", END)
workflow.add_edge("reject", END)

app = workflow.compile()

3.2 能力层：Tool Use 是 Agent 的"手"

没有工具的 LLM 只是一个"嘴炮"。Agent 的核心能力在于自主决策何时调用何种工具。OpenAI 的 Function Calling、Claude 的 Tool Use，以及开源社区的 MCP（Model Context Protocol），都在标准化这一接口。

一个设计良好的工具应该具备：

• 清晰的 Schema：名称、描述、参数类型、必填项
• 幂等性：同一输入应产生同一输出，避免副作用
• 错误可恢复：工具失败时返回结构化错误，供 LLM 决策重试或降级

// MCP 工具定义示例
{
  name: "query_database",
  description: "执行 SQL 查询，返回结果。仅支持 SELECT 语句。",
  parameters: {
    type: "object",
    properties: {
      sql: { type: "string", description: "SQL 查询语句" }
    },
    required: ["sql"]
  }
}

3.3 记忆层：从"金鱼"到"管家"

短期记忆通过滑动窗口维护对话上下文；长期记忆则需要向量数据库（如 Milvus、Pinecone）存储历史交互，配合 RAG 检索。对于工作流自动化，**工作记忆（Working Memory）**尤为关键——Agent 需要记住当前任务的中间状态、已完成的步骤、待办事项。

---

四、实战：三个典型工作流落地

案例 1：智能客服工单处理

场景：用户通过邮件提交售后问题，Agent 自动分类、查询知识库、生成回复草稿，复杂问题转人工。

工作流设计：

[收到邮件] 
    → [LLM 提取意图和情感] 
        → 情感负面 / 问题复杂 → [转人工队列]
        → 标准问题 → [RAG 检索知识库] 
            → [生成回复] 
                → [人工确认后发送]

关键实现：

• 使用 RAG 检索产品手册和历史工单，确保回答有据可依
• 情感分析节点作为网关，实现人机协同的分流
• 所有操作留痕，便于后续审计

案例 2：自动化代码审查

场景：GitHub PR 提交后，Agent 自动进行代码审查，检查安全漏洞、风格一致性、性能隐患，并生成 Review 评论。

工作流设计：

[PR Webhook 触发]
    → [获取 Diff]
        → [静态分析：ESLint / SonarQube]
        → [LLM 语义分析：逻辑漏洞、边界条件]
            → [聚合结果]
                → [生成结构化 Review 评论]
                    → [发布到 GitHub]

关键实现：

• 将大文件 Diff 分块处理，避免超出上下文窗口
• 结合 AST 解析和 LLM 推理，兼顾准确性和深度
• 使用缓存避免重复分析未变更的文件

案例 3：竞品情报自动采集

场景：每周自动采集竞品网站的价格、功能更新、用户评论，生成竞品分析报告。

工作流设计：

[定时触发]
    → [爬虫抓取网页 / API 获取数据]
        → [LLM 提取结构化信息：价格、功能点、情感倾向]
            → [存入数据库]
                → [周五汇总生成 Markdown 报告]
                    → [发送邮件给产品团队]

关键实现：

• 使用 Firecrawl / Jina AI 将网页转为 LLM 友好的 Markdown
• 提取阶段使用结构化输出（JSON Schema），确保数据一致性
• 报告生成使用长文本模型（Claude 3.5 Sonnet / GPT-4o）

---

五、技术选型指南

层级	开源方案	商业方案	适用场景
编排框架	LangGraph、LlamaIndex Workflows、AutoGen	Dify、Coze、字节的扣子	快速原型选 Dify/Coze；深度定制选 LangGraph
LLM 基座	Llama 3、Qwen、DeepSeek	GPT-4o、Claude 3.5、Gemini	复杂推理用 Claude；中文场景用 Qwen/DeepSeek
向量数据库	Milvus、Weaviate、Chroma	Pinecone、Zilliz Cloud	大规模生产用 Milvus/Pinecone
工具协议	MCP（Model Context Protocol）	各平台自有协议	跨平台工具生态建议遵循 MCP 标准
部署运维	Kubernetes + Helm	阿里云百炼、AWS Bedrock、Azure AI	有运维能力自托管；追求速度用托管服务

---

六、挑战与最佳实践

6.1 可靠性：LLM 不是确定性的

• 问题：同样的输入，LLM 可能产生不同的工具调用决策，导致工作流行为不稳定。
• 对策：
  • 对关键节点设置确定性校验层（如正则、JSON Schema 校验）
  • 使用**少样本提示（Few-shot）**规范输出格式
  • 引入**重试 + 回退（Fallback）**机制

6.2 成本：Token 就是钱

• 问题：Agent 的"思考过程"往往比最终输出长得多，频繁调用 LLM 成本高昂。
• 对策：
  • 使用小模型做路由，大模型做推理（如 GPT-4o-mini 分类 → GPT-4o 执行）
  • 缓存常见意图的推理结果
  • 限制最大循环次数，防止无限思考

6.3 安全：Agent 的权限边界

• 问题：给 Agent 开放数据库写权限、邮件发送权限，等同于给它一把"双刃剑"。
• 对策：
  • 遵循最小权限原则，工具权限粒度要细
  • 关键操作（如转账、删除数据）必须人工确认
  • 所有工具调用记录审计日志

6.4 可观测性：黑盒调试

• 问题：Agent 的决策过程不透明，出了问题难以定位。
• 对策：
  • 使用 LangSmith、Langfuse 等工具追踪每一步的输入输出
  • 要求 LLM 输出思考链（Chain-of-Thought），将推理过程显性化
  • 建立"决策日志"，记录"为什么选择工具 A 而非工具 B"

---

七、结语：从 Automation 到 Agentic Workflow

AI Agent 不是对传统自动化的取代，而是升维。它填补了"规则无法覆盖的灰色地带"——那些需要理解、推理、判断的任务。

构建 Agent 工作流时，记住一个核心原则：让 Agent 做它擅长的（理解、推理、决策），让传统工具做它们擅长的（精确执行、高性能、确定性）。两者结合，才能构建出既智能又可靠的自动化系统。

未来，"工作流"的定义将被改写。不再是人设计流程图、系统按图索骥，而是人描述目标、Agent 自主规划路径、人在关键节点把关。这，就是 Agentic Workflow 的终极形态。

---

推荐阅读：

• 《ReAct: Synergizing Reasoning and Acting in Language Models》
• LangGraph 官方文档：Multi-Agent Workflows
• Anthropic 博客：《Building effective agents》