当前位置：首页 > news >正文

从671B到70B，如何用更低成本实现企业大模型工程化的RAG、Agent与微调落地，大模型入门到精通，收藏这篇就足够了！

news 2025/10/12 10:29:16

从671B到70B，如何用更低成本实现企业大模型工程化的RAG、Agent与微调落地

虽然DeepSEEK本身无需付费，但硬件投入成本较高。通常在Q1或Q2季度复盘时，企业会意识到在AI领域的巨额投入后，面临如何实现价值转化的问题。此时，技术总监、经理及研发架构团队需要思考如何基于AI创造实际价值，推动工程化落地，实现业务整合。

然而，大模型的实施与传统软件开发架构存在显著差异，知识迁移面临诸多挑战。最终可能仅能向领导交付RAG问答系统等基础方案，但这往往难以令管理层满意。企业级知识沉淀通常包括多级缓存、读写分离、数据库优化和微服务等成熟稳定的商业化方案。相比之下，直接交付RAG系统或微调后的大模型存在一定随机性，不仅难以获得认可，实施团队自身也对其工程适用性存疑。部分企业甚至明确表示不会采用此类方案。

如何实现这一目标？我们选择由外部团队协助定制这些产品。这一转变反映了行业趋势的变化：最初，人们可能一时冲动地部署RAG、DeFi或High Engine等系统，但现在大家逐渐回归理性思考。

首要问题是：大模型能否真正落地应用？其次是如何将传统AI技术与现有工程环境相结合。当前热门的Multi Agent系统虽然广受关注，但部署后能否与现有工作流程有效联动，以及存在哪些潜在问题，都是新的挑战。

我们的团队在实践中积累了大量经验。企业最初可能因一时冲动购置GPU算力资源，并将私有数据直接导入RAG系统，但当发现RAG效果不佳时，往往陷入困境。这提出了新的要求：如何实现RAG、微调和知识图谱等技术的有效落地？

目前积累的技术尚不足以完全满足需求，关键在于缺乏软件工程化的经验。我们需要将工程化经验与大模型技术相结合，就像云计算发展初期面临虚拟机不稳定问题时，通过负载均衡和高可用技术实现系统优化。

在完成大量入口的自动化迁移工作后，这套系统才真正实现了稳定运行。当前在大模型应用领域，我们仍面临类似挑战，但解决方案已发生显著变化。

如左侧图示所示，横坐标代表行为优化维度，纵坐标则对应上下文优化维度。初期工作聚焦于提示词工程，随后技术演进方向出现分化：部分团队选择继续深化提示词优化，而更多团队转向模型微调技术路径。

通过实践发现，大模型的全参数微调存在较高实施难度，因此我们转向轻量化微调方案。为弥补上下文理解不足的问题，创新性地采用了RAG（检索增强生成）与KG（知识图谱）的融合架构。最终形成三条并行技术路线：

1.RAG机制专注于上下文增强

2.微调技术解决特定内容生成问题

3.智能体（Agent）系统实现任务分解与决策优化

当前技术发展呈现模块化特征，各技术组件相对独立。未来演进可借鉴软件开发领域的经验，沿两个维度深入：

·纵向深化：持续优化微调效果，改进RAG的知识增强能力

·横向整合：探索多智能体协同框架，实现技术组件的有机融合

在学术研究和大模型开发领域，专业人士的工作重点与我们实际业务需求存在显著差异。在工程实践中，我们更注重系统的可用性和稳定性，而非纯粹的学术创新。具体而言，我们追求以下特性：响应准确性、问题缓存机制、用户会话记忆功能等。这些关键需求往往无法直接从网络知识中获取。

无论是作为乙方的项目交付方，还是甲方的内部技术顾问，这些工程化考量都是必须面对的核心问题。关于技术采用时机，我通常不会选择早期采纳策略。以MCP技术为例，我更关注其实际应用中的局限性而非创新性。对于大模型技术，我们倾向于在技术成熟度曲线（Gartner曲线）的下降期开始采用，这时技术更稳定，更适合商业交付。

具体到RAG（检索增强生成）技术，其实际应用始于2024年七八月份，在DeepSeek年初爆火后才逐步普及。当技术即将度过泡沫破裂低谷期，进入稳步爬升阶段时，才是积累相关知识的合适时机。此时技术架构已相对稳定，不会因研发性质的变化而产生重大调整。例如Gartner曲线左侧提及的自主智能体技术，就需要在这种相对稳定的阶段进行工程化落地。

Auto GPT属于通用人工智能领域，涵盖强化学习、联邦学习和提示词工程等技术。AI的OS（操作系统）和机器客户等概念在去年七八月份已被提及。然而，真正实现落地的技术有哪些？通过观察可以发现，实际落地的技术主要集中在左侧部分：RAG、Agent和微调这三大方向。

对于值得投入时间积累的技术，我们需要关注其发展周期。当技术度过期望膨胀期，进入泡沫破裂后的低谷期，并逐渐成熟时，它将开始稳步爬升和复苏，最终迭代为可投入生产的技术。此时正是我们深入研究的恰当时机。

当前是2024年8月，预计到2025年8月再回顾时，我们将更清晰地看到机器学习技术的发展脉络。如需了解详细的技术发展路线，建议搜索Gartner发布的AI技术发展路线图（截至2024年8月）。该图源自官方网站，放大后可供详细查看。

由于内容较多，我已将其适当精简。各位可点击PPT右下角的二维码进行领取。这是我们企业对AI的需求总结，基于从业者的实践经验。

企业在应用大模型时已逐渐趋于务实。许多新兴技术最初仅存在于学术领域，但在实际落地过程中往往与预期存在差异。

例如，近期Google与新加坡大学合作发表了一篇关于多智能体系统（Multi-Agent System）的论文，探讨了优化方法。研究发现，提示词优化对多智能体系统的能力具有全局性影响，而传统的拓扑结构设计仅能带来局部提升。

论文指出，当大型语言模型（LLMs）作为多智能体进行交互时，如何解决复杂任务是当前的实际需求。然而，在设计过程中面临诸多挑战，可通过提示词和拓扑结构两种方式解决。

Google作为搜索领域的领军企业，通过多智能体系统（MAS）研究发现，传统方法无法显著提升多智能体性能。因此，他们在MAS基础上增加了搜索功能（S），形成带搜索的多智能体系统（MAS+S），效果显著。后续优化发现，这种方法能有效提升系统性能。

论文链接已附在下方，供进一步参考。

并没有采用更高深的技术来提升性能，而是使用了Gemini 1.5 Pro和Flash版本，类似于DeepSeek的满血版和小参数版两种版本。实验方法包括常见的COT、SE、SR，以及多智能体辩论、ADAS和AFlow等。尽管进行了大量实验，但最终对结论产生显著影响的却是最基础的提示词优化。

这篇论文发表后引发了广泛讨论，包括Google内部人员和大模型优化项目组的成员。他们发现，过去在优化多智能体系统时，虽然引入了许多复杂技术，但性能提升有限。而Google的这篇论文表明，性能提升与提示词的敏感性和拓扑结构的复杂程度密切相关。这让我们重新认识到，研究多智能体系统时，基础优化可能比复杂技术更为关键。

深入研究提示词工程，这引发了一个关键思考：如何通过论文将需求落地到企业，再将企业数据反馈给个人开发者。这才是我们真正可行且能实现的目标。具体方法如下：

从论文到企业实践存在一套通用方法论。例如，基于论文结论落地企业应用时，若验证结论正确，可采用自动化工具优化提示词。相比优化拓扑结构，提示词优化能创造更大价值，实现自动化并减少手动设计复杂拓扑的工作量。

部署大模型系统时，必须进行充分实验验证。同时需考虑成本效益，当前企业对成本极为敏感。此外，可将论文中提到的搜索算法与多智能体系统（MAS）相结合，应用于现有多智能体系统。提示词与拓扑结构的优化可能基于特定搜索算法。

当客户反馈多智能体系统未达预期时，可通过论文研究成果进行改进。

基于现有系统进行优化是企业需要考虑的，而作为个人开发者，我们应关注战术层面的问题。企业应着重战略层的投入产出比，例如跟随行业趋势部署大模型基础设施和训练资源。

对于开发者而言，当前应聚焦于工具链整合、算法优化和异常处理等方向，这些更符合开发工程师的能力范畴。以主流编程语言为例，如Java、Go、C++或Python，开发者需要熟练掌握其工具链。

在大模型领域，算法优化不仅涉及深度学习算法，还包括数据处理方法。此外，异常处理常被低估，实际上客户对系统稳定性的要求往往高于技术创新性。例如，在交付类似闸口审核功能的项目时，稳定性需求尤为突出。

客户需提交一份PDF文档，其中包含手写内容及一串审核数字。通过PDF上传时，系统不会提示识别成功率。若识别错误，客户可重新上传，直至审核通过，方可进入港口。

然而，客户无法接受的是上传功能失效。因此，当大模型落地后，工具链整合与算法优化将显著提升软件的可用性，从而改善用户体验。

在构建多智能体系统时，需注重高效性、可控性和可扩展性。

个人开发者需要考虑的是具体技术实现。从技术角度出发，我们可以从以下三个方面进行思考：

首先，通过业务目标的选择或设计高容错需求的场景，来完成多轮辩论拓扑结构的设计。其次，考虑到提示词对大模型的影响较大，可以尝试进行提示词的自动优化，这可能为多智能体系统带来性能提升。最后，从架构角度需要优先考虑ROI投入产出比。

值得注意的是，提示词和拓扑逻辑决定了整个多智能体系统的架构。此前我曾使用过完整版模型。

在大模型方面，我们是否可以采用轻量版本来优化提示词，以实现相应目标？这是架构师的视角。那么，从个人开发者角度来看，这些内容实际上又回归到了传统开发领域。

对于从事大模型开发的团队，例如落地了RAG或Multi-Agent系统，首先需要进行分层优化。以MASS为例，我们可以按照块级、拓扑和全局三个阶段进行优化，从而降低整体难度。

其次，从架构层面考虑，可以设计反馈机制和动态适应机制。例如，通过自下而上的检测、日志分析，以及调用传统工具来增强智能体的实时数据处理能力。虽然很多人专注于研究RAG和Agent，但我们更擅长数据库和缓存等技术。如何将这些能力融入系统，是值得思考的问题。

此外，我们在设计安全性和鲁棒性方面具有优势，可以创建沙盒环境来模拟冲突场景，并引入规则引擎作为系统保障。这些才是开发者在应用大模型时真正能够发挥自身价值的地方。并非一提到大模型就必须考虑RAG、Agent或VTL。

最后，关于如何具体实施这些方案，我们需要进一步探讨具体操作方法。

接下来我将重新梳理这一过程。在实际操作时，我们不必参考现有图示。虽然工程化确实对大模型有益，但不应全盘推翻现有架构。基于LangChain或LlamaIndex重建多任务问答助手并非明智之举，因为现有系统已包含大量积累。

在优化架构时，不建议一次性全面推翻现有设计。建议从已有项目沉淀的能力出发，逐步展开重构。

以多任务问答助手为例，我们将基于现有能力进行重新构建。接下来，我将展示一个更全面的架构示意图。

现在，我们寻找一张尺寸较大的图片。这张图片是我近期绘制的。让我们重新绘制一次。

然而，最棘手的问题出现了——页面无法打开。这正体现了稳定性带来的重大挑战。即便大模型的编写再出色，模型优化再完善，若无法正常使用，便失去了意义。

工程化为大模型带来的增益是显著的。在课程开始时，我们展示了一个反向案例。现在成功打开了界面，这体现了我们的能力。若无法访问，再优秀的大模型技术也无济于事。

此次，大模型才真正发挥了作用。我通过 Mermaid Live Editor 绘制了这一架构图。现在我们可以放大查看。左侧部分无法收起，因此我们直接使用这一部分。接下来，我们可以采取以下措施。

在工程化实践中，多轮对话应用场景的核心在于：用户提出问题后，系统能够准确输出答案并调用相应工具。

具体流程包括：

首先判断问题是否需要调用工具；
若需要，则执行相应工具调用；
此外，还需针对工具功能编写特定的处理逻辑。

逻辑内容的描述包括调用工具集合，例如查询天气、数据库或新闻等，获取内容后输出结果。若无需调用工具，则通过Prompt填充并调用自然语言处理来获取输出。通常我们更多关注的是左侧流程。

大家主要关注的是左侧部分。如果我们仅关注这一区域，就会遇到演示过程中无法打开网站的尴尬情况。所幸我们演示的内容正是关于异常情况的处理方式。

在实际工程交付过程中，情况往往更为复杂。除了基本流程外，我们还需考虑诸多附加因素。

通过对比可见，左侧仅展示标准流程，而右侧则涉及大量额外工作内容。首要任务是对大模型进行工具化处理。

在调用过程中，为优化效果，我们采用了反思、追问等策略。这些策略应用于业务场景，通过prompt提示词使普通用户在访问时能在业务逻辑层面获得更优反馈。此外，我们更需关注右侧内容。

例如，当用户完成咨询后，仅将信息直接展示在应用程序或工具中是不够的。我们需要存储用户的对话历史记录，特别是高频咨询的问题。这样，当用户再次提出类似问题时，系统就能基于用户画像调用memory功能进行响应。

企业智能体能够让用户感受到大模型越来越理解需求。然而，这些功能实际上很少被实现。

当用户与企业智能体对话时，有时会获得出色的回答，但有时无论如何引导，回答质量都不理想。目前，许多企业智能体都采用了长期存储机制来实现这一功能。

我们采用MongoDB、Redis等数据库进行长期数据存储。在此基础上，可以与用户历史数据相结合，实现用户查询记录的追溯，并与搜索系统进行整合，从而完善用户画像分析。

这些用户偏好信息将被存储起来。通过预先设置用户角色，并在对话过程中逐步分析，我们的智能体将能够更准确地理解用户需求。这一机制使得智能体在交互中不断优化其响应能力。

例如，在提示词工程的应用中，系统并非总能提供理想的回复。无论是使用Defi、扣子还是其他智能体工具，这些热门选项被优先展示。虽然简单的智能体和RAG架构能够处理基础逻辑问题，但在实际业务场景中往往无法满足需求。

许多企业仍在采购专门的RAGent软件，原因是现有系统缺乏错误回复逻辑。例如，当请求出错时，如何设置处理机制以确保系统能够正确响应。

这包括：

- 异常捕获
- 降级逻辑处理
- 缓存失败应对方案（即所谓的“缓存三件套”）

此外，对于提示词的处理也需要建立相应的响应机制。

在动态生成过程中，如何进行反思？例如，当用户询问前往某城市旅游时，常规大模型会直接给出回答。但若希望将其产品化，则需进一步思考：

·用户提供的信息是否充分？

·同行人员中是否有老人或儿童？

·目标旅游城市的具体情况如何？

通过这些问题，可以优化回答的精准度和实用性。

从宏观环境来看，安全性是否足够？不同国家的情况各不相同。从微观层面反思，出行时交通是否顺畅？这类问题需要通过思维链进行调度分析。

在引导模型输出中间步骤时，模型才能更好地理解用户需求。仅依靠现有的大模型RAG和Agent组件是不够的，这些只是框架。在实际交付时，我们需要对这些框架进行补充完善。此外，在多轮对话场景中，我们还需要进行更多优化工作。

状态机机制根据当前任务类型创建新的Agent来完成子任务。子任务可以串行或异步执行，最终将子任务结果合并。该机制旨在防止无限递归检测，这一功能并非预先设计，而是在实际发生无限递归情况后提出的解决方案。

我们意识到存在无限递归的问题，因此需要采取防护措施。最终，我们将最优的缓存结果保存下来。以旅游场景为例，热门城市会被频繁搜索，此时若有更优结果，无需重新计算。

能够直接进行反馈的缓存等机制，是否最适合我们现有开发人员的能力？实际上，我们的开发能力完全可以胜任这类任务。这正是我想强调的——我们具备的工程化能力。

因此，这一变化实际上是一个宏观的总体框架。然而，其规模可能过于庞大。事实上，这才是我们在向客户交付大模型时真正面临的挑战和问题。我将这些挑战简要总结如下。

在构建多智能体系统时，我们面临四个主要挑战。

首先是成本与效率问题。许多企业出于成本考虑，选择采购70B参数规模的大模型而非671B的满血版本。虽然成本显著降低，但需要评估其是否仍能满足RAG和智能体的性能需求。相关研究表明，通过增强搜索能力，并将系统重心从大模型本身转移到提示词工程和拓扑结构设计上，可以有效解决这一问题。

对于坚持不使用满血大模型的用户，我们需要从成本效益角度出发进行优化。这包括合理设计缓存机制，以及应对高并发场景下的用户请求处理方案。

关于请求限流、错误监控和日志追踪等问题，这些都是我们在模型落地过程中必须考虑的关键因素。真正的模型落地并非简单修改DeFi后交付给客户，否则必然会被退回。

让我们关注直播间互动。看不清PPT的同学可以扫描右下角二维码下载原始版本，便于放大查看。当前展示的是企业架构中的一环，但首先需要了解整体结构。这如同拼图，先掌握全貌，再深入分析每一模块的优化方法，这样能更好地理解业务逻辑。分块解析后再整合，有助于更透彻的理解。

关于之前的承诺：

在学习群中首批课程发放时提供更多福利，已在618节点上线课程并附赠官方折扣券；
将过往项目经验系统整理并复现，现已完成。

这两项承诺均已兑现。

确实，利用信息差盈利是常见做法，正如早期部署Deep Seeker的策略。

满血版大模型的情况与此类似。然而，经过Deep Seeker这一波热潮后，许多企业开始趋于理性。理性化后，企业首要关注的是成本与投入产出比。其次，企业会转向内部优化，毕竟已经投入了大量GPU等沉没成本，同时还有Rag Agent和微调等解决方案。

作为内部开发人员，企业期望获得能够工程化落地的解决方案，而非仅依赖Deep Seeker。因此，在理性化之后，工程化落地变得尤为重要。这也可以视为行业内卷的一种表现。

虽然我们尚未涉及具体代码实现，但已经完成了整体架构搭建，毕竟客户也已采纳。在此，我想分享搭建过程中的关键考虑点。例如，直接交付一个现成的开源方案可能不够，需要进一步优化。这些优化涉及整个Agent的能力，而最重要的是架构能力和工程化能力。归根结底，工程化才是关键。

接下来，我们将继续深入探讨。上方展示的是一个关于多任务问答助手的情况。左侧涉及大模型的核心技术，而右侧则更多关注工程化过程中需要解决的其他问题。

在Agent的应用中，常见的交付场景是协同化客服。这种模式下，每个Agent负责特定任务：一个负责协调，其他负责执行。典型的案例是斯坦福小镇，其中每个Agent模拟小镇中的一个角色，如农夫、牧场工人、白领、蓝领等。这些角色可以相互交互，并产生自然的结果。

斯坦福小镇展示了大模型Agent之间协作的可能性。然而，这种模式尚无法直接交付给客户，因为客户期望的是按照既定流程分解任务，而非随机行为。需要将整体任务拆解为多个Agent的动态适配，最终获得固定结果。

以虚拟法庭场景为例：法庭中包含法官、书记员、原告律师、被告律师以及被告人等角色。

在讨论过程中，我们会按照既定顺序进行发言。整个流程由多个环节组成，最终将产生三种可能的结果：原告胜诉、被告胜诉或延期审理。

当向客户交付多智能体系统时，客户不会接受智能体随意运行的结果。因此，我们需要确保智能体必须遵循既定规则输出结果。这一固定逻辑可以通过传统代码编写方式实现，或基于Lama Index开发的工作流来完成。若采用代码方式，则通过拖拽式工作流实现。无论采用哪种方式，都需要通过传统方法将整个工作流程固定下来。

系统中不固定的部分是各个智能体角色，包括法官、不同律师以及负责忠实记录的数据员等。在设计过程中，可能会遇到一些挑战。例如，当被要求设计一个法庭场景的多智能体系统时，需要考虑诸多因素。

关于系统框架的选择，我们会以LangChain、Lama Index和Defi三者为主进行横向比较。其中，LangChain将是主要采用的框架之一。

由于时间限制，今天无法进行实际的项目演示。我将重点介绍如何解决各类技术卡点，后续会安排直播演示具体代码实现。

在构建多智能体系统时，关键挑战在于协调各智能体的行为。例如，在模拟法庭场景中，需要确保法官发言时辩护律师不会同时发言。更复杂的问题在于智能体的异步思考机制：当某个智能体（如辩护律师）进入思考状态时，整个流程需要继续推进，但后续如何妥善处理其延迟输出的内容？这涉及到异步系统设计能力。

对大模型开发者而言，这类异步控制颇具挑战，但对传统软件开发人员则较为熟悉。具体挑战包括：

1.协调不同角色智能体的发言顺序和状态判断

2.处理智能体思考过程中产生的延迟响应

3.确保角色扮演的准确性，如法官智能体需准确体现真实法官的职能特征

这些问题的解决需要结合业务逻辑设计和异步编程技术。

通过多次辩护经验的积累，我们能否将这些经验提取出来，作为智能体的训练数据？这样，智能体就能像法官一样，完整地表达其话语和思维逻辑。这种能力是否源于智能体与大模型RAG技术的结合？

有同学提到，在输出时是否需要考虑使用法言法语。这需要通过微调来实现，目的是让大模型能够输出特定内容，而不仅仅是Circle或SDL。微调还可以让模型输出特定公文，甚至以古人的方式在每次回答时吟诗。这些都是模型固有的方法，用于解决特定问题。

要实现这一目标，我们需要结合智能体、微调和RAG技术来进行整体模拟。这套系统完成后，将为模拟法庭带来哪些价值？有人提到了意图识别，此外还包括协调和冲突解决等功能。

以企业为例，假设律所有500名律师。通过静态方式，我们可以模拟从开庭到结束的整个法庭流程。智能体可以采集不同法官和主控律师的言辞，并让每个智能体扮演不同角色。这样，我们可以将公司500名律师都训练成智能体，通过大模型在多智能体环境中进行500次模拟。如果不够，可以让每人模拟10次，共5000次。最终，我们可以评估在虚拟法庭过程中，哪位律师的胜率最高。通过这种方式，我们能够高效地筛选出表现最优异的律师。

Multiagent系统能够筛选出非常优秀的人才，使其参与商业或法律活动。这样的多智能体系统才能真正体现其价值，而非简单地在前端进行意图识别，后端调用或不调用工具，最后输出结果。这种做法过于基础，缺乏深度。

当我们将多智能体系统与业务场景结合时，其价值才能真正显现。例如，在符合公司目标的情况下，我们可以利用该系统提高胜率。当面临多种律师选择时，该系统能帮助我们做出更优决策。

此外，多智能体系统不仅可以作为我们的合作伙伴，还能扮演对方辩护律师的角色。通过让智能体扮演特定人物（如蓝军），我们可以与其进行对抗训练，并基于其反馈对我们的策略进行二次优化。这才是多智能体系统真正的价值所在。

多智能体系统的应用远不止于客服或电话转接等简单场景。在法律、金融、物流判责等多个领域，它都能发挥重要作用。特别是在物流判责场景中，我们需要基于时序因素进行深入分析。

在展开讨论时，我们需要梳理整个流程：商家发货后，商品经过哪些快递公司和驿站，最终送达用户手中。

如果用户需要投诉，客服会要求补充面单信息和快递编号。我们需要将这些流程节点细化，并考虑如何让智能体模拟不同节点的功能。

无论是出租车调度、物流配送，还是多节点场景，都可以采用这种思路。关键在于不仅要关注智能体的意图识别能力，更要解决节点间的协调问题。

这幅流程图值得深入研究，我将放大展示以便大家更好地理解。

接下来我将详细阐述企业智能体（Agent）所面临的挑战。正如刚才同学提到的，首要挑战是Agent之间的通信问题。具体而言，如何确保失败重试机制的有效性？包括重试次数的设定。

此外，还需要解决Agent间的交互过程管理问题，例如如何监管Agent的行为，以及在其完成当前任务后，能否按照既定流程继续执行后续操作。

我们可以进一步拆解这个问题。放大来看，当用户提问“为什么订单还没发货”时，工厂排产的情况也可以纳入考虑范围。正如刚才分析的模拟法庭流程所示，系统中的Agent可以处理这类问题，例如用户询问订单未发货原因时，工厂排产Agent就能发挥作用。

我需要一个意图识别模块，用于将问题拆分到不同的流程中。假设系统能够正确理解用户的问题，主Agent将接收并处理该问题。

当用户询问订单未发货的原因时，我们需要识别其真实意图。

在排产环节中，主要目的包含两方面：一是满足人际协作需求，二是实现实际生产需求。其中，人际协作需求是AI目前无法解决的领域。

其中较为典型的业务场景是排班。早期曾有人提出AI自动排班系统的概念。排班的主要目的在于帮助管理者解决员工频繁请假和人员协调困难的问题。

然而，这类问题无法通过大模型智能体解决，因为涉及过多的人情因素和管理能力体现，并非简单的规则性排班操作。

在工厂排班环节，系统具有明确的目标：通过优化排班方案，在既定投入产出比条件下实现更合理的资源配置，从而提升产出效率。至于用户未发货的情况，其核心诉求并非要求道歉，而是希望了解具体原因。

实际上，他更希望了解订单卡在哪个环节，以及哪些客户可以自主推动相关流程。根据他的预期，当前系统未能实现这些功能。因此，他需要明确自己的预期目标，并希望获得超出预期的解决方案。

这是一个有明确目标和结果导向的需求，这正是多智能体系统能够实现的功能，否则就只是玩具。接下来让我们具体分析。

需要查询对应的任务列表，例如订单状态，以确认是否如所述确实未收到。

在实际操作过程中，许多从业者往往忽略了一个关键环节——订单状态查询。

通过系统查询订单当前所处环节后，需基于查询结果，以平和的沟通方式向客户致歉，并清晰说明当前流程卡点。

这一步骤本质上是预先设计的兜底机制，旨在准确定位订单当前状态。

近期，我们观察到数字人技术的应用案例。通过提示词指令，数字人持续发出猫叫声的新闻引发了关注。

这一现象反映出当前数字人系统存在两个关键问题：

系统未能充分理解用户提示词的潜在意图；
缺乏必要的安全机制和容错设计。

这种技术缺陷直接导致了系统行为与用户预期严重偏离的情况。

数字人发起请求后，会直接执行操作。这对于程序员而言是不可接受的。软件测试为何未能发现此类问题？对于大模型而言，若不考虑特定逻辑路径，确实难以检测此类问题。因此，首要任务是确认事实。

接下来，我们将基于事实判定物流的具体卡点位置，并根据该位置与用户进行沟通。基于沟通结果，我们将做出相应承诺。承诺遵循固定规则与动态规则，例如可考虑让Agent向客户发放红包。

应当送达但未送达时，我们需要提升用户满意度。此时若缺乏左侧功能，用户会通过提示词话术反复请求。例如，询问Agent能否发放100元红包，金额甚至超过商品价格。这反映出当前多智能体设计中普遍存在的漏洞。

确实如吴同学所言，系统缺乏边界处理功能。这些本是我们特别擅长的领域，但在大模型中却未被实现。因此，我们需要将这些能力整合进去。

此外，在multiagent系统中，我们还可以进行以下优化：

首先是agent角色的明确定义。
其次是群聊功能的实现。

关于轮流发言机制的实现，可以参考虚拟法庭的模式。

在达成共识判断后，如何触发下一步行动？当需要选择最优解决方案时，可通过多个智能体相互投票来确定最优解。此外，提升决策准确性也是可行的方案。

左侧部分的内容……

这里涉及状态管理，例如用户查询中途离开或某个节点崩溃时，任务是否需要重新分配。

同时需要考虑消息传递机制，包括信息加密方式。此外，能否基于long graph自定义流程也是需要考虑的因素。

消息队列的通信机制同样需要纳入考量。

这些内容大家已经非常熟悉了。关于微调和扩容机制，都可以通过我们的方案来提升多智能体系统的稳定性。正如Tank同学提到的，还需要考虑prompt的安全处理。这些因素都需要综合考虑，才能打造出真正可落地的智能体解决方案。

因此，在实际应用工程法落地时，我们面临诸多挑战。为解决这些问题，需要分离关注点，从不同角度进行考量。

接下来，我将内容拆分为模块化设计，从模块二到模块八，涵盖深度学习理论等内容。

在数据工程和智能客服领域，针对多Agent协作的通信机制，如何提升表达的灵活性是一个关键问题。具体而言，是调用SQL、JSON还是直接访问数据库，这些选择都至关重要。此外，DSL的生成能力以及Agent的构建能力也是需要重点关注的方面。

在部署和服务优化环节，我们可以将案例拆解为多个模块。首先展示整体架构，随后分解为各个功能模块，类似于拼图的小块。每个模块中会涉及架构设计中的核心关键词，这些概念对于大家而言已经非常熟悉。

通过这些关键词，我们可以探讨大模型带来的价值，并与传统工程方法进行比较。需要评估这些价值是否发生了变化，或者是否存在价值迁移的现象。对于大模型而言，这些方面的考量尤为重要。

在这一领域中，我们面临诸多难点与挑战。

首先，整体架构呈现为总分结构，后续内容将在此基础上展开。在具体落地实施时，部分能力需要从模型中抽离出来。

考虑到开发团队主要使用Java和Golang等语言，但当前主流框架如LangChain和LlamaIndex均采用Python编写，因此需要额外补充编码能力，特别是多进程与多线程相关的技术实现。

Identic用于数据校验，以及GL的影响、线程池等性能对比。此外，还涉及代码静态分析能力。这些能力实际上是对编码硬实力的考量。如果无法编写程序，其他努力都是徒劳的，正如”show me the code”所言。

我认为还需要补充项目能力。因此，最后我将把这些内容集成到一个完整的项目中，展示多Agent工程化案例。案例将选择法律、金融、医疗等领域。选择这些领域主要基于投入产出比考虑。例如，金融分析师和律师的薪酬较高，通过Multi Agent技术，可以让大模型处理这些高薪人员的简单工作。

为了让大模型表现更好，需要进行数据清洗等工作。虽然这项工作繁琐，但我们可以考虑将这部分预算用于外包。同样地，在律师事务所，律师的高薪使得他们不太可能进行对练等工作。解决方案是将对练成本用于构建大模型，通过大模型替代高收入人群完成基础工作，从而释放他们的时间去做更重要的事情。这正是大模型能带来的真正价值。

能够落地的价值在于，首先出发点要正确，目标要明确，这样大模型才能体现出其实际意义，而非沦为玩具。其次，需要补充项目能力。第三点，我想强调的是产品能力。许多伙伴开发的功能，无论是玩具还是演示项目，往往难以体现其核心价值。因此，我会在最后简要补充AI产品设计的方法论，包括需求分析阶段、原型设计阶段、用户反馈迭代等关键环节。

基于个人工作经验，我将通过具体案例来展示实际应用场景：合同审核、公文生成、金融领域的智能客服、医疗领域的工作流优化，以及法律领域的多智能体系统等。我们将分析用户真正愿意付费的领域中，智能体的实际应用情况，以及甲方提出的严苛需求。

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？别再浪费时间啦！2025 年 AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇