发布时间2026-08-29标签AI Agent工程实践Use Case SelectionAgent 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/APIB根据订单、库存、物流生成处理建议能三步查→算→出报告流程可枚举WorkflowC分析一次支付服务异常自己判断查什么、发现异常继续查、最后给方案不能查日志还是监控、查到哪一步算完事前不知道需要动态决策AgentD在知识库里找某篇笔记能检索→摘录但需要外部知识检索型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] 例支付异常诊断 │ └─ 发现部分步骤其实确定 └─→ [WorkflowAgent 混合]代码或配置示例为了让四象限不是空话我拿一个真实需求来做示范判断——这也将是我整个第五阶段贯穿始终的项目。需求做一个针对本地 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 的调试成本最高。常见误区FAQQ1我的任务看起来需要理解自然语言是不是就该用 Agent不是。理解语言 ≠ 需要自主决策。知识库问答需要理解自然语言但它是 RAG 的活。判断标准是步骤能不能写死不是要不要理解语言。Q2Agent 用起来更酷用它有什么坏处三个实打实的代价① 幻觉风险编造不存在的东西② 调试困难输出不确定难以复现③ 成本高每步多次 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」的第一篇。