如果你最近在关注 AI 编程和 Agent 相关的话题大概率已经发现了单 Agent 写代码已经不够新鲜了真正让人兴奋的是多个 Agent 像一个小团队一样分工协作。但很多人尝试多 Agent 后反而更累了——任务拆不清楚、上下文接不上、Agent 之间互相打架最后几个智能体各说各话结论根本没法用。这里我的判断很直接多 Agent 的工程难点从来不在模型能力而在于分工、交接和验收。模型负责“想”你负责“管”。管得好三个 Agent 的产出能超过一个资深员工管不好十个 Agent 也只是十个幻觉生成器。这篇文章要解决的是基于 Claude Code 生态下的 Agent Teams 模式把“调研、反证、汇总”三个环节拆成真正的流水线附上可以直接复制的分工提示词以及每个环节的验收清单。你照着配一遍就能在企业项目的真实场景里跑通多 Agent 协作。文章会从基础概念讲起然后是环境搭建、完整流程、提示词模板、验收标准、常见问题最后是企业落地的避坑建议。全文偏实操代码和提示词都可以直接复制。1. 为什么企业项目需要多 Agent 协作先说一个很多人踩过的坑。用单 Agent 做企业项目调研常见流程是你给 Claude Code 一个任务比如“调研市场上主流的向量数据库并给出选型建议”它会吭哧吭哧写出一份看起来很完整的报告。但你仔细看会发现三个问题第一它不会否定自己。单 Agent 的输出是一条道走到黑你让它调研 TiDB它就会围绕“TiDB 有多好”找证据很少主动告诉你“这个场景其实更适合别的方案”。第二上下文太单一。企业项目的决策往往需要从多个角度审视技术可行性、团队维护成本、许可证合规、性能数据、竞品对比。这些信息杂在一起单个 Agent 很容易顾此失彼。第三结果不可追溯。报告里的结论和数据你很难搞清楚是哪条材料支撑的。一旦出问题回溯成本极高。多 Agent 协作解决的就是这三个问题。所谓 Agent Teams核心思想是把一个复杂任务拆成多个角色每个 Agent 只干一件事干完把结果交接给下一个。就像真实公司的项目组有人负责收集材料有人负责挑毛病有人负责写汇报。每一层都有明确输入输出每一层都能被检查。以“调研、反证、汇总”为例这套流水线是这样的调研 Agent 负责快速铺开把相关材料收集齐、整理成结构化初稿反证 Agent 专门给调研结果“泼冷水”找漏洞、找反例、找数据出处汇总 Agent 综合两边意见输出一份带有风险提示和置信度说明的最终报告。这个过程看起来多了一步实际上反而省时间。原因很简单让 Agent 去当“坏人”挑毛病比让人类去核对一堆材料快得多。反证 Agent 不需要特别聪明它只需要足够严格、足够机械就能把大多数问题上解决在报告交付之前。对开发者个人来说这套模式意味着你不再是一个一个地指挥 Agent而是搭好一套流程让 Agent 之间自己交接。对人来说你要做的不是写更多提示词而是设计好角色分工和验收标准。2. Claude Code 与多智能体的基础认知在进入实操之前有必要把几个基础概念讲清楚。很多教程把“Agent”“多智能体”“Agent Teams”混在一起用实际理解起来容易偏差。2.1 Claude Code 是什么Claude Code 是 Anthropic 推出的终端编程助手运行在命令行环境里。它不是一个简单的补全工具而是能读取项目文件、执行命令、修改代码、运行测试的自主 Agent。你可以把它理解成一个住在你终端里的“程序员实习生”给它一个任务它会自己规划步骤、读代码、改代码、跑测试。Claude Code 的关键特征有三个一是基于终端交互和 Git、npm、Python 等工具链天然亲近二是支持长上下文和 CLAUDE.md 项目记忆文件能持续理解项目背景三是支持 Skill、MCP 等扩展机制可以挂载工具和自定义能力。2.2 什么是多智能体Multi-Agent多智能体是指多个 AI Agent 在同一个系统里分工协作共同完成一个复杂任务。每个 Agent 有自己的角色、目标、工具和上下文它们之间通过消息传递、文件交换或统一的任务队列协作。多智能体的核心价值不是“人多力量大”而是通过角色拆分降低单次任务的复杂度。单个 Agent 做全流程上下文会越来越长、越来越乱拆成多个角色后每个 Agent 只需要关注自己的窄场景准确率和可控性都会提升。2.3 Agent Teams 模式怎么理解Agent Teams 是一种具体的多 Agent 协作编排方式。它借鉴了真实研发团队里的角色分工模式把任务按照“调研 → 反证 → 汇总”这类顺序拆解成一条流水线。在 Agent Teams 模式下核心要素有三个角色提示词每个 Agent 有自己的角色定义、工作目标和输出格式。上下文交接上一个 Agent 的输出文件成为下一个 Agent 的输入。人工验收点在关键环节之间插入人的检查和确认避免错误放大。这个模式特别适合一次性或低频率的复杂任务比如企业技术调研、方案选型、竞品分析。它不需要你写复杂的编排框架用 Claude Code 加几个目录和提示词就能跑起来。2.4 和单 Agent 写代码的核心区别如果只是写一个函数、修一个 bug单 Agent 完全够用。但企业项目里往往同时存在“信息量大”“观点对立”“决策要求高”三个特征。单 Agent 输出会有主观偏差多 Agent 通过角色对冲来纠偏。最简单的理解单 Agent 是一次对话多 Agent 是一条生产线。单 Agent 的优点在于反馈快、交互自由多 Agent 的优点在于质量可控、职责清晰、可追溯。对比维度单 AgentAgent Teams 多智能体任务复杂度低到中中到高上下文长度容易膨胀被角色拆解切短纠错能力弱容易一条道走到黑强有专门反证角色结果可追溯性低高人需要介入的频次全程介入关键节点介入3. 环境准备Claude Code 安装与基础配置开始跑多 Agent 流水线之前先把环境备好。这一部分覆盖 Claude Code 的安装、登录认证、常见编辑器集成以及本地模型的可选接入方案。3.1 前置条件Claude Code 是 Node.js 编写的命令行工具所以环境准备主要围绕 Node.js 和 npm。建议准备以下环境一个较新的 Node.js LTS 版本具体版本号以官方要求为准。npm 包管理器安装 Node.js 时一般会一起装好。Claude 账号或者你能获取到的 Claude API 访问权限。一个终端工具macOS 或 Linux 用自带终端Windows 推荐 Windows Terminal。对于企业项目建议提前确认你所在组织是否开放了 Claude Code 的订阅访问权限。如果你的机器上还没有 Node.js先到 Node.js 官网下载对应系统的 LTS 版本一路默认安装即可。安装完成后在终端验证node -v npm -v看到版本号输出就说明 Node.js 环境没有问题。3.2 安装 Claude CodeClaude Code 的安装方式非常简单核心命令只有一条npm install -g anthropic-ai/claude-code这里有几个细节值得注意第一-g表示全局安装这样你可以直接在任何目录下使用claude命令。如果全局安装遇到权限问题在 Linux / macOS 下可以尝试加上sudo不推荐生产环境直接使用更建议配置好 npm 的全局目录权限。第二安装完成后确认命令是否可用claude --version如果提示command not found说明 npm 的全局 bin 目录没有在 PATH 中。可以把 npm 全局 bin 路径加进环境变量具体的路径用npm bin -g查看。第三在 Windows PowerShell 环境下安装如果遇到执行策略限制通常需要以管理员身份打开 PowerShell并确认执行策略允许运行脚本。安装完成后如果依然无法运行检查一下 npm 全局目录是否在 PATH 中。3.3 登录与认证安装完成后在终端输入claude首次使用会进入登录流程。根据终端提示你会看到一个是登录地址和一次性授权码在浏览器里打开地址并授权即可完成后回到终端继续使用。如果你的组织已经开通了 Claude 订阅而登录时提示订阅访问被禁用通常是组织策略限制需要联系管理员确认 Claude Code 的正确开通方式。登录成功后Claude Code 会在本地保存凭据。后续打开终端运行claude一般可以直接进入交互模式。3.4 与 VSCode 集成大部分人写代码还是在编辑器里所以把 Claude Code 集成进 VSCode 是提升使用体验的重要一步。目前常见的做法有两种一种是在 VSCode 的终端里直接运行claude。因为 Claude Code 本身就是终端工具这种方式最简单也能完整使用全部功能。另一种是使用 VSCode 插件市场里的 Claude Code 相关扩展在编辑器界面里操作对话面板。这种方式操作更直观但功能完整性要看具体插件的实现建议选择较新的官方或社区维护版本。如果你使用 JetBrains 系 IDE比如 IntelliJ IDEA 或 PyCharm思路类似在 IDE 内置终端里运行claude或者安装对应的插件。本质都是调用 CLI 能力核心配置不变。3.5 可选接入本地模型或第三方模型Claude Code 的使用成本是很多人关心的问题。如果你的场景对效果要求不是特别高或者希望控制 token 消耗可以考虑接入本地模型比如 Ollama 管理的 llama、qwen 等。也可以接入 DeepSeek 等兼容 OpenAI 格式的第三方模型服务。在 Claude Code 中切换模型常见的方式是配置环境变量指向本地或第三方模型服务。以 Ollama 为例先确保 Ollama 在后台运行再选择对应的模型。这里的细节和模型版本更新较快建议以官方文档为准。给一个探索思路下载并运行 Ollama拉取一个开源模型比如 qwen 系列然后尝试通过环境变量把 Claude Code 的模型请求指向本地服务。如果配置正确你会发现在不消耗高级模型 token 的情况下也能完成简单任务。但这里要提醒本地小模型不要用于复杂的企业多 Agent 协作。调研、反证这类任务对推理能力要求较高本地 7B、13B 级别的模型很容易生成看似有理、实则空洞的内容。通用实践是重要任务用高级模型简单机械任务才用便宜模型或本地模型。4. 核心流程设计调研、反证、汇总三阶段环境搭好之后进入正题。这一节讲清楚多 Agent 协作的流程设计下一节给出可直接复制的提示词模板。4.1 先把任务拆成流水线在一次典型的企业项目调研中完整任务链是这样的任务发起人你输入一个目标比如“评估我们是否应该引入向量数据库来改造现有的模糊搜索接口”。第一步由主持人 Agent 对任务进行拆解明确要调研哪些方向需要收集哪些类型的材料产出格式是什么时间边界是什么。第二步调研 Agent 接收拆解后的任务书开始收集资料、整理信息输出一份结构化的《初步调研报告》。这份报告要求观点要有出处、数据要有来源、覆盖正反两面、列出关键取舍。第三步反证 Agent 拿到《初步调研报告》开始“找茬”检查数据是否过时、来源是否可靠、论证是否有逻辑漏洞、有没有更优替代方案没被考虑。输出一份《反证意见书》。第四步汇总 Agent 拿齐《初步调研报告》和《反证意见书》进行最终融合输出《最终决策简报》和《风险清单》。这四步是一个最小可用的 Agent Teams 闭环。4.2 上下文交接文件是 Agent 之间的“对话记录”多 Agent 之间怎么传递信息最简单的做法是用项目目录里的文件。每个 Agent 把输出写入独立的 Markdown 或文本文件下一个 Agent 只需要读取指定文件即可。这样做的好处有三个信息有存档随时可以回看和追溯。每个 Agent 只读取自己需要的文件上下文不会乱。人工可以在文件交接处插入审查即便某一环出问题也不会污染后续流程。具体目录结构可以这样规划agent-teams-demo/ ├── tasks/ │ ├── 00-task-book.md # 主持人输出的任务书 │ ├── 01-research-report.md # 调研 Agent 的输出 │ ├── 02-challenge-notes.md # 反证 Agent 的输出 │ └── 03-final-brief.md # 汇总 Agent 的输出 └── context/ └── project-context.md # 团队共享的项目背景信息4.3 人在哪个环节介入多 Agent 不等于无人值守。相反在关键节点插入人工检查是保证质量最重要的手段。这套流水线中有三个建议的人工检查点第一个检查点在主持人拆解任务之后。检查任务书是否真的覆盖了决策所需的关键问题。如果任务书本身就是偏的后面所有 Agent 都会跟着偏。第二个检查点在反证 Agent 输出之后。反证意见书里如果出现重大质疑你不能直接跳过需要在汇总前和真实业务情况对照一下。第三个检查点在最终报告产成之后。汇总报告只是辅助决策最终拍板还是人。不要因为是 Agent 写的报告就放松审查。4.4 一次任务跑多久合适多 Agent 协作很强大但不是所有任务都值得走全套流程。我的建议是分级简单查询类任务单 Agent 直接回答中等任务调研加汇总两个角色即可只有涉及企业级决策、技术选型、成本评估等高风险任务才建议跑完整的调研、反证、汇总三阶段。毕竟每次 Agent 交接都有 token 成本和时间成本。花一块钱买瓶水的事情没必要开一场董事会。5. 多 Agent 分工提示词模板可直接复制这是本文的重头戏。下面给出四个 Agent 的角色提示词主持人、调研 Agent、反证 Agent、汇总 Agent。把每个提示词保存成单独的文件或者直接粘贴到对应的对话上下文里即可使用。5.1 主持人 Agent 提示词作用接收原始需求拆解任务书定义调研边界和验收标准。# 角色 你是企业项目调研团队的主持人。你负责把模糊的业务需求拆解成清晰、可执行的调研任务书。 # 工作目标 - 将用户输入的原始需求转化为结构化的任务书。 - 明确调研范围、关键问题、时间边界、可用资源。 - 明确最终产出格式和验收标准。 # 输出格式 请输出 Markdown 格式的任务书包含以下章节 ## 1. 调研背景 一句话说明为什么需要这次调研。 ## 2. 核心问题 用列表列出本次调研必须回答的 3 到 5 个关键问题。 ## 3. 调研范围 明确需要覆盖的方向以及明确不需要覆盖的方向。 ## 4. 目标产出 说明最终报告应包含哪些章节、表格或关键数据。 ## 5. 验收标准 列出最终报告通过验收必须满足的条件。 # 注意事项 - 如果用户给出的需求不清晰先追问一次不要强行拆解。 - 任务书保持精简控制在 500 字以内。 - 不要直接回答调研问题你的职责是拆解任务。5.2 调研 Agent 提示词作用根据任务书收集资料、整理信息输出结构化调研报告。# 角色 你是企业项目调研团队中的调研专员。你的任务是快速、全面地收集与任务书相关的信息并整理成结构化报告。 # 工作目标 - 覆盖任务书中列出的全部关键问题。 - 所有结论必须有信息源支撑禁止编造数据和事实。 - 对存在争议的信息同时列出正反两方观点。 # 输出格式 输出 Markdown 格式的《调研报告》包含以下章节 ## 1. 核心结论 用 3 到 5 条要点概括调研的最重要发现。 ## 2. 信息全景 按任务书要求分方向列出收集到的信息。 每条信息格式 - 主题 - 核心内容 - 来源 - 时效性 - 可靠度评估 ## 3. 正反观点 针对核心问题列出支持和反对两种观点的证据。 ## 4. 待确认事项 列出信息不足或无法确认的问题。 # 注意事项 - 优先使用时效性强、可靠度高的来源。 - 数据信息必须标注时间范围比如“截至2025年”之类的描述。 - 如果无法找到足够信息明确说明“信息不足”不要硬编。5.3 反证 Agent 提示词作用对调研报告进行红队式审查找漏洞、找反例、找逻辑错误。# 角色 你是企业调研团队的反证专员也被称为“红队成员”。你的职责是对调研报告提出严格质疑找出潜在风险和论证漏洞。 # 工作目标 - 逐条审查调研报告中的结论尝试找出反例或反面证据。 - 检查数据来源、时效性、完整性标注不可靠信息。 - 对每个质疑给出可操作的修正建议。 # 输出格式 输出 Markdown 格式的《反证意见书》包含以下章节 ## 1. 总体判断 用一段话评价调研报告的整体质量指出是否具备决策支撑能力。 ## 2. 关键质疑 逐条列出你对核心结论的质疑。 每条质疑格式 - 质疑对象 - 质疑理由 - 可能影响 - 修正建议 ## 3. 数据与来源审查 列出来源不可靠、数据过时或证据链不完整的信息。 ## 4. 遗漏项 列出你认为调研报告没有考虑到但可能影响决策的重要事项。 # 注意事项 - 反证不等于无理抬杠每一条质疑都必须有理由。 - 如果你认为报告整体质量合格也要明确说出来不要为了找问题而找问题。 - 格式严谨便于汇总 Agent 直接参考。5.4 汇总 Agent 提示词作用融合调研报告与反证意见书输出最终决策简报。# 角色 你是企业调研团队的汇总专家。负责把调研报告和反证意见书融合成一份高质量、可决策的最终简报。 # 工作目标 - 综合调研信息与反证意见给出明确的判断和建议。 - 对于存在争议的问题说明争议点并给出倾向性意见。 - 最终报告必须让决策者在 10 分钟内读完并做出判断。 # 输出格式 输出 Markdown 格式的《最终决策简报》包含以下章节 ## 1. 结论摘要 用 3 到 5 句话概括最终建议。 ## 2. 关键依据 列出支持最终建议的核心证据注明来源。 ## 3. 风险与缓解措施 列出主要风险以及应对措施。 ## 4. 行动建议 给出具体的下一步行动项标注负责人建议和优先级。 ## 5. 遗留问题 列出本次调研未能解决、需要后续跟进的问题。 # 注意事项 - 不要简单复制调研报告原文要进行重新组织和提炼。 - 对不确定性用“置信度高 / 中 / 低”做标注。 - 如果反证意见推翻了调研结论要以反证意见为主并说明理由。提示词如何使用最简单的方式把主持人提示词粘贴给 Claude Code把你真实的业务需求作为问题追加在后面得到任务书后再把调研 Agent 提示词和任务书一起发给新的会话。这里可以直接用命令行参数指定上下文claude -p 请阅读 tasks/00-task-book.md然后按照调研 Agent 的角色要求完成调研工作在实际企业项目中还可以把每个人的提示词保存到项目里的prompts/目录方便版本管理和复用。6. 验收清单多 Agent 产出是否合格提示词只能保证 Agent 有方向不能保证结果一定正确。所以一份明确的验收清单比提示词更重要。下面这套验收清单可以直接打印出来每次跑完多 Agent 流水线都过一遍。6.1 任务书验收检查项验收标准是否通过核心问题明确每个关键问题都是单一、可回答的不包含歧义调研范围清晰明确写了覆盖和不覆盖的方向产出格式具体规定了报告章节结构验收标准可衡量可以据此判断最终报告是否合格6.2 调研报告验收检查项验收标准是否通过覆盖完整性任务书中所有关键问题都有对应答案或“信息不足”说明信息可追溯每个核心结论都有来源标记正反兼顾对争议问题同时呈现了支持和反对的证据时效性数据和分析基于特定时间范围没有明显过时无编造未出现无法核实却写成既定事实的内容6.3 反证意见书验收检查项验收标准是否通过质疑有依据每条质疑都说明了理由不是无脑抬杠覆盖核心结论调研报告的主要结论均经过质疑给出修正建议每条质疑都附带可执行的修正思路明确整体评价明确说明调研报告能否支撑决策6.4 最终决策简报验收检查项验收标准是否通过结论清晰读者可以在短时间内理解建议内容证据与结论对应结论有依据支撑不是“我觉得”风险充分披露主要风险都有提及并有应对建议不确定度标注对于把握不那么高的判断有明确说明行动项可执行建议明确、有优先排序而不是空话建议把验收结果直接写在汇总报告末尾。这样可以保留完整的决策痕迹方便日后复盘。7. 常见问题与排查方法这里汇总了几个新手最容易遇到的坑。多数问题与 Claude Code 本身有关也有一些是多 Agent 协作流程特有的。问题现象可能原因排查方式解决方案输入 claude 提示 command not foundnpm 全局目录不在 PATH 中执行npm bin -g查看路径把该路径加入 PATH 环境变量Windows 下安装后无法运行PowerShell 执行策略限制或 PATH 未刷新用管理员 PowerShell 检查执行策略重开终端调整执行策略或手动添加 PATH重开终端提示could not locate the claude cli on pathClaude Code CLI 未正确安装或 IDE 找不到命令在终端直接运行claude --version确认全局安装成功重启 IDE 后再试登录时提示组织禁用订阅访问企业策略限制了 Claude Code 使用联系管理员确认开通方式按企业标准流程开通或使用 API 访问对话输出乱码终端编码与工具字符集不匹配检查终端编码设置Windows 下执行chcp 65001切换 UTF-8使用 ollama 本地模型后回答质量明显下降小模型推理能力不足以支撑复杂任务对比高级模型和本地模型输出重要任务用高级模型本地模型仅处理简单任务Agent 之间上下文对不上没有用文件交接直接把上一个 Agent 的对话粘贴给下一个检查交接文件的完整性统一使用文件交接各自维护独立目录反证 Agent 变成无脑抬杠提示词缺少“每一条质疑必须有理由”的约束检查反证提示词是否完整补充反证 Agent 提示词中的约束条款token 消耗过高每个 Agent 都重复读取大量上下文检查每次交接时读取的文件大小精简任务书和交接内容只传递关键信息调研报告中出现无法追溯的结论提示词中缺少来源标注要求抽查核心结论是否有来源标记在调研 Agent 提示词中强制执行来源标注这里特别想强调一下 token 成本控制。多 Agent 协作每增加一个角色token 消耗就多一轮。最直接的控制方式是限制每个 Agent 的输入长度不要让 Agent 每次都读取整个项目目录只给它们必要的任务书和上下文文件。合适的流程设计往往比模型本身更省 token。Claude Code 也支持对话历史的保存与恢复你可以用会话恢复功能把同一条流水线的多次操作串起来避免上下文重新建立带来的额外消耗。8. 企业落地多 Agent 的最佳实践与安全建议当前面的流程跑通之后你可能会想把它推广到团队甚至整个部门。这里给几条企业级落地的建议每一条都踩过不少坑。8.1 敏感信息与权限边界企业项目一定会涉及代码、数据库、内部文档等敏感信息。使用 Claude Code 和 Agent Teams 时必须遵守最小权限原则。具体来说不要把生产环境的密钥直接放在项目文件里不要让 Agent 读取它完成任务并不需要的敏感目录如果需要在生产环境执行变更务必先在测试环境验证保留回滚方案。Claude Code 在读取和修改文件时有操作确认机制不要为了省事全部跳过。8.2 任务分派与精力管控多 Agent 不是越多越好。2 到 3 个角色通常足以完成大部分任务。Agent 越多上下文交接越乱排查问题越困难。建议先从三个角色起步调研、反证、汇总。跑通后再根据实际需要增加角色比如增加一个“成本核算 Agent”或者“竞品对比 Agent”。每次新增角色都要回答一个问题这个角色真的承担了不可合并的职责吗8.3 提示词版本管理提示词是会迭代的。把角色提示词当成代码来管放进 Git 仓库每次修改记录变更原因重要节点打 tag。很多团队最后发现多 Agent 项目最值钱的资产不是模型而是那套经过多轮迭代的提示词和验收清单。8.4 用 CLAUDE.md 管理项目记忆Claude Code 支持 CLAUDE.md 文件作为项目级记忆。可以在项目根目录维护一个 CLAUDE.md把团队背景、技术栈、常见约定写进去。这样每个 Agent 在启动时都能自动读取项目上下文不需要在每条提示词里重复描述项目背景。8.5 保留人工审批关键节点自动化的度要把握好。调研、反证这类低风险操作可以完全自动化但涉及预算承诺、生产变更、对外发布的产出必须加入人工审批。吃透一个原则Agent 负责准备弹药人负责扣动扳机。这个原则在可预见的未来都不会过时。8.6 记录全过程方便复盘建议为每次多 Agent 任务保留完整的任务书、调研报告、反证意见和最终简报。这不仅是为了追溯更是为了后续复盘 Agent 的产出质量。时间久了你就能形成一份“什么样的任务适合多 Agent、什么样的任务单 Agent 就能解决”的判断力。9. 总结与下一步实践建议这篇文章从企业项目调研的真实痛点出发讲了多 Agent 协作解决什么问题然后完整跑通了“主持人拆任务 → 调研 Agent 收集信息 → 反证 Agent 挑毛病 → 汇总 Agent 出结论”的流水线。核心收获可以概括成三句话第一多 Agent 的价值不在于“人多”而在于角色之间的互相制衡。反证环节是整套流程的灵魂没有反证的多 Agent 只是多了几个写作助手。第二文件是最可靠的 Agent 交接方式。不要试图用对话上下文串联 Agent会有太多隐性问题。第三验收清单比提示词更重要。提示词定义“怎么做”验收清单定义“什么算做好”。两者缺一不可。如果你正准备尝试建议找一个真实但低风险的任务比如让你所在团队做一个新工具的调研和选型用这篇文章里的提示词模板先完整跑一遍。跑完之后先不急着优化提示词而是先对照验收清单看看哪一环节产出最薄弱再针对性修改对应角色的提示词。进一步的深入学习方向有三个一是 Claude Code 的 Skill 机制学会把自己的工作流封装成可复用技能二是 MCP 多智能体让 Agent 可以调用更多外部工具和数据源三是关注多智能体系统核心架构与运行原理从原理层面理解上下文窗口、记忆管理、任务规划这些底层问题。走完这几步你对 Agent 的认知会和现在完全不同。把这套流程和验收清单收藏起来下次遇到团队里的复杂调研任务直接按这个套路拆你会回来感谢反证 Agent 的。