做品牌监测的同行大概都有同感这活儿不难就是磨人。我接手品牌检测流程自动化改造那阵子每天最烦的就是打开一堆网页把品牌名一个个搜过去、复制、粘进表格、手工判断正负面一整套下来大半天就没了。后来我把这套流程交给一个由 MCP 技能系统组成的全自动 Agent 去跑每天定时启动自己检索、自己清洗、自己写报告我只在收到告警时花十分钟看结论。这篇文章就把这套方案的完整拆解写下来包括架构设计、技能定义、Agent 主循环以及我踩过的坑。如果你也在做舆情监控、竞品跟踪或者品牌健康度评估并且对 Agent 落地这件事还处于“听说过但不知道怎么接流程”的阶段这篇应该能给你一条可以直接抄作业的路径。1. 先从流程痛点说起为什么品牌检测需要 Agent 化1.1 传统品牌检测的“人肉流水线”在聊技术方案之前我想先还原一下传统品牌检测日常到底长什么样。很多团队对“品牌检测”的理解是打开某个舆情工具看数据但真正常规操作其实是人工在几个平台上反复搜品牌词把搜到的帖子、新闻、评论一条条点开判断是否相关、是否负面、影响面多大然后汇总成一张 Excel再截图配文做成 PPT。这个过程听起来不复杂但它有几个非常折磨人的特点。第一是重复。品牌词就那十几个组合平台就那几个每天检索的动作几乎完全一样只是结果在变。第二是割裂。搜索、筛选、判断、归档、写报告每个环节都是独立的操作中间没有任何自动化衔接信息在工具之间传来传去稍微多几条数据就容易漏。第三是主观。判断一条内容算正面还是负面、算软广还是真实用户反馈不同的人标准不一样同一个内容今天审和明天审结论都可能不同。第四是滞后。日常检测做得再勤一天也就查两三次万一某条负面信息在凌晨发酵等你发现通常已经过了大半天。把这四点放在一起看品牌检测本质上是“长链路 多判断 周期执行”的工作。它不像写一篇文章、做一张图那样依赖灵感和一次性的创造力而是高度流程化、规则化、可重复。这就意味着它天然适合被拆成一套自动化任务。但过去的问题是自动化工具要么只能做机械的“爬取聚合”无法做判断要么需要把判断逻辑写死成规则换个品牌、换个场景就得重新开发。换句话说缺一个能把“搜索工具”和“分析判断”灵活编排起来的东西。这正好是我引入 MCP 和技能系统的原因。1.2 做成本自动 Agent 的三个关键前提把品牌检测做成全自动 Agent不是简单接几个 API 就完事。我在改造过程中发现有三个前提条件必须先满足否则后面怎么做都会别扭。第一个前提是数据源必须标准化。品牌检测要接触搜索接口、网页抓取、结构化存储、甚至内部的知识库这些数据源接口五花八门有的走 HTTP有的走 SDK有的连官方接口都没有只能靠模拟请求。如果让大模型直接面对这些接口光是适配就够写几千行样板代码。MCP 的价值在这里就体现出来了——把每个数据源封装成一个标准化的工具服务大模型只需要学会“调用一个叫 search 的工具传入关键词和时间范围拿到统一格式的结果”就可以了。第二个前提是分析逻辑必须可配置。品牌检测里的判断项很多这条内容说的是不是我们品牌是真实用户还是水军情感偏向是正面还是负面要不要升级为告警这些判断标准如果写死在代码里调整一次品牌就要改一次代码。我的做法是把判断标准做成“技能”——每个技能包含一段 Prompt 模板、一组参数、一份输出校验规则。想改变负面判定阈值改配置就行想新增一个平台源新增一个技能就行。第三个前提是执行过程必须可编排、可观测、可打断。全自动不代表完全没人管相反越自动的东西越需要设计“安全带”。Agent 每一步调用了哪些工具、结果是什么、为什么这么判断都要留下日志如果发现它绕进死循环或者连续多次调用失败要能自动熔断并通知人。这个前提直接决定了后面 Agent 主循环的写法我会在实操章节详细展开。2. 整体方案拆解MCP、技能系统与 Agent 各自扮演什么角色2.1 MCP给 AI 接上标准化的“工具插座”MCP 全称是 Model Context Protocol简单来说它是一套让大模型应用与外部工具、数据源进行标准化交互的协议。你可以把它想成给 AI 装了一个统一的“USB 接口”以前每接一个新设备都得专门配一根线现在只要设备支持这个协议插上就能用。在品牌检测这个场景里MCP 解决的问题特别具体。我之前试过直接把抓取函数写进大模型的系统提示词里让模型把参数自己拼出来调用效果很差——模型经常记错参数名返回的格式也不稳定。而用 MCP 之后模型不再直接面对原始函数而是面对一组“工具描述”工具叫什么、接收什么参数、返回什么结构全是统一标准。我这里搭了三个 MCP Server检索服务器负责对接某搜索接口并返回标准化结果列表网页内容服务器负责把目标页面里的正文、发布时间、作者信息抽出来存储服务器负责把检测结果写入数据库和报告文档。每个 Server 独立部署可以单独升级Agent 只通过 MCP 协议与其通信。还有一个容易忽略的点MCP 不只是“调用工具”它还包括 Resources资源和 Prompts提示模板两类能力。资源适合挂静态目录、字典、黑名单词库提示模板适合挂固定的分析框架。我早期只用了工具后来发现把品牌变体词典放到 Resources 里让模型随时读取比塞进 Prompt 上下文省 token 且更灵活。这几个细分能力后面实操章节会用到。2.2 技能系统把工作流拆成可编排的“乐高块”有了 MCPAgent 有了“手”但它还缺“操作手册”——这就是技能系统出场的地方。我这里的技能定义和很多人理解的“工具函数”不太一样。一个技能是“元数据 指令模板 校验规则”的组合元数据告诉 Agent 这个技能什么时候该用、输入输出是什么指令模板是给大模型看的执行指南校验规则负责检查输出的合法性。拿品牌检测流程举例我把整条链路拆成了六个技能品牌词扩展、检索召回、内容清洗去重、情感与相关性判断、竞品对比、报告生成。每个技能只负责一件事版本独立迭代。比如“品牌词扩展”这个技能它接收品牌名和行业词输出一组含别名、简称、谐音、错别字、话题标签在内的检索词列表“情感与相关性判断”接收一条文本输出结构化判断结果字段包括“是否相关”“情感极性”“置信度”“证据句”。这样拆的好处是任何一个环节的逻辑要调整只需要改对应技能然后跑一遍回归不会牵动整条链路。我还给技能定义了“适用阶段”属性比如检索召回只能出现在收集阶段报告生成只能出现在最后。这相当于给 Agent 画了一张操作流程图它可以在某个阶段内部自由决定先调哪个技能、传什么参数但阶段的先后顺序不能乱。这个设计我后面会讲它是防止 Agent 跑飞的关键。2.3 全自动 Agent从“推荐建议”到“自主执行”的跨越很多人把 Agent 理解成一个聊天机器人其实在品牌检测场景里Agent 的本质是一个能自主完成多步骤任务的执行器。它的核心循环是观察当前任务状态决定下一步行动调用技能或 MCP 工具拿到结果后更新状态然后继续循环直到任务完成。这套机制配上 MCP 和技能系统才真正实现了“全自动”。我举一个典型的执行过程。定时触发后Agent 先读取配置和品牌变体词典然后调用“品牌词扩展”技能生成检索词集合接下来在循环里反复调用 MCP 检索服务器获取各平台结果每拿到一批就调用“内容清洗去重”技能去掉重复内容和无关广告等所有平台都跑完后进入分析阶段逐条做情感判断命中负面阈值则标记告警最后调用“报告生成”技能输出日报并把告警消息推给值班群。整个过程没有人工介入而“做什么、怎么做、按什么顺序做”这些决策由 Agent 根据不同天的实际返回结果动态调整——这就是它比传统定时爬虫高明的地方。比如某天某个平台返回的数据量特别大Agent 会在去重阶段自动提高过滤阈值而不是傻乎乎地把几千条结果全塞进分析阶段。当然全自动的前提是有足够的护栏。Agent 所有可调用的工具都经过白名单每次调用都要记录入参和出参单次任务的技能调用步数有上限超过上限自动停止并告警。这些东西听起来不性感但没有它们Agent 跑不了几天就会出事故。3. 核心细节品牌检测 Agent 的架构与实现要点3.1 品牌检测流程的四个核心环节不管具体业务怎么变品牌检测的流程都可以抽象成四个核心环节收集、清洗、分析、报告。我把它们当作 Agent 的四个状态每个状态对应一组技能和 MCP 工具。收集Collect根据品牌词变体在多个平台检索MCP 检索服务器负责执行搜索返回标题、链接、摘要、发布时间等原始字段。这个环节的关键指标是召回率宁可多召回也不要在这一步把潜在相关的内容丢了。清洗Clean对收集到的原始结果做去重、去广告、提取正文、解析发布时间。很多内容在搜索页和详情页是重复的平台还有大量 SEO 软文需要靠内容清洗技能过滤。这个环节的关键是去重阈值和软文识别规则。分析Analyze对清洗后的每条内容做相关性和情感判断识别负面信息、竞品提及、用户反馈并产生结构化标签。这个环节是技能系统发挥最大的地方情感判断不能只靠单一模型打分还要叠加关键词规则兜底。报告Report把分析结果聚合为日报/周报按平台、情感极性、传播指数排序生成 Markdown 或 JSON 结构并触发告警推送。报告不是简单列数据而是要先做“归因”指出主要负面来源和趋势变动。四个环节呈现明显的先后依赖关系所以我把它做成带检查点的状态机而不是让 Agent 完全自由编排。每个环节完成时都会生成一份中间产物写入存储服务器这样即使某个环节跑挂了下次可以从检查点恢复不需要整个流程重来。这个设计在长期定时任务里非常实用。3.2 技能设计实操品牌词扩展与检索召回技能设计是整套方案的灵魂我挑两个最影响效果的说。第一个是品牌词扩展。很多做品牌检测失败的人死就死在检索词太单一。你以为搜“某品牌”就够但用户实际发帖可能写的是缩写、英文名、谐音甚至故意用错别字规避审核。“品牌词扩展”技能就是来解决这个问题的。我给它设计的输入是品牌官方名、品类词、目标平台列表输出是一组带权重的检索词。具体实现上我维护了一个扩展规则表包含中文名/英文名/缩写/官方话题标签/常见错别字/竞品对比词。例如某美妆品牌扩展词里会加入“XX 平替”“XX 烂脸”“XX 种草”“XX 旗舰店 售后”这些组合。规则表放在 MCP 的 Resources 里技能运行时会动态读取所以调整词典只需要改资源文件不用动代码。第二个是检索召回。这个技能的难点在于“怎么让 Agent 判断检索够了”。我设了三层停止策略第一层所有扩展词轮询完毕第二层连续多组检索词没有新增去重后的内容第三层累计召回条数达到上限。状态机里每轮检索后都会更新一个召回统计对象如果连续两轮新增量为零Agent 就自动判断“该平台已饱和”并切换到下一个平台。这三层策略在配置里都是可调参数针对不同平台可以单独设置召回上限——有的平台内容量大上限设高一些有的平台同质化严重上限可以低一些。3.3 关键参数与 Prompt 设计Agent 跑得稳不稳很大程度上取决于关键参数设置和 Prompt 设计。我先说参数。一个是时间窗口日常检测通常设最近 24 小时滚动窗口但遇到重点监控期我会让配置支持临时缩短为 2 小时窗口太短容易漏太长容易把旧新闻重复报。另一个是负面阈值我采用“关键词规则 模型打分”双通道任一关键词命中负面词库直接标记模型情感分数降到阈值以下也标记两边一致才进入告警有冲突则降级为观察。这样做是为了防止模型把讽刺、玩梗误判成真实负面。还有一个容易忽略的是模型参数做相关性判断时我把温度设为 0追求稳定输出写报告摘要时调到 0.3保留一点表达灵活性。Prompt 设计方面我总结出一个通用结构角色定位、任务目标、输入格式、输出要求、反例提示。拿“情感与相关性判断”技能来说Prompt 里我会明确写“你是一个品牌舆情分析师只根据给定文本判断禁止联想背景信息”然后给出字段说明和输出 JSON 的 schema最后附上“以下情况不算负面损失调侃型吐槽、无指名道姓的行业内批评”。加了反例提示之后误报率明显下降。这里有个小心得Prompt 里列反例比列正面要求更有效模型对“不要做什么”的理解往往比“要做什么”更精准。4. 实操过程从零搭建一个品牌检测 Agent4.1 第一步搭建 MCP 服务器层先搭最底层的数据服务。我这里用 Python 写了一个最小可用的 MCP 检索服务器关键逻辑是注册一个 search 工具接收 query 和 time_range 参数内部调用某搜索服务接口返回统一格式的结果列表。核心代码如下# mcp_search_server.py 摘要 from mcp.server import Server, stdio_server import json server Server(brand_search) server.tool() async def search(query: str, time_range: str 24h): 按关键词检索公开网络内容返回标准化结果列表。 results await call_search_api( qquery, timerangetime_range, max_resultsenv(SEARCH_MAX, 50) ) return [ { title: item[title], url: item[url], snippet: item[snippet], source: item[source], published_at: item[date], } for item in results ] if __name__ __main__: server.run(stdio_server())这段代码只负责暴露工具具体搜索逻辑被包在 call_search_api 里。要注意几点第一超时设置不能太短搜索接口偶尔会慢我设的是 30 秒超时 2 次重试第二返回字段必须固定哪怕某个字段为空也要保留 key这样大模型更容易理解结构第三并发限制必须做MCP Server 同一时间只允许限量请求否则会把搜索服务的配额很快打满。网页正文提取服务器和存储服务器也是同样的思路。正文提取服务器接收一个 URL返回清洗后的正文、标题、发布时间存储服务器接收结构化记录写入 SQLite。全部调试通过之后每个 Server 用nohup python mcp_xxx_server.py单独拉起然后在 Agent 的配置里注册它们的地址。4.2 第二步定义技能清单与运行规则MCP 工具就位后我建议不要急着写 Agent 主循环先把技能清单定义出来。这里我用 JSON 作为技能元数据格式每个技能一个文件字段包括技能名、描述、适用阶段、输入参数 schema、输出 schema、关联 MCP 工具、最大重试次数。下面是个精简例子{ name: sentiment_judge, description: 对单条内容做相关性与情感判断输出结构化结果, stage: analyze, input: { text: string, brand_variants: [string] }, output: { is_related: boolean, sentiment: positive|neutral|negative, confidence: float, evidence: string }, mcp_tools: [], prompt_template: skills/sentiment_judge_prompt.md, max_retries: 2 }技能描述这一栏值得多说两句。大模型决策是否调用这个技能全靠 description 里那段话。我一开始写的是“对内容进行情感判断”结果 Agent 在报告阶段也去调它后来改成“在清洗完成后对单条内容分析相关性只用于 analyze 阶段输入必须是已去重的文本”调度准确率一下就上来了。技能描述要回答三个问题这个技能解决什么、什么条件下不该用、输出给谁消费。技能提示模板单独放一个 markdown 文件让技能元数据和执行指令分离。这样产品同事可以直接改 Prompt不用碰代码。4.3 第三步Agent 主循环与调度逻辑技能清单有了现在写 Agent 主循环。我给整个流程设计了阶段状态机和步数限制伪代码如下# agent_loop.py 摘要 MAX_STEPS 50 pipeline [collect, clean, analyze, report] checkpoint load_checkpoint() # 从上次中断处恢复 state checkpoint.get(stage, collect) step 0 while state not in (done, failed): step 1 if step MAX_STEPS: alert(Agent exceeded max steps, needs human review) break # 根据当前阶段选择候选技能 candidates load_skills_for_stage(state) skill agent_choose_skill(candidates, context) result execute_skill(skill, context) validate(result, skill.output_schema) save_to_storage(result) state next_stage(state, result)这个循环看起来简单但有几个细节直接决定它能不能稳定跑。第一每执行一个技能结果先存储再喂给下一个技能绝不在内存里飘着即使 Agent 中途崩溃也能靠 checkpoint 恢复。第二技能输出一定要做 schema 校验大模型偶尔会返回残缺 JSON校验不通过就该走重试而不是继续往下传。第三阶段切换不能全凭 Agent 感觉我写了 next_stage 函数它根据当前阶段和结果集统计量判断是否进入下一阶段。比如 collect 阶段只有召回条数大于零或者所有平台轮询完毕才允许进入 clean。我给 Agent 的“自主权”严格限制在技能内部它可以决定调哪个技能、传什么参数、反复执行几次但不能改变阶段顺序。这个设计被我称为“半自主状态机”它既能保留 Agent 的灵活性又不会让流程失控。4.4 第四步定时触发与报告输出Agent 主循环跑通后定时调度就简单了。我用系统 crontab 配置每天定时执行# 每两小时跑一次增量检测每天 23:30 全量跑一次并出报告 0 */2 * * * cd /opt/brand-agent python agent_loop.py --mode incremental logs/agent.log 21 30 23 * * * cd /opt/brand-agent python agent_loop.py --mode full --report logs/agent.log 21报告输出这块我让它直接生成 Markdown 文件同时推一份 JSON 给内部看板。报告内容分四段总览数据各平台声量、正负面占比、环比变化、重点负面按影响面排序的前 N 条、竞品动态提及时自动聚合、明日关注基于趋势判断生成。生成完之后告警推送函数会检查负面列表如果超过阈值就把摘要发到值班群。还有一个容易被忽略的是幂等设计。每次任务开始前Agent 会先查询存储服务器里是否存在同一时间窗口的处理记录存在就直接跳过避免重复抓取导致数据虚高。我跑了一周后对比手动记录和 Agent 自动生成的报告发现 Agent 的召回率比人工还高因为它不会累、不会漏翻页只是偶尔在情感判断上需要人工复核。5. 常见问题与排查实录5.1 MCP 连接不稳定与超时第一次把整套系统挂到服务器上跑第二天就收到一堆告警全是 MCP 调用超时。排查到最后有四个原因都很典型一是 MCP Server 没有做存活检查后端服务重启后地址变了Agent 还在连旧地址二是检索接口响应时间本来就不稳定30 秒超时有时候确实不够三是没有幂等重试失败后直接抛错退出整个任务四是本地 DNS 解析在部分网络环境下很慢导致握手阶段就超时。我的解决方案是给每个 MCP Server 加 healthcheck 接口Agent 启动前先做一次连通性检测失败则自动重试三次再放弃所有 MCP 工具调用统一封装重试逻辑超时阈值提高到 45 秒失败任务支持从 checkpoint 恢复不会一次失败就前功尽弃。排查时还可以用 MCP 自带的调试模式手动调用工具确认 Server 本身没问题再往上层排查。5.2 检索结果太稀疏或太泛刚上线时另一个高频问题是结果集“营养不均衡”。有的平台只回几条有的平台回来一堆无关内容。检查发现平台 A 是因为扩展词里没有加该平台特有的话题格式平台 B 则是因为时间窗口设得太宽把大量旧内容重复召回。解决办法是把扩展规则表改成按平台分隔不同平台维护不同的检索词集合和召回上限时间窗口也改成“首次全量 增量滚动”的组合既保证历史覆盖又避免每天重复报旧闻。5.3 技能误调度与死循环技能误调度出现过一次最经典的场景Agent 在 analyze 阶段跑去调“报告生成”技能因为报告技能的描述里写了“汇总所有内容”它觉得这一步也算汇总。结果生成了一份空报告然后陷入“生成报告 → 发现没内容 → 调检索 → 回来又生成报告”的循环。幸好有最大步数保护拦住了。这之后我把技能描述全部加了“反面约束”并且在调度函数里加了硬编码阶段互斥表report 技能只能由 next_stage 触发不允许 Agent 在 analyze 阶段主动选择。从此再没出现过这种循环。这个教训给我的启发是不要高估 LLM 的纪律性阶段约束必须靠代码保证。5.4 Agent 报告质量不稳定报告质量不稳定主要体现在情感判断上。有一次某品牌发新品评论区大量玩梗“抢钱”Agent 把“抢钱”识别成负面。我梳理后发现问题出在上下文缺失模型只看到了单条文本不知道它是一个品牌活动下的调侃。改进方案是让情感判断技能接收一个可选的“上下文标题”字段判断时先看标题再看正文同时把玩梗词表加到规则兜底层。修改后误报率降了接近一半。在这里我也想说一个认知全自动不代表零人工。我的做法是让 Agent 把低置信度的内容单独归档每天早上我花十分钟刷一眼“待复核列表”凡是模型置信度低于 0.8 的结果都需要人瞄一眼再入库。这个机制加上去之后整体准确率才真正达到可用的水平。自动化解决的是“重复劳动”判断类的工作保留一道人工复核关卡反而更健康。最后再分享一个我个人的体会。这套全自动品牌检测 Agent 从搭建到稳定运行前后迭代了三版中间有过嫌弃它笨、干脆想回到手工阶段的冲动但坚持调下来之后它确实把我从每天几个小时的机械劳动里解放了出来。现在我的工作重点变成了设定判断标准、复核边界案例、优化技能描述而这些恰恰是机器替代不了的部分。如果你也想做类似的 Agent 化改造我建议一开始别追求“全自动”先把手头流程拆成技能用脚本先跑半自动等每个环节的输出都稳定了再让 Agent 把它们串起来。做 Agent 不是为了显示技术多酷是为了让重复的事不再占用人的时间把精力留给真正需要判断力的地方。这套方案目前已经跑成了常规动作下一步我打算把竞品检测和多平台告警渠道也接进来让它从一个“日报工具”长成真正的品牌健康监测中台。