从 Web Agent 应用到执行型 Agent
一、我最开始对 Agent 的疑问
今天在学习 Agent 项目时,我发现一个现象:
很多项目虽然叫 Agent,但它的技术栈看起来依然是:
前端:Vue / React
后端:Spring Boot / FastAPI / Node.js
模型:OpenAI / Claude / 通义 / 文心 / 本地大模型
能力:RAG、Function Calling、工具调用、知识库问答
这让我有点疑惑。
因为在我的理解里,Agent 不应该只是一个 Web 应用加上大模型接口。
我原本理解的 Agent 更像是:
用户给它一个任务
它自己分析任务
自己寻找信息
自己调用工具
自己执行命令
自己验证结果
最后完成任务
比如 Codex、Claude Code、Cursor这类工具,它们可以进入代码仓库,读取本地文件,分析项目结构,修改代码,运行测试,查看报错,再继续修复。
这种感觉才更像真正的 Agent。
而很多 Web 项目中的 Agent,给我的感觉是:
Web 系统 + 大模型 API + 一些工具调用
更像是“Agent 应用开发”,而不是“执行型 Agent”。
二、LLM 应用、Agent 应用开发、执行型 Agent 的区别
我对 Agent 的理解,主要可以分成三层。
1. 普通 LLM 应用
普通 LLM 应用的核心是“生成内容”如日常使用的ChatGPT、Gemini、豆包、千问。
它通常是:
用户输入问题
↓
大模型理解问题
↓
大模型生成回答
↓
返回给用户
比如:
帮我写一封邮件
帮我总结一篇文章
帮我解释一段代码
帮我生成一段 SQL
这类应用主要特点是:
一次提问,一次回答
核心能力是文本生成
不一定真的执行任务
不一定能调用外部工具
所以它更像是一个“智能问答系统”或者“内容生成助手”。
2. Web Agent 应用开发
第二类是现在很多项目中常见的 Agent,也就是基于 Web 框架的 Agent 应用。
它一般是这样的结构:
用户
↓
前端页面
↓
后端服务
↓
大模型
↓
工具调用 / 知识库 / 数据库 / 外部 API
↓
返回结果
这种项目通常会有:
用户系统
聊天界面
任务管理
文件上传
知识库检索
向量数据库
工具调用
历史记录
权限控制
日志记录
它比普通 LLM 应用更进一步,因为它不只是让大模型回答问题,还可以让模型调用一些工具。
比如:
查询数据库
搜索知识库
调用天气 API
发送邮件
生成报表
调用业务接口
但是这类 Agent 的工具通常是开发者提前配置好的,模型只能在规定范围内调用。
也就是说,它不是完全自由地操作环境,而是在 Web 系统提供的能力边界内执行任务。
所以我觉得它更准确的名字应该是:
Agent 应用开发
或者:
Agentic Application
它的本质是把大模型和工具调用能力集成到一个 Web 产品里。
3. 执行型 Agent
第三类就是我认为更接近“真正 Agent”的形态。
比如:
Codex
Claude Code
Cursor Agent
Devin
OpenHands
这类 Agent 不只是会回答问题,而是可以进入一个真实的执行环境。
它可以:
读取文件
搜索代码
分析项目结构
调用终端
执行命令
运行测试
查看报错
修改代码
生成 Git diff
重复尝试直到任务完成
它的工作流程更像这样:
用户提出任务
↓
Agent 理解目标
↓
Agent 扫描项目文件
↓
Agent 找到相关代码
↓
Agent 制定修改方案
↓
Agent 修改代码
↓
Agent 运行测试
↓
Agent 分析报错
↓
Agent 继续修复
↓
最终输出结果
这类 Agent 的关键点不是“会不会聊天”,而是:
它能不能进入环境
它能不能调用工具
它能不能执行动作
它能不能验证结果
它能不能根据反馈继续调整
所以我今天最大的收获是:
真正强大的 Agent,不只是会聊天,而是能在环境中自主执行任务。
三、为什么很多 Agent 项目还是基于 Web 框架?
刚开始我会觉得奇怪:
既然 Agent 是可以调用工具、执行任务的,为什么很多项目还要基于 Web 框架?
因为 Agent 如果要做成一个真实产品,它依然需要工程系统来承载。
一个完整的 Agent 应用,通常还是需要:
前端页面:让用户输入任务、查看结果
后端服务:接收请求、管理任务状态
数据库:存储用户、任务、历史记录
权限系统:控制 Agent 能调用哪些工具
日志系统:记录 Agent 做了什么
任务队列:处理长时间运行的任务
文件系统:管理上传文件和生成结果
接口层:连接模型、工具、外部服务
所以 Web 框架不是没用,而是负责产品化和工程化。
可以这样理解:
Web 框架负责系统承载
大模型负责理解和决策
工具负责执行动作
Agent 编排负责把这些能力串起来
因此,很多企业中的 Agent 项目仍然需要 Spring Boot、FastAPI、Vue、React 这些技术。
不是因为 Agent 不高级,而是因为真正能上线的 Agent 系统,必须有完整的工程基础。
四、Web Agent 应用和执行型 Agent 的核心区别
总结出一个比较清晰的区别:
| 类型 | 主要能力 | 是否能操作环境 | 典型例子 |
|---|---|---|---|
| LLM 应用 | 问答、总结、生成内容 | 基本不能 | Chatbot、文档总结 |
| Web Agent 应用 | Web 系统 + 工具调用 + 业务流程 | 只能调用预设工具 | 客服 Agent、报表 Agent、知识库 Agent |
| 执行型 Agent | 文件读写、命令执行、代码修改、测试验证 | 可以进入执行环境 | Codex、Claude Code、Cursor Agent |
我觉得这张表可以很好地区分现在市面上的 Agent 项目。
很多项目虽然叫 Agent,但其实只是:
Chatbot + RAG + Function Calling
这类项目更像是 AI 应用开发。
而执行型 Agent 更强调:
环境访问能力
工具调用能力
任务执行能力
反馈循环能力
结果验证能力
五、我认为 Codex 这类才更接近执行型 Agent
像 Codex 这类 Agent,之所以让我觉得更接近真正的 Agent,是因为它不只是生成代码,而是可以围绕一个开发任务进行完整执行。
例如我提出一个需求:
帮我给这个 Spring Boot 项目增加一个用户登录接口
一个执行型 Agent 可能会这样做:
1. 读取项目目录结构
2. 找到 Controller、Service、Mapper、Entity
3. 判断项目使用的是 MyBatis 还是 JPA
4. 查看已有的用户表结构
5. 新增登录接口代码
6. 修改 Service 逻辑
7. 添加 DTO 或 VO
8. 运行 mvn test
9. 如果报错,读取错误信息
10. 修复代码
11. 最后生成 Git diff
这个过程明显不只是“生成一段代码”。
它是在一个真实环境中完成任务。
这也是我觉得执行型 Agent 更有价值的原因。
六、Agent 项目真正难的地方是什么?
今天我也意识到,Agent 真正难的地方不是简单调用大模型 API。
真正难的是这些:
如何让 Agent 正确理解任务?
如何让 Agent 选择合适工具?
如何控制 Agent 的权限?
如何防止它误删文件?
如何让它能安全执行命令?
如何记录它做过什么?
如何失败后自动重试?
如何让用户确认关键操作?
如何在长任务中保存状态?
如何验证任务是否真的完成?
也就是说,Agent 工程不只是模型能力问题,还是系统工程问题。
特别是执行型 Agent,还需要考虑:
文件系统权限
Shell 命令权限
沙箱隔离
Git 回滚
日志审计
用户确认
任务中断
异常恢复
安全边界
这也是为什么真正好的 Agent 系统并不好做。
七、对我学习路线的启发
我原本是 Java / Web 方向,现在想往 AI 和 Agent 工程师方向发展。
通过今天的学习,我发现 Web 背景不是劣势。
因为 Agent 项目落地依然需要大量工程能力:
后端接口设计
数据库设计
权限系统
任务队列
文件管理
日志追踪
系统部署
API 集成
异常处理
但是如果只停留在 Web + 大模型接口,那还不够。
接下来我应该重点补这些能力:
1. LLM 调用与 Prompt 设计
2. Function Calling / Tool Calling
3. RAG 和向量数据库
4. Agent 状态管理
5. 工具注册与工具编排
6. 本地文件读写
7. Shell 命令执行
8. Git diff 生成
9. Maven / Gradle 测试执行
10. 沙箱和权限控制
如果想做一个更有区分度的项目,我觉得可以做一个:
Java 本地代码仓库 Agent
它的核心功能可以是:
读取本地 Java 项目
分析 Spring Boot 项目结构
定位 Controller / Service / Mapper
根据需求修改代码
运行 mvn test
读取报错并自动修复
生成 Git diff
让用户确认是否应用修改
这个项目相比普通 AI 问答系统,会更接近真正的 Agent 工程。
八、对 Agent 的重新理解
学习之前,我可能会把 Agent 简单理解成:
大模型 + 工具调用
但现在我觉得这个理解太浅了。
今天之后,我更愿意这样理解 Agent:
Agent = 大模型的决策能力 + 工具调用能力 + 环境执行能力 + 反馈循环能力
其中最重要的是:
环境
工具
执行
反馈
验证
没有环境,Agent 就只能聊天。
没有工具,Agent 就只能生成内容。
没有执行,Agent 就不能真正完成任务。
没有反馈,Agent 就不能自我修正。
没有验证,Agent 就不知道任务是否真的完成。
所以,真正有价值的 Agent,不只是回答问题,而是完成任务。
九、总结
今天关于 Agent 的学习,最大的收获是:
1. 很多 Web Agent 项目,本质上是 Agent 应用开发
2. Web 框架不是 Agent 的核心,但它是 Agent 产品化的基础
3. 普通 LLM 应用主要负责内容生成
4. Web Agent 应用主要负责业务流程和工具调用
5. 执行型 Agent 更接近 Codex、Claude Code、Cursor Agent
6. 真正强大的 Agent 需要能进入环境、调用工具、执行任务、验证结果
7. Java/Web 背景依然有价值,但需要继续补 Agent Runtime 和工具编排能力
最后我觉得可以用一句话总结今天的理解:
Agent 的核心不是“会聊天”,而是“能在一个环境中,为了完成目标,持续调用工具并验证结果”。
这也是我接下来学习 Agent 工程时最重要的方向。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐

所有评论(0)