作者：京东零售 杨兵

前言

自 2022 年底 ChatGPT 发布以来，大模型成为非常火爆的话题。如何在生活和工作中把大模型用的更好、更具价值，业界一致认为 Agent 是其中一个重要的方向。下面就分享一下我们京东广告在 Agent 应用上的一些实践和经验，希望能给大家带来一定的启发和思考。

一、Agent 在京东广告投放中的应用

1、Agent 是什么

既然是讲 Agent 的应用，还是要先来普及一下基本概念，一句话简介：

Agent 是以大语言模型为大脑驱动，具有自主理解感知、规划、记忆和使用工具的能力，能自动化执行完成复杂任务的系统。

2、Agent 能做什么

接下来，用一个小小的案例来让大家更直观的感受到，Agent 和大模型的区别。

举个栗子：一个工作中用到的高频场景—预定会议室，假如今天有个会议计划在 15-16 点，需要定个会议室。

现有的方式： 通常要先打开办公软件，其次打开会议室预定应用，然后选择期望的会议室楼层或区域、会议时间，进行筛选，如果找出多个，再找出离自己最近或者最方便的一个，进行预定。

那么，如果我们希望借助大模型来帮我们提效，计划通过一句话就实现会议室的预定：我在 12 层，帮我找个 15-16 点的会议室，尽量近一点

如果单纯靠大模型是无法帮我们解决这个问题的，它大概率会回答：”要找到离你最近的会议室并了解其可用性，通常需要使用公司内部的会议室预订系统或办公软件，如 Outlook、Google Calendar 等。以下是一些建议步骤…“

如果利用 Agent 的方式，就可以很好的解决这个问题：

1、在 Agent 中，我们有一些工具，其中包括：查找会议室（可以时间等条件查询可用的会议室）、预定会议室（根据会议室 ID、会议室时段等信息预定会议室）。

2、当 Agent 收到我们的需求时，会先用大脑（大模型）思考，大脑综合各种信息（历史的记忆、拥有的工具能力等）进行推理并规划要做哪些行动。

3、大脑告知 Agent 需要先调用【查询会议室】的工具，并给出调用参数（预定时段等）。

4、Agent 执行调用，完成后将结果给到大脑继续思考。

5、如果有可用的会议室，大脑会告知 Agent 调用【预定会议室】工具，进行预定。否则，会根据查询到的会议及空闲时段给出一些可用的建议，如下图。

相信通过上面这个案例，大家能更真切的感受到基于大模型的 Agent，会有非常大的想象空间及广泛的应用场景。

如果我们将上面的案例再进行一些扩展，增加会议邀请的工具，那么就实现了一个小型的会议助手 Agent。可以帮我们实现几秒钟就完成一个现在大约几分钟才能完成的事情。

3、Agent 在广告投放中的应用场景

以上，我们对 Agent 有了一定的了解，接下来就介绍一下我们京东广告投放业务在 Agent 应用上的一些实践。

首先，介绍一下 Agent 在广告投放中的两个主要的场景：

3.1、服务提效

背景

京准通作为专业的广告投放平台，每天有几十万的京东商家在此进行广告的投放，以获取更多的 C 端流量达成更高的商品销售量。

如此庞大的商家量级，在使用过程中，每天都会有各类商家的各种各样的问题，之前，所有用户的问题都会走到人工客服上，人工客服会根据产品、运营提供的一些资料为用户解答，对于客服无法解答的问题（如：功能异常、数据异常、政策咨询等），再转给产研侧跟进解决。

痛点

这种方式主要的问题：1.咨询高峰，通常需要排队等待，问题解决效率低，商家体验不好。2.人工客服成本高。

方案

针对这些问题，我们期望利用大模型打造一个智能客服，由智能客服承接用户的问题，智能客服无法解答的再转到人工客服，最后对于棘手的问题再转给产研跟进。

收益

该方案的主要收益：1.智能客服无需排队，秒级作答，可明显提升用户满意度。2.可明显减轻客服压力，节省客服成本。

3.2 盯盘提效

背景

在广告投放中，广告主通常需要创建广告物料，然后不断观察效果数据，及时调整投放策略，以获得更好的投放效果，整个过程我们称之为“盯盘”。

痛点

查数、物料创建、物料编辑是广告主最高频的操作，当前广告主进行多种操作时需要跳转多个产品线进行很多步操作才能完成，盯盘效率低。

方案

利用 Agent 的工具调用能力，为广告主提供一些智能指令，比如，一句话查询自定义数据：查询上个月各产品线的数据。

收益

智能指令的使用将明显提升广告主盯盘效率，比如查询上个月各产品线的数据，在之前，用户需要跳转多个界面，进行多次操作才能完成，使用智能指令后，仅需一步即可。

有了大致的思路和方案，基于此前的技术调研，我们需要构建 RAG 和 Function call 能力来分别支撑智能客服和智能指令。

接下来就详细介绍这两个能力的技术实现。

3.3 RAG 能力的构建

RAG 模块主要包含两部分，分别是：离线知识构建、在线推理引擎。

离线知识构建

主要的工作是将知识转化为向量并存储。主要几个步骤，如下：

1.产品/运营将相关业务的知识整理成文档（Markdown、Excel 等）

2.根据不同格式和切割方式将内容切割成若干个内容块

3.调用 embedding model，进行内容向量化

4.将向量存储至京东 Vearch 向量库

Embedding 模型有很多种，不同模型之间维度不一样，常见的有 1024、1536。向量存储时通常要创建表空间，创建时需要确定维度。所以最好先确定好向量模型再进行存储空间的创建。

在线推理引擎

提供实时在线服务，主要作用是检索相关知识并调用大模型解决问题。主要几个步骤，如下：

1.收到用户 Query，调用 embedding model，进行向量化，获得向量

假如，用户的问题： 搜索快车关键词设置

2.根据向量，调用 Vearch 接口，进行知识检索，获得和 Query 相关的知识

{"docs": [    {        "_id": "8684356582637079690",         "_score": 0.7526149153709412,         "_source": {            "content": "搜索快车-搜索快车投放要素-定向设置（关键词定向、商品定向）-关键词定向-功能入口 \n搜索快车->新增/编辑快车推广单元->添加关键词；\n- 搜索快车->计划->单元->关键词设置->添加关键词。",             "status": 1,             //更多字段...        },     },     {        "_id": "-1119433630625640889",         "_score": 0.7362563610076904,         "_source": {            "content": "搜索快车-搜索快车投放要素-定向设置（关键词定向、商品定向）-关键词定向-关键词投放策略-关键词批量添加功能（推广管理模块）\n添加关键词时，可在同个计划中选择不同单元，针对多个单元批量添加同批次的关键词，提升您的买词效率。",             "status": 1,             //更多字段...        },     },     {        "_id": "-2002741349177277662",         "_score": 0.7218812704086304,         "_source": {            "content": "搜索快车-产品操作指南-创建计划-普通计划-商品推广-定向设置-关键词\n添加关键词：点击添加关键词，弹出侧滑框进入买词界面；\n- 购买关键词：有以下几种买词方式\n- 商品推词：根据SKU ID，系统自动推荐关键词，可以选择热搜词、潜力词、捡漏词；\n- 核心拓词：根据输入的关键词，系统自动拓展；\n- 手动输入：手动一个个输入关键词；\n- 导入关键词：通过Excel批量导入；\n- 用词记录：自动识别单元下历史购买过的关键词；",             "status": 1,             //更多字段...        },     }    //更多知识...]}

3.拼接提示词，由于检索到的结果是 json，要让模型更方便理解，需要处理成特定的格式

//这里不方便展示业务真实的提示词，提示词的书写格式多种多样，以下仅提供大致思路
请根据信息"""搜索快车-搜索快车投放要素-定向设置（关键词定向、商品定向）-关键词定向-功能入口- 搜索快车->新增/编辑快车推广单元->添加关键词；- 搜索快车->计划->单元->关键词设置->添加关键词。
搜索快车-搜索快车投放要素-定向设置（关键词定向、商品定向）-关键词定向-关键词投放策略-关键词批量添加功能（推广管理模块）添加关键词时，可在同个计划中选择不同单元，针对多个单元批量添加同批次的关键词，提升您的买词效率。
搜索快车-产品操作指南-创建计划-普通计划-商品推广-定向设置-关键词添加关键词：点击添加关键词，弹出侧滑框进入买词界面；- 购买关键词：有以下几种买词方式- 商品推词：根据SKU ID，系统自动推荐关键词，可以选择热搜词、潜力词、捡漏词；- 核心拓词：根据输入的关键词，系统自动拓展；- 手动输入：手动一个个输入关键词；- 导入关键词：通过Excel批量导入；- 用词记录：自动识别单元下历史购买过的关键词；"""回答问题"""搜索快车关键词设置"""

4.调用大模型接口，传入拼接好的提示词，获取结果返回给用户。

{"output": "在搜索快车中进行关键词设置的步骤如下：\n\n1. **添加关键词**：\n   - 进入搜索快车 -> 新增/编辑快车推广单元 -> 添加关键词；\n   - 或者进入搜索快车 -> 计划 -> 单元 -> 关键词设置 -> 添加关键词。\n\n2. **购买关键词**：\n   - 点击添加关键词，弹出侧滑框进入买词界面；\n   - 有以下几种买词方式：\n     - 商品推词：根据SKU ID，系统自动推荐关键词，可以选择热搜词、潜力词、捡漏词；\n     - 核心拓词：根据输入的关键词，系统自动拓展；\n     - 手动输入：手动一个个输入关键词；\n     - 导入关键词：通过Excel批量导入；\n     - 用词记录：自动识别单元下历史购买过的关键词。\n\n3. **关键词批量添加**：\n   - 在同个计划中选择不同单元，针对多个单元批量添加同批次的关键词，提升买词效率。..."}

知识召回的问题

第一版的 RAG 能力在实际应用中，遇到两类问题：

一、我们认为更相关的知识未召回

对于【京准通切词匹配】这个 Query，我们认为更相关的内容（搜索快车切词匹配 \n 当用户发起搜索时，根据不同的匹配模式可能展现不同的 xxx），相关性不够无法召回。

向量召回的分数与相关内容密度强相关，理论上密度越高，相关分值越高，下面有个示例更直观的说明一下。

以上的例子只是为了让大家更直观了解向量检索，实际中，模型可能并不会认为【京准通】是独立词。同样，影响结果的因素有很多（向量维度、切词、向量矩阵转换算法、分值算法等），如果要改变模型对某些特定内容的行为，常见的做法是微调。（后续再学习探讨）

通过以上例子可以看到，提升相关内容密度，也是提升知识召回率的一种手段，且门槛和实现成本较低。

我们的方案是：将同一块知识，按照【概述+内容】分别存两份向量，在召回阶段，按照概述和内容分别进行召回，然后去重。其中概述内容较短，也就意味着密度较高，更容易获得高的相关性。

还有一种场景，在对用户问题分析中，发现有一部分广告主提出一些【智能计划】相关的问题（对于搜索快车或推荐广告的智能出价的计划的习惯性简称），由于广告投放产品中有一个叫做智能投放的产品，在知识召回的时候大部分召回了智能投放相关的知识，导致无法正确回答此类问题。

我们方案是新增一路 ES 检索，ES 分词时设置特定的同义词、专用词、否定词。比如：

同义词：智能计划 => 智能出价计划（解决用户习惯的问题）、 购物触点 => 推荐广告 京挑客 => 京东联盟 （解决产品线升级改名的问题）

收到请求后，分别通过向量和 ES 检索，最大化提升召回率。

更多 ES 检索技术实现细节，请看： 《广告智能助手Agent混合检索技术实践》

二、召回部分无关知识影响模型作答效果

通过以上一些手段，有效提升了知识召回率，但是引发了另一个问题，部分知识不相关，会误导模型，影响模型作答效果。

这里方案是引入 ReRank 模型，在知识召回后，调用算法侧部署的 ReRank 服务，对知识进行重排序，过滤无关知识。

通过以上多种能力的引入，RAG 的能力也逐渐演变为下图：

3.4 Function Call 能力的构建

Function Call 的能力主要是为了服务智能指令，比如：提供一个计划数据查询的工具，当用户发送【查询今天 ROI > 10 的计划】，模型会返回 Function Call 标识，包括 function name 及 arguments，调用成功后，用对应的组件渲染出来报表。

同样包含两部分，分别是：工具能力注册、在线推理引擎。

工具能力注册

该模块主要工作是将工具的信息管理起来，主要包含三部分信息，分别是：

1.模型感知的信息：主要作用是给模型做推理，名称、参数、描述，为了让模型推理更准确，描述的内容我们做了拆分，由基本描述、扩展描述、示例指令几部分组成，下面是一个工具给模型的信息示例：

{    "type": "function",     "function": {        "name": "query_xxxx_data" //名称        "description":             "根据ROI、时间....查询广告计划数据" + //基本描述            "这是一个查询计划数据的工具，可以根据..." + //扩展描述            "示例指令：\n- 查询今天ROI > 10的计划数据\n -查询上周..." //示例指令        "parameters": { //参数            "type":"object",            "properties":{                "startTime":{                    "type":"string",                    "description":"开始时间，格式yyyy-mm-dd"                },                "endTime":{                    "type":"string",                    "description":"结束时间，格式yyyy-mm-dd"                },                "roi":{                    "type":"string",                    "description":"ROI（投产比）查询条件，如：“ge|3”代表大于等于3。gt-大于，lt-小于，eq-等于，ge-大于等于，le-小于等于"                },                "cost":{                    "type":"string",                    "description":"消耗（花费）查询条件，如："lt|500"代表小于500。gt-大于，lt-小于，eq-等于，ge-大于等于，le-小于等于"                }            }        }    }}

2.后端感知的信息：正常情况下，工具的执行其实是调用了后端的接口，那么就需要接口地址、接口入参、接口出参、成功条件等信息。其中接口的入参和模型感知信息中的参数是同一份数据。

{    "url": "http://xxx.jd.local/xxx", //接口地址    "success":{//成功条件        "condition":{            "from":"code",            "operator":1,            "target":1        },        "data":"data"    },    "params":[//出参        {"key":"code","type":"integer","description":"code码"},        {"key":"msg","type":"string","description":"错误信息"},        {"key":"data","type":"string","description":"返回给前端数据"}    ],    "error":{"msgType":1,"msgKey":"msg","msgContent":""}}

3.前端感知的信息：工具调用成功后，通常有多种处理方式：1.把结果直接返回给用户。2.把结果给到模型，模型继续做推理，同时可以再定义 Prompt。3.将结果使用组件渲染给用户。

我们为广告主提供的工具大部分都要用组件进行渲染，比如数据报表。当工具需要和组件结合的时候，需要考虑组件的配置化和复用率，这里我们打通了既有的低代码平台，会将组件的信息保存下来。

{"pageData":[    {        "name":"数据表格",        "componentName":"jad_ReportTable",        "jsUrl":"jadfe/xxx/ReportTable.6a3493f4.js", //组件CDN地址        "options":[//组件配置            {                "key":"columns",                "type":"list",                "name":"列设置",                "options":[{"key":"title","name":"列名称","type":"input"},{"key":"key","name":"字段key","type":"input"},{"key":"width","name":"宽度","type":"inputNumber"},{"key":"sort","name":"排序","type":"switch"}],                "value":[{"title":"计划名称","key":"campaignName","width":110},{"title":"产品线","key":"businessTypeStr","width":110},{"title":"时间","key":"date","sort":false},{"title":"展现数","key":"impressions","sort":true}],        }],}

在线推理引擎

提供实时在线服务，主要作用是组装工具信息调用大模型进行推理。主要几个步骤，如下：

1.收到用户 Query，从数据库读取工具信息

2.将工具组装成模型需要的格式，组装 Prompt，调用模型

3.如果模型返回 Function Call 标识，通过标识中的 function name 找出对应的工具，调用该工具的接口

4.根据结果的展示行为，有以下几种处理方式：

4.1 给到模型继续作答，同时可自定义 Prompt，适用的场景如下

用户问题：查一下账户还剩多少钱
接口结果：{"data": {award: 20, cash: 100}, msg: ""}
显然，直接把json中data的结果给到用户，是不合理的。这个时候就适合给到模型去作答，但是模型不理解award和cash在系统中表达的意思，会按照自己的理解去作答，如下：账户中有两种形式的余额：奖励余额：20  现金余额：100
但实际award在系统可能意思是红包余额，这个时候就需要额外定义Prompt：award代表：红包余额，cash代表：现金余额，单位：元
最终确保能比较完美的回答用户问题。

4.2 直接返回结果，适用的场景如下

用户问题：这个优惠券：742382343 为什么不生效，SKU 123456789
接口结果：{"data": "未生效的原因是xxx"}
这种情况下，适合直接将data字段反给用户。

4.3 返回结果并需要用前端组件渲染，适用的场景如下

用户问题：查询今天ROI > 10的计划数据
接口结果：{"data": [{"id": 123, "campaignName": "计划-A", "ROI": 12.85},{"id": 456, "campaignName": "计划-B", "ROI": 10.25}]}
这种情况，适合用一个表格去更直观的呈现数据，这就需要返回接口结果同时还要返回相关的组件数据。

5.前端将返回的内容展示给用户，如需要组件，动态加载组件的 CDN 地址，完成渲染。

工具调用的问题

广告投放业务场景多，如果要给用户提供完整或精细化的盯盘能力，势必需要提供多种多样的工具，那基于以上的工作流程，会有个问题：每次请求都把所有工具给模型，当工具比较多时，可能会超出模型 Token 限制，其次，如果是收费的商业模型还会造成一定的费用的浪费。

对于该问题，我们参考了此前做 RAG 的思路，做法是将工具的基本描述和示例指令，分别存成向量，请求进来时候，使用向量先进行工具的召回，再进行拼接给到模型。

这样能明显减少给模型无效工具的输入，节省了 Token 和费用，也可以有效减少模型的幻觉几率。

3.5 能力的演变

将以上各种能力整合，最终能力演变为下图。这一版底层我们采用了 Langchain 框架。

3.6 京东广告智能助手

基于以上的能力，构建了京东广告智能助手。包含了问题解答、数据查询、物料创建、物料编辑等场景。

体验地址：https://jzt.jd.com（需要商家账号）

在支撑广告智能助手落地中，除了以上一些核心能力的构建，也有很多细节的优化，比如：

指令中日期的准确性优化

查数指令中常见的一些日期，如：今天、昨天、上个月、本月、近七天等，需要推理出正确的日期范围，才能确保数据的准确。

模型通常是有训练日期的，无法正确回答日期问题的，对于这个问题，解决的思路是，每次请求模型时，动态生成几组日期的说明，让模型能正确推理时间。

如：今天是 2024-11-xx，近七天的日期范围是 2024-11-xx~2024-11-xx...

二、基于业务沉淀 Agent 搭建平台

以上就是广告智能助手业务从 0 到 1 的过程，可见一个大模型应用真正应用到生产环境中，是比较复杂且有非常大的工作量的，我们在思考，如果广告内有其他的业务场景，是否能实现一些能力的快速复用？

与此同时，随着业务效果的优化进入深水区，我们需要通过对工作流程更精细化的编排来进行效果的优化。

综合以上考虑，我们决定将已有的能力增强并沉淀一个 Agent 搭建平台，以下是整体架构。

基建： 主要是公司的基建，提供一些基础能力，如：向量库、ES、OSS、Mysql、CDN 等等

Agent 设计器： 主要是提供 Agent 可视化的设计能力，包括智能体、知识库、工具库、记忆库、工作流等核心功能。

Agent 引擎： 主要是根据设计器产生的配置，动态运行工作流程，如：知识的召回、提示词的加工、模型的推理、工具的调用、代码的执行等等。

端能力： 主要是面向用户的对话式组件，这里我们沉淀了一套 AI 组件库，可快速组装出兼容 PC、H5 的对话框。与此同时，针对内部的京 ME 办公场景，对外如微信中的场景，我们也通过 API 调用的方式进行了支持。

应用场景： 有这些能力，就可以轻松的利用平台支撑起各种 Agent 应用，包括我们的广告智能助手。同时除了业务之外，还可以做内部提效的 Agent 应用。

1、Agent 设计器

团队空间为了方便协作和做业务隔离，团队空间下，可以进行智能体的搭建、知识库的管理、工具库的管理、工作流的编排等等。

知识库中，可以选择不同的向量模型，方便做召回优化的实验。

工具中，可以设置模型感知信息、接口、参数、组件等。

工作流中，可以随意拖拽编排工作流程，比如：召回节点可以设置召回策略、召回数量、最低分值等；大模型节点可以设置 System、User 提示词、历史会话轮数等。

2、Agent 引擎

Agent 引擎负责和模型交互，是影响效果和性能的核心模块。我们做了重点的设计和重构。在设计阶段，我们考虑的首要问题是：Langchain 的取舍。

相信做过大模型应用开发的同学，都听说或者使用过 Langchain。

Langchain 框架提出了 LCEL 语法，将 Prompt、LLM、Tool 等概念进行了抽象并高度封装，能快速上手并实现一些 Demo，对新手比较友好。

然而，随着业务的复杂度不断增加，以及对模型的了解不断深入，会发现，Langchain 的过度封装，把很多简单的事情变的更复杂了，明显影响了业务自由度及开发效率，同时也带来了一定的性能损耗。举个例子：

工具调用中，模型接受的参数是一个 JSON Schema，我们只要将工具参数存成一个 json 用的时候就会非常方便。

然而，如果使用 Langchain，就需要先将 json 转成一个 pydantic 类，再使用 Tool 类进行工具的注册，在调用模型时，Langchain 又会转换成 json。

本来一行代码就可以搞定，使用 Langchain 后需要几十行代码才能实现，并且带来了一定的性能损耗。

最终，我们决定移除 Langchain 框架，直接用原生 python 实现，仅保留个别用起来比较方便的工具，如：文档切割。

整体上，设计了一套工作流调度器，并将所有节点实现了组件化。收到请求后会初始化一个工作流调度器，调度器根据时机来操作每个节点的执行。工作流详细实现： Agent Workflow技术实现揭秘

3、端能力

端能力主要是沉淀了一套 AI 组件，包括：内容输入、指令联想、输出卡片等组件。可快速构建多端兼容的对话式应用。

三、Agent 平台赋能研发提效

有了 Agent 搭建平台，可以分钟级搭建大模型应用，同时，工作流的能力也大幅加速了策略迭代速度。在广告智能助手业务中，也进行了多项策略的优化并应用在大促中，带来了不错的效果提升。同时，我们也基于 Agent 平台做了一些研发提效的实践。

1、客诉处理

前面提到，在京准通中商家的部分问题接入人工客服后，客服侧无法解答的问题会流转给产运研来跟进。

客诉的处理时效会直接影响客户满意度，也会间接影响商家在投放广告时各平台间的预算分配，至关重要。因此，对于客诉的处理需要响应及时、快速解决。

现状： 当前，为了尽量提升处理时效，产运研和客服在一个约 400 人的咚咚群里，客服发出问题后，产运研团队看是谁的问题，分别进行跟进。

痛点： 所有人需要花较大精力聚焦于客诉群，只要有消息就要点进去看一眼，是不是自己的问题，要不要跟进。研发变相成了客服的客服，工作体验较差，明显影响工作效率。

理想的情况是人工客服收到客诉后，提工单给产运研，产运研进行流转跟进。但是为什么会演变为现状？

根本原因： 提工单，对客服团队会有一定的负担，首先，客服提工单，需要了解每个问题属于哪类问题，每类问题应该提给谁，加上客服团队人员变更，新人来了，都要学习一套提工单的流程，还是有不小的成本的。其次，对于客服团队来说，有时候沟通一个工单的提交过程就需要花一定的时间，会直接影响客诉处理时长。

目标： 在不增加客服团队负担的情况下，提升产运研工作效率和工作体验，同时提升客诉解决效率。

方案：

1、客服只需发送客诉内容给客诉处理 Agent，减少客服负担。

2、Agent 通过大模型分析，自动提交工单给相应同学，大幅提升工单流转效率。

3、Agent 通过对客诉分析，部分客诉实现自动化解决，提升解决效率，减少研发投入。

3.1 对于产品及运营问题能利用知识库解答的问题，会直接发布工单评论，如解决，只需点击完成即可。提升解决效率。

3.2 对于研发问题，会识别是否可以用自动化排查工具，可以的话执行自动化排查并给出答案，发布工单评论，如解决，只需点击完成即可。否则研发介入排查。

有了方案，我们借助 Agent 平台能力搭建了客诉处理 Agent，以下是主要的工作流程

成果： 通过搭建的客诉处理 Agent，目前已经可以实现根据客诉内容自动化提交工单。自动化解决方面在逐步完善知识库、排查工具的建设，后续将带来更明显的收益。

2、Code Review

Code Review 在业界已经有了比较多的实践，不过，如何把投产比做到符合预期，同时确保代码的安全，是需要重点关注的。

考虑到资源成本，人工复审成本等因素，我们的目标是：流程自动化、采纳率优先。

流程自动化

主要是借助 Git 的 webHooks 及接口实现全流程的自动化。

大致流程如下：

1、CR Server 提供一个通用接口，需要做 CR 自动化的项目注册到 webHooks 中即可

2、当发起 merge 的时候，会调用 CR Server 接口，CR Server 收到请求后，调用 Git 接口获取 diff

3、处理 diff，调用 Agent 接口，执行 Agent 平台搭建的工作流，进行 CR

4、处理返回结果，调用 Git 评论接口，完成 CR 流程。

工作流搭建

工作流搭建的过程中，我们也进行了一些提示词优化的过程，通过在提示词中增加 few shot 的方式，可明显提升结果的可用率。

其中，few shot 的内容是我们通过日常 review 积累的一些案例，这些案例包含了 9 种类型，共 40+个，如果都输入给模型，会带来其他问题：1、提示词内容过长，模型容易产生幻觉。 2、内容过长，可能会触发输入输出限制。

针对这个问题，我们的思路是按照类型拆分，每个模型节点只负责一种错误类型的查找。

通过以上的方式，可以最大限度的减少请求失败的概率，同时由于让模型做的事情更聚焦，能产出更有价值的结果。

四、未来展望

1、大模型推动行业壁垒逐步降低

大模型将推动更多的方法论实现产品化，通过产品化的形式，将极大提高生产力，降低行业门槛。

比如，拿程序员这个行业来说，之前或者现在的门槛还是比较高的，未来，随着代码模型微调、无代码设计等方法论的沉淀，可能会出现一种非常容易上手的产品，只需要导入代码库、设计文档等内容，就能开始通过对话式的方式完成功能的开发。极大降低了软件开发的门槛，这样，只要会使用 AI 的人就能轻松达到熟练级别。

同时，有了大模型的加持，可以让部分人进入到精通或者专家的行列中。

当然，短时间内大模型并不会替代程序员，但在实际工作中，善于使用大模型的同学在效率上已经有明显的提升表现。未来一定是更会利用 AI 的人，更具有先发优势。

同时，通过以上的思考，后续我们也会在 Agent 平台中将更多的方法论进行沉淀。下一步，我们会尝试如何将模型的微调，形成产品化，让更多非算法人员也能轻松的调教自己的模型，当然这其中有很多的困难需要克服，总之，道阻且长，行则将至！