用AI做大项目，你缺的不是更强的模型，是架构

你大概已经过了"AI能不能用"这个阶段。日常写东西、改代码、做research，Claude或GPT已经是你的默认工具。

但你一定遇到过这个问题：项目一大，对话就崩。

你边research边讨论边出框架边写，前面聊了什么越来越模糊，到后半段你在复述自己说过的话，Claude在重新发明你们已经否掉的方案。context window的物理限制卡在那，你再怎么提醒"参考前面的讨论"也没用。

这不是模型不够聪明。这是你在用单agent模式干multi-agent的活。

Anthropic自己是怎么解决这个问题的

Anthropic最近发了一篇工程博客，讲他们怎么构建Claude Research背后的multi-agent系统。核心架构叫orchestrator-worker模式：一个lead agent负责拆解问题、制定策略，然后spawn多个subagent并行去搜索和分析。

几个关键发现值得注意：

Delegation必须极其具体。 他们一开始给subagent模糊指令比如"研究半导体短缺"，结果一个agent查2021年的汽车芯片危机，另外两个重复查2025年供应链，完全没有有效分工。后来每个subagent都需要明确的目标、输出格式、工具指引和任务边界，效果才上来。

Effort要match复杂度。 简单事实查证一个agent做3-10次tool call就够了，直接对比需要2-4个subagent，复杂研究可能要10个以上，每个都有清晰的分工。

Multi-agent比single-agent强90%。 在他们的内部评估里，Claude Opus做lead + Sonnet做subagent的组合，比单个Opus强了90.2%。

有意思的是，他们还有一篇更早的方法论文章"Building effective agents"里反复强调一句话：从最简单的方案开始，只在确实能改善效果时才加复杂度。

这两篇放在一起读，信号很清楚：复杂项目确实需要multi-agent架构，但不是为了酷，是因为单agent真的扛不住。

你现在就能用的multi-agent工作流

你没有API，不会写orchestration代码，没关系。Claude的产品功能已经够你手动搭一个multi-agent系统了。核心思路：你自己当orchestrator，用Project当容器，用running doc做agent间的信息传递。

下面用一个真实场景走一遍——假设你要写一篇深度行业分析文章。

Phase 1：正常对话做Research

不要急着开Project。先在普通对话里做发散式research。这个阶段你需要全部的memory（你的背景、偏好、之前的讨论），Project会屏蔽这些。

这个对话的目标不是写文章，是搞清楚你要写什么。讨论、争论、推翻、重来，随便造。

关键动作：讨论到一个节点时，让Claude输出一个research brief。 比如：

“帮我把目前的讨论整理成一个md：核心论点、支撑素材、还没想清楚的问题、被否掉的方向。”

这个brief就是你的第一个"subagent产出"。

Phase 2：建Project，导入context

现在开一个Project。把research brief扔进Project Knowledge。

如果你的文章需要特定背景信息（行业术语、组织关系、你的立场），也一并写进去。记住：Project里的Claude不知道你在外面聊过什么，project knowledge就是它全部的"先验知识"。

这一步你在做的事情，本质上跟Anthropic给subagent写detailed task description是一样的——定义边界、给context、明确产出格式。

Phase 3：在Project里开多个对话，各有分工

这是重点。不要在一个对话里干所有事。

对话A：框架设计。 基于research brief，跟Claude讨论文章结构。产出一个大纲，更新到project knowledge的running doc里。

对话B：逐段写作。 拿着大纲，一段一段写。每完成一个部分，把定稿内容更新到running doc。这个对话的context永远是干净的——它只需要看running doc + 当前段落的要求。

对话C：修改打磨。 全文初稿完成后，开一个新对话专门做编辑。这个对话的Claude能看到完整的running doc，但没有前面讨论的包袱，能给你更客观的反馈。

每个对话结束时，你做一个动作：把产出更新(当然是让claude更新)到project knowledge的running doc里。 这就是你的agent间信息传递机制。

Running Doc的结构建议

# [项目名] Running Doc

## 当前状态
- Phase: [research / 框架 / 写作 / 修改]
- 最后更新: [日期]

## 核心论点
[一句话]

## 文章大纲
[结构化大纲，标注每段状态：待写/初稿/定稿]

## 已完成段落
[定稿内容]

## 待解决问题
[还没想清楚的点]

## 被否掉的方向
[试过但不work的思路，防止重复讨论]

“被否掉的方向"这一栏很重要。Anthropic在他们的系统里也发现，subagent最常见的浪费就是重复探索已经排除的路径。你手动维护这个列表，就是在帮每个新对话避免做无用功。

为什么这样做比"一个对话聊到底"好

三个原因：

Context window的有效利用率高。 每个对话只装它需要的信息，不用扛前面几千token的讨论历史。你的running doc是经过压缩的精华，信噪比远高于原始对话。

每个对话的角色清晰。 跟Anthropic给subagent分配具体任务一样，“框架设计"和"逐段写作"是两种不同的思维模式。分开做，每个对话的产出质量都更高。

你作为orchestrator的判断力是不可替代的。 什么时候从research切到写作，哪些信息该保留哪些该丢，running doc怎么更新——这些决策是AI做不了的。Anthropic的lead agent也只能按规则分配任务，真正的策略调整还是靠人。

一个诚实的补充

这套工作流有摩擦。每次"结算"一个阶段、更新running doc、开新对话，都是手动操作。比起在一个对话里一路聊下去，它更慢、更需要纪律。

但如果你的项目大到一个对话扛不住——你会发现这点摩擦远小于在崩掉的context里反复纠正和重复劳动的成本。

Anthropic自己说，multi-agent系统的token消耗是普通chat的15倍。你手动搭的这个"人肉multi-agent"也一样，总对话量会多出不少。但跟他们得出的结论一样：对于复杂度足够高的任务，这个tradeoff是值得的。

关键是判断什么时候值得切换。简单任务，一个对话聊完。中等任务，一个对话加上"帮我总结当前进度”。大项目——上Project，开多对话，维护running doc。

跟用任何工具一样，匹配复杂度，不多不少。