design-agent

CrewAI Agent 设计指南

如何通过合适的角色、目标、背景故事、工具和配置来设计高效的 Agent。

已根据 2026-10-01 的 crewai 1.15.23 进行验证。 已于 2026-10-01 使用真实大模型进行实时测试。

精确的 API 形式（导入、默认值、提供商扩展、结构化输出）见 check-crewai-api 技能；工具和 MCP 见 connect-tools-and-mcp。如果本技能与它们存在差异，请以它们为准。

---

80/20 法则

将 80% 的精力用于任务设计，20% 用于 Agent 设计。 设计良好的任务能让简单的 Agent 也发挥出色。但即使是最好的 Agent，也无法弥补任务含糊不清、范围不明确的问题。先把任务设计好（参见 design-task 技能），再完善 Agent。

---

0. 你到底需要多少个 Agent？

默认使用一个 Agent。 只有当任务确实分解为需要以下条件的工作时，才增加 Agent：

• 不同的工具或权限——例如，一个 Agent 拥有 Slack 写入权限，另一个只能读取文档。
• 大模型必须明确切换的不同角色——写作者的风格不同于研究者的风格。
• 不同的大模型——机械性步骤使用廉价模型，综合分析使用更强的模型。
• 不同的护栏或输出架构——使用独立 Agent 可以明确各阶段的约定。

不要仅仅因为工作流包含多个步骤就增加 Agent。 单个 Agent 可以在一次 kickoff 中依次调用多个工具（搜索 → 抓取 → 总结是一个 Agent 的循环），在一次响应中生成包含多个部分的结构化输出，也可以通过自身的工具使用循环反复迭代。

成本考量： 每增加一个 Agent，至少就会多一次大模型 kickoff 和一次上下文交接。将线性、单一角色的工作拆分给多个 Agent，会成倍增加令牌成本，并带来更多不稳定性，质量提升却微乎其微。

反模式

❌ 把一个研究者的工作交给三个 Agent：

source_finder = Agent(role="Finds URLs via Firecrawl search", tools=[firecrawl_search])
scraper       = Agent(role="Scrapes URLs via Firecrawl scrape", tools=[firecrawl_scrape])
writer        = Agent(role="Writes the report")  # plus goal, backstory, llm

✅ 一个研究者负责信息收集循环，一个写作者负责综合整理——因角色和大模型确实不同，所以使用两个 Agent：

researcher = Agent(role="Web Researcher", tools=[firecrawl_search, firecrawl_scrape], llm="anthropic/claude-haiku-4-5")
writer     = Agent(role="Technical Report Writer",                                    llm="anthropic/claude-sonnet-4-6")

❌ 使用一个 Summarizer Agent 和一个 Slack Sender Agent（apps=["slack"]），来总结一段字符串并通过私信发送。 ✅ 使用一个 Slack Reporter Agent，设置 apps=["slack"]，并在任务中写明：“先在顶部撰写一段 2-3 句的执行摘要，然后通过私信将摘要和完整正文发送给 {recipient_email}。”

经验法则： 如果两个“Agent”具有相同的角色、相同的工具范围和相同的大模型，那么它们其实是一个 Agent，只是任务描述更长。

确定“一个 Agent 足够”后

直接在 Flow 方法中使用 Agent.kickoff()——无需 Crew，也无需 Task 仪式。Flow 负责排序和状态；每个步骤都是一次单独的 Agent kickoff（Flow 机制：build-flow 技能；文档：https://docs.crewai.com/en/concepts/agents#direct-agent-interaction-with-kickoff）。

@listen(previous_step)
def my_step(self):
    agent = Agent(role="…", goal="…", backstory="…", tools=[...], llm="anthropic/claude-haiku-4-5")
    result = agent.kickoff(
        f"Use this prior step's output: {self.state.prior_field}",
        response_format=MyPydanticModel,  # optional
    )
    self.state.my_field = result.pydantic  # or result.raw

只有当某个步骤确实需要多 Agent 协作（委派、层级管理、并行专家共同提供综合结果），或者 Agent 需要只能在 crew 任务中使用的功能时，才使用 Crew.kickoff()：知识源和 max_execution_time（第 2 节）。

---

1. 角色-目标-背景故事框架

每个 Agent 都需要三项内容：它是谁、它想要什么，以及它为何具备相应资质。三个部分中的 {placeholders} 都通过 crew.kickoff(inputs={...}) 填入。

角色——Agent 是谁

角色定义了 Agent 的专业领域。要具体，不要笼统。

不佳	良好
Researcher	Senior Data Researcher specializing in {topic}
Writer	Technical Blog Writer for developer audiences
Analyst	Financial Risk Analyst with regulatory compliance expertise

角色会直接影响大模型的推理方式。即使任务相同，“Senior Data Researcher”与“Research Assistant”也会生成不同的输出。

目标 — Agent 想要达成什么

目标是 Agent 的个人任务，应当以结果为导向，并设定质量标准。

不佳	良好
Do research	Uncover cutting-edge developments in {topic} and identify the top 5 trends with supporting evidence
Write content	Produce publication-ready technical articles that explain complex topics clearly for non-technical readers
Analyze data	Deliver actionable risk assessments with confidence levels and recommended mitigations

背景故事 — Agent 为何胜任

背景故事用于确立专业知识、经验、价值观和工作方式。这是 Agent 的“个性提示词”。

backstory: >
  You're a seasoned researcher with 15 years of experience in AI/ML.
  You're known for your ability to find obscure but relevant papers
  and synthesize complex findings into clear, actionable insights.
  You always cite your sources and flag uncertainty explicitly.

应包括： 经验年限和深度、具体领域知识、工作方式和价值观（“始终注明来源”“偏好简洁的输出”），以及 Agent 对自身的质量要求。

应避免： 实现细节（工具、模型、配置）、特定任务的说明（应放在任务描述中），以及不会影响输出质量的性格特征。

---

2. Agent 配置参考

Agent 会静默忽略它不认识的关键字参数，因此，拼写错误或已移除的参数不会产生任何效果，也不会报错。如有疑问，请检查 "name" in Agent.model_fields。

Agent(
    role="...", goal="...", backstory="...",   # Required
    llm="anthropic/claude-haiku-4-5",          # See LLM Selection
    tools=[...],                               # Tool instances
    max_iter=25,             # Max reasoning iterations per task (default: 25)
    max_execution_time=300,  # Seconds, crew tasks only (default: None - no limit)
    max_rpm=10,              # Max LLM calls per minute for this agent (default: None)
    max_retry_limit=2,       # Retries when task execution errors (default: 2)
    allow_delegation=False,  # Default: False — agent works alone
    respect_context_window=True,  # Summarize and continue on overflow (default: True)
    inject_date=False,       # Put today's date in the prompt (default: False; format via date_format)
    verbose=False,           # Detailed execution logs (default: False)
)

执行限制（在 1.15.23 上测量）

限制	行为
max_iter	达到上限时不会报错。Agent 会收到立即给出最终答案的指示；无论它完成了多少工作，本次运行都会“成功”。max_iter=1 时，一个四步工具流程只记录了一步，并返回了不完整的答案。
max_rpm	超出限制的调用会阻塞，直到下一个分钟窗口。max_rpm=2 时，第三次大模型调用在 62 秒时才开始，而不是约 2 秒后。
max_execution_time	仅当 Agent 在 Crew 中运行 Task 时适用；Agent.kickoff() 会忽略它（设置 5 秒限制、使用 15 秒工具时，任务仍在 17 秒后正常完成）。在 crew 中，它不会在截止时间到达时停止工作：正在运行的工具和大模型调用会完成，随后任务会抛出 TimeoutError: Task '...' execution timed out after 5 seconds（在 18.8 秒时抛出），已完成的工作则会被丢弃。

因此，max_execution_time 会让运行缓慢的任务报错，却无法阻止任务卡住。若要限制实际耗时，应在耗时操作所在的位置设置超时：LLM(model=..., timeout=60)，并在工具内部设置超时；或者在可强制终止的子进程中运行 kickoff。

调整 max_iter： 默认值 25 较为宽松，大多数任务会在 3–8 次迭代内完成。对于定义明确的任务，可将其调低至 10–15，以便更快失败。如果 Agent 总是达到上限，说明任务过于模糊（应修改任务，而非限制）。达到上限不会报错，因此应检查输出，而不是退出代码。

其他开关： respect_context_window=True 会在提供方报告上下文长度超限时总结对话并继续运行；设为 False 时，运行会以 SystemExit: Context length exceeded ... 结束。对于有时效性的任务（研究、新闻、日程安排），建议启用 inject_date=True：询问今天的日期时，启用该选项的 Agent 能正确回答，而未启用的 Agent 回答了 UNKNOWN。

工具

• 没有工具的 Agent 在被要求搜索、获取或读取文件时会捏造数据——需要外部数据的任务务必提供工具。
• 优先选择数量更少、用途明确的工具——工具过多会让 Agent 困惑。
• Agent 级工具可供该 Agent 执行的所有任务使用。Task(tools=[...]) 会为该任务替换这些工具。在一项实时测试中，拥有天气工具的 Agent 被分配了一个只包含人口工具的任务后，只能调用人口工具。
• 预构建工具需要对应的密钥（SerperDevTool() 需要 SERPER_API_KEY）。自定义工具、实际存在的 crewai_tools 名称、缓存和 MCP 服务：connect-tools-and-mcp。

LLM 选择

from crewai import LLM

Agent(..., llm="anthropic/claude-haiku-4-5")
Agent(..., llm=LLM(model="anthropic/claude-haiku-4-5", temperature=0.2, timeout=60))

• 未设置 llm= 时，Agent 会依次使用环境变量 MODEL、MODEL_NAME、OPENAI_MODEL_NAME，否则使用 gpt-4.1-mini。这是一个 OpenAI 模型，因此没有 OPENAI_API_KEY 时，启动会失败。
• 只有 OpenAI 随核心 crewai 一起提供。anthropic/... 需要 uv add "crewai[anthropic]"，gemini/... 需要 crewai[google-genai]，非原生提供商需要 crewai[litellm]（完整表格见 check-crewai-api）。
• 为机械式 Agent 选择更便宜的模型。function_calling_llm（用于工具调用的单独模型）在 Agent 和 Crew 上都已弃用——请改为设置每个 Agent 的 llm。

协作

仅在 Agent 属于包含其他专业 Agent 的 crew、任务确实适合移交子任务，或使用由管理者委派任务的层级流程时，才设置 allow_delegation=True。警告： 没有明确的任务边界就进行委派，会导致无限循环或浪费迭代次数。

规划（计划并执行模式）

使用 PlanningConfig 时，Agent 会先生成计划（步骤列表），在各自的多轮循环中执行每个步骤（上限为 max_step_iterations），检查每个结果，然后继续、重新规划或提前结束。

from crewai import Agent
from crewai.agent.planning_config import PlanningConfig

agent = Agent(
    role="…", goal="…", backstory="…", tools=[...],
    planning_config=PlanningConfig(reasoning_effort="medium"),  # most common
)

要禁用规划，请省略 planning_config。单独设置 planning=True 等同于 PlanningConfig(reasoning_effort="low", max_attempts=1)。reasoning=True 已弃用（会发出 DeprecationWarning）——请改用 planning_config。

reasoning_effort	规划器在每一步之后……	适用场景
"low"	使用启发式方法检查步骤（不额外调用大模型），然后继续。不重新规划，也不优化。	你希望看到计划（待办事项、观察结果），但相信 Agent 会按顺序执行。速度最快。
"medium"（默认值）	调用大模型观察步骤；仅在失败时重新规划。	Agent 的工具可能会失败（网络、执行、抓取），而你希望能妥善恢复。这是沙盒编码、研究和其他工具密集型循环的合适默认值。
"high"	观察步骤，然后可提前结束、全面重新规划，或在每一步之后优化计划。	任务会根据中间发现改变方向，或你需要最大的适应性。每次运行调用的大模型次数最多。

PlanningConfig(
    reasoning_effort="medium",
    observe_steps=None,      # None = LLM observation for medium/high, heuristic for low
    max_steps=20,            # cap on planned steps
    max_replans=3,           # full re-plans before finalizing
    max_attempts=None,       # refinement attempts during plan generation
    max_step_iterations=15,  # LLM turns per step
    step_timeout=None,       # wall-clock seconds per step
    system_prompt=None, plan_prompt=None, refine_prompt=None,  # custom prompts
    llm=None,                # separate (cheaper) LLM for planning; else agent.llm
)

适用场景： 对于由 Agent 自主选择步骤、且你希望具备失败恢复能力的自主循环（例如，编写 → 运行 → 修补代码的编码 Agent；搜索 → 抓取 → 修改内容的研究 Agent）。对于单工具、单用途调用（“总结这段字符串”“发布这条 Slack 私信”），请勿启用。

成本： 在一次测量中，规划使一个包含两个步骤的任务增加了 3-7 次调用，并让回答变成了散文。启用前，请先在自己的任务上测量。

代码执行

allow_code_execution 和 code_execution_mode 已弃用且不执行任何操作（allow_code_execution=True 会发出 DeprecationWarning），CodeInterpreterTool 也已从 crewai_tools 中移除。请为 Agent 提供沙盒工具，例如 E2BPythonTool 或 DaytonaPythonTool（参见 connect-tools-and-mcp）。

Agent 防护规则

from typing import Any

def require_uppercase(result) -> tuple[bool, Any]:
    if result.raw != result.raw.upper():
        return (False, "Rewrite the whole answer in UPPERCASE letters only.")
    return (True, result.raw)

agent = Agent(..., guardrail=require_uppercase, guardrail_max_retries=3)  # default retries: 3
result = agent.kickoff("...")   # the agent guardrail runs here

防护规则也可以是字符串，此时会通过额外的大模型调用进行检查。在 crewai 1.15.23 中，Agent 防护规则有两项限制，两者均已通过真实大模型验证：

• 它们仅在 Agent.kickoff() 时运行。 同一个 Agent 在 Crew 中执行 Task 时，不会调用 Agent 防护规则。
• 在 crewai 1.15.23 中，Agent 级防护规则重试时会重新发送原始提示词，而不包含反馈，因此上述大写检查的三次尝试均失败。 建议使用任务级防护规则，因为它会传递反馈。重试次数用尽时，kickoff 会引发 ValueError: Agent's guardrail failed validation after N retries. Last error: ...。

如果必须修正输出，而不只是拒绝输出，请将防护规则设置在 Task 上（Task(guardrail=..., guardrail_max_retries=...)）。错误消息会反馈到任务中，同一项大写检查在第二次尝试时通过了。参见 design-task 和 check-crewai-api。

知识源

from crewai.knowledge.source.text_file_knowledge_source import TextFileKnowledgeSource

Agent(
    ...,
    knowledge_sources=[TextFileKnowledgeSource(file_paths=["company_handbook.txt"])],  # read from ./knowledge/
    embedder={"provider": "onnx"},   # local, no API key; omit it to use OpenAI embeddings
)

知识源通过 RAG 为 Agent 提供特定领域的数据。当 Agent 需要参考大型文档、政策或数据集时，请使用知识源。需要了解两点：

• 只有当 Agent 在 Crew 中运行任务时，才会查询 Agent 知识。 Agent.kickoff() 会静默忽略 knowledge_sources。在一次实时测试中，同一个 Agent 通过 kickoff() 回答了“UNKNOWN”，而通过包含一个任务的 crew 则给出了正确回答。
• 如果未设置 embedder=，知识功能会使用 OpenAI 嵌入模型。若未设置 OPENAI_API_KEY，在 crew 启动时，Agent 知识会引发 ValueError: Invalid Knowledge Configuration。Crew 级知识只会记录 Failed to upsert documents，并在不使用知识的情况下运行。

无需 OpenAI 的嵌入模型、KnowledgeConfig、内存和存储路径：references/memory-and-knowledge.md。

---

3. YAML 配置（推荐）

在 agents.yaml 中定义 Agent，以清晰分离配置与代码。使用 crewai create crew <name> --classic 创建 YAML 项目。不带 --classic 时，crewai create crew 会启动交互式向导，并写入 JSON 项目。

researcher:
  role: >
    {topic} Senior Data Researcher
  goal: >
    Uncover cutting-edge developments in {topic}
    with supporting evidence and source citations
  backstory: >
    You're a seasoned researcher with 15 years of experience.
    Known for finding obscure but relevant sources and
    synthesizing complex findings into clear insights.
    You always cite your sources and flag uncertainty.
  # Optional overrides: llm: anthropic/claude-haiku-4-5, max_iter: 15, max_rpm: 10,
  # allow_delegation: false, verbose: true

然后在 crew.py 中进行连接：

@CrewBase
class MyCrew:
    agents_config = "config/agents.yaml"
    tasks_config = "config/tasks.yaml"

    @agent
    def researcher(self) -> Agent:
        return Agent(config=self.agents_config["researcher"], tools=[SerperDevTool()])

重要： 方法名（def researcher）必须与 YAML 键（researcher:）一致。不一致会导致 KeyError（已验证：KeyError: 'researcher'）。

已通过实时测试验证：YAML 中设置的 llm 和 max_iter 会生效，角色中的 {topic} 会在启动时填入，工具则在 Python 中附加。请将工具、护栏函数和 Pydantic 模型保留在 Python 中；YAML 用于存放文本和标量设置。

---

4. Agent.kickoff() — 直接执行 Agent

当你需要一个具备工具和推理能力、且无需 crew 开销的 Agent 时，请使用 Agent.kickoff()。这是 Flows 中最常见的模式。它不会使用 Agent 的知识源或 max_execution_time（第 2 节）。

from pydantic import BaseModel
from crewai import Agent

researcher = Agent(
    role="Senior Research Analyst",
    goal="Find comprehensive, factual information with source citations",
    backstory="Expert researcher known for thorough, evidence-based analysis.",
    tools=[...],
    llm="anthropic/claude-haiku-4-5",
)

result = researcher.kickoff("What are the latest developments in quantum computing?")
print(result.raw)             # str — the agent's full response
print(result.usage_metrics)   # dict: total_tokens, prompt_tokens, completion_tokens, ...

class ResearchFindings(BaseModel):
    key_trends: list[str]
    sources: list[str]
    confidence: float

result = researcher.kickoff("Research the latest AI agent frameworks", response_format=ResearchFindings)
print(result.pydantic.key_trends, result.pydantic.confidence)

result = await researcher.kickoff_async("...", response_format=ResearchFindings)  # async variant

注意： Agent.kickoff() 返回 LiteAgentOutput——通过 result.pydantic 访问结构化输出。这与 llm.call(messages, response_model=Model) 不同，后者会直接返回 Pydantic 对象。Agent.kickoff(..., response_model=...) 会引发 TypeError。

文件输入需要额外安装依赖：uv add "crewai[file-processing]"，然后使用 from crewai_files import FileInput，并调用 researcher.kickoff("Summarize this document", input_files={"document": FileInput(path="report.pdf")})。如果未安装此额外依赖，导入会失败并报错 ModuleNotFoundError: No module named 'crewai_files'。

Agent.kickoff() 与 Crew.kickoff()： 如果每个步骤都由不同的 Agent 执行，且由 Flow 控制顺序（第 0 节的结构——已通过实时双步骤 Flow 验证），请使用 Agent.kickoff()。如果多个 Agent 在单个步骤中协作完成相关任务，或 Agent 需要知识源或 max_execution_time，请使用 Crew.kickoff()。

对话式 Flow 路由中的 Agent

在对话式 Flows（from crewai.flow import ConversationState）中，Flow 负责聊天生命周期和路由选择。在路由处理程序中调用 Agent，以执行范围明确、由工具支持的工作：研究、文档查询、账户操作、分类处理、起草或升级准备。相关机制（handle_turn、ConversationConfig 和一个经过测试的示例）见 build-flow 技能中的 conversational-flows 参考文档。

设计要点：

• 由对话式 Flow 负责会话 ID、消息历史、路由、跟踪记录收尾和审批。
• 每个 Agent 的职责应保持精简：一个路由、一组工具、一个任务。
• 对于不应进入规范聊天历史的临时工作，请使用 self.append_agent_result(name, result, visibility="private")。
• 从处理程序返回用户可见的回复（或调用 self.append_assistant_message(reply)），以便下一轮对话包含助手上下文。
• 不要创建一个配备所有工具的“聊天 Agent”。应先进行路由，然后为选定的路由调用专用 Agent。

---

5. 专家型 Agent 与通用型 Agent

请在确定确实需要多个 Agent（第 0 节）之后再应用本节。只有一个 Agent 时，唯一需要考虑的问题就是如何设计该 Agent。

确实需要多个 Agent 时，优先选择专家型 Agent。 一个能把一件事做好得 Agent，胜过一个什么都会做但样样都只是过得去的 Agent。任务需要深厚的领域知识、质量比速度更重要，或任务复杂到能从专注的专业能力中受益时，应使用专家型 Agent。对于说明明确的简单任务、打算先做原型之后再细分专业角色的任务，以及确实同等涉及多个领域的任务，通用型 Agent 也可以接受。

不要只创建一个“内容撰写者” Agent，而应创建 technical_writer（技术准确性、代码示例）、copywriter（有说服力、关注受众的文案）和 editor（语法、一致性、风格指南）。每个 Agent 都有明确的职责、具体的目标，以及能强化其专业能力的背景故事。

---

6. Agent 交互模式

顺序模式（默认）： Researcher → Writer → Editor。Agent 依次工作，每个 Agent 都会将前序输出作为上下文。最适合每一步都基于上一步结果构建的线性流水线。

层级模式： 管理器 Agent 负责委派和验证；任务分配是动态的。最适合任务分配取决于中间结果的复杂工作流。

Crew(
    agents=[researcher, writer, editor],
    tasks=[research_task, writing_task, editing_task],
    process=Process.hierarchical,
    manager_llm="anthropic/claude-haiku-4-5",   # or manager_agent=...; one is required
)

如果没有 manager_llm 或 manager_agent，Crew(...) 会抛出 ValidationError。

Agent 之间的委派： 设置 allow_delegation=True 后，Agent 会获得两个工具：Delegate work to coworker 和 Ask question to coworker，用于指定其他 Crew 成员。已通过实时验证：当被要求向 Writer 获取一句话时，主导 Agent 调用了 ask_question_to_coworker，并返回了 Writer 的回答。

---

7. Agent 设计中的常见错误

错误	影响	修正方法
使用“助手”这类泛泛的角色	Agent 产出缺乏重点、内容浅显	明确专业能力，例如“高级财务分析师”
数据收集任务没有配置工具	Agent 会编造数据，而不是搜索数据	任务需要外部信息时，始终添加工具
工具过多（10 个以上）	Agent 会在选择工具时感到困惑	每个 Agent 限制在 3–5 个相关工具
背景故事里充斥任务说明	Agent 会混淆个性与任务执行	背景故事只写 Agent 是谁；任务细节放在任务中
默认设置 allow_delegation=True	Agent 会浪费迭代次数进行无意义的委派	只有委派确实有帮助时才启用
简单任务的 max_iter 设置过高	Agent 会在模糊任务上不必要地循环	降低 max_iter；改进任务描述
关键输出没有护栏	不良输出会未经检查地通过	对会输入生产系统的输出添加 Task 护栏
在 Crew 中使用的 Agent 上设置 Agent 护栏	护栏不会运行	将护栏设在 Task 上
相信 max_execution_time 能终止卡住的操作	只有在缓慢调用返回后才会抛出错误，而且 Agent.kickoff() 会忽略它	为 LLM 和工具添加超时设置
通过 Agent.kickoff() 运行的 Agent 配置了知识来源	知识会被静默忽略	将其作为 Crew 任务运行，或将相关事实写入提示词
没有设置 llm=，也没有 OpenAI 密钥	Kickoff 失败：默认模型是 OpenAI gpt-4.1-mini	设置 llm=（或环境变量 MODEL）并安装对应的 provider extra
在简单任务上启用规划	LLM 调用次数增加 2–3 倍，有时答案反而更差	仅在开放式工具循环中启用规划

---

8. Agent 设计检查清单

部署 Agent 前，请确认：

• 角色 具体且聚焦于特定领域（而非“助手”或“帮手”）
• 目标 包含预期结果和质量标准
• 背景故事 体现专业知识和工作风格
• 工具 已分配给任何需要外部数据的任务
• 工具数量不过多 — 每个 Agent 最多 3–5 个
• max_iter 根据预期任务复杂度进行调整（简单任务为 10–15，复杂任务为 20–25）
• 超时 已设置在耗时的环节（LLM timeout、工具超时）；max_execution_time 仅作为 crew 任务的兜底限制
• 关键输出的 护栏 已设置在 Task 上
• LLM 已明确设置，与任务复杂度匹配，且已安装其提供商的额外依赖
• 知识 已明确设置 embedder，且 Agent 在 crew 内运行
• 除非确有需要，否则禁用 委派

---

参考资料

如需深入了解特定主题，请参阅：

• 自定义工具 — 使用 @tool 装饰器和 BaseTool 子类构建自己的工具
• 记忆与知识 - 记忆、知识来源、无需 OpenAI 即可使用的嵌入器、存储、作用域

相关技能：

• check-crewai-api - 当前的导入项、参数、默认值和提供商额外依赖
• connect-tools-and-mcp - 自定义工具、真实的 crewai_tools 名称、缓存、MCP 服务
• build-flow - Flow 状态、路由、持久化、对话式流程
• getting-started - 项目脚手架、选择合适的抽象
• design-task — 任务描述/expected_output 最佳实践、护栏、结构化输出、依赖项
• test-crewai-project - 使用 stub LLM 离线测试 Agent 和 crew
• ask-docs - 针对这些技能未涵盖的问题，查询 CrewAI 实时文档