1. 项目概述当AI学会自己修Bug最近在折腾一个挺有意思的东西用Claude的Agent SDK搭了一个能自动修复代码Bug的AI智能体。整个过程比我想象的要简单核心逻辑用20行左右的Python代码就能跑起来。这听起来有点“魔法”但背后其实是Claude API和一套清晰的Agent工作流在支撑。简单来说你给它一个有问题的代码片段和报错信息它就能分析问题、提出修改方案甚至直接生成修复后的代码。对于日常开发中那些琐碎但耗时的语法错误、逻辑小Bug或者只是想快速验证一个修复思路这个工具能省下不少翻文档、查Stack Overflow的时间。我最初的想法很简单能不能让AI把“代码审查”和“即时修复”这两件事自动化尤其是在处理一些遗留代码或者快速原型开发时经常遇到一些低级错误手动修复虽然不难但来回切换上下文很打断思路。Claude Agent SDK正好提供了构建这类“工具使用型”AI助手的框架它能让Claude模型根据你的指令去调用你预先定义好的函数比如运行测试、读取文件然后基于结果再决定下一步动作形成一个自主的工作循环。当然理想很丰满现实在搭建过程中也踩了不少坑。比如如何让Agent准确理解复杂的错误上下文如何设计工具函数让它高效执行以及如何处理那些AI也“拿不准”的边界情况。这篇文章我就来详细拆解这个“自动修Bug Agent”从构思到实现的完整过程包括核心的20行代码逻辑、SDK的关键用法以及那些只有亲手做过才会知道的注意事项和避坑指南。无论你是想快速实现一个类似的效率工具还是对AI Agent的开发流程感兴趣相信都能从中获得一些实用的参考。2. 核心思路与Claude Agent SDK 选型解析2.1 为什么选择Claude Agent SDK构建一个能处理具体任务如修Bug的AI Agent核心是让大语言模型LLM具备“行动力”。它不能只停留在分析和建议层面还需要能真正执行操作、获取反馈并迭代。市面上能让LLM调用外部工具的框架不少比如LangChain、AutoGPT等。我选择Claude Agent SDK主要基于几个实际的考虑第一原生集成与简洁性。Claude Agent SDK由Anthropic官方提供与Claude模型系列如Claude 3 Opus, Sonnet, Haiku的配合度最高。它不需要像LangChain那样引入大量抽象层和概念API设计非常直接。对于“修Bug”这个相对聚焦的场景我需要的是一个轻量、专注的解决方案而不是一个全功能的大框架。SDK的“Agent”和“Tool”两个核心概念刚好够用。第二强大的模型能力基础。修复代码Bug尤其是逻辑错误需要模型有极强的代码理解、推理和生成能力。Claude 3系列模型在代码相关的基准测试上表现一直很出色对上下文的理解深度和指令遵循能力是完成复杂代码任务的关键。SDK让我们能方便地利用这些模型能力。第三可控的成本与效率。自建Agent意味着每一步思考、每一次工具调用都可能产生API费用。Claude Agent SDK的工作流相对透明你可以清晰看到Agent的“思考过程”ReAct模式Reasoning and Acting便于优化提示词和工具设计减少不必要的调用轮次从而控制成本。对于修Bug这种可能涉及多轮交互的任务效率至关重要。第四符合直觉的开发体验。SDK的设计很像在给一个非常聪明的实习生定义工作流程你先告诉它目标“修复这段代码的Bug”然后为它准备一些工具“运行测试”、“读取文件”最后它自己会尝试完成任务并向你汇报。这种模式对于开发者来说非常友好。2.2 自动修Bug Agent的核心工作流设计这个Agent的目标不是解决所有软件工程问题而是处理那些在开发流程中常见的、定义相对清晰的代码缺陷。它的核心工作流我把它设计成一个经典的“诊断-修复-验证”循环输入与诊断用户提供有问题的代码和相关的错误信息运行错误、测试失败输出等。Agent首先分析代码和错误尝试理解Bug的根本原因。这一步完全依赖Claude模型的分析能力。制定修复方案基于诊断结果Agent构思一个或多个修复方案。这可能包括修改语法、调整逻辑、添加异常处理等。执行验证关键工具调用这是Agent“动手”的环节。它需要调用我们预先定义好的工具来验证修复方案。最重要的工具就是“运行代码”。Agent生成一个修复后的代码版本然后通过工具执行它看看错误是否消失或者基本功能是否正常。评估与迭代根据工具执行的结果成功输出、新的报错、测试结果Agent评估修复是否有效。如果问题依旧或出现新问题它将回到第2步基于新的反馈调整修复方案形成循环。输出最终结果当修复被验证有效或者达到最大迭代次数后Agent将总结问题根因并给出最终修复后的代码。这个工作流中“运行代码”这个工具是灵魂所在。它让AI的推理从“空想”落地到“实践”通过真实环境的反馈来修正自己的方案。这也正是编程调试的本质假设-验证-修正。3. 20行核心代码拆解与SDK关键用法下面就是驱动整个Agent的核心代码骨架。虽然实际项目中会有更多的错误处理和工具定义但主干逻辑确实非常简洁。import asyncio from anthropic import Anthropic from anthropic.types import MessageParam from dotenv import load_dotenv import os import subprocess import sys # 1. 加载环境变量存储CLAUDE_API_KEY load_dotenv() # 2. 初始化Claude客户端 client Anthropic(api_keyos.getenv(CLAUDE_API_KEY)) # 3. 定义核心工具运行Python代码并返回结果 def run_python_code(code: str) - str: 在安全隔离的子进程中运行提供的Python代码并捕获输出和错误。 try: # 使用subprocess运行代码设置超时防止死循环 result subprocess.run( [sys.executable, -c, code], capture_outputTrue, textTrue, timeout10, # 10秒超时 encodingutf-8, errorsignore ) output result.stdout if result.stderr: output f\n[STDERR]: {result.stderr} if result.returncode ! 0: output f\n[Process exited with code: {result.returncode}] return output.strip() or (代码执行完毕无输出) except subprocess.TimeoutExpired: return 错误代码执行超时可能包含无限循环。 except Exception as e: return f执行过程异常{str(e)} # 4. 将工具封装成Agent可识别的格式 tools [{ name: run_python_code, description: 在隔离环境中运行一段Python代码字符串并返回执行结果包括标准输出、标准错误和退出码。用于验证代码修改是否正确。, input_schema: { type: object, properties: { code: {type: string, description: 要执行的Python代码字符串} }, required: [code] } }] # 5. 主函数创建Agent并运行任务 async def debug_and_fix_agent(problematic_code: str, error_context: str ): 自动调试和修复Bug的Agent入口函数。 :param problematic_code: 有问题的代码字符串 :param error_context: 可选的错误信息或测试失败输出 # 构建系统提示词定义Agent的角色和规则 system_prompt f你是一个资深的Python调试专家。你的任务是分析和修复用户提供的Bug代码。 用户会提供 1. 有问题的代码。 2. 可能附上运行时的错误信息或期望行为描述。 你的工作流程 1. 仔细分析代码和错误定位Bug的根本原因。 2. 构思修复方案编写修复后的代码。 3. 使用run_python_code工具来运行你修改后的代码验证修复是否有效。 4. 如果运行成功且符合预期总结问题并给出最终代码。 5. 如果运行失败或输出不符分析新错误迭代修改直到成功或达到最大尝试次数。 规则 - 每次调用run_python_code工具时必须提供完整的、可独立运行的代码片段。 - 优先修复导致当前错误的最直接原因。 - 保持代码简洁避免不必要的改动。 - 如果原始代码有缺失的导入或上下文你可以合理地添加它们以使其可运行。 # 构建用户消息 user_message_content f请修复以下Python代码中的Bug 问题代码 python {problematic_code}错误上下文/期望行为 {error_context if error_context else 未提供具体错误请检查代码中的潜在问题如语法错误、逻辑错误等}请开始你的分析并使用工具进行验证。# 创建初始消息 messages: list[MessageParam] [ {role: user, content: user_message_content} ] # 调用Claude Messages API启用工具使用并让Agent自动决定何时调用 response client.beta.tools.messages.create( modelclaude-3-5-sonnet-20241022, # 推荐使用Sonnet或Opus模型以获得更好的推理能力 max_tokens4096, toolstools, systemsystem_prompt, messagesmessages ) # 处理Agent的响应和可能的工具调用 # 注意这是一个简化示例实际需要处理多轮工具调用循环。 # Claude SDK的beta.tools.messages接口支持自动工具调用这里展示第一轮响应。 print(Agent响应:) for block in response.content: if block.type text: print(block.text) # 在实际完整实现中这里需要解析tool_use类型的block并执行对应工具然后将结果追加到messages中再次请求。6. 示例用法ifname main: buggy_code def calculate_average(numbers): total sum(numbers) average total / len(number) # 变量名拼写错误 return averageprint(calculate_average([1, 2, 3, 4, 5])) asyncio.run(debug_and_fix_agent(buggy_code, 运行时报错NameError: name number is not defined))### 3.1 代码逐段解析与SDK核心概念 **第1-2部分初始化** 这是标准操作加载包含CLAUDE_API_KEY的环境变量文件.env并用这个密钥初始化Anthropic客户端。确保你的API Key有足够的权限调用Messages API特别是beta版的tools功能。 **第3部分工具函数定义 - run_python_code** 这是整个Agent的“手”和“眼睛”。它接收一个代码字符串在一个全新的子进程中执行它。 * subprocess.run([sys.executable, -c, code], ...)这里使用当前环境的Python解释器sys.executable来执行代码。-c参数表示后面跟着的是命令行字符串形式的代码。这是一种安全且隔离的执行方式。 * capture_outputTrue, textTrue捕获所有的标准输出和标准错误并以文本形式返回。 * timeout10**至关重要的安全措施**。防止Agent提交一个包含无限循环或死锁的代码导致进程挂起。 * 函数最终将标准输出、标准错误和进程退出码组合成一个字符串返回作为工具执行的结果反馈给Agent。 **注意**这个工具执行环境是高度简化的。在生产环境中你需要考虑更强的安全隔离如Docker沙箱、资源限制CPU/内存以及对敏感操作如文件系统访问、网络请求的严格限制以防恶意代码。 **第4部分工具封装** Claude Agent SDK要求工具必须以特定的JSON Schema格式声明。这个声明告诉Claude模型有一个叫run_python_code的工具可用它需要一个code字符串参数作用是运行代码并返回结果。Agent在“思考”时会根据这个描述决定是否以及如何调用它。 **第5部分主Agent逻辑 - debug_and_fix_agent** 这是协调中心。 * **系统提示词system_prompt**这是指导Agent行为的“宪法”。它定义了Agent的角色Python调试专家、工作流程分析-修复-验证循环和行动规则如每次提供完整代码、优先直接修复。提示词的质量直接决定Agent的表现。写得越清晰、具体Agent就越不容易“跑偏”。 * **用户消息构建**将用户输入的问题代码和错误上下文格式化作为任务描述。 * **API调用client.beta.tools.messages.create**这是Claude支持工具调用的核心API。关键参数是toolstools和systemsystem_prompt。当模型认为需要调用工具时它会在响应内容response.content中返回一个typetool_use的块。**示例代码中只展示了第一轮响应**。完整的实现需要一个循环解析响应 - 如果是工具调用则执行对应函数 - 将工具执行结果作为新的消息追加到对话历史 - 再次调用API直到模型返回纯文本结论。 **第6部分示例** 一个简单的测试用例函数中有一个典型的变量名拼写错误len(number) 应为 len(numbers)。我们同时提供了错误信息帮助Agent快速定位问题。 ### 3.2 如何扩展到多轮工具调用 上面的示例是单次请求。要实现真正的自主循环需要处理多轮交互。逻辑如下 python async def run_agent_with_tool_loop(initial_messages, max_turns5): messages initial_messages for turn in range(max_turns): response client.beta.tools.messages.create( modelclaude-3-5-sonnet-20241022, max_tokens4096, toolstools, systemsystem_prompt, messagesmessages ) # 准备下一轮请求的消息列表先追加本次模型的响应内容 messages.append({role: assistant, content: response.content}) # 检查本次响应中是否有工具调用 tool_use_blocks [b for b in response.content if b.type tool_use] if not tool_use_blocks: # 没有工具调用说明Agent已经给出最终答案结束循环 print(Agent完成工作。) break # 处理每一个工具调用 for tool_block in tool_use_blocks: tool_name tool_block.name tool_input tool_block.input if tool_name run_python_code: tool_result run_python_code(tool_input[code]) else: tool_result f未知工具: {tool_name} # 将工具执行结果作为“用户”消息追加供模型在下一轮分析 messages.append({ role: user, content: [ { type: tool_result, tool_use_id: tool_block.id, # 必须与tool_use块的id对应 content: tool_result } ] }) print(f第 {turn 1} 轮工具调用完成。) # 循环结束后最后一条Assistant消息就是最终结论 return messages这个循环结构是Claude Agent交互的标准模式。tool_use_id必须正确匹配这样模型才知道哪个工具调用返回了哪个结果。4. 实战部署与关键配置详解4.1 环境搭建与依赖安装要让这个项目跑起来你需要准备一个Python环境建议3.9以上并安装必要的包。以下是详细的步骤和说明创建虚拟环境强烈推荐这能避免包版本冲突。python -m venv claude_agent_env # 激活环境 # Windows: claude_agent_env\Scripts\activate # macOS/Linux: source claude_agent_env/bin/activate安装核心依赖除了官方的anthropicSDK我们还需要python-dotenv来管理密钥。pip install anthropic python-dotenvanthropic务必安装最新版本以确保能使用beta.tools.messagesAPI。python-dotenv方便地从.env文件加载环境变量。获取并配置Claude API Key前往Anthropic官网注册并获取API Key。在项目根目录创建一个名为.env的文件注意文件名开头的点。在.env文件中写入CLAUDE_API_KEY你的实际API密钥重要确保.env文件被添加到.gitignore中绝对不要将包含密钥的文件提交到版本控制系统。模型选择在代码中model参数我选择了claude-3-5-sonnet-20241022。这是基于性价比和能力的平衡Claude 3 Opus能力最强推理最深但价格最贵响应可能稍慢。适合处理极其复杂、模糊的Bug。Claude 3.5 Sonnet在智力、速度和成本之间取得了绝佳平衡。对于大多数代码调试任务Sonnet的表现已经非常出色是首选。Claude 3 Haiku最快、最经济但处理复杂逻辑推理时可能深度不足。适合简单的语法错误检查或作为快速验证。4.2 系统提示词System Prompt的工程化设计系统提示词是Agent的“大脑编程”其设计好坏直接决定成败。对于“修Bug”这个任务我经过多次迭代总结出以下几个核心要点1. 明确角色与边界你是一个专注、严谨的Python调试助手。你的唯一目标是修复给定代码中导致特定错误或行为不符的Bug。你不应重写代码以实现新功能除非这是修复Bug所必需的。对于不明确的需求应优先保证代码原有逻辑的正确性。这防止Agent过度发挥把修Bug变成代码重构。2. 定义清晰的工作流程Chain of Thought在提示词中明确写出步骤能显著提升模型推理的条理性和成功率。就像上面示例中的“1.分析2.构思3.验证4.迭代”。3. 设定具体工具使用规则关于工具使用 - 每次调用run_python_code时必须提供**完整、可独立运行**的代码片段。如果需要导入模块请包含导入语句。 - 如果修复涉及多个文件或复杂依赖请先聚焦于创建一个能复现问题的最小可运行示例进行验证。 - 工具执行后请仔细分析输出。如果成功确认输出是否符合预期如果失败根据新的错误信息进行下一轮诊断。这能减少因代码片段不完整而导致的无效工具调用。4. 注入安全与最佳实践意识安全与规范 - 生成的代码不得包含任何可能危害系统安全的内容如无限循环、递归爆炸、尝试访问受限文件或网络。 - 修复应遵循Python的PEP 8风格指南保持代码整洁。 - 在修改时尽量添加注释说明修复的原因。虽然工具层有超时等防护但在模型层面进行约束是另一道防线。5. 处理不确定性如果经过几轮尝试仍无法修复或者你认为Bug可能源于更深层次的设计问题、外部依赖缺失或提供的信息不足请清晰地向用户说明你的分析、已尝试的方案以及需要用户进一步澄清的信息。让Agent学会“求助”而不是无限循环或给出错误答案。4.3 工具函数的安全与健壮性增强基础的run_python_code存在风险。以下是几个必须考虑的增强点1. 资源限制使用resource模块Unix-like系统或psutil库来限制子进程的内存和CPU时间。import resource def set_limits(): # 限制内存为100MB resource.setrlimit(resource.RLIMIT_AS, (100 * 1024 * 1024, 100 * 1024 * 1024)) # 限制CPU时间秒 resource.setrlimit(resource.RLIMIT_CPU, (5, 5)) # 在subprocess.run之前通过preexec_fn在子进程设置 result subprocess.run( [sys.executable, -c, code], ..., preexec_fnset_limits # 仅限Unix-like系统 )注意preexec_fn在Windows上不可用。Windows上可以考虑使用joblib或更复杂的沙箱方案。2. 敏感操作拦截在代码执行前进行简单的静态检查风险较高可能误判。dangerous_patterns [ r__import__\s*\([^)]*os[^)]*\), # 动态导入os r(open|exec|eval|compile)\s*\(, # 危险函数 rimport\s(os|sys|subprocess)\s*, # 导入敏感模块 # ... 其他模式 ] for pattern in dangerous_patterns: if re.search(pattern, code, re.IGNORECASE): return 安全警告代码中包含可能有害的操作已被阻止执行。注意这种方法很初级绕过很容易。最安全的方式还是在Docker等沙箱中运行。3. 使用临时目录与文件隔离如果代码涉及文件操作应在临时目录中运行。import tempfile with tempfile.TemporaryDirectory() as tmpdir: # 将代码写入临时文件或在tmpdir下运行 code_path os.path.join(tmpdir, script.py) with open(code_path, w, encodingutf-8) as f: f.write(code) result subprocess.run([sys.executable, code_path], cwdtmpdir, ...)4. 超时与异常处理示例中已经有了超时但可以更细化比如区分代码编译错误、运行时错误、超时错误等并将更结构化的错误信息返回给Agent帮助它更好地诊断。5. 踩坑记录与实战经验分享在实际搭建和测试过程中我遇到了不少典型问题。这里记录下来希望能帮你绕过这些弯路。5.1 坑一Agent陷入无限循环或无效尝试现象Agent反复调用工具每次只做微小改动但Bug始终无法修复或者在一个错误方向上不断尝试。根因分析系统提示词不够清晰没有明确“成功”的标准或者没有限制最大尝试次数。工具反馈信息模糊如果工具只返回“执行失败”Agent缺乏足够的信息来调整策略。模型“固执己见”有时模型会对某个错误诊断产生“思维定势”难以跳出。解决方案在提示词中明确终止条件例如“最多尝试5次修复。如果5次后仍未成功请总结已尝试的方案和剩余问题并停止调用工具。”丰富工具反馈让run_python_code函数返回更结构化的错误信息。不仅仅是stderr还可以包括异常类型、行号如果可能等。try: # ... 执行代码 return json.dumps({ success: result.returncode 0, stdout: result.stdout, stderr: result.stderr, returncode: result.returncode }) except subprocess.TimeoutExpired: return json.dumps({success: False, error_type: Timeout, message: 执行超时})然后在提示词中告诉Agent“工具将返回一个JSON包含success、stdout、stderr等字段请根据这些信息判断。”引入“强制反思”步骤在提示词中要求在连续失败2次后Agent必须“暂停重新审视最初的错误信息和所有尝试过的方案考虑是否诊断方向有误”。5.2 坑二代码上下文缺失导致修复失败现象用户只提供了一小段有问题的函数Agent生成的修复代码因为缺少必要的导入import或依赖的全局变量而无法运行。根因分析Agent接收到的信息是不完整的。它只能基于你给的片段生成代码而运行工具时需要的是完整、可独立执行的脚本。解决方案用户提供更完整上下文在构建用户消息时引导用户尽可能提供完整的、可运行的脚本或者至少说明依赖的模块和关键变量。Agent智能补全在系统提示词中赋予Agent“合理假设”的权力。例如“如果提供的代码片段缺少必要的导入语句如import math或明显的变量定义你可以在调用工具运行的代码中合理地添加它们以使代码能够执行。但请确保添加的内容是最小且必要的并予以说明。”设计“获取上下文”工具对于更复杂的项目可以设计另一个工具如read_related_file让Agent在需要时主动请求读取项目中的其他相关文件以获取更完整的上下文。这需要更复杂的项目结构感知能力。5.3 坑三安全风险与资源消耗现象测试时Agent生成了一段包含while True:的代码导致工具调用超时或者在未加防护时尝试执行import os; os.system(rm -rf /)之类的危险命令。根因分析LLM本质上是在生成“最可能”的文本它没有恶意但可能生成符合逻辑但危险的代码。如果工具执行环境没有隔离风险极高。解决方案总结与强化沙箱隔离是必须对于任何生产环境或对外服务必须在Docker容器或类似的安全沙箱中运行用户或Agent提供的代码。主进程只与沙箱通信。多层防御提示词约束如上所述在系统提示词中明确禁止危险操作。静态预检执行前进行简单的关键词过滤但要知道这很容易被绕过如getattr(os, system)(...)。运行时限制这是最关键的。必须设置严格的超时、内存限制、CPU时间限制并禁用子进程的网络访问和特定系统调用可通过Seccomp等机制。白名单机制如果场景极度受限可以考虑只允许导入特定的安全模块如math,json,datetime但这会大大限制Agent的能力。监控与日志详细记录每一次工具调用的输入生成的代码和输出。一旦发现异常模式可以及时分析并调整提示词或安全策略。5.4 坑四复杂逻辑Bug修复能力有限现象对于简单的语法错误、变量名错误Agent效果很好。但对于涉及多线程竞争条件、深层算法逻辑错误或需要领域知识的BugAgent可能无法正确修复甚至引入新的Bug。根因分析当前的Agent本质上是基于代码文本和错误信息进行模式匹配和推理。它缺乏对程序“状态”的深入理解也无法进行真正的“调试”如设置断点、单步执行。修复复杂Bug需要更高级的抽象推理和领域知识这仍是AI的挑战。解决方案降低预期明确范围将这个Agent定位为“初级开发助手”或“第一响应者”用于处理明确、简单的错误。将复杂问题转交给人类。提供更丰富的上下文除了错误信息提供相关的日志、输入输出示例、甚至自然语言描述的业务逻辑能极大帮助模型理解问题。结合单元测试设计一个更强大的工具run_unit_test。用户不仅提供问题代码还提供一组失败的单元测试。Agent的目标变为“让所有测试通过”。这为修复提供了更精确、更安全的验证标准。例如你可以把测试框架如pytest集成到工具中。分而治之对于复杂函数可以提示Agent“尝试将函数分解为更小的部分并逐一验证每个部分的正确性。”6. 效果评估与典型应用场景经过大量测试这个自动修Bug的Agent在以下几类场景下表现非常出色1. 语法错误与拼写错误这是它的“舒适区”。比如缺失的冒号、括号不匹配、错误的缩进、未定义的变量/函数名几乎能做到100%识别和修复。2. 简单的运行时异常例如TypeError类型不匹配、IndexError索引越界、KeyError字典键不存在、ZeroDivisionError除零错误等。只要错误信息清晰Agent通常能快速定位并给出修复比如添加类型转换、检查索引范围、使用dict.get()方法、添加零值判断。3. 基础API使用错误比如错误的方法名、参数顺序不对、缺少必需参数。Agent能结合常见库的用法进行纠正。4. 逻辑错误简单一些明显的逻辑疏漏比如循环条件错误导致无限循环、条件判断边界处理不当写成、累加器初始化错误等。5. 代码风格与最佳实践建议虽然主要任务是修Bug但好的提示词可以让Agent在修复的同时提出改进建议比如将魔法数字改为常量、提取重复代码为函数、添加更详细的文档字符串等。它的局限性也很明显需要清晰的错误信号如果代码能运行但结果不对静默错误且没有提供明确的预期结果或测试用例Agent很难发现问题。对复杂架构和设计模式理解有限涉及多个类、模块间复杂交互的Bug修复起来困难。无法处理环境与依赖问题如果Bug是因为缺少某个第三方包或者系统环境变量不对Agent通常无能为力除非你为它提供了检查依赖的工具。“创造性”不足它擅长修复但不擅长基于模糊需求进行创造性的代码编写或重构。一个实用的工作流建议是将Agent集成到你的开发环节中比如作为代码提交前的自动检查工具或者当你在IDE中看到错误时快速将错误片段和报错信息丢给它获取一个修复建议作为参考而不是完全依赖它。它更像一个反应迅速、不知疲倦的初级搭档能帮你处理大量琐碎工作从而让你更专注于更复杂、更有创造性的部分。最后关于成本一次简单的修复通常只需1-2轮工具调用消耗的Token数有限成本极低。但对于复杂的、需要多轮深度推理的任务使用Claude 3 Opus模型可能会产生相对较高的费用。在项目初期建议从Sonnet模型开始并根据实际效果和成本进行调整。记住清晰、具体的提示词是降低无效Token消耗、提升成功率的最有效手段。 基于Claude Agent SDK构建AI自动修Bug智能体：20行核心代码实现
1. 项目概述当AI学会自己修Bug最近在折腾一个挺有意思的东西用Claude的Agent SDK搭了一个能自动修复代码Bug的AI智能体。整个过程比我想象的要简单核心逻辑用20行左右的Python代码就能跑起来。这听起来有点“魔法”但背后其实是Claude API和一套清晰的Agent工作流在支撑。简单来说你给它一个有问题的代码片段和报错信息它就能分析问题、提出修改方案甚至直接生成修复后的代码。对于日常开发中那些琐碎但耗时的语法错误、逻辑小Bug或者只是想快速验证一个修复思路这个工具能省下不少翻文档、查Stack Overflow的时间。我最初的想法很简单能不能让AI把“代码审查”和“即时修复”这两件事自动化尤其是在处理一些遗留代码或者快速原型开发时经常遇到一些低级错误手动修复虽然不难但来回切换上下文很打断思路。Claude Agent SDK正好提供了构建这类“工具使用型”AI助手的框架它能让Claude模型根据你的指令去调用你预先定义好的函数比如运行测试、读取文件然后基于结果再决定下一步动作形成一个自主的工作循环。当然理想很丰满现实在搭建过程中也踩了不少坑。比如如何让Agent准确理解复杂的错误上下文如何设计工具函数让它高效执行以及如何处理那些AI也“拿不准”的边界情况。这篇文章我就来详细拆解这个“自动修Bug Agent”从构思到实现的完整过程包括核心的20行代码逻辑、SDK的关键用法以及那些只有亲手做过才会知道的注意事项和避坑指南。无论你是想快速实现一个类似的效率工具还是对AI Agent的开发流程感兴趣相信都能从中获得一些实用的参考。2. 核心思路与Claude Agent SDK 选型解析2.1 为什么选择Claude Agent SDK构建一个能处理具体任务如修Bug的AI Agent核心是让大语言模型LLM具备“行动力”。它不能只停留在分析和建议层面还需要能真正执行操作、获取反馈并迭代。市面上能让LLM调用外部工具的框架不少比如LangChain、AutoGPT等。我选择Claude Agent SDK主要基于几个实际的考虑第一原生集成与简洁性。Claude Agent SDK由Anthropic官方提供与Claude模型系列如Claude 3 Opus, Sonnet, Haiku的配合度最高。它不需要像LangChain那样引入大量抽象层和概念API设计非常直接。对于“修Bug”这个相对聚焦的场景我需要的是一个轻量、专注的解决方案而不是一个全功能的大框架。SDK的“Agent”和“Tool”两个核心概念刚好够用。第二强大的模型能力基础。修复代码Bug尤其是逻辑错误需要模型有极强的代码理解、推理和生成能力。Claude 3系列模型在代码相关的基准测试上表现一直很出色对上下文的理解深度和指令遵循能力是完成复杂代码任务的关键。SDK让我们能方便地利用这些模型能力。第三可控的成本与效率。自建Agent意味着每一步思考、每一次工具调用都可能产生API费用。Claude Agent SDK的工作流相对透明你可以清晰看到Agent的“思考过程”ReAct模式Reasoning and Acting便于优化提示词和工具设计减少不必要的调用轮次从而控制成本。对于修Bug这种可能涉及多轮交互的任务效率至关重要。第四符合直觉的开发体验。SDK的设计很像在给一个非常聪明的实习生定义工作流程你先告诉它目标“修复这段代码的Bug”然后为它准备一些工具“运行测试”、“读取文件”最后它自己会尝试完成任务并向你汇报。这种模式对于开发者来说非常友好。2.2 自动修Bug Agent的核心工作流设计这个Agent的目标不是解决所有软件工程问题而是处理那些在开发流程中常见的、定义相对清晰的代码缺陷。它的核心工作流我把它设计成一个经典的“诊断-修复-验证”循环输入与诊断用户提供有问题的代码和相关的错误信息运行错误、测试失败输出等。Agent首先分析代码和错误尝试理解Bug的根本原因。这一步完全依赖Claude模型的分析能力。制定修复方案基于诊断结果Agent构思一个或多个修复方案。这可能包括修改语法、调整逻辑、添加异常处理等。执行验证关键工具调用这是Agent“动手”的环节。它需要调用我们预先定义好的工具来验证修复方案。最重要的工具就是“运行代码”。Agent生成一个修复后的代码版本然后通过工具执行它看看错误是否消失或者基本功能是否正常。评估与迭代根据工具执行的结果成功输出、新的报错、测试结果Agent评估修复是否有效。如果问题依旧或出现新问题它将回到第2步基于新的反馈调整修复方案形成循环。输出最终结果当修复被验证有效或者达到最大迭代次数后Agent将总结问题根因并给出最终修复后的代码。这个工作流中“运行代码”这个工具是灵魂所在。它让AI的推理从“空想”落地到“实践”通过真实环境的反馈来修正自己的方案。这也正是编程调试的本质假设-验证-修正。3. 20行核心代码拆解与SDK关键用法下面就是驱动整个Agent的核心代码骨架。虽然实际项目中会有更多的错误处理和工具定义但主干逻辑确实非常简洁。import asyncio from anthropic import Anthropic from anthropic.types import MessageParam from dotenv import load_dotenv import os import subprocess import sys # 1. 加载环境变量存储CLAUDE_API_KEY load_dotenv() # 2. 初始化Claude客户端 client Anthropic(api_keyos.getenv(CLAUDE_API_KEY)) # 3. 定义核心工具运行Python代码并返回结果 def run_python_code(code: str) - str: 在安全隔离的子进程中运行提供的Python代码并捕获输出和错误。 try: # 使用subprocess运行代码设置超时防止死循环 result subprocess.run( [sys.executable, -c, code], capture_outputTrue, textTrue, timeout10, # 10秒超时 encodingutf-8, errorsignore ) output result.stdout if result.stderr: output f\n[STDERR]: {result.stderr} if result.returncode ! 0: output f\n[Process exited with code: {result.returncode}] return output.strip() or (代码执行完毕无输出) except subprocess.TimeoutExpired: return 错误代码执行超时可能包含无限循环。 except Exception as e: return f执行过程异常{str(e)} # 4. 将工具封装成Agent可识别的格式 tools [{ name: run_python_code, description: 在隔离环境中运行一段Python代码字符串并返回执行结果包括标准输出、标准错误和退出码。用于验证代码修改是否正确。, input_schema: { type: object, properties: { code: {type: string, description: 要执行的Python代码字符串} }, required: [code] } }] # 5. 主函数创建Agent并运行任务 async def debug_and_fix_agent(problematic_code: str, error_context: str ): 自动调试和修复Bug的Agent入口函数。 :param problematic_code: 有问题的代码字符串 :param error_context: 可选的错误信息或测试失败输出 # 构建系统提示词定义Agent的角色和规则 system_prompt f你是一个资深的Python调试专家。你的任务是分析和修复用户提供的Bug代码。 用户会提供 1. 有问题的代码。 2. 可能附上运行时的错误信息或期望行为描述。 你的工作流程 1. 仔细分析代码和错误定位Bug的根本原因。 2. 构思修复方案编写修复后的代码。 3. 使用run_python_code工具来运行你修改后的代码验证修复是否有效。 4. 如果运行成功且符合预期总结问题并给出最终代码。 5. 如果运行失败或输出不符分析新错误迭代修改直到成功或达到最大尝试次数。 规则 - 每次调用run_python_code工具时必须提供完整的、可独立运行的代码片段。 - 优先修复导致当前错误的最直接原因。 - 保持代码简洁避免不必要的改动。 - 如果原始代码有缺失的导入或上下文你可以合理地添加它们以使其可运行。 # 构建用户消息 user_message_content f请修复以下Python代码中的Bug 问题代码 python {problematic_code}错误上下文/期望行为 {error_context if error_context else 未提供具体错误请检查代码中的潜在问题如语法错误、逻辑错误等}请开始你的分析并使用工具进行验证。# 创建初始消息 messages: list[MessageParam] [ {role: user, content: user_message_content} ] # 调用Claude Messages API启用工具使用并让Agent自动决定何时调用 response client.beta.tools.messages.create( modelclaude-3-5-sonnet-20241022, # 推荐使用Sonnet或Opus模型以获得更好的推理能力 max_tokens4096, toolstools, systemsystem_prompt, messagesmessages ) # 处理Agent的响应和可能的工具调用 # 注意这是一个简化示例实际需要处理多轮工具调用循环。 # Claude SDK的beta.tools.messages接口支持自动工具调用这里展示第一轮响应。 print(Agent响应:) for block in response.content: if block.type text: print(block.text) # 在实际完整实现中这里需要解析tool_use类型的block并执行对应工具然后将结果追加到messages中再次请求。6. 示例用法ifname main: buggy_code def calculate_average(numbers): total sum(numbers) average total / len(number) # 变量名拼写错误 return averageprint(calculate_average([1, 2, 3, 4, 5])) asyncio.run(debug_and_fix_agent(buggy_code, 运行时报错NameError: name number is not defined))### 3.1 代码逐段解析与SDK核心概念 **第1-2部分初始化** 这是标准操作加载包含CLAUDE_API_KEY的环境变量文件.env并用这个密钥初始化Anthropic客户端。确保你的API Key有足够的权限调用Messages API特别是beta版的tools功能。 **第3部分工具函数定义 - run_python_code** 这是整个Agent的“手”和“眼睛”。它接收一个代码字符串在一个全新的子进程中执行它。 * subprocess.run([sys.executable, -c, code], ...)这里使用当前环境的Python解释器sys.executable来执行代码。-c参数表示后面跟着的是命令行字符串形式的代码。这是一种安全且隔离的执行方式。 * capture_outputTrue, textTrue捕获所有的标准输出和标准错误并以文本形式返回。 * timeout10**至关重要的安全措施**。防止Agent提交一个包含无限循环或死锁的代码导致进程挂起。 * 函数最终将标准输出、标准错误和进程退出码组合成一个字符串返回作为工具执行的结果反馈给Agent。 **注意**这个工具执行环境是高度简化的。在生产环境中你需要考虑更强的安全隔离如Docker沙箱、资源限制CPU/内存以及对敏感操作如文件系统访问、网络请求的严格限制以防恶意代码。 **第4部分工具封装** Claude Agent SDK要求工具必须以特定的JSON Schema格式声明。这个声明告诉Claude模型有一个叫run_python_code的工具可用它需要一个code字符串参数作用是运行代码并返回结果。Agent在“思考”时会根据这个描述决定是否以及如何调用它。 **第5部分主Agent逻辑 - debug_and_fix_agent** 这是协调中心。 * **系统提示词system_prompt**这是指导Agent行为的“宪法”。它定义了Agent的角色Python调试专家、工作流程分析-修复-验证循环和行动规则如每次提供完整代码、优先直接修复。提示词的质量直接决定Agent的表现。写得越清晰、具体Agent就越不容易“跑偏”。 * **用户消息构建**将用户输入的问题代码和错误上下文格式化作为任务描述。 * **API调用client.beta.tools.messages.create**这是Claude支持工具调用的核心API。关键参数是toolstools和systemsystem_prompt。当模型认为需要调用工具时它会在响应内容response.content中返回一个typetool_use的块。**示例代码中只展示了第一轮响应**。完整的实现需要一个循环解析响应 - 如果是工具调用则执行对应函数 - 将工具执行结果作为新的消息追加到对话历史 - 再次调用API直到模型返回纯文本结论。 **第6部分示例** 一个简单的测试用例函数中有一个典型的变量名拼写错误len(number) 应为 len(numbers)。我们同时提供了错误信息帮助Agent快速定位问题。 ### 3.2 如何扩展到多轮工具调用 上面的示例是单次请求。要实现真正的自主循环需要处理多轮交互。逻辑如下 python async def run_agent_with_tool_loop(initial_messages, max_turns5): messages initial_messages for turn in range(max_turns): response client.beta.tools.messages.create( modelclaude-3-5-sonnet-20241022, max_tokens4096, toolstools, systemsystem_prompt, messagesmessages ) # 准备下一轮请求的消息列表先追加本次模型的响应内容 messages.append({role: assistant, content: response.content}) # 检查本次响应中是否有工具调用 tool_use_blocks [b for b in response.content if b.type tool_use] if not tool_use_blocks: # 没有工具调用说明Agent已经给出最终答案结束循环 print(Agent完成工作。) break # 处理每一个工具调用 for tool_block in tool_use_blocks: tool_name tool_block.name tool_input tool_block.input if tool_name run_python_code: tool_result run_python_code(tool_input[code]) else: tool_result f未知工具: {tool_name} # 将工具执行结果作为“用户”消息追加供模型在下一轮分析 messages.append({ role: user, content: [ { type: tool_result, tool_use_id: tool_block.id, # 必须与tool_use块的id对应 content: tool_result } ] }) print(f第 {turn 1} 轮工具调用完成。) # 循环结束后最后一条Assistant消息就是最终结论 return messages这个循环结构是Claude Agent交互的标准模式。tool_use_id必须正确匹配这样模型才知道哪个工具调用返回了哪个结果。4. 实战部署与关键配置详解4.1 环境搭建与依赖安装要让这个项目跑起来你需要准备一个Python环境建议3.9以上并安装必要的包。以下是详细的步骤和说明创建虚拟环境强烈推荐这能避免包版本冲突。python -m venv claude_agent_env # 激活环境 # Windows: claude_agent_env\Scripts\activate # macOS/Linux: source claude_agent_env/bin/activate安装核心依赖除了官方的anthropicSDK我们还需要python-dotenv来管理密钥。pip install anthropic python-dotenvanthropic务必安装最新版本以确保能使用beta.tools.messagesAPI。python-dotenv方便地从.env文件加载环境变量。获取并配置Claude API Key前往Anthropic官网注册并获取API Key。在项目根目录创建一个名为.env的文件注意文件名开头的点。在.env文件中写入CLAUDE_API_KEY你的实际API密钥重要确保.env文件被添加到.gitignore中绝对不要将包含密钥的文件提交到版本控制系统。模型选择在代码中model参数我选择了claude-3-5-sonnet-20241022。这是基于性价比和能力的平衡Claude 3 Opus能力最强推理最深但价格最贵响应可能稍慢。适合处理极其复杂、模糊的Bug。Claude 3.5 Sonnet在智力、速度和成本之间取得了绝佳平衡。对于大多数代码调试任务Sonnet的表现已经非常出色是首选。Claude 3 Haiku最快、最经济但处理复杂逻辑推理时可能深度不足。适合简单的语法错误检查或作为快速验证。4.2 系统提示词System Prompt的工程化设计系统提示词是Agent的“大脑编程”其设计好坏直接决定成败。对于“修Bug”这个任务我经过多次迭代总结出以下几个核心要点1. 明确角色与边界你是一个专注、严谨的Python调试助手。你的唯一目标是修复给定代码中导致特定错误或行为不符的Bug。你不应重写代码以实现新功能除非这是修复Bug所必需的。对于不明确的需求应优先保证代码原有逻辑的正确性。这防止Agent过度发挥把修Bug变成代码重构。2. 定义清晰的工作流程Chain of Thought在提示词中明确写出步骤能显著提升模型推理的条理性和成功率。就像上面示例中的“1.分析2.构思3.验证4.迭代”。3. 设定具体工具使用规则关于工具使用 - 每次调用run_python_code时必须提供**完整、可独立运行**的代码片段。如果需要导入模块请包含导入语句。 - 如果修复涉及多个文件或复杂依赖请先聚焦于创建一个能复现问题的最小可运行示例进行验证。 - 工具执行后请仔细分析输出。如果成功确认输出是否符合预期如果失败根据新的错误信息进行下一轮诊断。这能减少因代码片段不完整而导致的无效工具调用。4. 注入安全与最佳实践意识安全与规范 - 生成的代码不得包含任何可能危害系统安全的内容如无限循环、递归爆炸、尝试访问受限文件或网络。 - 修复应遵循Python的PEP 8风格指南保持代码整洁。 - 在修改时尽量添加注释说明修复的原因。虽然工具层有超时等防护但在模型层面进行约束是另一道防线。5. 处理不确定性如果经过几轮尝试仍无法修复或者你认为Bug可能源于更深层次的设计问题、外部依赖缺失或提供的信息不足请清晰地向用户说明你的分析、已尝试的方案以及需要用户进一步澄清的信息。让Agent学会“求助”而不是无限循环或给出错误答案。4.3 工具函数的安全与健壮性增强基础的run_python_code存在风险。以下是几个必须考虑的增强点1. 资源限制使用resource模块Unix-like系统或psutil库来限制子进程的内存和CPU时间。import resource def set_limits(): # 限制内存为100MB resource.setrlimit(resource.RLIMIT_AS, (100 * 1024 * 1024, 100 * 1024 * 1024)) # 限制CPU时间秒 resource.setrlimit(resource.RLIMIT_CPU, (5, 5)) # 在subprocess.run之前通过preexec_fn在子进程设置 result subprocess.run( [sys.executable, -c, code], ..., preexec_fnset_limits # 仅限Unix-like系统 )注意preexec_fn在Windows上不可用。Windows上可以考虑使用joblib或更复杂的沙箱方案。2. 敏感操作拦截在代码执行前进行简单的静态检查风险较高可能误判。dangerous_patterns [ r__import__\s*\([^)]*os[^)]*\), # 动态导入os r(open|exec|eval|compile)\s*\(, # 危险函数 rimport\s(os|sys|subprocess)\s*, # 导入敏感模块 # ... 其他模式 ] for pattern in dangerous_patterns: if re.search(pattern, code, re.IGNORECASE): return 安全警告代码中包含可能有害的操作已被阻止执行。注意这种方法很初级绕过很容易。最安全的方式还是在Docker等沙箱中运行。3. 使用临时目录与文件隔离如果代码涉及文件操作应在临时目录中运行。import tempfile with tempfile.TemporaryDirectory() as tmpdir: # 将代码写入临时文件或在tmpdir下运行 code_path os.path.join(tmpdir, script.py) with open(code_path, w, encodingutf-8) as f: f.write(code) result subprocess.run([sys.executable, code_path], cwdtmpdir, ...)4. 超时与异常处理示例中已经有了超时但可以更细化比如区分代码编译错误、运行时错误、超时错误等并将更结构化的错误信息返回给Agent帮助它更好地诊断。5. 踩坑记录与实战经验分享在实际搭建和测试过程中我遇到了不少典型问题。这里记录下来希望能帮你绕过这些弯路。5.1 坑一Agent陷入无限循环或无效尝试现象Agent反复调用工具每次只做微小改动但Bug始终无法修复或者在一个错误方向上不断尝试。根因分析系统提示词不够清晰没有明确“成功”的标准或者没有限制最大尝试次数。工具反馈信息模糊如果工具只返回“执行失败”Agent缺乏足够的信息来调整策略。模型“固执己见”有时模型会对某个错误诊断产生“思维定势”难以跳出。解决方案在提示词中明确终止条件例如“最多尝试5次修复。如果5次后仍未成功请总结已尝试的方案和剩余问题并停止调用工具。”丰富工具反馈让run_python_code函数返回更结构化的错误信息。不仅仅是stderr还可以包括异常类型、行号如果可能等。try: # ... 执行代码 return json.dumps({ success: result.returncode 0, stdout: result.stdout, stderr: result.stderr, returncode: result.returncode }) except subprocess.TimeoutExpired: return json.dumps({success: False, error_type: Timeout, message: 执行超时})然后在提示词中告诉Agent“工具将返回一个JSON包含success、stdout、stderr等字段请根据这些信息判断。”引入“强制反思”步骤在提示词中要求在连续失败2次后Agent必须“暂停重新审视最初的错误信息和所有尝试过的方案考虑是否诊断方向有误”。5.2 坑二代码上下文缺失导致修复失败现象用户只提供了一小段有问题的函数Agent生成的修复代码因为缺少必要的导入import或依赖的全局变量而无法运行。根因分析Agent接收到的信息是不完整的。它只能基于你给的片段生成代码而运行工具时需要的是完整、可独立执行的脚本。解决方案用户提供更完整上下文在构建用户消息时引导用户尽可能提供完整的、可运行的脚本或者至少说明依赖的模块和关键变量。Agent智能补全在系统提示词中赋予Agent“合理假设”的权力。例如“如果提供的代码片段缺少必要的导入语句如import math或明显的变量定义你可以在调用工具运行的代码中合理地添加它们以使代码能够执行。但请确保添加的内容是最小且必要的并予以说明。”设计“获取上下文”工具对于更复杂的项目可以设计另一个工具如read_related_file让Agent在需要时主动请求读取项目中的其他相关文件以获取更完整的上下文。这需要更复杂的项目结构感知能力。5.3 坑三安全风险与资源消耗现象测试时Agent生成了一段包含while True:的代码导致工具调用超时或者在未加防护时尝试执行import os; os.system(rm -rf /)之类的危险命令。根因分析LLM本质上是在生成“最可能”的文本它没有恶意但可能生成符合逻辑但危险的代码。如果工具执行环境没有隔离风险极高。解决方案总结与强化沙箱隔离是必须对于任何生产环境或对外服务必须在Docker容器或类似的安全沙箱中运行用户或Agent提供的代码。主进程只与沙箱通信。多层防御提示词约束如上所述在系统提示词中明确禁止危险操作。静态预检执行前进行简单的关键词过滤但要知道这很容易被绕过如getattr(os, system)(...)。运行时限制这是最关键的。必须设置严格的超时、内存限制、CPU时间限制并禁用子进程的网络访问和特定系统调用可通过Seccomp等机制。白名单机制如果场景极度受限可以考虑只允许导入特定的安全模块如math,json,datetime但这会大大限制Agent的能力。监控与日志详细记录每一次工具调用的输入生成的代码和输出。一旦发现异常模式可以及时分析并调整提示词或安全策略。5.4 坑四复杂逻辑Bug修复能力有限现象对于简单的语法错误、变量名错误Agent效果很好。但对于涉及多线程竞争条件、深层算法逻辑错误或需要领域知识的BugAgent可能无法正确修复甚至引入新的Bug。根因分析当前的Agent本质上是基于代码文本和错误信息进行模式匹配和推理。它缺乏对程序“状态”的深入理解也无法进行真正的“调试”如设置断点、单步执行。修复复杂Bug需要更高级的抽象推理和领域知识这仍是AI的挑战。解决方案降低预期明确范围将这个Agent定位为“初级开发助手”或“第一响应者”用于处理明确、简单的错误。将复杂问题转交给人类。提供更丰富的上下文除了错误信息提供相关的日志、输入输出示例、甚至自然语言描述的业务逻辑能极大帮助模型理解问题。结合单元测试设计一个更强大的工具run_unit_test。用户不仅提供问题代码还提供一组失败的单元测试。Agent的目标变为“让所有测试通过”。这为修复提供了更精确、更安全的验证标准。例如你可以把测试框架如pytest集成到工具中。分而治之对于复杂函数可以提示Agent“尝试将函数分解为更小的部分并逐一验证每个部分的正确性。”6. 效果评估与典型应用场景经过大量测试这个自动修Bug的Agent在以下几类场景下表现非常出色1. 语法错误与拼写错误这是它的“舒适区”。比如缺失的冒号、括号不匹配、错误的缩进、未定义的变量/函数名几乎能做到100%识别和修复。2. 简单的运行时异常例如TypeError类型不匹配、IndexError索引越界、KeyError字典键不存在、ZeroDivisionError除零错误等。只要错误信息清晰Agent通常能快速定位并给出修复比如添加类型转换、检查索引范围、使用dict.get()方法、添加零值判断。3. 基础API使用错误比如错误的方法名、参数顺序不对、缺少必需参数。Agent能结合常见库的用法进行纠正。4. 逻辑错误简单一些明显的逻辑疏漏比如循环条件错误导致无限循环、条件判断边界处理不当写成、累加器初始化错误等。5. 代码风格与最佳实践建议虽然主要任务是修Bug但好的提示词可以让Agent在修复的同时提出改进建议比如将魔法数字改为常量、提取重复代码为函数、添加更详细的文档字符串等。它的局限性也很明显需要清晰的错误信号如果代码能运行但结果不对静默错误且没有提供明确的预期结果或测试用例Agent很难发现问题。对复杂架构和设计模式理解有限涉及多个类、模块间复杂交互的Bug修复起来困难。无法处理环境与依赖问题如果Bug是因为缺少某个第三方包或者系统环境变量不对Agent通常无能为力除非你为它提供了检查依赖的工具。“创造性”不足它擅长修复但不擅长基于模糊需求进行创造性的代码编写或重构。一个实用的工作流建议是将Agent集成到你的开发环节中比如作为代码提交前的自动检查工具或者当你在IDE中看到错误时快速将错误片段和报错信息丢给它获取一个修复建议作为参考而不是完全依赖它。它更像一个反应迅速、不知疲倦的初级搭档能帮你处理大量琐碎工作从而让你更专注于更复杂、更有创造性的部分。最后关于成本一次简单的修复通常只需1-2轮工具调用消耗的Token数有限成本极低。但对于复杂的、需要多轮深度推理的任务使用Claude 3 Opus模型可能会产生相对较高的费用。在项目初期建议从Sonnet模型开始并根据实际效果和成本进行调整。记住清晰、具体的提示词是降低无效Token消耗、提升成功率的最有效手段。