01"Agent 把任务做完了，但我要的事情没有发生"
一个销售自动化团队花了两个月开发了一个邮件跟进 Agent：它能读取 CRM 数据，识别超过七天未跟进的潜在客户，自动撰写个性化跟进邮件并发送。从技术指标来看，成功率达到 94%——94% 的目标客户收到了跟进邮件。
但三个月后，销售总监发现转化率几乎没有变化。他们做了用户访谈，发现问题：邮件确实发出去了，但几乎所有邮件都进了收件方的"推广"文件夹，被自动过滤。而且，Agent 发送的邮件模板虽然"个性化"（加了收件人名字和公司名），但内容和语气让很多收件人感到这就是一封自动化邮件，直接删掉。
从技术角度，Agent 完成了任务：邮件发送成功率 94%。从业务角度，Agent 什么也没做：转化率没有变化，这些邮件甚至可能损害了品牌形象。
这就是 JTBO（任务-业务结果，Jobs to Be Outcomes）框架要解决的核心问题：任务完成≠结果达成。在功能导向的 AI 开发文化里，"做完了"是成功标准；在 JTBO 框架里，"业务结果真的发生了"才是成功标准。
02核心问题：功能鸿沟 vs. 结果鸿沟
本框架创新：F14 在 JTBD 基础上，针对 Agent 产品的特性，提出 JTBO（Jobs to Be Outcomes）三层结构——任务层（用户委托什么）、结果层（什么叫成功）、所有权层（谁对结果负责）——并把"结果所有权归属"设计为 Agent 产品设计的必要元素。
传统产品设计的"需求"概念，其实停留在功能层面——用户需要什么功能，功能是否可用。JTBO 框架把"需求"上升到结果层面——用户委托 Agent 完成这个任务，最终要实现什么业务目标？那个目标是否真的发生了？
更关键的是"所有权"问题：当 Agent 承担了某项任务，谁对这项任务的业务结果负责？是 Agent？是监督 Agent 的人类？是使用这个 Agent 的用户？责任归属不清晰，任何人都可以在结果不好时指向其他人——"是 Agent 做得不好"、"是用户没有正确使用"、"是任务定义有问题"。这种责任真空，是 Agent 产品质量长期无法提升的根本原因之一。
03JTBO 三层结构
第一层：任务层（用户委托什么）——明确谁在委托这个任务、任务描述是什么、触发条件是什么、交付物是什么。这一层是最多 Agent 产品已经回答了的层面，但往往回答得不够精确。邮件跟进 Agent 的任务层如果被定义为"发送跟进邮件"，就注定会在业务结果上失败；如果被定义为"推进销售对话进入下一阶段"，整个设计逻辑就完全不同了。
第二层：结果层（什么叫成功）——这是 JTBO 框架最核心的层面。定义成功需要四要素：可测量的结果指标（不是"提升满意度"，而是"NPS 提升 5 分"）；结果的观测时间（什么时候去看）；最低可接受阈值（低于这个分数算失败）；当前基线数据（对比基准）。
第三层：所有权层（谁对结果负责）——对每个关键成功结果，必须指定一个具名的结果所有者：这个人被授权获取结果数据；负责在结果低于阈值时启动改进；对外代表这个 Agent 的业务成效。一个没有结果所有者的 Agent，就是一个没有人真正负责的系统。
04结果鸿沟的四种根因
JTBO 框架总结了任务完成但结果未达成的四种常见根因：
目标层错误：任务定义本身就和真正的业务目标脱钩（发邮件 vs. 推进销售对话）。这是最根本的问题，需要重新定义任务。
上下文不足：Agent 拥有正确的任务定义，但缺少执行时需要的关键信息，导致输出质量无法支撑目标的实现（邮件内容缺少真实个性化需要的具体上下文）。这需要 F15 上下文优先设计来解决。
结果未度量：团队从未追踪过业务结果，只追踪技术指标，因此无法知道结果鸿沟在哪里。这需要建立结果度量体系。
所有权缺失：没有人对结果负责，没有人在结果不达标时推动改进。这需要 JTBO 第三层的所有权归属设计。
05在体系中的位置
F14 是模块三"产品重写"的需求定义框架，在 F13 的产品定位之后，为每个 Agent 的具体任务建立明确的成功标准。这是 F16（可靠性 PMF 诊断）的前提——PMF 的评估指标（任务完成率、Override 率、Re-delegation 率）都需要以 JTBO 定义的结果标准为基础。
上承 F13（产品定位决定结果定义深度）→ 本框架（JTBO 三层结构，定义成功结果和所有权）→ 下启 F15（上下文优先设计，提供实现结果所需的信息架构）→ F16（PMF 诊断，验证产品是否真正达到结果层面的市场匹配）。
01"这个 AI 有时候很有用，但关键时刻总是差那么一点"
智能体产品在上线后，有一类反馈会以相当高的频率出现：用户说"这个 AI 有时候很有用，但关键时刻总是差那么一点"。
追问"差那么一点"是什么意思，往往会得到这样的描述：它把我说的事情都做了，但最终我想要的那个结果没有发生。招聘智能体筛了几百份简历，但推给我的候选人在第一轮面试就全军覆没；内容智能体按照我的要求写了十篇文章，但没有一篇能直接发出去；客服智能体把用户投诉按流程处理了，但用户还是觉得没有被解决，继续升级投诉。
这类问题有一个共同特征：智能体在"执行任务"这个层面表现完好，但在"产生价值"这个层面失效了。产品团队通常的反应是优化具体功能，或者调整提示词，但这种局部修补不能解决根本问题，因为问题出在产品的设计起点上。
02JTBD 理论为什么需要被升级
本框架创新：在 JTBD 的"功能→工作"二层结构基础上，增加第三层"结果所有权（Outcome Ownership）"，构建"任务-结果-所有权"三层 JTBO 框架。
克莱顿·克里斯坦森的"Jobs to Be Done"理论，是过去二十年产品设计领域影响最深远的框架之一。它的核心洞察是：用户购买的不是产品本身，而是产品能帮助他们"完成某个工作"的能力。
JTBD 把产品设计从"功能导向"推向了"需求导向"，这是一个重要的进步。但在智能体产品的语境下，JTBD 还不够——因为它解决了"用户真正需要什么"的问题，但没有解决"智能体如何确保那个结果真实发生"的问题。
在传统软件产品里，这两个问题之间的连接是相对直接的：一个设计良好的功能，大概率会产生预期的用户价值。但在智能体产品里，这个连接断掉了——一个执行了所有正确步骤的智能体，完全可能没有产生任何实际的业务价值。
这个断裂，需要一个专门的框架来处理。
03从"工作"到"结果"的第三层
JTBO 在 JTBD 的"任务层"和"工作层"基础上，增加了第三层：结果所有权层。
任务层（Task Layer）
智能体实际执行的具体操作——发送邮件、分析数据、筛选候选人、生成报告。这是传统产品设计最熟悉的层面。任务层的完成质量，对应的是传统的"任务完成率"指标。
结果层（Outcome Layer）
用户真正想要发生的业务变化。不是"简历被筛选了"，而是"招到了合适的人"；不是"报告被生成了"，而是"管理层做出了更好的决策"；不是"客诉被处理了"，而是"客户真正满意并继续使用"。结果层要求产品设计者反复追问：任务完成之后，用户的业务状态会发生什么变化？
所有权层（Ownership Layer）
这是整个框架最独特的贡献，也是最容易被遗漏的一层。所有权层问的是：当结果没有达成时，谁负责？谁有义务去追问为什么没有达成，并且采取行动？
在传统软件产品里，这个问题不需要被显式回答，因为用户自己是结果的所有者——他们用了一个工具，工具表现如何是他们的事。但在智能体产品里，情况变了：当一个智能体被赋予了足够高的自主权来完成一个完整的工作流，用户可能已经退出了这个工作流的日常参与。如果结果没有达成，用户往往不知道问题出在哪一步，也不知道应该由谁来负责。
04所有权层为什么是最关键的
所有权层的缺失，是智能体产品最普遍的治理漏洞。它的表现形式很典型：结果没有达成，产品团队说"智能体按规格执行了任务"，用户团队说"但结果没发生"，两方面都说的是事实，但没有人的职责范围涵盖"端到端为结果负责"这件事。
这不只是流程问题，这是产品设计问题。一个没有明确所有权的结果，在智能体系统里会被所有人隐性放弃——因为追究一个没有所有者的结果，需要额外的协调成本，而在日常工作的压力下，没有人愿意主动承担这个成本。
JTBO 要求在产品设计阶段，就必须明确三件事：
- 谁是结果的定义者（谁说"这个结果算达成"）
- 谁是结果的监控者（谁在持续追踪结果是否正在发生）
- 谁是结果不达成时的响应者（当结果偏离预期，谁有权力和义务介入调整）
这三个角色可以是同一个人，也可以是不同的人，但它们必须在产品设计时就被明确分配，而不是在出问题之后再去讨论。
05价值交付逻辑的根本性差异
JTBO 揭示的，是智能体产品和传统软件产品在"价值交付逻辑"上的根本性差异。
传统软件产品的价值交付是"工具就位，用户使用，价值产生"——价值产生是用户行为的结果，产品的责任边界在"工具可用"这一层结束。
智能体产品的价值交付是"系统运行，结果发生，用户感知价值"——当智能体的自主性足够高，它不再只是用户使用的工具，它是参与价值创造过程的主体。一个主体，必须对它参与创造的结果承担某种形式的责任。
这是一个范式级别的转变。它意味着智能体产品团队不能只用"功能完整性"和"技术性能"来衡量产品质量，他们必须把"结果达成率"和"所有权清晰度"纳入核心产品指标体系。
没有这个视角，所有的产品迭代都在优化任务执行层面的细节，而那个真正决定用户价值的结果层，没有人在认真设计。
T1理论来源与学术引证
以下为本框架的理论基础说明，提炼自正文中的理论注释块。
本框架创新：在 JTBD 的"功能→工作"二层结构基础上，增加第三层"结果所有权（Outcome Ownership）"，构建"任务-结果-所有权"三层 JTBO 框架。
T2框架定位与适用边界
本框架是管理实践工具，为高管和研究者提供结构化分析视角，不提供可直接验证的因果预测。其有效性依赖于：分析者对所在行业的深度认知、可获取的组织数据质量、以及将分析结论与具体决策场景相结合的能力。
智能体时代的框架有一个共同的时效性问题——AI 技术演化速度快于传统战略框架的更新周期。建议每 12–18 个月对本框架的核心假设进行一次复盘，检视其前提条件是否仍然成立。