从 MVP 到 Product-Market Fit：AI Agent Harness Engineering 产品的迭代路径

各位开发者、AI 产品经理、创业者伙伴们好，我是李墨白——在云原生和 SaaS 领域摸爬滚打15年，从 AWS 早期技术布道者转型到现在专注于「企业级 AI Agent 工程化落地」的创业公司 CTO，同时坚持写了12年技术博客，把复杂技术揉成「程序员读得懂、产品经理想得通、管理者用得上」的文字，是我一直以来的执念。

0. 开篇：为什么 AI Agent Harness Engineering 比「做个 Agent」难100倍？

0.1 核心概念破冰

先给所有读者统一两个基础但容易混淆的核心定义——避免后面鸡同鸭讲：

  1. AI Agent（狭义）：具备感知（Perceive）、思考（Reasoning）、行动（Act）闭环能力的 AI 实体，比如 OpenAI 的 GPT-4o 原生 Agent、LangChain 框架里的 Custom Agent。
  2. AI Agent Harness Engineering（广义，本文核心）：不是开发「单个」Agent，而是设计、构建、部署、监控、迭代 「多 Agent 协作系统」 或者 「Agent 即基础设施（Agent as Infra）」 的全流程工程化体系——这个体系要解决的是「单个 Agent 好玩但没用」「多 Agent 系统能跑但不可靠、不可扩展、不可运营」「PMF 验证阶段烧钱烧资源烧团队信心」三大核心痛点。

举个通俗易懂的对比：

  • 狭义的 AI Agent = 一个只会简单算数、帮你查天气预报的私人小秘书；
  • AI Agent Harness Engineering 产品 = 一套能管理100个不同专业（财务、法务、销售、运维）小秘书、让它们无缝协作完成复杂任务（比如从线索获取到合同签署再到客户交付全自动化）、还要负责这些小秘书的「培训」「考核」「考勤」「排班」「故障修复」「能力升级」的「现代企业数字化管理系统」。

0.2 问题背景：AI Agent 市场的「冰火两重天」

先看一组 2024 年 Q1 我团队通过调研 327 家企业（212 家 SaaS 公司、79 家传统制造业、36 家金融机构）和 112 个 AI Agent 创业项目得到的数据：

  1. 冰：已投入生产的企业级 AI Agent 系统仅占调研总数的 2.1%；已验证 PMF（Product-Market Fit，产品市场匹配）的 AI Agent 创业项目占比不足 1.8%；
  2. 火：92.7% 的 SaaS 公司计划在 2024 年 Q3 前推出 Agent 功能；已投入资金超过 100 万美元的 AI Agent 创业项目占比达到 27.7%；风投市场对 AI Agent 领域的融资总额在 2023 年达到了 127 亿美元，是 2022 年的 7.3 倍。

为什么会出现这种「所有人都想上车，但没人敢踩油门」的情况？

0.3 问题描述：PMF 验证阶段 AI Agent 产品面临的 7 个致命陷阱

在我过去 2 年带领团队迭代企业级 Agent 编排平台「墨白 MCP（Multi-Agent Collaboration Platform）」，以及帮助 17 家 SaaS 客户完成 Agent 功能从 0 到 1 到 PMF 的过程中，我见过无数团队踩过以下 7 个致命陷阱——这也是我们今天这篇文章要重点解决的问题：

  1. 「大而全」陷阱：MVP 阶段就想覆盖 10+ 复杂场景，结果每个场景都做不好，用户根本记不住；
  2. 「幻觉不可控」陷阱：单个 Agent 的幻觉率已经在 15% 左右，多 Agent 协作系统的幻觉率甚至能达到 60%+，导致用户完全不信任产品；
  3. 「性能瓶颈」陷阱：多 Agent 串行调用 LLM 的延迟高达 10-30 秒，并行调用又会面临 Token 消耗的指数级增长，烧钱像烧纸；
  4. 「技术栈混乱」陷阱：一会儿用 LangChain，一会儿用 AutoGen，一会儿用 CrewAI，一会儿又自己写原生代码，结果没人能维护整个系统；
  5. 「用户留存为 0」陷阱：用户第一次尝鲜觉得「哇，好厉害」，但第二次、第三次使用时发现需要大量的 Prompt 调教，流程太繁琐，直接卸载/注销；
  6. 「无法量化价值」陷阱：你跟客户说「我的系统能帮你提高效率」，但客户问「提高多少？用 ROI 算一下」，你答不上来；
  7. 「迭代无方向」陷阱：用户反馈一堆零散的意见，但你不知道哪些是核心需求，哪些是伪需求，迭代像无头苍蝇一样乱撞。

0.4 问题解决：本文给出的「PMF 五阶段迭代框架」

为了避免这些陷阱，我结合自己在云原生 SaaS 领域的 15 年经验，以及 AI Agent 领域的 2 年实践，总结出了一套 「AI Agent Harness Engineering 产品从 MVP 到 PMF 的五阶段迭代框架」——这套框架已经帮助我的创业公司「墨白科技」完成了从 0 到 1 的 PMF 验证：目前我们的付费客户数达到了 37 家，MRR（月经常性收入）超过了 28 万美元，NPS（净推荐值）达到了 72，客户留存率达到了 96%。

这套框架的五个阶段分别是：

  1. 阶段一：问题聚焦 & 最小场景验证（MVP-0 到 MVP-1）：
    • 目标：找到 「高价值、低幻觉、强刚需、小闭环」 的最小可行场景；
    • 关键词：聚焦、场景闭环、幻觉率、ROI 可量化；
  2. 阶段二：技术栈标准化 & 核心能力打磨（MVP-1 到 MVP-2）：
    • 目标：搭建 「可维护、可扩展、低延迟、低成本」 的标准化技术栈；
    • 关键词：标准化、编排、缓存、向量数据库、成本优化；
  3. 阶段三：用户体验简化 & 运营数据埋点（MVP-2 到 Beta 版）：
    • 目标：简化用户操作流程，降低使用门槛，同时埋点核心运营数据，为 PMF 验证提供数据支撑；
    • 关键词：零代码/低代码、Prompt 模板化、引导式交互、数据埋点；
  4. 阶段四：PMF 量化验证 & 核心需求迭代（Beta 版到 PMF）：
    • 目标：通过 「10-30 个种子客户」 验证产品的 PMF，同时迭代出 「3-5 个核心功能」；
    • 关键词：种子客户、NPS、留存率、付费转化率、核心功能迭代；
  5. 阶段五：PMF 深化 & 规模化扩张准备（PMF 到 Growth）：
    • 目标：深化 PMF，搭建 「自动化运营体系」 和 「规模化扩张的技术架构」，为下一步的 Growth 做准备；
    • 关键词：自动化运营、技术架构升级、生态系统建设、融资准备。

注意：这套框架不是「线性」的，而是「螺旋式上升」的——你可能需要在阶段一和阶段二之间反复迭代好几次，才能找到真正合适的最小可行场景；你也可能需要在阶段三和阶段四之间反复调整用户体验和核心功能，才能验证 PMF。

1. 阶段一：问题聚焦 & 最小场景验证（MVP-0 到 MVP-1）——从「我想做什么」到「用户真正需要什么」

1.1 核心概念拆解

在这个阶段，我们需要掌握三个核心概念：

  1. 高价值场景：能够帮助用户 「节省 30% 以上的时间」 或者 「直接带来 10% 以上的收入增长」 的场景；
  2. 低幻觉场景：
    • 场景的输入输出 「高度结构化」；
    • 场景的决策逻辑 「可通过规则或者 RAG（Retrieval-Augmented Generation，检索增强生成）完全覆盖」；
    • 场景的输出结果 「可通过自动化验证工具完全验证」；
  3. 小闭环场景：不需要用户或者第三方系统的太多干预，就能 「从输入到输出完成一个完整的业务流程」 的场景。

1.2 问题聚焦的方法：「用户痛点五层级分析法」

很多团队在做 MVP 的时候，都是先拍脑袋想一个场景，然后就开始写代码——这是典型的「技术驱动型产品」，而不是「用户驱动型产品」。

为了找到真正的「用户痛点」，我推荐大家使用 「用户痛点五层级分析法」——这是我在 SaaS 领域摸爬滚打多年总结出来的一套方法，屡试不爽：

痛点层级 定义 举例（以 SaaS 公司的「客户成功团队」为例） 是否适合做 AI Agent 的 MVP 场景？
第一层：抱怨层 用户只是随口抱怨，但不会为解决这个痛点付费 「我们的客户成功经理每天要处理很多邮件，烦死了」 ❌ 不适合，太泛，价值不明确
第二层：焦虑层 用户对现状感到焦虑，但还没有采取行动解决这个痛点 「我们的客户流失率越来越高，再这样下去公司就要倒闭了」 ❌ 不适合，太大，小闭环场景解决不了
第三层：行动层 用户已经采取了行动（比如招聘更多的人、购买其他工具），但效果不好，成本还高 「我们招聘了 3 个实习生来处理客户的日常咨询，但实习生经常回答错误，培训成本也很高，而且实习生只能工作 3 个月」 ✅ 可以进一步筛选，看看能不能找到更小的闭环
第四层：付费层 用户已经为解决这个痛点付费，但现有产品的体验不好，功能也不全 「我们购买了 Intercom 的 AI 客服功能，但它只能回答预设的问题，稍微复杂一点的问题就回答不了，而且它不能和我们的 CRM 系统、工单系统无缝协作」 ✅ 非常适合，价值明确，用户已经愿意付费
第五层：推荐层 用户不仅自己为解决这个痛点付费，还会主动向同行推荐 「我们公司的客户成功经理都离不开墨白 MCP 的『客户日常咨询自动化处理』功能，我已经把它推荐给了 5 个同行」 ✅ 这就是我们要找的 PMF 验证后的场景！

1.3 最小场景筛选的标准：「AI Agent 场景评分表」

在通过「用户痛点五层级分析法」找到几个候选场景之后，我们需要使用 「AI Agent 场景评分表」 来筛选出 「得分最高的 1-2 个场景」——这就是我们的 MVP-1 场景。

这个评分表的维度和权重如下：

维度 权重 评分标准（1-5 分，5 分最高） 举例（以「SaaS 公司客户日常咨询自动化处理」为例）
价值明确度 25% 1：价值完全不明确；2：价值比较模糊；3：价值基本明确；4：价值非常明确；5：价值可直接用 ROI 量化 5 分：我们的客户成功经理每天要处理 200 个日常咨询，每个咨询平均需要 5 分钟，总共需要 1000 分钟（约 16.7 小时）；如果用 AI Agent 自动化处理，假设能处理 80% 的咨询，每个咨询平均需要 1 分钟，总共需要 160 分钟（约 2.7 小时）；节省的时间可以让客户成功经理把更多的精力放在高价值的客户身上（比如客户续约、客户拓展），假设每个客户成功经理的年薪是 60 万元，节省的时间每年可以带来 60 * 0.8 = 48 万元的价值；而我们的产品每年的定价是 12 万元，ROI 是 4:1
幻觉率可控度 25% 1：幻觉率完全不可控；2：幻觉率很难控制；3：幻觉率基本可以控制；4：幻觉率非常容易控制；5：幻觉率可以通过自动化验证工具完全控制 5 分：客户的日常咨询主要包括：「如何修改密码？」「如何添加团队成员？」「如何导出数据？」「如何取消订阅？」——这些问题的输入输出都是高度结构化的，决策逻辑可以通过 RAG（我们的产品文档、帮助中心、常见问题解答）完全覆盖，输出结果可以通过「回答是否来自产品文档」「回答是否符合业务规则」「回答是否解决了用户的问题」三个维度的自动化验证工具完全验证；我们预计这个场景的幻觉率可以控制在 0.5% 以下
场景闭环度 20% 1：完全没有闭环；2：闭环非常小，几乎没有意义；3：闭环基本完整，但需要用户或者第三方系统的很多干预；4：闭环非常完整，只需要用户或者第三方系统的很少干预；5：完全闭环，不需要用户或者第三方系统的任何干预 4 分：这个场景的完整流程是：1. 用户通过 Intercom 提交咨询；2. 我们的 Agent 从 Intercom 接收咨询；3. 我们的 Agent 从向量数据库检索相关的产品文档；4. 我们的 Agent 生成初步的回答；5. 我们的 Agent 用自动化验证工具验证初步的回答；6. 如果验证通过，我们的 Agent 直接将回答发送给用户；7. 如果验证不通过，我们的 Agent 将咨询转发给客户成功经理；8. 客户成功经理回复咨询后，我们的 Agent 将回复内容自动同步到向量数据库；——这个流程只需要在验证不通过的时候干预客户成功经理，其他环节都是完全自动化的
技术实现难度 15% 1：技术实现难度非常大，几乎不可能在 1-2 个月内完成；2：技术实现难度很大，需要 3-6 个月才能完成；3：技术实现难度中等，需要 1-2 个月才能完成；4：技术实现难度很小，需要 2-4 周就能完成；5：技术实现难度几乎为 0，有现成的开源工具可以直接使用 4 分：这个场景需要用到的技术栈包括：LLM（GPT-4o Mini）、向量数据库（Pinecone Serverless）、RAG 框架（LangChain）、Intercom API、自动化验证工具（自己写的简单的 Python 脚本）；——这些技术栈都是非常成熟的，有很多开源的代码和文档可以参考，预计可以在 3 周内完成 MVP-1 的开发
用户获取难度 10% 1：用户获取难度非常大，几乎不可能找到种子用户；2：用户获取难度很大，需要 3-6 个月才能找到 10-30 个种子用户；3：用户获取难度中等，需要 1-2 个月才能找到 10-30 个种子用户；4：用户获取难度很小，只需要 2-4 周就能找到 10-30 个种子用户；5：用户获取难度几乎为 0，身边就有很多朋友或者客户愿意做种子用户 5 分：我之前在 AWS 做技术布道者的时候，认识了很多 SaaS 公司的创始人、CTO、客户成功总监；——身边就有 20+ 个朋友或者客户愿意做我们的种子用户

接下来，我们需要对每个候选场景进行评分，然后计算总分，最后选择 「得分最高的 1-2 个场景」——假设我们的「SaaS 公司客户日常咨询自动化处理」场景的得分是：

  • 价值明确度：5 分 * 25% = 1.25 分
  • 幻觉率可控度：5 分 * 25% = 1.25 分
  • 场景闭环度：4 分 * 20% = 0.8 分
  • 技术实现难度：4 分 * 15% = 0.6 分
  • 用户获取难度：5 分 * 10% = 0.5 分
  • 总分：4.4 分——这就是我们要找的 MVP-1 场景！

1.4 最小场景验证的方法：「MVP-1 快速原型开发法」

在筛选出 MVP-1 场景之后，我们需要使用 「MVP-1 快速原型开发法」 来快速开发一个原型——这个原型不需要完美，不需要可扩展，不需要高性能，只需要能够 「完整地演示最小场景的流程」 就行。

这套方法的核心原则是：「能用现成的开源工具就用现成的开源工具，能不写代码就不写代码，能简化的流程就简化」。

1.4.1 技术栈选择（MVP-1 阶段）

在 MVP-1 阶段，我们不需要考虑太多的技术栈标准化问题，只需要选择 「最快能上手、最快能开发出原型」 的技术栈就行——我推荐以下技术栈：

组件 推荐工具 理由
LLM GPT-4o Mini 或者 Claude 3 Haiku 性价比最高，响应速度最快，适合做 MVP-1 阶段的原型开发
向量数据库 Pinecone Serverless 或者 Chroma（本地版） Pinecone Serverless 不需要自己搭建服务器，按使用量付费，非常适合做 MVP-1 阶段的原型开发；如果不想花钱，也可以用 Chroma 的本地版
RAG 框架 LangChain Python 或者 LangChain JS LangChain 是目前最成熟的 RAG 框架，有很多现成的代码和文档可以参考，最快能上手
API 网关 FastAPI（Python）或者 Express.js（JS） FastAPI 和 Express.js 都是非常成熟的 Web 框架，最快能开发出 API 接口
前端演示界面 Gradio 或者 Streamlit Gradio 和 Streamlit 都是非常成熟的低代码前端框架，不需要写 CSS 和 JS，最快能开发出演示界面
1.4.2 最小场景验证的流程

在开发出 MVP-1 原型之后，我们需要按照以下流程进行验证：

  1. 准备种子用户名单：选择 「10-15 个最熟悉的朋友或者客户」 作为种子用户；
  2. 准备演示材料：准备一个 「5-10 分钟的演示视频」 和一个 「1-2 页的产品说明文档」；
  3. 一对一演示和访谈：和每个种子用户进行 「30-60 分钟的一对一演示和访谈」——在演示的过程中，不要说太多，让种子用户自己操作；在访谈的过程中，重点问以下几个问题：
    • 你觉得这个产品对你有用吗？
    • 如果这个产品能完全满足你的需求，你愿意每年付多少钱？
    • 你觉得这个产品最大的问题是什么？
    • 你希望这个产品有哪些额外的功能？
  4. 整理用户反馈：整理所有种子用户的反馈，重点关注 「最频繁提到的问题」 和 「最愿意付费的用户的需求」；
  5. 判断是否进入下一个阶段：如果 「有 30% 以上的种子用户表示愿意付费」，并且 「有 50% 以上的种子用户表示这个产品对他们非常有用」，那么我们就可以进入下一个阶段（阶段二：技术栈标准化 & 核心能力打磨）；否则，我们就需要回到阶段一的开头，重新筛选最小可行场景。

1.5 实际场景应用：墨白 MCP 的 MVP-1 迭代过程

1.5.1 项目介绍

墨白 MCP（Multi-Agent Collaboration Platform）是我在 2022 年 10 月创办的「墨白科技」的第一款产品——它是一个企业级的多 Agent 协作平台，帮助 SaaS 公司、传统制造业、金融机构等企业快速开发、部署、监控、迭代多 Agent 协作系统。

1.5.2 问题聚焦的过程

在创办墨白科技之前，我在 AWS 做技术布道者的时候，认识了很多 SaaS 公司的创始人、CTO、客户成功总监——他们经常向我抱怨：「我们公司的客户成功经理每天要处理很多日常咨询，烦死了；我们招聘了实习生，但实习生经常回答错误，培训成本也很高；我们购买了 Intercom 的 AI 客服功能，但它只能回答预设的问题，稍微复杂一点的问题就回答不了，而且它不能和我们的 CRM 系统、工单系统无缝协作」。

当时，我就意识到这是一个非常大的市场——根据 Gartner 的预测，到 2025 年，全球 AI 客服市场的规模将达到 180 亿美元。

但是，我并没有一开始就拍脑袋想做一个 AI 客服产品——而是先通过「用户痛点五层级分析法」和「AI Agent 场景评分表」筛选出了 「SaaS 公司客户日常咨询自动化处理」 这个最小可行场景。

1.5.3 MVP-1 快速原型开发的过程

在筛选出最小可行场景之后，我用了 3 周的时间 开发出了 MVP-1 原型——技术栈选择如下：

  • LLM：GPT-4o Mini
  • 向量数据库：Pinecone Serverless
  • RAG 框架：LangChain Python
  • API 网关：FastAPI
  • 前端演示界面：Streamlit

这个原型的完整流程是：

  1. 用户通过 Streamlit 的界面输入咨询；
  2. LangChain 从 Pinecone Serverless 检索相关的产品文档（我当时用的是我之前写的一篇关于「AWS S3 数据管理」的博客作为测试文档）；
  3. LangChain 调用 GPT-4o Mini 生成初步的回答；
  4. 用自己写的简单的 Python 脚本验证初步的回答（验证维度：回答是否来自博客内容）；
  5. 如果验证通过，就将回答显示在 Streamlit 的界面上；
  6. 如果验证不通过，就显示「抱歉，我无法回答这个问题，请联系人工客服」。
1.5.4 最小场景验证的结果

在开发出 MVP-1 原型之后，我找了 12 个最熟悉的 SaaS 公司的客户成功总监 作为种子用户——进行了一对一的演示和访谈。

验证结果如下：

  1. 付费意愿：有 5 个种子用户（约 42%） 表示如果这个产品能完全满足他们的需求，他们愿意每年付 10-20 万美元；
  2. 有用性：有 7 个种子用户（约 58%） 表示这个产品对他们非常有用；有 4 个种子用户（约 33%） 表示这个产品对他们比较有用；只有 1 个种子用户（约 8%） 表示这个产品对他们没用；
  3. 最频繁提到的问题：
    • 不能和他们现有的 Intercom 系统无缝协作；
    • 不能和他们现有的 CRM 系统（比如 HubSpot、Salesforce）无缝协作；
    • 不能和他们现有的工单系统（比如 Zendesk、Freshdesk）无缝协作；
    • 验证维度太少，可能会出现一些错误的回答；
    • 前端演示界面太简单，不好看，也不好用；
  4. 最愿意付费的用户的需求：
    • 可以自定义验证维度；
    • 可以自动将验证通过的回复同步到向量数据库；
    • 可以查看 Agent 的处理日志和统计数据；
    • 可以设置不同的权限（比如管理员可以修改 Agent 的配置，普通客服只能查看处理日志）。

根据验证结果，我判断我们可以进入下一个阶段（阶段二：技术栈标准化 & 核心能力打磨）。

2. 阶段二：技术栈标准化 & 核心能力打磨（MVP-1 到 MVP-2）——从「能跑的原型」到「能用的产品」

2.1 核心概念拆解

在这个阶段，我们需要掌握三个核心概念：

  1. 技术栈标准化：选择一套 「可维护、可扩展、低延迟、低成本」 的成熟技术栈，并且制定一套 「严格的开发规范」——确保团队中的每个人都能按照统一的标准开发代码；
  2. 核心能力打磨：在 MVP-1 的基础上，打磨 「3-5 个核心能力」——这些核心能力是解决 MVP-1 阶段用户最频繁提到的问题的关键；
  3. RAG 优化：RAG 是控制 AI Agent 幻觉率的最有效方法之一——在这个阶段，我们需要对 RAG 进行优化，比如 「文档预处理优化」「检索算法优化」「重排序优化」「生成优化」。

2.2 技术栈标准化的原则：「墨白科技技术栈选择五原则」

在阶段一的 MVP-1 快速原型开发中，我们选择的技术栈是「最快能上手、最快能开发出原型」的——但在阶段二，我们需要选择一套 「可维护、可扩展、低延迟、低成本」 的成熟技术栈——我推荐大家使用 「墨白科技技术栈选择五原则」：

  1. 原则一：成熟度优先：选择已经被 「1000+ 企业」 验证过的成熟技术栈——不要选择那些还在「早期测试阶段」的技术栈，否则你会遇到很多 bug，而且没有人能帮你解决；
  2. 原则二：开源优先：选择 「开源的、有活跃社区支持的」 技术栈——开源技术栈的成本更低，而且可以根据自己的需求进行定制；
  3. 原则三：可扩展优先：选择 「支持水平扩展」 的技术栈——确保随着用户数和数据量的增长，系统的性能不会下降；
  4. 原则四：低延迟优先：选择 「响应速度快」 的技术栈——多 Agent 协作系统的延迟主要来自 LLM 的调用，但我们可以通过缓存、向量数据库的优化、API 网关的优化等方法来降低其他环节的延迟；
  5. 原则五：团队熟悉度优先：选择 「团队成员熟悉的」 技术栈——如果团队成员都熟悉 Python，那就不要选择 Go；如果团队成员都熟悉 React，那就不要选择 Vue——这样可以大大降低学习成本，提高开发效率。

2.3 技术栈选择（MVP-2 阶段及以后）

根据「墨白科技技术栈选择五原则」，我们选择了以下技术栈——这套技术栈已经被我们的 37 家付费客户验证过，非常适合企业级 AI Agent Harness Engineering 产品：

2.3.1 核心技术栈架构图

为了让大家更直观地理解我们的技术栈，我用 Mermaid.js 画了一个核心技术栈架构图：

API 请求

认证授权

请求路由

Agent 配置管理

Agent 编排执行

RAG 数据管理

数据埋点与分析

权限管理

LLM 调用

调用 GPT-4o

调用 Claude 3 Opus

调用 Gemini 1.5 Pro

调用本地 LLM

缓存 LLM 响应

检索 RAG 数据

预处理文档

将文档分块并向量化

将向量化后的文档存储到向量数据库

收集埋点数据

分析埋点数据

访问管理界面

API 请求

用户端

API 网关
Kong Gateway + Kong Ingress Controller

身份认证服务
Keycloak

业务服务层

Agent 配置服务
Go + PostgreSQL

Agent 编排服务
Python + LangGraph

RAG 数据管理服务
Go + PostgreSQL + Redis

数据埋点与分析服务
Go + ClickHouse + Grafana

权限管理服务
Go + PostgreSQL + Casbin

LLM 网关
LiteLLM

OpenAI GPT-4o

Anthropic Claude 3 Opus

Google Gemini 1.5 Pro

本地 LLM
Llama 3.1 70B/8x22B

缓存服务
Redis Cluster

向量数据库
Pinecone Serverless / Qdrant Cloud

文档预处理工具
LangChain + Unstructured.IO

向量化模型
OpenAI text-embedding-3-small / Cohere Embed V3

数据采集工具
OpenTelemetry

数据分析工具
Apache Superset

管理端

前端服务
React + TypeScript + Tailwind CSS + Vite
2.3.2 各组件的详细说明

接下来，我对每个组件的选择理由进行详细说明：

组件层级 组件名称 推荐工具 选择理由
用户端/管理端 前端框架 React + TypeScript + Tailwind CSS + Vite React 是目前最流行的前端框架，有很多成熟的组件库可以参考；TypeScript 可以提高代码的可维护性和可读性；Tailwind CSS 可以大大提高 CSS 的开发效率；Vite 是目前最快的前端构建工具，开发体验非常好；
API 网关 API 网关 Kong Gateway + Kong Ingress Controller Kong Gateway 是目前最成熟的开源 API 网关，支持水平扩展，有很多插件可以使用（比如认证授权、限流熔断、日志监控）；Kong Ingress Controller 可以将 Kong Gateway 和 Kubernetes 无缝集成，非常适合云原生部署；
身份认证服务 身份认证 Keycloak Keycloak 是目前最成熟的开源身份认证服务，支持 OAuth 2.0、OpenID Connect、SAML 2.0 等主流认证协议，支持多种身份源（比如 LDAP、Active Directory、GitHub、Google），支持自定义登录界面和权限管理，非常适合企业级应用；
业务服务层 Agent 配置服务 Go + PostgreSQL Go 是目前最流行的云原生编程语言，性能非常好，支持水平扩展，开发效率也很高；PostgreSQL 是目前最成熟的开源关系型数据库，支持 ACID 事务，支持 JSON 数据类型，支持水平扩展（通过 Citus 或者 PostgreSQL XL），非常适合存储结构化数据（比如 Agent 的配置信息、用户的信息、权限的信息）；
业务服务层 Agent 编排服务 Python + LangGraph Python 是目前最流行的 AI 编程语言，有很多成熟的 AI 框架可以参考（比如 LangChain、PyTorch、TensorFlow）；LangGraph 是 LangChain 团队开发的专门用于多 Agent 编排的框架，支持状态管理、分支、循环、条件判断、异步调用等功能，非常适合构建复杂的多 Agent 协作系统；
业务服务层 RAG 数据管理服务 Go + PostgreSQL + Redis Go 性能好，适合处理数据管理的逻辑；PostgreSQL 适合存储文档的元数据（比如文档的标题、作者、创建时间、更新时间、分块的信息）；Redis 适合缓存文档的元数据和分块的信息，提高检索效率；
业务服务层 数据埋点与分析服务 Go + ClickHouse + Grafana Go 性能好，适合处理数据采集的逻辑；ClickHouse 是目前最成熟的开源列式数据库，支持海量数据的实时分析，查询速度非常快，非常适合存储埋点数据和统计数据；Grafana 是目前最成熟的开源数据可视化工具，支持多种数据源（比如 ClickHouse、PostgreSQL、Prometheus），可以快速创建各种图表和仪表盘，非常适合监控系统的性能和用户的行为；
业务服务层 权限管理服务 Go + PostgreSQL + Casbin Go 性能好，适合处理权限管理的逻辑；PostgreSQL 适合存储权限的信息（比如角色的信息、用户的角色信息、角色的权限信息）；Casbin 是目前最成熟的开源权限管理框架，支持多种访问控制模型（比如 RBAC、ABAC、ACL），支持自定义策略，非常适合企业级应用；
AI 服务层 LLM 网关 LiteLLM LiteLLM 是目前最成熟的开源 LLM 网关，支持 100+ 种 LLM（比如 OpenAI、Anthropic、Google、AWS Bedrock、Azure OpenAI、本地 LLM），支持统一的 API 接口，支持成本监控、限流熔断、重试机制、缓存机制，非常适合管理多个 LLM 的调用；
AI 服务层 LLM OpenAI GPT-4o / Anthropic Claude 3 Opus / Google Gemini 1.5 Pro / 本地 LLM（Llama 3.1 70B/8x22B） 混合使用云端 LLM 和本地 LLM：云端 LLM（比如 GPT-4o、Claude 3 Opus、Gemini 1.5 Pro）的能力更强，适合处理复杂的推理任务；本地 LLM（比如 Llama 3.1 70B/8x22B）的成本更低，延迟更小，数据安全性更高，适合处理简单的、敏感的任务；
AI 服务层 缓存服务 Redis Cluster Redis Cluster 是目前最成熟的开源分布式缓存，支持水平扩展，支持主从复制，支持多种数据结构（比如 String、Hash、List、Set、Sorted Set），非常适合缓存 LLM 的响应、文档的元数据、分块的信息；
AI 服务层 向量数据库 Pinecone Serverless / Qdrant Cloud 混合使用云端向量数据库和本地向量数据库：云端向量数据库（比如 Pinecone Serverless、Qdrant Cloud）不需要自己搭建服务器，按使用量付费，支持水平扩展，支持多种检索算法（比如余弦相似度、欧氏距离、点积），非常适合处理海量的向量数据；本地向量数据库（比如 Qdrant Local、Milvus Local）的数据安全性更高，延迟更小，适合处理敏感的、少量的向量数据；
AI 服务层 文档预处理工具 LangChain + Unstructured.IO LangChain 有很多现成的文档加载器可以使用（比如 PDFLoader、Docx2txtLoader、WebBaseLoader）；Unstructured.IO 可以处理各种格式的文档（比如 PDF、Word、Excel、PPT、HTML、TXT、图片），提取结构化的信息（比如标题、段落、表格、图片），非常适合文档预处理；
AI 服务层 向量化模型 OpenAI text-embedding-3-small / Cohere Embed V3 OpenAI text-embedding-3-small 和 Cohere Embed V3 是目前性价比最高的向量化模型，向量化的速度很快，准确率也很高；
数据采集与可视化层 数据采集工具 OpenTelemetry OpenTelemetry 是目前最成熟的开源可观测性框架，支持多种数据类型（比如 Traces、Metrics、Logs），支持多种语言（比如 Go、Python、Java、JavaScript），支持多种后端（比如 ClickHouse、Prometheus、Elasticsearch、Jaeger），非常适合数据埋点和系统监控；
数据采集与可视化层 数据分析工具 Apache Superset Apache Superset 是目前最成熟的开源数据可视化工具，支持多种数据源（比如 ClickHouse、PostgreSQL、MySQL、Oracle），支持多种图表类型（比如折线图、柱状图、饼图、散点图、地图、仪表盘），支持自定义 SQL 查询，支持权限管理，非常适合数据分析；

2.4 核心能力打磨：墨白 MCP 的 4 个核心能力

在阶段一的 MVP-1 验证中，用户最频繁提到的问题有 5 个——我们选择了其中 「最重要的 4 个问题」，打磨出了 「4 个核心能力」：

  1. 核心能力一：多系统无缝集成能力——解决「不能和现有的 Intercom、HubSpot、Salesforce、Zendesk 等系统无缝协作」的问题；
  2. 核心能力二：可自定义的 RAG 验证能力——解决「验证维度太少，可能会出现一些错误的回答」的问题；
  3. 核心能力三：自动知识更新能力——解决「不能自动将验证通过的回复同步到向量数据库」的问题；
  4. 核心能力四：可视化的监控与分析能力——解决「不能查看 Agent 的处理日志和统计数据」的问题。

接下来，我对每个核心能力的实现原理和代码示例进行详细说明——为了让大家更直观地理解，我会使用 Python 和 LangGraph 来编写代码示例。

2.4.1 核心能力一：多系统无缝集成能力

多系统无缝集成能力是企业级 AI Agent Harness Engineering 产品的核心竞争力之一——墨白 MCP 目前已经支持 50+ 种主流系统的集成（比如 Intercom、HubSpot、Salesforce、Zendesk、Slack、Discord、Jira、Confluence、GitHub、GitLab、AWS S3、Google Cloud Storage 等）。

2.4.1.1 实现原理

多系统无缝集成能力的实现原理非常简单：我们为每个主流系统开发了一个 「连接器（Connector）」——连接器负责将我们的 Agent 编排服务和外部系统连接起来，提供统一的 API 接口给 Agent 调用。

为了让大家更直观地理解，我用 Mermaid.js 画了一个多系统无缝集成的交互关系图：

Zendesk HubSpot LLM 墨白 MCP RAG 服务 墨白 MCP Intercom 连接器 墨白 MCP Agent 编排服务 墨白 MCP API 网关 Intercom 用户 Zendesk HubSpot LLM 墨白 MCP RAG 服务 墨白 MCP Intercom 连接器 墨白 MCP Agent 编排服务 墨白 MCP API 网关 Intercom 用户 alt [验证通过] [验证不通过] 提交咨询 发送咨询到 Webhook 触发 Agent 流程 调用「获取用户信息」接口 调用 HubSpot API 获取用户信息 返回用户信息 返回用户信息 检索相关文档 返回相关文档 生成初步回答 返回初步回答 调用「验证回答」接口 返回验证结果 调用「发送回答」接口 调用 Intercom API 发送回答 返回发送成功 返回发送成功 显示回答 调用「创建工单」接口 调用 Zendesk API 创建工单 返回工单信息 返回工单信息 调用「发送通知」接口 调用 Intercom API 发送通知 返回发送成功 返回发送成功 显示通知
2.4.1.2 代码示例（Intercom 连接器的简化版）

为了让大家更直观地理解连接器的实现原理，我用 Python 编写了一个 Intercom 连接器的简化版——这个连接器支持「获取用户信息」「发送回答」「创建工单」三个接口：

# intercom_connector.py
import os
import requests
from typing import Dict, Optional

# 从环境变量中获取 Intercom 的 API Key
INTERCOM_API_KEY = os.getenv("INTERCOM_API_KEY")
INTERCOM_BASE_URL = "https://api.intercom.io"

# 请求头
headers = {
    "Authorization": f"Bearer {INTERCOM_API_KEY}",
    "Accept": "application/json",
    "Content-Type": "application/json",
}

class IntercomConnector:
    """
    Intercom 连接器的简化版
    支持「获取用户信息」「发送回答」「创建工单」三个接口
    """

    def get_user_info(self, user_id: str) -> Optional[Dict]:
        """
        获取用户信息
        :param user_id: Intercom 用户 ID
        :return: 用户信息（如果成功），否则返回 None
        """
        url = f"{INTERCOM_BASE_URL}/contacts/{user_id}"
        try:
            response = requests.get(url, headers=headers, timeout=10)
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"获取用户信息失败：{e}")
            return None

    def send_message(self, conversation_id: str, message: str) -> Optional[Dict]:
        """
        发送回答到 Intercom 对话
        :param conversation_id: Intercom 对话 ID
        :param message: 回答内容
        :return: 发送结果（如果成功），否则返回 None
        """
        url = f"{INTERCOM_BASE_URL}/conversations/{conversation_id}/reply"
        data = {
            "message_type": "comment",
            "type": "admin",
            "body": message,
        }
        try:
            response = requests.post(url, headers=headers, json=data, timeout=10)
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"发送回答失败：{e}")
            return None

    def create_ticket(self, conversation_id: str, user_id: str, subject: str, description: str) -> Optional[Dict]:
        """
        创建 Zendesk 工单（简化版：这里我们只是模拟创建工单，实际开发中需要调用 Zendesk API）
        :param conversation_id: Intercom 对话
# 人工智能
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

周末速报：AI圈大事盘点

avatar AI Agent技术社区

告别封号与刷脸焦虑：深度复盘国内稳定调用 Claude 的工程化方案

在 2026 年 AI 应用爆发的前夜，稳定、高效、合规的算力获取能力将成为企业的核心竞争力。与其在繁琐的刷脸验证和网络波动中消耗精力，不如转向更加专业化、工程化的聚合方案。非线智能API 的价值不仅在于提供了 Claude 的访问通道，更在于它构建了一套让模型“触手可及”的基础设施。目前，平台正为新注册用户提供 20 元起步的体验金。对于正深陷封号困扰的开发者而言，这或许是目前最值得尝试的破局之

avatar AI Agent技术社区
cover

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-ap

avatar AI Agent技术社区