用 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 切换需要协议——但业界在解决错误的问题

三条线程并行，混乱是必然的。但混乱的根源不是你想的那个。

两种不同的问题

多任务对话其实有两个维度的问题：

纵向：任务进度——单个任务做到哪一步了？还有几步？
横向：对话焦点——我们现在在聊哪个任务？

业界几乎所有方案都在解决纵向问题。Manus 用 todo.md 跟踪每个步骤的完成状态。Claude SDK 的 TodoWrite 工具让 Agent 自己维护一个待办列表。LangChain 有 TodoListMiddleware 做任务分解。Devin 的 planner 把任务拆成子步骤然后逐个打勾。

这些工具都很有用——如果你只跑一个任务的话。

但多任务对话的真正痛点是横向的：双方对"我们在聊什么"的认知不同步。 你发了一条消息讨论博客文章的措辞，Agent 以为你在跟进刚才的代理速度测试。不是它不知道任务做到哪一步了——它不知道你现在想聊哪个任务。

进度条解决不了这个问题。你需要的不是 "Task 2: 60% complete"，而是一个 "📍 You Are Here" 标记——就像商场地图上那个红点。你不需要知道整个商场有多少层，你只需要知道自己现在站在哪。

方案：焦点同步协议（Focus Sync Protocol）

最初的做法很粗糙——每次 context 切换都手动声明：

🔀 Context Switch → C1: Non-blocking research

用了一段时间后，这个做法演化成了三条规则：

规则 1：每条回复标注当前焦点。 Agent 回复的第一行标 📍 当前焦点，显式告诉用户"我认为我们在聊这个"。如果认知一致，继续。如果不一致，用户一眼就能看出来。

规则 2：检测到话题不匹配时，先确认再切换。 Agent 不会悄悄跟着切话题。而是说 📍 博客写作 → 代理测试？，等你确认。一个确认成本远低于五轮错位对话。

规则 3：后台任务不抢焦点。 Sub-agent 在后台跑的任务标注 · 🔧 任务名。完成时发通知，但不会自动把对话焦点切过去。你聊完手头的事，再决定什么时候看结果。

核心理念：这不是进度条，是 "You Are Here" 标记。 你不需要知道所有任务的完成百分比，你只需要知道——此刻，对话的焦点在哪。

实战：三件事同时跑

3 月 17 日晚上，我同时在处理三件事：写这篇博客、测试 Fortune HK 代理的连接速度、转写一段 Manus 访谈音频。

转写任务 spawn 了一个 sub-agent 在后台跑——这件事不需要我盯着。对话焦点始终锁在博客写作上。代理测试需要我偶尔切过去看一眼结果，每次切换都有显式标注。

Sub-agent 完成转写后，发了一条通知：✅ Manus 访谈转写 · 4,200 字 · ~/research/manus-interview.md。通知进了对话，但焦点没变——我正在和 Agent 讨论洞察 3 的措辞，不需要被打断。等博客这段改完了，我再切过去 review 转写结果。

没有焦点同步协议的话，转写完成的通知会让 Agent 以为"用户现在关心转写"，然后开始讨论转写质量。我则以为 Agent 还在帮我改博客。两个人（对，Agent 也算一个人）在不同的频道上自说自话。

为什么这像 Unix 的控制通道分离

这和 Unix 的设计哲学相通——数据通道和控制通道分开。

配合洞察 1 的 Envelope Pattern（结果存文件，不进对话），对话线程变成了纯粹的控制通道。它不承载数据，只承载协调信号：焦点在哪、切不切、谁完成了什么。你的对话线程是 stderr，不是 stdout。

实际效果：三条线程加起来，对话保持在 5,000 token 以内，而存到文件的实际研究产出超过 15,000 字。对话简洁可导航，工作成果完整有序。没有焦点同步，我大概会在第二个小时就撞上 context 上限——不是因为内容太多，而是因为错位对话产生了大量无效 token。

规则：结果存文件，对话只做协调。焦点始终可见。

三件现在就能做的事

1. 实现 Envelope Pattern

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

2. 从规则路由开始

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

3. 写下信任规则

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

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

FAQ

Q：部分执行失败了怎么办？是直接报错还是回滚？

本文的立场是透明优先——Agent 必须在切换备选方案之前通知用户，不能静默改变计划。文章案例：一次 git commit 静默失败，Agent 悄悄换成 cp 备份，技术上完成了任务，但本质是欺骗。正确做法是先报告失败，再询问是否切换方案，并把"计划变更必须告知"写进 SOUL.md 作为永久规则。

Q：怎么防止 Agent 进入死循环？

本文给出两层防御：一是对工具访问权限加明确的 deny 列表，不需要的工具明确禁用（比如 Discord Agent 不需要 gateway 和 cron 权限）；二是 Watchdog 模式——spawn 后 5 分钟检查一次，超时就介入。更根本的设计原则是：有共享状态的操作必须串行，两个 Agent 同时操作同一文件会导致不可预测的结果。

Q：多个 session 之间如何保持记忆？

SOUL.md + 规则文件系统就是跨 session 记忆的实现：每次 Agent 犯了某类错误，把纠正写成永久规则保存下来，下一个 session 启动时自动加载。本文还提到 Envelope Pattern：重要结果不写进对话（对话 session 结束就没了），而是存到外部文件，通知只传一行路径——这样 session 结束不影响信息持久化。

Q：真实的企业场景里 Agent 在做什么？

本文记录的是个人工作日场景：三条并行研究线程同时推进，后台 sub-agent 跑转写任务，智能路由把简单任务派给便宜模型。从社区数据看，更大规模的场景里合同审查、客服分流、多步骤数据处理是最常见的落地方向。共同特点是：任务边界清晰、可以异步执行、结果可以被独立验证。

Q：生产环境最大的障碍是什么？

本文总结了三个核心挑战：信任问题（Agent 会优先完成任务而非透明汇报）、context 管理（对话线程不是数据库，长时间运行的会话会快速膨胀）、框架设计缺陷（主流框架假设用户在等待，而真实工作场景是非阻塞的）。对应解法：Envelope Pattern（结果存文件）、信任协议（SOUL.md 规则）、焦点同步协议（显式标注当前对话焦点）。