Agent 技术调研自动化

实战一：技术调研自动化

系列第 7 篇 · 前置：第 1 篇 → 第 2 篇→ 第 3 篇→ 第 4 篇→ 第 5 篇→ 第 6 篇

前面讲的 auto-article 是"搜资料→写文章"。这篇做一个不同的东西：技术调研报告。

区别在哪？写文章可以自由发挥，调研报告要求每个观点有来源、关键说法要交叉验证、结论不能瞎编。这正好用上前面学的：parallel 多源搜索、schema 约束输出、多维度验证。

最终效果：说一句"调研一下 React Server Components"，自动产出一份带来源标注、有验证状态的结构化报告。

一、先定义两个 Custom Agent

researcher：只搜不编

yaml 复制代码

---
name: researcher
description: 搜索技术资料并提取观点，每个观点标注来源。用于技术调研、资料收集。不做判断，只做整理。
model: haiku
tools: WebSearch, WebFetch
---

你是一个技术资料研究员。给你一个技术主题，你搜索相关资料，提取关键观点。

规则：
1. 每个观点必须标注来源（标题 + URL）
2. 只提取搜索结果中确实存在的内容，不补充、不推测
3. 如果搜索结果互相矛盾，原样记录两方说法
4. 输出格式：每条观点一行，格式为"[来源标题](URL)：观点内容"
5. 至少找 3 个不同来源

搜索整理用 haiku 就够了，不需要强推理。只给 WebSearch 和 WebFetch，它不需要写文件。

verifier：只验不写

yaml 复制代码

---
name: verifier
description: 验证技术说法是否有多个来源支持。用于交叉验证调研发现，判断说法可信度。
tools: WebSearch, WebFetch
---

你是一个技术事实核查员。给你一个技术说法，你独立搜索验证。

规则：
1. 独立搜索，不要只看说法中附带的来源
2. 判断标准：
   - "confirmed"：至少 2 个独立来源一致
   - "disputed"：来源之间有矛盾
   - "unverified"：只找到 1 个来源或找不到
3. 输出你的判断和依据
4. 如果发现说法有误，指出正确的说法

验证用默认模型（sonnet），因为需要判断和推理。

二、Workflow 脚本

php 复制代码

export const meta = {
  name: 'tech-research',
  description: '技术调研：多源搜索 → 提取观点 → 交叉验证 → 生成报告',
  phases: [
    { title: '多源搜索' },
    { title: '交叉验证' },
    { title: '生成报告' },
  ],
}

const TOPIC = args.topic || 'React Server Components'

// ===== 阶段1：三个角度并行搜索 =====
phase('多源搜索')
log(`调研主题：${TOPIC}`)

const [tutorials, official, discussions] = await parallel([
  // 角度1：教程和实战文章
  () => agent(
    `搜索「${TOPIC}」的教程、入门文章、实战案例。提取关键观点，每条标注来源URL。`,
    { agentType: 'researcher', label: '搜教程', phase: '多源搜索' }
  ),
  // 角度2：官方文档和规范
  () => agent(
    `搜索「${TOPIC}」的官方文档、RFC、规范、发布说明。提取核心概念和设计目标，每条标注来源URL。`,
    { agentType: 'researcher', label: '搜官方', phase: '多源搜索' }
  ),
  // 角度3：社区讨论和争议
  () => agent(
    `搜索「${TOPIC}」的社区讨论、争议、批评、踩坑经验。提取正反两方观点，每条标注来源URL。`,
    { agentType: 'researcher', label: '搜讨论', phase: '多源搜索' }
  ),
])

log('三路搜索完成，开始提取观点...')

// 合并所有素材
const allRaw = [tutorials, official, discussions].join('\n---\n')

// 用一个Agent把原始搜索结果整理成结构化的观点列表
// 用schema约束输出，保证格式；整理用haiku够了
phase('多源搜索')
const claimsData = await agent(
  `从以下调研素材中提取所有技术观点。每个观点包含：内容、来源URL、来源类型。
   去重：意思相同的观点合并，保留所有来源。

   素材：
   ${allRaw}`,
  {
    phase: '多源搜索',
    model: 'haiku',
    schema: {
      type: 'object',
      properties: {
        claims: {
          type: 'array',
          items: {
            type: 'object',
            properties: {
              claim: { type: 'string', description: '观点内容' },
              sources: {
                type: 'array',
                items: {
                  type: 'object',
                  properties: {
                    title: { type: 'string' },
                    url: { type: 'string' },
                    type: { type: 'string', enum: ['tutorial', 'official', 'discussion'] }
                  },
                  required: ['title', 'url', 'type']
                }
              }
            },
            required: ['claim', 'sources']
          }
        }
      },
      required: ['claims']
    }
  }
)

log(`提取出 ${claimsData.claims.length} 个观点，开始交叉验证...`)

// ===== 阶段2：对每个观点交叉验证 =====
phase('交叉验证')

const verified = await pipeline(
  claimsData.claims,
  // 每个观点派一个verifier独立验证
  (claim) => agent(
    `请验证以下关于「${TOPIC}」的说法：

     "${claim.claim}"

     已知来源：${claim.sources.map(s => s.title).join('、')}
     请独立搜索验证，不要只依赖以上来源。`,
    { agentType: 'verifier', label: `验证: ${claim.claim.slice(0, 20)}...`, phase: '交叉验证' }
  ).then(verdict => ({
    claim: claim.claim,
    sources: claim.sources,
    verdict: verdict,
  })),
)

// ===== 阶段3：生成报告 =====
phase('生成报告')

const report = await agent(
  `基于以下经过验证的调研结果，生成一份关于「${TOPIC}」的技术调研报告。

   要求：
   1. 每个观点标注验证状态（已确认/有争议/未验证）
   2. 有争议的观点列出两方说法
   3. 末尾附参考来源列表
   4. 用中文，技术术语保留英文
   5. 不要写"在当今""随着"这种废话开头

   验证结果：
   ${JSON.stringify(verified, null, 2)}`,
  { phase: '生成报告' }
)

return {
  topic: TOPIC,
  claimCount: claimsData.claims.length,
  verified: verified,
  report: report,
}

三、几个设计决策

为什么三个搜索角度分开？

教程讲"怎么用"，官方文档讲"是什么"，社区讨论讲"有什么问题"。一个 Agent 全搜容易偏向某一类。分开搜再合并，覆盖面更广。

为什么提取观点用 schema？

三个 Agent 返回的是自由文本，格式不统一。用 schema 约束输出，拿到的直接是结构化对象，后续验证和报告生成都不用解析文本。这比让 Agent "返回 JSON 格式"可靠得多，constrained decoding 保证格式合法。

为什么验证用 pipeline 不用 parallel？

观点数量可能很多（10-20 个），用 parallel 要等最慢的那个验证完。用 pipeline，验证完一个就往下走一个，快的先到报告阶段。

为什么验证要独立搜索？

如果只看观点附带的来源，那等于自己证明自己。verifier 独立搜一遍，才能发现"这个说法只有一个博客提过，官方文档根本没说"。

四、运行方式

arduino 复制代码

运行 workflows/tech-research.js，主题是 React Server Components

跑完你会得到：

report：完整的调研报告文本
verified：每个观点的验证详情
claimCount：提取了多少个观点

你可以直接看 report，也可以看 verified 了解每个观点的验证过程。

五、和 auto-article 的区别

	auto-article	tech-research
目标	写一篇可读的文章	出一份可信的报告
搜索	三源搜资料	三角度搜（教程/官方/讨论）
输出	自由文本	schema 约束的结构化数据
验证	无	每个观点独立交叉验证
关键要求	可读性	可信度、来源可追溯

同样是"搜索→生成"，目标不同，设计完全不同。写文章可以自由组织，调研报告必须每个说法有依据。

六、可以改进的地方

给 verifier 也加 schema，让验证结果也是结构化的
加一个"可信度评分"，按来源类型加权（官方文档 > 权威博客 > 社区讨论）
争议观点可以多派一个 Agent 仲裁
报告生成后加质量门（第 5 篇讲的模式），检查是否有未标注来源的说法

这些等跑通基础版后按需加。

小结

复制代码

技术调研 = 多角度搜索 + 结构化提取 + 独立验证 + 带来源报告

researcher 负责搜和整理（haiku）
verifier 负责独立核查（sonnet）
schema 保证中间产物格式可靠
pipeline 让验证不互相等待