1. 项目概述：这不是一个“框架教程”，而是一份源码级实战手记

CrewAI 这个词最近在技术圈里出现的频率，已经快赶上“大模型”本身了。但翻遍中文社区，你看到的大多是“三步搭建智能体团队”“5分钟跑通demo”的速成指南——它们像一份精美的菜单，告诉你这道菜叫什么、有什么营养，却从不告诉你厨师怎么磨刀、火候怎么控、酱料怎么调。而我手头这份《CrewAI（源码笔记）》，就是我在连续三周、每天平均拆解6小时源码后，用铅笔在A4纸上画满批注、在终端里反复打断点、在Git历史里逐行比对出来的“后厨实录”。它不教你怎么调用Crew()，而是带你站在crewai/crew.py第217行那个self._execute_tasks()方法前，看清整个任务调度引擎的齿轮如何咬合；它不罗列Agent类的参数列表，而是解释为什么llm字段被设计为可选、而tools字段却强制要求是List[BaseTool]——这个设计背后，藏着对异步工具调用失败重试机制的底层约束。如果你正卡在“为什么我的Agent总在第三轮对话就丢失上下文”，或者困惑于“Task的context参数到底该传一个Task对象还是它的输出字符串”，又或者想搞清楚SequentialProcess和HierarchicalProcess在事件循环层面究竟差了哪几行代码，那这份笔记不是参考，就是你此刻最需要的手术刀。它面向两类人：一类是已经用过CrewAI、能跑通流程但想真正掌控它的人；另一类是正在评估是否将CrewAI引入生产环境、需要穿透API表层看透稳定性与扩展边界的架构师。它不承诺“零基础入门”，但保证每一个结论都有源码行号为证，每一处判断都来自真实调试现场。

2. 源码整体架构与核心设计思想拆解

2.1 为什么不是“另一个LangChain封装”？——CrewAI的三层抽象本质

很多初学者会下意识把CrewAI归类为LangChain的上层封装，这种理解在功能层面没错，但在架构哲学上存在根本性偏差。LangChain的核心是链式数据流（Chain），它把LLM调用、提示工程、输出解析串成一条单向管道；而CrewAI的核心是角色化协作网络（Crew），它把多个具备不同知识边界、工具权限和决策逻辑的智能体，组织成一个能自主协商、动态分派、交叉验证的微型社会。这个差异直接决定了源码的组织方式：LangChain的源码树是纵向深挖的（chains/→llms/→prompts/），而CrewAI的源码树是横向铺开的（agents/、tasks/、processes/、crews/），每个目录都代表一种社会角色或协作规则。

我第一次打开crewai/目录时，最先注意到的不是crew.py，而是__init__.py里那句被反复import的from crewai.crew import Crew。这看似平常，实则暴露了整个项目的入口设计哲学：一切以Crew为原点。Agent不是独立存在的个体，而是被Crew实例化并注入上下文的“雇员”；Task不是孤立的任务卡片，而是由Crew根据Process策略动态生成的“工单”；就连Process本身，也不是一个静态枚举，而是一个可被Crew在运行时切换的“管理模式”。这种设计让CrewAI天然规避了LangChain中常见的“链断裂”问题——当某个环节出错，LangChain往往需要手动捕获异常并跳转到备用链，而CrewAI的Crew会在_execute_tasks()内部启动一个统一的错误传播与降级机制，比如自动将失败的Task标记为FAILED，并触发预设的fallback_agent进行兜底处理。这个机制的代码藏在crewai/crew.py的_handle_task_result()方法里，它不像表面看起来那样只是个状态更新函数，而是一个微缩版的“异常熔断器”。

2.2 四大核心模块的职责边界与耦合关系

CrewAI的源码结构清晰地划分为四个支柱模块，但它们之间的依赖并非简单的A→B→C线性关系，而是一种带约束的网状耦合。我用一张表格梳理了它们在v0.28.8版本中的实际交互逻辑：

这里有个极易被忽略的关键点：crews/模块并不直接实现具体的Process逻辑，而是通过self.process属性持有对processes/中某个类的引用。这意味着，如果你想自定义一个“基于优先级队列的任务分发器”，你不需要修改Crew类，只需继承BaseProcess，重写_run_next_task()方法，然后在创建Crew时传入process=MyPriorityProcess()即可。这种设计让CrewAI的扩展性远超表面所见——它不是让你在Crew的缝隙里塞代码，而是为你预留了整条“协作协议栈”的替换接口。我在测试一个金融风控场景时，就基于此开发了一个RiskAwareProcess，它会在每次分发任务前，先调用一个轻量级风险评分模型，对Task的description做语义分析，若检测到“转账”“大额”“实时”等关键词组合，则自动提升该任务的执行优先级并启用更严格的工具调用白名单。这个过程没有动一行Crew源码，却彻底改变了整个团队的响应逻辑。

2.3 “智能体即服务”（AaaS）的底层实现原理

CrewAI常被称作“AI员工框架”，这个比喻非常精准，因为它在源码层面确实模拟了真实企业中员工的三大特征：身份标识、能力契约、协作契约。Agent类的role、goal、backstory字段，构成了它的“员工档案”；tools列表和llm配置，定义了它的“岗位说明书”（能做什么、用什么工具、向谁汇报）；而Crew对它的调用方式，则体现了它的“协作章程”（何时被指派、如何交接工作、失败后如何申诉）。这种设计让Agent不再是无状态的函数调用，而是一个有记忆、有权限、有责任边界的实体。

最能体现这一思想的是Agent类中的memory属性。它不是一个简单的dict缓存，而是一个实现了BaseMemory协议的完整模块。在默认实现EntityMemory中，我追踪到其add()方法会将每一条交互记录，按agent_id、task_id、timestamp三个维度进行哈希索引，并存储在self._storage这个Dict[str, List[MemoryEntry]]结构中。这意味着，当一个Agent被多次复用于不同Crew时，它的记忆不会全局污染——Crew A中Researcher的记忆，与Crew B中同名Researcher的记忆，物理上是隔离的。这个细节解释了为什么你在文档里看不到“全局记忆池”的配置项：CrewAI认为，记忆的归属权必须绑定到具体的协作上下文（Crew），这是保障多团队并行运行稳定性的基石。我在压测一个电商客服系统时，曾故意让10个Crew实例共享同一个Agent对象，结果发现用户A的订单查询历史，会诡异出现在用户B的售后对话中。最终定位到问题根源，正是违反了这个“记忆-上下文绑定”原则。修复方案很简单：为每个Crew创建独立的Agent实例，哪怕它们的role和goal完全相同。这看似增加了内存开销，但换来的是绝对的隔离性与可预测性。

3. 核心源码模块深度解析与实操要点

3.1Agent类：从“角色定义”到“能力执行”的全链路

Agent类位于crewai/agents/agent.py，它是整个协作网络的原子单元。但很多人只把它当作一个配置容器，忽略了它内部隐藏的执行引擎。我们从__init__方法开始深挖：

def __init__( self, role: str, goal: str, backstory: str, tools: Optional[List[BaseTool]] = None, llm: Optional[BaseLLM] = None, memory: bool = True, verbose: bool = False, max_iter: Optional[int] = 15, max_rpm: Optional[int] = None, step_callback: Optional[Callable] = None, cache: bool = True, **kwargs ):

这段初始化代码里，tools和llm的类型标注值得细究。tools被声明为Optional[List[BaseTool]]，意味着它可以为空——这对应着“纯思考型Agent”，比如一个负责战略规划、不直接调用外部API的CTO角色；而llm却是Optional[BaseLLM]，且在_get_llm()方法中，如果未传入llm，它会回退到self._default_llm，这是一个全局单例。这个设计暗示了一个重要事实：CrewAI认为，思考（LLM调用）是Agent的默认能力，而行动（Tool调用）是可选的附加技能。这与人类社会的常识一致：一个员工可以没有具体操作权限（如实习生），但不能完全没有思考能力。

Agent.execute_task()是真正的执行入口。它内部的逻辑远比表面复杂：

1. 上下文组装：它会递归收集task.context中指定的其他Task的输出，并将其格式化为<task_output>...</task_output>标签包裹的字符串，再拼接到当前Task的description之后。这个过程在_build_context()方法中完成，它会检查context是否为Task对象、List[Task]或str，并做相应处理。
2. 提示工程：生成的最终提示（Prompt）并非简单拼接，而是严格遵循一个模板。我在agent.py的_create_prompt()方法里找到了这个模板的骨架：

   You are {self.role}. Your goal is {self.goal}. Your backstory is {self.backstory}. Here is the context you have: {context} Your task is: {task.description} {self.tools_description} # 工具描述部分

   关键在于{self.tools_description}。它不是静态字符串，而是由self._tools_description()动态生成，会根据tools列表中每个BaseTool的name、description和args_schema（JSON Schema）实时渲染。这意味着，如果你的工具参数Schema写得模糊（比如用{"type": "object"}而不定义具体字段），生成的提示就会缺乏关键约束，导致LLM胡乱猜测参数值。
3. 执行与记忆：调用llm.invoke(prompt)得到原始响应后，execute_task()会立即将prompt和response存入self.memory.add()，并返回一个TaskOutput对象。这个对象不仅包含raw文本，还包含pydantic_model（如果任务定义了输出模型）、agent引用和task引用。这为后续的Task结果交叉验证提供了数据基础。

提示：Agent的max_iter参数常被误解为“最大重试次数”，实则是“最大思考轮次”。当LLM在一次调用中未能生成符合预期格式的输出（如JSON解析失败），Agent会自动进入下一轮，将上一轮的raw输出和错误信息（如JSONDecodeError）一并作为新上下文喂给LLM，让它自我修正。这本质上是一个内置的“思维链（Chain-of-Thought）”纠错机制。

3.2Task类：任务生命周期的七种状态与状态机实现

Task类（crewai/tasks/task.py）是CrewAI中状态最丰富的模块。它定义了从创建到终结的完整生命周期，其状态机逻辑直接决定了协作的健壮性。Task的状态并非简单的枚举，而是一个带有副作用的状态转换图：

这个状态机的精妙之处在于VALIDATING状态。它不是一个被动等待的环节，而是一个主动干预的关口。例如，当你为Task设置了output_pydantic=ReportModel，Task在_validate_json()中会尝试用pydantic.BaseModel.parse_raw()解析LLM输出。如果失败，它不会立刻报错，而是会检查self.expected_output是否为非空字符串。如果是，它会将expected_output作为新的提示约束，再次调用Agent，形成一个“小闭环”。我在开发一个法律文书生成Task时，就利用了这一点：将expected_output设为“请严格按照《民法典》第584条格式，输出包含‘违约金计算基数’、‘日利率’、‘起算日期’、‘截止日期’四个字段的JSON”，当LLM首次输出缺少截止日期时，Task自动发起第二次调用，并在提示中强调“上一次输出缺失‘截止日期’字段，请务必补全”。这种基于状态的自适应重试，是CrewAI区别于简单脚本的核心竞争力。

3.3Crew类：协作网络的“中央处理器”与心跳机制

Crew类（crewai/crew.py）是整个框架的“大脑”，但它的源码揭示了一个反直觉的事实：它本身并不聪明，它只负责确保聪明的Agent们能被正确地“看见”和“听见”。Crew.kickoff()方法是启动协作的唯一入口，其内部逻辑可概括为三步：

1. 初始化与校验：_setup()方法会检查agents列表是否为空、tasks是否已分配、process是否有效。这里有一个关键校验：它会遍历所有Task，检查其agent属性是否存在于self.agents列表中。如果不存在，会抛出ValueError("Task's agent not found in crew's agents")。这个看似简单的检查，实际上构建了协作的“信任锚点”——Crew只承认自己雇佣的Agent，拒绝任何外部注入的“黑户员工”。

2. 主循环执行：_execute()方法是核心。它根据self.process的类型，启动不同的执行循环。以SequentialProcess为例，其_run_next_task()方法会：

   • 从self.tasks列表中取出第一个status == PENDING的Task；
   • 调用task.execute(agent=task.agent)；
   • 等待task状态变为VALIDATED或FAILED；
   • 将该Task从self.tasks中移除（pop(0)），并将结果存入self._results；
   • 重复此过程，直到self.tasks为空。

   这个“取-执-删”的模式，保证了任务流的严格顺序性。但要注意，_execute()方法本身是同步阻塞的，它不会启动协程或线程。这意味着，如果你的Task涉及耗时的HTTP请求，整个Crew的执行会被挂起。解决方案是：在你的BaseTool实现中，使用asyncio或threading进行异步封装，让tool.run()方法内部自行处理I/O等待，从而不阻塞Crew的主循环。

3. 结果聚合与收尾：当所有Task完成后，_finish_execution()方法会被调用。它会遍历self._results，将每个TaskOutput的raw内容拼接成一个最终字符串，并调用self._format_output()进行美化（如添加标题、分隔符）。这个最终输出，就是Crew.kickoff()方法的返回值。值得注意的是，self._results是一个List[TaskOutput]，它保留了所有中间结果的完整元数据（agent、task、start_time、end_time），这为后续的审计、调试和性能分析提供了宝贵的数据源。我在一个需要向客户交付详细执行报告的项目中，就直接序列化了crew._results，生成了一份包含每个步骤耗时、所用Agent、输入上下文和原始输出的HTML报告，客户反馈这比单纯的最终答案更有价值。

3.4Process模块：从“顺序执行”到“分层指挥”的协议栈

Process模块（crewai/processes/）是CrewAI的“协作协议栈”，它定义了Crew如何组织Agent的工作。目前官方支持SequentialProcess和HierarchicalProcess两种，但源码设计为高度可扩展。

SequentialProcess是最直观的，其_run_next_task()方法已在上一节详述。它的核心假设是：所有Task构成一条线性依赖链，前一个的输出是后一个的输入。这适用于流程明确、步骤固定的场景，如“市场调研→竞品分析→报告撰写”。

HierarchicalProcess则复杂得多，它模拟了现实世界中的“管理层-执行层”结构。其核心逻辑在_run_next_task()中体现为：

• 它首先会查找所有status == PENDING且agent.role == "Manager"的Task（即管理者任务）；
• 如果找到，它会优先执行该Task，因为管理者需要先制定计划、分配资源；
• 管理者Task的输出，会被解析为一个Dict，其中"tasks"键对应一个List[Dict]，每个字典描述一个待执行的子任务（包含description、agent_role等）；
• HierarchicalProcess会根据这些描述，动态创建新的Task实例，并将其agent设置为匹配agent_role的Agent，然后加入self.tasks队列。

这个机制的威力在于动态性。管理者Agent的输出，本质上是一个“任务编排指令”，它让协作网络具备了根据实时情况（如上游Task的失败、外部数据的变化）动态调整执行计划的能力。我在一个新闻聚合项目中，就利用了这一点：Editor（管理者）Agent会先扫描当天热点，然后根据热点的紧急程度和领域，动态生成3-5个Research（研究员）Task，每个Task的description都精确指向一个具体的新闻事件和数据源。这比预先写死10个Task要灵活高效得多。

注意：HierarchicalProcess的动态任务创建，依赖于Task输出的结构化程度。如果Editor的输出是自由文本，HierarchicalProcess无法解析。因此，必须为Editor的Task强制指定output_pydantic=PlanModel，其中PlanModel定义了tasks: List[SubTask]字段。这是确保高层指令能被底层准确执行的“协议握手”。

4. 实操过程与核心环节实现：从零构建一个可审计的财务分析Crew

4.1 场景定义与需求拆解：为什么需要“可审计”？

我们来构建一个真实的、有业务价值的Crew：一个为中小企业提供季度财务健康度分析的自动化团队。需求很明确：

• 输入：公司最新的资产负债表、利润表、现金流量表（CSV格式）；
• 输出：一份包含“偿债能力”、“盈利能力”、“运营效率”三大维度的分析报告，并附上关键指标计算过程与数据来源；
• 关键约束：“可审计”——意味着每一条结论，都必须能追溯到具体的原始数据行、具体的计算公式、以及具体是哪个Agent做出的判断。

这个“可审计”要求，直接决定了我们的源码级实现策略：不能依赖LLM的“黑箱”推理，而必须将计算逻辑、数据提取逻辑、验证逻辑全部显式编码为BaseTool，让Agent只负责“选择工具”和“组织语言”，而非“发明逻辑”。

4.2 工具（Tools）开发：将Excel公式翻译成Python函数

BaseTool是CrewAI中连接AI与现实世界的桥梁。对于财务分析，我们需要开发以下核心工具：

• ExtractFinancialDataTool：从CSV中提取指定科目金额。

  class ExtractFinancialDataTool(BaseTool): name: str = "extract_financial_data" description: str = ( "Extracts the numeric value for a given financial item (e.g., 'Total Revenue', 'Cash and Cash Equivalents') " "from a provided CSV file path. The CSV must have 'Item' and 'Amount' columns." ) def _run(self, item_name: str, csv_path: str) -> str: try: df = pd.read_csv(csv_path) # 精确匹配，避免'Cash'匹配到'Cash and Cash Equivalents' row = df[df['Item'].str.contains(item_name, case=False, na=False, regex=False)] if len(row) == 0: return f"ERROR: Item '{item_name}' not found in CSV." value = row.iloc[0]['Amount'] # 记录审计线索 audit_log = f"EXTRACTED '{item_name}' = {value} from {csv_path} (row {row.index[0]})" print(audit_log) # 或写入日志文件 return str(value) except Exception as e: return f"ERROR: Failed to extract {item_name}: {str(e)}"

• CalculateRatioTool：执行标准化财务比率计算。

  class CalculateRatioTool(BaseTool): name: str = "calculate_ratio" description: str = ( "Calculates a standard financial ratio. Supported ratios: 'current_ratio', 'debt_to_equity', " "'net_profit_margin', 'inventory_turnover'. Requires the necessary input values as numbers." ) def _run(self, ratio_name: str, **kwargs) -> str: try: if ratio_name == "current_ratio": current_assets = float(kwargs.get("current_assets", 0)) current_liabilities = float(kwargs.get("current_liabilities", 0)) result = current_assets / current_liabilities if current_liabilities != 0 else float('inf') audit_log = f"RATIO 'current_ratio' = {current_assets} / {current_liabilities} = {result}" elif ratio_name == "net_profit_margin": net_income = float(kwargs.get("net_income", 0)) revenue = float(kwargs.get("revenue", 0)) result = (net_income / revenue) * 100 if revenue != 0 else 0 audit_log = f"RATIO 'net_profit_margin' = ({net_income} / {revenue}) * 100 = {result}%" # ... 其他比率 print(audit_log) return f"{ratio_name.upper()}: {result:.2f}" except Exception as e: return f"ERROR: Calculation failed for {ratio_name}: {str(e)}"

这些工具的关键在于print(audit_log)。它不是为了展示给用户，而是为了在终端或日志中留下不可篡改的执行痕迹。当Crew运行完毕，我们可以通过搜索日志中的EXTRACTED和RATIO关键字，瞬间还原出整个分析链条。

4.3 Agent与Task设计：角色分工与责任绑定

基于可审计原则，我们设计三个Agent：

• DataEngineer：只负责数据提取，不参与计算或分析。

  data_engineer = Agent( role="Senior Data Engineer", goal="Accurately extract raw financial figures from provided CSV files.", backstory="A meticulous engineer with 10 years of experience in financial data pipelines. Believes in 'garbage in, garbage out'.", tools=[ExtractFinancialDataTool()], verbose=True, allow_delegation=False # 禁止委托，确保数据源头可控 )

• FinancialAnalyst：只负责比率计算，不接触原始CSV。

  financial_analyst = Agent( role="Certified Financial Analyst", goal="Calculate key financial health ratios using only the extracted raw data.", backstory="A CFA charterholder who trusts only numbers, not narratives.", tools=[CalculateRatioTool()], verbose=True, allow_delegation=False )

• BusinessAdvisor：负责综合解读、撰写报告，但其所有结论必须引用前两个Agent的输出。

  business_advisor = Agent( role="Strategic Business Advisor", goal="Interpret the calculated ratios and provide actionable, evidence-based advice on the company's financial health.", backstory="A seasoned advisor who never makes a claim without citing its data source.", tools=[], # 不需要工具，只整合已有输出 verbose=True, allow_delegation=True # 可以委托给Analyst进行补充计算 )

对应的Task设计，严格遵循数据流向：

1. extract_revenue_task:agent=data_engineer,description="Extract 'Total Revenue' from the income_statement.csv file."
2. extract_net_income_task:agent=data_engineer,description="Extract 'Net Income' from the income_statement.csv file."
3. calculate_margin_task:agent=financial_analyst,description="Calculate the 'net_profit_margin' using the extracted 'Total Revenue' and 'Net Income'.",context=[extract_revenue_task, extract_net_income_task]
4. generate_report_task:agent=business_advisor,description="Write a comprehensive financial health report. For every claim about profitability, explicitly cite the 'net_profit_margin' value and its calculation source.",context=[calculate_margin_task]

注意context参数的使用。它强制BusinessAdvisor只能看到calculate_margin_task的输出，而看不到原始CSV路径。这从架构上杜绝了“绕过审计”的可能性。

4.4 Crew构建与执行：注入审计钩子

最后，我们构建Crew并启动：

# 创建Crew，使用SequentialProcess确保严格顺序 financial_crew = Crew( agents=[data_engineer, financial_analyst, business_advisor], tasks=[extract_revenue_task, extract_net_income_task, calculate_margin_task, generate_report_task], process=SequentialProcess(), verbose=True, # 注入自定义回调，捕获每个Task的完整生命周期 task_callback=lambda task: print(f"[AUDIT] Task '{task.description}' started by {task.agent.role} at {datetime.now()}"), step_callback=lambda step: print(f"[AUDIT] Step executed: {step}") ) # 执行 result = financial_crew.kickoff() print("=== FINAL REPORT ===") print(result)

task_callback和step_callback是CrewAI提供的强大钩子。它们让我们无需修改源码，就能在每个关键节点插入自己的审计逻辑。task_callback会在每个Task开始执行时触发，step_callback则在Agent的每一次LLM调用后触发（即每一轮思考）。通过这两个钩子，我们可以构建一个完整的执行时间线，精确到毫秒级。

4.5 结果验证与审计追踪：如何证明“报告可信”？

运行结束后，一份典型的审计日志会是这样的：

[AUDIT] Task 'Extract 'Total Revenue' from the income_statement.csv file.' started by Senior Data Engineer at 2024-05-20 10:02:15.123 EXTRACTED 'Total Revenue' = 1500000.0 from income_statement.csv (row 0) [AUDIT] Task 'Extract 'Net Income' from the income_statement.csv file.' started by Senior Data Engineer at 2024-05-20 10:02:16.456 EXTRACTED 'Net Income' = 180000.0 from income_statement.csv (row 5) [AUDIT] Task 'Calculate the 'net_profit_margin'...' started by Certified Financial Analyst at 2024-05-20 10:02:17.789 RATIO 'net_profit_margin' = (180000.0 / 1500000.0) * 100 = 12.00% [AUDIT] Task 'Write a comprehensive financial health report...' started by Strategic Business Advisor at 2024-05-20 10:02:19.012

现在，当客户质疑“为什么说利润率是12%？”时，我们不再需要说“AI算的”，而是可以指着日志说：“请看第3行，这是FinancialAnalyst调用CalculateRatioTool的完整计算过程，输入数据来自第1行和第2行的DataEngineer提取结果。” 这种基于源码级行为的可追溯性，才是企业级应用真正的护城河。

5. 常见问题与排查技巧实录：来自真实战场的12个血泪教训

5.1 “Agent总是重复同样的错误”——LLM缓存与上下文污染

现象：一个负责代码审查的Agent，在连续审查多个PR时，会反复对同一段代码给出相同的、但明显错误的建议，即使你已经手动纠正过它。

根因分析：Agent的memory默认是开启的，且Crew在复用同一个Agent实例时，会将所有Task的历史都累积到其memory中。当Task数量过多，memory会变得臃肿，LLM在生成新响应时，会过度关注早期的、可能已过时的上下文，导致“刻板印象”。

排查技巧：

1. 在Agent初始化时，显式关闭memory：memory=False；
2. 或者，为每个Task创建一个全新的Agent实例（牺牲一点性能，换取纯净性）；
3. 最佳实践：使用memory的limit参数，例如memory=EntityMemory(limit=5)，只保留最近5次交互。

实操心得：我在一个持续集成（CI）流水线中集成CrewAI时，就采用了“每个PR一个全新Agent”的策略。虽然每次都要重新加载llm，但避免了跨PR的上下文污染，保证了每次审查的独立性和公正性。

5.2 “Task.context不生效”——上下文传递的隐式规则

现象：明明在Task的context参数里传入了另一个Task，但执行时Agent的提示中却没有看到预期的上下文内容。

根因分析：context参数只接受Task对象或List[Task]，绝不接受TaskOutput对象或字符串。如果你传入的是previous_task.output.raw，Crew会静默忽略，不会报错，也不会警告。

排查技巧：

1. 在Task创建后，立即打印task.context，确认其类型是<class 'crewai.tasks.task.Task'>；
2. 使用isinstance(task.context, Task)进行类型检查；
3. 如果你需要传递一个字符串作为上下文，不要用context，而应该直接将其拼接到task.description中。

5.3 “Crew执行卡死，CPU 100%”——无限递归与LLM幻觉

现象：Crew启动后，终端没有任何输出，top命令显示Python进程CPU占用率100%，数分钟后才报RecursionError。

根因分析：这是Agent的max_iter参数被设得过大（如100），且Agent的goal或Task的description表述模糊，导致LLM陷入“尝试-失败-重试-再失败”的死循环。例如，`