竞品监测：三路信源并行抽取与矛盾标记

场景

典型场景：市场或品牌团队每天盯几个渠道的竞品动态：社交媒体上的官方账号、社区讨论、行业新闻。同一件事在三处的说法常常不一致——发布日期差一天，性能提升写成 60% 或 55%——社区帖子又夹着未经证实的猜测。人工做法是逐条抄进表格再对照，渠道一多就跟不上。

这个示例演示的是把每个渠道交给一个独立的抽取 Agent 并行处理，统一成同一种结构化格式，再由一个汇总 Agent 做交叉比对：合并同一说法、计算平均置信度、记下最早报道日期，并把冲突按 minor / moderate / critical 三档标出。fixture 里预埋了两处矛盾供它识别：竞品 X 的发布日期（Twitter 写 04-15、Reddit 写 04-14、新闻写 04-16），以及查询性能提升幅度（Twitter 写 60%、新闻写 55%）。

方案

表中模型为示例仓库的默认配置；实际选型在方案阶段按场景确定。

四个 Agent 由脚本直接构造并调用 agent.run()，并行靠 Promise.all 实现，没有经过任务 DAG 编排。每个 Agent 的工具注册表里登记了内置工具，但配置里没有 toolPreset 或 allowedTools；OMA 的工具授权默认拒绝（src/tool/grants.ts：没有正向授权则内置工具清空），所以整条流程只做模型调用。

三个监测 Agent 用同一个 zod schema（claim、date、source_url、confidence 0–1），maxTurns 1、maxTokens 800、temperature 0.2；汇总 Agent 用另一个 schema（verified_claims、contradictions、summary），maxTokens 1200、temperature 0.3。框架对 outputSchema 的处理是：先从回复里抽 JSON 校验，失败就把错误信息回传给模型再试一次，第二次仍失败则该次运行判为失败（src/agent/agent.ts validateStructuredOutput）。

fixture 是仓库里提交的三份 JSON，各 10 条说法。脚本末尾的注释给出了接入真实信源的方式：把三个 fixture 读取函数换成自己的数据适配器，抽取与汇总两段保持不变。

结果

可运行产物与验证方式：

需要 API key。脚本头部写明前置条件是 ANTHROPIC_API_KEY 与 Node.js 20 以上；运行命令 npx tsx packages/core/examples/cookbook/competitive-monitoring.ts。

能观察到并行。每个监测 Agent 打印 [RUN] / [DONE] 与各自耗时、输出 token 数，随后打印并行墙钟时间、三路串行耗时之和与加速比；报告末尾断言并行耗时低于串行之和的 70%，打印 PASS 或 FAIL，FAIL 时以退出码 1 结束。任一监测 Agent 或汇总 Agent 失败、或结构化输出缺失，脚本同样以退出码 1 结束。

最终产物是一份 COMPETITIVE INTELLIGENCE REPORT，分 Summary、Verified Claims（来源、平均置信度及 high / medium / low 标签、最早报道日期、合并说明）、Contradictions（主题、严重度、两个版本及各自来源）、Timing Analysis 四段，末尾汇总输出 token 数。

示例用的是虚构数据：三份 fixture 里被监测的公司写成 Competitor X、Company Y 这类占位名，链接是示意地址。产出是一段模型生成的文本，供演示与验证流程使用。

出处

与元定义的关系

本页素材是 open-multi-agent 官方仓库里的 cookbook 示例，由元定义维护。

如果你手上有一条真实的竞品或舆情监测流程，要把多个渠道的数据并行抽成统一格式、交叉比对出矛盾说法，并接进你自己的数据源与报表系统，元定义对应的服务是 AI Agent 定制开发 →