最近帮一家企业做技术调研时我遇到一个很典型的场景团队需要判断“要不要引入某个新平台”但资料散落在几十个网页、文档和视频里。让一个人去查容易偏信让几个人分头查汇总时又各说各话。最后往往是一周时间花掉了PPT 做出来了但决策层问几个追问团队就答不上来。去年开始我把这类“调研—反证—汇总”的工作交给 Claude Code 里的多智能体协作流程来做。试完之后我的判断是Agent Teams 的价值不体现在“同时开了几个任务”而在于它把一次不可控的信息搜集变成了一套可管理、可核查、可复用的小型工作流。这篇文章会把我实际跑通这套流程的方法、提示词结构和验收清单整理出来。不会只讲概念重点放在“怎么在企业项目里真正用起来”以及哪些地方最容易翻车。1. 先搞清楚Agent Teams 解决的是“多人协作的流程问题”不是“多开几个任务”1.1 单线程提示词够用为什么还要 Agent Teams很多人第一次接触 Claude Code 时习惯是“给它一个复杂任务让它一口气做完”。比如“帮我调研一下 MCP 在企业落地的方案。”“写一份竞品分析报告。”“整理一份知识库文档。”这种方式适合小任务但一旦任务范围变大问题就暴露了。Claude Code 虽然能处理很长上下文但单线程处理时它会自己揣摩你的需求自己决定先做什么、后做什么。结果常常是报告写得挺顺畅但缺少深入验证缺少反对意见甚至会把一些未经证明的假设当成结论直接写进文档。Agent Teams 的思路不是让一个 Agent 从头做到尾而是把任务拆给不同角色的 Agent一个负责正向调研一个负责反向证伪一个负责把两边合成最终结论。这就像写文章之前先让几个人从不同立场发言再由主编统稿。单线程提示词适合“执行”Agent Teams 适合“决策前的信息准备”。前者追求快后者追求可靠。1.2 企业项目的真正痛点输出不可信、过程不可查、结论不可复用企业项目和开发者自己玩不一样。我自己做个人学习时AI 给个大概方向就够了但一旦放到企业里就必须面对三个非常现实的问题第一个是输出不可信。AI 生成的内容很可能有知识过期、数据交叉混淆、甚至凭空推断。它不会主动告诉你“这条信息我不确定”它只会用一种非常确定的语气写出来。第二个是过程不可查。如果让一个 Agent 直接写最终报告你可能看不到它依据了哪些材料、跳过了哪些信息、做了哪些取舍。汇报时被问“这个数据哪来的”你答不上来。第三个是结论不可复用。人工做调研做完一次就结束了经验全在脑子里。用 AI 做调研如果只是复制粘贴几段回答做完一次也就结束了下次还得从头写提示词。Agent Teams 的真正价值是把“输出一份报告”升级成“跑通一条流水线”。角色固定、任务步骤固定、验收标准固定。第一次跑通后换个主题还能继续用。2. 搭一个最小 Agent Teams调研、反证、汇总三个角色怎么分工2.1 角色拆解三个 Agent 各自的职责与产出物在 Claude Code 里搭 Agent Teams不需要先从复杂框架开始。我先跑通的是最小三角色结构每个角色有明确职责和固定交付物。调研 Agent正向职责围绕主题收集信息列出支持性论据、案例、数据和实现路径。产出物一份带来源标记的要点报告。信息要按“事实/推断/待验证”三类分开。关键动作做第一轮广度扫描不提前下结论。反证 Agent反向职责对调研 Agent 的结论提出质疑找出反例、失效条件、统计偏差和逻辑漏洞。产出物质疑清单。列出哪些结论不可靠、哪些数据不适用、哪些前提可能不成立。关键动作故意站在对立面先假设调研结论有问题再找证据。汇总 Agent决策辅助职责把调研报告和质疑清单合成最终交付文档。产出物结论与不确定性说明包含“如果……那么……”形式的决策条件、待人工确认事项、下一步行动建议。关键动作不合并矛盾而是把矛盾显式写出来。这三个角色的关系不是“上游—下游”单向流水线。调研 Agent 先输出反证 Agent 再质疑汇总 Agent 综合。如果有必要还可以把反证结果丢回调研 Agent 做一次修订。这就是第一轮和第二轮协作。2.2 分工提示词的正确写法先定任务、再定边界、最后定交付格式提示词是 Agent Teams 里最容易出问题的地方。我踩过最大的坑是角色写得太像人设任务写得太模糊。比如这样写就非常错你是一个严谨的调研专家请认真负责地完成调研。“严谨”“认真负责”这种词对模型没有约束力。模型不会因为你在提示词里夸它严谨就真的变严谨。真正起作用的是任务边界和交付格式。我更推荐按照“角色—任务—边界—交付格式”四段式来写提示词。以一个调研 Agent 的提示词为例你是一个企业技术调研助手。 任务围绕「主题」收集市场、技术、成本和风险四类信息各整理至少 5 条有效信息。 边界 1. 只基于材料或公认常识写作不编造数据。 2. 每条信息必须标注可能的来源方向或验证方式。 3. 不确定的内容必须标注「待验证」不得写成确定结论。 交付格式Markdown 表格列名主题 / 核心观点 / 支持证据 / 信息来源方向 / 可信度 / 是否需要人工复核。这里的核心不是“你是一个严谨的调研专家”而是“不确定的内容必须标注『待验证』不得写成确定结论”。后者才是模型能执行的行为约束。2.3 从实操看提示词应该保留哪些关键字段整理了几次实战之后我发现一份能直接用的 Agent 提示词至少要有六个字段字段作用容易被忽略的原因角色定位告诉 Agent 要站在什么视角很多人只写角色名不写视角任务目标明确最终要交付什么目标必须是动词短语比如“输出一份列表”输入来源说明材料在哪里不写就会自行脑补工作边界明确不要做什么不写就什么都说容易编造交付格式规定输出结构不写就会输出长散文验收标准告诉 Agent 什么样算完成不写就交一份半成品比如反证 Agent 的提示词里验收标准可以写“至少提出 5 条对调研结论的质疑每条必须给出一个可能的反例或失效场景。”汇总 Agent 的提示词里验收标准可以写“最终报告必须同时包含「结论」「不确定性」「人工复核点」三个章节。”有了这几个字段Agent 才知道自己要做到什么程度才算完工。3. 在 Claude Code 里一次跑通从环境准备到两轮协作3.1 环境准备安装、登录、项目目录与基础配置关于 Claude Code 的安装我在实际尝试中基本遵循官方文档的做法。不同操作系统和版本会有差异落地前先确认你手上的版本和官方文档一致。一般需要确认以下几项Node.js 环境Claude Code 的启动和扩展通常依赖 Node.js建议先确认版本符合官方要求。账号登录与授权安装完成后在终端里执行登录操作。企业场景中需要确认账号具备 Claude 使用权限。项目目录建议为每一个调研任务单独建目录不要把所有 Agent 任务都堆在主目录里。目录里放一份AGENTS.md或任务说明文件方便理解和复现。终端类型Windows 上我遇到过 PowerShell 的权限问题换成 CMD 或配置好终端权限会顺利很多。这里没有统一答案以你的实际环境为准。更稳妥的做法是先在官方文档里找到安装章节对照自己的系统完成安装然后跑一次最小命令验证 Claude Code 能正常启动。如果启动命令都报错后面的 Agent Teams 流程先不要谈。3.2 用提示词初始化三个 Agent 并完成第一轮任务我这里说的方法是基于常见使用流程做的示例结构不是某个固定版本的功能。具体操作时要把下面的文字替换成你自己的主题。第一步在 Claude Code 会话里分别用三段角色提示词初始化三个 Agent。如果 Claude Code 支持子任务或多 Agent 模式就依据官方提供的写法来组织如果不支持也可以在一个会话里按顺序切换提示词效果接近。以“要不要引入一个新平台”为例我给调研 Agent 的提示词可以这样写角色技术调研助手 任务围绕「该平台在企业场景的应用现状」输出调研简报。 边界只基于现有材料或公认信息每条结论都要能说出依据来源方向无法确认的写「待验证」。 交付格式 1. 平台能力摘要 2. 典型落地场景 3. 已知限制或风险 4. 待人工确认问题列表跑完这一步通常会得到一个结构完整的调研简报。但这只是第一步。如果不做反证你得到的信息会很“顺”顺得让人想直接写报告。3.3 引入反证 Agent 后的第二轮调整接下来把调研 Agent 的输出直接作为反证 Agent 的输入。反证 Agent 的提示词可以这样写角色反证审阅助手 任务对调研简报进行压力测试找出其中不可靠、不完整、逻辑跳跃或可能被误导的部分。 边界 1. 假设每一条结论都有可能是错的。 2. 对每一条结论至少给出一种反例或失效条件。 3. 不要补充新信息只做质疑。 交付格式问题清单按严重程度排序每条写清「原始结论 / 质疑点 / 可能的后果」。这个环节是很多人不会做的因为它和直觉相悖。我们习惯让 AI 帮忙“做成事”很少有人主动让它“拆台”。但从企业决策的角度看反证环节比调研环节更重要。它能让决策者看到硬币的另一面而不是只看一份精心包装的正面报告。3.4 汇总 Agent 如何把两部分内容合成一份可交付报告最后一步把调研 Agent 的输出和反证 Agent 的质疑清单同时交给汇总 Agent。汇总 Agent 的提示词可以这样写角色决策汇总助手 任务将调研简报与质疑清单合并为一份交付文档。 边界 1. 不得删除质疑必须保留不一致的结论。 2. 对每一条关键结论都用「支持证据」和「质疑点」两个角度呈现。 3. 最终必须给出结论 / 不确定性 / 人工复核点 / 下一步行动建议。 交付格式Markdown 文档适合直接放入项目 Wiki 或汇报材料。汇总阶段的关键词是“保留不一致”不是“消解不一致”。如果汇总 Agent 把所有矛盾意见统一成“结论可行”这个报告就失去价值了。4. 验收清单怎么判断这次多 Agent 协作是“跑通”了4.1 一份可以直接抄走的验收清单“跑通”不能只看有没有输出报告。输出一份毫无根据的报告那叫“跑错了”。我建议用下面这份清单作为验收标准每一项都打勾才说明流程是合格的。编号验收项判断标准1来源可追溯每条关键论点都标注了信息来源方向或验证方式2事实与推断分离报告能分清“确定事实”“合理推断”“待验证信息”3反证存在质疑清单不少于 5 条而且不是“走流程”式质疑4矛盾保留最终报告没有把争议结论偷偷抹平5不确定性显式有专门章节或表格列出“目前不确定的地方”6人工复核点明确报告明确指出哪些地方需要人来做最终判断7决策条件清晰关键建议以“如果……那么……”形式组织8可复现提示词和输入材料保存下来换个主题后能复用9版本记录完整记录了使用的模型/工具版本、提示词版本、时间10人工审阅人存在有明确的负责人在报告上签字或确认4.2 常见“假跑通”看起来有报告实际上经不起追问用这套流程跑几次后你会发现一种典型情况报告看起来像模像样但追问两层就露馅。比如报告写“目前业界普遍认为 A 方案更具优势”追问一句“这个结论基于哪些材料时间截止到什么时候覆盖了多少个案例”——如果 Agent 答不出来说明这条结论大概率是模型基于训练数据里的刻板印象写出来的。这就是验收清单第一条“来源可追溯”要防的情况。宁可让报告显得“空”也不能让它显得“假”。“空”可以通过后续补充完善“假”会直接误导决策而且很不容易被识别出来。4.3 验收之后还要做的两个动作版本记录与人工复核我见过很多团队把 Agent 生成的报告直接用结果过了两个月发现某个数据错了。这时候想追责、想复盘却根本不知道当时是拿什么提示词、什么模型版本、什么输入材料跑出来的。所以每次跑完 Agent Teams一定要顺手做两个动作把本次运行的提示词全文、输入材料、输出报告、模型版本、日期保存到一个文件夹里。以后复盘只需要打开这一个文件夹。把报告里“待人工复核”的每一条单独摘出来指派给具体的人确认。不要停留在“已列出来”这一步。建议的做法格式projects/2025-06-20-agent-teams-practice/ ├── prompts/ │ ├── 01-investigation.md │ ├── 02-challenge.md │ └── 03-summary.md ├── inputs/ │ └── reference-links.md ├── outputs/ │ ├── investigation-report.md │ ├── challenge-list.md │ └── final-deliverable.md └── README.md5. 企业项目落地的坑点与排查链路5.1 按现象定位问题输出冲突、内容拼凑、结论摇摆多 Agent 协作常见的失败现象主要有三种。遇到问题先别急着改提示词先按现象分类再排查。第一种三个 Agent 输出互相冲突无法整合。调研 Agent 说“方案 A 是主流”反证 Agent 说“方案 A 已衰退”。汇总 Agent 不知所措。这种现象的根源通常是输入没有限定。三个 Agent 各自脑补了不同的背景材料。解决办法给三个 Agent 提供完全相同的输入材料明确要求只基于材料做判断不要自行补充超出材料的“事实”。第二种汇总报告像拼接文档没有增量。调研部分两页质疑部分两页汇总部分把两者简单复制粘贴然后加了个“综上所述”。这种问题的根源是汇总 Agent 缺少“提炼”动作。解决办法给汇总 Agent 加一条硬性要求——转换表达方式重新组织结构不直接复制任意一个上游 Agent 的完整段落。第三种同一条任务跑两次结论差别很大。第一次说方案可行第二次说风险太高。这种现象和模型随机性、上下文内容都有关系。建议为关键任务设置固定种子或固定输出流程同时把输入材料顺序固定下来。更严一点的做法是给每个 Agent 增加一个“结论自检”步骤要求它在最终交付前先列出自己的核心判断再检查这些判断是否都有依据。5.2 提示词层面的三大常见毛病从我的实践经验看多 Agent 提示词最容易出三个毛病毛病一角色命名高大上行为约束不具体。写了“你是资深战略顾问”但没写“不得编造统计数字”。建议把“道德品质”换成“行为规则”。毛病二任务描述缺少验收标准。写“请输出调研报告”不写“报告必须包含待验证信息清单”。建议每次任务最后都加一段“完成标志”。毛病三没有防止幻觉的机制。模型有强烈的“把话圆回来”倾向。如果要求它写 5 条信息它即使只知道 2 条也会补 3 条听起来合理的。建议用“如果材料不足以支撑 5 条就写少于 5 条并明确标注信息缺口”来兜底。5.3 上下文与模型层面的局限Claude Code 的多 Agent 协作也有能力边界。首先是上下文长度。如果输入材料特别多单个 Agent 能接收的信息有限。需要自己控制输入材料规模或者把材料切块给不同 Agent 分别处理。比如调研 Agent 负责技术面另一个调研 Agent 负责商业面而不是让一个 Agent 吞下所有内容。其次是模型“讨好用户”的趋势。如果你在任务描述里强烈表达了倾向性模型更容易顺着你说。所以在反证 Agent 的提示词里最好明确写“不要认同用户观点先找到反例再下判断”。再者Agent Teams 不能替代真实的数据库查询、内部系统访问和访谈调研。它只能处理“输入材料里有的内容”和“模型训练阶段掌握的知识”。对于企业内网信息、未公开数据、实时市场数据它完全无能为力。如果你需要用 Agent Teams 做企业真实决策一定要把外部真实数据源接入流程而不是只靠模型脑内知识。5.4 哪些场景不建议用 Agent Teams不是所有项目都适合用 Agent Teams。以下场景我建议谨慎使用甚至不要用需要访问企业内网数据库或私有系统数据。Agent 如果没有接入这些系统它只能猜测猜错了就是决策事故。法律法规、医疗、财务合规等需要强事实核查的领域。AI 的输出形式再专业也不能作为法定依据。执行一次性的小任务。比如“帮我把这句话润色一下”单独一个 Agent 就够了没必要组织一场多人会议。输出速度优先的任务。Agent Teams 因为有多轮协作、反证和汇总耗时通常比单 Agent 更久。如果只是临时查一个信息直接问更快。Agent Teams 适合的是“重要但不紧急需要多角度信息支撑”的调研类任务而不是所有任务。6. 把一次跑通变成长期工作流还差哪几步6.1 提示词模板化与管理一旦确认了调研 Agent、反证 Agent、汇总 Agent 三套提示词在自己的场景里有效就应该立刻模板化。具体做法是把提示词里的“变量”抽出来用占位符代替。比如任务围绕「{{主题}}」输出调研简报。 边界 1. 只基于现有材料或公认信息。 2. 每条结论都要能说出依据来源方向。 3. 无法确认的写「待验证」。 交付格式{{交付格式}}以后换一个主题只需要把占位符替换掉不用重新设计整套流程。6.2 从单次运行到批量任务更进一步是把这套流程沉淀成一个项目模板。目录结构、提示词文件、输出路径、验收清单都可以提前固定好。以后任何一个新的调研任务复制一份模板目录替换主题跑一遍流程就能得到同规格的交付报告。这里有一个建议不要一开始就追求“自动化运行全部 Agent”。先把人工指挥跑通记录过程中每一步的输入输出确认稳定后再考虑串成自动化脚本。自动化你的不了解的东西只会让错误放大。6.3 人机协作的边界让 Agent 干事但别让 Agent 拍板最后一点也是我认为整个 Agent Teams 实践里最重要的一点Agent 可以做调研、做反证、做汇总但最终决策必须由人来拍板。AI 生成的内容有“流畅性幻觉”它能把一个不成熟的判断写得很自信。在企业项目里如果直接把 Agent 的输出当成结论那风险全在决策者身上Agent 不会承担任何后果。因此我的最终建议是把 Agent Teams 当成企业的“外脑研究院”它能帮你快速覆盖大量信息提出让人清醒的质疑整理出结构清晰的文档。但最终是否采纳、是否执行、是否需要进一步实证一定要回到人工判断环节。这套“调研—反证—汇总”的协作模式真正的价值不是省掉人工而是把人工从“从零开始搜集和阅读资料”中解放出来把时间花在更值得花的地方判断、决策和行动。下一次接到企业调研任务时不妨先试一次最小流程三个角色、三份提示词、一份验收清单。先跑通再优化。很多问题会在跑一次之后自然浮现出来。