Agent落地最难的不是模型调优，而是这个被90%团队忽略的能力
前言
我们团队（语核科技）成立于2023年5月，专注于B2B场景的AI Agent落地。过去两年，我们服务了制造业、能源、科技等行业的上百家企业。
在这个过程中，我们发现了一个反直觉的规律：大多数Agent项目的失败，不是因为模型能力不够，而是因为团队根本没搞清楚要解决什么问题。
客户说「我要提升售前效率」——这是需求吗？不是。这只是一个模糊的期望，无法转化为任何技术方案。
真正的需求是：「售前在处理招标文件的需求理解环节，平均耗时2小时，导致整体响应时效从收标到出初稿需要数日，影响中标率。」
从前者到后者的能力，我们内部称为「场景Taste」。这篇文章分享我们将其工程化的完整路径。
一、问题：Demo到生产的巨大鸿沟
很多团队做了一个在测试集上表现不错的Agent，但上线后立刻暴露三类典型问题：
1.1 需求定义失效
客户验收标准是「感觉更好用了」，而非可量化指标。这类需求无论怎么优化模型，都无法验证是否达标，项目最终沦为无法验收的「说不清」。
1.2 阻塞点识别错误
花3个月优化了「方案撰写环节」的文本生成质量，但该环节并非业务瓶颈——实际阻塞点在上游的招标文件解析，这个环节漏掉关键技术要求，导致所有下游工作反复返工。优化了错误的环节，ROI接近零。
1.3 技术可行性错判
承诺「客户谈判策略自动生成」，但该场景高度依赖现场实时判断，无历史数据可参考，难以设计验收标准，项目最终烂尾。
二、传统方案的失效边界
常见的「需求分析」方法在AI Agent项目中存在根本性失效：
用户调研失效：传统问卷和访谈能收集到「我希望更快」「我希望更准确」这类模糊期望，无法产出可执行的技术规格。业务人员描述的是「感受」，工程师需要的是「指标」，中间有一道隐形的鸿沟。
原型验证失效：Demo环境下的准确率来自精选测试集，而非真实生产环境随机样本。在某个项目中，Demo准确率92%，生产环境实际准确率仅68%——因为Demo集排除了格式混乱的文件，而这类文件占真实场景的40%。
需求文档失效：传统软件的需求文档聚焦功能描述（「系统应能生成报价」），而Agent需要的是判断逻辑描述（「当客户需求文件包含X类条款时，报价参考Y历史案例；若无匹配案例，触发人工审核」）。两者的抽象层级完全不同。
三、核心方案：场景Taste的工程化框架
场景Taste不是玄学，可以被拆解为三个可操作步骤：需求拆解 → 阻塞点定位 → 可行性评估。
3.1 整体架构
模糊业务期望（如"提升售前效率"） │ ▼ ┌────────────────────────────────────────────┐ │ 场景Taste 工程化流程 │ │ │ │ Step 1 需求拆解 │ │ ┌──────────────┐ ┌───────────────────┐ │ │ │ 识别核心目标 │──▶│ 转化为量化指标 │ │ │ └──────────────┘ └───────────────────┘ │ │ │ │ │ ▼ │ │ Step 2 阻塞点定位 │ │ ┌─────────────────────────────────────┐ │ │ │ 时间 × 频率 × 下游影响 → 阻塞指数 │ │ │ │ 按指数排序，优先攻克高分环节 │ │ │ └─────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ Step 3 可行性评估（三维） │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ 数据 │ │ 知识 │ │ 技术 │ │ │ └────────┘ └────────┘ └────────┘ │ └────────────────────────────────────────────┘ │ ▼ 清晰的技术问题定义（可以开始建模）3.2 需求拆解框架（Python伪代码）
class RequirementAnalysis: """场景Taste：需求工程化拆解框架（伪代码）""" def __init__(self, raw_requirement: str): self.raw = raw_requirement # 输入：模糊业务期望 def extract_measurable_goal(self) -> dict: """ 将模糊期望转化为可量化目标 输入: "提升售前效率" 输出: 含时效、准确率、覆盖率、审核模式的结构化指标 """ return { "time_constraint": "20min", # 处理时效上限 "accuracy_threshold": 0.90, # 关键信息提取准确率下限 "coverage_rate": 0.80, # 覆盖招标文件类型的比例 "review_mode": "human_in_loop" # L2阶段，保留人工审核 } def identify_bottleneck(self, process_steps: list) -> list: """ 定位阻塞点，按阻塞指数降序排列 阻塞指数 = 平均耗时(h) × 每周频率 × 下游影响系数 """ for step in process_steps: step["bottleneck_score"] = ( step["avg_hours"] * step["weekly_freq"] * step["downstream_impact"] # 1=低影响, 2=中, 3=高 ) return sorted(process_steps, key=lambda x: x["bottleneck_score"], reverse=True) def assess_feasibility(self, scenario: dict) -> str: """ 可行性评估：数据 + 知识 + 技术三维判断 返回: "feasible" / "conditional" / "not_feasible" """ data_ok = scenario.get("historical_samples", 0) >= 100 knowledge_ok = scenario.get("sop_definable", False) # 隐性知识能否显性化 tech_ok = ( scenario.get("structured_task", False) and scenario.get("verifiable_output", False) ) score = sum([data_ok, knowledge_ok, tech_ok]) if score == 3: return "feasible" elif score == 2: return "conditional" else: return "not_feasible"3.3 阻塞点定位：真实业务数据示例
import pandas as pd # 某制造企业售前流程各环节数据（真实生产环境测量值，非测试集） process_data = [ {"环节": "招标文件解析", "avg_hours": 2.0, "weekly_freq": 5, "downstream_impact": 3}, {"环节": "历史案例检索", "avg_hours": 1.0, "weekly_freq": 5, "downstream_impact": 2}, {"环节": "方案撰写", "avg_hours": 4.0, "weekly_freq": 3, "downstream_impact": 1}, {"环节": "内部评审", "avg_hours": 1.5, "weekly_freq": 3, "downstream_impact": 1}, ] df = pd.DataFrame(process_data) df["bottleneck_score"] = df["avg_hours"] * df["weekly_freq"] * df["downstream_impact"] df_sorted = df.sort_values("bottleneck_score", ascending=False) print(df_sorted[["环节", "bottleneck_score"]]) # 实际输出： # 招标文件解析 30.0 ← 最高优先级（非直觉最优项） # 方案撰写 12.0 # 历史案例检索 10.0 # 内部评审 4.5结论与直觉相反：「方案撰写」耗时最长（4小时），但阻塞指数排第二；「招标文件解析」耗时仅2小时，但因为下游影响系数最高（漏了关键要求会导致所有后续环节返工），阻塞指数最高，应该优先解决。
四、效果验证：引入场景Taste方法论前后对比
以下数据来自语核科技在某大型制造企业真实生产环境的随机样本（非精选测试集）：
| 维度 | 未使用场景Taste方法 | 应用场景Taste方法论后 |
|---|---|---|
| 需求对齐周期 | 2–4周（反复来回） | 3–5天（结构化拆解） |
| 招标文件解析时效 | 人工约2小时 | Agent约20分钟 |
| 关键信息提取准确率 | 约85%（人工偶发遗漏） | 99%+（真实生产环境随机样本） |
| 首次上线后返工率 | 约40%（需求不清导致） | 约8% |
| 人工审核工作量 | 逐字全量审核 | 抽查确认（工作量降约70%） |
| 项目交付周期 | 6–9个月 | 3–4个月 |
说明：上述数据仅适用于「招标文件解析+初步方案生成」这一具体场景，不同行业和场景的数据会有差异，请勿直接套用。
五、总结与后续方向
「场景Taste」解决的核心问题：在技术开发开始之前，先确保「在解决真实问题，且能验证是否解决好了」。
工程化路径：模糊期望 → 量化目标（需求拆解）→ 阻塞点排序（时间×频率×影响）→ 可行性三维评估 → 清晰技术规格。
这个能力，90%的团队在Agent项目中跳过了——他们从「客户说要什么」直接跳到「我们来实现什么」，绕过了「这件事是不是真的值得做，怎么才算做好了」这个最关键的问题。
语核科技正在将这套方法论进一步工具化，输出标准化的「场景评估清单」，供团队在项目立项阶段使用。这不是银弹，但它能大幅降低因需求不清而烂尾的概率。