问题驱动对话智能体建设

最近几年，随着大模型技术的普及，几乎每个公司都在尝试建设自己的对话智能体（AI Agent）。

但是我观察到一个普遍的现象：很多团队在立项时，往往是“技术驱动”或“功能驱动”的。大家会列出一长串酷炫的功能清单——要支持多轮对话、要能调用外部 API、要支持多模态……结果项目做得很重，上线后用户却不买账，觉得“不聪明”或者“没解决我的问题”。

其实，建设对话智能体，最务实也最高效的方法应该是“问题驱动”。

智能体的本质是一个交互界面的革命，它的核心价值不在于背后用了多复杂的模型，而在于它能多快、多准确地解决用户的实际疑问。顺着这个思路，我们可以把传统软件工程的生命周期，重新映射到对话智能体的建设上来。

核心思想可以概括为三个阶段：

传统的软件开发，起点是产品经理写的 PRD（产品需求文档）。但在对话智能体的世界里，真实的“用户问题”才是最核心的需求。

很多团队在设计初期喜欢凭空想象用户会怎么问，这往往会导致偏差。正确的做法是，去收集用户在真实场景下会问的“Top 100 个问题”。

从问题推导意图： 用户问“我的快递到哪了？”，这背后是一个“物流查询”的意图。
从意图推导能力（工具/API）： 为了回答这个问题，智能体需要具备调用内部订单系统和物流接口的能力。
从能力推导 Prompt 与工作流： 开发者需要设计相应的 Prompt，让大模型知道在识别到该意图时，应该提取哪些参数（如订单号），并触发哪个工作流。

总结： 不要先建系统再找场景，而是先收集“问题”，让问题来决定你需要开发什么“需求”。

代码写完了，怎么测试？传统软件测试是点按钮、填表单，看系统是否崩溃。而对话智能体的测试，本质上是语义和逻辑的验证。

这个时候，前期收集的“问题”，以及我们期望智能体给出的“标准答案”，就构成了问答对（Q&A Pairs）。这些问答对，就是我们的测试用例。

SIT（系统集成测试）： 重点验证“死逻辑”。将几百个基础问答对批量输入给智能体，测试意图识别是否准确、API 调用是否成功、参数提取是否遗漏。这是一个客观的、可量化的过程，甚至可以引入另一个大模型来进行自动化的交叉打分。
UAT（用户验收测试）： 重点验证“活体验”。让业务人员基于真实的业务场景，用口语化、甚至带点口音或错别字的表述去提问。这里测试的是智能体的鲁棒性（Robustness）、语气是否合适、以及多轮追问下的上下文记忆能力。

总结： 没有覆盖核心问答对的测试，对于智能体来说就是盲人摸象。问答对集的质量和覆盖面，决定了系统上线的底线。

系统上线试运行（Beta 测试）后，真正的考验才刚开始。

无论你在实验室里测试得多么完美，真实用户永远会问出你意想不到的问题，或者用你完全没预料到的句式。智能体给出了错误、荒谬或答非所问的回答，这就是 Bad Case。

传统软件碰到 Bug 需要改代码，而智能体碰到 Bad Case，往往需要的是“数据飞轮”和“提示词工程”。

收集与归类： 每天把试运行产生的 Bad Case 拉出来。是因为知识库没覆盖？是因为意图识别错了？还是大模型出现了幻觉？
针对性优化：
- 如果是知识缺失： 补充相关文档到 RAG（检索增强生成）系统的知识库中。
- 如果是意图混淆： 优化 Prompt，或者在 Few-shot（少样本提示）中增加这个 Bad Case 作为反面教材。
- 如果是逻辑死循环： 调整 Agent 的工作流编排节点。
回归测试： 把解决后的 Bad Case 沉淀到第二步的“测试问答对”池子中，防止未来发生退化。

总结： 对话智能体不是“开发”出来的，而是“盘”出来的。试运行期间的 Bad Case 不是失败，而是系统进化的养料。