想象一家只在夜晚排练的即兴话剧社。导演不会给每位演员逐句台词，只发三样东西：一张角色卡、一句演出目标、一段人物小传。角色卡写着“你是管家”，目标写着“今晚要让观众为这场推理戏鼓掌”，小传写着“你服侍过三代主人，最恨别人动你的银器”。有了这三样，演员就能临场发挥，但始终不跑偏。 CrewAI 里的每个 Agent（智能体）也是这样一位演员。Role 就是它的角色卡，Goal 是导演给的演出目标，Backstory 是它的人物小传。多智能体协作之所以看起来“有组织”，不是因为每个模型更聪明，而是因为这“三件套”在演出前就把人设定好了。这篇文章会用一场话剧的排练到公演，把 CrewAI 的 Role/Goal/Backstory 角色定义讲透，再从配置技巧讲到实战案例。

岗位关联

对 AI 从业者而言，理解 Role/Goal/Backstory 是驾驭 CrewAI、AutoGen 等高级多智能体框架的基本功。它直接决定 Agent 是否稳定、协作是否顺畅，也是从“能跑通 Demo”走向“能交付工程”的关键一步。

目录
  1. 可视化演示
  2. 角色定义
  3. 目标设定
  4. 背景故事
  5. 协同机制
  6. 配置策略
  7. 实战案例
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Role/Goal/Backstory三要素结构、四类Agent分类及多Agent协作流程，切换模式理解CrewAI角色定义核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.struct+'

角色定义

话剧排练开始前，导演在布告栏上贴出一张角色卡：扮演者是谁、角色叫什么、在剧里负责什么。演员看到“管家”两个字，声音会压低，动作会收敛；看到“侦探”两个字，就会下意识去寻找线索。这就是角色定义的力量。

在 CrewAI 中，Role 是每个 Agent 的身份标签。它不只是一句自我介绍，而是模型在执行任务时的“人设锚点”。比如一个 Agent 的 role 是“资深数据工程师”，那么大模型在生成内容时，会自动采用工程师的术语体系，主动考虑数据质量、管道稳定性和工程可行性。相反，如果 role 只写“助手”，输出就会变得平庸而含混。

在实际配置中，角色命名要短而可辨识，职责边界要清晰。一个 Agent 不要同时扮演“产品经理、运营、客服”三个角色，否则大模型会在多个身份之间摇摆。好的 role 通常是一个名词短语，例如“前端代码审查员”，而不是“我们希望他能帮助我们检查代码并给出建议的程序员”。太多修饰只会稀释重点。

回到话剧社：角色卡越明确，演员越知道自己该站在舞台的哪个位置。Role 不是装饰，而是让每一个 Agent 在 CrewAI 的舞台上“入戏”的第一步。

Match(ai,tj)=∣Ri∩Tj∣∣Tj∣\displaystyle \text{Match}(a_i, t_j) = \frac{|R_i \cap T_j|}{|T_j|}
这个公式把“谁最适合这个任务”变成了集合匹配问题：Agent 的角色描述和任务需求重合度越高，越应该由它接单。
  1. 候选演员与任务这里把每个 Agent 当作候选演员 \(a_i\)，把待办任务当作剧本片段 \(t_j\)。
    Match(ai,tj)\text{Match}(a_i, t_j)
  2. 角色关键词集合\(R_i\) 是从 Role 描述中拆出的关键词集合，例如“数据分析”“报告”；\(T_j\) 是任务需求中的关键词集合。
    Ri∩TjR_i \cap T_j
  3. 匹配度计算分子表示角色与任务重合的关键词数量，分母表示任务关键词总数，结果越接近 1，说明这个角色越适合承接该任务。
    ∣Ri∩Tj∣∣Tj∣\frac{|R_i \cap T_j|}{|T_j|}

目标设定

演员有了角色卡，还需要导演一句清晰的指令：“今晚你的任务，是让观众在第二幕结束后猜出凶手。”这句指令不是情绪，而是可执行的目标。CrewAI 中的 Goal 正是扮演这个角色。

Goal 是 Agent 要完成的自然语言目标。它决定了模型如何分配注意力。目标写得越具体，模型越容易拆解步骤；目标写得越抽象，模型越容易“即兴发挥”到无关方向。比如“推进项目”会让 Agent 无从下手，而“产出项目周报并标注三个风险”就能立刻触发结构化的回答。

目标还需要与整个 Crew 的任务对齐。每个 Agent 的目标不是独立宣言，而是整场演出的一部分。如果一个 Agent 的目标是“收集所有资料”，另一个 Agent 的目标是“只保留三个重点”，两者就会互相拖累。目标颗粒度要合适：太小会让 Agent 频繁等待上级指令，太大又会让它越过职责边界，抢了其他角色的戏。

导演在排练时不会喊“大家好好演”，而是喊“第三幕结束前把道具放到指定位置”。Goal 就是这句具体的指令，它让演员知道什么叫“演完了”。

GoalQuality=NdoneNtotal\displaystyle \text{GoalQuality} = \frac{N_{\text{done}}}{N_{\text{total}}}
衡量一个 Goal 是否有效，最简单的方式就是看它能否被验收：设定目标总数中，有多少个目标项真正完成了。
  1. 目标总数\(N_{\text{total}}\) 表示这个 Agent 在一个任务周期内要达成的目标项总数，比如“收集数据、清洗数据、输出图表”三项。
    NtotalN_{\text{total}}
  2. 完成目标数\(N_{\text{done}}\) 是通过验收标准检查后，真正完成的目标项数量。
    NdoneN_{\text{done}}
  3. 目标质量两者相除得到一个 0 到 1 的比值，用来判断当前 Goal 的指令是否足够清晰，能否被稳定执行。
    NdoneNtotal\frac{N_{\text{done}}}{N_{\text{total}}}

背景故事

演员拿到角色卡后，导演还会给他一页纸的人物小传：“你曾服侍三代主人，最恨别人动你的银器。”这段背景看似无用，但会让演员在临场反应时保持人设。CrewAI 的 Backstory 就是这页小传。

Backstory 给 Agent 提供额外的上下文，让它在没有明确指示时仍能做出符合人设的判断。例如，一个“资深安全工程师”的 Agent，如果 Backstory 写着“你经历过多次数据泄露应急响应”，那么在回答时就会更自然地优先考虑风险边界；如果 Backstory 空白，它可能只会泛泛而谈。

但人物小传不是越长越好。Backstory 占用上下文窗口，信息过密会稀释模型对当前任务的注意力。好的 Backstory 应该包含性格、语气、相关经验和隐性约束，而不是把百科全书写进去。一个常见做法是控制在三到五句话，只保留能影响判断的信息。

话剧社里，好的小传让演员在意外发生时也不会“出戏”。Backstory 的价值不是信息量，而是关键时刻的一句“我是谁”。

Budgetbackstory=Budgettotal−Budgetrole−Budgetgoal\displaystyle \text{Budget}_{\mathrm{backstory}} = \text{Budget}_{\mathrm{total}} - \text{Budget}_{\mathrm{role}} - \text{Budget}_{\mathrm{goal}}
这段话的意思是：给 Backstory 的预算，等于总上下文预算减去 Role 和 Goal 占用的部分。主角不能把舞台全部占满。
  1. 总预算\(\text{Budget}_{\mathrm{total}}\) 代表 Agent 可用的全部提示词上下文空间，受模型窗口限制。
    Budgettotal\text{Budget}_{\mathrm{total}}
  2. 角色与目标预算\(\text{Budget}_{\mathrm{role}}\) 和 \(\text{Budget}_{\mathrm{goal}}\) 分别是 Role 描述和 Goal 描述占用的大小。
    Budgetrole+Budgetgoal\text{Budget}_{\mathrm{role}} + \text{Budget}_{\mathrm{goal}}
  3. 剩余给小传总预算减去前两者，剩下的空间才是 Backstory 的合理容量。
    Budgettotal−Budgetrole−Budgetgoal\text{Budget}_{\mathrm{total}} - \text{Budget}_{\mathrm{role}} - \text{Budget}_{\mathrm{goal}}

协同机制

独幕剧只需要一个好演员，而 CrewAI 的精彩之处在于多人同台。当多个 Agent 组成一个 Crew 时，Role、Goal、Backstory 就变成了舞台调度图：谁先上场、谁接谁的戏、谁负责谢幕。

在多智能体协作中，任务分发不是随机的。CrewAI 可以根据角色定义和任务内容，决定让哪个 Agent 处理哪一步。上游 Agent 的输出会成为下游 Agent 的输入，这种上下文传递很像话剧里的“台词接龙”：管家说完线索，侦探才能继续推理。如果管家的角色卡和侦探的目标不一致，台词就会断档。

角色互动也需要三要素来润滑。下游 Agent 读到上游产生的文本时，它需要知道这个文本是谁写的、为什么写、语气是否可靠。Role 提供了身份信息，Goal 说明了动机，Backstory 则补充了潜在偏见。没有这三者，Agent 之间的协作就成了“互发不知所云的便条”。

演员之间不需要重新认识彼此，因为角色卡已经写清了关系。CrewAI 的协作不是靠运气，而是靠提前写好的“人物关系表”。

Score(ai,tj)=λRSim(Rolei,tj)+λGSim(Goali,tj)+λBSim(Backstoryi,tj)\displaystyle \text{Score}(a_i, t_j) = \lambda_R \text{Sim}(\text{Role}_i, t_j) + \lambda_G \text{Sim}(\text{Goal}_i, t_j) + \lambda_B \text{Sim}(\text{Backstory}_i, t_j)
这个综合得分把身份、目标和背景都纳入任务分配，三个维度各有权重，最终决定 Agent \(a_i\) 是否适合任务 \(t_j\)。
  1. 三个相似度\(\text{Sim}(\text{Role}_i, t_j)\) 表示角色与任务的相似度，同理还有目标相似度和背景相似度。
    Sim(Rolei,tj)\text{Sim}(\text{Role}_i, t_j)
  2. 权重系数\(\lambda_R\)、\(\lambda_G\)、\(\lambda_B\) 分别控制身份、目标、背景在决策中的重要性，三者通常为正数。
    λR+λG+λB=1\lambda_R + \lambda_G + \lambda_B = 1
  3. 加权求和把三个方向的匹配度按权重相加，得到最终分数，用于给 Agent 排序或选择下一步执行者。
    λRSim(Rolei,tj)+λGSim(Goali,tj)+λBSim(Backstoryi,tj)\lambda_R \text{Sim}(\text{Role}_i, t_j) + \lambda_G \text{Sim}(\text{Goal}_i, t_j) + \lambda_B \text{Sim}(\text{Backstory}_i, t_j)

配置策略

话剧社每一次公演前都要彩排，角色卡也不是一次定稿的。配置 Role/Goal/Backstory，同样需要策略。最小角色配置是第一步：先让一个 Agent 跑通，再逐步增加角色，而不是一开始就拉一整个剧团上台。

所谓最小角色配置，就是先定义“这个任务非有不可的角色”。如果你的任务只是“总结一篇新闻”，一个“资深新闻编辑”就足够了，不需要再配“市场分析师”和“舆情观察员”。角色越多，协作成本越高，上下文越长，出错的概率也越大。

提示词模板是复用三要素的关键。你可以把 Role、Goal、Backstory 写成带变量的模板，例如在模板中把 {topic} 替换成不同主题。这样同一个“研究助理”角色，既能在“AI 行业调研”中使用，也能在“新能源调研”中使用。模板还可以纳入版本管理，用 Git 记录每一次提示词变更。很多团队只对代码做版本管理，却忘了提示词也需要，这是后期排查效果波动的重要依据。

导演不会让所有演员同时站上舞台抢戏。好的配置策略是克制的：只安排必要的角色，把每个角色的戏份写到最精准。

Qualitycrew=1n∑i=1nAligni\displaystyle \text{Quality}_{\text{crew}} = \frac{1}{n} \sum_{i=1}^{n} \text{Align}_i
团队整体质量等于每个 Agent 与自身任务对齐程度的平均值。配置角色时，真正的目标不是角色多，而是每个角色都贴对位置。
  1. 单个角色对齐度\(\text{Align}_i\) 表示第 \(i\) 个 Agent 的角色定义与其承担任务的匹配程度。
    Aligni\text{Align}_i
  2. 角色总数\(n\) 表示 Crew 中 Agent 的数量，数量越少，越容易逐一检查对齐度。
    nn
  3. 求平均将所有角色的对齐度相加后除以 \(n\)，得到整个 Crew 的配置质量。
    1n∑i=1nAligni\frac{1}{n} \sum_{i=1}^{n} \text{Align}_i

实战案例

当这些配置策略被搬上真实舞台，效果会非常明显。第一个案例是内容生成。一个由“调研员”和“资深编辑”组成的 Crew，调研员的角色是“搜集并整理信息”，目标是“输出带出处的材料清单”；编辑的角色是“润色并校验事实”，目标是“把材料改写成可发布的文章”。三要素分开后，内容生产的稳定性和交付速度都会显著提升。

第二个案例是客服质检。传统质检依赖人工抽听录音，成本高且标准不一致。使用 CrewAI 后，可以让一个“质检专员”Agent 专门检查客服话术是否包含情绪安抚、解决方案和结束确认。它的 Backstory 可以写成“你熟悉银行客服合规要求”，这样模型就会自动用合规视角判断问题。

第三个案例是代码审查。一个“后端架构师”Agent 负责检查并发安全，一个“安全工程师”Agent 负责检查注入风险。两者 Role 明确，Goal 独立，Backstory 各有所长。它们轮流处理同一段代码，比单个 Agent 泛泛审查更专业，也更接近真实团队的分工方式。效果评估时，可以用抽取样本的方式计算问题发现率，定期调优三要素。

一场成功的公演，离不开反复彩排和复盘。AI 工程也一样：Role/Goal/Backstory 是每次演出前都可以修改的剧本，而不是一成不变的代码。

SuccessRate=PassedTotal\displaystyle \text{SuccessRate} = \frac{\text{Passed}}{\text{Total}}
实战中评估角色配置是否有效，最终要看“通过验收的任务数”占总任务数的比例。这个比例低，往往不是模型不行，而是角色人设没立住。
  1. 通过验收任务数\(\text{Passed}\) 表示在效果评估中，输出结果符合验收标准的任务数量。
    Passed\text{Passed}
  2. 总任务数\(\text{Total}\) 表示参与评估的样本任务总数。
    Total\text{Total}
  3. 成功率两者相除得到成功率，用来验证 Role/Goal/Backstory 配置是否值得沿用。
    PassedTotal\frac{\text{Passed}}{\text{Total}}

AI 应用场景

智能内容生产线

阶段：多智能体分工与任务分发

解决的问题：过去写一份行业报告需要人工搜集资料、整理提纲、撰写正文、校对事实，流程长且质量不稳定。AI 方法通过为每个 Agent 定义独立角色，把流水线拆成多个可复用节点。

具体案例：一个内容团队配置“调研员”Agent 负责收集资料，“数据分析师”Agent 负责提取图表，“主编”Agent 负责终审。每个 Agent 的 Goal 都精确到“输出什么格式、包含哪些部分”，Backstory 则补充行业经验。最终一份报告从三天缩短到三小时。

客服质检自动化

阶段：人设约束与一致性控制

解决的问题：传统质检依赖人工抽检，覆盖率低，评价标准因人而异。AI 质检 Agent 可以用明确 Role 锁定“质检专员”身份，用 Goal 定义“检查情绪安抚”等指标。

具体案例：某金融公司用 CrewAI 构建质检系统，质检 Agent 的 Backstory 写入“你熟悉消费者权益保护法”。每通客服录音被转写后，质检 Agent 输出合规与风险标签，异常样本自动进入人工复核队列。

代码审查助手

阶段：多角色协同与上下文传递

解决的问题：通用代码审查工具只能查静态问题，难以理解业务意图。AI 可以通过不同角色 Agent 对同一段代码做多视角检查。

具体案例：一个研发团队让“并发专家”Agent 先检查线程安全，再让“安全工程师”Agent 检查输入校验。两个 Agent 的 Role 不同、Goal 互补，后一个 Agent 可以直接读取前一个 Agent 的输出，形成接力式审查。

Python 演示

python41 行
import re class CrewMember:    def __init__(self, role, goal, backstory):        self.role = role        self.goal = goal        self.backstory = backstory     def can_handle(self, task):        keywords = re.findall(r'[\w]+', self.goal)        return any(k in task for k in keywords)     def act(self, task):        return "[" + self.role + "] " + self.backstory + " 我开始处理: " + task class MiniCrew:    def __init__(self, members):        self.members = members     def run(self, task):        assigned = [m for m in self.members if m.can_handle(task)]        if not assigned:            assigned = [self.members[0]]        outputs = []        for member in assigned:            outputs.append(member.act(task))        return "\n".join(outputs) if __name__ == "__main__":    editor = CrewMember(        role="资深编辑",        goal="审校文章中的逻辑与错别字",        backstory="你做了十年图书编辑，对措辞极其敏感。"    )    researcher = CrewMember(        role="调研员",        goal="搜集并整理最新AI论文信息",        backstory="你在大学图书馆工作，擅长从海量资料中找答案。"    )    crew = MiniCrew([editor, researcher])    print(crew.run("请调研并整理CrewAI中Role的用法"))
目的：用最简 Python 模拟 CrewAI 的三要素配置与任务分发，帮助理解 Role/Goal/Backstory 如何决定谁会接手任务。
  1. class CrewMember:定义一个“演员”对象，对应 CrewAI 中的 Agent。
  2. self.role = role保存角色卡，决定 Agent 的身份。
  3. def can_handle(self, task):根据 Goal 拆出的关键词判断是否适合当前任务。
  4. return any(k in task for k in keywords)只要目标关键词在任务中出现，就认为该 Agent 可以接单。
  5. assigned = [m for m in self.members if m.can_handle(task)]让所有 Agent 试镜，符合条件者进入演出名单。
  6. if not assigned:如果无人匹配，就默认交给第一个 Agent，避免流程中断。
  7. print(crew.run("请调研并整理CrewAI中Role的用法"))触发整场“排练”，输出被选中 Agent 的处理结果。

常见误区

误区只要把 Role 写成“宇宙第一超级人工智能架构师”，模型就会更努力，输出质量也会更高。

正解Role 的价值是清晰，而不是夸张。大模型不会因为头衔更响亮就发挥超常，反而会被冗余形容词干扰，导致回答风格飘忽。CrewAI 的任务分发更看重角色与需求的匹配度。一个“Python后端工程师”比“最伟大的全栈架构师”更容易被模型稳定执行。

为何常见：人们习惯用“职位越高越厉害”的职场直觉去设计提示词，但大模型没有职称晋升机制，只有上下文指令。

误区目标写得太具体会限制模型，所以应该写“帮助用户解决问题”这种万能目标。

正解抽象目标等于没有目标。模型只能顺着“帮助用户”猜一个方向，无法判断何时算完成。好的 Goal 应该让另一个工程师看到后也知道怎么验收，例如“整理用户反馈并按问题类型生成三张统计表”。

为何常见：很多人担心约束太多会让模型“不敢发挥”，其实 CrewAI 中发挥空间应该由 Backstory 和工具调用去实现，而不是由模糊目标来制造自由。

误区既然 Backstory 能提供背景信息，那就把所有行业知识、公司历史、个人经历全部写进去，模型一定会更懂业务。

正解Backstory 越长，上下文窗口被占用越多，模型反而容易忽略真正重要的指令。信息密度比信息量更重要。三到五句与当前任务相关的小传，往往胜过一大段无关背景。

为何常见：人的直觉是“背景越完整，理解越准确”，但大模型的注意力资源是有限的，冗余信息会稀释关键线索。

误区每个新 Crew 都要重新设计 Role、Goal、Backstory，不能复用，否则效果不好。

正解三要素可以做成模板和配置项。同一个“调研员”角色，只需要替换主题变量，就能用于不同行业。合理复用不仅能节省提示词设计时间，还能通过版本管理持续优化。

为何常见：提示词工程早期阶段，大家习惯为每个任务手工写提示词，忽略了软件工程中的复用思想。

误区Role/Goal/Backstory 只是让 Agent 说话更像某个职业，对实际任务协作没什么影响。

正解三要素会影响工具选择、任务分发、上下文传递和最终输出结构。在多智能体协作中，如果 Role 不清晰，上游 Agent 不知道该产出什么，下游 Agent 也不知道该接收什么，整个流程会断链。

为何常见：从单个聊天模型迁移到多智能体框架时，人们容易把提示词理解为“语气”，而忽略它在系统调度中的作用。

面试题

Q1. 在 CrewAI 中，Role 的主要作用是什么？

单选题 · easy

  • A.定义Agent在团队中的身份与职责← 正确答案
  • B.决定Agent选择哪个底层大模型
  • C.规定Agent必须输出的JSON字段
  • D.控制Agent的上下文窗口长度

答案：A。Role 是 Agent 的身份标签，用来定义它在团队中的身份和职责。它不会直接决定底层模型、输出格式或上下文长度。就像话剧中的角色卡，它决定演员“演谁”，而不是“用哪支话筒”。

Q2. 下面哪个 Goal 写法更适合放入 CrewAI 的 Agent 配置？

单选题 · easy

  • A.输出一份CrewAI入门教程← 正确答案
  • B.尽最大努力改进项目质量
  • C.发现并记录代码中的隐患
  • D.为公司创造更多商业价值

答案：A。目标要具体、可验收。A 明确给出了交付物类型和主题；B 和 D 太抽象，无法判断完成标准；C 虽较具体，但没有说明输出形式，B、C、D 都不如 A 清晰。

Q3. 编写 Backstory 时，最重要的原则是？

单选题 · mid

  • A.信息密度适中且服务当前任务← 正确答案
  • B.把所有知识都塞进一段话
  • C.让背景越离奇越能激发效果
  • D.只写角色姓名和年龄就好

答案：A。Backstory 像人物小传，目的是给模型提供与任务相关的性格和背景约束。信息过多会稀释注意力，完全没有则失去约束作用。A 准确描述了“既不过量又有用”的原则。

Q4. 下列哪些字段属于 CrewAI 角色定义的三要素？

多选题 · easy

  • A.Role← 正确答案
  • B.Goal← 正确答案
  • C.Backstory← 正确答案
  • D.Temperature

答案：ABC。CrewAI 的角色定义核心是 Role、Goal、Backstory 三个字段。Temperature 是模型随机性参数，不属于角色人设字段。

Q5. 合理配置 Role/Goal/Backstory 能带来哪些好处？

多选题 · mid

  • A.让模型输出更稳定← 正确答案
  • B.提高任务交接效率← 正确答案
  • C.绕过底层模型限制
  • D.使角色行为更一致← 正确答案

答案：ABD。三要素通过人设约束让模型输出更稳定、行为更一致；在多智能体协作中也能让下游 Agent 更好理解上游产出，从而提高交接效率。但它无法绕过模型本身的技术限制，C 错误。

Q6. 在多智能体协作中，Role/Goal/Backstory 主要帮助 CrewAI 解决什么问题？

单选题 · mid

  • A.决定哪名Agent先接单← 正确答案
  • B.决定使用哪个API密钥
  • C.决定输出文件的格式
  • D.决定模型部署的位置

答案：A。三要素为任务分发提供判断依据，CrewAI 可以根据角色与任务的匹配度决定哪个 Agent 先处理任务。API 密钥、文件格式和部署位置属于工程配置，不是这三要素的核心职责。

Q7. 已知 Agent 的 role 是“资深数据分析师”，goal 是“从销售表提炼趋势”，backstory 是“熟悉零售业务”。哪个任务最适合它？

单选题 · hard

  • A.撰写一首现代诗
  • B.分析季度销售下滑原因← 正确答案
  • C.设计公司新品牌Logo
  • D.将合同翻译成英文

答案：B。角色、目标和背景都指向零售数据分析，因此“分析季度销售下滑原因”最匹配。写诗、设计 Logo、翻译合同都需要完全不同的角色配置。

Q8. 为什么 Backstory 过长不一定更好？

单选题 · hard

  • A.会占用上下文并稀释关键线索← 正确答案
  • B.模型会直接忽略所有背景信息
  • C.模型不擅长理解超过百字的文案
  • D.Backstory 需要像简历一样越长越好

答案：A。过长的小传会占用有限上下文，也会让模型难以分辨哪些信息与当前任务有关。模型能理解长文本，但注意力会被无关内容分散。D 的观点正好与正确做法相反。

Q9. 想在多个 Crew 中复用 Role/Goal/Backstory 配置，正确的做法是？

多选题 · hard

  • A.将三要素抽取成模板再注入← 正确答案
  • B.每次替换新的模型供应商
  • C.用Git管理提示词版本← 正确答案
  • D.删除Goal只保留Role

答案：AC。模板化和版本管理是软件工程思路在提示词上的应用。模板可以替换变量，Git 可以追踪变更。更换模型供应商与复用配置无关，删除 Goal 会破坏角色定义完整性。

Q10. 关于 CrewAI 多智能体协作中的上下文传递，下列说法正确的是？

多选题 · hard

  • A.上游输出会成为下游Agent输入← 正确答案
  • B.下游Agent不会接触上游输出
  • C.清晰角色能帮助下游理解上游产出← 正确答案
  • D.上下文内容始终不被裁剪

答案：AC。多智能体协作的核心是接力，上游结果通常会传给下游；清晰的 Role 和 Goal 能让下游知道这份产出来自谁、为什么这样写，从而更好地继续处理。上下文受模型窗口限制，不一定完整保留，D 错误。