Agent搭建并非简单的提示词堆砌，而是一场精密的架构设计。本文分享了从多人分工导致的格式混乱到主从Agent架构的全过程，揭秘如何通过依赖关系排序、上下文摘要传递等关键技术，解决跨模块协作、生成顺序错乱等核心痛点。这套方法论不仅适用于报告生成，更为复杂AI任务的系统化搭建提供了可复用的解决方案。
最近我做了一个产品深度报告的Agent，过程中踩了不少坑，也总结出一套非常值得借鉴的方法论。今天分享出来，希望能帮到同样在做Agent搭建的朋友。
我的目标很明确：搭一个能够独立生成一份AI产品深度体验报告的Agent。
一份合格的行业深度报告，通常包含市场全景、竞品分析、产品概况、用户画像、产品体验、增长策略、SWOT分析、改进建议、执行摘要、目录和附录这些模块。每个模块的分析逻辑、专业视角、输出格式都不一样——市场分析需要数据驱动，产品分析需要结构化拆解，用户研究需要真实用户声音，增长分析需要可验证的策略观察。
正常来说，一个人用一个长对话应该就能搞定整个Agent的搭建。但我犹豫了一下：我一个人，够专业吗？
市场分析我懂一些，但竞品梯队划分怎么做更严谨？用户画像需要真实评论数据怎么采集？增长策略背后的增长模型应该用什么框架？每个模块都有自己的”专业度门槛”，我怕自己写出来的提示词，看起来有，但不够深。
于是我做了一个决定：让多个人分工协作，每人专精一个模块。
现在回头看，这个决定让我绕了很大的弯路。但也正是这个弯路，让我摸索出了一套非常值得借鉴的方法论。
分工的初衷是好的——每个模块由最擅长这个领域的人来写提示词，同时调取对应的MCP工具做网页数据抓取，保证数据的质量和深度。
比如：
每个人写完后，我把所有提示词汇总到一起，准备交给Claude Code去做最终的整合。
然后问题一个接一个地来了。
第一个问题：格式风格完全不统一。虽然有整体的大纲目录作为参考，但每个人的写作习惯不同，导致细节千差万别：
第二个问题：有些东西没人写。封面怎么生成？目录怎么拼？执行摘要怎么提炼？附录怎么整理？这些依赖全部内容才能生成的部分，每个分工的人只管自己的模块，谁也没管。以为自己是”各管一摊”，结果”一摊”之间的衔接完全空白。
第三个问题：生成顺序搞错了。我一开始让Agent按章节1→2→3→4的顺序生成，结果执行摘要写出来全是空话——因为那时候后面的章节还没生成，它根本没有结论可提炼。
原来我以为分工是”加速器”，没想到它差点变成了”绊脚石”。
既然分工搞出了这些坑，那就硬着头皮补吧。
我把所有人写好的提示词文档交给Claude Code，试图让它来做最终的汇总。
一开始我想得很简单：”把所有提示词丢给它，让它自己整合。”
结果Claude Code做了很多我不想要的修改——删掉某个模块的关键限制、调整你不希望它动的内容、把各章节的编号改得面目全非。
于是我又给了它一个”补丁”指令：按照我的大纲结构调整，不要删减提示词的内容，只梳理序号，各模块内部的专家角色保留。
然后它做出来了，我又发现新的问题：某些章节的编号和大钢对不上、某些内部编号互相冲突（比如市场分析用了2.1，产品分析也用了2.1）、某些自相矛盾的指令没有被清理掉（比如提示词里写着”不要改变章节编号”，但它的编号必须改）。
我开始进入Plan模式，和Claude Code反复拉扯。一轮一轮地对话、一轮一轮地调整、一轮一轮地验证。从”帮我改编号”到”这块内容你理解错了”，从”这里不能删”到”那里编号又乱了”。
说实话，这个过程挺痛苦的。因为Claude Code不会主动理解你的”不改什么”，它只会执行你的”改什么”。你需要非常精确地告诉它边界在哪里。
最终，经过多轮拉扯，生成了一版看起来完整的v1版本。
v1出来后，我试了一下，发现生成的报告还是不完整。
问题出在哪里？
每个人只负责生成各自部分的报告——市场分析负责市场全景，产品分析负责产品概况，用户研究负责用户画像。但没有人负责那些依赖全部内容才能生成的部分：
这些不是”某个模块”的问题，而是全局性的问题。你让市场分析组写执行摘要？他们不知道用户研究的结论是什么。你让产品分析组写目录？他们不知道增长策略最终输出了几个子节。
更关键的是：生成顺序搞错了。如果按章节1→2→3→4的顺序生成，执行摘要写出来一定是空话——因为它是”总结”，而后面还有7个章节没生成。
这就像是让一个人写论文的”结论”，但他的文献综述、方法论、数据分析都还没写。写出来的结论能有什么深度？
这时候我意识到：我需要一个”总指挥”。而且不是简单的拼装工——它需要能调度、能统筹、能处理依赖关系、能管理上下文。
于是，我重新设计了整个架构。核心思路是：
主Agent是总指挥，负责调度、统筹、汇总。分Agent是各领域专家，负责各自模块的专业分析。
主Agent和分Agent不是简单的”拼装关系”，而是有明确的职责分工和依赖管理。
主Agent的职责（总指挥）：
分Agent的职责（领域专家）：
关键突破：按依赖关系排序。
生成顺序不是按报告章节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是最终整合。
复盘整个过程，我总结了6个关键坑点：
现象：不同人的提示词用了不同的编号体系（2.1 vs 01. vs Part 0）。
解法：统一编号体系后再整合。如果已经写好了，用正则表达式批量替换。但更根本的解法是——在分工时就给出统一的模板。
现象：某个提示词里写着”不要改变章节编号”，但整合后它的编号必须改。
解法：整合时删除模块内部的”不要改变章节编号”限制，在全局规则中统一规定。
现象：分工时每个人都负责”主体分析模块”，但封面、目录、执行摘要、附录这些依赖全部内容的部分没人负责。
解法：这是主Agent的核心职责。主Agent不能只是”拼装工”，它需要有自己的提示词来处理这些依赖全部内容的环节。
现象：10个章节一次性生成，到了第8章就开始质量下降或截断。
解法：分步生成+摘要传递。每次只生成一个章节，生成完后提取摘要，后续章节只接收摘要。
现象：整合后，所有模块都用同一个”产品分析专家”的角色设定。
解法：保留每个模块的专家角色。市场分析用”市场全景专家”，用户研究用”资深AI产品经理”，增长分析用”资深增长策略分析师”。不同领域的分析需要不同专家的专业视角。
现象：让Agent按章节1→2→3→4的顺序生成，结果执行摘要写出来是空话。
解法：按依赖关系排序。执行摘要必须在主体章节完成后生成，目录必须在所有内容完成后生成。
这套”主从Agent”的架构思路，其实不只适用于报告生成。任何一个需要多领域专业知识、多步骤输出、有依赖关系的复杂任务，都可以用这个框架。
拆解任务时问自己三个问题：
举几个例子：
回头看整个过程，其实最开始那个”多个人分工”的决定，反而帮我想清楚了一件事：任何一个复杂任务的Agent搭建，本质上都是一个架构设计问题，而不只是提示词问题。
提示词解决的是”每个模块怎么写得专业”——专家角色、分析框架、输出格式、质量标准。
架构解决的是”多个模块怎么组合在一起”——依赖关系、生成顺序、上下文传递、整合机制。
这两件事缺一不可。但很多人在搭Agent的时候，只关心前者，忽略了后者。
我的经验是：先把架构想清楚，再写提示词。如果顺序反了，你会像我一样——写完了再改编号、再改顺序、再解决截断问题、再和AI反复拉扯。
当然，如果当初我没走那个”分工”的弯路，可能也不会发现这些问题。有时候，将错就错反而能发现真正的答案。
本文由 @冲少说AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。