Agent搭建并非简单的提示词堆砌，而是一场精密的架构设计。本文分享了从多人分工导致的格式混乱到主从Agent架构的全过程，揭秘如何通过依赖关系排序、上下文摘要传递等关键技术，解决跨模块协作、生成顺序错乱等核心痛点。这套方法论不仅适用于报告生成，更为复杂AI任务的系统化搭建提供了可复用的解决方案。

最近我做了一个产品深度报告的Agent，过程中踩了不少坑，也总结出一套非常值得借鉴的方法论。今天分享出来，希望能帮到同样在做Agent搭建的朋友。

01 先说一下背景

我的目标很明确：搭一个能够独立生成一份AI产品深度体验报告的Agent。

一份合格的行业深度报告，通常包含市场全景、竞品分析、产品概况、用户画像、产品体验、增长策略、SWOT分析、改进建议、执行摘要、目录和附录这些模块。每个模块的分析逻辑、专业视角、输出格式都不一样——市场分析需要数据驱动，产品分析需要结构化拆解，用户研究需要真实用户声音，增长分析需要可验证的策略观察。

正常来说，一个人用一个长对话应该就能搞定整个Agent的搭建。但我犹豫了一下：我一个人，够专业吗？

市场分析我懂一些，但竞品梯队划分怎么做更严谨？用户画像需要真实评论数据怎么采集？增长策略背后的增长模型应该用什么框架？每个模块都有自己的”专业度门槛”，我怕自己写出来的提示词，看起来有，但不够深。

于是我做了一个决定：让多个人分工协作，每人专精一个模块。

现在回头看，这个决定让我绕了很大的弯路。但也正是这个弯路，让我摸索出了一套非常值得借鉴的方法论。

02 将错就错：分工之后的混乱

分工的初衷是好的——每个模块由最擅长这个领域的人来写提示词，同时调取对应的MCP工具做网页数据抓取，保证数据的质量和深度。

比如：

• 市场分析的人负责”市场全景”，调MCP抓市场规模、竞品数据
• 产品分析的人负责”产品概况”，抓产品定位、发展历程、商业模式
• 用户研究的人负责”用户画像”，抓应用商店评论、社交媒体讨论
• 增长分析的人负责”增长策略”，抓ASO数据、投放素材、定价页面

每个人写完后，我把所有提示词汇总到一起，准备交给Claude Code去做最终的整合。

然后问题一个接一个地来了。

第一个问题：格式风格完全不统一。虽然有整体的大纲目录作为参考，但每个人的写作习惯不同，导致细节千差万别：

• 有人用## 1.1，有人用01.，有人用”第9页”，有人用Part 0
• 有人在提示词里写了”不要改变章节编号”
• 有人对表格的要求写得非常细，有人一笔带过
• 更麻烦的是，每个人写的时候都以为自己是”第2章”，编号互相冲突

第二个问题：有些东西没人写。封面怎么生成？目录怎么拼？执行摘要怎么提炼？附录怎么整理？这些依赖全部内容才能生成的部分，每个分工的人只管自己的模块，谁也没管。以为自己是”各管一摊”，结果”一摊”之间的衔接完全空白。

第三个问题：生成顺序搞错了。我一开始让Agent按章节1→2→3→4的顺序生成，结果执行摘要写出来全是空话——因为那时候后面的章节还没生成，它根本没有结论可提炼。

原来我以为分工是”加速器”，没想到它差点变成了”绊脚石”。

03 和AI反复拉扯：从混乱到v1

既然分工搞出了这些坑，那就硬着头皮补吧。

我把所有人写好的提示词文档交给Claude Code，试图让它来做最终的汇总。

一开始我想得很简单：”把所有提示词丢给它，让它自己整合。”

结果Claude Code做了很多我不想要的修改——删掉某个模块的关键限制、调整你不希望它动的内容、把各章节的编号改得面目全非。

于是我又给了它一个”补丁”指令：按照我的大纲结构调整，不要删减提示词的内容，只梳理序号，各模块内部的专家角色保留。

然后它做出来了，我又发现新的问题：某些章节的编号和大钢对不上、某些内部编号互相冲突（比如市场分析用了2.1，产品分析也用了2.1）、某些自相矛盾的指令没有被清理掉（比如提示词里写着”不要改变章节编号”，但它的编号必须改）。

我开始进入Plan模式，和Claude Code反复拉扯。一轮一轮地对话、一轮一轮地调整、一轮一轮地验证。从”帮我改编号”到”这块内容你理解错了”，从”这里不能删”到”那里编号又乱了”。

说实话，这个过程挺痛苦的。因为Claude Code不会主动理解你的”不改什么”，它只会执行你的”改什么”。你需要非常精确地告诉它边界在哪里。

最终，经过多轮拉扯，生成了一版看起来完整的v1版本。

04 v1还不够：需要一个”总指挥”

v1出来后，我试了一下，发现生成的报告还是不完整。

问题出在哪里？

每个人只负责生成各自部分的报告——市场分析负责市场全景，产品分析负责产品概况，用户研究负责用户画像。但没有人负责那些依赖全部内容才能生成的部分：

• 封面怎么生成？需要汇总产品名、作者、日期
• 目录怎么生成？需要知道所有章节的实际结构，不能凭空编
• 执行摘要怎么写？需要提炼前8章的核心结论，但那时候后面的章节还没生成
• 附录怎么整理？需要汇总所有章节中引用的数据来源

这些不是”某个模块”的问题，而是全局性的问题。你让市场分析组写执行摘要？他们不知道用户研究的结论是什么。你让产品分析组写目录？他们不知道增长策略最终输出了几个子节。

更关键的是：生成顺序搞错了。如果按章节1→2→3→4的顺序生成，执行摘要写出来一定是空话——因为它是”总结”，而后面还有7个章节没生成。

这就像是让一个人写论文的”结论”，但他的文献综述、方法论、数据分析都还没写。写出来的结论能有什么深度？

这时候我意识到：我需要一个”总指挥”。而且不是简单的拼装工——它需要能调度、能统筹、能处理依赖关系、能管理上下文。

05 最终方案：主从Agent + 上下文摘要传递

于是，我重新设计了整个架构。核心思路是：

主Agent是总指挥，负责调度、统筹、汇总。分Agent是各领域专家，负责各自模块的专业分析。

主Agent和分Agent不是简单的”拼装关系”，而是有明确的职责分工和依赖管理。

主Agent的职责（总指挥）：

• 接收用户的输入，制定执行计划
• 按依赖关系排序各模块的生成顺序
• 调度分Agent依次执行，每步切换专家角色
• 处理那些”依赖全部内容”的部分：封面、目录、执行摘要、附录
• 做最后的整合和拼装

分Agent的职责（领域专家）：

• 各自拿到自己的提示词后，独立完成分析
• 每个分Agent有自己的专业角色（市场全景专家、资深AI产品经理、增长策略分析师……）
• 调用对应的MCP工具获取真实数据
• 不需要关心全局，只需要把自己的模块写好

关键突破：按依赖关系排序。

生成顺序不是按报告章节1→2→3→4来排，而是按依赖关系来排：

执行摘要必须放在最后，因为它需要”提炼整个报告最重要的3~5个结论”。如果它先生成，后面7章还没写，它只能写空话。目录和附录同理——必须看到所有章节的最终结构，才能生成准确的目录和完整的附录。

还有一个隐藏的坑：上下文窗口溢出。

方案定了，但我又发现了一个问题。如果让一个对话里的Agent按顺序生成全部10个章节，到了后面的章节，前面的内容已经占满了上下文窗口——后面的章节开始截断、遗忘关键结论、输出质量下降。

一份完整的产品深度体验报告通常有3-5万字，一个Claude对话的上下文虽然有200K tokens，但提示词本身加上已经生成的内容，到了Step 7、Step 8就容易超。

我的解决方案是：每章生成完后，自动提取一个300-500字的关键摘要，后续章节只接收摘要，不接收完整内容。

别小看这个摘要模板。它不只是”压缩文字”那么简单。第四栏**”数据缺口”**是最有价值的——它把跨模块的线索传递了起来。

举个例子：市场分析没有找到某个竞品的MAU数据，这个缺口会在摘要中标注出来。到了用户分析模块，它接收到这个摘要，就知道”前序没搞定那个数据，我这边需要关注”。这就是跨模块的线索传递——让每个模块不只是独立工作，还能接收到前序的”遗留任务”。

整个架构最终形成了12个Step，其中Step 2-8是主体分析（各分Agent执行），Step 9-11是依赖全部内容的章节（主Agent执行），Step 12是最终整合。

06 回头看，踩了哪些坑

复盘整个过程，我总结了6个关键坑点：

坑1：多人写提示词，格式必乱

现象：不同人的提示词用了不同的编号体系（2.1 vs 01. vs Part 0）。

解法：统一编号体系后再整合。如果已经写好了，用正则表达式批量替换。但更根本的解法是——在分工时就给出统一的模板。

坑2：提示词里有自相矛盾的指令

现象：某个提示词里写着”不要改变章节编号”，但整合后它的编号必须改。

解法：整合时删除模块内部的”不要改变章节编号”限制，在全局规则中统一规定。

坑3：摘要和附录没人写

现象：分工时每个人都负责”主体分析模块”，但封面、目录、执行摘要、附录这些依赖全部内容的部分没人负责。

解法：这是主Agent的核心职责。主Agent不能只是”拼装工”，它需要有自己的提示词来处理这些依赖全部内容的环节。

坑4：一次生成太长会截断

现象：10个章节一次性生成，到了第8章就开始质量下降或截断。

解法：分步生成+摘要传递。每次只生成一个章节，生成完后提取摘要，后续章节只接收摘要。

坑5：不同模块的专家角色被混淆

现象：整合后，所有模块都用同一个”产品分析专家”的角色设定。

解法：保留每个模块的专家角色。市场分析用”市场全景专家”，用户研究用”资深AI产品经理”，增长分析用”资深增长策略分析师”。不同领域的分析需要不同专家的专业视角。

坑6：生成顺序搞错了

现象：让Agent按章节1→2→3→4的顺序生成，结果执行摘要写出来是空话。

解法：按依赖关系排序。执行摘要必须在主体章节完成后生成，目录必须在所有内容完成后生成。

07 这个方法论的通用性

这套”主从Agent”的架构思路，其实不只适用于报告生成。任何一个需要多领域专业知识、多步骤输出、有依赖关系的复杂任务，都可以用这个框架。

拆解任务时问自己三个问题：

1. 这个任务可以拆成几个独立的专业模块？—— 每个模块对应一个子Agent
2. 哪些模块之间有依赖关系？—— 依赖关系决定生成顺序
3. 有没有哪些输出需要”汇总全部内容”才能生成？—— 这些是主Agent的核心职责

举几个例子：

• 竞品分析报告：子Agent分析每家竞品，主Agent做对比和结论
• 产品规划文档：子Agent分析用户需求、技术可行性、商业模式，主Agent做优先级排序和roadmap
• 用户研究报告：子Agent分别做定量分析、定性访谈、竞品benchmark，主Agent做洞察整合

08 最后

回头看整个过程，其实最开始那个”多个人分工”的决定，反而帮我想清楚了一件事：任何一个复杂任务的Agent搭建，本质上都是一个架构设计问题，而不只是提示词问题。

提示词解决的是”每个模块怎么写得专业”——专家角色、分析框架、输出格式、质量标准。

架构解决的是”多个模块怎么组合在一起”——依赖关系、生成顺序、上下文传递、整合机制。

这两件事缺一不可。但很多人在搭Agent的时候，只关心前者，忽略了后者。

我的经验是：先把架构想清楚，再写提示词。如果顺序反了，你会像我一样——写完了再改编号、再改顺序、再解决截断问题、再和AI反复拉扯。

当然，如果当初我没走那个”分工”的弯路，可能也不会发现这些问题。有时候，将错就错反而能发现真正的答案。