评审会上的质疑很具体：搜索 DAU 800 万、推荐 1200 万、智能客服日均 30 万会话，新立项的「生活助手 Agent」能查、能比价、能下单、能办售后，凭什么不是又一个入口？
「Agent 更适合复杂任务」这种回答撑不过第二轮追问。要答好，必须拿出一个具体任务，逐个指出已有产品是在哪一步断掉的。
本系列第 7/10 篇 · 上一篇：成功率从 85% 掉到 61%，先别急着修超时 · 下一篇：2.5 秒和两毛钱，降级顺序是一份产品决策
一个任务，三处失效
用户说：「给爸妈买台 3000 以内、噪音小的洗衣机，周末送到老家；送到后如果有问题，帮我走售后，进度随时告诉我。」
拆成六步：明确约束 → 找候选并比价 → 校验老家地址周末可送 → 下单 → 三天后确认签收 → 有问题则发起售后并跟踪。
- 搜索在第 1 步之后就断了。它能给候选链接，不维持状态，不记得「老家地址」「不买延保」，更不会在三天后回来确认。用户得自己把六步串起来，每步重新输入一遍上下文。
- 推荐解决的恰恰是相反的问题：用户没有明确目标时激发需求。这里目标已经很清楚了，继续推「你可能还喜欢」是干扰，不是帮助。
- 客服是被动响应、按工单闭环。它能在售后那一步帮上忙，但不会主动在签收后发起跟进，也不承接前面那笔订单的完整状态。
所以 Agent 的增量不是「更聪明的搜索框」，是有状态地承接一个跨时间、跨系统的任务，并对结果跟踪到底。这句话里最值钱的是「跨时间」：前三者的交互单位都是一次请求或一次会话，Agent 的单位是一个可能延续几天的任务。
反过来说，如果产品做不到跨会话状态和进度回访，就别叫 Agent——那只是把搜索结果换成了对话气泡。
路由规则要可执行
我不想让模型自己判断「这个请求该归谁」。规则用四个信号，前两个是硬判据：
| 信号 | 判定 | 去向 |
|---|---|---|
| 是否需要跨会话状态 / 后续跟踪 | 含「到时候」「送到后」「提醒我」等 | Agent |
| 是否含代执行动作（下单、退款、改约） | 布尔 | Agent |
| 动作数 | ≥ 2 个且存在依赖 | Agent |
| 意图明确度 | 明确且只需事实型答案 | 搜索 |
| 无明确目标、以浏览为主 | 弱意图 | 推荐 |
| 已有订单号/工单号的咨询 | 命中业务实体 | 客服 |
阈值思路写清：「动作数 ≥ 2」是按动宾结构计数，不按句子数；「明确且只需事实型答案」优先于其他信号，哪怕用户用了对话式提问。这条优先规则很重要，否则所有问句都会被吸进 Agent，直接把搜索流量换个壳搬过来。
还有一条产品底线：路由错了要能一键回到原入口，并带上已输入的上下文。用户被 Agent 接住却发现只想查个参数，不该重新打一遍字。
入口别去抢搜索框的心智
首期我反对做一级 Tab 或首页大输入框。那等于同时宣布「原来的搜索不够用」，还要跟一个用了多年的肌肉记忆抢位置，冷启动数据几乎必然难看。
入口从具体任务场景里长出来：搜索结果页在比价类 query 下给一个「帮我盯着这件事」，订单详情页给「跟踪这次送达与售后」，客服会话在结论尾部给「交给助手办完」。用户不是来「用 Agent」的，是某一步嫌麻烦时顺手交出去的。
首期明确不做三件事：开放式闲聊、全品类代下单、跨账号数据打通。前两件会把失败率拉到没法看，第三件在权限和合规上会拖死排期。
怎么证明是增量，不是搬运
会话级指标全都不算数——多一个入口，会话数必然涨。我用任务级口径：
新增完成任务数 = 在 Agent 中完成、且对照组在同一周期内未通过搜索/推荐/客服完成同类任务的数量。任务要有稳定 id（由意图 + 关键实体 + 时间窗生成），同一用户跨入口的重复行为去重。
配合三个辅助数：跨步骤完成率（走到最后一步的比例）、存量入口的同类任务完成时长变化、以及 Agent 完成的任务里「含跨会话跟踪」的占比。最后这个数如果长期很低，说明产品实际在干搜索的活，定位就该收回来重做。
对照组怎么设：按用户分流，对照组不开放入口但保留全部原有产品；比较的是同类任务的整体完成率，而不是 Agent 组内部的完成率。只看实验组，永远能证明自己有用。
追问：60% 的请求搜索就能满足
我不会据此砍项目，也不会据此说项目没问题。先看三件事：
- 这 60% 里，搜索满足的质量如何——是不是查完就走、有没有后续比价与下单行为、平均耗时比 Agent 长还是短。如果 Agent 只是多包了一层对话，这部分应当主动回流搜索，收缩入口。
- 剩下 40% 的价值密度：跨步骤任务完成率、客单价、次周留存。40% 若贡献了大部分转化和留存，产品该聚焦这 40%，而不是去跟搜索争那 60%。
- 把 60% 回流搜索之后的整体指标：总任务完成率、总耗时、存量入口流量。整体不降甚至变好，说明收缩是对的。
砍的应该是入口范围，不是能力。真正该砍项目的信号是另一条：那 40% 里也没有出现搜索做不到的状态承接与跟踪，或者用户根本不愿意把代执行交给它。那时候要怀疑的是需求假设，不是流量分配。
我会怎么看答案
及格：说 Agent 能做多步任务、体验更自然。良好：能拿具体任务指出三者失效点，能写路由规则。优秀：把「跨会话状态」作为增量核心、敢于不做一级入口、给出任务级去重口径与对照组设计、并且能在 60% 数据面前调整结论而非硬守立项。
最常见的失分是把差异化做成能力清单对比表，列一堆「Agent 有记忆、有工具」。评委问的从来不是「多了什么」，是「原来那个为什么做不到、以及用户会不会为此换个入口」。
差异化不是功能更多，是承接了一件原本没人负责到底的事。
定位谈完，合同上的数字更硬：P95 要压到 2.5 秒，单会话成本要砍一半。
评论