发布时间：2026-08-29
标签：AI Agent｜工程实践｜Use Case Selection｜Agent Architecture
- 上一篇：AI Agent 工程实践（35）：我的 AI Engineering OS 最终架构
- 下一篇：AI Agent 工程实践（37）：需求分析——一个 Agent 项目到底应该怎么拆
上个月我朋友面试了一个岗位，他简历上写着"精通 Agent 开发"。
面试官问他：你最近做的那个 Agent，解决的是什么问题？
他说：我搭了一个客服 Agent，能查订单、能退换货、能回答物流。
面试官又问：那为什么不用三个 API + 一个 if-else？
他愣住了。
这就是我想先聊的事：在写任何 Agent 之前，你真正需要回答的不是"怎么做"，而是"到底该不该做"。
问题背景
这是「AI Agent 工程实践」系列的第五阶段，也是最后一段长路。
前面三十五篇，我们默认了一个前提——我们已经决定要做一个 Agent 了。然后去讨论 Rules 怎么分层、Memory 怎么设计、Planner 怎么跑、Observability 怎么看。这些都对，但它们都跳过了一个更早、也更致命的问题：
这个问题，真的值得用一个 Agent 来解决吗？
我见过太多这样的项目：花了三周搭出一个 Agent，能调十个工具、有完整的 Memory、还上了 LangGraph，最后发现它 90% 的工作，一个 200 行的 Flask 接口就能干完，而且更快、更稳、更便宜。
更糟的是，这种"用 Agent 解决不需要 Agent 的问题"的项目，往往不是效率问题，而是可靠性灾难：因为 Agent 会"自由发挥"，把本来确定的事情做成不确定的——该返回"订单未找到"的时候，它可能编一个"订单已发货"。
Agent 不是目的，它是手段。而在你把它当手段之前，你得先证明：这个手段是必要的。
这一篇，就是整个第五阶段的地基：先定义一个真实问题，并证明它值得用 Agent。地基打歪了，后面十五篇全是白搭。
错误尝试
第一次尝试：我的个人知识库问答助手
我的第一个 Agent 项目，就是典型的反面教材。
我想做一个"个人知识库问答助手"——喂给它一堆笔记，然后问什么答什么。听起来很 Agent 对吧？"它要理解我的问题、去检索、去组织答案"，多有自主性。
于是我上了全套：向量库、RAG、多轮对话、工具调用。
结果呢？绝大多数问题，其实就是"这篇笔记里写了什么"——一个关键词搜索 + 原文摘录就够了。我精心设计的"自主决策能力"，在 80% 的场景里完全用不上，反而因为它会"自由发挥"，时不时给我编造笔记里根本不存在的结论。
我当时的判断是"技术不够好"，于是继续加 Prompt、换模型、调检索。绕了一大圈才意识到，问题根本不在技术，在于——
我从一开始就选错了问题：一个确定性极高、几乎不需要自主决策的任务，硬被我套上了 Agent。
第二次尝试：以为"加上推理"就能救活它
吸取第一次教训后，我并没有立刻想通，而是走上了一条更隐蔽的弯路：给这个确定性的任务强行加"推理环节"。
我想："既然它是个问答任务，那让它先分析用户意图、再决定检索策略、最后组织答案——这不就有自主性了吗？"
于是我加了一个"意图理解"节点、一个"检索策略"节点、一个"答案组织"节点。结果呢？
- 多花了 3 倍的 Token
- 延迟从 0.8s 涨到 4s
- 准确率没有提升，因为原来那 80% 的问题根本不需要这些"推理"
- 反而因为中间环节变多，出错的概率变大了
这第二次失败教会我的东西比第一次更值钱：问题本身的确定性不会因为你在外面套更多 Agent 环节而改变。一个不需要 Agent 的任务，你把它包装得再像 Agent，它依然不需要——你只是在用复杂度掩盖判断错误。
第三个观察：什么才是"选对问题"
真正让我开窍的，是一个完全反面的对比。同样是"客服"场景：
- 问"订单状态"——确定，一步查库
- 问"帮我分析为什么昨天支付失败率暴涨"——不确定，要先看日志、再看监控、再关联部署记录、可能还要追到具体订单
前者是 API 的活，后者才是 Agent 的活。区别不在"问题是不是客服相关的"，而在问题的结构：步骤能不能提前写死、分支能不能提前枚举。
于是，我得到了那一句贯穿全文的判断标准。
关键观察
痛定思痛，我把"该不该用 Agent"这个判断，收敛成了两个维度：
- 不确定性：这个任务的每一步，是不是固定的、可预测的？
- 可枚举性：这个任务的所有步骤和分支，能不能提前写清楚？
把这两个维度一交叉，任务就分成了四个象限：
quadrantChart title 任务类型四象限：该用什么技术 x-axis 低不确定性 --> 高不确定性 y-axis 步骤不可枚举 --> 步骤可枚举 quadrant-1 需要 Agent quadrant-2 需要 Workflow quadrant-3 普通 CRUD / API quadrant-4 需要 RAG "查订单状态": [0.15, 0.85] "生成处理建议": [0.45, 0.65] "仓库故障诊断": [0.8, 0.35] "知识库问答": [0.55, 0.4]核心洞察一句话：
当一个任务能写清楚 SOP，它就不需要 Agent。
SOP（标准作业流程）能写出来，意味着步骤是确定的、分支是可枚举的，那它就是 Workflow 甚至 CRUD 的活。只有当你发现"我没法提前把步骤写死，只能让它在执行中自己判断下一步"，Agent 才真正登场。
注意"能写清楚 SOP"和"看起来复杂"不是一回事。一个 50 步的固定流程，哪怕很长，只要每步都确定，它就是 Workflow；一个 3 步的调查任务，哪怕很短，只要"第 2 步该查什么"要视第 1 步结果而定，它就是 Agent 的活。复杂度不决定要不要 Agent，确定性才决定。
最终方案：四象限判断法
落地成一个可操作的判断流程。拿到一个需求，先别急着开写，按顺序问自己四句：
def choose_tech(task): if task.steps_are_fixed and task.no_external_knowledge: return "CRUD / API" # 场景A：查订单状态 if task.steps_are_fixed and task.need_retrieval: return "RAG" # 场景D：知识库问答 if task.steps_enumerable and task.low_uncertainty: return "Workflow" # 场景B：生成处理建议 if task.high_uncertainty and task.steps_not_enumerable: return "Agent" # 场景C：自己判断查什么、调什么 return "Agent + Workflow 混合" # 大多数真实项目的答案用四个真实场景把这个判断说透（每个象限一个代表性案例）：
| 场景 | 用户需求 | 步骤能写死吗 | 结论 | 技术 |
|---|---|---|---|---|
| A | 查询订单状态 | 能，就一步：查库返回 | 确定性极高 | CRUD/API |
| B | 根据订单、库存、物流生成处理建议 | 能，三步：查→算→出报告 | 流程可枚举 | Workflow |
| C | 分析一次支付服务异常，自己判断查什么、发现异常继续查、最后给方案 | 不能，查日志还是监控、查到哪一步算完，事前不知道 | 需要动态决策 | Agent |
| D | 在知识库里找某篇笔记 | 能，检索→摘录，但需要外部知识 | 检索型 | RAG |
场景 C 为什么是 Agent？因为它的关键特征是过程不确定：用户只说"帮我分析昨天支付服务异常"，没说查哪些系统、按什么顺序、查到什么算结束。这些得让 Agent 在执行中自己判断。这才是自主性的真正用武之地。
为了强化这个判断，我把四种"真实项目里常见的错误选型"也列出来——它们都是"看起来该用 Agent，实际不用"的陷阱：
| 常见陷阱 | 你以为 | 实际 | 正确做法 |
|---|---|---|---|
| 报表生成 | 要理解需求，用 Agent | 流程固定，纯模板 | Workflow |
| 表单自动填写 | 要识别字段，用 Agent | 字段映射可枚举 | Workflow + 规则 |
| 文档问答 | 要理解语义，用 Agent | 检索即答案，不需要推理 | RAG |
| 定时抓取 | 要处理异常，用 Agent | 固定 URL + 固定解析 | 普通脚本 |
架构图 / 流程图
整个判断的决策树，画出来是这样：
注意最后两个菱形：真实项目很少是"纯 Agent"或"纯 Workflow"，绝大多数是混合体——确定的步骤用代码固定，不确定的节点才交给 Agent。这个认知，后面第 47、48 篇会专门展开。
第二张图：用 ASCII 画同一个判断的"落地视角"（发布提示：可用 draw.io 重画成正式图，与 Mermaid 图形成双图组合）：
需求进来 │ ├─ 步骤能写死？ │ ├─ 就一步 ──────────────→ [CRUD/API] 例：查订单状态 │ ├─ 需要外部知识 ─────────→ [RAG] 例：知识库问答 │ └─ 多步可枚举 ───────────→ [Workflow] 例：生成处理建议 │ └─ 步骤不能写死？ └─ 需要动态决策 ────────→ [Agent] 例：支付异常诊断 │ └─ 发现部分步骤其实确定？ └─→ [Workflow+Agent 混合]代码或配置示例
为了让"四象限"不是空话，我拿一个真实需求来做示范判断——这也将是我整个第五阶段贯穿始终的项目。
需求：做一个针对本地 Git 仓库的诊断助手，用户问"这个项目里支付相关逻辑在哪 / 帮我定位这个 bug / 这次改动有什么风险"。
# 需求 → 技术选型的判断记录（这就是"选对问题"的产出物） requirement = { "name": "Repo Doctor（仓库诊断 Agent）", "q1_steps_fixed": False, # 定位 bug 时，先 grep 还是先看 git log？不确定 "q2_branches_enumerable": False, # "查到哪算找到"无法事前写死 "q3_need_external_knowledge": True, # 需要读代码 + git 元数据 "q4_uncertainty": "high", # 用户问句本身含糊，需 Agent 追问/猜测 } verdict = choose_tech(requirement) # 输出：Agent —— 因为"该查什么、按什么顺序、查到哪一步"都不确定这个判断为什么成立？因为"定位 bug"这件事，本质上是一个调查过程：你可能先 grep 关键字，发现不对，再去看 git blame 找是谁改的，又顺藤摸瓜去看关联文件……每一步都依赖上一步的结果，没法提前写成固定脚本。这正是 Agent 该上场的地方。
为了让"判断记录"更可复现，我给每个候选需求都留了一张"选型卡"，第五阶段每做一个任务都填一张：
# 选型卡：repo_doctor/use_case.md case: name: 仓库诊断 ask: 帮我定位这个 bug / 解释这段代码 / 审查这次改动 steps_fixed: false # 调查路径不可枚举 branches_enumerable: false need_external_knowledge: true uncertainty: high verdict: agent reason: 定位 bug 是动态调查过程，路径依赖中间结果 review_date: 2026-08-15 # 注意：这个 verdict 不是永久的。第 47 篇会发现 # "PR review"子任务其实很确定，会把它单独退成 Workflow。设计权衡
| 候选方案 | 优点 | 缺点 | 为什么不选 |
|---|---|---|---|
| 硬编码脚本（CRUD） | 快、稳、零幻觉 | 只能答固定问题，遇到新 bug 就废 | 诊断的路径无法枚举 |
| 固定 Workflow | 可控、可测 | 调查型任务步骤不可枚举 | "查到哪算完"写不死 |
| RAG | 检索代码片段快 | 只检索不推理，定位不了 bug 的因果链 | 诊断需要推理，不是找片段 |
| Agent | 能动态决策调查路径 | 有幻觉风险、调试难、成本高 | 调查的本质是动态决策，只能它 |
关键结论：选 Agent 不是因为"它更高级"，而是因为这个任务的结构本身要求动态决策。反过来，如果哪天 Repo Doctor 里某个任务（比如 PR review）被证明步骤是固定的，我会毫不犹豫把它退成 Workflow——这是第 47 篇的事。
这里有一条诚实的边界值得说：四象限不是精确科学，是判断框架。有些任务会落在象限边缘，需要你结合"错误容忍度"和"团队能力"来定。判断的准则只有一条：选错了的代价，是你能承受的吗？如果你不确定，优先选更简单的方案（CRUD > Workflow > Agent），因为 Agent 的调试成本最高。
常见误区（FAQ）
Q1：我的任务"看起来需要理解自然语言"，是不是就该用 Agent？
不是。理解语言 ≠ 需要自主决策。知识库问答需要理解自然语言，但它是 RAG 的活。判断标准是"步骤能不能写死"，不是"要不要理解语言"。
Q2：Agent 用起来更酷，用它有什么坏处？
三个实打实的代价：① 幻觉风险（编造不存在的东西）；② 调试困难（输出不确定，难以复现）；③ 成本高（每步多次 LLM 调用）。这些代价，只有在任务真的需要自主决策时才值得付。
Q3：一个任务现在不需要 Agent，以后呢？
会变。任务是会演化的：今天"生成处理建议"是固定三步 Workflow，明天可能要"根据库存异常自己决定查哪些 SKU"，那它就滑进 Agent 区。所以选型不是一次性的，要定期复审（后面第 47 篇会讲"从 Agent 退成 Workflow"的反向演化）。
Q4：团队已经搭好 Agent 了，但需求其实很确定，怎么办？
这是最常见的现实：架构已经上了，发现选错了。建议不要立刻推翻，而是先量一下"Agent 自由发挥导致的错误率"，如果错误率可控、成本可接受，可以继续用；如果不行，把那部分确定的任务剥出来退成 Workflow——具体方法见第 47 篇。
总结
✅ 写 Agent 之前，先回答"到底该不该用 Agent"，这比"怎么用"更致命。
✅ 判断靠两个维度：不确定性 × 步骤可枚举性，交叉成四象限。
✅ 一句话铁律：能写清楚 SOP 的任务，就不需要 Agent。
✅ 真实项目大多是 Workflow + Agent 混合，不是纯 Agent。
✅ 我选"仓库诊断"作为第五阶段贯穿项目，因为它的调查本质要求动态决策。
✅ 选型要定期复审，任务会演化，Agent 和 Workflow 之间可以双向流动。
参考资料
- Anthropic《Building Effective Agents》→ 为什么引用：它最早把 Workflow 和 Agent 分开，提出"简单优先"原则，是四象限判断的源头。
- LangGraph 官方文档 → 为什么引用：确认了 Workflow 与 Agent 在工程实现上的边界，支撑"混合体"的结论。
系列导航
- 上一篇：AI Agent 工程实践（35）：我的 AI Engineering OS 最终架构
- 下一篇：AI Agent 工程实践（37）：需求分析——一个 Agent 项目到底应该怎么拆
本文是 [AI Agent 工程实践] 系列的第 36 篇，也是第五阶段「从 Demo 到 Production」的第一篇。
