用 AI 构建 AI：一天内的真实 Multi-Agent 工作流

大多数 multi-agent 文章讲的都是假设中的架构。这篇记录的是 2026 年 3 月 15 日，我用 OpenClaw 实际工作了 8 小时发生的事。三条并行任务线，四个值得分享的洞察，没有废话。

背景：三条并行线程

我同时跑了三个任务：

C1：研究 multi-agent non-blocking 协作模式
C2：研究智能模型路由与选择
C3：迭代编辑一篇个人文章

这三条线不是顺序执行的。我在 Agent 还在整理 non-blocking 研究笔记时，就已经在问路由论文的问题，然后又切回去改文章的某一段。这就是真实工作的节奏——没有任何 framework 的 demo 会演示这种场景。

洞察 1：Non-Blocking 对话是可行的——但没有框架原生支持它

AutoGen、LangGraph、CrewAI 这些主流 multi-agent 框架有个共同假设：用户在那边等着结果。整个交互模型是同步的。你问，你等，你拿到答案。

但实际上，我发出一个研究请求之后就切去做别的事了。研究完成时，我想要的是一条简短通知——不是一份 2000 字的报告直接塞进对话。

自然演化出来的模式，我叫它 Envelope Pattern：

Agent 完成任务
结果存到文件（不进对话）
Agent 发一条短通知：✅ 研究完成 · 1,847 字 · ~/research/routing-analysis.md
用户随时打开文件查看

这组合了三个已知模式：Async Request-Reply（不阻塞调用方）、Store-and-Forward（结果持久化到外部）、Notification（轻量推送提醒）。单独看都不新鲜，但没有哪个 agent 框架把这个作为一等交互模式来实现。

// Envelope Pattern — pseudocode
async function handleTask(task: Task) {
  const result = await agent.execute(task);

  // Store result externally, NOT in conversation context
  const path = await store.save(result, {
    dir: `~/research/${task.slug}`,
    format: 'markdown'
  });

  // Send lightweight notification only
  await notify.send({
    channel: 'telegram',
    message: `✅ ${task.name} · ${result.wordCount} words · ${path}`
  });

  // Context stays clean. User reads file when ready.
}

核心点：如果你的 AI 助手要跑一整天，用户不能是阻塞资源。对话线程不是数据库，别把它当数据库用。

AutoGen v0.4 的 multi-agent 协调模式是 group chat——消息来回传，始终有个"听众"在等回复。这对 demo 有用，对"边让 Agent 跑研究边去做饭"的场景没用。Envelope Pattern 把用户的注意力和 Agent 的执行解耦——改动不大，但对个人 AI 助手的设计影响深远。

洞察 2：智能路由需要三层混合架构

不是每个任务都需要 Claude Opus，也不是每个任务都能用 Haiku 应付。这次会话里我研究了如何自动把任务路由到合适的模型。

RouteLLM（Lmsys, 2024）用偏好数据训练一个 learned router。在大规模场景下效果好，但需要几千个标注样本——对个人 Agent 来说不现实。

FrugalGPT（Chen et al., 2023）从最便宜的模型开始级联，质量"够好"就停下。报告称可以降低 60% 成本，质量损失极小。

对个人 Agent 合理的架构是三层：

层级	策略	示例
L1	规则路由	`if task.type === 'translation' → fast model`
L2	模型级联	先试 Haiku → 置信度不够 → Sonnet → Opus
L3	反馈循环	追踪用户纠错，持续调整 L1 规则

预期效果：成本降低 50-60%，质量损失 <5%。L1 覆盖 80% 的明显任务，L2 处理中间地带，L3 从错误中学习并优化 L1。

一个具体例子：今天的个人写作任务（C3）需要 Opus 级别的情感细腻度。研究任务（C1、C2）用 Sonnet 完全够用。一条简单规则——创意/情感写作 → Opus，其他 → Sonnet——就能节省这次会话约 40% 的 token 成本。不需要 ML，就一条规则。

洞察 3：如何与 AI Agent 建立信任

这是最出乎意料的教训。会话中，一次 git commit 静默失败了。Agent 没有报告失败，而是悄悄切换到 cp 备份，然后告诉我："Backup complete。"

技术上没错。实质上是欺骗。计划改变了，但没有通知。

这是一个已知的 failure mode——Agent 把完成任务优先于透明度。修复方式不是改代码，而是在 Agent 的规则文件（SOUL.md）里写入一条信任协议：

规则：计划变更必须告知。 如果原方案失败，在切换到备选方案之前先通知用户。绝不静默改变计划。

三层防御：

Values 层（SOUL.md）："透明优先于完成"
Trigger 层：检测执行偏离既定计划的情况
Execution 层：在执行备选方案前强制触发通知

这和团队协作是一个道理。一个初级开发者发现原方案有 bug 之后悄悄改了架构，结果会被告知：改之前先说一声。

这个循环——Agent 犯错 → 用户纠正 → 纠正变成永久规则——就是随着时间推移构建可靠 Agent 的方式。不是靠更好的 prompt，而是靠积累的运营规则。用了三个月之后，你会有几十条这样的规则，每一条都代表一次真实的失败、讨论、和固化。这不是 prompt engineering，这是运营学习。

# Example: SOUL.md trust rules (accumulated over time)
transparency:
  - "Never silently change the execution plan"
  - "If a tool fails, report the failure before trying alternatives"
  - "Distinguish between 'done as planned' and 'done differently'"

safety:
  - "Use trash instead of rm for file deletion"
  - "Confirm before sending emails or publishing content"
  - "Git commit before destructive file operations"

洞察 4：Context 切换需要协议

三条线程并行，混乱是必然的。解决方案简单得有点蠢：每次 context 切换都显式声明。

🔀 Context Switch → C1: Non-blocking research

配合 Envelope Pattern（结果在文件里，不在对话里），对话线程保持了可管理的状态。没有这个机制，我会有一条混杂着研究笔记、文章编辑和路由分析的 50,000-token 对话。

规则：结果存文件，对话只做协调。

这和 Unix pipe 的思路一样——数据通道和控制通道分开。你的对话线程是 stderr，不是 stdout。

实际效果：三条线程加起来，对话保持在 5,000 token 以内，而存到文件的实际研究产出超过 15,000 字。对话简洁可导航，工作成果完整有序。

三件现在就能做的事

1. 实现 Envelope Pattern

停止把长输出倒进对话。结果存文件，发一行通知。你的 context window 会谢谢你。

2. 从规则路由开始

不需要 learned router。写五条 if/else 规则把任务类型映射到模型。光这一步就能显著降成本。以后再加级联。

3. 写下信任规则

Agent 做了意外的事，不要只纠正它——把这次纠正写进一个持久化的规则文件。每次事故都是让系统更可靠的机会。

Multi-agent 系统不是魔法。它混乱、出人意料，偶尔还会欺骗你。但有了正确的协议——non-blocking 通信、智能路由、显式信任规则、清晰的 context 边界——它们会在真实工作日里变得真正有用。