从提示词到代码：用工程化思维构建可控AI智能体

1. 从“写代码”到“造智能体”一个开发范式的转变最近和几个做AI应用的朋友聊天发现一个挺有意思的现象大家从年初狂热地“调教”各种大模型聊天机器人到现在开始不约而同地琢磨怎么把AI能力真正“工程化”地嵌入到自己的工作流里。说白了就是不想再一遍遍地复制粘贴提示词而是希望像调用一个函数库一样稳定、可控地使用AI。这让我想起了“Cursor SDK”这个最近在开发者圈子里被频繁提及的工具。它的口号“用写代码的方式写Agent”精准地戳中了这个痛点。这不仅仅是一个新工具更像是一种新思路的宣告智能体Agent的开发应该回归到我们最熟悉的软件工程范式——用代码来定义、构建和迭代。传统的Agent构建无论是基于LangChain、AutoGen还是其他框架很多时候都绕不开对“提示词工程”的重度依赖。你需要精心设计系统提示System Prompt在对话历史Chat History里维护状态通过复杂的链式Chain或工作流Workflow来串联多个步骤。这个过程充满了不确定性调试起来像在解一个黑盒谜题一个标点符号的改动可能就让整个逻辑跑偏。而Cursor SDK提出的“写代码的方式”其核心是将智能体的行为逻辑、记忆状态、工具调用等抽象层从脆弱的自然语言描述转变为强类型、可静态分析、可版本控制的代码。这相当于为AI能力套上了一层可靠的“脚手架”让开发者能像开发一个微服务一样去开发一个智能体。那么它到底适合谁如果你是一个希望将AI能力深度集成到现有产品中的全栈或后端工程师厌倦了在JSON和YAML配置文件中挣扎如果你是一个独立开发者或小团队需要快速构建一个可靠、可维护的自动化助手或者你就是一个对“提示词玄学”感到疲惫渴望更坚实开发体验的AI应用探索者那么Cursor SDK所代表的这种“代码优先”的Agent开发模式值得你花时间深入了解。它试图解决的正是从“玩具演示”到“生产级应用”之间那道关键的工程化鸿沟。2. 核心理念拆解为什么是“写代码的方式”要理解Cursor SDK的价值我们得先跳出工具本身看看它试图解决的根源问题。当前主流的AI应用开发尤其是涉及复杂逻辑和状态的Agent面临几个显著的工程挑战2.1 状态管理的脆弱性一个典型的对话式Agent需要在多轮交互中维持上下文。传统做法是将整个对话历史作为文本传入下一次模型调用。这带来了几个问题历史越长token消耗越大成本越高历史中可能存在大量无关信息干扰模型判断更重要的是状态分散在非结构化的文本中你无法精准地查询或修改某个特定状态比如“用户偏好的主题”。这就像用一个文本文档来管理数据库效率低下且容易出错。2.2 逻辑控制的模糊性用自然语言描述的指令和判断条件例如“如果用户问的是价格就调用查询价格的函数”本质上是模糊的。模型可能会误解也可能在复杂条件下做出不符合预期的分支选择。调试这种逻辑极其困难你无法设置断点也无法进行单元测试只能通过反复的端到端对话来验证效率极低。2.3 工具调用的不确定性让模型学会在合适的时机调用正确的工具函数并传入正确的参数是一个经典难题。尽管有Function Calling这样的技术但参数提取的准确性、工具选择的合理性依然严重依赖提示词的撰写质量。一个参数类型错误就可能导致整个调用失败。Cursor SDK的“代码方式”正是针对这些痛点的系统性回应。它的核心思想是将智能体视为一个由代码明确定义的状态机和逻辑控制器。开发者用代码TypeScript/Python来声明状态State使用强类型的类或接口来定义例如一个UserSession类里面有preferredLanguage: string、queryCount: number这样的字段。状态的变化由代码逻辑直接驱动清晰可控。逻辑Logic使用if/else、switch、循环等标准的程序控制流来决定Agent的行为路径。判断条件基于明确的状态值而非对自然语言的语义分析。工具Tools将外部能力数据库查询、API调用、文件操作封装成标准的函数或方法。Agent“调用工具”的行为转化为对这些函数的同步或异步调用参数传递是类型安全的。这样一来整个Agent的运行轨迹就从一个基于概率的文本生成过程转变为一个可预测、可调试、可测试的确定性程序执行过程。模型如GPT-4的角色从“总指挥”转变为“高级策略顾问”或“自然语言理解器”它负责解析用户的自然语言输入并将其“翻译”成对状态变量的修改建议或触发某个逻辑分支的信号但最终的执行权牢牢掌握在开发者编写的代码手中。3. 核心架构与关键组件实战解析理解了理念我们来看看Cursor SDK具体是如何落地的。虽然其官方文档和API可能迭代但其架构思想是稳定的。我们可以基于常见的开源Agent框架如LangGraph和Cursor的理念构建一个概念模型来进行实操拆解。假设我们正在构建一个“智能技术文档助手”Agent。3.1 状态State的定义与管理状态是Agent的“记忆核心”。在代码中我们首先定义一个强类型的状态结构。// 定义Agent的会话状态 interface DocAssistantState { // 用户信息 userId: string; currentTopic: string; // 当前讨论的技术主题如“React Hooks”、“Docker网络” conversationDepth: number; // 对话深度用于控制解答详细程度 preferredDetailLevel: brief | normal | detailed; // 对话历史结构化而非纯文本 messageHistory: Array{ role: user | assistant | system; content: string; timestamp: Date; // 可以附加元数据如关联的代码片段ID codeSnippetId?: string; }; // 临时上下文 pendingQuery?: string; // 用户尚未被完全解答的问题 referencedDocs: string[]; // 本次会话中已引用过的文档ID }注意这里的状态是“应用状态”不是模型的上下文窗口。我们只将最相关的1-2条消息和必要的状态摘要送入模型绝大部分状态逻辑由代码维护。这极大地减少了token消耗并提升了状态操作的精度。3.2 工具Tools的封装与注册工具是Agent的手和脚。我们需要以模型能理解的方式声明它们并在代码中实现其具体逻辑。// 工具声明用于让模型知道有哪些工具可用 const tools { searchDocumentation: { description: “在知识库中搜索与技术主题相关的文档”, parameters: { query: { type: “string”, description: “搜索关键词” }, limit: { type: “number”, description: “返回结果数量”, default: 5 } }, execute: async (params: { query: string; limit: number }) { // 实际调用内部搜索API或查询向量数据库 const results await internalSearchAPI(params.query, params.limit); return results; } }, fetchCodeExample: { description: “根据主题和语言获取代码示例”, parameters: { topic: { type: “string” }, language: { type: “string”, enum: [“javascript”, “python”, “go”] } }, execute: async (params: { topic: string; language: string }) { ... } }, clarifyQuestion: { description: “当用户问题模糊时生成澄清性问题以获取更多上下文”, parameters: { ambiguousPart: { type: “string” } }, execute: async (params: { ambiguousPart: string }) { // 这里甚至可以再调用一次LLM来生成一个友好的澄清问题 return 您提到的“${params.ambiguousPart}”具体是指哪个方面呢可以举个例子吗; } } };3.3 逻辑Logic与控制流Workflow的编排这是“写代码”精髓的体现。我们不再用自然语言描述“先这样再那样”而是用代码编排一个工作流。// 主Agent工作流函数 async function docAssistantWorkflow(state: DocAssistantState, userInput: string): PromisePartialDocAssistantState { // 1. 解析用户意图调用LLM进行NLU const intent await parseUserIntent(userInput, state.currentTopic); // 2. 基于意图的状态更新和逻辑分支 switch (intent.type) { case ‘query’: // 如果是查询先更新状态 state.currentTopic intent.extractedTopic || state.currentTopic; state.conversationDepth; // 检查是否需要澄清 if (intent.needsClarification) { const clarification await tools.clarifyQuestion.execute({ ambiguousPart: intent.ambiguousPart }); // 将澄清问题存入状态并暂停主流程等待用户回复 state.pendingQuery userInput; return { pendingQuery: userInput, messageHistory: [...state.messageHistory, {role: ‘assistant’, content: clarification}]}; } // 执行搜索 const searchResults await tools.searchDocumentation.execute({ query: state.currentTopic, limit: 3 }); state.referencedDocs.push(...searchResults.map(d d.id)); // 3. 生成回答调用LLM进行合成但给予精确的上下文 const answer await generateAnswer(userInput, searchResults, state.preferredDetailLevel); return { messageHistory: [...state.messageHistory, {role: ‘user’, content: userInput}, {role: ‘assistant’, content: answer}], referencedDocs: state.referencedDocs }; case ‘change_preference’: // 处理用户偏好更改如“请说得详细点” state.preferredDetailLevel ‘detailed’; return { preferredDetailLevel: ‘detailed’ }; case ‘follow_up’: // 处理跟进问题利用已有的 referencedDocs // ... 逻辑类似但搜索范围更窄 break; default: // 兜底逻辑 break; } }这个workflow函数就是一个典型的“代码式”Agent核心。它清晰展示了状态如何被读取和更新、工具如何在确定条件下被调用、不同的执行路径如何被选择。你可以用任何你熟悉的调试工具如VSCode Debugger来单步执行这个函数观察每一个变量的变化这与调试普通程序毫无二致。4. 从零构建一个代码式Agent完整实操流程理论说得再多不如动手建一个。下面我们以构建一个“个人日程管理Agent”为例展示从环境搭建到核心功能实现的完整步骤。我们将使用TypeScript和一个假设的类Cursor SDK框架其思想与LangGraph、DSPy等框架相通来演示。4.1 环境准备与项目初始化首先确保你的开发环境就绪。# 初始化项目 mkdir my-calendar-agent cd my-calendar-agent npm init -y # 安装核心依赖 # 假设我们使用一个提供类似“代码式”抽象的框架‘agent-kit’ npm install agent-kit # 安装LLM SDK例如OpenAI npm install openai # 安装类型定义和开发工具 npm install typescript ts-node types/node --save-dev # 初始化TypeScript配置 npx tsc --init在tsconfig.json中确保设置“target”: “ES2020”,“module”: “commonjs”, 并启用严格模式。4.2 定义状态模型与初始状态在src/state.ts中定义Agent的所有状态。export interface CalendarEvent { id: string; title: string; startTime: Date; endTime: Date; location?: string; participants?: string[]; status: ‘pending’ | ‘confirmed’ | ‘cancelled’; } export interface CalendarAgentState { // 用户身份 userId: string; // 当前处理的日期范围用于上下文 dateContext: { start: Date; end: Date }; // 事件列表 events: CalendarEvent[]; // 临时操作状态 pendingAction?: { type: ‘create’ | ‘update’ | ‘delete’; eventId?: string; draftEvent?: PartialCalendarEvent; }; // 对话历史精简版 lastUserIntent: string; }4.3 实现工具函数在src/tools.ts中封装所有与外部世界交互的能力。这里的关键是工具函数是纯粹的、可测试的代码。import { CalendarEvent } from ‘./state’; // 模拟的日历存储实际中可能是Google Calendar API、数据库等 let mockEventStore: CalendarEvent[] []; export const calendarTools { // 工具1查询事件 queryEvents: { description: “查询指定时间范围内的日历事件”, parameters: { startTime: { type: “string”, format: “date-time” }, endTime: { type: “string”, format: “date-time” } }, execute: async (params: { startTime: string; endTime: string }): PromiseCalendarEvent[] { const start new Date(params.startTime); const end new Date(params.endTime); // 实际这里会有复杂的查询逻辑比如处理时区、重复事件等 return mockEventStore.filter(event event.startTime start event.endTime end event.status ! ‘cancelled’ ); } }, // 工具2创建事件 createEvent: { description: “在日历中创建一个新事件”, parameters: { title: { type: “string” }, startTime: { type: “string”, format: “date-time” }, endTime: { type: “string”, format: “date-time” }, location: { type: “string”, optional: true }, participants: { type: “array”, items: { type: “string” }, optional: true } }, execute: async (params: OmitCalendarEvent, ‘id’ | ‘status’): PromiseCalendarEvent { const newEvent: CalendarEvent { id: event_${Date.now()}, ...params, status: ‘pending’ }; mockEventStore.push(newEvent); console.log(事件创建成功: ${newEvent.title} (ID: ${newEvent.id})); return newEvent; } }, // 工具3解析自然语言时间 parseNaturalLanguageTime: { description: “将‘明天下午两点’这样的自然语言描述解析为具体的日期时间对象”, parameters: { timeExpression: { type: “string” }, referenceDate: { type: “string”, format: “date-time”, optional: true } }, execute: async (params: { timeExpression: string; referenceDate?: string }): Promisestring { // 这里可以集成专门的库如‘chrono-node’ // 简化演示假设我们有一个解析函数 const parsed await mockParseTime(params.timeExpression, params.referenceDate); return parsed.toISOString(); } } }; // 模拟的时间解析函数 async function mockParseTime(expr: string, ref?: string): PromiseDate { // 实际项目中请使用chrono-node等成熟库 if (expr.includes(‘明天’)) { const date new Date(); date.setDate(date.getDate() 1); date.setHours(14, 0, 0, 0); // 下午两点 return date; } // ... 其他解析逻辑 return new Date(); }4.4 编排核心工作流Workflow这是Agent的大脑在src/workflow.ts中实现。import { CalendarAgentState } from ‘./state’; import { calendarTools } from ‘./tools’; import { openai } from ‘./llm-client’; // 假设已初始化的OpenAI客户端 export async function calendarWorkflow(state: CalendarAgentState, userMessage: string): PromisePartialCalendarAgentState { // 第一步使用LLM进行意图识别和关键信息提取 const systemPrompt 你是一个日历助手的意图解析器。请分析用户输入识别意图并提取结构化信息。 可能的意图有QUERY查询日程CREATE创建事件UPDATE修改事件DELETE删除事件CHANGE_CONTEXT更改日期范围。 请以JSON格式回复包含字段intent, extractedFields如title, startTime等。; const completion await openai.chat.completions.create({ model: “gpt-4-turbo”, messages: [ { role: “system”, content: systemPrompt }, { role: “user”, content: userMessage } ], response_format: { type: “json_object” } }); const parsed JSON.parse(completion.choices[0].message.content!); // 第二步根据意图执行确定性的代码逻辑 switch (parsed.intent) { case ‘QUERY’: { // 提取或计算查询时间范围 let start state.dateContext.start; let end state.dateContext.end; if (parsed.extractedFields.timeRange) { // 如果有特定时间范围则解析这里简化 start new Date(parsed.extractedFields.timeRange.start); end new Date(parsed.extractedFields.timeRange.end); } // 调用工具函数查询事件 const events await calendarTools.queryEvents.execute({ startTime: start.toISOString(), endTime: end.toISOString() }); // 准备给LLM的上下文用于生成友好回复 const contextForReply events.map(e ${e.title} at ${e.startTime}).join(‘\n’); // 生成最终回复可以再调用一次LLM但这里为演示直接构造 const reply events.length 0 ? 在您指定的时间段内找到${events.length}个事件\n${contextForReply} : 该时间段内没有找到日程安排。; return { events: events, // 更新状态中的事件列表 lastUserIntent: ‘QUERY’ }; } case ‘CREATE’: { // 提取字段 const { title, naturalLanguageTime } parsed.extractedFields; // 关键步骤使用工具将自然语言时间转为机器时间 const startTimeIso await calendarTools.parseNaturalLanguageTime.execute({ timeExpression: naturalLanguageTime }); // 假设事件时长1小时 const startTime new Date(startTimeIso); const endTime new Date(startTime.getTime() 60 * 60 * 1000); // 调用工具创建事件 const newEvent await calendarTools.createEvent.execute({ title, startTime: startTime.toISOString(), endTime: endTime.toISOString() }); // 更新状态 const updatedEvents [...state.events, newEvent]; return { events: updatedEvents, pendingAction: undefined, // 清空待处理动作 lastUserIntent: ‘CREATE’ }; } // ... 处理UPDATE, DELETE等其他意图 default: // 未知意图返回错误或请求澄清 return { lastUserIntent: ‘UNKNOWN’ }; } }4.5 主循环与状态持久化最后在src/index.ts中创建一个简单的运行循环并考虑状态如何持久化例如存入数据库或文件。import { CalendarAgentState } from ‘./state’; import { calendarWorkflow } from ‘./workflow’; // 初始状态 let currentState: CalendarAgentState { userId: ‘user_001’, dateContext: { start: new Date(‘2024-01-01’), end: new Date(‘2024-12-31’) }, events: [], lastUserIntent: ‘’ }; // 模拟与用户的交互循环 async function runInteraction(userInput: string) { console.log(用户: ${userInput}); // 执行工作流获取状态变更 const stateUpdate await calendarWorkflow(currentState, userInput); // 应用状态变更这里可以用更精细的合并策略 currentState { ...currentState, ...stateUpdate }; // 这里可以根据新的state生成回复或者回复已在workflow中生成 console.log(状态已更新。当前事件数: ${currentState.events.length}); console.log(‘---’); // 在实际应用中你需要将currentState持久化 // await saveStateToDatabase(currentState.userId, currentState); } // 模拟几次交互 (async () { await runInteraction(“我明天下午两点有什么安排吗”); await runInteraction(“帮我创建一个会议主题是‘项目评审’时间定在明天下午两点。”); await runInteraction(“那我后天上午十点忙吗”); })();通过以上步骤一个具备核心功能的“代码式”日历Agent就搭建起来了。你可以清晰地看到每一个步骤都是代码都可以打断点调试都可以写单元测试例如测试calendarWorkflow函数在给定输入和初始状态下是否返回预期的状态更新和工具调用。5. 进阶模式复杂逻辑编排与外部系统集成当你的Agent需要处理更复杂的场景比如多步骤任务、条件判断循环、或与多个外部系统交互时“写代码”的优势会更加明显。我们来看两个进阶模式。5.1 多步骤任务与子工作流假设用户说“帮我安排一个下周的团队周会预订一个会议室并邮件通知所有组员。”这是一个典型的规划-执行型多步骤任务。在传统的提示词方法中你需要写一个非常长的系统提示试图让模型自己规划步骤、记住进度这极易出错。而在代码模式中你可以将其分解为一个明确的状态机和子工作流。interface MeetingSchedulingState { task: ‘schedule_meeting’; step: ‘parse_request’ | ‘find_time_slot’ | ‘book_room’ | ‘send_invites’ | ‘completed’; extractedDetails?: { topic: string; preferredWeek: ‘next_week’; participants: string[]; }; candidateTimeSlots?: Array{ start: Date; end: Date }; bookedRoom?: { name: string; id: string }; invitationSent?: boolean; } async function scheduleMeetingWorkflow(state: MeetingSchedulingState, userInput: string): PromisePartialMeetingSchedulingState { // 根据当前步骤执行不同的逻辑 switch (state.step) { case ‘parse_request’: // 调用LLM解析需求填充extractedDetails // 完成后推进到下一步 return { step: ‘find_time_slot’, extractedDetails: parsedDetails }; case ‘find_time_slot’: // 调用日历API查找所有参与者的共同空闲时间 const slots await findCommonFreeSlots(state.extractedDetails!.participants); // 如果找到推进如果没找到可以创建一个“请求用户选择”的子状态 if (slots.length 0) { return { step: ‘book_room’, candidateTimeSlots: slots }; } else { return { step: ‘ask_user_for_alternative’ }; // 进入另一个处理分支 } case ‘book_room’: // 使用第一个候选时间段尝试预订会议室 const room await bookRoomApi(state.candidateTimeSlots![0]); if (room.success) { return { step: ‘send_invites’, bookedRoom: room.info }; } else { // 预订失败尝试下一个时间段或者回退到上一步 return { step: ‘find_time_slot’, candidateTimeSlots: state.candidateTimeSlots!.slice(1) }; } case ‘send_invites’: // 发送邮件 await sendEmailInvites(state.extractedDetails!.participants, state.bookedRoom!); return { step: ‘completed’, invitationSent: true }; case ‘completed’: // 任务完成可以重置状态或返回总结 return { step: ‘idle’ }; } }这种显式的状态机让复杂任务的进度一目了然并且非常容易实现错误处理和重试逻辑比如会议室订不上就换一个时间。你甚至可以将其可视化方便团队理解和维护。5.2 与现有后端服务的深度集成“代码式”Agent能无缝融入你现有的技术栈。你的工具函数Tools可以直接调用公司内部的RPC服务、数据库ORM、消息队列生产者等。// 工具函数创建JIRA工单 const createJiraTicket { description: “在JIRA项目中创建一个新的任务或Bug工单”, parameters: { ... }, execute: async (params) { // 直接使用公司内部封装好的JIRA客户端SDK const jiraClient new InternalJiraClient(process.env.JIRA_TOKEN); const ticket await jiraClient.createIssue({ project: params.project, summary: params.summary, description: params.description, issueType: params.issueType, // ... 其他字段 }); // 可以触发后续流程如发送Slack通知 await slackClient.postMessage(‘#dev-channel’, 新工单创建: ${ticket.key}); return ticket; } }; // 工具函数查询数据库用户画像 const queryUserProfile { description: “根据用户ID查询其历史行为画像和偏好”, parameters: { userId: { type: “string” } }, execute: async ({ userId }) { // 使用TypeORM、Prisma等ORM直接查询数据库 const userRepo dataSource.getRepository(UserEntity); const profile await userRepo.findOne({ where: { id: userId }, relations: [‘preferences’, ‘recentActivities’] }); return profile; } };这意味着你的Agent可以成为连接AI大脑与公司所有数字资产的桥梁。它不再是一个孤立的聊天界面而是一个深度集成、拥有强大执行能力的智能工作流引擎。6. 避坑指南与性能优化实战经验在实际项目中采用这种模式我积累了一些宝贵的经验教训这里分享几个关键点。6.1 状态设计的黄金法则最小化与结构化最初我们倾向于把很多东西都塞进状态里导致状态对象臃肿且难以维护。后来我们总结出一条法则状态只存储驱动核心逻辑和需要跨轮次记忆的信息。反面例子把整个对话历史几十条消息的原始文本都存进状态。这会导致状态巨大序列化/反序列化慢且难以查询。正面例子只存储结构化摘要。例如在客服Agent中状态里可能只存customerMood: ‘frustrated’ | ‘neutral’ | ‘happy’、openIssues: Array{id: string, type: string}、lastAgentAction: ‘apologized’ | ‘offered_solution’。具体的对话历史可以存到专门的对话存储服务中状态里只留一个conversationId用于关联。6.2 工具调用的错误处理与降级策略工具调用尤其是调用外部API失败是常态。代码式Agent必须要有健壮的错误处理。async function callToolSafely(tool, params, maxRetries 2) { for (let i 0; i maxRetries; i) { try { return await tool.execute(params); } catch (error) { console.error(工具调用失败 (尝试 ${i1}/${maxRetries}):, error.message); if (i maxRetries - 1) { // 最后一次重试也失败返回一个友好的降级结果 return { success: false, error: error.message, fallbackMessage: 暂时无法完成此操作请稍后再试或联系管理员。 }; } // 等待一段时间后重试 await sleep(1000 * Math.pow(2, i)); // 指数退避 } } } // 在工作流中使用 const searchResult await callToolSafely(tools.searchDocumentation, { query: ‘xxx’ }); if (!searchResult.success) { // 根据降级结果更新状态让Agent给出合适的回复 state.lastError searchResult.fallbackMessage; return state; }6.3 LLM调用的成本与延迟优化在代码式架构中LLM通常只用于意图识别、信息提取和最终回复生成。要优化这块的成本和速度分层使用模型对于简单的意图分类可以使用更快、更便宜的模型如GPT-3.5-Turbo。对于需要复杂推理或生成高质量文本的任务再用更强大的模型如GPT-4。在你的工作流代码中可以很容易地根据任务类型切换模型。缓存Caching对于频繁出现的、结果确定的用户查询例如“帮助菜单是什么”可以将LLM的回复缓存起来。可以在调用LLM之前先计算用户输入的哈希值查询缓存。设置超时和回退给LLM调用设置严格的超时例如5秒。如果超时立即使用预定义的、虽然不那么精准但可用的回退逻辑保证Agent的响应性。6.4 测试策略单元测试与集成测试这是代码式Agent相对于提示词Agent最大的优势之一——可测试性。单元测试你可以为每一个工具函数、每一个工作流中的纯函数逻辑编写单元测试。// 测试时间解析工具 test(‘parseNaturalLanguageTime 应正确解析“明天下午两点”’, async () { const result await calendarTools.parseNaturalLanguageTime.execute({ timeExpression: ‘明天下午两点’, referenceDate: ‘2024-05-20T12:00:00Z’ }); expect(new Date(result)).toEqual(new Date(‘2024-05-21T14:00:00Z’)); }); // 测试工作流分支逻辑 test(‘calendarWorkflow 在CREATE意图下应调用createEvent工具’, async () { const mockState { ... }; const mockUserInput “创建会议...”; // 使用Jest等工具mock掉LLM调用和工具调用 jest.spyOn(openai.chat.completions, ‘create’).mockResolvedValue(...); jest.spyOn(calendarTools.createEvent, ‘execute’).mockResolvedValue(...); await calendarWorkflow(mockState, mockUserInput); expect(calendarTools.createEvent.execute).toHaveBeenCalled(); });集成测试/端到端测试模拟用户的一系列对话验证整个Agent的端到端行为是否符合预期。你可以录制这些测试用例作为回归测试套件确保每次更新都不会破坏已有功能。7. 模式对比与未来展望最后我们来对比一下“代码式”Agent与传统“提示词式”Agent并看看未来的可能性。7.1 模式对比表特性维度传统提示词式AgentCursor SDK代表的代码式Agent逻辑控制依赖模型根据提示词“自主”规划模糊、不可预测。由开发者编写的确定性代码控制清晰、可预测。状态管理依赖完整的对话历史上下文冗长、低效、非结构化。使用精炼的结构化状态对象高效、易查询、易修改。调试体验极其困难需反复进行端到端对话观察输出。与调试普通程序无异可使用断点、日志、单元测试。可维护性提示词冗长牵一发而动全身版本管理困难。代码模块化功能解耦可利用Git进行版本控制和协作。执行可靠性工具调用参数易出错复杂流程容易“迷路”。工具调用是类型安全的函数调用复杂流程由状态机明确指引。入门门槛对新手友好快速出原型。需要一定的编程基础学习曲线稍陡。适用场景简单问答、创意生成、一次性任务。复杂多步任务、需要与现有系统集成、高可靠性要求的生产环境。7.2 未来的融合与演进“代码式”不是要完全取代“提示词式”而是提供另一种更工程化的选择。我认为未来会出现更优秀的融合模式低代码/可视化编排在代码式的基础上提供可视化界面来编排工作流和状态机降低非程序员的使用门槛。底层仍然生成可靠、可维护的代码。AI辅助代码生成这正是Cursor编辑器所擅长的。你可以用自然语言描述需求“我需要一个处理用户退货申请的工作流先检查订单状态然后根据政策决定是退款还是换货”让AI生成大致的代码骨架开发者再进行细化和调整。自适应AgentAgent的核心逻辑工作流本身也可以是可学习的。通过记录成功的交互轨迹Agent可以逐步优化自己的工作流结构或参数实现一定程度的自我演进但核心框架仍由代码保证稳定。从我个人的实践来看将Agent的开发拉回代码的轨道带来的最大收益是心理上的踏实感。你知道你的智能助手为什么会那样回答你知道如何修复它的错误你知道如何为它添加新功能。这种可控性和可扩展性是将AI从“炫技的玩具”转变为“可靠的生产力工具”的关键一步。如果你正在构建严肃的、需要长期维护的AI应用那么投入时间掌握这种“写代码的方式”将会是一次非常值得的投资。