Cursor SDK：用代码化思维构建可维护的AI智能体-尧图网络科技

1. 从“写代码”到“定义智能体”：一个开发范式的转变

最近在折腾各种AI智能体（Agent）的时候，我一直在想一个问题：为什么我们构建智能体的方式，和写一个传统的软件系统，感觉上差异这么大？传统的软件开发，我们有清晰的架构、可调试的代码、版本控制，以及一套成熟的工程化实践。但到了智能体这里，很多时候我们像是在“调教”一个黑盒，通过自然语言描述、复杂的提示词工程，或者拖拽一个流程图，来定义它的行为。这个过程充满了不确定性，调试困难，也难以复用和规模化。

直到我开始深入使用Cursor的SDK，这种割裂感才被打破。它的核心主张非常吸引我：用写代码的方式写Agent。这不仅仅是换了个工具，更像是一种思维模式的回归。它把智能体的构建，重新拉回到了我们开发者最熟悉、也最擅长的领域——编程。这意味着，你可以用函数、类、条件判断、循环、异常处理这些你每天都在用的编程范式，来精确地定义一个智能体的决策逻辑、工具调用流程和状态管理。这听起来可能有点抽象，但它的实际意义在于，它让智能体开发从一种“玄学”般的提示词艺术，变成了一种可预测、可测试、可维护的软件工程实践。

简单来说，Cursor SDK让你能够像编写一个Python库或者一个Web服务后端一样，去构建一个具备复杂推理和行动能力的AI智能体。你不再需要把所有的逻辑都塞进一个庞大的、难以维护的提示词里，而是可以将其拆解成一个个模块化的“技能”（Skills），并通过清晰的代码逻辑将它们串联起来。这对于需要处理复杂业务逻辑、要求高可靠性的生产级应用来说，是一个游戏规则的改变。接下来，我将带你深入这个SDK，看看它是如何实现这一点的，以及在实际项目中，我们该如何用好它。

2. Cursor SDK 核心架构：将智能体“代码化”

要理解“用写代码的方式写Agent”，首先得拆解Cursor SDK是如何设计它的核心架构的。它并非一个简单的API封装，而是一套完整的、面向对象的智能体编程框架。其设计哲学是：一个智能体就是一个状态机，它的思考、决策和行动，都可以通过代码对象和流程来控制。

2.1 核心对象模型：Agent, Skill, Tool

Cursor SDK的基石是几个核心的类，它们共同构成了智能体的“身体”和“大脑”。

1. Agent 类：智能体的本体这是你创建智能体实例的入口。一个Agent对象包含了这个智能体的所有配置：它使用哪个大模型（如GPT-4o）、它的系统提示词（角色设定）、它的记忆（对话历史管理）、以及它所能调用的所有“技能”（Skills）。创建Agent就像初始化一个复杂的服务对象。

from cursor import Agent, Model # 初始化一个智能体，指定模型和角色 my_agent = Agent( model=Model.GPT_4O_MINI, # 指定底层模型 system_prompt="你是一个专业的软件工程师助手，擅长代码审查和架构设计。", skills=[], # 初始技能列表，后续可以添加 memory=... # 可配置的记忆模块 )

这里的Model枚举让你可以灵活选择不同能力和成本的模型，这是代码化带来的第一个好处：配置即代码，清晰且可版本控制。

2. Skill 类：模块化的能力单元这是Cursor SDK设计中最精妙的部分。一个Skill代表智能体的一项独立能力。比如，“执行Shell命令”是一个Skill，“读取文件内容”是另一个Skill，“调用某个特定的Web API”也是一个Skill。Skill是可组合、可复用的。

更重要的是，Skill的本质是一个Python类。你可以继承基础的Skill类，重写它的run方法，在里面编写任意的Python逻辑。这个逻辑可以包含对大模型的调用、对工具的调用、或者纯粹的程序计算。

from cursor import Skill from typing import Any, Dict class CodeReviewSkill(Skill): """代码审查技能""" name = "code_review" description = "对给定的代码片段进行审查，指出潜在问题并提出改进建议。" async def run(self, context: Dict[str, Any]) -> str: code_snippet = context.get("code", "") if not code_snippet: return "未提供待审查的代码。" # 这里可以封装一个更复杂的提示词，调用Agent自身的模型进行审查 # 但关键是，这个调用过程被封装在了Skill内部 review_prompt = f""" 请审查以下代码： ```python {code_snippet} ``` 请从代码风格、潜在bug、性能、安全性等方面给出详细审查意见。 """ # 假设我们通过Agent的聊天接口来获取审查结果 # 这展示了Skill如何与Agent的核心能力交互 response = await self.agent.chat(review_prompt) return response.content

通过将能力封装为Skill，我们实现了：

关注点分离：每个Skill只做一件事，并且做好。
可测试性：你可以像测试普通Python函数一样，为每个Skill编写单元测试。
可复用性：写好的Skill可以轻松导入到其他Agent项目中使用。
可维护性：当某个能力需要升级时，你只需要修改对应的Skill类，而不会影响其他部分。

3. Tool 与 Skill 的融合在其他框架中，Tool（工具）通常是一个独立的、用于被大模型调用的函数。在Cursor SDK里，Tool的概念被巧妙地融合进了Skill体系。当你定义一个Skill时，SDK可以自动将其“暴露”给大模型作为一个可调用的工具。模型在思考过程中，如果判断需要某项能力，就会生成调用对应Skill的请求，然后由SDK的路由机制将请求分发到正确的Skill实例的run方法中执行。

这意味着，你既可以用代码显式地调用一个Skill（await my_skill.run(...)），也可以让AI模型在自主推理后隐式地调用它。这种双重接口提供了极大的灵活性。

2.2 执行流程：从自然语言到代码执行

那么，用户的一句自然语言请求，是如何通过这一套代码化架构最终变成行动的呢？这个过程完全由SDK管理，但对开发者是透明的。

请求接收：用户发送消息“帮我审查一下这个函数：def foo(): pass”给Agent。
模型推理：Agent将用户消息和系统提示、历史记录一起，发送给配置的大模型（如GPT-4）。模型会根据它对已注册Skills的描述（name和description），判断是否需要调用某个Skill。在这个例子中，模型会识别出这需要“代码审查”能力。
工具调用生成：模型输出一个结构化的请求，指明要调用code_review这个Skill，并传入参数{"code": "def foo(): pass"}。
SDK路由与执行：Cursor SDK接收到这个结构化请求，在其注册表中找到名为code_review的Skill实例，然后异步调用该实例的run方法，并传入参数。
Skill执行与返回：CodeReviewSkill.run()方法执行。它可能会进行简单的处理，也可能会像上面例子那样，再发起一次对大模型的子调用以完成审查。最终，该方法返回一个字符串结果，例如：“审查意见：函数名foo过于简单，应使用描述性名称...”。
结果整合与回复：SDK将Skill返回的结果再次提交给大模型，模型会生成一个面向用户的、自然的总结性回复：“好的，我已经审查了您的代码。主要问题是函数命名不清晰...”。
状态更新：整个交互过程会被自动记录到Agent的memory中，供后续对话参考。

整个过程的关键在于：作为开发者，你无需关心第2、3、6步中模型是如何思考的。你只需要专注于第4、5步——即用Python代码实现每个Skill的具体逻辑。你把智能体的“肌肉”（行动能力）用代码定义好，把“大脑”（推理决策）交给大模型。这种分工使得系统既灵活又可靠。

3. 实战：构建一个代码分析与自动修复智能体

理论说得再多，不如动手实践。我们来构建一个相对复杂的智能体：一个能够分析代码仓库、识别问题、并能自动尝试修复的“AI工程师”。这个例子将串联起多个Skill，并展示如何用代码控制复杂的工作流。

3.1 项目初始化与环境配置

首先，确保你已安装Cursor SDK（假设通过pip安装）并准备好API密钥（这里指Cursor或你所集成的AI模型服务商密钥）。

pip install cursor-sdk # 示例包名，请以官方文档为准

然后，我们规划一下这个智能体需要哪些Skill：

CloneRepoSkill: 克隆目标Git仓库到临时目录。
AnalyzeCodebaseSkill: 静态分析代码库，找出可能的问题（如未使用的变量、简单的语法风格问题）。
ProposeFixSkill: 针对某个具体问题，生成修复建议（代码补丁）。
ApplyFixSkill: 尝试应用修复建议，并运行测试验证修复是否有效。
CreatePullRequestSkill: 如果修复成功，创建一个Pull Request。

3.2 核心Skill的代码实现

我们重点实现其中两个最具代表性的Skill，来展示代码化的威力。

Skill 1: AnalyzeCodebaseSkill - 静态分析这个Skill将使用像pylint、flake8这样的命令行工具，或者libcst、ast这样的Python库来分析代码。我们选择用subprocess调用flake8，因为它输出格式规范。

import asyncio import tempfile import subprocess from pathlib import Path from cursor import Skill from typing import List, Dict, Any import json class AnalyzeCodebaseSkill(Skill): name = "analyze_codebase" description = "使用静态分析工具扫描代码仓库，找出代码风格问题和潜在错误。" async def run(self, context: Dict[str, Any]) -> str: repo_path = context.get("repo_path") if not repo_path or not Path(repo_path).exists(): return "错误：提供的仓库路径无效。" # 使用flake8进行分析，输出格式为JSON以便解析 cmd = ["flake8", repo_path, "--format=json", "--exit-zero"] # --exit-zero 确保即使发现问题也返回成功 try: process = await asyncio.create_subprocess_exec( *cmd, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE ) stdout, stderr = await process.communicate() if stderr: self.logger.warning(f"flake8 stderr: {stderr.decode()}") if stdout: analysis_results = json.loads(stdout.decode()) # 对结果进行整理和摘要 summary = self._summarize_issues(analysis_results, repo_path) # 将详细结果也存入context，供后续Skill使用 context["detailed_issues"] = analysis_results return summary else: return "静态分析完成，未发现任何问题。" except subprocess.CalledProcessError as e: return f"静态分析过程出错：{e}" except json.JSONDecodeError as e: return f"解析分析结果时出错：{e}" def _summarize_issues(self, results: List[Dict], repo_path: str) -> str: """将flake8的JSON结果转换为易读的摘要""" issue_count = len(results) if issue_count == 0: return "✅ 代码分析完成，未发现任何风格或语法问题。" # 按错误类型分类 error_codes = {} for issue in results: code = issue.get("code", "UNKNOWN") error_codes[code] = error_codes.get(code, 0) + 1 summary_lines = [f"🔍 代码分析完成，共发现 {issue_count} 个潜在问题："] for code, count in sorted(error_codes.items()): summary_lines.append(f" - {code}: {count} 处") summary_lines.append("\n主要问题分布：") # 取前5个最常出现的问题示例 for issue in results[:5]: rel_path = Path(issue["filename"]).relative_to(repo_path) summary_lines.append(f" {rel_path}:{issue['line_number']} - [{issue['code']}] {issue['text']}") summary_lines.append(f"\n（详细报告已保存，可供后续修复步骤使用）") return "\n".join(summary_lines)

为什么这么设计？

异步执行：使用asyncio.create_subprocess_exec避免在调用外部命令时阻塞整个Agent。
结构化输出：使用--format=json让工具输出机器可读的数据，便于后续Skill处理。这是工程化的关键——Skill之间通过结构化的context字典传递数据，而不是纯文本。
错误处理：捕获子进程异常和JSON解析异常，确保Skill失败时有明确的错误信息返回，而不是让整个Agent崩溃。
日志记录：通过self.logger记录警告信息，便于调试。

Skill 2: ProposeFixSkill - AI驱动的修复建议生成这个Skill将利用大模型的能力，针对具体问题生成修复代码。这里展示了如何在一个Skill内部，再次利用Agent的对话能力。

class ProposeFixSkill(Skill): name = "propose_fix" description = "针对特定的代码问题，生成具体的修复建议和代码补丁。" async def run(self, context: Dict[str, Any]) -> str: issue = context.get("issue") # 假设issue是一个包含文件、行号、错误信息的字典 if not issue: return "错误：未提供具体的问题描述。" file_path = issue.get("filename") line_num = issue.get("line_number") error_code = issue.get("code") error_text = issue.get("text") # 读取有问题的文件内容 try: with open(file_path, 'r', encoding='utf-8') as f: file_content = f.read() except Exception as e: return f"无法读取文件 {file_path}: {e}" # 构建一个非常具体的提示词，引导模型生成修复 prompt = f""" 你是一个代码修复专家。请修复以下代码片段中的一个问题。 **文件路径**: {file_path} **问题位置**: 第 {line_num} 行 **问题类型**: {error_code} **问题描述**: {error_text} **原始代码文件内容**: ``` {file_content} ``` **你的任务**: 1. 首先，理解上述 `{error_code}` 错误的具体含义。 2. 然后，聚焦于第 {line_num} 行及其上下文，分析导致此问题的根本原因。 3. **生成一个具体的代码补丁**。请使用统一的“差异（diff）”格式输出，就像`git diff`那样，清晰地展示需要修改的行。 4. 在补丁之后，用一两句话简要解释你的修复方案。 **输出格式要求**: 首先输出“```diff”标记，然后是你的diff补丁，最后以“```”标记结束。补丁之后是你的解释。 请确保补丁是精确的、可直接应用的。 """ # 使用Agent自身的聊天能力来获取修复建议 # 注意：这里直接使用了agent.chat，这是Skill类中可用的一个便捷方法。 response = await self.agent.chat(prompt) model_proposal = response.content # 将模型生成的建议存储起来 context["proposed_fix"] = { "file": file_path, "line": line_num, "diff_patch": model_proposal # 这里可能包含diff块和解释文本 } return f"已针对 `{file_path}` 的第 {line_num} 行问题 (`{error_code}`) 生成修复建议。\n\n{model_proposal}"

这个设计的精妙之处：

提示词工程代码化：复杂的提示词被直接写在Python字符串中，你可以使用多行字符串、f-string嵌入变量，甚至从外部文件读取模板。这比在UI里编辑大段文本要易于管理和版本控制得多。
Skill间协作：它从context中获取上游Skill（AnalyzeCodebaseSkill）产出的结构化数据（issue），并将自己的产出（proposed_fix）再结构化地存入context，供下游Skill（ApplyFixSkill）使用。
利用Agent自身能力：self.agent.chat()的调用展示了Skill如何与承载它的Agent进行交互，将AI推理能力作为一个子服务来调用。

3.3 编排工作流：用代码控制智能体行动序列

有了这些Skill，我们如何让Agent按顺序执行它们？这里有两种模式，体现了“代码化”的灵活性。

模式一：显式流程控制（推荐用于复杂、确定性的流程）在这种模式下，开发者完全掌控流程。我们写一个主函数，像编排普通函数调用一样编排Skill的执行。

import asyncio from cursor import Agent, Model from pathlib import Path import shutil async def main(): # 1. 初始化智能体 agent = Agent( model=Model.GPT_4O_MINI, system_prompt="你是一个全栈AI工程师，负责自动化代码质量检查和修复。", skills=[CloneRepoSkill(), AnalyzeCodebaseSkill(), ProposeFixSkill(), ApplyFixSkill()] # 初始化时注册所有Skill ) repo_url = "https://github.com/example/some-repo.git" temp_dir = tempfile.mkdtemp(prefix="code_review_") try: # 2. 显式调用CloneRepoSkill clone_ctx = {"repo_url": repo_url, "target_dir": temp_dir} clone_result = await agent.skills["clone_repo"].run(clone_ctx) print(f"克隆结果: {clone_result}") if "失败" in clone_result: raise Exception("仓库克隆失败") # 3. 显式调用AnalyzeCodebaseSkill analysis_ctx = {"repo_path": temp_dir} analysis_result = await agent.skills["analyze_codebase"].run(analysis_ctx) print(f"分析结果:\n{analysis_result}") # 假设我们从analysis_ctx中获取到了第一个严重问题 first_critical_issue = analysis_ctx.get("detailed_issues", [])[0] if first_critical_issue: # 4. 针对第一个问题，显式调用ProposeFixSkill fix_proposal_ctx = {"issue": first_critical_issue} fix_proposal = await agent.skills["propose_fix"].run(fix_proposal_ctx) print(f"修复建议:\n{fix_proposal}") # 5. 显式调用ApplyFixSkill apply_ctx = {"proposed_fix": fix_proposal_ctx.get("proposed_fix")} apply_result = await agent.skills["apply_fix"].run(apply_ctx) print(f"应用结果: {apply_result}") # ... 可以循环处理更多问题 finally: # 清理临时目录 if Path(temp_dir).exists(): shutil.rmtree(temp_dir) print("临时目录已清理。") if __name__ == "__main__": asyncio.run(main())

模式二：AI驱动的工作流（用于探索性、非确定性的任务）在这种模式下，我们赋予Agent更高的自主权。我们只给它一个高级目标，并注册所有可用的Skill，让它自己决定何时调用哪个Skill。

async def main_ai_driven(): agent = Agent( model=Model.GPT_4O, system_prompt="""你是一个自主的代码仓库维护AI。你的目标是分析和改进给定的代码仓库。 你可以克隆仓库、分析代码问题、生成修复方案、应用修复并验证。 请根据情况，自主决定使用哪些工具，并按合理的顺序执行任务。 在开始前，请先与我确认你要执行的操作计划。""", skills=[CloneRepoSkill(), AnalyzeCodebaseSkill(), ProposeFixSkill(), ApplyFixSkill(), CreatePullRequestSkill()] ) # 我们只需要给Agent一个目标指令 user_request = "请分析并尝试自动修复仓库 https://github.com/example/some-repo.git 中的代码质量问题，如果修复成功且通过测试，就创建一个Pull Request。" # 启动对话，Agent会开始规划并自主调用Skill response = await agent.chat(user_request) print("Agent回复:", response.content) # 后续可以通过agent.chat()继续对话，引导或询问进度

两种模式的对比与选择：

显式控制：流程确定，易于调试和测试，适合对结果有严格要求的自动化流水线。缺点是需要开发者事先设计好所有步骤。
AI驱动：更加灵活，能处理未预见的场景，适合探索性任务或需求不明确的场景。缺点是执行过程可能不可预测，调试困难，成本也可能更高（因为需要更多的模型调用进行规划）。

在实际项目中，我常常采用混合模式：对于核心的、确定性的步骤（如克隆、分析、应用补丁），用显式代码控制；对于其中需要创造力的子任务（如“生成有意义的PR描述”），则交给AI自主完成。

4. 高级技巧与避坑指南

在深度使用Cursor SDK构建了多个生产相关的智能体后，我积累了一些非常重要的经验和教训。这些是你在官方文档里可能看不到的“坑”和“最佳实践”。

4.1 Skill设计的“单一职责”与“纯净性”原则

这是最重要的设计原则。一个Skill应该只做一件事，并且尽可能“纯净”。

反面教材：一个名为AnalyzeAndFixSkill的Skill，它既运行静态分析，又调用模型生成修复，还尝试应用修复。这样的Skill难以测试（你需要模拟所有环节），一个环节出错整个Skill就失败了，而且无法被复用（比如另一个流程可能只需要分析，不需要修复）。
正确做法：拆分成AnalyzeCodebaseSkill、ProposeFixSkill、ApplyFixSkill三个Skill。每个Skill功能单一，接口清晰。AnalyzeCodebaseSkill的输出就是问题列表，ProposeFixSkill的输入是单个问题，输出是补丁。这样，你可以单独测试分析工具的准确性，也可以单独测试模型生成补丁的质量。

纯净性指的是Skill应尽量减少副作用和对全局状态的依赖。Skill的run方法应该主要依赖于其输入参数（context），并明确地返回输出或修改context。避免在Skill内部修改文件系统、数据库等全局状态时不做声明，也避免依赖一些隐式的全局变量。这能让你的Skill像乐高积木一样，在任何工作流中都能可靠地运行。

4.2 Context字典：Skill间的通信总线与状态管理

context字典是Skill之间传递数据的唯一标准方式。用好它是关键。

命名空间规划：为了避免键名冲突，建议为每个Skill定义其使用的键名前缀或采用嵌套字典。例如，AnalyzeCodebaseSkill可以将详细结果存入context["analysis"]["detailed_issues"]，而ProposeFixSkill将建议存入context["fix_proposal"]["patch_for_issue_xyz"]。
序列化友好：存入context的数据应该是JSON可序列化的（字符串、数字、列表、字典）。如果你需要传递一个复杂的对象（比如一个打开的文件句柄或数据库连接），考虑传递一个标识符（如文件路径、记录ID），让下游Skill自己去获取。或者，设计一个专门的ResourceManagerSkill来管理这类资源。
生命周期意识：context通常在一次任务链中存活。明确哪些数据是临时中间结果，哪些是最终产出。对于大型数据（如整个代码库的AST），考虑是否真的需要在整个链中传递，或许只传递一个路径引用更高效。

4.3 错误处理与智能体鲁棒性

智能体在复杂环境中运行，错误是常态。必须为每个Skill设计健壮的错误处理。

Skill内部的错误处理：如我们之前在AnalyzeCodebaseSkill中做的，用try...except捕获所有可能的异常（子进程错误、文件IO错误、网络错误等）。不要静默吞掉异常，而是应该返回一个清晰的错误信息字符串，或者抛出一个自定义的、可识别的异常。
Agent层面的错误处理：当Agent在自主模式下调用Skill失败时，SDK通常会捕获异常并将错误信息反馈给模型。模型可能会尝试其他方法或向用户求助。在显式控制模式下，你需要在调用每个Skill后检查其结果，决定工作流是继续、重试还是终止。
设置超时与重试：对于可能耗时的Skill（如调用外部API），一定要在调用时设置超时（asyncio.wait_for）。对于因网络抖动导致的暂时性失败，可以实现简单的重试逻辑。

import asyncio from tenacity import retry, stop_after_attempt, wait_exponential class RobustAPISkill(Skill): @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10)) async def call_external_api(self, url): async with aiohttp.ClientSession() as session: try: async with session.get(url, timeout=10) as response: response.raise_for_status() return await response.json() except asyncio.TimeoutError: self.logger.error(f"调用 {url} 超时") raise except aiohttp.ClientError as e: self.logger.error(f"调用 {url} 网络错误: {e}") raise async def run(self, context): data = await self.call_external_api("https://api.example.com/data") # ... 处理data

4.4 测试策略：如何对“AI智能体”进行单元测试？

测试一个依赖不确定AI模型的系统似乎很矛盾，但Cursor SDK的代码化特性让这成为可能。核心思想是：隔离测试。

测试纯代码逻辑：对于Skill中不涉及AI调用的部分（如数据处理、格式转换、算法），编写标准的单元测试。例如，测试AnalyzeCodebaseSkill._summarize_issues方法，给定一个模拟的flake8输出，检查它生成的摘要格式是否正确。
模拟（Mock）AI调用：对于Skill中调用self.agent.chat或直接调用模型API的部分，使用unittest.mock库进行模拟。你可以预设模型的返回内容，从而测试Skill在收到特定AI响应后的处理逻辑是否正确。
集成测试关注流程：编写集成测试，将几个Skill串联起来，但同样用模拟的AI响应。测试的重点是Skill之间的数据传递（context）是否正确，整个工作流是否能按预期步骤走完。
“黄金标准”测试：对于AI生成内容的质量，很难用断言测试。可以采用“黄金标准”对比法：保存一组标准输入和期望的高质量输出。在测试中，用相同的输入调用Skill，将AI的实际输出与“黄金标准”进行相似度比较（如使用BLEU、ROUGE分数或嵌入向量余弦相似度），设置一个阈值来判断本次输出是否可接受。这更适合在CI/CD中作为回归测试，而不是严格的单元测试。

4.5 性能与成本优化

当你的智能体变得复杂，频繁调用大模型时，成本和延迟会成为问题。

技能路由优化：在Agent的system_prompt中清晰、简洁地描述每个Skill的用途。模糊的描述会导致模型困惑，错误地调用Skill或进行不必要的多轮思考。描述要像API文档一样精确。
分层模型使用：并非所有任务都需要最强的模型。你可以在Agent初始化时使用一个能力强但贵的模型（如GPT-4），但对于一些简单的、模式固定的子任务，可以在对应的Skill内部，显式地使用一个更小、更快的模型（如GPT-3.5-Turbo或Claude Haiku）来完成。这需要对SDK进行一些扩展，允许Skill指定自己使用的模型客户端。
缓存：对于确定性较高的AI调用（例如，对同一段代码的静态分析问题，其修复建议很可能是相同的），可以考虑在Skill层面加入缓存机制。将提示词和参数哈希作为键，将模型的输出缓存起来（可以放在内存缓存如redis，或磁盘上），短期内相同的请求直接返回缓存结果，能大幅降低成本和延迟。
批量处理：在显式控制流程中，如果有一大批类似的任务（如修复100个类似的代码风格问题），不要一个个地调用ProposeFixSkill。可以设计一个BatchProposeFixSkill，它接受一个问题列表，构造一个批处理提示词让模型一次性生成多个修复建议，或者内部使用并发来同时处理多个问题，但要注意模型的并发限制和令牌数限制。

5. 超越基础：用SDK构建复杂多智能体系统

Cursor SDK不仅适用于单个智能体。它的代码化本质使得编排多个智能体协同工作变得异常清晰。你可以构建一个“智能体团队”，每个成员负责专门领域，由一个“协调员”智能体或你的主控代码来调度。

设想一个更复杂的场景：一个自动化漏洞修复系统。

智能体A（侦察兵）：使用SASTSkill（静态应用安全测试）扫描代码，找出潜在漏洞。
智能体B（分析员）：针对侦察兵找到的每个漏洞，使用VulnerabilityAnalysisSkill深入分析其可利用性和危害等级。
智能体C（修复专家）：对于高等级漏洞，使用SecureFixProposalSkill生成安全补丁。这个Skill可能需要专门训练或使用安全领域的微调模型。
智能体D（测试员）：使用TestFixSkill应用补丁，并运行安全测试套件和单元测试，验证修复没有引入回归问题。
智能体E（项目经理）：一个“元智能体”，它不直接处理代码，而是接收用户指令（如“修复仓库X中的所有高危漏洞”），然后通过代码调用或规划，协调A、B、C、D的工作流，并最终向用户汇报总结。

在这个架构中，每个智能体都是一个独立的Agent实例，拥有自己专门的Skill组。它们之间的通信可以通过共享的context（在一个更高层的工作流中），或者通过消息队列（如Redis Streams）来实现。协调员智能体（或你的主程序）的工作，就是编写业务流程代码，实例化这些智能体，并在正确的时机调用它们的相应方法。

这种“多智能体系统”的代码，看起来就像一个微服务架构的编排脚本，每个服务（智能体）职责明确，接口定义清晰（Skill的输入输出）。这彻底将智能体应用开发，从提示词魔术提升到了软件工程的高度。你会发现，最大的挑战不再是“如何让AI理解我要它做什么”，而是“如何设计清晰的服务边界和API”、“如何管理分布式状态”和“如何确保整个系统的可靠性”——这些都是软件开发中经典且已有成熟模式的问题。