不需要写代码!这节课手把手带你从零搭建一个能用的 AI Agent。30 秒部署,配置提示词和工具,立刻体验 Agent 的威力。
课程概述
前面两门课讲了"Agent 是什么"和"工具调用怎么运作"。现在到动手环节——用零代码平台搭建你的第一个 AI Agent。
不需要写一行代码。你会经历完整的流程:明确需求 → 设计 Agent 的人设和能力 → 配置工具 → 测试迭代 → 投入使用。学完这门课,你就能拥有一个为你工作的 AI Agent。
学习目标
- 掌握搭建 AI Agent 的完整流程(5 步法)
- 学会用零代码/低代码平台快速搭建 Agent
- 理解"系统提示词"在 Agent 中的关键作用
- 能独立完成 Agent 的测试和优化迭代
- 避免新手最常犯的 5 个错误
课程内容
1. 动手之前——先想清楚三个问题
在打开任何工具之前,先回答这三个问题。它们决定了你的 Agent 是"真的有用"还是"搭完吃灰"。
问题 1:这个 Agent 帮谁,做什么?
不要"做一个帮我工作的 Agent"——太模糊了。好的定义是:
✓ "这个 Agent 每天早上 9 点自动拉取我们 3 个核心业务指标(销售额、用户活跃数、客诉量),如果任何一个指标低于正常范围,自动发微信通知我,并把相关数据整理成一句话总结。"
✗ "做一个数据助手"
问题 2:这个任务现在谁在做?花了多少时间?
如果你不能明确回答这个问题,说明这个 Agent 的需求还没想清楚。最好的 Agent 候选任务是那些:
- 你在做的时候心里想"这事真该交给机器"
- 频率高(每天、每周做)
- 规则明确(不需要每次做判断)
问题 3:Agent 需要什么"手"和"眼"?
"手" = Agent 能做什么动作(发消息、写表格、调 API) "眼" = Agent 能看到什么信息(数据库、文件、日历)
如果答案是"不需要什么手和眼,纯靠 LLM 就行"——那你可能不需要 Agent,聊天 AI 就够了。
2. 搭建 Agent 的五步法
Step 1:写系统提示词(System Prompt)——Agent 的"人设和操作手册"
系统提示词是 Agent 最重要的配置。它不是用户每次输入的内容,而是"写在 Agent 骨子里"的指令。
系统提示词包含四个部分:
## 角色定义
你是一名 [职位描述]。你的工作风格是 [风格描述]。
## 任务职责
你的核心任务是 [具体描述]。
你不需要做的事情包括 [排除项]。
## 可用工具
你可以使用以下工具:
- [工具1名称]:[功能描述],使用时机:[什么时候用]
- [工具2名称]:[功能描述],使用时机:[什么时候用]
## 行为规范
- [规则1,如:在发送任何对外消息前,先草拟内容并等待确认]
- [规则2,如:如果遇到无法处理的情况,不要编造,直接说"这超出了我的能力范围"]
- [规则3,如:保持回复简洁,单次不超过200字]
系统提示词的质量直接决定了 Agent 的质量。 花 40% 的时间在写好系统提示词上。
Step 2:配置工具——给 Agent "接上手"
在零代码平台上,工具通常以"插件"或"集成"的形式存在:
| 常用工具 | 零代码实现方式 |
|---|---|
| 读取/写入表格 | 连接 Google Sheets 或飞书多维表格 |
| 发送消息 | 连接企业微信/钉钉/飞书/邮件 |
| 搜索信息 | 开启联网搜索或连接知识库 |
| 查询数据库 | 连接数据库(需配置连接信息) |
| 调用 API | HTTP 请求工具(填 URL、参数) |
新手建议:第一个 Agent 只配置 1-2 个工具。 工具越多,出错的组合也越多。
Step 3:准备知识库(可选)——给 Agent "喂资料"
如果你的 Agent 需要基于特定知识回答问题——比如公司产品文档、FAQ、运营手册——你需要一个知识库。
- 把相关的文档(PDF、Word、网页)上传到平台
- Agent 收到问题时,会先在知识库中搜索相关内容,再基于搜索到的内容回答
这其实就是前面讲过的 RAG(检索增强生成)——避免 Agent 在不知道答案时"胡编"。
Step 4:测试——让 Agent"先跑 10 圈"
不要上线就让 Agent 面对真实用户。先自己测试:
测试清单:
- 正常流程:最常见的 3 个场景,Agent 能顺利完成吗?
- 边界情况:信息不全(比如用户没写日期)、输入格式异常(比如用户打错字)
- 错误处理:工具调用失败时,Agent 是卡住了还是能优雅降级?
- 拒绝场景:用户让 Agent 做不该做的事(比如发敏感数据),Agent 会拒绝吗?
- 响应质量:Agent 的回复是不是太啰嗦?太冰冷?太不确定?
每轮测试问自己:Agent 哪里做得不对?为什么?是系统提示词的问题还是工具的问题?
Step 5:上线 + 监控——Agent 不是"设好就忘"
上线不等于结束。至少在前两周,每天花 5 分钟看看 Agent 的"工作记录":
- 有没有调用失败的记录?是什么原因?
- 用户有没有追问/纠正 Agent?(这说明一步到位率低)
- 有没有人绕过 Agent 直接来找你?(说明 Agent 没满足需求)
把 Agent 当成一个新入职的实习生——前两周你要多盯着,后面慢慢放手。
3. 三个简单但实用的 Agent 案例
案例 1:每日数据摘要 Agent
# 系统提示词
你是一名数据助理。每天早上8点,自动拉取以下指标并发送到我微信:
- 昨日销售额
- 昨日活跃用户数
- 昨日新增客诉数
如果任一指标偏离正常范围(销售额低于X,活跃低于Y,客诉高于Z),用 🔴 标注并附一句简要分析。
# 需要的工具
- 数据库查询(只读权限)
- 企业微信/钉钉消息推送
# 关键配置
- 定时触发:每天早上8:00
- 正常范围配置(可以用一个表格来维护,Agent 读取此表格)
案例 2:客户询问分类 + 草拟回复 Agent
# 系统提示词
你是一名客服助手。你的任务是:
1. 阅读客户发来的消息
2. 判断问题类型:产品咨询/技术问题/投诉/合作意向
3. 在知识库中搜索相关信息
4. 草拟回复内容(但不要发送!先给我审批)
5. 标注紧急程度:普通/重要/紧急(判断标准:投诉 + 提到退款/法律 = 紧急)
# 约束
- 绝对不要直接回复客户,只草拟内容等待我确认
- 不确定的情况标注"建议人工处理"
案例 3:会议准备 Agent
# 系统提示词
你是一名会议准备助手。当你收到一个会议主题时:
1. 搜索公司内部知识库中与该主题相关的文档和过往会议纪要
2. 如果主题涉及外部公司,搜索最新行业新闻
3. 生成一份"会前准备包":
- 背景:关于此主题的已知信息(1-2段)
- 关键数据:相关的数字和指标
- 上次讨论的待办事项(如有)
- 建议的议程要点(3-5个)
- 准备的问题(至少3个)
4. 新手常犯的 5 个错误——以及如何避免
错误 1:系统提示词太模糊
"你是一个助手,帮助用户解决问题"——这样的系统提示词等于没说。
修正: 写清楚它是谁、做什么、怎么做、有什么工具、什么是红线。参见 Step 1 的四部分格式。
错误 2:一次给 Agent 太多工具
配置了 15 个工具,觉得"万一用得上呢"。结果 Agent 经常选错工具,或者调用了一大堆没必要的工具。
修正: 从 1-2 个工具开始。确认这个组合靠谱后,再逐个添加。
错误 3:没有设置"安全护栏"
Agent 可以发邮件、改数据、调价格——而且没人审核。
修正: 所有"对外"和"修改"的操作都加确认步骤,至少上线初期如此。等运行稳定 2 周后再考虑半自动化。
错误 4:一次测试就上线
"我试了一次,走通了,上线吧"——一次走通不代表稳定。
修正: 至少测试 10 个不同场景,包括错误场景(工具挂了、用户输入不合理)。Agent 在"不正常"情况下的表现更体现质量。
错误 5:没有后续优化的机制
Agent 上线后就不再管了,直到有人抱怨。
修正: 建立一个简单的反馈渠道——比如让用户可以对 Agent 的回答"点赞/踩",或者每周抽 5 条 Agent 的回答检查质量。Agent 不是一次性产品,是需要持续优化的"数字员工"。
5. 平台选择建议
| 平台类型 | 代表产品 | 适合 |
|---|---|---|
| 零代码 SaaS | 怡途Claw、扣子(Coze)、Dify | 非技术用户、快速验证想法 |
| 低代码框架 | LangChain、AutoGen | 开发者、需要高度定制的场景 |
| 全代码自建 | 基于 API 自研 | 大型企业、特殊安全需求 |
新手建议: 先用零代码平台搭 3 个 Agent 找感觉。不要一上来就学 LangChain——就像不要还没开过车就去学修车。
实操练习
-
需求设计(10 分钟): 按"三个问题"框架,定义你想搭建的第一个 Agent。写清楚:帮谁?做什么?现在花多少时间?需要什么工具?
-
写系统提示词(15 分钟): 为你定义的 Agent 写一份完整的系统提示词(四部分)。这是整个课程最重要的练习——系统提示词就是 Agent 的"灵魂"。
-
动手搭建(20 分钟): 用任何一个零代码平台(推荐怡途Claw或扣子),根据你写的系统提示词搭建一个真实可用的 Agent。至少测试 5 个场景。
总结
搭建 Agent 不难——难的是想清楚"到底要它做什么"。
记住五步法:定义角色 → 配置工具 → 准备知识 → 充分测试 → 上线监控。 花 80% 的时间在前两步(思考和设计),搭建本身很快。
你的第一个 Agent 可能不完美——没关系。Agent 是迭代出来的,不是设计出来的。先让它跑起来,再用实际反馈来打磨它。