复杂AI项目团队架构深度解析：从工作流到多轮知识问答的构建与优化指南

April 5, 2026

我们之前已经讨论过，模型的核心三要素是算法、算力与数据。对于AI应用而言，对算力的要求通常极低，在算法层面其复杂性也得到了极大程度的简化。唯一要求依然较高的环节是数据，甚至可以说，AI应用工程的核心工作几乎完全围绕大型语言模型与数据的交互展开。

因此，当我们着手启动一个AI项目时，可以从以下四个维度进行分层架构设计：

其中，模型边界控制与幻觉处理通常可被视为工程能力的一部分。优质数据则往往是行业专业知识（KnowHow）的沉淀与结构化体现，但拥有专业知识并不等同于拥有结构化的数据。

那么，究竟什么是行业KnowHow呢？简而言之，它可以是算法逻辑、标准操作程序（SOP），或是具体的工作流程。简单的形式可能如下所示：

稍微复杂一些的版本可能呈现为：

因此，无论开发何种类型的AI项目，核心重点必定是行业特有的专业知识。因为说到底，大型语言模型（LLM）本质上只是一个应用程序接口（API）。通过实践两个复杂项目，几乎可以掌握其应用精髓：

所以，当工程能力（包括LLM工程能力）、行业KnowHow与数据三者进行排列组合后，几乎所有的AI项目类型便应运而生：

然而，其中存在一个**“异类”——Manus**。它不太容易被归类到某一特定类型中，因为它功能全面，无所不包！更令人担忧的是，如今这类大而全的智能体（Agent）正变得越来越多……

因此，对于Agent这种看似能够解决所有行业问题的模式，以及一套代码适配所有场景的做法，我们更倾向于将其归入基座模型的范畴。但如果是专注于垂直领域的Agent，例如Cursor、OpenEvidence、Lovart等，则应归属为行业级应用。严格来说，这类应用旨在解决特定行业或特定岗位的具体问题。

当然，映射到各家公司具体的视角中，Cursor、OpenEvidence这些巨头可能显得过于遥远。我们可以进一步简化分类方式，从如何开发一个AI应用的角度出发，将AI应用划分为三类：

第一类：工作流类AI；
第二类：简单知识问答系统；
第三类：多轮知识问答系统/复杂知识库项目。

多轮知识问答系统的挑战

首先，根据前期的文章分析，我们可以清晰地认识到，工作流类AI的核心在于KnowHow，即如何梳理出完整、高效的标准操作程序（SOP）。AI在其中更多扮演辅助角色，这类应用中AI的技术含量通常不会超过20%。它们可以被归为降本增效型AI，实施后往往能迅速见效，性价比极高。

其次，简单知识问答系统的核心在于检索增强生成（RAG）技术的运用。其难点主要集中在知识数据的处理环节，而在Agent平台上的应用反而相对次要。因为这类系统通常只涉及简单的单轮问答，无需考虑复杂的意图识别，因此实现难度较低。如果将数据处理视为AI模块的一部分，其AI技术含量大约在50%左右。

最后，就是多轮知识问答系统。其复杂度陡然提升，如果我们将工作流类项目的难度设定为5，简单知识库项目难度为4，那么多轮知识问答项目的难度则高达10！

关于前两类项目，我们已有详细的阐述：

今天我们将重点探讨多轮知识问答系统。这一领域存在相当的挑战，主要难点包括以下三个方面：

第一，如何将专业知识（KnowHow）有效梳理、转化为结构化知识；或者，在已有知识素材的情况下，如何高效地组织数据。
第二，数据应如何与AI模型进行交互，以确保每次交互中AI都能准确获取到相关的上下文数据。
第三，也是最关键的关卡，即用户意图的准确识别与理解。

关于第二点，如果发现因数据不足导致AI表现不佳，应如何利用生产环境中产生的数据来持续反馈并优化知识库？这就是我们常说的数据飞轮系统。它是数据工程的一个重要分支，而AI项目的核心，归根结底始终是数据工程！

从数据的整理与加工，到与AI模型的交互，再到后续的数据反馈与迭代，共同构成了常规的数据工程体系。

并且，许多专业知识依赖于医生、律师、教师等非互联网领域的专业人士。这些群体通常缺乏系统梳理自身认知的能力，因此需要互联网从业者来组织协调他们。这其中又涉及到管理学的挑战。请相信，管理医生和律师完成常规工作是相对简单的，但要求他们进行系统化的知识输出，则难度巨大。

最后，数据工程是一个漫长的周期性工作，这会导致AI项目的研发周期延长。并且，系统性能可能时好时坏，这将极大地消耗团队的士气，这里又涉及到了项目管理的艺术。

综上所述，复杂知识库项目本质上是一个偏向工程实施的项目。特别是其中的专业知识、数据、技术架构与模型特性相互交织，关系错综复杂。若非自身水平很高，很难将这些问题梳理清楚；或者即使理清了，也可能缺乏调动各专业领域人员的管理能力。然而，对于那些已经身处高位的管理者而言，又很难沉下心来一点点梳理专业知识与数据细节。这或许是导致复杂AI应用相对较少的主要原因。

接下来，分享一些在实施复杂AI项目过程中的心得体会。

实践心得分享

在开展多轮知识问答项目时，我们总结出以下几点心得供大家参考：

第一，知识库的设计至关重要。其中最为困难的是确定系统的边界与知识结构。所谓边界，是指你的AI系统究竟要完成哪些具体任务，必须通过穷举的方式明确界定；所谓结构，则是指知识体系必须能够匹配和支持这套系统的运行逻辑。

第二，在梳理知识时，需要考虑逻辑关系链，设计实体结构，并找到切入知识库的核心。例如，可以使用一个独特的关键词将知识实体检索出来，再根据实体间的逻辑关系链找到各种关联。只要逻辑链条清晰，提示词（Prompt）就容易设计，AI的表现也会更加智能。

第三，在设计知识库的实体结构时，类型不宜过多。如果产生层级关系，层级也不宜过深。因为关系越复杂，工程实现的难度越大；层级越多，知识库的处理过程就越复杂。开发AI应用时，需要在真实世界场景的模拟还原与数据工程实现的投入产出比（ROI）之间寻求平衡。如果工程实现的复杂度过高，就需要在数据复杂度层面做出适当的取舍。

第四，在前三点的基础上，需要考虑架构实现的问题。这里必须由项目一号位亲自撰写文档，进行产品或架构设计。不要求你编写代码，但你的文档完成后，应达到相当于伪代码级别的详细程度。否则，后续的产品经理和工程师可能不具备将其落地的能力。这里的架构设计核心在于你的知识体系如何确保AI每次交互都能拿到、拿对、拿全，并且不拿多无关信息。

第五，在知识体系完备的前提下，如何让AI的对话表现更接近真人，这是一个相对封闭的技术问题。其前提是知识内容本身是正确的。如何让AI像人一样表达这些知识，需要考虑对话策略、情感模拟等因素，这通常需要进行建模或策略设计。

以上就是核心的心得体会。即便对于经验丰富的从业者而言，在实际操作过程中也会不断遇到各种需要解决的麻烦事。因此，建议大家在吸收这些信息后，结合自身实践进行深入思考。

这里还遗留了一个关键问题：复杂AI项目的团队应该如何设置与分工呢？

AI团队架构设置指南

从项目实施的难度来看，存在这样一个关系：多轮知识问答项目 » 简单AI知识库项目 > AI工作流项目。并且，根据上述的分层模型，它们呈现出向下兼容的特点。这意味着，一个团队如果能做好多轮知识问答系统，就必然能够轻松驾驭简单的AI知识库项目。

因此，我们在进行团队架构设计时，可以直接按照最复杂项目的需求来安排。后续可根据具体项目情况适当缩减。首先，需要确立核心的三角协作关系：

首先，技术负责人（技术Leader）是必须存在的角色，在某些情况下他甚至可以兼任产品负责人。其次，在复杂的AI项目中，行业专家必不可少。例如，开发AI医生系统，团队中必须要有医生；开发AI律师系统，团队中也必须要有律师。

原因很简单，他们需要从专业角度衡量AI产品的输出质量，在这方面，产品与研发负责人几乎无能为力。但需要特别注意的一点是：

行业专家必须向产品/研发负责人汇报。因为与这批专业人士沟通确实存在较大障碍，如果没有明确的汇报关系，他们可能会表现得较为固执，难以按照项目既定的思路和节奏推进。

在建立了稳定的三角协作关系后，就可以开始分配各自的工作了。首先要明确最为关键的技术路径（包括技术架构与产品目标）。

每个AI产品都有其核心目标。以行业级AI应用（如AI医生）为例，我们在设计时通常不会期望一个大而全的系统解决所有问题，而是会对其进行拆分。例如，可以分别开发负责诊断的Agent、负责慢病管理的Agent、负责医保咨询的Agent等。

再比如，在开发教育类AI时，我们不会期待一个AI教师能够博古通今，同时在数学和英语领域都非常出色。因此，在设计时必须进行拆分，甚至在具体科目内可能还需要进一步细分……

大型AI产品的总体目标是一个，同时每个细分Agent的目标也必须非常清晰。如果强行将它们合并为一个整体，就属于人为地增加了技术难度。当难度过高时，系统往往难以实现，此时最容易发生的情况就是团队“摆烂”，将所有问题都丢给LLM自由发挥。

在这个基础之上，才能进入真正的核心工作阶段——这也是必须由三个角色共同协作创造的部分——即输出核心的技术路径，也就是设计出工程架构和数据结构。

虽然目前很多AI项目做出演示原型（demo）的周期很短（通常一周左右），但基础技术路径的确立并非一朝一夕之功。它需要经过多轮试错迭代，正如前述多轮知识问答AI系统的难点所示：

数据结构需要找出当前业务在真实世界中的映射关系，这项工作成果将长期影响项目。
技术架构需要匹配这套数据结构，目标是让AI能够“思我所思，言之有物”，简单来说就是实现思维链（CoT）和结果的可追溯性。

在基本技术路径通过验证后，真正的AI项目才算正式开始。因为验证技术路径可能只需要50条数据，但要看到真实、稳定的效果，至少需要500条甚至更多的数据。此时，各条线的工作开始正式运转：

首先最繁忙的是技术团队。他们需要在完成AI项目工程实现的同时，开发各种效率工具，例如：

复杂的AI项目提示词数量庞大（轻松达到数十万行），因此需要一个提示词管理平台，后续还需要支持多模型、多版本的测试、切换与发布等功能。
知识库生产平台，用于协助行业专家录入和整理知识库。
可观测性平台。对于生产级应用，需要一个产品调试工具，主要供技术团队和业务专家使用。技术目标是进行调试，业务目标是检查各个环节是否存在错误。这里的观测粒度会很细，会查看每个提示词、每条数据是否存在问题。
……

其次是专家团队。他们的工作相对单纯，主要是生产数据与进行各项评估：

数据工程的主力，配合技术团队不断挑战和优化数据结构，并持续采集数据。
产品评测的主力，评估每次发布的AI产品的实际效果，这需要构建大量的测试数据集。
数据飞轮系统的执行者，主要工作是配合技术团队不断补充边界情况的数据。
论文编写，如果涉及到知识产权保护等需求，需要在产品技术团队的辅助下，由专家产出相关论文。
……

最后是产品团队。他们的工作除了最本质的输出产品原型外，还包括：

竞品调研，需要调研各个竞争对手的产品，并需要专家团队协助优化测试数据集，以便让团队清晰认识到自家产品与竞品的真实差距。
销售方案，所有的AI产品最终都指向商业化盈利，销售方案的输出通常由产品团队牵头负责。
公关（PR）与投放策略。
……

最终的整体协作效果大致如下图所示：

其实从这张图也可以看出通用型Agent架构（类似Manus的产品）本身可能存在的问题：它们或许并没有真正深入思考如何解决具体的行业问题。例如，它们完全缺失了“行业负责人”这条线，或者说将这部分工作直接委托给了大模型自行处理。如果这样都能产出高质量的结果，那确实堪称奇迹……

总结

至此，大家应该能够看出，今天这篇文章的核心目标是探讨：一个复杂AI项目的团队应该如何构成，以及每个角色在其中大致承担什么样的工作。

其中的三角协作关系其实非常清晰：产品团队更多地对外，技术团队更多地对内，专家团队更多地做专业性配合。整个团队运转的核心多依赖于技术团队，因此技术负责人往往还需要承担部分项目管理办公室（PMO）的协调工作。

如果是简单的知识库项目或工作流AI，产品负责人可能不是必需的，行业专家也可以兼职参与。但如果是复杂的AI项目，这种三角协作关系缺一不可！

然而，这里也存在一个问题：工程技术团队是否必须全部由精英构成呢？答案未必如此！

根据个人经验，这类复杂的AI项目，除了初期的架构确认阶段，到后期更多是提示词编写和项目管理的工作。只不过，其中的核心提示词几乎全部由少数几个关键人物编写。

因此，AI项目的核心其实是文档工作，或者说文字组织能力。从这个角度来看，压根不需要那么多高端的工程师。从项目落地角度而言，三角关系的三位负责人必须能力出众，其他产品或专家只要能做好配合工作即可。

技术团队的构成比较特殊，通常采用 “1超 + 1专 + N” 的模式。“1超”是指技术负责人，他必须是“超人”，无论在技术视野、行业KnowHow还是专业技能方面都要非常强。这里尤其看重的是沟通交流能力，以及交流后组织文档的能力。对文档的要求会非常细致，因为文档稍有差池，工程实现就可能出现问题，所以反而具体的代码编写能力并非首要考虑因素。

除了负责人之外，团队还需要有一位架构师。他的编码能力要很强，能够与负责人形成互补。因为项目中仍会有很多模型训练、工程调优的具体工作需要进行，负责人由于工作繁杂，很难在具体代码层面做得非常深入。

以上就是今天的分享，希望能为大家带来一些有益的启发。