1. 从“写代码”到“定义智能体”一个开发范式的转变最近在折腾各种AI智能体Agent的时候我一直在想一个问题为什么我们构建智能体的方式和写一个传统的软件系统感觉上差异这么大传统的软件开发我们有清晰的架构、可调试的代码、版本控制以及一套成熟的工程化实践。但到了智能体这里很多时候我们像是在“调教”一个黑盒通过自然语言描述、复杂的提示词工程或者拖拽一个流程图来定义它的行为。这个过程充满了不确定性调试困难也难以复用和规模化。直到我开始深入使用Cursor的SDK这种割裂感才被打破。它的核心主张非常吸引我用写代码的方式写Agent。这不仅仅是换了个工具更像是一种思维模式的回归。它把智能体的构建重新拉回到了我们开发者最熟悉、也最擅长的领域——编程。这意味着你可以用函数、类、条件判断、循环、异常处理这些你每天都在用的编程范式来精确地定义一个智能体的决策逻辑、工具调用流程和状态管理。这听起来可能有点抽象但它的实际意义在于它让智能体开发从一种“玄学”般的提示词艺术变成了一种可预测、可测试、可维护的软件工程实践。简单来说Cursor SDK让你能够像编写一个Python库或者一个Web服务后端一样去构建一个具备复杂推理和行动能力的AI智能体。你不再需要把所有的逻辑都塞进一个庞大的、难以维护的提示词里而是可以将其拆解成一个个模块化的“技能”Skills并通过清晰的代码逻辑将它们串联起来。这对于需要处理复杂业务逻辑、要求高可靠性的生产级应用来说是一个游戏规则的改变。接下来我将带你深入这个SDK看看它是如何实现这一点的以及在实际项目中我们该如何用好它。2. Cursor SDK 核心架构将智能体“代码化”要理解“用写代码的方式写Agent”首先得拆解Cursor SDK是如何设计它的核心架构的。它并非一个简单的API封装而是一套完整的、面向对象的智能体编程框架。其设计哲学是一个智能体就是一个状态机它的思考、决策和行动都可以通过代码对象和流程来控制。2.1 核心对象模型Agent, Skill, ToolCursor SDK的基石是几个核心的类它们共同构成了智能体的“身体”和“大脑”。1. Agent 类智能体的本体这是你创建智能体实例的入口。一个Agent对象包含了这个智能体的所有配置它使用哪个大模型如GPT-4o、它的系统提示词角色设定、它的记忆对话历史管理、以及它所能调用的所有“技能”Skills。创建Agent就像初始化一个复杂的服务对象。from cursor import Agent, Model # 初始化一个智能体指定模型和角色 my_agent Agent( modelModel.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方法中执行。这意味着你既可以用代码显式地调用一个Skillawait 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 # 示例包名请以官方文档为准然后我们规划一下这个智能体需要哪些SkillCloneRepoSkill: 克隆目标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, --formatjson, --exit-zero] # --exit-zero 确保即使发现问题也返回成功 try: process await asyncio.create_subprocess_exec( *cmd, stdoutasyncio.subprocess.PIPE, stderrasyncio.subprocess.PIPE ) stdout, stderr await process.communicate() if stderr: self.logger.warning(fflake8 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。结构化输出使用--formatjson让工具输出机器可读的数据便于后续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, encodingutf-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中获取上游SkillAnalyzeCodebaseSkill产出的结构化数据issue并将自己的产出proposed_fix再结构化地存入context供下游SkillApplyFixSkill使用。利用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( modelModel.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(prefixcode_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( modelModel.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(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) async def call_external_api(self, url): async with aiohttp.ClientSession() as session: try: async with session.get(url, timeout10) 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) # ... 处理data4.4 测试策略如何对“AI智能体”进行单元测试测试一个依赖不确定AI模型的系统似乎很矛盾但Cursor SDK的代码化特性让这成为可能。核心思想是隔离测试。测试纯代码逻辑对于Skill中不涉及AI调用的部分如数据处理、格式转换、算法编写标准的单元测试。例如测试AnalyzeCodebaseSkill._summarize_issues方法给定一个模拟的flake8输出检查它生成的摘要格式是否正确。模拟MockAI调用对于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”、“如何管理分布式状态”和“如何确保整个系统的可靠性”——这些都是软件开发中经典且已有成熟模式的问题。