Agent高级编排模式

四个高级编排模式

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

---

基础的 agent 串联、parallel、pipeline 会了之后，实际工作中反复出现的就那么几种套路。这篇讲四个用得最多的模式，每个给核心代码和设计思路。

---

模式一：质量门——写完多维度审查再改

写完一篇文章或一段代码，一个 Agent 从头查到尾容易漏。让多个 Agent 各查一个维度，最后一个人综合意见改。

// 阶段1：写初稿
const draft = await agent(`写一篇关于${TOPIC}的文章`, { phase: '写初稿' })

// 阶段2：三个维度同时审查（haiku 够了，便宜）
const [tech, style, readability] = await parallel([
  () => agent(`查技术错误：\n${draft}`, { label: '技术审查', model: 'haiku' }),
  () => agent(`查AI味和套话：\n${draft}`, { label: '风格审查', model: 'haiku' }),
  () => agent(`查可读性，站在新手角度：\n${draft}`, { label: '可读性', model: 'haiku' }),
])

// 阶段3：一个 Agent 综合三条意见改
const final = await agent(
  `原文：\n${draft}\n\n技术意见：${tech}\n风格意见：${style}\n可读性意见：${readability}\n
   技术错误必须改，风格问题必须改，可读性建议选择性采纳。`,
  { phase: '综合修改' }
)

设计要点：

• 审查用 parallel，三个维度互不依赖
• 审查用 haiku，找问题不需要强推理
• 最后综合必须用一个 Agent，因为三条意见可能冲突，需要权衡
• 返回时带上初稿和审查意见，方便看改了什么

---

模式二：批量生产——pipeline 多受众各走各的

同一个主题受众不同，多个版本同时开工，互不等待。

const audiences = [
  { name: '新手', prompt: '从零讲，多用类比' },
  { name: '有经验的开发者', prompt: '直接对比，给代码' },
  { name: '技术管理者', prompt: '讲效率和ROI，不贴代码' },
]

const results = await pipeline(
  audiences,
  // 阶段1：搜资料（管理者搜不同的内容）
  (a) => agent(
    a.name === '技术管理者'
      ? `搜索${TOPIC}的效率提升案例和数据`
      : `搜索${TOPIC}的教程和实战`,
    { model: 'haiku' }
  ).then(materials => ({ a, materials })),

  // 阶段2：列大纲
  ({ a, materials }) => agent(
    `面向${a.name}列大纲。${a.prompt}\n资料：${materials}`
  ).then(outline => ({ a, outline })),

  // 阶段3：写初稿
  ({ a, outline }) => agent(
    `面向${a.name}写初稿。${a.prompt}\n大纲：${outline}`
  ).then(draft => ({ audience: a.name, draft })),
)

设计要点：

• 用 pipeline 不用 parallel，因为每个受众要走三个阶段
• .then() 把受众信息打包传下去，否则到写初稿时不知道写给谁
• 受众越多 pipeline 优势越大，任何一个卡住不影响别的流程

---

模式三：审查验证——多维度查→去重→逐个对抗验证

代码审查最怕误报。四个维度各查一遍，去重后，每个发现派一个独立 Agent 尝试反驳它，只有确认的才保留。

// 阶段1：四维度并行审查（用 schema 直接拿结构化结果）
const DIMENSIONS = [
  { key: 'bugs', prompt: '查逻辑错误、await缺失' },
  { key: 'security', prompt: '查注入、敏感信息泄露' },
  { key: 'performance', prompt: '查不必要的串行、重复计算' },
  { key: 'style', prompt: '查命名、可简化代码' },
]

const FINDINGS_SCHEMA = {
  type: 'object',
  properties: {
    findings: {
      type: 'array',
      items: {
        type: 'object',
        properties: { description: { type: 'string' } },
        required: ['description'],
      },
    },
  },
  required: ['findings'],
}

const allFindings = await parallel(
  DIMENSIONS.map(d => () =>
    agent(`审查 ${TARGET}。${d.prompt}`, {
      model: 'haiku',
      schema: FINDINGS_SCHEMA,
    }).then(result => result.findings.map(f => ({ ...f, dimension: d.key })))
  )
)

// 去重：纯JS
const seen = new Set()
const unique = allFindings.flat().filter(f => {
  const key = f.description.slice(0, 40)
  if (seen.has(key)) return false
  seen.add(key)
  return true
})

// 阶段2：每个发现派一个Agent尝试反驳（pipeline，慢的不挡快的）
const verified = await pipeline(
  unique,
  (finding) => agent(
    `读 ${TARGET}。有人说这里有问题："${finding.description}"
     请验证。成立输出CONFIRMED，误报输出FALSE，不确定也算FALSE。`
  ).then(verdict => verdict.startsWith('CONFIRMED') ? finding : null)
)

const realIssues = verified.filter(Boolean)

设计要点：

• 去重用 JS 不用 Agent
• 验证阶段用 pipeline，一条要读大文件慢，不挡其他条
• "不确定也算 FALSE"是降低误报的关键
• 批量验证容易偷懒，必须逐条验证
• 完整的工程化版本（自动修复、跑测试）

---

模式四：loop-until-dry——不知道总量就循环到没有新发现

找硬编码路径、找安全漏洞这类任务，你不知道一共有多少个。一个 Agent 找一次肯定漏，就多轮找，每轮换角度，直到连续两轮没有新发现。

const STRATEGIES = [
  '用grep搜绝对路径模式',
  '检查配置文件里的硬编码路径',
  '检查Shell和JS脚本里的路径',
  '检查文档里的真实用户路径',
]

const allFound = new Set()
let dryRounds = 0
let round = 0

while (dryRounds < 2) {
  round++
  const strategy = STRATEGIES[(round - 1) % STRATEGIES.length]

  const found = await agent(
    `${strategy}。已知发现（别重复）：\n${[...allFound].join('\n') || '无'}`,
    { model: 'haiku' }
  )

  const lines = found.split('\n').filter(l => l.match(//Users//))
  const newOnes = lines.filter(l => !allFound.has(l))

  if (newOnes.length === 0) {
    dryRounds++
  } else {
    dryRounds = 0
    newOnes.forEach(l => allFound.add(l))
  }
}

return { total: allFound.size, items: [...allFound] }

设计要点：

• while (dryRounds < 2) 连续两轮无新发现才停，防某一轮漏了
• 每轮换策略，从不同角度找，减少盲区
• 已知发现喂回去防重复
• 去重 Set 是纯 JS
• 适合：排查类任务、不知道总量的任务
• 不适合：知道精确数量的任务、每轮成本很高的任务

---

怎么选

多个子任务互不依赖，结果要放一起用 → parallel
多个东西走相同的多步流程         → pipeline
写完要多维度检查再改             → 质量门（parallel + 综合）
查出来的东西要验证真假           → 审查验证（parallel + 去重 + pipeline）
不知道总量，要反复排查           → loop-until-dry（while）

这几个模式可以组合。比如审查验证模式里就同时用了 parallel 和 pipeline。

---

小结

质量门：     写 → parallel多维度查 → 一个人综合改
批量生产：   pipeline 多受众各走各的，.then() 传参
审查验证：   parallel查 → JS去重 → pipeline逐条反驳
loop-until-dry：while循环 + 换策略 + 连续N轮无新发现则停