Skip to main content

什么是 Agent

By 程序员Left (@coder_left)

随着小龙虾爆火，越来越多的 AI 应用产品走进大众视野中。但你是否好奇，究竟什么是 Agent？Agent 在 AI 应用中发挥着什么作用？这篇文章，Left 从工程的角度揭开 Agent 的神秘面纱

一、AI 应用的三种形式​

AI 应用的三种形式分别是 Chatbot、Workflow 和 Agent

Chatbot 的形态是指，每轮都由用户主动提问，AI 对用户提问进行回答，这种一问一答的形式是 Chatbot 最经典的特征。就像去服务台问路，你问一句前台答一句，你不开口，对方就不会有动作

Workflow 的形态比较灵活，可以理解为在传统代码工作流中加入 AI 能力。AI 运行在既定代码逻辑中，按照写死的流程节点老老实实干活。就像按步骤做菜的食谱，先洗菜、再切肉、最后下锅，大模型只负责其中切肉这一步

Agent 的形态是 ReAct 模式，即思考行动模式。区别于前两者，它具备最基本的感知、思考、决策、行动能力。更像把买菜做饭这整件事全包出去，中间遇到菜市场没开门，它会自己琢磨换个超市买

Image

那么，上面三种形态各有什么优缺点？

Chatbot 是比较早期的 AI 应用形态。它的优点是系统简单，适合简单的日常问答和单点任务；缺点是交互主权完全在用户手里，每一步都需要用户推着走，无法自主完成多步骤的复杂任务

Workflow 是让 AI 嵌入到传统代码流程中，优点是运行路径确定，编排灵活，速度快，适合规则明确的交付任务；缺点是流程被硬编码卡死，遇到突发情况无法动态调整路径

Agent 采用了 ReAct 模式，具备自主决策和行动能力，灵活性最高，适合目标明确但流程不确定的复杂任务。当然，由于多个环节都依赖大模型自主推理，成本高、响应慢，还会带来模型幻觉和输出不可控等工程治理挑战

Image

看到这里，有的朋友可能会问：Left，我该如何区分 Chatbot、Workflow 和 Agent？

Left 的一句话总结：Chatbot 看交互是否完全由用户单轮驱动，Workflow 看流程是否走固定的预设链路，Agent 看内部是否有自主循环的 ReAct 机制

Chatbot 本质上是对话驱动。现在的 Chatbot 可能会加上工具调用、长期记忆等功能，但它的核心目标依然是伺候好眼前的这轮问答，不会主动发散出新的延伸目标

Workflow 的本质是自动化流水线，流程怎么走早就定好了，大模型只是流水线上某几个工位的高级打工人，不能擅自跳出既定环节

Agent 的本质是自驱运转，核心在于让大模型通过思考和行动的闭环，自主探索解题路径，直到目标完成

Image

二、最小 Agent​

有些朋友可能会好奇，最小的 Agent 到底长什么样？答案就藏在 Agent Loop 里

我们直接剥离掉花哨的框架，看一段最简单的 Agent Loop 伪代码骨架：

messages = [{"role": "user", "content": "查一下深圳今天天气"}]

while True:
    response = client.chat(messages=messages, tools=tools)
    
    # 如果大模型认为任务已完成，跳出循环
    if response.stop_reason == "end_turn":
        print(response.content)
        break
        
    # 如果大模型决定调用工具
    if response.stop_reason == "tool_use":
        tool_result = call_tool(response.tool_name, response.tool_args)
        # 把工具执行结果塞回上下文，开启下一轮思考
        messages.append({"role": "tool", "content": tool_result})

这个极简循环主要分为三步：

1、请求大模型，并解析返回结果

2、分析 stop_reason 参数。如果要求 tool_use，就去调用对应的本地或外部工具

3、把工具调用结果写回上下文；如果 stop_reason 变成 end_turn，就结束本轮任务

这套实现是怎么支撑起 ReAct 模式的？拿查天气来串一遍两轮 Agent Loop：

1、第一轮 Loop（思考、决策与行动）： 大模型收到查深圳天气的诉求，发现自己缺乏实时数据，决策调用查天气工具（思考与决策）。随后系统拿到指令，替它执行天气接口获取数据（行动）

2、第二轮 Loop（感知与最终输出）： 系统把接口拿到的天气结果塞回消息列表，大模型通过新的上下文看到了现实世界的数据（感知）。大模型基于这些信息组织成自然语言回复用户，判断任务已经达成，返回结束信号跳出循环

感知外部环境、内部思考决策、调用工具行动，最小 Agent 的全貌其实就落在这个循环之间

Image

三、Agent 能力有哪些​

跑通上面的最小循环，仅仅算让 Agent 正常跑了起来。然而大模型的输出具有不确定性，要让它在复杂的真实业务里稳定工作，必须给它配上优秀的装备，也就是行业里常说的 Harness

Left 根据实际落地经验，把核心能力梳理成了八个模块。这部分后续会在本系列中逐步拆解，大家可以先建立全局认知：

上下文管理能力：记性好但不能撑爆肚子，在有限的 Token 窗口里自动提炼关键信息、扔掉冗余废话

任务管理能力：面对大目标时，懂得拆解成第一步、第二步，并且随时记录、获取当前的推进进度

记忆能力：分得清临时草稿和长期偏好，上周交代过的习惯，下周依然记得住

连接器能力：能灵活插拔各种外部 API、数据库与企业内网系统

Trace 能力：类似系统黑匣子，循环跑了十来步一旦出错，能精准倒查究竟是哪一步模型理解歪了

容灾能力：调用的工具超时或者报错时，系统能自动重试、降级，不至于整条链路直接卡死崩溃

Agent 编排能力：多个 Agent 协同干活时的分工与指挥机制

安全能力：防止恶意 Prompt 注入，死守核心数据与高危接口的执行权限

Image

有对某一块特别感兴趣的朋友，可以在评论区留言，Left 会把呼声最高的能力优先排上文章日程

四、工程上 Chat Bot、Workflow 与 应如何取舍​

三者并非非黑即白的选择题，核心取决于业务场景对任务确定性、容错率和自由度的要求

Image

实际业务工程中，大家很少走极端只选其中一种，常见的是取长补短的混合架构：

1、**Agentic Workflow：**在确定性极强的工作流骨架中，把某些复杂的节点换成小型 Agent。骨架保证整体任务不跑偏，节点内的 Agent 负责搞定局部的模糊任务

2、**把 Workflow 包装成 Agent 的工具：**Agent 负责全局调配与决策，当它判断需要执行一整套严谨的报表生成或付款流程时，直接把现成的 Workflow 当作一个原子工具去调，用确定的代码逻辑罩住核心风险

3、**前置路由分发：**先用轻量规则或小模型给用户的输入做分类：闲聊直接交给 Chatbot 处理，固定报销申请直接走 Workflow，复杂的开放式分析才唤醒 Agent。这样兼顾了系统响应速度与综合调用成本

Image