一个失败的 Agent 项目复盘：需求理解出了问题

AIGC应用创新大全

121人浏览 · 2026-06-01 21:36:58

AIGC应用创新大全 · 2026-06-01 21:36:58 发布

一个失败的 Agent 项目复盘：需求理解出了问题

作者：老周 | 15年软件架构师，资深技术博主
本文约10200字，阅读需要20分钟，建议所有做AI Agent、大模型ToB项目的开发者/产品经理/项目经理收藏

大家好，我是老周。去年底我带团队接了一个320万的国内头部家电品牌售后智能Agent项目，熬了6个月全量上线，结果3个月就被客户要求下线，退还80%项目款，算上人力、云资源、第三方API成本，净亏217万，团队核心的2名算法工程师也因为项目受挫离职。

复盘了整整2个月，我们排除了所有技术层面的问题：Agent意图识别准确率92%，工具调用成功率94%，RAG检索准确率91%，所有技术指标都达到了合同约定的标准。但最终项目失败的核心原因，从第一天签合同开始就埋下了：我们完全理解错了客户的真实需求。

今天把整个复盘过程完整写出来，没有任何藏私，所有踩过的坑、总结的方法论全部公开，希望能给所有做AI Agent项目的同行提个醒：对于大模型这类新兴技术项目，需求理解的权重占70%，技术只占30%。

一、项目背景：看起来稳赚不赔的单子

1.1 客户背景

客户是国内TOP3的家电售后平台，服务覆盖全国31个省份，2万+合作网点，10万+安装维修师傅，日均售后咨询量12万次，现有1200人的人工客服团队，每年人力成本超过2亿。

1.2 需求来源

客户的IT部门在2023年中启动了「售后智能化升级」项目，公开招标智能售后Agent系统，要求实现：

「替代80%的人工售后客服，覆盖报装、报修、进度查询、投诉四类核心场景，降低人力成本，提升用户体验」

1.3 我们的判断

当时我们团队已经做过3个政务、电商领域的Agent项目，对LangChain、LLM微调、RAG、工具调用等技术栈非常熟悉，看到这个需求第一反应是「稳了」：

场景明确：四类售后场景都是标准化流程
数据充足：客户有超过500万条历史客服对话标注数据
技术成熟：RAG+工具调用+记忆链的架构完全能覆盖需求
预算充足：320万的预算足够覆盖所有开发、测试、上线成本

我们用了2周时间做了Demo，演示了用户报装、报修的完整流程，客户IT部门非常满意，很快就签了合同，工期6个月，验收标准是「Agent独立闭环率≥80%」。

二、需求偏差：我们理解的 vs 客户真实要的

上线后第一个月，我们就接到了客户的投诉：Agent天天捅娄子，人工客服的工作量反而增加了30%，用户投诉率上升了17%。我们拉了客户的业务部门、一线客服、网点服务商开了3次对齐会，才发现我们理解的需求和客户真实的需求，差了十万八千里。

2.1 核心需求偏差对比

我们做了一个详细的对比表，把双方的认知差异拆成了5个核心维度：

维度	我们理解的需求	客户真实需求	偏差程度
核心目标	替代80%的人工客服，减少80%的客服人力	让每个客服的工单处理效率提升80%，不用裁人，承接更多的业务量	100%完全相反
验收标准	Agent独立闭环率≥80%，即80%的咨询不需要人工介入	人工单工单处理时长降幅≥50%，用户投诉率降幅≥20%	指标完全不对齐
服务角色	只服务C端消费者，对接用户的咨询需求	同时服务C端消费者、B端网点服务商、安装师傅、内部运营4类角色，需要跨角色协同	覆盖范围差了4倍
容错阈值	容错率≤5%，即100个咨询最多错5个，出错了Agent自己纠正	容错率≤0.1%，涉及费用、派单、承诺的场景不允许出错，出错了由Agent项目方承担损失	容错要求差了50倍
成本要求	只需要承担Agent系统的开发运维成本	Agent系统的使用成本不能超过现有客服人力成本的10%，包括API调用、运维、人工审核成本	成本要求完全没考虑

2.2 偏差产生的核心原因

2.2.1 需求访谈只对接了IT部门，没碰业务决策人

我们整个需求调研阶段，只和客户的IT部门对接，IT部门转述的需求是「要做行业最先进的智能Agent，替代人工降本」，但我们从来没和业务总监、一线客服主管、网点服务商这些真正的使用方聊过。

业务总监的真实诉求是：「现在客服团队接不住旺季的咨询量，每年要临时招300个兼职客服，培训成本高，出错率高，我要Agent帮人工处理掉重复的信息收集、流程查询工作，让每个客服能同时处理10个工单，而不是裁掉我的人」
一线客服的真实诉求是：「我每天要接80个电话，很多用户问的都是‘我的工单什么时候派’‘师傅到哪了’‘安装费多少钱’，我要在5个系统之间切来切去查信息，我要Agent帮我把这些信息自动汇总好，我直接回答用户就行」
网点服务商的真实诉求是：「每个区域的安装政策、收费标准、师傅资质都不一样，Agent不能随便给用户承诺上门时间、收费金额，不然最后赔的钱都是我们网点出」

2.2.2 模糊需求没有量化，默认按技术最优解实现

合同里写的「替代80%的人工售后客服」是完全模糊的描述，我们默认按技术层面的「独立闭环率」来理解，但客户的业务层面的「替代」是「替代人工的重复操作环节」，我们没有把模糊需求拆解成可量化、可验收的指标就开工了。

2.2.3 没有做业务蹲点，对真实场景完全不了解

我们想当然的认为售后场景就是「用户发消息→Agent回答/处理」，但实际上整个售后链路有17个环节，涉及5个角色的交互：

我们的Agent只覆盖了B环节的C端咨询，剩下的C、D、H等核心环节完全没碰，根本帮不上业务的忙。

三、连锁反应：需求偏差带来的全链路失败

需求理解的错误，从架构设计阶段就开始传导，最终导致整个系统完全无法满足业务需求。

3.1 架构设计完全错误

我们当时设计的是单Agent架构，直接对接C端用户，所有逻辑都是围绕「独立处理用户咨询」来做的：

而客户实际需要的是多Agent协作架构，支持多角色、多权限、人在回路的协同：

两个架构的核心差异：

没有多租户权限中心：我们的知识库是通用的，没有按区域、网点、品牌拆分，导致Agent经常给出错误的政策信息，比如上海的网点高空作业费是50元，北京的是80元，Agent统一返回50元，最后网点要自己承担差价。
没有人在回路调度中心：我们的Agent默认是尽量不转人工，所有决策都自己做，而客户要求所有涉及费用、派单、承诺的决策都必须人工审核。
没有多角色Agent：我们只做了C端的接待Agent，没有做服务师傅、服务商、运营的Agent，根本覆盖不了全链路的需求。

3.2 开发资源完全错配

我们把70%的开发资源都投入到了优化Agent的意图识别准确率、工具调用成功率上，花了3个月时间把意图识别准确率从85%优化到92%，但这些功能对客户来说完全没用：

客户需要的不是Agent自己做决策，而是把不同系统的信息汇总给人工，由人工做决策
我们花了2个月做的Agent自主派单功能，客户从来没用过，因为派单涉及到网点的利益分配，必须由人工调度
我们花了1个月优化的自然语言生成回复功能，客户要求直接用固定话术，避免出现违规承诺

3.3 评估指标完全不对齐

我们用的技术层面的评估指标是独立闭环率：
$Accagent=NclosedNtotalAcc_{agent} = \frac{N_{closed}}{N_{total}}$
其中 $N_{closed}$ 是Agent独立闭环的咨询量， $N_{total}$ 是总咨询量，我们上线后这个指标达到了89%，达到了合同约定的80%的标准。

但客户用的业务层面的评估指标是人工效率提升率：
$Effimprove=Tbefore−TafterTbefore×100%Eff_{improve} = \frac{T_{before} - T_{after}}{T_{before}} \times 100\%$
其中 $T_{before}$ 是上线前人工处理每个工单的平均时长（12分钟）， $T_{after}$ 是上线后人工处理每个工单的平均时长（15.6分钟），算下来效率反而降低了30%，因为Agent经常给出错误的信息，人工要花更多时间擦屁股。

四、核心代码复盘：我们当时写的错误实现

下面是我们当时开发的单Agent核心代码，用LangChain实现，现在回头看到处都是问题：

import time
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.tools import tool
import chromadb

# ========== 初始化组件 ==========
# 初始化向量库，通用售后知识库，没有做权限隔离
chroma_client = chromadb.PersistentClient(path="./public_knowledge_base")
kb_collection = chroma_client.get_collection("after_sales_public")

# 初始化大模型
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0, api_key="xxx")

# ========== 定义工具 ==========
@tool
def search_knowledge_base(query: str) -> str:
    """搜索售后知识库，获取政策、流程、收费相关信息"""
    # 没有加区域、网点、品牌的过滤条件，返回的是通用信息
    results = kb_collection.query(query_texts=[query], n_results=3)
    return "\n".join(results["documents"][0])

@tool
def create_work_order(user_id: str, order_type: str, address: str, desc: str) -> str:
    """创建售后工单，类型可选：报装/报修/投诉"""
    # 没有校验网点的服务范围、师傅资质、排期，直接创建工单
    # 调用工单系统API的逻辑省略
    return f"工单已创建成功，编号：WO{int(time.time())}，师傅会在24小时内联系您"

@tool
def query_work_order_status(order_id: str) -> str:
    """查询工单的当前处理进度"""
    # 没有校验用户的工单权限，只要有工单编号就能查
    # 调用工单系统API的逻辑省略
    return f"工单{order_id}当前状态：已派单，师傅张三，电话13xxxxxxxxx，预计上门时间：今天14:00-18:00"

# ========== 初始化Agent ==========
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是专业的售后智能客服，需要独立处理用户的所有售后问题，尽量不要转人工，所有问题都要给出明确的答复。"),
    ("user", "{input}"),
    ("agent_scratchpad", "{agent_scratchpad}")
])
tools = [search_knowledge_base, create_work_order, query_work_order_status]
agent = create_openai_tools_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# ========== 测试调用 ==========
if __name__ == "__main__":
    # 真实用户咨询
    response = agent_executor.invoke({
        "input": "我家昨天买的XX牌空调，地址是北京市朝阳区XX小区6楼没有电梯，今天能不能上门安装？安装费多少钱？"
    })
    print("Agent回复：", response["output"])
    # 输出：您好，今天可以上门安装，安装费是免费的，已经为您创建工单，编号WO123456789，师傅会在24小时内联系您。
    # 实际错误：北京朝阳区的网点6楼无电梯需要收80元高空作业费，今天已经没有排期，无法上门。

4.1 代码中的核心问题

系统提示词完全错误：要求Agent「尽量不要转人工，给出明确答复」，和客户要求的「不确定就转人工，不要随便承诺」完全相反。
知识库没有权限隔离：搜索知识库的时候没有加区域、网点、品牌的过滤条件，返回的是通用信息，导致收费标准、政策信息错误。
工具调用没有校验逻辑：创建工单的时候没有校验网点的排期、服务范围、师傅资质，直接返回创建成功，导致大量空单、错单。
没有人工介入钩子：所有决策都由Agent直接做出，没有人工审核的环节，出了问题无法追溯。
没有多角色支持：只支持C端用户的查询，不支持师傅、服务商、运营的角色登录和权限控制。

五、正确的需求拆解与实现方案

复盘后我们重新梳理了客户的真实需求，设计了符合业务要求的多Agent协作系统，下面是核心实现逻辑：

5.1 需求拆解的核心原则

所有需求必须拆解到「可量化、可验收、可落地」的颗粒度，我们把客户的「替代80%人工操作」的模糊需求拆解成了12个可验收的指标：

指标名称	验收标准	权重
信息收集自动化率	100%的用户咨询的基础信息（地址、联系方式、产品型号）由Agent自动提取，不需要人工录入	20%
跨系统信息汇总率	100%的工单相关信息（物流、备件、排期、政策）由Agent自动从各个系统汇总，不需要人工切换系统查询	25%
标准回复生成率	90%的通用咨询回复由Agent自动生成，人工只需要点击发送即可	15%
工单创建自动化率	80%的工单由Agent自动创建，人工只需要审核即可	15%
单工单处理时长降幅	≥50%，从12分钟降到6分钟以内	25%

5.2 核心ER关系设计

我们梳理了整个系统的实体关系，明确了多角色、多权限的设计：

5.3 修正后的核心代码

import time
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_tools_agent
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.tools import tool
import chromadb
from typing import Optional

# ========== 新增：权限中心组件 ==========
class PermissionCenter:
    def get_user_region(self, user_id: str) -> Optional[str]:
        """获取用户所属区域"""
        # 从用户系统查询，这里省略实现
        return "beijing_chaoyang"
    
    def get_user_brand(self, user_id: str, product_id: str) -> Optional[str]:
        """获取用户产品所属品牌"""
        # 从订单系统查询，这里省略实现
        return "xx_air_conditioner"
    
    def check_work_order_permission(self, user_id: str, order_id: str) -> bool:
        """校验用户是否有权限查询工单"""
        # 权限校验逻辑省略
        return True

permission_center = PermissionCenter()

# ========== 初始化组件 ==========
# 知识库按区域、品牌拆分
chroma_client = chromadb.PersistentClient(path="./multi_tenant_knowledge_base")

# 初始化大模型
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0, api_key="xxx")

# ========== 新增：人在回路组件 ==========
class HumanInLoop:
    def need_audit(self, action: str, context: dict) -> bool:
        """判断是否需要人工审核"""
        # 涉及创建工单、费用承诺、派单的操作都需要人工审核
        need_audit_actions = ["create_work_order", "commit_fee", "dispatch_order"]
        return action in need_audit_actions
    
    def push_audit_task(self, action: str, context: dict) -> str:
        """推送审核任务给人工"""
        # 推送到人工坐席系统逻辑省略
        return f"审核任务已提交，审核ID：AUD{int(time.time())}"

human_in_loop = HumanInLoop()

# ========== 定义工具 ==========
@tool
def search_knowledge_base(query: str, user_id: str, product_id: Optional[str] = None) -> str:
    """搜索售后知识库，获取政策、流程、收费相关信息，必须传入user_id"""
    # 先获取用户的区域、品牌信息
    region = permission_center.get_user_region(user_id)
    brand = permission_center.get_user_brand(user_id, product_id) if product_id else None
    # 按权限过滤知识库
    filter_conditions = {"region": region}
    if brand:
        filter_conditions["brand"] = brand
    results = kb_collection.query(
        query_texts=[query],
        n_results=3,
        where=filter_conditions
    )
    if not results["documents"]:
        return "未查询到相关信息，请转人工处理"
    return "\n".join(results["documents"][0])

@tool
def create_work_order(user_id: str, order_type: str, address: str, desc: str, product_id: str) -> str:
    """创建售后工单，类型可选：报装/报修/投诉，必须传入user_id、product_id"""
    # 先校验权限和排期
    region = permission_center.get_user_region(user_id)
    # 调用网点系统校验排期逻辑省略
    has_schedule = False
    if not has_schedule:
        return "当前区域暂无可用安装师傅，请转人工确认上门时间"
    # 人在回路审核
    if human_in_loop.need_audit("create_work_order", locals()):
        audit_id = human_in_loop.push_audit_task("create_work_order", locals())
        return f"已为您提交工单申请，需要人工审核，审核编号：{audit_id}，审核通过后会第一时间通知您"
    # 审核通过后创建工单逻辑省略
    return f"工单已创建成功，编号：WO{int(time.time())}"

# ========== 初始化Agent ==========
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是专业的售后智能客服助手，所有涉及费用、时间、服务承诺的问题，如果没有100%的把握，请直接转人工处理，不要给用户明确的承诺。所有操作必须严格遵守权限规则。"),
    ("user", "{input}"),
    ("agent_scratchpad", "{agent_scratchpad}")
])
tools = [search_knowledge_base, create_work_order]
agent = create_openai_tools_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

5.4 修正后的核心改进

增加了权限中心：所有工具调用都要先校验用户的权限，按区域、品牌过滤知识库和工具的使用范围。
增加了人在回路模块：所有涉及风险的操作都要经过人工审核，避免Agent做出错误承诺。
修正了系统提示词：明确要求Agent不确定就转人工，不要随便给出承诺。
工具参数增加了权限校验字段：所有工具都必须传入用户ID，做权限校验。
增加了异常处理逻辑：当查询不到信息、没有排期的时候，明确提示转人工，不要给出错误信息。

六、Agent项目需求管理最佳实践

从这个失败的项目里，我们总结了10条Agent项目需求管理的最佳实践，只要严格遵守，能避免90%的需求理解问题：

6.1 需求调研阶段

必须访谈3类人：业务决策人（出钱的）、一线使用人（客服、运营、师傅）、最终用户（C端/B端用户），缺一类都不要开工。
必须蹲点1周业务：跟着一线使用人员坐班，观察100个真实的业务场景，比开10次需求评审会有用。
必须拆解模糊需求：所有「智能」「高效」「体验好」「替代人工」这类模糊描述，必须拆解成可量化、可验收的数字指标，写进合同。
必须做预期管理：明确告诉客户Agent的能力边界，什么场景能做，什么场景不能做，出错了怎么处理，不要吹牛逼说Agent能解决所有问题。

6.2 需求确认阶段

必须签需求边界确认书：把所有需求、验收标准、边界、变更流程都写清楚，双方签字盖章，避免后面扯皮。
必须做MVP验证：先花2周做最小可行产品，跑通1个核心场景，和客户对齐后再做全量开发，不要上来就做所有功能。
必须对齐评估指标：所有技术指标必须和客户的业务KPI绑定，不要自己给自己定技术指标，比如客户的KPI是效率提升，你的指标就不能是准确率。

6.3 开发上线阶段

必须内置人在回路：所有Agent项目的默认设计必须包含人工审核环节，不要假设Agent可以100%正确。
必须做2周灰度测试：选1%的流量跑，每天和客户对齐问题，不要一下子全量上线。
必须建立快速响应机制：Agent项目上线后前3个月，必须有7*24小时的运维团队，遇到问题快速修复，不然很容易被客户下线。

七、AI Agent项目需求演变趋势

我们整理了近5年Agent项目需求的演变趋势，能明显看到需求的复杂度越来越高，对需求理解的要求也越来越高：

时间	Agent形态	核心需求特征	需求理解痛点	需求对齐方式
2020年及以前	FAQ问答机器人	固定问题匹配，回答准确率≥90%	需求清晰，边界明确	功能列表确认
2021-2022年	任务型对话机器人	完成固定流程任务，比如查快递、改地址	流程边界不清晰，异常场景多	流程梳理+用例确认
2023年	单Agent工具调用	独立完成复杂任务，比如写报告、查数据	任务复杂度高，用户预期不统一	MVP验证+指标对齐
2024年及以后	多Agent协作系统	融入企业业务流程，跨角色协同提效	业务链路长，涉及角色多，客户自己都不清楚需求	业务咨询+流程重构+分阶段验收