如何构建真正可用的 AI Agent：开发者实践教程

适合谁读

这篇教程适合已经了解一点 Python 和大模型基础、想把 AI Agent 用到真实任务里的开发者。

你不需要一开始就掌握复杂的多 Agent 框架。真正重要的是：先做出一个能稳定完成任务的单 Agent，再决定是否需要扩展成多 Agent 系统。

一、先明确：LLM 不是 Agent

LLM 本质上是一个文本生成模型。它可以：

• 总结文章
• 写代码
• 翻译文本
• 回答问题
• 模仿某种写作风格

但单独的 LLM 有明显限制：

• 没有默认持久记忆
• 不会主动执行动作
• 不能自己调用系统工具
• 容易在不确定时编造内容

可以把 LLM 理解成一个“读过很多资料的实习生”。

而 AI Agent 是在 LLM 外面加了一层执行能力。一个 Agent 通常包含：

• 模型：负责理解、推理和生成文本
• 工具：比如搜索网页、读文件、执行代码、发邮件
• 记忆：保存任务上下文或历史行为
• 循环：思考 → 调工具 → 观察结果 → 再思考 → 输出结果

所以，Agent 不是“更聪明的 LLM”，而是“可以使用工具并完成任务的 LLM 应用”。

二、第一原则：永远从一个 Agent 开始

很多人一上来就想做多 Agent：

• 一个规划 Agent
• 一个执行 Agent
• 一个审查 Agent
• 一个搜索 Agent
• 一个总结 Agent

这通常是过度设计。

正确做法是：

先做一个单 Agent，让它在真实任务上跑起来，再根据评估结果决定是否扩展。

原因很简单：

• 多 Agent 会增加 token 成本
• 多 Agent 会增加协调成本
• Agent 之间可能互相放大错误
• 复杂系统更难调试和验证
• 很多任务其实一个 Agent 就够了

如果一个单 Agent 已经能稳定完成任务，多 Agent 只会让系统更慢、更贵、更难维护。

三、构建 Agent 前先看预算

Agent 系统会消耗 token，而 token 就是成本。

你可以按预算选择模型运行方式。

预算有限：用 Ollama 本地跑模型

适合：

• 学习
• 原型验证
• 本地实验
• 低成本测试

优点：

• 免费
• 可离线
• 不依赖外部 API
• 适合小规模实验

缺点：

• 本地硬件限制明显
• 小模型能力不如前沿闭源模型
• 推理速度可能较慢

本地硬件不够：用 Google Colab

适合：

• 没有 GPU
• 想快速跑 notebook 示例
• 需要临时云端算力

预算充足：用商业 API

可以考虑：

• OpenAI
• Anthropic Claude
• Google Gemini

适合：

• 更高质量任务
• 生产前验证
• 复杂推理或代码任务

但要注意，每次工具调用、上下文传递、多 Agent 协作都会增加 token 消耗。

四、先定义任务，不要先选框架

很多 Agent 项目失败，是因为一开始就在选框架：

• LangChain
• CrewAI
• AutoGen
• LlamaIndex
• 自研框架

但更重要的问题是：

1. 这个 Agent 要完成什么任务？
2. 输入是什么？
3. 输出是什么？
4. 成功标准是什么？
5. 失败时如何判断？
6. 是否需要工具？
7. 是否需要记忆？
8. 是否真的需要多 Agent？

例如：

不清晰的目标：

做一个帮我处理文档的 Agent。

清晰的目标：

给 Agent 一个财报 PDF，它需要提取收入、利润、现金流、风险因素，并输出固定格式的中文摘要。结果要能被人工用 checklist 审查。

后者才适合进入实现。

五、构建第一个单 Agent

一个最小可用 Agent 可以按这个结构设计：

输入任务
  ↓
模型理解任务
  ↓
判断是否需要工具
  ↓
调用工具
  ↓
读取工具结果
  ↓
继续推理
  ↓
输出结构化结果

示例任务

假设你要构建一个“财务文档总结 Agent”。

它的职责是：

• 读取一份财务报告
• 提取关键指标
• 总结管理层观点
• 标出风险因素
• 输出中文摘要

推荐输出格式

## 财务摘要

公司：
报告期：

## 关键指标

- 收入：
- 净利润：
- 毛利率：
- 现金流：

## 管理层观点

...

## 风险因素

...

## 需要人工复核的点

...

固定输出格式很重要，因为它能降低随机性，也方便后续做评估。

六、先评估单 Agent，而不是急着加 Agent

文章引用的研究给了一个有用经验：

如果单 Agent 在真实任务上的成功率超过约 45%，通常不需要加 Agent。

这个数字不能机械套用，但它提醒我们：多 Agent 不是默认升级路径。

你应该先准备 50–100 个代表性任务，然后评估单 Agent 表现。

评估方式

可以用三种方式：

1. 人工审查
   • 人看结果是否正确
   • 适合早期验证
2. 标准答案对比
   • 有 known-good answer
   • 适合结构化任务
3. Checklist 打分
   • 是否提取了关键字段
   • 是否遗漏风险
   • 是否编造内容
   • 是否符合格式

示例 checklist

- 是否提取了收入？
- 是否提取了利润？
- 是否提取了现金流？
- 是否总结了风险？
- 是否出现未经来源支持的结论？
- 是否按固定格式输出？
- 是否标出了不确定信息？

如果单 Agent 表现不好，第一反应不应该是“再加几个 Agent”。

应该先优化：

• prompt
• 工具
• 输入格式
• 输出格式
• 模型选择
• 任务拆解
• 上下文质量

七、什么时候才需要多 Agent？

只有当任务天然可并行时，才考虑多 Agent。

不适合多 Agent 的任务

这类任务最好保持单 Agent：

• 顺序执行的任务
• 强依赖上下文连续性的任务
• 简单总结
• 单文件分析
• 单轮问答
• 小范围代码修改

例如：

读取一篇文章 → 总结核心观点

这不需要多 Agent。

适合多 Agent 的任务

这类任务可以考虑多 Agent：

• 多来源研究
• 多模块代码审查
• 大型文档对比
• 多候选方案评估
• 可拆分的数据分析任务
• 一个 Agent 执行、另一个 Agent 独立审查

例如：

分析一个项目是否适合重构：
- Agent A：读架构
- Agent B：读测试
- Agent C：读部署
- Supervisor：汇总结论

这种任务可以并行，而且不同 Agent 的职责边界清晰。

八、多 Agent 的两种常见结构

1. 中心化结构

结构类似：

Supervisor Agent
  ├── Research Agent
  ├── Coding Agent
  └── Review Agent

Supervisor 负责任务拆分、汇总和最终判断。

适合：

• 分析型任务
• 报告生成
• 代码审查
• 有明确验收标准的任务
• 企业内部流程

优点：

• 更容易控制质量
• 输出一致性更好
• 方便审计

缺点：

• Supervisor 可能成为瓶颈
• 设计不好会增加无效沟通

2. 去中心化结构

结构类似：

Agent A ↔ Agent B ↔ Agent C

多个 Agent 平行探索、互相补充。

适合：

• 开放式研究
• 多角度头脑风暴
• 信息搜索
• 候选方案生成

优点：

• 探索空间更大
• 容易发现不同视角

缺点：

• 更容易跑偏
• 更难统一结论
• 更需要后续审查

九、控制 Agent 数量和工具数量

多 Agent 系统不是越大越好。

文章给出的实用建议是：

• Agent 团队控制在 3–4 个以内
• 每个 Agent 只给 1–3 个必要工具

这是很重要的工程原则。

为什么工具不能太多？

如果一个 Agent 同时拥有：

• 搜索
• 文件读写
• Shell
• 数据库
• 浏览器
• 发消息
• 部署权限

它就很容易做出错误动作，而且行为难以审计。

更好的做法是：

Research Agent：只给 web_search / web_extract
Code Agent：只给 read_file / patch / terminal
Review Agent：只给 read_file / terminal

权限越小，系统越安全，也越容易定位问题。

十、必须建设 evals

文章最后的核心结论是：

未来真正赢的不是 Agent 最多的团队，而是 evals 做得最好的团队。

evals 就是评估系统。

没有 evals，你无法判断：

• Agent 是否真的变好了
• 多 Agent 是否比单 Agent 好
• 新模型是否值得替换旧模型
• prompt 修改是否引入了退化
• 工具增加是否带来收益

evals 至少要覆盖三类指标

1. 准确性

结果是否正确？

例如：

• 摘要是否忠实原文
• 代码是否通过测试
• 数据是否计算正确
• 是否出现幻觉

2. 效率

完成任务的成本如何？

例如：

• token 消耗
• 响应时间
• 工具调用次数
• 人工介入次数

3. 轨迹

Agent 是否用正确方式完成任务？

例如：

• 是否先读文件再修改
• 是否误用了工具
• 是否跳过验证
• 是否在没有上下文时编造答案

轨迹评估很关键，因为 Agent 可能偶然给出正确答案，但过程是错的。

十一、一个推荐的开发流程

可以按下面这套流程构建 Agent 系统。

Step 1：写清楚任务定义

目标：
输入：
输出：
成功标准：
失败标准：
允许使用的工具：
不允许做的事：

Step 2：做单 Agent 原型

先不要拆多个 Agent。

只做一个 Agent，并给它最少工具。

Step 3：准备 50–100 个测试样本

样本要来自真实任务，而不是玩具 demo。

Step 4：跑评估

记录：

• 成功率
• 错误类型
• token 成本
• 工具调用轨迹
• 人工修正点

Step 5：先优化单 Agent

优化顺序推荐：

1. 改输入格式
2. 改输出格式
3. 改 prompt
4. 改工具
5. 换模型
6. 拆任务

Step 6：判断是否需要多 Agent

只有满足下面条件才扩展：

• 任务可并行
• 单 Agent 有明显瓶颈
• 多 Agent 能降低时间或提升质量
• 有 evals 能验证收益
• 有 supervisor 或审查机制

Step 7：小规模多 Agent

不要超过 3–4 个 Agent。

每个 Agent 只负责一个清晰职责。

Step 8：上线前做回归评估

确保多 Agent 版本确实优于单 Agent，而不是只是看起来更复杂。

十二、一个实用架构模板

单 Agent 模板

适合大多数任务：

User Request
  ↓
Agent
  ├── read/search/tool
  ├── reason
  └── structured output

多 Agent 模板

适合复杂任务：

User Request
  ↓
Supervisor
  ├── Research Agent
  ├── Implementation Agent
  └── Review Agent
  ↓
Final Answer

审查型模板

适合高风险任务：

Main Agent 生成方案
  ↓
Reviewer Agent 独立审查
  ↓
Main Agent 修正
  ↓
确定输出

这个模板比“很多 Agent 一起聊天”更实用。

十三、常见错误

错误 1：一开始就多 Agent

问题：

• 成本高
• 难调试
• 难评估
• 容易互相放大错误

正确做法：

先单 Agent，评估后再扩展。

错误 2：没有固定输出格式

问题：

• 每次输出都不一样
• 无法做自动评估
• 后续系统难以消费

正确做法：

给 Agent 明确 schema 或模板。

错误 3：工具给太多

问题：

• Agent 容易误用工具
• 权限风险变高
• 行为不可控

正确做法：

每个 Agent 只给完成任务所需的最少工具。

错误 4：没有 evals

问题：

• 不知道系统是否变好
• prompt 改动不可验证
• 模型替换靠感觉

正确做法：

先建立测试集和评分标准，再谈扩展。

错误 5：高风险任务没有人工复核

问题：

• Agent 可能幻觉
• 工具可能误操作
• 错误后果不可接受

正确做法：

涉及财务、法律、生产系统、数据删除、部署等场景，必须有人类确认。

十四、生产落地建议

如果要把 Agent 用到真实业务里，建议遵守这些原则：

1. 默认单 Agent
   • 除非有明确证据需要多 Agent。
2. 所有任务都要有验收标准
   • 没有标准就无法判断 Agent 是否成功。
3. 工具权限最小化
   • 不需要写文件就不给写权限。
   • 不需要 shell 就不给 shell。
4. 保留执行轨迹
   • 记录工具调用、输入、输出、错误。
5. 先离线评估，再上线
   • 不要直接把新 Agent 接入生产流量。
6. 高风险任务必须人工确认
   • 尤其是数据库、K8s、财务、通知、删除、部署。
7. 持续回归测试
   • 每次改 prompt、模型、工具，都重新跑 evals。

十五、简化版决策清单

构建 Agent 前，先问这 10 个问题：

1. 这个任务真的需要 Agent 吗？
2. 单次 LLM 调用能不能解决？
3. 是否需要工具？
4. 是否需要记忆？
5. 输入输出是否清晰？
6. 成功标准是什么？
7. 有没有测试样本？
8. 单 Agent 表现如何？
9. 任务是否天然可并行？
10. 多 Agent 的收益能否被 evals 验证？

如果第 8 步单 Agent 已经表现不错，就不要急着扩展。

结论

构建可用 AI Agent 的关键不是“堆更多 Agent”，而是：

• 任务定义清楚
• 单 Agent 先跑通
• 工具权限最小化
• 输出格式稳定
• 有真实 evals
• 只有在任务可并行时才引入多 Agent
• 高风险场景保留人工监督

一句话：

好的 Agent 系统不是 Agent 多，而是边界清楚、评估扎实、工具克制、结果可验证。