药明生物 Pre-sales Agent：从业务问题到 Agent 落地的产品思考

一个被简化的需求

2025 年 11 月，我在径硕科技担任 AI 产品实习生，接到的第一个项目是药明生物官网的 AI Agent。

药明生物是全球领先的生物医药 CDMO 企业，官网面向全球访客。业务方给出的需求看起来很简单：

在官网上部署一个 24 小时 AI 客服，自动回答访客问题。

如果只看这句话，这个项目没什么难的。找一个 FAQ 列表，搭一个问答机器人，上线，完事。

但我在做需求分析的时候，越挖越觉得这个需求被严重简化了。

表面需求 vs 真实业务需求

我花了大概两周时间和业务方、售前团队做深度访谈。聊完之后，我把"24h AI 客服"这个一句话需求，拆成了五个真实的业务问题：

问题一：跨时区售前响应成本高。

药明生物是全球化企业，访客来自欧美、亚太各个时区。海外访客在北京时间凌晨咨询，售前团队第二天上班才能回，延迟可达 12 小时以上。这不是"回答快不快"的问题，是"人在不在"的问题。

问题二：访客意向难以判断。

官网每天都有大量浏览，但哪些访客是潜在客户，哪些只是查资料的同行或学生，完全分不出来。流量数据是有了，但转化不成结构化的销售线索。

问题三：产品信息分散。

产品文档、FAQ、案例库、技术白皮书，内容散落在不同页面和系统中。访客想了解某个服务，得自己翻找，效率很低。售前团队也经常要重复回答同样的基础问题。

问题四：重复性问题消耗人力。

"你们做什么的""有哪些服务""怎么联系"——这些问题每天占用售前团队大量时间，导致真正有高价值客户的咨询反而得不到及时响应。

问题五：无法解决的问题没有沉淀。

售前团队接到的疑难问题，处理完就过去了，没有形成知识沉淀。下次遇到类似问题，还是要从头来一遍。

你看，"24h AI 客服"这五个字背后，藏着五个不同层次的业务问题。如果只按字面需求做一个问答机器人，可能只解决了问题三和问题四的一部分，剩下三个根本没碰。

为什么用 Agent 而不是传统 FAQ

这是我在做产品方案时面临的第一个决策。

传统 FAQ 机器人的逻辑是：用户选一个问题 → 系统返回预设答案 → 结束。优点是简单、可控、不会出错。缺点是它只能处理"你问我答"的场景，一旦用户的真实需求是"我想了解你们能不能解决我的问题"，FAQ 就力不从心了。

B2B 售前咨询有一个特点：用户的问题具有开放性和多轮属性。一个访客进来，通常不是问一个孤立的问题就走，而是一连串的追问：

"你们提供哪些服务？" → "细胞系开发你们做吗？" → "产能有多大？" → "我们有个 Phase 2 的项目，怎么对接？"

这种多轮、上下文关联、逐步深入真实需求的对话模式，不是 FAQ 能覆盖的。它需要一个能理解上下文、能追问、能判断意图的 Agent。

所以我决定用 Agent 而不是 FAQ。但这个决策不是免费的——Agent 的复杂度、不可控性和维护成本远高于 FAQ。你选择 Agent，就要接受它可能答错、可能跑偏、可能在某些场景下不如一个简单的列表页好用。

产品决策的本质不是选"更好的方案"，而是选"更适合当前业务问题的方案，并接受它的代价"。

为什么引入 RAG

第二个决策是知识库方案。

药明生物的产品信息有很强的专业性：生物药发现、开发、生产，每个环节都有大量专业术语和文档。如果让 LLM 直接回答，会有几个问题：

• 幻觉风险：LLM 可能编造不存在的服务或数据，在企业售前场景下是不可接受的
• 内容时效性：产品和服务会更新，如果答案写死在 Prompt 里，每次更新都要改 Prompt
• 专业性不足：通用 LLM 对生物医药行业的理解有限，回答容易"看似专业实则跑偏"

RAG（检索增强生成）解决的是这些问题。核心思路是：答案不靠 LLM 自己"想"，而是先从受控的知识库里检索相关内容，再让 LLM 基于这些内容组织语言。

这样做了之后，有三个好处：

1. 答案有据可查：每条回答背后都有知识库来源，降低幻觉风险
2. 知识库可独立维护：产品文档更新了，只需要更新知识库，不需要改 Prompt 或重新训练模型
3. 可控性强：哪些内容可以被检索到、哪些不能，由知识库决定，而不是由模型决定

RAG 不是万能的——检索质量、知识库结构化程度、chunk 大小和切分策略都会影响效果。但对于企业级场景，它是目前最务实的方案。

Agent Workflow：从意图识别到人工转接

方案确定后，我设计了完整的 Agent 工作流。不是从技术实现出发，而是从用户旅程出发——一个访客从进入官网到最终留资或离开，中间会经历哪些环节。

访客发起咨询
  ↓
意图识别：判断用户咨询类型
  ├── 产品咨询 → 知识库检索 → 回答生成
  ├── 报价/合同 → 标记高意向 → 直转销售
  ├── 技术支持 → 知识库检索 → 回答生成
  └── 其他 → 通用回答 + 引导
  ↓
多轮追问：识别后续问题，维持对话上下文
  ↓
意向判断：分析用户表达，评估销售线索等级
  ├── 高意向 → 收集关键信息 → 转接销售
  ├── 中意向 → 推荐相关内容 → 软性引导
  └── 低意向 → 正常回答，不强推留资
  ↓
人工转接（触发条件满足时）
  → 推送对话摘要给销售团队

这个流程里有几个设计决策值得展开说。

意图识别不是一锤子买卖

用户第一句话的意图，不一定代表真实需求。有人说"你们是做什么的"，可能只是随便看看，也可能是在做供应商调研的前一步。

所以我设计了动态意图识别：每轮对话后更新一次意图判断，随着对话深入，意图判断会越来越准确。这比第一句话就定死的方案更接近真实售前顾问的工作方式。

人工转接的触发条件

什么时候应该把对话从 Agent 切换给真人？我定了三类触发条件：

1. Agent 连续两次无法给出满意回答——说明问题超出 Agent 能力范围
2. 用户明确表达购买意向或要求对接销售——说明用户已经准备好了
3. 问题涉及报价、合同等敏感内容——这类内容不适合 AI 直接回答

转接的时候不是"甩手"给销售，而是自动生成对话摘要和用户画像，让接手的销售快速了解上下文。这很重要——如果销售接过来还要从头问一遍，用户体验反而更差了。

意向分层走不同路径

这是我后来复盘觉得最重要的一点（上一篇复盘文章里详细讲了），但在初版设计时做得不够好。

理想情况下，不同意向的用户应该走不同的对话路径：

初版 Agent 的问题在于：所有用户共用一套话术，面对同一个留资 CTA。这导致低意向用户被吓跑，高意向用户被耽误。后来我们做了迭代，根据对话中的信号动态调整策略。

我在项目里做了什么

作为 AI 产品实习生，我的角色不是"写代码的实现者"，而是"从需求到落地的推进者"。具体来说：

需求分析：和业务方、售前团队深度访谈，从"24h 客服"一句话需求拆解出五个业务问题。

Agent 工作流设计：从意图识别到人工转接的完整流程，包括动态意图更新、分层路径设计、转接条件定义。

知识库搭建：产品文档结构化、FAQ 体系建设、检索策略设计。这部分最耗时——不是"有没有文档"的问题，是"文档适不适合被检索"的问题。很多产品文档是给人看的 PDF，不是给机器查的结构化数据，光整理就花了大量时间。

Prompt 设计：多轮对话模板、语气控制（要专业但不生硬）、答案格式规范（什么时候给列表，什么时候给段落）。

数据跟踪与迭代：上线后持续跟踪转化漏斗，分析对话数据，优化流程和知识库内容。

怎么衡量 Agent 是否成功

项目上线后，我定的核心跟踪指标是这几个：

这几个指标不是孤立的，要结合起来看。比如首次解决率高但线索获取量低，说明 Agent 很会回答问题但不会做商业转化——这恰好就是我们后来复盘发现的真实问题。（详见我之前写的转化分析文章）

回头看

如果重新做一遍，我会改变几个做法：

第一，先想清楚衡量标准再开始做。 我们上线后才发现手里的数据不够细，只有访问量、对话数、线索数三个数字，中间漏斗全是黑箱。如果一开始就把埋点方案设计好，后续的迭代会精准得多。

第二，Agent 不只是"会聊天的机器人"。 做完之后我最大的感触是，Agent 的核心不是"回答得准不准"，而是"能不能把对话往业务方向推进"。一个只会回答问题的 Agent 和一个能识别意图、判断意向、分层推进的 Agent，完全是两个产品。

第三，产品决策要写下来。 当时做决策的时候讨论了很多，但没有形成文档。后来复盘的时候，很多"为什么这么设计"的回答只能靠记忆。如果每个关键决策都有一页纸记录（为什么选 Agent 不选 FAQ、为什么用 RAG、转接条件怎么定），后续迭代和团队协作会顺畅很多。

这些经验后来直接影响了我在 OpenClaw 和 Inrepli 项目中的工作方式。特别是"先想清楚衡量标准"这一点，在 Inrepli 项目里我一开始就建了完整的测试和验收体系，就是因为在这个项目里吃过亏。

做产品就是这样一个项目喂一个项目，每个项目踩的坑都会变成下一个项目的起点。