# AI Agent 如何真正赋能业务？两大实战案例与工程融合实践指南 随着人工智能技术的持续演进，如何让 AI Agent 在企业真实业务场景中落地并创造实际价值，已成为众多技术团队面临的迫切课题。脱离业务场景的技术创新，往往容易沦为“空中楼阁”。本文将分享我在淘天集团将 AI Agent 与工程实践深度融合，并成功应用于**智能播报助手**与**批量建任务**两大业务场景的完整历程，最后总结出 Agent 与工程选型融合的核心法则。希望通过这些真实案例，帮助你在技术与业务场景之间找到最佳结合点。 ## 一、Agent + MCP 打造智能播报助手 ### 1.1 业务背景与问题 在日常工作中，我们经常需要制作或使用大量统计报表。淘天会在一个数据产品上制作报表，制作好的报表需要由关心数据的同学每隔一定周期去查看数据是否出现异常。典型的场景包括：每天上午 10 点查看表 A 的数据，或者在大型促销活动期间每半小时查看表 B 的数据。 定时查看报表的整体流程，简单概括就是：打开网页 → 找到异常数据 → 基于异常数据采取某些行动。现有的平台（如 FBI）虽然有定时播报能力，但仍然存在以下三大痛点： - 表格类型报表只能播报图片：若要导出报表数据，只能选择“邮件格式”，并且只能把数据导出为 Excel 格式。如果要用工程（编码）去处理，就需要为每一个表格类型定义接收对象，非常繁琐。 - 文本类型报表的异常播报能力有限：虽然可以定义异常指标，但只能修改异常指标的展示样式。无法满足“只有当某指标出现异常时才播报给某些特定联系人”的需求，并且无法基于异常数据执行后续动作。 - 无法获取加工过的中间数据：虽然底表的数据可以直接获取，但无法拿到 FBI 平台加工过后的数据（如日环比）。 举个例子，假设我们在下图中定义了异常数据为“指标1 < 10% 或指标2 < 30%”。同学甲只关注 A-aa1 的数据，同学乙只关注 A-aa2 的数据，同学丙只关注 B-bb1 的数据。理想的情况是：在周期到达时，系统能自动向同学甲和同学丙播报异常数据，甚至基于异常数据执行下一步动作。遗憾的是，FBI 平台目前做不到这一点。 ### 1.2 MCP 介绍 事情的转折点在于 LLM 的不断进化以及 MCP 的横空出世。 MCP（Model Context Protocol），翻译过来就是**模型上下文协议**。简单来说，它定义了一套标准规则，让 LLM 模型能够安全、有序地访问和使用各种外部资源，从而大大扩展 Agent 的能力边界。 MCP 中有两个重要的角色： - **MCP Server**：提供各种各样的能力与工具。 - **MCP Client**：MCP Server 的调用者。 > **小提示**：把 MCP Client 想象成 DVD 播放器，而 MCP Server 就是不同的碟片。不同的碟片有不同的内容（能力），但你不能在 DVD 播放器里放入磁带（不符合 MCP 规范的 Server）。在 AI 场景下，MCP 就是给予 Agent 通用调用各种工具的能力。 可能有些同学会好奇：让 Agent 调用工具，难道是很新的能力吗？其实不是，工具调用（Function Calling）是早于 MCP 提出的能力。但在只有 Function Calling 的时代，不同厂商（如 OpenAI、Anthropic）的 Function Calling 协议都不同，而且许多开源模型根本不支持。比如你为 OpenAI 的某个模型开发了一个工具，想复用到 Anthropic 的模型，就要先去检查该模型是否支持 Function Calling，如果支持还需要重新对工具进行适配开发。而 MCP 提供了一套通用的协议，免去了重复开发工具的问题，大大降低了工具使用的复杂度。 #### MCP 的三种通讯方式 MCP 目前支持三种通讯方式： | 通讯方式 | 说明 | 安全性 | |---------|------|--------| | **STDIO** | MCP Client 和 MCP Server 部署在同一台机器上，通过标准输入输出通信 | 绝对安全 | | **SSE** | 部署在不同机器，通过 HTTP 请求通信 | 若暴露连接方式可能有安全问题 | | **StreamableHttp** | 部署在不同机器，通过 HTTP 请求通信 | 若暴露连接方式可能有安全问题 | > **常见问题**：为什么 2025 年 3 月 26 日 Anthropic 在 MCP 规范中正式弃用 SSE，全面转向 StreamableHttp？ > > **答案**：SSE 的原理是 MCP Client 与 MCP Server 通过 HTTP 建立 SSE 长连接，之后 Server 可以不断向 Client 发送数据。问题在于整个过程都依赖这个长连接，一旦出现网络毛刺（短暂中断），Server 发送的数据就会丢失，而且 Server 无法感知数据丢失。而 Streamable 方式中，Server 可以感知到数据丢失，当连接恢复时，可以持续地把没有发送给 Client 的数据再次发送，从而保证长连接的高可用性。 随着 MCP 的流行，社区也在不断壮大，越来越多的工具开始支持 MCP 协议（如 mcp.so、魔搭社区）。可以说，**MCP 就是模型进行工具调用的未来**。 ### 1.3 Agent + MCP 快速上手 如果你想快速体验一下 MCP 的功能，可以按照以下步骤操作，非常简单。 1. **安装 AI 对话客户端**。我们选择 Cherry Studio 来快速体验。首先访问官网下载并安装客户端。 2. **配置模型服务**。安装完成后，点击“设置”→“模型服务”→“添加”。随便填写“提供商名称”。如果你使用 idealLab 的服务，提供商类型选择默认的“OpenAI”。 3. **输入 API 密钥**。添加完成后，输入 idealLab 的密钥，填入 API 地址。 4. **添加模型**。点击模型平台中的“添加”，这里需要填入模型 ID。进入 idealLab 提供的模型清单，复制模型 ID 填入即可。 > 注意：选择的模型必须要有工具调用能力。 5. **测试连通性**。点击“助手”，选择配置好的模型，测试是否可以正常连接。 6. **配置 MCP 设置**。回到设置，选择“MCP 设置”，点击“添加服务器”→“快速创建”。如果需要安装依赖，跟着客户端教程无脑安装即可。 7. **配置 MCP Server**。以魔搭社区提供的文件系统服务为例，进入后可以看到服务提供的工具。 8. **关联 MCP Server**。回到助手页面，在 MCP 设置中选择刚才配置好的 MCP Server。再次强调，选择的模型必须要有工具调用能力。 9. **测试工具调用效果**。输入指令，看看 Agent 是否能成功调用工具。 > **小提示**：实际体验后，你是否体会到 MCP 的作用了？MCP Client 使用统一的配置方式，可以快速接入各种工具。没有工具调用能力的 Agent，最多就是充当“百科全书”。而有了工具调用能力的 Agent，就可以把它当作一个“人”来看了——它可以像我们一样写文件、操作浏览器。 ### 1.4 浏览器操作探索过程 上述看报表场景的核心难点在于如何让 Agent 像人一样操作网页。我们用浏览器相关的 MCP Server 来解决这个问题。 #### 1.4.1 服务选择：playwright-mcp 浏览器相关的 MCP Server 主要分为两类，我们选择 **playwright-mcp**。它是一个利用 Playwright 提供浏览器自动化功能的 MCP 服务器，可以让 LLM 通过结构化的可访问性快照与网页交互，无需依赖截图或视觉调优模型。这个项目目前仍在活跃更新中。 playwright-mcp 提供了丰富的工具能力，主要包括： - **核心自动化功能**：点击、关闭、控制台消息获取、拖拽、JavaScript 评估、文件上传、悬停、导航、前进后退、获取网络请求、键盘操作、调整窗口大小、下拉选择、获取快照、截图、输入文本、等待等。 - **标签页管理**：关闭标签页、列出标签页、打开新标签页、选择标签页。 - **浏览器安装**：自动安装浏览器。 - **基于坐标的操作**（需开启 `--caps=vision`）：点击、拖拽、移动鼠标到指定坐标。 - **PDF 生成**（需开启 `--caps=pdf`）：将页面另存为 PDF。 #### 测试 playwright-mcp 的效果 还是以 Cherry Studio 为例： 1. 在“设置”→“MCP 服务器”中，添加一个服务器，类型选择“stdio”。 2. 命令输入 `npx`，参数写入 `-y @playwright/mcp@0.0.27`（或 `@playwright/mcp@latest`）。`-y` 可以让 Agent 自动进行工具调用而无需等待用户同意；`--headless` 开启无头模式，Agent 的浏览器操作不会打开可见窗口。如果想要看到浏览器操作过程，就移除这个参数。 3. 回到聊天助手页面，打开 MCP 服务器，选择配置好的 Server。 4. 让 Agent 总结网页内容，观察效果。 #### 1.4.2 环境准备 如果要在项目环境中使用 Agent 和 MCP 服务，需要以下准备： 1. 在工程的 Dockerfile 中安装 playwright，并解决大量的依赖问题。也可以新建一个 Docker 镜像，但只能用 SSE 或 StreamableHttp 模式。 2. Java 工程中需要使用 Spring-Ai 或 Spring-Ai-Alibaba 框架进行 Agent 开发。创建 MCP Client 时，需要确保是无头模式，并且指定 playwright 的无头浏览器路径。 #### 1.4.3 Agent 构建 有了工具的支持，我们就可以设置定时任务，让 Agent 来查看报表了。不同的报表场景，在定时时间、具体的网页操作、关注的指标、联系人等方面都各不相同。我们可以把数据划分为两类： | 配置类（触发 Agent） | 补充信息类（Agent 执行具体任务） | |---------------------|-------------------------------| | 模型相关配置（模型名称、温度参数）、定时时间、触发提示词。例如，一段期望每天早上 09:30 执行的场景配置。 | 不同场景的工作流、要打开的 URL、浏览器窗口大小、结果标题与内容格式、规定异常数据、具体示例等。 | **构建系统提示词时，建议先用 Agent 生成一个框架，然后基于 Agent 的行为和结果不断调整。** 最初构建时，我在系统提示词中使用 mermaid 选择节点来区分不同场景，如下图所示。但随着场景增多，流程描述越来越复杂，这种方式显然不可行。 于是我想到了保存不同场景的元数据信息： - **RAG 方案**：把数据保存到向量数据库中。但向量数据库更适合保存非结构化文本，不太适合保存结构化的元数据。 - **最终方案**：把数据保存到关系型数据库中。表结构中设置一个 `keywords` 列，用户提问后，Agent 先查询 `keywords` 进行语义匹配，返回最适合的 ID，再查询 ID 对应的其他信息。如果没有匹配的 keywords，则按照用户提供的信息执行任务。这一步其实就是 RAG 做的事情。 > 常见问题：担心 Agent 生成危险的 SQL 语句怎么办？ > > **答案**：可以在系统提示词中直接写好需要执行的 SQL，并且创建一个只供 Agent 调用的专用数据库，不要直接让 Agent 调用线上的库表，这样就可以把风险降到最低。 #### 1.4.4 消息推送 消息推送可以通过工程与钉钉机器人结合来实现。只需要在知识库（数据库）中配置好场景结果的联系人工号或群 ID，让 Agent 按照指定 JSON 格式返回结果，工程解析后就可以实现钉钉消息推送。 > 安全注意：为了避免把消息发送给无关的人或群，需要在程序中配置工号/群号白名单，工程中做强校验。 #### 1.4.5 已有场景介绍 目前，以下三个场景已经验证并稳定执行，未来还会有更多场景接入： 1. 每天早上 09:30 查看某报表是否存在异常数据（指定日环比小于 -20%），如果发现异常，立刻发送钉钉消息给相应负责人。 2. 大促上线时，每半小时查看某任务的执行情况，并在群中播报。 3. 每天 11:00 查看报表某指标，如果指标值小于 90%，则打开另一个指定页面，筛选后关闭开关。 #### 1.4.6 常见问题汇总 在使用过程中，可能会遇到以下问题： 1. **浏览器窗口大小影响快照结果**。基于实际经验，设置窗口大小为 3840×2160 可以满足大部分场景。也可以在提示词中写明：“为了获取完整结果，你需要调整合适的窗口大小”。 2. **表格数据容易出现数据错乱**。可能需要在示例中模拟表格数据。需要在灵活性与准确性之间找到平衡。 3. **提示词中需约束快照内容**。例如“遵守快照内容最小获取原则”，否则容易导致 token 超限。 4. **提示词中需限制失败重试次数**。例如“若某操作执行失败，重试三次之后换一种操作方式；若仍然失败，则结束任务”，否则 Agent 可能会无限重复调用失败的方法。 5. **浏览器操作后一定要关闭浏览器**。playwright 执行新任务时会默认打开新的浏览器窗口，如果不关闭，可能出现资源泄漏和端口冲突问题。 6. **钉钉 Markdown 消息不支持表格类型**，不适合返回大量数据。 #### 1.4.7 Agent 看报表 vs. FBI 播报 | 对比项 | Agent + playwright-mcp | FBI | |-------|----------------------|-----| | 平台限制 | 不局限于任何平台，可以操作任意网页 | 仅限 FBI 平台 | | 数据获取 | 能轻松获取页面上的任何数据 | 只能播报图片或导出为 Excel | | 灵活性 | 极高，可自定义各种操作逻辑 | 低，固定播报模式 | | 适用场景 | 适合需要深入分析或复杂操作的数据监控 | 适合简单的定时播报需求 | > **总结**：Agent + playwright-mcp 的方式可以不局限于 FBI 平台，任何网页都可以操作处理，并且可以轻松获取页面数据。但如果你只是需要简单的定时播报，直接使用 FBI 的播报能力就已经足够了。 --- ## 二、Agent 批量建任务 ### 2.1 业务背景与问题 在大促与日常切换时，运营人员会在某个平台上，基于 Excel 的内容进行批量任务的创建与暂停操作。目前存在以下两个痛点： 1. **任务量过大，操作耗时**：任务的配置都不相同，每次操作需要大约一小时。 2. **需要人工对比任务**：运营需要人肉对比 Excel 中的任务与已经存在的线上任务，判断哪些应该新增、哪些应该修改，还要找出所有不在 Excel 中的任务并暂停。 在这样的背景下，我们尝试引入 Agent，期望它能基于 Excel 和已有的任务自动生成结果，解放人力。 ### 2.2 Agent 批量建任务探索过程 #### 2.2.1 第一步：只让 Agent 处理最简单的场景 首先，我们只考虑最简单的情况来验证可行性：对于上传的所有任务，统一按照新增处理。 具体做法是：通过工程解析 Excel，在 idealLab 中配置 Agent，并在提示词中增加： - **字段转换规则**：将 Excel 的字段内容转换为枚举值。 - **补充信息规则**：给每个任务添加默认属性和默认值。 Agent 处理流程如下： - 工程解析 Excel → Agent 根据规则转换字段 → 调用工具匹配任务范围 → 生成最终任务。 在这个场景下，任务范围需要由 Agent 调用工具并基于一定规则进行匹配。我们可以在 idealLab 中添加工具实现。 最终效果很好——Agent 能够完成这个场景下的任务（我们可以称之为“NL2Task”任务）。于是我们开始探索更复杂的场景。 #### 2.2.2 第二步：完全让 Agent 处理复杂逻辑（结果是教训） 现在，我们需要让 Agent 处理更加复杂的场景：对比上传的任务和已经存在的任务。 Agent 处理流程图如下： - 输入：上传的 Excel 任务 + 已存在的线上任务信息。 - 任务：逐一对比每一个上传对象和已有对象，寻找差异 → 输出“新增/修改/暂停”的分类结果。 相比于初版，复杂点在于： 1. **输入 token 更多**：需要把已经存在的所有任务信息全部交给 Agent。 2. **处理逻辑更复杂**：需要对比每一个上传对象和已有对象，找出差异。 但在与实际业务结合后，出现了严重问题： - 响应速度慢、质量差：运营每次需要处理大约 50 个任务。如果让 Agent 一次性处理所有任务，它的回答速度非常慢，而且质量很差。 - 超时问题：小二工作台限制了 HSF 方法等待时间最长为 60s，并且不支持 SSE，Agent 根本无法在规定时间内完成响应。 我们想了一些解决办法： 1. 把任务拆分成多个小任务，并发调用。经过测试，调用 idealLab 的 Agent 请求接口最多支持 10 并发。 2. 从同步等待改为异步轮询，将 Agent 的结果保存到 Redis 中。 虽然拆分任务减少了每次处理的任务数量，但新的问题又出现了： - 成本极高：输入 token 数量非常庞大，一次调用就需要约 4 万 token。拆成十份后，一次调用的成本约为 40 元（40000/1000×0.1×10）。 - 响应依然缓慢：即使拆分了任务，模型首次响应的平均时间仍在 25 秒左右。 - 准确性无法保证：我花费了大量时间调整提示词，生成的结果依然存在字段转换错误、范围匹配错误、漏处理任务等问题，根本无法交付。 > **教训回顾**：前面提到的“字段转换”和“任务对比”这些工作，工程不仅可以干，而且处理得更精准、更快！换句话说，这个事情本来就应该是工程做的，强行让 Agent 做，耗费大量精力和财力，最终效果差到无法交付！ #### 2.2.3 第三步：各取所长——工程 + Agent 高效处理 最终，我们对流程进行了重构。重构后的分工非常明确： - **工程负责所有标准化、确定性工作**：包括 Excel 解析、字段转换、任务对比、分类处理等所有可以用编码精确实现的步骤。 - Agent 只负责一件事：根据 Excel 的内容，基于规则进行语义匹配，确定每个任务的范围。这是一项适合 Agent 处理的“语意匹配”工作。 处理流程如下： - 工程解析 Excel，处理字段转换 → Agent 进行语义匹配，确定任务范围 → 工程根据结果执行创建/修改/暂停操作。 经过重构，Agent 只干这一件适合它的事情： - 输入输出 token 大幅减少 - 响应速度和回答质量显著提高 - 成本大大降低 - 工程保障了准确性和稳定性 最终效果非常好，成功实现了业务的提效目标。 --- ## 三、总结：Agent 与工程选型的黄金法则 回顾以上两个实战案例，我们都将 Agent 与工程进行了结合，并成功作用于实际业务场景。但第二个案例中，我们起初让 Agent 做了不适合的工作，反而降低了效率和效果。 以下总结出 **Agent 和工程的能力对比**，帮助你做出正确决策： | 能力维度 | Agent（LLM） | 工程代码 | |---------|-------------|---------| | **核心本质** | 概率游戏、基于统计 | 确定性、精确无误 | | **优势** | 语义理解、灵活匹配、自然语言交互 | 精准计算、批量处理、稳定可靠 | | **劣势** | 速度慢、成本高、结果不可靠 | 无法处理模糊语义、灵活性差 | | **最佳场景** | 语意匹配、文本生成、不追求 100% 准确的任务 | 数据转换、批量对比、逻辑判断、需要绝对准确的任务 | **核心结论：Agent 的本质还是概率游戏，它并不是万能的。** 千万不要把任何业务问题都一股脑全部丢给 Agent，期望它能给出一个完美的结果。 ### 现阶段的最优策略 **将 Agent 与工程结合使用，扬长避短。** 在做技术方案时，要充分考虑每一环节最适合用什么工具去解决。 > 三个关键原则： > 1. **确定性工作用工程**：凡是可以用代码精确实现的功能，优先用工程解决。 > 2. **语义性工作用 Agent**：需要理解模糊语义、灵活匹配的业务，才交给 Agent。 > 3. **及时止损永不死磕**：在具体实践中，如果发现方向不对，尝试调整后仍然得不到比较好的结果，就及时更换方向，不要死磕。 只有准确理解各种技术的边界和长处，你才能构建出真正高效、稳健的解决方案。技术的价值不在于用最酷的工具，而在于用最合适的工具解决最正确的问题。希望这两个实战案例能为你在实际业务中落地 AI Agent 提供一些有价值的参考。