AI Agent究竟如何落地？不必急于追求全自动化，不妨先参考这两个实战案例。核心路径只有一条：让Agent与传统工程系统深度融合，而非幻想它能完全替代一切。

核心内容：

• 智能播报助手场景：破解传统报表监控的三大核心痛点
• MCP协议创新：构建Agent调用外部工具的标准框架
• 工程选型方法论：平衡技术创新与业务实效的黄金法则

引言

AI Agent相关技术发展迅速，但验证其在真实业务中的价值才是当务之急。脱离具体场景的技术创新，终究只是空中楼阁。本文分享一段真实经历——将Agent与工程相结合，落地到两个实际业务场景中，最后总结出一些选型层面的经验。

Agent + MCP 打造智能播报助手

2.1 业务背景与问题

在日常工作中，统计报表的使用频率非常高。淘天内部有一款数据产品，用于制作和查看报表，关注数据的人员需要定期刷新——例如每天早上十点查看表A的数据，大促上下线时每半小时查看表B的数据。

定时查看报表的流程，简单来说就是：打开网页 → 发现异常数据 → 针对异常数据采取行动。FBI平台具备定时播报功能，但其局限性也很明显：

• 表格型报表只能播报图片，导出数据只能通过邮件格式，且导出的文件为Excel。如果使用工程代码处理，每个表格类型都需要单独定义接收对象。
• 文本型报表虽然可以定义异常指标，但只能修改展示样式，无法实现“某指标异常时才播报给特定联系人”，更无法基于异常数据触发后续操作。
• 底层数据虽然可以直接获取，但拿不到FBI加工过的日环比等衍生数据。

举个例子：定义异常为“指标1 < 10% 或 指标2 < 30%”。同学甲只关心A-aa1，同学乙只关心A-aa2，同学丙只关心B-bb1。预期的效果是：周期到达时，自动向甲和丙播报异常，甚至直接执行下一步操作。目前FBI无法实现这一点。

2.2 MCP介绍

转机出现在LLM持续进化（例如Claude 4）以及MCP横空出世之后。MCP全称Model Context Protocol，即模型上下文协议。简单来说，它定义了一套标准规则，让LLM能够安全、有序地调用各种外部资源，从而大幅扩展Agent的能力边界。

MCP中有两个关键角色：MCP Client和MCP Server。Server提供各类能力和工具，Client负责调用。打个比方，将MCP Client想象成DVD播放器，不同的碟片就是不同的MCP Server，每张碟片内容各异。你不能把磁带塞进DVD播放器，同理，不符合MCP协议的也无法使用。在AI场景下，这相当于赋予了Agent通用调用各类工具的能力。

可能有人会问，让Agent调用工具是最近才出现的能力吗？其实并非如此。工具调用（Function Calling）早已存在，但过去不同厂商的协议互不兼容，许多开源模型甚至不支持。例如，为OpenAI的某个模型开发了一个工具，想复用到Anthropic的模型上，需要先确认它是否支持Function Calling，支持的话还需重新适配。MCP提供了一套统一协议，免去了重复开发工具的麻烦，大大降低了使用门槛。

目前MCP有三种通讯方式：STDIO、SSE和StreamableHttp。Client和Server在同一台机器上，通过标准输入输出通信即为STDIO模式；不同机器通过HTTP通信则为SSE或StreamableHttp。STDIO由于是本地运行，绝对安全；SSE和StreamableHttp如果暴露了连接方式，可能存在安全风险。

2025年3月26日，Anthropic在MCP规范中正式弃用SSE，全面转向StreamableHttp。原因在于：SSE依赖一条长连接，一旦网络出现波动，Server发送的数据就会丢失，且Server自身无法感知。Streamable方式下，Server能够感知数据丢失，连接恢复时可以重新发送，从而保证高可用性。

随着MCP的流行，社区不断壮大，涌现出越来越多符合MCP的工具，各平台也在积极适配（例如mcp.so、魔搭社区）。可以说，MCP就是模型进行工具调用的未来方向。

2.3 agent + MCP快速上手

没用过MCP的同学可以按照以下步骤快速体验，操作非常简单。

1. 首先需要一个AI对话客户端。ideaLab目前不支持STDIO模式，因此使用Cherry Studio来体验。下载并安装客户端。

2. 安装完成后，点击设置 → 模型服务 → 添加。任意填写一个“提供商名称”。如果使用ideaLab的SK，提供商类型选择默认的OpenAI。

3. 添加完成后，输入ideaLab的SK，并填入API地址。

4. 点击模型平台中的“添加”，填入模型ID。从ideaLab提供的模型清单中复制ID，填入即可。需要注意的是，选择的模型必须具有工具调用能力。

5. 点击“助手”，选择配置好的模型，测试连通性。

6. 返回设置，选择“MCP设置”，点击添加服务器 → 快速创建。如果需要安装依赖，按照客户端教程操作即可。

7. 配置MCP Server。这里以魔搭社区提供的文件系统服务为例。

8. 进入后可以看到服务提供的工具，以stdio方式安装。

9. 点击助手 → MCP设置，选择刚才配置好的MCP Server。再次强调，模型必须具有工具调用能力。

10. 测试工具调用效果。

实际体验下来，应该能感受到MCP的价值：Client使用统一配置，能够快速接入各种工具。没有工具调用能力的Agent，充其量只是一个“百科全书”；有了工具调用，Agent才真正像一个“人”——它能像我们一样写文件、操作浏览器。那么，前面提到的看报表痛点，或许可以通过Agent + MCP的方式解决。

2.4 浏览器操作探索过程

2.4.1. 服务选择

与浏览器相关的MCP Server主要有两类：

playwright-mcp：一个基于Playwright的MCP服务器，提供浏览器自动化功能。它通过结构化的可访问性快照与网页交互，无需截图或视觉模型。目前仍在活跃更新中。

其提供的工具列表如下（可直接在GitHub查看）：

能力	工具	解释
核心自动化功能	browser_click	点击操作
	browser_close	关闭浏览器
	browser_console_messages	获取控制台消息
	browser_drag	按住鼠标左键拖拽
	browser_evaluate	评估JavaScript
	browser_file_upload	上传文件
	browser_hover	悬停元素
	browser_na vigate	导航到指定URL
	browser_na vigate_back	返回上一页
	browser_na vigate_forward	前进到下一页
	browser_network_requests	获取所有网络请求
	browser_press_key	模拟键盘操作
	browser_resize	调整窗口大小
	browser_select_option	下拉列表选择
	browser_snapshot	获取页面快照
	browser_take_screenshot	截图
	browser_type	在可编辑元素中输入文本
	browser_wait_for	等待文本出现或消失，或等待指定时间
标签页管理	browser_tab_close	关闭标签页
	browser_tab_list	列出标签页
	browser_tab_new	打开新标签页
	browser_tab_select	选择标签页
浏览器安装	browser_install	安装配置中指定的浏览器
基于坐标（--caps=vision）	browser_mouse_click_xy	点击指定坐标
	browser_mouse_drag_xy	拖拽到指定坐标
	browser_mouse_move_xy	将鼠标移动到指定坐标
PDF生成（--caps=pdf）	browser_pdf_sa ve	将页面另存为PDF

使用Cherry Studio测试playwright-mcp的效果：

1. 在设置→MCP服务器中，添加服务器，类型选择“stdio”，命令输入“npx”，参数如图。其中 -y 让Agent自动调用工具无需确认；@playwright/mcp@0.0.27 指定版本；--headless 开启无头模式（不显示浏览器窗口），如需查看过程则移除该参数。

2. 返回聊天助手，打开MCP服务器，选择刚才配置好的Server。

3. 让Agent总结网页内容，效果如下。

2.4.2. 环境准备

要在项目环境中使用Agent和MCP服务，需要进行以下准备：

• 工程Dockerfile中需要安装playwright，并解决大量依赖问题。（也可以新建Docker，但只能使用SSE或StreamableHttp模式）

• Java工程中需要使用Spring-Ai或Spring-Ai-Alibaba框架进行Agent开发。创建MCP Client时确保为无头模式，并指定playwright的无头浏览器路径。

2.4.3. agent构建

有了工具支持，就可以设置定时任务让Agent查看报表了。不同报表场景的定时时间、网页操作、关注指标、联系人各不相同。数据主要分为两类：

配置类：触发agent	补充信息类：agent拿到后执行具体任务与生成结果
模型相关配置（模型、温度）、定时时间、触发提示词。例如下图就是每天早上09:30执行的场景配置。	不同场景的工作流、要打开的URL、浏览器窗口大小、结果标题与内容格式、异常数据定义、具体示例等。

构建系统提示词时，先让Agent生成一个提示词框架，然后基于行为与结果不断调整优化。

最开始将所有场景都放入系统提示词中，使用mermaid的选择节点区分不同场景。但随着场景增多，流程描述变得越来越复杂，这条路显然行不通。

后来考虑将不同场景的信息存入向量数据库，但向量库更适合非结构化文本，而这里需要保存的是元数据。于是改用关系型数据库，表中设置keywords列，用户提问后Agent先查询keywords进行语义匹配，返回最合适的ID，再根据ID查询其他信息。如果没有匹配上，则按照用户提供的信息执行——这其实就是RAG的常见做法。

如果担心Agent生成危险的SQL，可以在系统提示词中写明要执行的SQL，并创建一个专门给Agent调用的数据库，避免直接接触线上库表，从而降低风险。

2.4.4. 消息推送

消息推送可以结合钉钉机器人实现。在知识库（数据库）中配置好结果对应的联系人工号或群ID，让Agent按指定JSON格式返回结果，工程解析后推送钉钉消息。

为了避免将消息发错人，在Switch中配置工号/群号白名单，由工程进行强校验。

2.4.5. 已有场景介绍

目前有三个场景已经验证并稳定执行，其他场景正在接入中：

1. 每天09:30查看某报表是否存在异常数据（日环比小于-20%），有异常则通过钉钉通知负责人。

2. 大促上线时，每半小时查看某任务的执行情况，在群内进行播报。

3. 每天11:00查看报表某指标，若小于90%，则打开另一个页面，筛选后关闭开关。

2.4.6. 问题汇总

使用过程中遇到的主要问题：

1. 浏览器窗口大小会影响快照结果。经验表明，设置为3840×2160可以满足大部分场景。也可以在提示词中加入“为获取完整结果，请调整合适的窗口大小”等说明。

2. 表格数据容易出现错乱，可能需要在examples中模拟表格数据。灵活性和准确性之间需要找到平衡。

3. 提示词中应约束Agent可以获取的快照内容，例如“遵守快照内容最小获取原则”，否则token很容易超限。

4. 提示词中应限制失败重试的最大次数，例如“若某操作失败，重试三次后换一种方式，仍然失败则结束任务”。否则Agent可能会无限循环调用失败的方法。

5. 浏览器操作结束后一定要关闭浏览器。playwright执行新任务会默认打开新窗口，不关闭可能引发资源泄漏和端口冲突。

6. 钉钉markdown消息不支持表格，不适合返回大量数据。

2.4.7. Agent看报表与FBI播报对比

总体来看，Agent+playwright-mcp的方案不局限于FBI平台，任何页面都可以操作处理，数据获取也更加灵活。但如果只是简单的定时播报，直接使用FBI的能力就足够了。

Agent批量建任务

3.1 业务背景与问题

在大促与日常切换时，运营人员会在某平台基于Excel内容批量创建或暂停任务。痛点非常明显：

1. 任务数量多，每个任务的配置各不相同，每次操作耗时大约一小时。
2. 需要人工对比Excel中的任务与线上任务，判断哪些需要新增、哪些需要修改，还要找出所有不在Excel中的任务并暂停。

在此背景下，尝试引入Agent，期望它能基于Excel和已有任务自动生成结果，从而解放人力。

3.2 Agent批量建任务探索过程

3.2.1. 能力尝试：只让Agent处理最简单的场景

首先考虑最简单的情况：上传的所有任务统一按新增处理。通过工程解析Excel，在ideaLab中配置Agent，提示词中加上字段转换规则（Excel字段转枚举值）和补充信息规则（给每个任务添加默认属性）。

任务范围需要由Agent调用工具并按照规则匹配。在ideaLab中添加工具来实现。

最终效果不错，Agent能够完成该场景下的“NL2Task”任务。于是开始探索更复杂的场景。

3.2.2. 初见端倪：完全让Agent处理复杂逻辑

现在需要Agent处理更复杂的场景：对比上传的任务与已存在的任务。

相比初版，复杂之处在于：

1. 输入token更多：需要将已有任务信息全部交给Agent；
2. 处理更复杂：需要逐一对比上传对象和已有对象，找出差异。

与实际业务结合后，出现了以下问题：

1. 运营每次处理约50个任务，一次性让Agent处理，回答速度极慢且质量很差；
2. 小二工作台限制HSF方法等待时间最长60秒，且不支持SSE，Agent无法在规定时间内响应。

解决方式：

1. 拆分任务，并发调用。测试下来，ideaLab的Agent请求接口最多支持10个并发；
2. 从同步等待改为异步轮询，Agent结果存入Redis。

虽然拆分了任务，但调试时发现输入token量仍然巨大——一次调用约4万token，拆成十份后，每次成本大约 40000/1000×0.1×10 = 40元。

成本无法避免，而且token输入量大，模型响应很慢，平均25秒才首次响应。花费大量时间调整提示词，结果依然无法保证高准确性——字段转换错误、范围匹配错误、漏处理任务等问题频发。

回过头来重新审视这个场景：前面提到的那些工作，工程不仅能做，而且更精准、更快。换句话说，这件事本来就该由工程完成，强行让Agent处理，费时费力费钱，最终效果差到无法交付。

3.2.3. 各取所长：工程 + agent结合高效处理

最终重构流程：工程处理除任务范围之外的所有工作，Agent只负责任务范围——因为需要根据Excel内容基于规则进行语义匹配，这件事确实适合Agent。

Agent只干一件事，输入输出token大幅减少，响应速度和回答质量都显著提升，再加上工程保证准确性，最终效果非常好。

总结

两个场景都将Agent与工程相结合，落地到实际业务中，目标是用Agent提升效率。但第二个场景一开始让Agent做了不适合的工作，反而降低了效率。下面列出Agent和工程的能力对比。

Agent的本质仍然是基于概率的推理，它并非万能。千万不能将任何场景问题一股脑全丢给Agent，指望它给出完美的结果。现阶段的最优策略是：将Agent和工程结合使用，扬长避短。在制定技术方案时，要仔细考虑每个环节适合用什么工具来解决。实践过程中，如果发现方向不对，调整后依然得不到好结果，就及时转换方向，不要死磕。只有准确理解各种技术的边界和优势，才能构建出真正高效、稳健的解决方案。