模块化AI智能体框架：基于任务路由的智能编程助手设计与实践

1. 项目概述：一个为开发者设计的模块化AI智能体框架

如果你和我一样，每天都在和代码打交道，同时也在探索如何让AI真正成为得力的编程伙伴，而不是一个只会闲聊的玩具，那么你肯定遇到过这样的困境：不同的开发任务需要AI扮演不同的角色。写新功能时，你需要一个严谨的“架构师”；调试Bug时，你需要一个敏锐的“侦探”；代码审查时，你又需要一个挑剔的“审计员”。手动在聊天窗口里切换角色、重复描述需求，不仅效率低下，而且难以保证AI输出的质量和一致性。

今天要深入拆解的这个项目——cursor-agents-kit，正是为了解决这个痛点而生的。它不是一个简单的提示词集合，而是一个完整的、模型无关的AI智能体框架。它的核心思想是“让任务决定AI的行为”。当你提出一个需求，比如“为我的用户登录API添加JWT验证”，框架会自动判断这是一个“编码”任务，选择“编码者”智能体，并为其加载“构建API”和“安全审计”等相关技能，最后调用最适合的AI模型（如GPT-4或Claude 3）来生成结构严谨、安全可靠的代码。整个过程无需你手动干预，真正实现了智能化的任务路由与执行。

这个框架最吸引我的地方在于它的“双模”设计。一方面，它提供了完整的命令行接口，适合集成到自动化脚本或CI/CD流程中；另一方面，它深度集成了Cursor IDE，只需将规则文件放入项目，就能让你在IDE内的每一次AI对话都自动享受这套智能体工作流的加持。这意味着，无论是通过终端执行一个复杂的重构指令，还是在Cursor里随手让AI帮你写个工具函数，你都能获得同样高质量、有保障的输出。接下来，我将从设计思路、核心模块、实操配置到深度定制，为你完整呈现如何将这个框架应用到你的日常开发中。

2. 框架核心设计思路与架构解析

2.1 为何选择“智能体工作流”而非“单一提示词”

在深入代码之前，我们首先要理解这个框架背后的设计哲学。传统的AI辅助编程，无论是使用ChatGPT的网页版还是某些插件的简单集成，大多是基于一个静态的、通用的提示词。这种方式存在几个明显缺陷：上下文割裂（每个问题都是独立的，AI没有“记忆”或“角色”连续性）、能力泛化（一个提示词试图解决所有问题，导致在专业领域深度不足）、输出不可控（格式、风格、安全规范难以统一）。

cursor-agents-kit采用的“多智能体工作流”模式，本质上是一种基于规则的专家系统与大型语言模型的结合。它将复杂的软件开发任务分解为多个子角色（智能体），每个角色有明确的职责、工作流程和输出规范。当一个任务到来时，框架的“路由层”会像一位项目经理一样，分析任务性质，分派给最合适的专家（智能体），并为这位专家配备好它需要的工具（技能）和参考资料（知识库）。

这种设计带来了几个关键优势：

1. 关注点分离：调试智能体不需要知道如何规划系统架构，它只需专注于诊断问题、定位错误。这使得每个智能体的提示词可以做得非常精深和专业。
2. 质量与一致性：通过预定义的输出格式和约束规则，无论哪个智能体响应，其输出的结构、详略程度、安全规范都是统一的，极大提升了产出的可读性和可用性。
3. 灵活性与可扩展性：增加一个新的任务类型（比如“数据库迁移”），你不需要重写整个系统，只需定义一个新的智能体和相应的技能即可。这种模块化设计让框架能轻松适应技术栈的演进。

2.2 核心工作流：从用户输入到最终输出的智能决策链

框架的执行流程是一个精心设计的决策链，我们可以将其理解为一条高度自动化的流水线。理解这条流水线，是后续进行定制和调试的基础。

用户输入 -> 输入验证与安全护栏 -> 模式检测 -> 复杂度评估 -> 模型选择 -> 智能体选择 -> 技能选择 -> 上下文组装 -> LLM调用 -> 输出验证与过滤 -> 最终输出

第一阶段：任务分析与路由（智能决策）这是框架的“大脑”。core/router.py模块负责此阶段。

• 模式检测：框架会分析你的自然语言指令，判断任务属于哪种“模式”。它内置了至少六种模式：coding（编码）、debugging（调试）、architecture/planning（规划）、review（审查）、security（安全）、general（通用）。检测逻辑通常基于关键词匹配和语义分析，例如，输入中包含“error”、“fix”、“bug”会触发调试模式；包含“design”、“plan”、“architecture”会触发规划模式。
• 复杂度评估：紧接着，框架会评估任务的复杂度，分为fast（快速）、balanced（平衡）、reasoning（深度推理）三档。这直接影响后续的模型选择。一个简单的“重命名变量”任务可能是fast，而“设计一个高并发的消息队列”则会被归类为reasoning。
• 模型与智能体映射：根据确定的模式和复杂度，框架会查询config/models.yaml配置文件，选择一个最合适的AI模型。例如，coding模式下的fast任务可能映射到gpt-3.5-turbo以求速度，而reasoning任务则映射到gpt-4或claude-3-opus。同时，模式也直接决定了启用哪个智能体（agents/目录下的文件）。

实操心得：models.yaml的配置是控制成本和质量平衡的关键。我的经验是，对于日常的代码补全和简单bug修复，使用gpt-3.5-turbo完全足够，响应速度快且成本极低。只有在进行系统设计、复杂算法重构或深度安全审计时，才切换到gpt-4这类更强大的模型。你可以根据自己API的预算和需求，精细调整这个映射表。

第二阶段：上下文组装与执行（精准交付）这是框架的“双手”。路由决策完成后，执行引擎开始工作。

• 技能选择：core/skill_loader.py会扫描skills/目录下的所有Markdown技能文件。每个技能文件都有tags（标签）元数据。框架将当前任务描述与所有技能的标签进行匹配，选出最相关的几个技能。例如，一个“构建用户认证API”的任务，可能会匹配到build_api.md和audit_code.md（安全审计）两个技能。
• 上下文组装：core/context_builder.py是信息整合的中心。它会按照一个固定的模板，将以下信息有序地拼接成一个最终的提示词（Prompt）：
  1. 元数据：当前任务、模式、复杂度等信息。
  2. 智能体指令：所选智能体（如coder.md）中定义的Role、Scope、Process等。
  3. 系统规则：rules/目录下的全局约束，如代码规范、安全原则。
  4. 选中技能：匹配到的技能的具体内容。
  5. 知识库：knowledge/目录下的通用知识，如编码原则。
  6. 用户任务：原始的用户输入。
• 调用与后处理：组装好的超级提示词会被发送给选定的AI模型提供商（如OpenAI）。返回的结果首先经过core/guardrails.py的检查，包括输出格式验证、可能存在的密钥信息脱敏等，最后才呈现给用户。

3. 快速上手指南：两种使用模式详解

3.1 模式一：无缝集成Cursor IDE（开箱即用）

这是对个人开发者最友好、最无缝的使用方式。你不需要运行任何命令，只需将框架的规则文件放入你的项目，Cursor的内置AI就会自动获得超能力。

步骤拆解：

1. 获取规则文件：克隆整个项目仓库，或者只复制其中的.cursor/rules/目录到你的项目根目录。

   # 方法A：克隆整个项目作为参考 git clone https://github.com/sakshampandey1901/cursor-agents-kit.git # 方法B：只复制规则文件夹到你的现有项目 cp -r path/to/cursor-agents-kit/.cursor/ your-project/

2. 在Cursor中打开项目：用Cursor IDE打开你刚刚放入规则文件的项目。
3. 开始对话：现在，当你使用Cursor的AI聊天功能（Cmd/Ctrl + K）时，规则已经自动生效。你可以尝试以下指令，观察AI回复风格和结构的变化：
   • “帮我写一个Python函数，从URL中提取域名。”
   • “我这段代码报错了TypeError: can‘t multiply sequence by non-int of type ’float‘， 怎么修复？”
   • “请为我设计一个简单的待办事项应用的数据库Schema。”

原理解析：Cursor IDE允许在项目根目录的.cursor/rules/下放置.mdc文件。这些文件在AI对话时会被自动加载到上下文中。本框架的规则文件被精心设计为“Always Apply”（始终应用，如守护规则和输出格式）和“Intelligent”（智能触发，如各智能体和技能）。Cursor会根据你的问题语义，智能地激活相关的规则，从而模拟出多智能体工作流的效果。

注意事项：这种方式虽然便捷，但其“路由”逻辑依赖于Cursor内置的语义理解能力，不如CLI模式下的router.py那样精确和可定制。它更适合日常辅助编码，对于需要严格流程控制的复杂任务，建议使用CLI模式。

3.2 模式二：使用命令行接口（CLI）进行精细控制

CLI模式提供了最大的灵活性和控制力，适合将AI智能体集成到自动化脚本、构建流程，或者执行非常复杂、多步骤的任务。

环境准备与配置：

1. 克隆项目并安装依赖：

   git clone https://github.com/sakshampandey1901/cursor-agents-kit.git cd cursor-agents-kit pip install -r requirements.txt # 核心依赖通常是openai, anthropic, pyyaml, python-dotenv等

2. 配置API密钥：项目支持多模型提供商，你需要至少配置一个。

   cp .env.example .env # 编辑 .env 文件，填入你的API密钥 # OPENAI_API_KEY=sk-your-openai-key-here # ANTHROPIC_API_KEY=your-anthropic-key-here

   重要提示：如果你只有一个模型的订阅（比如只有OpenAI），务必在config/agent_config.yaml或调用时指定默认模型，否则框架在尝试调用未配置的提供商时会报错。

3. 运行你的第一个智能体任务：

   # 基本用法：框架会自动判断模式、复杂度并选择智能体 python cli/run_agent.py "实现一个快速排序算法，并用Python编写单元测试" # 使用高级参数进行控制 python cli/run_agent.py "审查下面这段代码的安全漏洞：<你的代码>" --mode review --show-routing

CLI参数深度解析：run_agent.py提供了多个参数让你能干预自动决策流程，这在调试或特定场景下非常有用。

• --dry-run：强烈推荐在首次使用或添加新技能后使用。它不会真正调用AI模型，而是打印出组装好的完整提示词上下文。这是你理解框架如何解读你的任务、选择了哪些技能和规则的绝佳方式。
• --show-routing：在输出结果的同时，显示框架内部的路由决策日志，包括检测到的模式、评估的复杂度、选择的模型和智能体。这对验证框架的“理解”是否准确至关重要。
• --mode：手动覆盖自动模式检测。例如，即使你描述了一个编码任务，你也可以强制使用--mode planner来先获得一个实施计划。
• --model：手动指定模型，跳过配置文件的映射。例如--model gpt-4-turbo-preview。
• --multi-agent：强制启用多智能体工作链。对于极其复杂的任务，框架可以安排多个智能体依次协作（如先由planner设计，再由coder实现，最后由reviewer审查）。注意，这会显著增加API调用次数和耗时。

4. 核心模块深度剖析与定制指南

4.1 智能体定义：打造专属的AI角色

智能体是框架的灵魂，它们定义了AI在特定场景下的“人格”和“工作流程”。所有智能体定义都存放在agents/目录下，是简单的Markdown文件。

让我们以agents/coder.md为例，拆解其结构：

# Coder ## Role You are an expert software engineer specializing in writing clean, efficient, and production-ready code. ## Scope - Implementing new features based on specifications. - Refactoring existing code to improve readability or performance. - Translating algorithms or pseudocode into concrete implementations. ## Process 1. **Analyze Requirements**: Clarify any ambiguities in the task. Identify input/output, edge cases. 2. **Choose Patterns**: Select appropriate design patterns, data structures, and libraries. 3. **Write Code**: Implement the solution in the specified language, following best practices. 4. **Add Documentation**: Include clear comments and docstrings for public interfaces. 5. **Self-Review**: Briefly check for obvious errors, style consistency, and adherence to constraints. ## Output Format - Provide the complete code block with correct language tagging. - If the solution is complex, start with a brief explanation of the approach. - After the code, list any assumptions made and potential improvements. ## Constraints - Do not use deprecated or insecure libraries. - Prioritize readability over overly clever one-liners. - If the task is ambiguous, state your assumptions before proceeding.

如何创建一个新的智能体？假设你想增加一个“文档工程师”智能体，专门用于生成API文档。

1. 在agents/目录下创建documenter.md文件。
2. 参照上述模板，填写Role（角色，如“专业的技术文档工程师”）、Scope（范围，如“为函数、类、API端点生成Markdown或OpenAPI格式文档”）、Process（流程，分步骤描述如何分析代码、提取信息、组织文档结构）、Output Format（输出格式，如要求必须包含端点、参数、示例请求/响应）、Constraints（约束，如必须与现有代码风格一致）。
3. 关键一步：修改core/router.py中的模式检测逻辑，将某些与文档相关的关键词（如“generate docs”, “write documentation”, “api spec”）映射到新的模式（比如documentation），并确保该模式在config/agent_config.yaml中指向你的documenter智能体。

4.2 技能系统：模块化的能力注入

技能是附着在智能体之上的具体“工具”或“知识包”。它们以标签系统进行管理，实现了灵活的、按需加载的能力组合。技能文件存放在skills/目录。

一个典型的技能文件skills/build_api.md开头是这样的：

--- tags: [api, rest, endpoint, flask, fastapi, django, express] --- # Skill: Building RESTful APIs ## Objective Guide the agent in designing and implementing well-structured, secure, and scalable REST API endpoints. ## Key Principles 1. **Resource-Oriented**: Use nouns for endpoints (e.g., `/users`, `/posts/{id}`). 2. **HTTP Semantics**: Proper use of GET (read), POST (create), PUT/PATCH (update), DELETE. 3. **Input Validation**: Always validate and sanitize request data. 4. **Error Handling**: Return appropriate HTTP status codes and informative error messages. 5. **Pagination & Filtering**: For list endpoints, support pagination (`limit`, `offset`) and filtering. ## Implementation Checklist - [ ] Define clear request/response schemas (Pydantic, Marshmallow). - [ ] Implement route handlers with proper error try-catch blocks. - [ ] Add authentication/authorization middleware if needed. - [ ] Write API documentation (in-code comments or separate OpenAPI spec). ...

技能匹配机制：当用户输入“如何创建一个用户登录的POST接口？”时，skill_loader.py会提取任务中的关键词（“创建”、“POST”、“接口”），并与所有技能的tags列表进行匹配。tags中包含api、rest、endpoint的build_api.md技能就会被选中，并将其内容注入到上下文中，从而指导AI生成更专业的API代码。

创建自定义技能：如果你想添加一个关于“使用Redis进行缓存”的技能。

1. 在skills/下创建cache_with_redis.md。
2. 在文件开头的Front-matter中，定义相关的tags，例如[cache, redis, performance, database]。
3. 在正文中，详细描述技能的目标、关键原则（如缓存策略、过期时间、缓存击穿处理）、以及一个实现清单或代码示例片段。
4. 完成后，任何涉及缓存或性能优化的任务，只要描述中触发了相关标签，这个技能就会被自动加载。

4.3 配置与路由：控制框架的行为中枢

框架的行为由几个YAML配置文件精细控制，理解它们是进行高级定制的关键。

config/models.yaml：成本与性能的调度表这个文件定义了模式、复杂度与具体AI模型的映射关系。它是一个双层结构。

# config/models.yaml 示例 openai: fast: gpt-3.5-turbo balanced: gpt-4 reasoning: gpt-4-turbo-preview anthropic: fast: claude-3-haiku-20240307 balanced: claude-3-sonnet-20240229 reasoning: claude-3-opus-20240229 # 默认提供商和模型（当自动选择失败时使用） default_provider: openai default_model: gpt-3.5-turbo

你可以根据自己拥有的API订阅和预算来修改这个映射。例如，如果你认为所有reasoning级别的任务都值得使用最好的模型，可以把openai.reasoning改为gpt-4。

config/agent_config.yaml：智能体运行时参数这个文件控制智能体的通用行为参数。

# config/agent_config.yaml 示例 temperature: 0.2 # 较低的温度使输出更确定、更专注，适合编码任务 max_tokens: 4000 # 单次响应的最大token数 timeout: 30 # API调用超时时间（秒） enable_guardrails: true # 是否启用输入/输出护栏 default_mode: general # 当模式检测失败时的回退模式

调整temperature是一个重要的技巧。对于需要创造性解决方案的规划任务，可以适当调高（如0.7）；对于需要精确、可预测代码的编码任务，则应调低（如0.1-0.3）。

路由逻辑定制：core/router.py中的route_task()函数是决策核心。如果你发现框架总是错误地将“优化代码性能”的任务识别为general而不是coding，你可以修改其中的关键词字典或引入更复杂的逻辑（如使用正则表达式或简单的文本分类）。

5. 实战：从零开始构建一个自动化代码审查流水线

理论说得再多，不如动手实践。让我们利用cursor-agents-kit的CLI模式，构建一个简单的自动化代码审查脚本，它可以在每次Git提交前，自动对变更的代码进行安全性和代码风格审查。

5.1 场景设计与脚本编写

我们的目标是：在项目的.git/hooks/pre-commit钩子中，调用框架的CLI，对暂存区（staged）的代码文件进行分析，并输出审查报告。

首先，创建一个Python脚本auto_code_review.py：

#!/usr/bin/env python3 """ Git Pre-commit Hook: 使用cursor-agents-kit自动审查代码。 """ import subprocess import sys import os # 假设cursor-agents-kit项目目录在同级或已知路径 AGENT_KIT_PATH = os.path.join(os.path.dirname(__file__), 'cursor-agents-kit') RUN_SCRIPT = os.path.join(AGENT_KIT_PATH, 'cli', 'run_agent.py') def get_staged_code(): """获取Git暂存区的代码差异。""" try: # 获取暂存区变更的文件列表 result = subprocess.run( ['git', 'diff', '--cached', '--name-only', '--diff-filter=ACM'], capture_output=True, text=True, check=True ) changed_files = [f.strip() for f in result.stdout.split('\n') if f.strip()] if not changed_files: print("No staged files to review.") return None # 获取每个文件的diff内容 diff_content = "" for file in changed_files: if file.endswith(('.py', '.js', '.ts', '.java', '.go')): # 只审查支持的代码文件 diff = subprocess.run( ['git', 'diff', '--cached', '--', file], capture_output=True, text=True, check=True ) if diff.stdout: diff_content += f"\n--- File: {file} ---\n{diff.stdout}\n" return diff_content if diff_content else None except subprocess.CalledProcessError as e: print(f"Error getting git diff: {e}") return None def run_agent_review(code_diff): """调用智能体框架进行代码审查。""" if not os.path.exists(RUN_SCRIPT): print(f"Error: Agent kit not found at {AGENT_KIT_PATH}") return False # 构建任务指令 task = f"""请对以下代码变更进行全面的代码审查，重点关注： 1. 潜在的安全漏洞（如SQL注入、XSS、敏感信息泄露）。 2. 代码风格和一致性（是否符合项目规范）。 3. 明显的逻辑错误或性能问题。 4. 改进建议。 代码变更： {code_diff} """ try: # 使用 --mode review 强制调用审查智能体，并显示路由决策 process = subprocess.run( [sys.executable, RUN_SCRIPT, task, '--mode', 'review', '--show-routing'], cwd=AGENT_KIT_PATH, capture_output=True, text=True, timeout=120 # 设置超时 ) print("=" * 60) print("AI Code Review Report") print("=" * 60) print(process.stdout) if process.stderr: print("\n[Stderr]:", process.stderr) # 你可以在这里解析输出，如果发现严重问题（如安全漏洞）则返回False以阻止提交 # 例如：if "CRITICAL" in process.stdout: return False return True except subprocess.TimeoutExpired: print("Review process timed out.") return True # 超时时不阻止提交，但记录警告 except Exception as e: print(f"Error running agent: {e}") return True def main(): print("Running pre-commit code review with AI agent...") code_diff = get_staged_code() if not code_diff: # 没有需要审查的代码变更，直接通过 sys.exit(0) print(f"Reviewing changes in {len(code_diff.split('--- File:')) - 1} file(s)...") review_passed = run_agent_review(code_diff) if not review_passed: print("\n❌ Code review failed. Please address the issues above before committing.") sys.exit(1) # 非零退出码会阻止git commit else: print("\n✅ AI review passed. Proceeding with commit.") sys.exit(0) if __name__ == '__main__': main()

5.2 配置与集成

1. 放置脚本：将auto_code_review.py脚本放在你的项目根目录或一个专门的scripts/文件夹下。
2. 设置Git钩子：

   # 进入你的项目目录 cd /path/to/your/project # 创建或编辑pre-commit钩子（如果没有.git/hooks目录，先创建） cp /path/to/auto_code_review.py .git/hooks/pre-commit chmod +x .git/hooks/pre-commit # 赋予执行权限

3. 确保环境：确保运行Git钩子的环境（通常是你的本地开发环境）已经安装了cursor-agents-kit的依赖，并且正确配置了.env文件中的API密钥。

5.3 效果验证与优化

现在，当你执行git commit时，钩子会自动触发：

git add some_file.py git commit -m "Add new feature" # 此时会自动运行审查脚本，并在终端输出AI的审查报告。

可能遇到的问题与优化方向：

• 问题：审查时间过长，影响提交体验。
  • 解决：在脚本中限制审查的文件大小或类型，或者只对特定的关键目录（如src/,app/）进行审查。也可以考虑使用--fast模式对应的轻量级模型。
• 问题：AI的审查建议过于琐碎，包含了很多风格建议而非严重问题。
  • 解决：修改agents/reviewer.md智能体的Constraints部分，强调“只报告关键的安全漏洞和逻辑错误，代码风格问题除非严重否则忽略”。或者，在调用CLI时，通过更精确的任务描述来引导AI。
• 问题：希望审查报告以某种格式（如Markdown文件）保存下来。
  • 解决：修改run_agent_review函数，将process.stdout重定向写入到一个文件中（如ai_review_report.md），而不是仅仅打印到终端。

这个实战案例展示了如何将cursor-agents-kit从一个被动的对话工具，转变为一个主动的、可集成到开发工作流中的自动化质量关卡。通过类似的思路，你还可以构建自动生成测试用例、自动编写文档、甚至自动进行简单重构的流水线。

6. 常见问题排查与高级技巧

6.1 故障排除速查表

在实际使用中，你可能会遇到一些典型问题。下表列出了常见问题、原因及解决方法：

6.2 性能优化与成本控制技巧

在长期、高频次使用AI辅助编程时，成本和响应速度是需要权衡的两个核心因素。

1. 分层使用模型：充分利用config/models.yaml的配置。我的策略是：

   • 日常对话、简单代码补全：映射到fast->gpt-3.5-turbo。成本极低，速度飞快。
   • 复杂逻辑实现、代码重构：映射到balanced->gpt-4或claude-3-sonnet。保证质量。
   • 系统架构设计、复杂算法推导：映射到reasoning->gpt-4-turbo或claude-3-opus。仅在必要时使用。 你可以在router.py中根据代码行数、任务关键词的复杂性来自动调整复杂度评估，实现更精细的控制。

2. 优化提示词上下文：context_builder.py组装的提示词可能很长。定期审查agents/、skills/、knowledge/下的Markdown文件，删除冗余信息，保持内容精炼。过长的上下文不仅增加token消耗（成本），也可能导致模型忽略尾部的重要指令。

3. 设置使用配额与缓存：对于团队使用，可以在providers/层添加一个装饰器或中间件，用于记录每个用户/每个项目的API调用次数和token消耗，并设置每日/每月配额。对于常见的、重复性的任务（如“如何写一个Python装饰器？”），可以考虑将高质量的AI回答缓存起来，下次遇到相似问题时直接返回缓存结果。

6.3 扩展框架：添加新的AI模型提供商

框架设计是模型无关的，添加新的提供商（如Google Gemini、本地部署的Llama）非常 straightforward。

以添加Gemini为例：

1. 创建提供商文件：在providers/目录下创建gemini_provider.py。

   # providers/gemini_provider.py import google.generativeai as genai from .base import LLMProvider class GeminiProvider(LLMProvider): def __init__(self, api_key, default_model="gemini-pro"): genai.configure(api_key=api_key) self.client = genai self.default_model = default_model def supports_model(self, model_name): # 检查是否支持该模型，例如 gemini-pro, gemini-ultra return model_name.startswith("gemini-") def invoke(self, prompt, model=None, temperature=0.2, max_tokens=2048, **kwargs): model_name = model or self.default_model if not self.supports_model(model_name): raise ValueError(f"Unsupported model: {model_name}") # 调用Gemini API model_obj = self.client.GenerativeModel(model_name) # 根据Gemini API要求格式化prompt response = model_obj.generate_content( prompt, generation_config=genai.GenerationConfig( temperature=temperature, max_output_tokens=max_tokens, ) ) # 提取文本响应 return response.text

2. 注册提供商：在providers/__init__.py或providers/registry.py中，将你的新提供商类注册到全局的提供商字典中。

   # providers/registry.py from .openai_provider import OpenAIProvider from .anthropic_provider import AnthropicProvider from .gemini_provider import GeminiProvider # 导入新的 PROVIDERS = { "openai": OpenAIProvider, "anthropic": AnthropicProvider, "gemini": GeminiProvider, # 添加注册 }

3. 更新配置：在.env文件中添加你的GEMINI_API_KEY。在config/models.yaml中，添加gemini的模型映射。

   gemini: fast: gemini-pro balanced: gemini-pro reasoning: gemini-ultra

4. 测试：使用--model gemini-pro参数运行CLI，测试新的提供商是否工作正常。

通过以上步骤，你就成功地将框架的能力扩展到了新的AI模型。这种模块化设计使得cursor-agents-kit能够紧跟AI生态的发展，始终保持其灵活性和生命力。