基于MCP与技能系统构建全自动品牌检测Agent-北京尧图网络

折腾了大概一个月我把原来需要三个人轮流盯盘的品牌检测流程做成了全自动 Agent。今天这篇就从头聊一聊为什么选择 MCP 技能系统这套组合以及我在落地过程中踩过哪些坑。给同样想把自己手头重复机械流程做成 Agent 的朋友一个可参考的样板。我一直觉得品牌检测这种事特别适合交给大模型 Agent 来做但又不能只交给一个“会聊天的模型”。因为它不是一个问答任务而是一个由“搜索、抽数据、读图、判断、存证、出报告”串起来的完整流程。MCP 解决的是 Agent 手上有没有“工具”技能系统解决的是 Agent 懂不懂“流程”两者一结合流程才真正自动起来。1. 项目起点品牌检测做全自动化之前我经历了什么先说业务背景。很多品牌方尤其是做消费品的日常有个刚需盯着各个平台上有没有人在卖他们的品牌。这个“盯”包括好几件事有没有未经授权的店铺在低价卖货有没有打着擦边球用品牌名引流有没有图片上印了 logo 但标题里故意不写全称甚至有没有店铺直接卖假货。我做检测那会儿标准流程是这样每天早上打开几个电商平台手动搜索品牌关键词一页一页翻商品列表看店铺名、看价格、看销量、看商品图。觉得可疑的点进去截图、记录链接、标注店铺然后汇总成 Excel 表格发给品牌方。一个品牌查一遍少说两小时。品牌方有时候一次甩过来十几个品牌整个人基本就废在表格里了。痛点的核心不是“搜索”这个动作累而是“判断”一直在消耗人的注意力。什么样的店算违规、什么样的价格算乱价、什么样的情况该升级为侵权投诉这些判断标准在人脑里是有的但没法跑批量。所以我才想到要做一个 Agent让它自己去查、自己去判断最后交一份带证据的报告出来。我给它定的目标很简单你给我一个品牌名和平台清单剩下的别烦我。2. 为什么是 MCP 技能系统而不是写一堆脚本最开始我其实想得很朴素写个爬虫脚本配上规则匹配和关键词过滤也就能跑了。但写着写着我发现两个问题。第一平台侧的接口和页面结构经常变脚本跟着改改一次烦一次。更麻烦的是光靠代码规则根本判断不了“疑似侵权”这件事比如一个商品标题只写“同款”但图片里正面印了品牌 logo规则怎么写都别扭。第二我可以写脚本但没法让业务同事去改脚本。等他们提需求再等我改代码这个循环本身就不够快。后来接触了 MCP整件事的思路就变了。MCP 全称是 Model Context Protocol翻译过来是“模型上下文协议”。你可以把它理解成 AI 时代的 USB-C 接口协议它定义了一套标准的连接方式让大模型可以调用外部工具、读取外部数据而不必关心每个工具背后的实现细节。对我这种场景来说MCP Server 就是把“搜索商品”“读取商品详情”“下载图片”“网页截图”“查询授权店铺名单”这些能力统统暴露成一个个标准工具Agent 通过 MCP 协议去调用它们就像在电脑上插 U 盘一样插上就能用。技能系统解决的是另一层问题MCP 给 Agent 提供了零件零件怎么组装成一个工序靠技能系统来定义。所谓技能就是一段结构化的“岗位说明书”里面写清楚了这个技能什么时候用、输入什么参数、按什么顺序调用哪些 MCP 工具、中间步骤怎么处理数据、最终输出什么格式。MCP 加技能系统的组合比写脚本强在三个地方一是 Agent 自己能决定调什么工具平台变化时我只需要更新那个工具的实现不用推翻整条流水线二是判断逻辑可以交给 LLM它能把“标题没写品牌但图片有 logo”这类语义问题处理得比我手写规则靠谱得多三是技能可以沉淀成资产这个项目里写的技能换一个客户、换一个行业依然能复用。说白了脚本是给一个固定流程写的技能是给一个会自我规划的 Agent 准备的。3. 整体架构与核心设计这套系统的整体架构我拆成五层来讲。第一层是触发层。Agent 不可能一直开机盯着页面所以需要一个触发器。我在生产环境里用了两种触发方式定时任务和消息触发。定时任务就是每天固定时间点跑一遍巡检消息触发则是品牌方直接在内部群里发一条消息Agent 收到关键词就开始干活。第二层是编排层也就是 Agent 核心。这一层的职责是拆解用户请求决定使用哪个技能确认参数然后按步骤调度工具。我实现的时候没有用特别复杂的 Agent 框架而是用一个系统提示词加一个工具列表让模型先生成一个结构化的执行计划再按计划调用工具。这么做的好处是计划可见、可控出了问题我知道它当时想干什么而不是像黑盒一样直接丢给我一个结果。第三层是能力层包含两个部分MCP Server 和技能库。MCP Server 我封装了这些工具工具名称作用返回内容search_platform在指定平台按关键词搜索商品商品标题、店铺名、价格、销量、链接get_item_detail获取单个商品的详情字段详情描述、图片列表、发货地image_ocr识别商品图中的文字和 logo 区域OCR 文本、是否包含品牌词fetch_snapshot对商品页面做整页快照截图文件地址、页面 HTML、抓取时间check_authorized_shop查询店铺是否在品牌方授权名单里授权状态、授权类型、到期时间write_violation_record写入疑似侵权记录记录 ID、证据文件路径这组工具并不是我一次性想出来的而是照着人工检测动作一条条拆出来的。你会发现它们一个个都是比较粗粒度的操作不是“拿商品标题里第几个字符”这种细粒度接口。原因很实际Agent 在判断要不要调用工具时靠的是函数名和描述工具粒度太碎会让模型陷入选择困难而且每次多调一个工具就多一次 token 开销。第四层是存储层。所有检测结果、证据快照、历史记录都存在数据库里。我用的是 PostgreSQL原因没别的就是证据类数据用关系型表管理更顺手。表结构上核心是违规记录表和商品快照表每一份证据都要能追溯到抓取时间和来源 URL否则将来品牌方拿着报告去投诉时证据链站不住。第五层是通知层。检测完成后Agent 会把 Markdown 报告发送到企业微信和邮件。如果发现高危疑似侵权比如假货店铺还会单独发一条卡片消息通知负责人做人工复核。这套架构落到实际运行里最大的设计原则是能自动的尽量自动但关键判定点保留人工复核入口。因为品牌检测这个场景比较特殊机器判断错了代价不是推荐算法里推荐错一条内容那么简单而是可能冤枉一个正常商家或者漏掉一个真正的售假店铺。所以我的流程里默认动作是“自动排查、自动初筛、人工复核、自动归档”。4. 实操搭一个最小可运行的自动检测 Agent这一节我直接讲怎么落地。假设你已经有一个可以调用大模型 API 的基础环境我们从零搭一个只检测单一平台的小 Agent然后逐步加能力。4.1 先准备 MCP 服务端我用的语言是 PythonMCP 这块用的是 FastMCP 这个库上手非常快只需要定义好函数装饰一下就变成一个可被 Agent 调用的工具。from fastmcp import FastMCP mcp FastMCP(brand-guard) mcp.tool() def search_platform(keyword: str, max_pages: int 2) - list[dict]: 在已接入的电商平台搜索商品关键词返回商品标题、店铺名、价格、销量、链接列表。 results [] for page in range(1, max_pages 1): # 这里接入平台开放 API 或抓取逻辑 batch query_platform(keywordkeyword, pagepage) results.extend(batch) return results mcp.tool() def check_authorized_shop(shop_name: str) - dict: 检查店铺是否在品牌方授权名单中。 return query_authorization(shop_nameshop_name) mcp.tool() def fetch_snapshot(url: str) - dict: 对商品页做整页截图返回文件路径和抓取时间。 snapshot_path, captured_at capture_page(urlurl) return {url: url, snapshot_path: snapshot_path, captured_at: captured_at}这里有个非常容易被忽视的点函数名和 docstring 写得好不好直接决定 Agent 会不会正确地使用工具。大模型看不到你的函数实现它只看得到“工具名描述参数”然后根据当前任务内容做工具选择。我一开始把 search_platform 的描述写成了“搜索商品”后来发现 Agent 在用户说“查一下某品牌的仿冒品”时根本不会调用改成“搜索电商平台上包含指定品牌关键词的商品用于品牌侵权排查”之后召回的准确率明显上来。4.2 写一个技能文件MCP 工具准备好了接下来要让 Agent 知道“做一次品牌巡检应该先做什么、再做什么”。我把这个流程写成了一个 YAML 技能文件。name: brand_infringement_inspect description: 当用户要求排查某品牌在某平台是否有疑似侵权、未经授权销售、低价乱价问题时使用。 inputs: brand: type: string required: true description: 要检测的品牌名称 platforms: type: array required: false default: [某电商A] max_pages: type: int required: false default: 2 steps: - call: search_platform with: keyword: {brand} max_pages: {max_pages} - call: get_item_detail with: items: $STEP1 - call: image_ocr with: items: $STEP2 - call: classify_infringement with: items: $STEP3 brand: {brand} - call: write_violation_record with: violations: $STEP4实际运行时我并不是把这个 YAML 原封不动丢给模型而是把它先转成 Agent 内部的“技能描述”再由模型展开成一次具体执行计划。这其中的关键是每个步骤之间的数据怎么传递。我用的是$STEP1这种变量引用表示下一步的输入来自上一步的输出。这样写的好处是技能文件足够直观业务同学也能看懂大概流程而不需要懂 Python。技能文件的价值在于把“经验”固化下来。人工检测时老手和新手的差距就是流程感新手可能查完销量就忘了看图老手则一定会在意图片里有没有被裁掉的 logo。我把这些经验都写进技能里Agent 执行时就稳定地带着老手的习惯去跑。4.3 Agent 的规划和执行有了 MCP 工具和技能文件接下来就是让 Agent 学会“选技能、填参数、跑流程”。我没有写复杂的规划器而是用一个很直接的 prompt 约定。agent_system_prompt 你是品牌巡检 Agent。你的任务是根据用户请求在以下技能中选择最合适的一个并生成 JSON 格式的执行计划。技能列表 {sill_manifest} 执行计划格式 {{skill: 技能名, inputs: {{...}}}} 生成计划后必须严格按照计划调用 MCP 工具完成步骤最后按步骤结果生成中文报告。当用户输入“查一下某品牌在某电商平台的情况”Agent 会先输出{ skill: brand_infringement_inspect, inputs: { brand: 某品牌, platforms: [某电商A], max_pages: 3 } }然后我的代码拿到这个 JSON把技能文件里的 steps 展开逐条调用对应的 MCP 工具。每调完一步把结果存到临时上下文里传给下一步。全部走完后Agent 汇总所有中间结果输出一份报告。这一步看起来简单但部署时有个容易踩的坑不要为每个步骤单独调用大模型去“思考”那是巨大的 token 浪费。我的做法是步骤数据全部用代码拼接和汇总只有“分类判断”这一步调用 LLM 做语义分析其余步骤都是确定性处理。分类判断也尽量给模型喂精简字段而不是完整的页面 HTML。4.4 判定规则与报告输出品牌检测的判定逻辑是最核心的部分。我总结了一套自己的分类规则分成四类正常、疑似乱价、疑似未经授权、疑似假冒。分类判断条件处理方式正常店铺在授权名单内价格正常仅记录疑似乱价非授权店铺价格低于官方指导价 70%自动记录并通知疑似未经授权商品标题或图片含品牌关键词店铺不在授权名单自动记录提示复核疑似假冒价格异常低图片质量差或 OCR 识别到涂改品牌痕迹高优先级告警这些规则不是写死在代码里的而是写在提示词里让模型按这套标准去判断。为什么不用纯粹的代码规则因为“价格异常低”“图片质量差”这些描述本身就是模糊边界模型处理模糊条件的表现远好于一堆 if else。但反过来完全让模型自由发挥也不行必须给它明确的分类框架否则它会发明出自己的分类报告就没法统一。报告输出我用的是 Markdown 表格这样无论是在企业微信还是在邮件里都直接可读。表头和内容长这样时间平台商品标题店铺价格判定结果关键词证据商品链接2025-06-18 09:30某电商A专柜同款品牌羽绒被某某工厂店269元疑似乱价价格显著低于官方价图片含品牌logo链接2025-06-18 09:31某电商A品牌家纺清仓品牌官方旗舰店899元正常授权店铺链接每一条报告里的“商品链接”都会附带一个证据快照存的是抓取时的页面截图和原始数据文件。这个习惯让我在后期处理客户投诉时省了无数麻烦。4.5 定时调度与告警接入最小可运行版本搭建完之后我给它接了一个定时触发器每天早上八点跑一次全量巡检。这里没什么花哨的直接用一个定时任务服务在指定时间向 Agent 发送一条“开始巡检范围是 X 品牌列表”的消息即可。关键的是告警接入。我的实现比较轻量检测完后Agent 会把新增的高危记录拼成一个 JSON通过 webhook 发给企业微信群机器人。消息卡片里包含品牌名、平台、商品标题、价格、判定结果和链接。这样操作者不需要打开报告系统被一下就能看到重点。5. 踩坑清单与排查实录做这个项目的过程中我踩过不少坑挑几个最有代表性的记录下来。5.1 工具调用总超时先查 MCP 传输模式第一次把 MCP Server 部署到远程机器时Agent 调用 search_platform 频繁超时。排查了半天发现是传输模式的问题。MCP 支持 stdio 和 streamable HTTP 两种传输方式本地开发用 stdio 很方便但远程部署时如果还走 stdio进程管理和响应稳定性都会受影响。我后来把服务端改成 streamable HTTP 方式部署并在客户端设置了合理的超时时间问题就解决了。给新手的建议是本地玩用 stdio上了服务器直接切 HTTP 模式别犹豫。5.2 技能老选不中Description 要会写技能仓库里一开始只有三个技能Agent 还经常选错。后来我总结出一个规律技能选择完全靠 description 做语义匹配description 写得太泛模型就觉得什么任务都合适。比如“检查侵权”这种描述模型看到“查销量”也会它选上。改成“当用户要求排查某品牌在某平台是否有疑似侵权假冒商品、低价乱价或未经授权销售时使用”以后选错率直线下降。每个技能的 description 都要像写检索关键词一样用心写清楚触发条件和适用范围。5.3 品牌重名导致误报有一个品牌客户的产品名跟某个日用词完全同名一搜出来半屏都是无关商品Agent 直接给人家标了一堆“疑似侵权”。这个问题靠 LLM 也救不了因为商品标题里确实出现了品牌词。我的解法是加了一个品牌词库配置里面维护了每个品牌的核心类目、排除词和同义词。在把数据喂给模型之前先用规则把明显不属于目标类目的商品过滤掉再结合标题中的类目词做一次预筛选。假如有人卖的是别的东西只是标题顺带蹭了个词那就不值得进入后续的图片分析环节。5.4 证据链必须完整如果你做检测只是为了内部看数据那网址截图就够用了。但如果你要拿检测结果去投诉、去维权那证据链不完整等于白干。我一开始的记录表只有字段链接、标题、店铺、价格。后来品牌方反馈说“你们说人家侵权图呢时间呢”我才意识到必须把每次检测的原始页面快照、截图时间、甚至接口返回的原始 JSON 都存下来。现在我每次巡检跑完都会把原始数据按品牌和平台归档成独立文件夹报告中只给摘要文件夹才是证据本体。5.5 Token 成本失控最开始的版本直接调用模型分析商品 HTML 全文一份页面几十 KB跑了几个平台下来单次巡检的 token 消耗非常惊人。后来我做了两个优化一是做字段裁剪进入模型之前只保留标题、价格、店铺名、销量、图片 URL、OCR 文本这几个字段二是做分批处理每批最多分析 20 条商品避免单次请求过长。优化之后单次巡检成本降到原来的三分之一左右速度还快了不少。6. 从单一检测到品牌治理中台的扩展方向如果只是做一个跑通流程的 Demo到上一节已经可以收尾了。但这类系统在实际业务里通常会被持续要求接入更多平台、更多品牌我的建议是不要直接开始铺量先把下面几个维度定好。第一个维度是多品牌隔离。不同品牌的授权名单、词库、告警规则都不一样系统里如果所有品牌共用一张配置表后面一定炸。我把每个品牌的配置独立成一份配置块包含品牌名、核心类目、排除词、授权店铺名单、价格阈值、通知人。这样品牌之间互不干扰新品牌接入就是新增一份配置的事。第二个维度是指标趋势分析。单次巡检只能解决“现在有没有问题”但品牌方其实更关心“问题为什么变多”。我后来在存储层加了趋势聚合每天记录每个品牌的疑似违规数量和类型分布按周拉出曲线。这个功能原本没在计划里但做完以后客户满意度提升非常明显。第三个维度是人工复核闭环。即便有了自动巡检我仍然坚持保留一个人工确认环节。Agent 把高优先级的疑似侵权记录推到负责人的待办列表里负责人确认处理后标记完成。这个“确认”动作不会每单都触发只针对高风险记录但我们保留了中间产物这样模型误判时能及时纠正而且纠正结果会反哺到提示词里后续判断会越来越准。如果你也想做类似的东西我的建议是先选一个最小场景跑通比如只测一个平台、只查一个品牌、只输出一份报告不要一上来就搞微服务和多平台适配。我最初跑通最小版本只花了一周时间后面大部分时间都花在调判断规则和补证据链上了。先把流程走通让 Agent 真正做到“给品牌名出报告”再考虑横向铺开。最后分享一个我自己的体会这类 Agent 项目里模型的能力反而是最不用担心的部分真正决定成败的是工具封装和流程设计。工具封装得好不好决定了 Agent 能不能接触到可靠的数据流程设计得好不好决定了 Agent 的输出能不能稳定地满足业务要求。MCP 和技能系统恰好分别解决了这两件事。我把这套东西搭起来之后最大的感受是以后再有品牌方跟我说“帮我们盯一下市场”我终于可以回答“把品牌名发我明天给你报告”了。

基于MCP与技能系统构建全自动品牌检测Agent

相关推荐

AI视频分析赋能交通监控：目标检测、跟踪与事件识别实战

歌词转旋律与旋律转伴奏：两个模型分开训的工程实践

ThinkPHP教学系统部署避坑指南：从500错误到稳定200

更多资讯

Java进阶自学路线：从会用到底层原理，三个月实战闭环

指挥情报中心建设实战：从数据接入到闭环处置的架构设计

高斯分布与GMM：从概率密度到可信分类的实战指南

节点重要度排序实战：从中心性到inocc综合指标的Python实现

警务指挥情报中心建设实战：从业务流程到系统落地

Java面试实录：从JVM到MySQL，那些让面试官崩溃的基础错误

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？