1. 项目概述：一个能自动分诊的AI智能体

如果你在B2B公司待过，肯定对那个“黑洞”般的公共收件箱不陌生。客户通过官网表单发来咨询、潜在合作伙伴发来邮件、或者有人在领英上发消息，这些信息最终都汇聚到一个地方，然后就开始漫长的等待。总得有人去点开它，花几分钟甚至更久去理解这封邮件到底在说什么，它属于销售、技术支持还是别的什么，最后再手动转发给对的人。这个过程，快则一小时，慢则一天，有时候消息就直接沉底，再无回音。这根本不是技术问题，而是一个典型的“分诊”流程瓶颈，它直接导致商机流失——每一个在收件箱里静置一小时的合格线索，都可能在这段时间里转向你的竞争对手。

我受够了在公司里目睹这种情况反复发生，于是花了一个周末的时间，构建了一个能够自动处理整个流程的AI智能体。现在，当一个新的请求进来时，这个智能体会自动解读内容、研究背后的公司、生成具体的后续行动建议，并精准地路由给团队中最合适的人。整个过程只需几秒钟，完全无需人工介入阅读、转发或猜测。这篇文章，我就来详细拆解我是如何一步步把它搭建起来的，以及在这个过程中踩过的坑和总结出的实战经验。

2. 核心架构设计：为什么是四步流水线？

在开始敲代码之前，最重要的决定是整体架构。我见过很多尝试用一个“超级提示词”让大模型一次性完成所有任务的方案，结果往往不尽如人意。模型要么顾此失彼，要么输出的格式混乱不堪，难以集成到下游系统。因此，我设计的核心思路是： 分而治之，结构化输出 。

整个智能体被设计成一个四步流水线，每一步都有明确、单一的职责，并产出严格结构化的JSON数据，作为下一步的输入。这样做有几个关键优势：

  1. 可预测性与可调试性 ：如果最终路由出错，我可以清晰地追溯到是分类错了，还是公司信息提取有误，抑或是匹配逻辑出了问题，而不是面对一个模糊的“模型没理解”的结论。
  2. 质量提升 ：让模型专注于一个任务，其输出质量远高于让它同时处理多个复杂任务。这就像让一个专家只做他最擅长的那部分工作。
  3. 系统集成友好 ：每一步的标准化JSON输出，使得整个流水线的结果可以像乐高积木一样，轻松嵌入到现有的CRM、工单系统、Notion或Slack中。

2.1 第一步：智能分类与摘要生成

这是流水线的入口，目标是将一段自由文本的客户咨询，转化为带有元数据的结构化信息。我需要的不是简单的关键词匹配（比如检测到“价格”就标记为销售），而是真正的语义理解。

实现细节 ： 我使用 Anthropic 的 Claude Sonnet 模型，通过一个精心设计的系统提示词来约束输出。这个提示词的核心是定义好一个JSON Schema，并要求模型必须严格遵守。以下是我实际使用的提示词框架（已做脱敏处理）：

system_prompt_classification = """
你是一个专业的商务请求分类助手。请严格分析用户提供的请求信息，并按照以下JSON格式输出，不要输出任何其他文字。

JSON格式必须包含以下字段：
- `category`: 字符串，必须是以下之一：`sales`(销售咨询), `support`(技术支持), `partnership`(合作提案), `press`(媒体问询), `other`(其他)。
- `urgency`: 字符串，必须是 `high`(高), `medium`(中), `low`(低)。判断依据：明确的时间要求、问题导致的业务中断程度、客户职位级别（如CEO/CTO直接联系通常更高）。
- `summary`: 字符串，用一句话（不超过30字）概括请求的核心内容。
- `language`: 字符串，请求使用的语言代码，如 `en`, `de`, `zh`。

请基于请求的整体语境和隐含意图进行分类，而非仅仅依赖个别关键词。
"""

当收到像“我们正在寻找自动化容器工作负载部署的解决方案，你们在受监管行业有经验吗？”这样的消息时，模型会输出：

{
  "category": "sales",
  "urgency": "medium",
  "summary": "某科技公司咨询自动化容器部署方案，并关注合规性经验。",
  "language": "zh"
}

实操心得 ：在定义分类时，一定要和业务团队对齐。我们最初的分类只有“销售”和“其他”，结果大量技术支持请求被误判。后来增加了“技术支持”和“合作提案”后，准确率大幅提升。 urgency 字段的判断逻辑也需要明确规则，比如“系统宕机”为高，“功能咨询”为低，避免模型主观臆断。

2.2 第二步：动态公司背景调研

分类之后，我们知道了“是什么事”，但还不知道“是谁的事”。传统的表单可能会让用户填写公司规模、行业，但用户经常不填或乱填。这里的解决方案是利用AI进行实时网络搜索，自动构建客户画像。

技术选型与实现 ： 我选择了 Tavily AI 作为网络搜索工具。它是一个为AI智能体优化的搜索引擎API，能返回结构化、简洁且相关性高的摘要，非常适合喂给大模型做分析。相比直接使用谷歌搜索API然后解析整个网页，Tavily省去了大量清洗和提取噪音的工作。

这一步的提示词会引导模型利用搜索到的信息来回答问题：

system_prompt_research = """
你是一个商业情报分析员。请根据提供的公司名称和可选的网络搜索信息，生成一份简要的公司背景报告。
输出必须是严格的JSON格式，包含以下字段：
- `company_name`: 字符串，确认的公司名称。
- `industry`: 字符串，所属行业。
- `estimated_size`: 字符串，如“1-10人”，“50-200人”，“1000人以上”。
- `core_business`: 字符串，简述其主要业务。
- `potential_needs`: 数组，基于其行业和业务，推测其可能面临的、与我方产品相关的挑战或需求（不超过3条）。
- `research_source`: 字符串，注明“tavily_search”或“model_knowledge”。
"""

如果Tavily搜索失败（比如公司太新或信息太少），系统会有一个降级策略：直接让模型基于其内部知识进行推测，并在 research_source 中标注。这对于知名大公司通常可行，但对初创公司效果会打折扣。

踩坑记录 ：最初我没有设置请求超时和失败回退机制，当Tavily API偶尔响应慢时，整个流水线就会卡住。后来我添加了异步请求与超时控制，并完善了降级逻辑，保证了系统的鲁棒性。另外，对于数据隐私要求极高的客户（如来自某些特定行业的咨询），我们在生产环境中添加了一个开关，可以手动或基于分类结果跳过公司调研步骤。

2.3 第三步：生成具体可执行的行动项

这是将“信息”转化为“任务”的关键一步。我们不要“请跟进”这种模糊的建议，而是要像资深销售或客服人员一样，给出下一步可以直接操作的、具体的工作指示。

提示词设计思路 ： 这一步的提示词会综合前两步的输出（分类结果、公司背景），要求模型扮演相应的团队角色（如销售总监、技术支持专家），并生成任务。例如，对于一个来自中型制造业公司的“销售”类咨询，且其需求涉及“合规”，提示词会要求：“作为销售负责人，请为该线索制定3个具体的后续行动项。”

输出示例：

{
  "action_items": [
    "准备一份针对制造业NIS2合规要求的解决方案概览文档。",
    "预约一次产品演示，重点展示自动化部署在隔离环境（如本地化部署或私有云）中的实现方式。",
    "询问对方当前容器化部署的具体流程和痛点，以评估定制化开发需求。"
  ]
}

经验之谈 ：行动项的数量和质量高度依赖于前两步输入信息的丰富程度。如果公司调研步骤只返回了很少的信息，行动项就会变得泛泛而谈。因此，确保前序步骤的质量是重中之重。我们也在不断优化提示词，加入更多引导，比如“行动项应尽可能引用客户原话中的具体需求点”。

2.4 第四步：基于角色画像的智能路由

这是最后一步，决定“事情交给谁”。我们摒弃了简单的按部门分配，而是为团队每个关键成员创建了一个动态的“技能与职责画像”。

团队画像数据结构 ： 画像存储在一个JSON文件或数据库中，结构如下。每个画像包含个人基本信息、专注领域以及一个具体处理的请求类型列表。

[
  {
    "id": "tech_lead",
    "name": "张三",
    "title": "技术负责人",
    "focus": "技术架构、AI模型实现、系统集成、基础设施",
    "handles": [
      "技术实现类问题",
      "AI与自动化项目咨询",
      "API与系统集成讨论",
      "技术可行性评估"
    ]
  },
  {
    "id": "business_lead",
    "name": "李四",
    "title": "业务负责人",
    "focus": "商业合作、大客户策略、市场拓展",
    "handles": [
      "战略合作伙伴洽谈",
      "大型企业采购询盘",
      "投资者与媒体关系",
      "其他角色无法明确覆盖的综合性事务"
    ]
  }
]

路由逻辑 ： 路由模块会将分类的 category 和 summary ，以及公司调研的 potential_needs ，与每个画像的 focus 和 handles 列表进行匹配。匹配算法不单纯是关键词匹配，而是通过一个嵌入模型（如OpenAI的 text-embedding-3-small ）计算请求文本与每个画像描述文本的语义相似度，选择相似度最高的画像。同时，也会结合一些硬性规则，比如 urgency 为“high”的请求可能会同时路由给技术负责人和业务负责人。

路由结果会附带一个解释：

分配理由：该请求涉及“自动化容器部署”和“合规性”，与张三（技术负责人）的专注领域“技术架构”、“基础设施”及处理类型“技术实现类问题”、“AI与自动化项目咨询”高度匹配。同时，客户来自受监管行业，可能需要技术方案满足特定合规要求。

注意事项 ：团队画像是需要持续维护的。当团队成员的职责发生变化，或者出现了新的业务类型时，必须及时更新画像。我们建立了一个简单的管理后台，允许团队负责人自行编辑自己的画像。此外，路由逻辑中加入了一个“默认兜底”角色（通常是团队管理者），用于处理那些匹配度都不高的请求，防止漏单。

3. 技术栈与实现细节

3.1 后端框架与API设计

我选择 Python + FastAPI 作为后端。FastAPI的异步支持、自动生成API文档以及数据验证（通过Pydantic）特性，让它非常适合构建这种需要频繁调用外部AI API的轻量级、高性能服务。

核心就是一个POST端点 /process-inbound ：

from pydantic import BaseModel
from typing import Optional

class InboundRequest(BaseModel):
    name: str
    email: str
    company: Optional[str] = None # 公司名可能为空
    message: str
    source: str = “web_form” # 来源：web_form, email, linkedin等

@app.post(“/process-inbound”)
async def process_inbound(request: InboundRequest):
    # 1. 分类
    classification_result = await classify_request(request)
    # 2. 公司调研（如果有公司名）
    research_result = await research_company(request.company) if request.company else None
    # 3. 生成行动项
    action_items_result = await generate_actions(classification_result, research_result)
    # 4. 路由
    routing_result = await route_request(classification_result, research_result, action_items_result)

    # 整合所有结果
    final_output = {
        “request_id”: generate_unique_id(),
        “classification”: classification_result,
        “company_research”: research_result,
        “action_items”: action_items_result,
        “routing”: routing_result,
        “timestamp”: datetime.utcnow().isoformat()
    }
    # 这里可以异步触发后续操作，如写入数据库、发送通知到Slack等
    await notify_team(final_output)
    return final_output

整个流水线使用 asyncio 实现异步调用，避免在等待某个AI API响应时阻塞整个进程，显著提升了吞吐量。

3.2 大模型交互与提示工程

与Claude API的交互是核心。我创建了一个通用的异步函数来处理所有需要调用模型的步骤：

import anthropic
import json

client = anthropic.AsyncAnthropic(api_key=“YOUR_API_KEY”)

async def call_claude(system_prompt: str, user_prompt: str, model=“claude-3-sonnet-20240229”) -> dict:
    try:
        message = await client.messages.create(
            model=model,
            max_tokens=1000,
            temperature=0.1, # 低温度保证输出稳定性
            system=system_prompt,
            messages=[{“role”: “user”, “content”: user_prompt}]
        )
        # 解析返回的JSON
        response_text = message.content[0].text
        # 有时模型会在JSON外加一层```json ```标记，需要处理
        if response_text.strip().startswith(“```json”):
            response_text = response_text.strip().lstrip(“```json”).rstrip(“```”)
        return json.loads(response_text.strip())
    except json.JSONDecodeError as e:
        # 记录错误并返回一个安全的默认结构
        logging.error(f“Failed to parse Claude response as JSON: {response_text}”)
        return {“error”: “Failed to parse model response”, “raw_text”: response_text}
    except Exception as e:
        logging.error(f“Error calling Claude API: {e}”)
        raise

关键点 ：

  • 温度（Temperature） ：设置为较低的0.1，旨在获得更确定、更一致的结构化输出，减少随机性。
  • 错误处理 ：必须对模型可能返回的非JSON内容或格式错误的JSON进行健壮性处理。在生产环境中，我们加入了重试机制和更完善的降级策略。
  • Token管理 ：注意提示词和消息的长度，特别是公司调研步骤，可能会包含较长的网络搜索结果摘要。需要监控token使用量以控制成本。

3.3 外部服务集成：Tavily搜索

Tavily的集成非常简单：

from tavily import AsyncTavilyClient

tavily_client = AsyncTavilyClient(api_key=“YOUR_TAVILY_KEY”)

async def search_company(company_name: str):
    try:
        # 设置超时，避免长时间等待
        response = await asyncio.wait_for(
            tavily_client.search(company_name, max_results=3, include_answer=True),
            timeout=10.0
        )
        # Tavily返回的结果包含‘answer’字段，是一个简洁的摘要
        if response and response.get(‘answer’):
            return response[‘answer’]
        else:
            return None
    except asyncio.TimeoutError:
        logging.warning(f“Tavily search timeout for {company_name}”)
        return None
    except Exception as e:
        logging.error(f“Tavily search error for {company_name}: {e}”)
        return None

将搜索得到的摘要（ answer ）连同原始问题一起放入提示词中，引导模型进行信息提取和总结。

4. 生产环境部署与集成考量

一个不能融入现有工作流的AI工具是没有生命力的。这个智能体的设计初衷就是“无头”的，即它只提供结构化的JSON输出，如何展示和后续处理交给现有系统。

4.1 与现有工具的连接

我们目前主要集成了两个地方：

  1. Slack通知 ：当智能体处理完一个请求后，会向一个指定的Slack频道发送一条格式化的消息。消息卡片中包含了分类、摘要、分配对象和一个直接跳转到CRM创建页面的链接。
  2. CRM（我们使用HubSpot）创建联系人/工单 ：通过调用HubSpot的API，将 name , email , company 以及智能体生成的 summary 和 action_items 作为备注，自动创建一个新的联系人记录或工单，并打上相应的标签（如 sales_inquiry , high_priority ）。

集成代码示例（Slack） ：

import httpx

async def notify_to_slack(final_output: dict):
    slack_webhook_url = “YOUR_SLACK_WEBHOOK_URL”
    message_block = {
        “blocks”: [
            {
                “type”: “header”,
                “text”: {“type”: “plain_text”, “text”: f“📥 新请求已分配: {final_output[‘routing’][‘assignee_name’]}”}
            },
            {
                “type”: “section”,
                “fields”: [
                    {“type”: “mrkdwn”, “text”: f“*来自:*\n{final_output[‘classification’][‘summary’]}”},
                    {“type”: “mrkdwn”, “text”: f“*公司:*\n{final_output[‘company_research’].get(‘company_name’, ‘N/A’)}”},
                    {“type”: “mrkdwn”, “text”: f“*优先级:*\n{final_output[‘classification’][‘urgency’]}”},
                    {“type”: “mrkdwn”, “text”: f“*建议行动:*\n” + “\n”.join([f“• {item}” for item in final_output[‘action_items’][‘action_items’]])}
                ]
            }
        ]
    }
    async with httpx.AsyncClient() as client:
        await client.post(slack_webhook_url, json=message_block)

4.2 监控、日志与成本控制

在AI项目中，可观测性至关重要。

  • 日志 ：记录每一个请求的原始输入、每一步的中间输出、最终结果以及API调用耗时和Token使用量。这不仅是调试的需要，也是优化提示词和分析模型性能的基础。
  • 成本监控 ：由于每一步都调用Claude API，并且可能调用Tavily，成本会随着请求量增长。我们设置了每日预算告警，并正在考虑对低优先级的请求使用更便宜的模型（如Haiku）进行分类步骤。
  • 人工审核队列 ：我们设置了一个仪表盘，展示所有被智能体处理的请求，并标记出“低置信度”的分配（例如，路由匹配分数低于某个阈值）。团队成员可以定期检查这个队列，进行人工校正，这些校正数据反过来又可以用于优化模型。

5. 遇到的挑战与解决方案

5.1 模型输出的不稳定性

尽管使用了低温度和严格的JSON提示，模型偶尔还是会输出格式错误的JSON，或者在字段中返回 null 。

解决方案 ：

  1. 强化提示词 ：在系统提示词中明确强调“输出必须是有效的JSON，且所有字段都必须存在”。使用类似“你必须用双引号包裹所有键和字符串值”的指令。
  2. 后置验证与清洗 ：在解析JSON后，增加一个数据清洗层，检查必填字段是否存在、类型是否正确，并为缺失字段填充默认值（如将 null 的 urgency 设为“medium”）。
  3. 重试机制 ：对于JSON解析失败的请求，不是直接失败，而是记录错误并使用一个更简单、约束性更强的提示词进行重试。

5.2 对模糊或简短请求的处理

客户可能只写一句“嗨，我想了解更多信息”。这种请求缺乏分类和调研所需的上下文。

解决方案 ：

  1. 请求丰富化 ：在调用分类模型前，先尝试用一个小模型（或规则）判断消息长度和内容密度。如果过于简短，可以自动在提示词中补充上下文，例如：“以下是一条来自网站联系表单的留言，留言者可能不愿提供过多细节。请根据有限信息尽力判断。”
  2. 默认路由规则 ：为分类结果为“other”或“summary”过于模糊的请求，设置默认路由规则（如直接分配给销售开发代表进行初步筛选）。
  3. 设计引导式表单 ：在前端联系表单上做优化，通过下拉选择或必填字段引导用户提供更结构化信息（如“咨询类型”），这可以作为AI分析的补充输入，大幅提升首步分类准确率。

5.3 隐私与数据安全

公司调研涉及搜索外部公司信息，而处理的消息内容可能包含客户敏感数据。

解决方案 ：

  1. 数据匿名化处理 ：在日志和调试信息中，对所有个人身份信息（PII）如邮箱、姓名进行脱敏。
  2. API密钥管理 ：所有API密钥（Anthropic, Tavily）都通过环境变量或秘密管理服务注入，绝不硬编码在代码中。
  3. 合规性考量 ：在隐私政策中明确说明可能会使用AI工具处理咨询信息以改善服务。对于明确要求数据不出境的客户，可以配置关闭公司调研功能。

6. 未来演进方向

这个项目远未结束，它只是一个起点。接下来我计划从两个方向进行深化：

6.1 端到端自动化集成

目前还需要手动向API发送请求。下一步是构建连接器，直接监听公司的共享邮箱（如通过Microsoft Graph API）或官网表单的后台数据库。让智能体以定时任务（例如每5分钟）的方式自动抓取新消息进行处理，实现真正的“无人值守”分诊。

6.2 构建反馈学习闭环

这是最具潜力的部分。目前智能体只负责“建议”，并不知道后续发生了什么。计划建立一个反馈机制：

  1. 当被分配者处理完一个请求（如在CRM中标记为“已联系”、“已解决”），系统会捕获这个结果。
  2. 将这些结果（包括最终是谁处理的、用了多长时间解决、是否成单等）与智能体最初的分类、路由建议进行关联。
  3. 定期用这些“输入-输出-结果”数据对微调一个轻量级模型，或用于优化路由匹配的权重参数。

例如，如果系统发现来自“金融科技”行业的“技术支持”类请求，如果直接路由给“技术负责人”而非一线支持，解决速度更快、客户满意度更高，那么路由算法就会逐渐调整，给这类请求匹配“技术负责人”时赋予更高的权重。

更长远的愿景是，让智能体在学习了足够多的成功回复模板后，能够为某些高确定性、低复杂度的请求（如“请发我一份产品资料”）自动生成回复草稿，交由人工审核后发送，从而将自动化从“分诊”延伸到“初步应答”，进一步解放团队生产力。

构建这样一个AI智能体的过程，更像是在设计一个懂得你业务逻辑的数字化同事。它不需要理解一切，但需要在关键节点上做出可靠、可解释的决策。从最初的一个简单分类脚本，到如今这个四步流水线，最大的感悟是： 复杂的智能往往源于简单、模块化且结构清晰的步骤组合 。与其追求一个全能但不可控的“黑箱”，不如拆解流程，让AI在每个它擅长的子任务上发挥价值，并通过严谨的工程化将其串联起来。这个项目不仅解决了我们公司的收件箱混乱问题，更重要的是为如何将大语言模型稳妥、有效地融入实际业务流程，提供了一个可复用的蓝本。

# AI智能体
Logo
智能体开发者社区

中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。

更多推荐

cover

ChatGPT怎么用？2026年三种路径对比与GPT-5.5新功能详解

avatar 智能体开发者社区

数据集成与应用集成为什么要“双轨并行”？2026年企业混合集成架构深度设计_

企业数据集成与应用集成"双轨分离"导致效率低下、成本倍增，提出双轨融合的本质是统一连接层、元数据治理与可观测性，而非简单合并引擎。2026年，AI Agent接入、CDC与API边界消融及国产化替换正加速融合趋势，"混合集成平台"将成为企业iPaaS选型新基准。

avatar 智能体开发者社区
cover

这个开源项目有点狠：让 AI Agent 自己选模型、自己付钱，还能把 LLM 成本打下来 90%+

avatar 智能体开发者社区