Agent到底是什么

2025年12月1日 · 阅读需 5 分钟

James Zheng

Javaer

随着大模型能力不断增强，越来越多企业开始尝试构建自己的 AI Agent。然而在真实业务场景中，很多团队很快会发现：

一个大模型 + 一个Agent，远远无法支撑复杂企业流程。

真正能够落地生产环境的，往往不是单个 Agent，而是一套可编排、可治理、可审计的 Agent Workflow（Agent工作流）。

本文将从工程视角介绍企业级 Agent 工作流设计思想。

1. 为什么单Agent不够

很多初学者理解的 Agent：

用户问题
    ↓
    LLM
    ↓
调用工具
    ↓
返回结果

例如：

用户：

帮我查询订单状态

Agent：

调用订单系统API
↓
获取结果
↓
生成回复

这种模式适合简单任务。

但企业真实场景往往更加复杂：

例如客服场景：

用户投诉商品质量
    ↓
识别情绪
    ↓
识别意图
    ↓
查询订单
    ↓
查询商品知识库
    ↓
生成处理方案
    ↓
人工审核
    ↓
发送回复

此时问题出现：

多步骤依赖
多系统调用
多个模型协作
需要人工介入
需要失败重试
需要审计日志

如果全部交给一个 Agent 自主决策：

Agent自己思考
Agent自己决定
Agent自己调用工具

将产生：

不稳定
不可预测
难以调试
难以监管

因此企业更倾向于：

Agent能力
+
Workflow编排

而不是完全自治 Agent。

2. 工作流与Agent区别

很多人容易混淆 Workflow 和 Agent。

Agent

核心特点：

自主决策

执行过程：

Thought
Action
Observation
Thought
Action
Observation

Agent每一步都由模型决定。

例如：

用户：
帮我分析这个客户

Agent可能：

查CRM
↓
查订单
↓
查聊天记录
↓
生成报告

整个路径是不确定的。

Workflow

核心特点：

流程确定

例如：

情绪分析
 ↓
意图识别
 ↓
知识库检索
 ↓
生成回复
 ↓
人工审核

路径提前定义。

模型只负责某个节点能力。

企业为什么偏爱Workflow

因为：

可观测
可调试
可回放
可审计
可治理

生产环境稳定性远比智能程度更重要。

因此很多企业Agent本质上是：

Workflow + Agent

而不是纯Agent。

3. LangGraph思想

目前最火的 Agent Workflow 框架之一是：

LangGraph

它的核心思想非常简单：

Graph
=
Node + Edge

即：

节点 + 连线

例如：

用户输入
    ↓
意图识别
    ↓
知识库检索
    ↓
答案生成

对应：

Node A
 ↓
Node B
 ↓
Node C

LangGraph进一步增加：

状态

State

条件路由

Conditional Edge

循环

Loop

例如：

生成答案
    ↓
质量检查
    ↓
不合格
    ↓
重新生成

形成闭环。

4. 状态机设计

企业级Agent最重要的设计其实不是Prompt。

而是：

State

状态管理。

例如客服工作流：

public class CustomerServiceState {

    private String userQuestion;

    private String sentiment;

    private String intent;

    private List<Document> documents;

    private String draftReply;

    private boolean needHumanReview;

}

整个流程都围绕 State 展开。

流程执行：

节点1
更新 sentiment
↓
节点2
更新 intent
↓
节点3
更新 documents
↓
节点4
更新 draftReply

最终形成：

共享上下文

而不是节点之间互相传参数。

推荐原则：

节点无状态
状态集中管理

这样：

易扩展
易测试
易回放

5. 条件路由

企业流程一定会出现分支。

例如：

好评
↓
自动感谢

差评
↓
进入售后处理

路由节点：

if(sentiment.equals("positive")){
    goto(POSITIVE_FLOW);
}else{
    goto(NEGATIVE_FLOW);
}

流程图：

          情绪分析
             ↓
      ┌──────┴──────┐
      ↓             ↓
    好评          差评
      ↓             ↓
 自动回复      售后处理

再比如：

意图识别：

物流问题
商品问题
退款问题
发票问题

分别路由：

物流Agent
商品Agent
退款Agent
财务Agent

形成多Agent协作架构。

6. 人工审核节点

这是企业落地中极其重要的一环。

很多团队上线Agent失败的原因：

没有Human-in-the-Loop

即：

人工介入能力

典型设计：

生成回复
 ↓
风险检测
 ↓
人工审核
 ↓
发送用户

高风险场景：

金融

贷款审批
投资建议

医疗

诊断建议
用药建议

客服

赔偿金额
退款金额

审核节点设计：

public class ReviewNode {

    public ReviewResult review(State state){

        if(state.isHighRisk()){
            return WAIT_HUMAN;
        }

        return PASS;
    }

}

企业往往还会提供：

通过
驳回
修改后通过

三种操作。

形成：

Human Approval Workflow

7. 企业客服Agent案例

下面以电商客服Agent为例。

整体架构

用户评价
    ↓
情感分析
    ↓
意图识别
    ↓
条件路由

好评流程

好评
 ↓
商品知识库
 ↓
生成感谢回复
 ↓
自动发送

差评流程

差评
 ↓
意图识别

可能识别：

水果不甜
物流太慢
包装破损
售后问题

进入对应Agent：

商品Agent
物流Agent
售后Agent

各Agent执行：

RAG检索
 ↓
知识增强
 ↓
Prompt组装
 ↓
生成回复

随后进入：

风险检测
 ↓
人工审核
 ↓
发送用户

整体流程图：

                用户评价
                    ↓
                情感分析
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
         好评               差评
          ↓                   ↓
      自动感谢          意图识别
                              ↓
                ┌──────┬──────┬──────┐
                ↓      ↓      ↓
            商品Agent 物流Agent 售后Agent
                ↓
             RAG检索
                ↓
             回复生成
                ↓
             风险检测
                ↓
             人工审核
                ↓
             回复用户

总结

企业级 Agent 的核心并不是让模型拥有无限自主能力，而是将大模型能力嵌入到可治理的业务流程中。

一个成熟的企业 Agent 系统通常具备：

Workflow编排
状态机管理
条件路由
多Agent协作
RAG知识增强
Human-in-the-Loop
全链路日志与审计

1. 为什么单Agent不够

2. 工作流与Agent区别

Agent​

Workflow​

企业为什么偏爱Workflow​