AI Agent 学习笔记:工具调用、RAG 和项目落地思路
写在前面
实习结束后,我开始更认真地补 AI 应用开发。原因很现实:AI 工具发展太快,单纯做传统业务开发会越来越卷,但我自己的 AI 知识又还不够系统。
Agent 是我这段时间重点学习的方向之一。刚开始我以为 Agent 很神秘,后来发现先不用把它想得太玄。对应用开发来说,可以先理解成:模型不只是回答问题,还能根据任务选择工具、调用接口、读取资料,并把结果组织起来。
这篇文章是我的学习笔记,不是生产级 Agent 系统经验。重点记录我现在对工具调用、RAG 和项目落地的理解。
我怎么理解 Agent
普通聊天模型更像是“问一句答一句”。Agent 则多了一层任务执行能力。
一个简化流程可以这样看:
1 | |
所以 Agent 的关键不只是模型本身,还包括:
- 工具怎么定义
- 参数怎么约束
- 调用失败怎么办
- 结果怎么校验
- 是否需要多轮执行
这些问题都和后端工程能力有关。
工具调用
比如做一个旅行规划助手,模型自己并不知道实时天气和酒店信息。这时就需要工具。
工具可以是一个普通函数:
1 | |
也可以是一个 HTTP 接口:
1 | |
对我来说,工具调用最重要的是参数和返回值要清楚。模型如果传错参数,后端要能校验;工具调用失败时,也要有兜底提示,而不是直接让整个流程崩掉。
Prompt 不是越长越好
学习 Agent 时,我一开始很容易把 Prompt 写得很长,想把所有规则都塞进去。后来发现太长反而不好维护。
更适合的方式是把 Prompt 拆清楚:
- 角色是什么
- 任务目标是什么
- 可以使用哪些工具
- 输出格式是什么
- 遇到异常怎么处理
例如:
1 | |
Prompt 的作用是给模型边界,不是写一篇作文。
RAG 和 Agent 的关系
RAG 解决的是“模型不知道资料内容”的问题。比如企业知识库、课程资料、项目文档,都可以先切分、向量化,再根据用户问题检索相关片段。
Agent 可以在执行任务时调用 RAG 检索工具:
1 | |
我现在对 RAG 的理解是:它不是简单把文档丢给模型,而是要处理切分、召回、重排、上下文长度、回答可信度这些问题。
项目里容易踩的坑
我在做 AI 应用项目时,最常遇到的不是“模型完全不会回答”,而是工程细节问题:
- 模型输出不是合法 JSON
- 工具参数缺字段
- 第三方 API 超时
- 返回内容太长,前端展示不好
- 多轮对话里上下文越来越乱
- 用户输入不完整,模型仍然强行回答
这些问题让我意识到,AI 应用不是调一个模型接口就结束。真正落地时,后端要做很多兜底。
我会怎么设计一个简单 Agent 项目
如果现在让我做一个小型 Agent 项目,我会这样拆:
1. 明确业务场景
不要一上来就做“万能助手”。先选一个明确场景,比如:
- 旅行规划
- 简历优化
- 课程问答
- 文档检索
- 数据分析助手
场景越清楚,工具和输出格式越容易设计。
2. 定义工具
每个工具只做一件事:
- 天气查询
- 地点搜索
- 文档检索
- 数据库查询
- 文件解析
工具参数和返回结构要固定,方便模型调用,也方便后端校验。
3. 控制输出格式
如果前端要展示结构化结果,就不能只让模型自由发挥。
可以要求模型输出 JSON,并用 Pydantic 或后端 DTO 校验。如果解析失败,就进入兜底逻辑。
4. 加异常处理
AI 应用一定要考虑失败:
- 模型调用失败
- 工具调用失败
- JSON 解析失败
- 用户输入缺失
- 结果为空
这些失败不是小概率事件,而是开发时必须面对的情况。
后端能力在 AI 应用里的价值
学 Agent 之后,我反而更能理解后端基础的重要性。
一个 AI 应用最终还是需要:
- 接口设计
- 参数校验
- 数据存储
- 日志排查
- 权限控制
- 服务部署
- 异常兜底
模型能力很重要,但真正把它接到业务里,还需要工程能力。
这也是我现在的方向:不是放弃 Java 后端去追 AI,而是把后端能力和 AI 应用结合起来。
小结
Agent 对我来说还在学习阶段,但我已经能明确几个重点:
- Agent 的核心是任务拆解和工具调用
- 工具参数和返回格式要稳定
- RAG 可以补充模型不知道的知识
- Prompt 要控制边界,不是越长越好
- AI 应用必须重视异常处理和结构化输出
我现在不会说自己做过生产级 Agent 系统,更真实的说法是:我正在通过项目学习 Agent、RAG 和工具调用,并尝试把它们和后端工程能力结合起来。