P1：AI Agent 场景识别
Easy Data x AI 课程 · “道篇” · 第一期
从这节课开始，“道篇”和“术篇”分开。“道篇”的每一节课回答一个你在实际工作中会遇到的真实问题——不是教技术细节，而是帮你建立判断力。
我们想通过这期课程，帮助 AI 爱好者建立“这个想法 / 需求是否适合通过 Agent 来做”的判断能力。比“怎么做 Agent”更重要的是“值不值得做”。
本期课程视频
开场：我走过的弯路
这是一个真实的故事。
也欢迎大家来 OceanBase 社区论坛，发帖调戏故事的主人公——“论坛小助手”~
我最早把 AI 应用到工作里的记录，是曾经在社区论坛里做过一个“论坛小助手”，用户在发贴时会默认 @ 这个小助手来回答问题。但上线后社区用户频繁抱怨“答非所问”。当时我以为是模型不行，要升级，于是就换到当时市面上最强的模型 GPT-4o。上线后，用户满意度几乎没有提升。
接下来，我们花了很多时间去翻用户反馈，然后发现，绝大多数的“答错”其实不是模型理解错了，而是我们的知识库里根本没有对应的内容。产品和组件的版本频繁更新，但知识库里的内容还停留在几个月前；内部 SOP（标准操作程序） 散落在无数个语雀文档里，也完全没有及时整理进系统。
于是我把“论坛小助手”背后依赖的数据彻底整理了一遍：补全缺失的文档、修正过时的内容、统一了格式和标签。并设置了官方文档的修改，会第一时间同步到 github 仓库，作为小助手的知识库。
然后，我就可以非常放心地把论坛上的用户问题，全权交给小助手去处理了。这也是为什么我能忙里偷闲做这期课程，和大家分享我曾经犯下的错误。
我犯了什么错？不是技术选型错误，而是问题诊断错误。AI 做的不好，根本原因不在模型层——模型的理解能力已经足够了。问题在数据层：AI 需要查找的知识内容，要么不存在，要么过时了，要么格式混乱导致检索不到。
但这还不是故事的全部。
让我们再往前推一步：如果回到“论坛小助手”立项那天，如果有人能站出来问一句——“它要回答的这些问题，答案数据准备好了吗？”那后面被社区用户大面积吐槽的事情，可能根本就不会发生。
先判断问题在哪一层，再决定在哪一层投入资源。 这是贯穿整个“道篇”路径的核心思维方式。
而在所有判断中，最前置、最关键的一个判断是——这个需求，到底适不适合用 Agent 来做？
这就是今天这节课要解决的问题。
上面提到的“论坛小助手”是一个 ChatBot，不支持调用外部工具/API 去完成复杂任务，“行动”能力是大大受限的，只能称为广义上的 AI Agent。
第一部分：唱唱反调——哪些场景根本不需要 Agent？
过度工程化是 AI 产品最常见的早期错误。
很多需求看起来“很 AI”，团队讨论的时候也很兴奋——“这个用 Agent 来做一定很酷”——但冷静一想，用更简单的方案就能解决，而且解决得更好。
以下是几类常见的“看起来适合 Agent，其实不需要”的场景。如果你做过一两年 AI 相关的产品，大概率会在其中看到自己熟悉的影子。
固定答案的 FAQ
“我们的退款政策是什么？”“办公室 Wi-Fi 密码是多少？”“报销流程是什么？”
这类问题有一个共同特征：答案是固定的、明确的、不需要推理的。一个静态页面、一个搜索框加上几十条结构化的 FAQ，就能完美解决。
为什么不需要 Agent？因为 Agent 的价值在于理解模糊意图和组合推理。当意图完全不模糊（用户就是想知道退款政策）、答案完全不需要组合（退款政策就是那一段话）的时候，用 Agent 来做这件事，不是大材小用，而是引入了不必要的复杂度和出错的可能性。一个 FAQ 页面永远不会给出幻觉答案，但 Agent 可能会。
结构化数据查询
“上个月我们的 GMV（总成交额）是多少？”“北京区域本季度的签约客户数量？”“最近 7 天的日活趋势？”
这类需求的本质是从结构化数据中提取特定指标。它不需要语义理解（问题完全精确），不需要多步推理（一条 SQL 就能搞定），也不需要持续交互（答案就是一个数字或一张图表）。
一个设计良好的数据看板、一个有筛选和下钻功能的 BI 工具，是解决这类需求的最佳方案。用 Agent 来查数据库、生成 SQL、返回结果——听起来炫酷，但引入了多个出错环节（SQL 生成错误、数据理解偏差），而且用户体验还不如直接看图表直观。
当然，如果用户的查询是模糊的（“帮我看看最近业务哪里不太对劲”），那就回到了 Agent 的甜区。关键在于：查询的意图是精确的还是模糊的？
对准确性零容忍的计算
“帮我算一下这张发票的含税金额。”“这笔贷款的月还款额是多少？”
大模型不是计算器。F1 讲过，它的本质是预测下一个最可能出现的 Token，不是执行数学运算。虽然通过 Tool Use，Agent 可以调用计算器工具来完成精确计算，但如果你的场景只是精确计算，直接用计算公式或程序实现是更可靠、更高效的方案。
用 Agent 来做加减乘除，就像雇一个大学教授来帮你查字典——能做，但为什么？
总结一下
过度工程化的代价不只是浪费开发资源。
一个不需要 Agent 却被硬塞了 Agent 的功能，往往比原来的方案更慢、更贵、更难维护，而且因为引入了大模型的不确定性，可能比原来更容易出错。
第二部分：三维度可行性评估
很多 AI 项目的失败不是因为选错了场景，而是因为在立项阶段忽略了一些基本的可行性条件。
根据上节课程中的分析，AI Agent 的能力上限 = 数据质量 x 模型能力 + 流程编排。
因此，我们也可以把是否适合用 AI Agent 的判断条件，对应这个公式中的三个因子，归纳为三个维度：数据可得性、任务可定义性、流程编排的选择。
维度一：Agent 要用的数据存在吗？（数据可得性）
这是三个维度中最重要、最容易被低估、也最容易在立项阶段就验证的。
Agent 不是凭空变出答案的。它要么从知识库里检索信息，要么调用外部工具获取数据，要么基于对话历史进行推理。无论哪种方式，背后都有一个前提：它需要的数据得存在。
回到开场的案例——论坛小助手回答不好问题，不是因为模型不够聪明，而是因为知识库里缺了一半的内容。再好的厨师，冰箱里没有食材，也做不出菜来。
数据可得性要问的问题很具体：
- 内容覆盖：Agent 需要回答的问题，答案数据存在吗？是在数据库里、文档里，还是只在某个老员工的脑袋里？
- 数据质量：数据存在，但准确吗？是不是几个月前的版本？
- 可接入性：数据存在且准确，但 Agent 能拿到吗？是不是锁在某个没有 API 的系统里？是不是需要特殊权限才能访问？
很多 PM（产品经理）在立项时会花大量时间讨论模型选型、交互设计、用户体验——这些当然重要，但如果数据层的问题没解决，这些讨论都是空中楼阁。
一个简单的验证方法： 在立项会上，随机列出 10 个你期望 Agent 能回答的典型问题，然后让团队去找——这些问题的答案数据在哪？能找到几个？找到的内容准确吗？如果 10 个问题里有 6 个找不到答案数据，那这个项目最该做的不是上 Agent，而是先把数据准备好（血的教训）。
维度二：怎么算做对了？（任务可定义性）
Agent 做了一件事，你怎么知道它做对了？
这个问题在传统软件里很简单：输入确定、输出确定，测试用例写清楚，跑一遍就知道对错。
实际上很多和 AI 相关的需求，在立项时根本说不清楚“成功标准”。因为 LLM 让这个问题变复杂了——它是概率生成的，不是确定执行的。
LLM 带来的新挑战
想象你让 Agent 做一件事：“根据用户的订单号，查询物流状态并返回。”
传统软件：输入订单号，输出物流状态。对或错，一目了然。
LLM + Agent：同样的输入，它可能返回三种不同的表述方式：
- “您的订单正在运输中，预计明天送达。”
- “包裹已在路上，明天到。”
- “物流状态：运输中，预计送达时间：2026-03-28。”
这三个回答，哪个算对？哪个算错？还是都算对？
这就是 LLM 引入的新问题：输出不是确定的，是概率分布的采样结果。 你没法用传统软件的“预期输出 vs 实际输出”来做测试。
更进一步，LLM 还有幻觉倾向。它可能返回一个听起来完全合理、但事实错误的答案：
“您的订单已签收，签收人是前台。”（但实际物流显示还在运输中）
这不是 Agent 故意撒谎——是模型在“补全”它不确定的信息。F1 讲过，大模型的本质是预测下一个最可能出现的 Token，不是检索事实。
所以，任务可定义性在 LLM 时代需要回答两个问题：
- 输出形式的边界在哪？ —— 同样的事实，可以用多少种方式表述？哪些表述是可接受的，哪些算错？
- 事实正确性怎么验证？ —— 当模型可能幻觉时，你的验证机制是什么？
两类任务的对比
容易定义的任务：
- “根据用户的订单号，查询物流状态并返回。”——成功标准清晰：返回的状态必须和物流系统一致。事实可验证，表述可以有弹性。
- “从这 100 条用户反馈中，提取所有提到‘价格’的负面评价。”——召回率和准确率都可以量化。
难定义的任务：
- “帮用户写一个有创意的营销文案。”——什么叫“有创意”？谁来评判？不同的人可能有完全不同的标准。
- “分析一下我们产品的竞争优势。”——答案没有标准解，不同分析师可能给出完全不同的结论。
注意一个关键区别：前一类任务有“事实锚点”（物流系统、用户反馈原文），后一类任务没有。 有事实锚点的任务，可以用事实正确性作为底线标准；没有事实锚点的任务，你需要建立主观评估机制（如多人打分、A/B 测试）。
论坛小助手的成功标准很简单：用户在它的回复下面点击了“问题已解决”按钮。
这就是一个有事实锚点的任务——让用户用脚投票。
任务可定义性决定了你能不能衡量成功
任务可定义性越高，Agent 的效果越容易度量和改进；可定义性越低，你越难判断“到底是 AI 不行，还是需求本身就模糊”。
这不是说不可定义的任务就不能做——而是你需要在立项时就想清楚：评估标准是什么？谁来评估？以什么频率评估？ 如果你无法回答这三个问题，这个 Agent 功能上线之后，你很可能陷入“用户说不好用，但你不知道哪里不好用”的困境。
一个实用建议：对于难定义的任务，先用小样本人工评估建立基线。比如让团队人工写 10 个营销文案，作为“合格线”的参考标准。然后让 Agent 生成 10 个，盲测对比。这比空泛讨论“有没有创意”更有意义。
我们会在道篇的最后一课中，对评估评测（evaluation）做进一步的展开。这个是智能体工程（agent engineering）里面最重要的一环，对于生产落地极为关键。
维度三：完全自主的 Agent，还是设计好流程的 Workflow？（流程编排的选择）
这是三个维度中最容易被忽略，但最能体现 PM 架构判断力的一个。
很多人一提到 AI，想到的就是“完全自主的 Agent”——用户说一句话，AI 自己理解、自己规划、自己调用工具、自己完成任务。
但现实中，大多数成功的 AI 应用都不是完全自主的 Agent，而是“人机协作”的工作流（Workflow）。
Agent vs Workflow：本质区别是什么？
Agent（自主代理）：
- 用户给一个模糊目标（“帮我分析一下竞品情况”）
- AI 自己决定怎么做：查什么资料、用什么工具、按什么顺序、输出什么格式
- AI 掌握控制权，人可以中途干预，但不必须
Workflow（工作流）：
- 人设计好流程：第一步做什么、第二步做什么、每步的输入输出是什么
- AI 负责执行流程中的一个或多个环节（通常是语义理解、内容生成这类需要智能的环节）
- 人掌握控制权，AI 是流程中的一个“智能组件”
举个例子：处理用户售后请求。
Agent 方案：用户说“我要退货”，AI 自己判断是否符合退货政策、查询订单状态、生成退货码、通知仓库——全流程自主完成。
Workflow 方案：人设计好流程——① 验证用户身份 → ② 查询订单信息 → ③ 判断是否符合退货政策 → ④ 生成退货码。其中第③步交给 AI（因为需要语义理解用户的退货原因），其他步骤用传统代码实现。
怎么判断该用 Agent 还是 Workflow？
问自己三个问题：
1. 数据可得性如何？
这是一个和维度一呼应的判断。
Agent 需要自己能检索到完成任务所需的全部数据。如果数据分散在多个系统、权限复杂、或者根本不存在，那 Agent 做不了。
Workflow 可以把数据需求拆解到每个步骤——某些步骤用传统 API 获取结构化数据，只有需要语义理解的步骤才让 AI 介入。这对数据层的要求更低。
2. 任务的确定性高吗？
如果任务的大部分步骤是确定的、可预测的——比如“处理退货”永远是那几步——那 Workflow 更合适。确定性越高，越不需要把控制权交给 AI。
如果任务每一步都可能需要根据上下文做判断——比如“帮我处理一个复杂的客户投诉”，可能需要查订单、查政策、查历史沟通记录、判断用户情绪、决定补偿方案——那 Agent 更合适。
3. 错误的代价是什么？
Workflow 的优势是可控——每一步的输入输出都是设计好的，出了错容易定位。
Agent 的优势是灵活——它能处理设计时没想到的情况，但也可能做出设计时没想到的错事。
如果错误代价高（比如涉及资金、法律、医疗），优先选 Workflow——把 AI 放在风险可控的环节，比如“辅助人工判断”而不是“替代人工决策”。
论坛小助手其实是一个 Workflow：用户提问 → AI 检索知识库 → 生成回答 → 用户点击“已解决”。
它不是完全自主的 Agent，因为它不会主动调用外部 API、不会规划多步任务。但这不妨碍它成为一个有价值的产品。
一个实用的光谱模型
不要把 Agent 和 Workflow 看成二元选择——它们是一个光谱：
完全自主 Agent（AI 控制） ←→ 人机协作 Workflow （混合控制） ←→ 传统软件 （人控制）
大多数成功的 AI 产品，都落在这个光谱的中间地带：
- Copilot 模式：人主导，AI 辅助（如 GitHub Copilot——人写代码，AI 补全）
- Human-in-the-loop：AI 执行，人审核（如客服助手——AI 生成回复，人确认后发送）
- 混合模式：简单情况 AI 自主，复杂情况升级人工（如退款助手——小额自动批，大额转人工）
如果你的团队是第一次做 AI 项目，优先选 Workflow，不要选 Agent。
原因很简单：
- Workflow 对数据层的要求更低（维度一）
- Workflow 更容易定义成功标准（维度二）
- Workflow 的错误更容易控制和定位（维度三）
先把 Workflow 跑通，验证 AI 在这个场景中的价值，再逐步增加自主性。“先 Workflow，再 Agent” 是更稳妥的路径。
三个维度的关系
这三个维度不是独立的打分项，它们有内在的关联。
数据可得性是地基。 如果数据不存在，任务定义得再清楚、流程设计得再稳妥，AI 也做不出有价值的事。这是为什么我们把它排在第一位。
任务可定义性决定了你能不能衡量成功。 没有清晰的成功标准，你无法判断项目是否值得继续投入。尤其是 LLM 的概率生成特性，让“怎么算做对”这个问题比传统软件更复杂。
流程编排选择决定了你的可控性。 完全自主的 Agent 上限更高，但 Workflow 更可控、更容易落地。第一个 AI 项目，优先选 Workflow 验证价值，再逐步增加自主性。
一个理想的第一个 AI 项目，应该是：数据可得性高、任务可定义性高、流程可控性高。换句话说——数据已经有了、成功标准清楚、出了错也能控制。在这样的场景中快速验证 AI 的价值，积累经验，然后再逐步挑战更复杂的场景。
第三部分：实用工具 —— Agent 场景评估 Checklist
以下是一份结构化的评估表，可以直接用于产品评审。当团队讨论“要不要做一个 Agent 功能”时，拿这份 Checklist 逐项过一遍，能帮你在 10 分钟内形成一个初步判断。
一、场景匹配度
| 检查项 | 是 | 否 |
|---|---|---|
| 用户意图是否可能模糊或多样化？（不同用户问同一件事的方式差异大） | ☑ | ☐ |
| 回答是否需要从多个数据来源组合信息？（答案不在单一文档中） | ☑ | ☐ |
| 任务是否涉及多轮交互？（需要理解上下文才能给出好的回答） | ☑ | ☐ |
| 这个任务能否用 if-else 逻辑完整描述？（如果能，Agent 可能是过度设计） | ☐ | ☑ |
判断标准：前三项至少命中一个“是”，且第四项为“否”，场景才值得考虑用 Agent。
二、数据可得性（最关键的维度）
| 检查项 | 状态 |
|---|---|
| Agent 需要回答的典型问题，答案数据是否存在？ | 存在 / 部分存在 / 不存在 |
| 数据是最新的吗？最近一次更新是什么时候？ | 最新 / 有些过时 / 严重过时 |
| 数据格式是否可被系统处理？（结构化文档 vs 扫描件 vs 口头知识） | 可处理 / 需转换 / 不可处理 |
| Agent 是否有技术途径获取这些数据？（有 API / 有数据库 / 需手动导入） | 可接入 / 需开发 / 无法接入 |
| 用 10 个典型问题测试，能找到多少个问题的答案数据？ | __/10 |
判断标准：如果“10 个问题测试”中超过一半找不到答案数据，当前阶段不应该启动 Agent 开发——应该先投入数据建设。
三、任务可定义性
| 检查项 | 状态 |
|---|---|
| 能否用一句话描述 Agent 在这个场景中“做对了”的标准？ | 能 / 模糊 / 不能 |
| 是否有现成的评估数据？（如历史问答对、用户反馈记录） | 有 / 少量 / 没有 |
| 评估标准是客观的（事实正确性）还是主观的（用户感受）？ | 客观 / 混合 / 主观 |
判断标准：如果成功标准完全说不清楚，建议先做小范围用户调研明确需求后再立项。
四、流程编排选择
| 检查项 | 状态 |
|---|---|
| 任务的大部分步骤是确定的、可预测的吗？ | 是 / 部分 / 否 |
| 如果 AI 做出设计时没想到的决策，后果是什么？ | 可接受 / 需审核 / 不可接受 |
| 是否需要调用多个系统的数据/API？ | 是（Workflow 更合适）/ 否 |
| 首选方案是 Agent 还是 Workflow？为什么？ | Agent / Workflow / 混合 |
判断标准：如果任务确定性高、错误代价高、数据源分散，强烈建议从 Workflow 起步，而不是直接做完全自主的 Agent。
综合建议
| 评估结果 | 建议 |
|---|---|
| 场景匹配 ✓，数据充足 ✓，任务可定义 ✓，适合 Workflow ✓ | 立即启动——这是理想的 AI 项目 |
| 场景匹配 ✓，但数据不足 | 先建数据，再做 AI——在数据建设完成之前，AI 的体验不会好 |
| 场景匹配 ✓，但任务不可定义 | 先做用户调研——没有清晰的成功标准，项目容易陷入“改到天荒地老”的泥潭 |
| 场景匹配 ✓，但应该用 Workflow 却选了 Agent | 重新设计流程——把控制权收回来，让 AI 只做它擅长的事 |
| 场景不匹配 | 用更简单的方案——FAQ 页面、数据看板、自动化脚本，可能是更好的选择 |
第四部分：什么问题适合交给 Agent？
在展开“适合做 Agent”的判断之前，我们先明确一个定义。F2 讲过，Agent 的本质是一个具有“感知 → 推理 → 行动”循环能力的系统——它能理解模糊的意图，能自主决定下一步做什么，能调用外部工具和数据来完成任务。
理解了这个定义，Agent 的“甜区”就比较清晰了。有三类场景，是 Agent 最能发挥价值的地方。
场景一：语义理解——用户说不清楚他要什么
传统软件要求用户精确表达需求：选哪个菜单、填哪些字段、用什么关键词搜索。但现实中，用户经常说不清楚自己要什么。
想象一个企业内部的 HR 助手。员工问：“我下个月要去美国出差，需要办什么手续？”
这个问题看起来简单，但其实很模糊——“手续”是指签证？还是差旅审批？还是费用报销流程？答案取决于这个员工的国籍、职级、出差目的、公司的差旅政策版本……
Agent 能做的是：理解“去美国出差”这个模糊意图，主动判断需要回答哪几个方面，然后从不同的知识来源中组合出一个完整的回答。它不是在执行一条预设的流程，而是在理解语义之后自主决定应该怎么做。
这就是 Agent 的第一个甜区：用户意图模糊，需要 AI 来理解和拆解。
场景二：外部工具调用——Agent 能“做事”的关键
有些任务不是靠“想”就能完成的——Agent 需要自动调用外部工具和 API 才能真正解决问题。
这就是 Agent 和聊天机器人的本质区别：聊天机器人只需要能“说话”，Agent 还需要能调用工具“做事”。
场景三：持续交互——需要记住上下文
很多任务不是一轮对话就能完成的。用户可能需要和 AI 反复沟通、逐步澄清需求、基于前面的结论继续推进。
持续交互的价值不只是“不用重复说”这么简单。更深的价值在于：AI Agent 可以通过多轮交互逐步深入理解用户的真实需求，给出越来越精准的回答。
总结一下：Agent 的三个甜区是——用户意图模糊需要语义理解、需要调用外部工具/API、任务复杂需要持续交互。 如果你的需求场景同时命中两个甚至三个甜区，那它大概率是一个值得用 Agent 来解决的问题。
但“适合做 Agent”只是判断的第一步。一个需求即使命中了甜区，也不意味着它马上可以启动——你还需要评估它的可行性。
我们的思考
我们接触过大量 AI 应用项目——有的是自己做的，有的是客户的，有的是行业里观察到的。有一个现象反复出现：
90% 的 Agent 功能失败，不是因为模型不够好，而是因为立项的时候没人问一句：“数据在哪？”
这不是夸张。你去翻一下那些上线后被下掉的 AI 功能，绝大多数不是模型选错了、不是 Prompt 写差了、也不是交互设计不好——而是 Agent 根本拿不到它需要的数据。知识库是空的，或者是半年前的版本；用户数据没有打通，Agent 不知道这个用户是谁；业务规则散落在各个系统里，从来没有人整理成 Agent 可以检索的格式。
团队在立项会上讨论了两小时的模型选型、Prompt 策略、交互设计，却没有花五分钟问一句：“Agent 要用的数据准备好了吗？”
这件事为什么重要？因为数据可得性是立项阶段最容易验证的维度——你不需要写一行代码，不需要调一次 API，只需要列出 10 个典型问题，然后去找答案数据在哪里。这个验证可能只需要半天时间，却能帮你避免几个月的弯路。
这节课要留下的印象
如果这节课的所有内容你只记住一句话，记住这句：
90% 的 AI 功能失败不是模型不行，而是立项时没人问“数据在哪”。评估一个 AI 功能，数据可得性永远排在第一位。
延伸阅读：数据隐私与信任 —— 本地 Agent 的兴起
在讨论完“要不要做 Agent”之后，还有一个产品决策值得提前关注：Agent 应该运行在哪里？
传统方案是云端 SaaS——用户通过网页或 App 使用你的 AI 服务。但 2025 年底开始，一个新的趋势正在出现：本地 Agent。
代表项目是 OpenClaw——一个开源的自主 AI Agent，完全在用户本地设备上运行，数据不出本地，可以 7×24 小时自主执行任务。
从产品决策角度看，本地 Agent 解决了一个核心问题：数据隐私与信任。
想象一个场景：你要做一个企业内部的财务助手，它能查员工的报销记录、差旅预算、合同信息。如果这个 Agent 运行在公有云上，你需要把敏感的财务数据传给第三方——很多老大在这一步就会把你给叫停。
但如果 Agent 运行在员工自己的电脑上（就像 OpenClaw 那样），数据不需要离开公司网络——Agent 只是“借”一个推理核心，数据本身不出本地。这对某些高敏感场景是决定性的产品决策。
当然，本地 Agent 也有代价：运维复杂度上升（你要支持不同操作系统）、用户设备性能差异、无法集中更新模型。不过在某些场景中，“数据不出本地”这个优势足以抵消所有代价。
这和 P1 的核心判断是一致的：Agent 能做什么，取决于它能拿到什么数据。如果数据因为隐私顾虑根本不敢给 Agent 用，那 Agent 的能力再强也没用。OpenClaw 这类本地 Agent 框架的价值，就是帮你在某些高敏感场景中先拿到数据接入的许可。
产品决策点：当你的目标用户对数据隐私极度敏感（金融、医疗、法律、企业内部），本地 Agent 可能不是一个技术选型问题，而是一个市场准入问题。
课后行动
从你当前产品的 backlog 中，找一个 AI 相关的需求（或者一个团队正在讨论的 Agent 功能），用本节课的 Checklist 做一次评估。
重点关注数据可得性维度：
- 列出 10 个你期望 Agent 能回答的典型问题
- 逐一检查：这些问题的答案数据在哪？存在吗？准确吗？Agent 能拿到吗？
- 统计结果：10 个问题中，几个的答案数据是“立即可用”的？
把你的评估结论写下来，跟你的团队分享，一起讨论一个问题：我们当前最该投资的是模型层还是数据层？
下期预告
“术篇”： D1 · 大模型 API 工程化基础——建立从 “用 ChatGPT” 到 “用 API 构建 AI 应用” 的认知跨越。
Tool Use 把大模型从 “只能说” 变成了 “能做事”，这是聊天机器人和 Agent 的分界线。在这节课程中，我们会附上 6 个循序渐进且可以直接跑通的 Python 代码段，带大家快速体验你的第一个 Agent。
“道篇”：P2 · Agentic RAG 产品设计——帮助大家理解 “AI 回答问题” 背后发生了什么，以及产品设计的哪些决策会直接影响用户体验。
在这节课程中，我们会为大家奉上一个 RAG 问题归因决策树，并引入三层归因框架，帮你精准定位问题出在哪一层。
课后习题
通过课后小测，即可获取 OceanBase 社区积分，换取社区定制礼品~