布吉岛 Agent

Appearance

Agent 开发 FAQ ​

这篇文章集中回答一下学习和开发 Agent 时经常遇到的问题。

学习 Agent 需要什么基础 ​

没有编程基础，可以学 Agent 吗？ ​

可以。

如果只是想先理解 Agent 是什么、MCP 怎么用、Agent 能做什么，完全可以借助 AI 辅助阅读和实践。

但如果目标是自己开发真实 Agent，后面还是需要逐渐补上基本编程能力，例如变量、函数、API、JSON、Git、命令行等。

不需要等到编程全部学完才开始学 Agent，但是也不要认为完全不用学编程。

学 Agent 一定要先学 Python 吗？ ​

不一定。

如果完全没有编程基础，Python 确实是一个比较合适的起点，大量大模型和 Agent 示例也会优先提供 Python 版本。

但如果已经熟悉 Java、TypeScript、Go 等语言，没有必要先停下来重新系统学习一遍 Python。

Agent 开发真正需要理解的是：

text
模型怎么调用
Tool 怎么执行
Context 怎么传递
Agent 怎么继续下一步

而不是必须使用某一种语言。

学 Agent 之前必须先学 Transformer、RAG 和微调吗？ ​

不需要。

如果目标只是开始开发 Agent，可以先学习模型调用、Tool Calling、Agent Loop，再进入 Framework 和项目。

Transformer、RAG、微调也有价值，但它们属于不同方向的知识。

其中：

  • LLM 原理适合希望理解模型底层或准备相关面试时深入
  • RAG 在知识库、文档检索等项目中非常重要
  • 微调则只在一部分业务和岗位中真正需要

具体可以参考 Agent 开发学习路线。

应该先自己写 Agent，还是直接学习框架？ ​

建议至少亲手跑通一次最小 Agent，再进入框架。

不需要自己造一个完整的 LangGraph，也不需要实现复杂 Runtime。

只要真正理解一次：

text
Model
↓
Tool Call
↓
执行 Tool
↓
Tool Result
↓
Model 再决定下一步

就足够了。

我们后面学习 Framework 时，会更容易判断框架到底替你解决了什么。

具体可以参考 从零实现一个最小 AI Agent 和 从零实现一个最小 Coding Agent。

Agent Framework 要全部学一遍吗？ ​

不用。

比起同时学习很多框架，更推荐先选择一个适合当前方向的主框架，完整做一次项目。

等真正遇到状态管理、Context、Tool、Workflow 等问题以后，再去比较不同框架的实现，区别会清楚很多。

RAG、Memory、MCP 这些是不是 Agent 必备能力 ​

一个 Agent 一定需要 RAG 吗？ ​

不一定。

RAG 主要解决的是：

怎样让模型获取外部知识。

而 Agent 更关注：

怎样根据任务动态决定下一步并采取行动。

企业知识助手、文档问答 Agent 可能非常依赖 RAG，但 Coding Agent、Browser Agent 等完全可能不需要复杂 RAG。

所以不要因为开发 Agent，就默认必须先搭一个向量数据库。

一个 Agent 一定需要 Memory 吗？ ​

不一定。

如果任务只有几轮，并且所有必要信息都能放在当前 Context 中，可能根本不需要额外的长期 Memory。

Memory 更适合解决跨会话、长期任务、用户偏好、历史事实等持续保存的问题。

还要注意：

text
当前 Context
Session 中的历史
长期 Memory

不是完全相同的概念。

没有必要因为 Agent“忘了东西”，就立刻增加一个向量数据库当 Memory。

最好在真正需要的时候再加。

一个 Agent 一定需要 MCP 吗？ ​

不需要。

如果系统只有几个自己开发的 Tool，直接通过普通 Tool Calling 接入完全没有问题。

MCP 更适合解决：

外部工具、资源和能力如何以统一方式被不同 Agent 或应用接入。

所以 MCP 是一种非常重要的能力标准，但不是“没有 MCP 就不算 Agent”。

MCP 会取代普通 Tool Calling 吗？ ​

其实不应该这样理解。

Tool Calling 解决的是：

模型怎么表达“我要调用这个工具”。

MCP 更关注的是：

应用怎么和外部工具、资源等能力建立标准化连接。

它们处在不同层面。

很多系统最终可能同时存在：

text
Model
↓
Tool Calling
↓
Agent Runtime
↓
MCP Client
↓
MCP Server

所以 MCP 不是 Tool Calling 的“高级版本”。

MCP 接得越多，Agent 就越强吗？ ​

不一定。

Agent 可以访问的能力更多，理论上能够做的事情确实更多，但同时模型也要在更多工具之间做选择。

如果十几个 Tool 功能非常相似：

text
search
search_docs
search_web
search_database
find
query

反而可能增加错误选择。

真正重要的是：

Tool 的边界是否清晰，以及当前任务到底需要哪些 Tool。

这个问题和 MCP 数量本身没有直接关系。

Agent、Workflow 和 Multi-Agent 怎么选 ​

Workflow 和 Agent 是不是二选一？ ​

不是。

真实系统完全可以同时使用两者。

例如：

text
固定流程
↓
到达需要判断的节点
↓
交给 Agent 决定
↓
继续固定流程

对于高确定性的步骤，Workflow 通常更稳定。

只有那些确实需要模型根据当前情况动态判断的地方，才有必要交给 Agent。

所以两者更多是组合关系，而不是谁取代谁。

接了 Tool 的聊天机器人，就一定算 Agent 吗？ ​

不一定需要纠结这个 Tool 。

相比“它到底算不算 Agent”，更值得关注的是：

  • 模型是否能够根据任务主动选择 Tool
  • 是否能够看到真实 Tool Result
  • 是否能根据结果重新决定下一步
  • 是否能够持续推进任务直到结束

一个系统即使叫“Agent”，如果只是固定调用一次搜索再回答，本质上可能还是普通AI应用。

Multi-Agent 一定比单 Agent 更强吗？ ​

不一定。

多个 Agent 可以进行角色分工，但同时会增加：

text
任务怎么拆
谁负责什么
Context 怎么传
结果冲突怎么办
状态怎么同步

这些额外问题。

如果一个 Agent 已经可以稳定完成任务，没有必要为了“架构更高级”强行拆成多个 Agent。

合理的顺序应该是：

text
先把单 Agent 做稳
↓
发现明确的职责或 Context 问题
↓
再判断是否需要 Multi-Agent

Planner、Reviewer、Researcher 都需要单独做成 Agent 吗？ ​

也不一定。

“规划”“审查”“研究”是一种职责，不意味着一定要对应三个独立 Agent。

有时候一个 Agent 通过不同阶段的 Prompt 或 Tool 就能完成这些工作。

只有当不同职责真的需要独立 Context、工具集合、权限或者执行周期时，拆成不同 Agent 才更有意义。

实际开发为什么总会遇到各种问题 ​

为什么 Agent Demo 看起来很好，放进真实项目以后却不稳定？ ​

因为 Demo 往往只展示了一条比较理想的成功路径。

进入真实项目以后会出现：

text
Tool 失败
参数错误
Context 过长
模型做错判断
网络超时
权限不足
任务无法完成

这时候问题就不再只是“模型能不能回答”。

还需要 Runtime、Tool、Context、错误处理和安全边界一起工作。

这也是 从最小 Coding Agent 到 Pi 主要讨论的问题。

Agent 总是调用错 Tool，是不是模型不够强？ ​

不一定。

在换模型之前，可以先检查：

  • Tool 名字是不是容易混淆
  • Description 是否把使用场景说清楚
  • 参数 Schema 是否合理
  • 当前 Context 是否包含正确的信息
  • Tool Result 是否真实反映执行结果

很多看起来像“模型不会用 Tool”的问题，其实首先是 Tool 设计问题。

这类情况可以参考 Agent 开发常见误区。

Agent 一直循环，不结束怎么办？ ​

Agent Runtime 本来就应该存在停止机制。

常见的停止条件包括：

text
任务已经完成
出现无法继续的错误
达到最大 Step
执行超时
用户主动 Abort

不能只告诉模型：

“完成任务以后记得停止。”

然后期待它永远正确判断。

Agent 应该知道怎么继续，也必须能够在合适的时候停下来。

Tool 调用失败以后，应该自动重试吗？ ​

要看失败类型。

例如临时网络错误，可以考虑有限次数重试。

如果是：

text
参数本身错误
权限不足
文件不存在
业务条件不满足

盲目执行相同重试通常没有意义。

更合理的做法是把真实错误返回给模型，让它判断是否需要调整参数、换一个 Tool，或者直接停止。

Agent 是不是一定要全自动运行？ ​

不是。

很多真实系统本来就应该在关键节点让人确认。

例如：

  • 删除数据
  • 修改生产环境
  • 支付
  • 对外发送正式消息
  • 执行高风险命令

Human-in-the-loop 并不意味着 Agent“不够智能”。

对于高风险任务来说，可控通常比完全自动更重要。

Agent 的成本和运行环境 ​

Agent 会不会非常烧 Token？ ​

有可能。

普通聊天可能只调用一次模型，而 Agent 往往会不断重复：

text
Model
↓
Tool
↓
Model
↓
Tool
↓
Model

并且每一轮都可能携带部分历史 Context、Tool Schema 和 Tool Result。

所以成本不仅取决于：

一次调用用了多少 Token。

还取决于：

一整个任务调用了多少次模型，以及每一轮携带多少 Context。

任务变长以后，Context 管理也会越来越重要。

Tool 越多，Token 消耗也一定越大吗？ ​

不一定线性增长，但 Tool Schema 本身通常也需要进入模型可以看到的上下文。

如果同时暴露大量复杂 Tool：

text
名称
Description
参数 Schema

它们都会占用一定 Context，并增加模型选择工具时的复杂度。

所以 Tool 不是接得越多越好。

更合适的是只暴露当前任务真正可能需要的能力。

开发 Agent 一定需要 GPU 吗？ ​

不需要。

完全可以直接使用云端模型 API：

text
OpenAI
Anthropic
Gemini
DeepSeek
Qwen API
……

Agent 本身可以运行在普通电脑或者普通服务器上。

GPU 的需求通常出现在：

text
本地部署模型
模型微调
模型训练
推理优化

开发 Agent 一定需要本地部署模型吗？ ​

不需要。

对于学习和很多业务项目，先使用模型 API 往往更简单。

只有出现：

  • 数据不能离开本地环境
  • 需要部署私有模型
  • 调用量很大，需要重新计算成本
  • 需要特殊模型能力
  • 需要自行控制推理服务

这些需求时，本地部署才会变得更加重要。

相关内容在 LLM 栏目继续深入。

做 Agent 一定需要微调模型吗？ ​

通常不需要。

Agent 项目效果不好时，常见的检查顺序应该是：

text
任务设计
↓
Context
↓
Prompt
↓
Tool
↓
模型能力

而不是第一步就训练一个新模型。

只有当确认问题确实来自模型能力，并且有足够高质量数据时，才值得进一步评估 Fine-tuning。

微调是一种模型能力调整手段，不是 Agent 的标准组件。

学到什么程度才可以开始做项目 ​

是不是要把 Agent 所有概念都学完，才能开始项目？ ​

不需要。

Agent 领域变化很快，如果等待：

text
Memory 学完
MCP 学完
RAG 学完
Multi-Agent 学完
所有框架学完

很可能永远没有真正开始。

更实用的方式是：

text
先理解基本结构
↓
做一个小项目
↓
遇到真实问题
↓
再回来补对应知识

很多概念只有进入项目以后，才会知道它为什么存在。

第一个 Agent 项目应该做多复杂？ ​

不用复杂。

第一次真正做 Agent，更适合选择：

  • 目标明确
  • Tool 不多
  • 结果容易验证
  • 出错代价低

的任务。

例如一个能够读取文件、修改代码并运行测试的最小 Coding Agent，就比一开始做一个“自动管理整个公司”的 Multi-Agent 系统更适合学习。

学完入门以后，下一步应该去哪？ ​

如果目标是继续开发：

text
入门
↓
框架
↓
项目

就可以作为主线。

「原理」适合遇到感兴趣的问题时深入。

「LLM」和「RAG」适合拓宽专项知识。

准备求职时，再重点进入「面试题」。

完整说明可以参考 Agent 开发学习路线。

最后 ​

Agent 领域会不断出现新的框架、新协议和新名词。

遇到一个新概念时，可以先问三个问题：

text
它解决什么问题？

我的项目现在有没有这个问题？

如果用它，会不会带来更好的效果？

如果这三个问题还回答不出来，就不要着急把它加进系统。