找 Job，而不是找 Agent

一句话理解：好的 Agent 需求不是“做一个客服 Agent”，而是“在 10 分钟内查清一笔卡住的退款为什么没到账，并把能处理的处理掉”——具体到触发、输入、完成标准和可验证的结果。

几乎所有失败的 Agent 项目，都始于一句听起来很合理的话：“我们要做一个客服 Agent”“给财务做个 AI 助手”。这句话里没有用户、没有触发时机、没有完成标准，于是团队只能先搭一个能聊天、能查几个接口的原型，演示时很惊艳，上线后没人用，因为它没有接住任何一件具体的工作。

这一课是整个产品模块的起点：先找到 Job（用户真正要完成的任务），再决定是否需要 Agent、需要多大的自主性。后面的流程拆解、PRD、评估与商业测算，全都建立在这一步之上。

从“做个 Agent”到一个可验证的 Job

Job 这个词来自 Jobs-to-be-Done：用户“雇佣”一个产品，是为了在特定情境下取得某个进展。放到 Agent 语境里，一个合格的 Job 至少要回答五个问题：

要素	要回答的问题	模糊写法	具体写法
谁	谁在什么岗位上遇到这件事	客服人员	售后运营专员，每天处理 30–50 笔退款异常
何时	什么事件触发这件事	需要的时候	用户或客服投诉“订单一直没退款”，或退款申请超过时效 T+3 仍未完成
做什么	最终要取得什么进展	帮忙处理售后问题	定位退款未完成的原因，处理能自动处理的，把需要审批的整理成审批单
做到什么程度	怎样算完成	回答用户问题	输出原因分类 + 证据 + 已执行动作 + 待审批动作，退款状态可被系统确认
为什么重要	不做会怎样	提升效率	人工排查平均 40 分钟/单，涉及 6 个系统，用户退款延迟引发投诉与流失

把左边的“模糊写法”换成右边的“具体写法”之后，这件事是否值得做、要接哪些系统、怎么评估，几乎一目了然。

用三层问题挖出真正的 Job

用户提需求时说出来的通常是方案，而不是 Job。比如业务方说“我们要一个能查订单的 AI”，这是方案；你需要一层层往下问。

图 1 · Job 定义漏斗：追问两层，才从“方案”走到真正的 Job

三层问题分别对应三种产品形态：只停在第 1 层，做出来的是查询 Chatbot；停在第 2 层，是诊断 Assistant；挖到第 3 层，才会自然推导出“诊断 + 执行 + 审批 + 验证”的 Agent 设计，以及“资金安全”这一条硬约束。

几个实用的追问句式：

“你上一次处理这件事是什么时候？从头到尾做了什么？”（逼出真实流程，而不是理想流程）
“最麻烦、最耗时的是哪一步？”（找到价值集中点）
“哪一步你最怕做错？做错会怎样？”（找到风险点与审批点）
“做完之后你怎么知道真的好了？”（找到验证方式）

电商案例：把一句话改写成 Job 卡片

以本模块贯穿全程的「订单售后处理 Agent」为例。原始需求是：“做一个客服 Agent，帮售后团队处理异常。” 访谈 3 位售后专员、翻看 50 张历史工单之后，可以改写成下面这张 Job 卡片：

job: 定位并处理“订单退款长期未完成”的异常
user: 售后运营专员（主）、客服坐席（次）
trigger:
  - 人工输入：“订单 SO20260912001 为什么还没退款？”
  - 定时扫描：退款申请提交后超过 T+3 仍未完成的订单
input: 订单号（必需）、用户投诉描述（可选）
desired_outcome:
  - 给出未退款原因：支付未到账 / 退货未签收 / 政策不符 / 流程卡单 / 其他
  - 每个结论附带证据（来自哪个系统、哪条记录）
  - 低风险动作自动完成（如催办用户寄回、重新触发退款通道校验）
  - 涉及资金或主数据的动作生成审批单，不直接执行
done_when: 原因被确认，且退款单进入退款队列或审批队列，状态可在系统中查询到
not_in_scope: 修改商品定价、直接发起打款、处理平台仲裁与法务纠纷
value: 人工 40 分钟/单 → 目标 5 分钟内完成诊断；减少退款超时投诉

注意几个细节：

not_in_scope 和 in_scope 同样重要。 明确“不直接发起打款”，等于提前划出了自主性上限，后面的权限设计会轻松很多。
done_when 必须能被系统确认。 “回答了用户”不算完成，“退款单进入退款队列”才算。这是后面设计验证环节的基础，详见「各类动作的验证方式」。
价值要有基线。 没有“现在 40 分钟/单”这个数字，上线后就无法证明价值，也算不清 ROI。

判断这个 Job 是否值得交给 Agent

有了 Job 卡片，再回到「什么时候值得做 Agent」中的四个条件逐条核对：

条件	订单退款异常 Job	结论
跨系统	订单、支付、发货与签收、退货入仓与库存、售后工单、退款单、优惠分摊、退款政策，至少 8 个数据源	满足
多步骤	查完订单才知道该查哪条退货记录、哪条政策条款	满足
需要判断	同样是“未退款”，原因可能是四类中的任意一种或几种叠加	满足
最终要执行	催办寄回、重新校验、生成审批单	满足

四项全满足，适合做 Agent。反过来，如果某个 Job 只是“按订单号查退款状态”，一个查询接口加一个表单就够了，不必上 Agent。

把这次核对画成一张图，结论和反例放在一起看会更清楚：

图 2 · 四个条件逐条核对，全部满足才值得做成 Agent

常见误区

“先把 Agent 做出来，再找场景。” 没有 Job 的 Agent 只能靠演示取悦人，无法建立评测集，也就无法迭代。先有 Job，再有 Agent。
“Job 越大越好，一次解决所有售后异常。” 过大的 Job 会让工具、上下文和评测全部失控。先选一个高频、边界清晰的子 Job（如“退款未完成”），做透后再扩展到“换货超时”“价保争议”。
“用户说要什么就做什么。” 用户描述的往往是方案。“能查订单的 AI”背后真正的 Job 是“让钱按时退出去且不出错”，这决定了审批与验证才是设计重心。

产品经理检查清单

这个 Job 的主要用户是谁？他们一天遇到几次？
触发条件是什么？是人发起、事件触发，还是定时扫描？
完成标准能不能被系统确认，而不是靠“感觉回答得不错”？
明确写出了哪些事情不做？
现在人工完成它的耗时、成本和错误率是多少？
做错的最坏后果是什么？谁来承担？
它满足跨系统、多步骤、需要判断、最终要执行中的几条？

练习

选一个你所在团队经常听到的“做个 AI / Agent”需求，用 30–45 分钟完成：

找一位真正做这件事的人，用“三层问题”访谈 15 分钟。
按本文的 YAML 结构写一张 Job 卡片，重点写清 trigger、done_when 和 not_in_scope。
用四个条件判断它该做成 Agent、Workflow 还是一个普通功能，并写一句理由。

下一步

Job 定下来之后，下一课「拆解人工流程」会带你观察专家是怎样一步步完成这件事的——这是 Agent 设计中信息量最大的一步。

找 Job，而不是找 Agent