从工具调用到多智能体协作：6大开源项目解析代码智能体构建心法-平芜编程栈

1. 从“对话框”到“工程伙伴”的认知跃迁

最近在开发者圈子里，Claude Code 的热度居高不下。很多朋友拿到手的第一反应，就是把它当成一个更聪明的“代码对话框”——遇到报错贴进去，想写个函数描述一下需求，或者把一段看不懂的代码扔给它求解释。这么做当然有用，但说实话，有点暴殄天物了。这就好比给你一台顶级工作站，你却只用来刷网页。

Claude Code，或者说这一类“代码智能体”（Code Agent），其真正的潜力远不止于此。它们不是简单的问答机器，而是能够理解复杂上下文、自主规划任务、调用工具并执行操作的“AI工程师”雏形。当你只把它当对话框用时，你是在手动驾驶；而当你以“智能体”的思维去构建和调用它时，你才开启了自动驾驶模式，让它能独立处理一个完整的开发子任务，比如“为这个API添加鉴权中间件”或“修复这个模块中的所有类型错误”。

这个认知的转变，是效率提升的关键。但空谈概念没用，怎么落地？最好的学习方法，就是去拆解那些已经跑起来的、优秀的开源项目。它们就像一个个活生生的标本，展示了智能体如何被设计、如何与开发环境交互、以及如何解决真实问题。下面，我就结合 GitHub 上 6 个极具代表性的项目，带你彻底吃透“代码智能体”的构建心法。我们会从最简单的工具调用开始，逐步深入到复杂的多智能体协作框架，让你不仅能“用”，更能“造”。

2. 智能体的基石：从“会说话”到“会动手”的质变

在深入项目之前，我们必须先厘清一个核心概念：是什么让一个AI从“聊天机器人”变成了“智能体”？关键在于“工具调用”（Tool Calling）和“规划与执行”（Planning & Execution）能力。

当你对 Claude Code 说“写一个快速排序函数”时，它生成代码，你复制粘贴，这是聊天模式。智能体模式则是：你给它一个高级指令，比如“优化项目根目录下的src/utils/里的数据清洗模块性能”。一个合格的代码智能体需要能：

规划：理解指令，拆解为子任务（如：先定位文件、分析现有代码、识别性能瓶颈、提出优化方案、实施修改）。
感知：读取指定目录的文件列表和内容，理解项目结构。
执行：调用“文件读写”、“代码分析”、“运行测试”等工具，具体地修改代码。
验证：运行测试或检查语法，确保修改无误。

这个过程完全由AI自主驱动，无需你在每个步骤进行人工干预。而实现这一切的桥梁，就是一套定义良好的工具API。智能体通过函数调用（Function Calling）来使用这些工具。例如，一个基础的代码智能体工具集可能包括：

# 一个简化的工具定义示例（基于 OpenAI 风格） tools = [ { "type": "function", "function": { "name": "read_file", "description": "读取指定路径文件的内容", "parameters": { "type": "object", "properties": { "file_path": {"type": "string", "description": "文件的相对或绝对路径"} }, "required": ["file_path"] } } }, { "type": "function", "function": { "name": "write_file", "description": "将内容写入指定路径的文件，会覆盖原有内容", "parameters": { "type": "object", "properties": { "file_path": {"type": "string", "description": "文件的相对或绝对路径"}, "content": {"type": "string", "description": "要写入的文件内容"} }, "required": ["file_path", "content"] } } }, { "type": "function", "function": { "name": "run_command", "description": "在项目根目录执行 shell 命令", "parameters": { "type": "object", "properties": { "command": {"type": "string", "description": "要执行的命令，如 'npm test' 或 'ls -la'"} }, "required": ["command"] } } } ]

有了这些工具，AI模型（如 Claude 3.5 Sonnet）在思考时，如果认为需要读取文件，它就会在回复中输出一个结构化的“函数调用请求”，而不是自然语言。我们的程序接收到这个请求后，执行真正的read_file函数，将结果（文件内容）再塞回给AI，让它继续下一步思考。这个过程循环往复，直到任务完成或无法继续。

注意：工具的定义至关重要。description字段要清晰明确，它直接决定了AI是否能正确理解和使用该工具。参数设计也要尽可能周全，比如run_command就要考虑工作目录、环境变量等问题。

所以，评价一个代码智能体项目好不好，第一个要看的就是它的工具生态是否丰富、安全、易用。接下来我们要看的项目，都在这一点上做出了卓越的探索。

3. 项目深潜一：Cursor-Agent —— IDE集成的典范

项目定位：Cursor 编辑器内置的智能体，代表了最贴近开发者工作流的“贴身助理”模式。

虽然 Cursor-Agent 并非完全开源的独立项目，但其设计理念和实现方式（通过 Cursor 编辑器暴露）是理解IDE集成型智能体的绝佳案例。它完美诠释了“智能体即功能”的思想。

核心机制剖析： Cursor-Agent 深度嵌入在 VSCode 内核的 Fork 中，这意味着它拥有无与伦比的上下文感知能力：

全量代码库索引：它不是在对话时才去看文件，而是在后台持续为整个项目（或你指定的部分）建立语义索引。当你提出“修改登录逻辑”时，它瞬间就能定位到所有相关的控制器、服务、模型和测试文件。
完整的IDE操作工具集：它的工具不是简单的文件读写，而是直接映射到IDE操作。
- editor.openFile：打开并聚焦到某个文件的特定行。
- editor.applyDiff：应用一个差异补丁，这是比直接覆写更安全、可预览的修改方式。
- terminal.run：在项目集成终端中运行命令，并能捕获输出。
- search.symbol：在项目内搜索符号（类、函数、变量名）。
交互式工作流：它很少一气呵成地完成复杂任务，而是采用“规划-执行-确认”的循环。例如，它可能会先为你列出它计划修改的三个文件及其大致改动，问你“是否继续？”。在修改过程中，如果遇到模糊不清的地方（比如两个同名函数），它会停下来问你选择哪一个。

实操心得与避坑指南：

优势：开箱即用，上下文感知最强，安全边界清晰（所有操作通过IDE界面确认或自动生成Diff审查），适合日常编码辅助和中小型重构。
局限：耦合度高，无法脱离Cursor编辑器使用。对于超大型项目，建立索引可能消耗较多资源和时间。
一个关键技巧：在向 Cursor-Agent 发出复杂指令时，学习“分步描述”。不要直接说“重写整个认证模块”，而是尝试“第一步，分析当前auth/目录下的所有文件，找出基于Session的认证逻辑；第二步，设计一个替换为JWT的方案，并列出需要修改的文件清单；第三步，逐一实现修改”。这更符合它的交互式工作流，成功率更高。

Cursor-Agent 展示了智能体作为“增强型IDE功能”的终极形态。但对于想要更灵活、可编程、能集成到CI/CD流水线中的开发者来说，我们需要更底层的框架。这就是下一个项目的价值所在。

4. 项目深潜二：OpenDevin —— 开源界的“全栈AI工程师”

项目定位：一个旨在复现甚至超越 Devin（知名AI软件工程师）的开源项目，目标是创建一个能够端到端处理完整软件工程任务的自主智能体。

OpenDevin 的野心很大，它不满足于仅仅修改代码，而是试图涵盖从理解需求、规划、编码、调试到最终提交的完整生命周期。它的架构非常值得研究。

核心架构拆解： OpenDevin 采用了一种经典的智能体架构，核心是“规划器（Planner）- 执行器（Executor）”循环，并辅以丰富的工作空间（Sandbox）管理。

规划器：通常由一个强大的LLM（如Claude 3 Opus或GPT-4）驱动。它接收用户指令（如“在项目里添加一个用户注册页面”），并将其分解成一个具体的任务列表（Task List）。每个任务可能对应一个“命令”（Command）。
命令系统：这是OpenDevin工具集的抽象。它定义了一系列原子操作，例如：
- BashCommand：执行shell命令。
- FileReadCommand/FileWriteCommand：文件操作。
- AgentThinkCommand：让智能体“思考”下一步（输出分析、计划等自然语言）。
- IPythonRunCellCommand：运行Python代码块（用于数据分析等任务）。
执行器与工作空间：执行器负责运行规划器产生的命令。最关键的是，所有这些命令都在一个隔离的Docker容器工作空间中执行。这保证了安全性（不会破坏宿主机）和可复现性。工作空间内预装了常见的开发工具（git, python, node等）。
状态管理与记忆：智能体有长期记忆（存储对话和工作历史）和短期记忆（当前任务上下文）。它能记住之前执行过的命令和结果，用于后续决策。

从源码看设计思想：浏览 OpenDevin 的agent和commands目录，你能清晰地看到它是如何将抽象的“智能”转化为具体“行动”的。以添加一个依赖为例：

规划器分析后，可能生成一个BashCommand: “npm install lodash”。
执行器在Docker工作空间中运行此命令。
运行结果（成功或错误日志）被捕获，并连同当前工作空间的文件状态变化一起，反馈给规划器。
规划器根据结果决定下一步：如果成功，继续下一个任务（如引入lodash到代码中）；如果失败（如网络问题），则可能尝试换源或报告错误。

实操心得与避坑指南：

部署考量：OpenDevin 对资源要求较高，需要能运行Docker，并且调用LLM API（如OpenAI, Anthropic）会产生费用。自部署时，网络稳定性是关键，因为工作空间容器需要拉取基础镜像。
指令的艺术：给 OpenDevin 的指令需要更加“工程化”。明确指定技术栈、项目结构偏好、甚至测试要求，会得到更好的结果。例如：“使用React + TypeScript，在src/components/下创建一个UserRegistrationForm组件，需包含邮箱、密码验证，并配套一个Storybook文件。”
安全边界：虽然工作在容器内，但赋予它BashCommand权限仍需谨慎。不建议在包含敏感信息或核心业务代码的环境中使用。最好先在一个干净的临时项目中进行测试。
处理“卡住”：复杂的任务可能导致智能体进入循环或无关操作。OpenDevin 通常有超时机制，但作为用户，学会观察其思考过程（Log），并在适当时机通过提示进行干预或调整任务描述，是必备技能。

OpenDevin 代表了通用型代码智能体的前沿，但它可能过于“重型”。很多时候，我们只需要一个轻量、专注的智能体来处理特定问题。这时，就需要看看那些“术业有专攻”的项目。

5. 项目深潜三：Smol-Agent / Aider —— 轻量化与专注化的代表

项目定位：这类项目追求极简哲学，用最少的代码和配置，快速构建一个能完成特定编码任务的智能体。Smol-Agent 和 Aider 是其中的佼佼者，它们放弃了“全栈工程师”的幻想，专注于“代码编辑助手”这一核心职能。

Smol-Agent 的精髓：如其名“Smol”（小），它的代码库非常简洁。它的核心思想是：提供最必要的工具（读、写、运行），搭配一个清晰的提示词（Prompt）模板，然后让一个强大的LLM（如Claude 3 Haiku）去驱动。它没有复杂的规划器，更多依靠LLM自身的推理和规划能力。

它的工作流可以概括为：

初始化：将用户指令、项目相关文件（通过全局或手动指定）的上下文喂给LLM。
循环： a. LLM 决定下一步做什么（思考、读文件、写文件、运行命令）。 b. 执行该操作。 c. 将结果追加到对话历史中。 d. 重复，直到LLM认为任务完成或无法进行。
输出：最终给出修改总结。

它的强大在于其提示词工程，其中明确规定了智能体的角色、目标、约束和操作格式。这种设计使得它极其容易理解和定制。

Aider 的独特价值： Aider 与 Smol-Agent 理念类似，但它有一个“杀手级”特性：与本地Git仓库的深度集成。Aider 不仅修改代码，还自动帮你生成有意义的、原子化的Git提交（Commit）。

核心工作流程：

你启动 Aider，指向一个Git仓库。
你提出需求，比如“给这个函数添加错误处理”。
Aider 分析代码，进行修改。
修改完成后，Aider 会自动执行git diff，并让LLM为这些改动生成一个简洁的提交信息，然后询问你是否要提交。
如果你同意，它就完成git add和git commit。

这个功能看似简单，却极大地改变了开发习惯。它鼓励了“小步快跑”的迭代方式，并且保持了清晰可追溯的版本历史。Aider 相当于把你的代码编辑器和版本管理工具用AI智能体无缝衔接了起来。

实操心得与避坑指南：

选择依据：如果你需要快速原型验证，或者处理的任务相对独立、明确，Smol-Agent 这种轻量级方案是首选。如果你的工作流严重依赖Git，并且希望AI的每次修改都能形成可追溯的记录，Aider 是绝配。
上下文管理是关键：轻量级智能体没有全局索引，它们所知的“上下文”完全取决于你喂给它的文件。因此，手动为它提供关键文件至关重要。例如，在让Aider修改一个函数前，最好先把该函数所在的文件、其依赖的头文件/接口文件都通过聊天界面“送”给它。Aider 有/add命令来方便地做这件事。
避免上下文过载：不要一次性把整个项目塞给LLM，会耗尽Token且降低效果。精准地提供相关文件。
善用“检查点”：在开始一系列复杂修改前，先让Aider帮你提交一次，创建一个“检查点”。如果后续的AI修改跑偏了，你可以轻松地git reset回这个点，而不是手动回滚一堆混乱的更改。

轻量级智能体让我们看到了“专注”的力量。但当问题变得极其复杂，需要不同专长的“AI专家”会诊时，我们就需要更高级的架构——多智能体系统。

6. 项目深潜四：MetaGPT / ChatDev —— 多智能体协作的工厂模式

项目定位：这些框架模拟了一个软件公司或团队的协作流程，通过定义多个具有不同角色（如产品经理、架构师、程序员、测试员）的AI智能体，让他们通过对话和协作来完成从创意到成品的软件开发。

这完全超越了“单个AI编辑代码”的范畴，进入了“AI组织管理”的层面。MetaGPT 和 ChatDev 是这一领域的明星项目。

MetaGPT 的运行机制： MetaGPT 的核心是“标准化操作程序”（SOP）。你给它一个需求，比如“开发一个贪吃蛇游戏”，它会自动启动以下流程：

产品经理（Product Manager）智能体：根据需求，撰写一份包含用户故事、竞品分析、需求列表的PRD（产品需求文档）。
架构师（Architect）智能体：根据PRD，设计系统架构图，选择技术栈，定义模块和接口。
项目经理（Project Manager）智能体：根据架构，拆解任务，生成任务列表和API规范。
工程师（Engineer）智能体：领取任务，开始编写代码。它拥有读、写、运行测试的工具。
测试工程师（QA Engineer）智能体：编写测试用例，对生成的代码进行测试，并报告Bug。
审查者（Reviewer）智能体：对代码进行审查，提出改进意见。

所有这些智能体通过一个共享的“消息队列”进行通信。每个智能体在行动时，都能看到之前相关角色的输出。例如，工程师在写代码时，会参考架构师的设计图和项目经理的API文档。

ChatDev 的简约之美： ChatDev 的理念与 MetaGPT 类似，但更强调通过智能体间的“对话”（Chat）来驱动进化。它的角色设定可能包括CEO、CTO、程序员、测试员等。其流程设计得像一场研讨会：

设计阶段：智能体们讨论技术方案，达成共识。
编码阶段：程序员智能体编码，其他角色可以提出疑问或建议。
测试阶段：测试员智能体运行代码，报告错误。
修复阶段：程序员根据错误进行修复，可能引发新的讨论。

这个过程会循环迭代，直到所有智能体对产出满意为止。

实操心得与避坑指南：

适用场景：这类框架最适合从零开始的绿色项目，或者有非常明确、独立功能模块的项目。它擅长的是“生成”而非“修改”复杂的现有系统。用来快速生成项目脚手架、原型、算法Demo或小型工具非常强大。
成本与耗时：多智能体意味着多次LLM API调用，完成一个简单项目也可能需要几十甚至上百次交互，时间和金钱成本显著高于单智能体。它更像一个“演示”或“创意加速”工具，而非日常生产工具。
可控性与调试：当输出不符合预期时，调试多智能体系统是困难的。你需要追踪整个对话链，看是哪个角色的理解出现了偏差。因此，初始的需求描述必须极其清晰、无歧义。
一个实用技巧：不要一开始就追求完美流程。可以先运行一个最小闭环，比如只启用“产品经理”和“工程师”两个角色，快速出一个草稿。然后基于这个草稿，再逐步引入“架构师”、“测试员”进行优化和补充。这能帮你控制成本和迭代方向。

多智能体框架展示了AI在复杂任务协调上的潜力，但对于大多数开发者日常面对的“在现有代码库中工作”的场景，我们还需要一种能深刻理解庞大、复杂代码结构的智能体。这就是代码库专家智能体的用武之地。

7. 项目深潜五：GPT Engineer / Clippy — 代码库专家与“学习型”智能体

项目定位：这类项目专注于让智能体成为某个特定代码库的“专家”。它们通过预先对代码库进行深入的分析、索引和总结，使智能体在回答问题和执行修改时，能拥有远超单次对话上下文的、对项目整体结构的理解。

GPT Engineer 的“学习”阶段： GPT Engineer 的经典模式包含两个阶段：

学习/索引阶段：你指向一个代码库，它会遍历所有文件，读取内容，并可能生成每个文件/模块的摘要、理清模块间的依赖关系、提取关键的类和方法定义。这些信息被结构化的存储起来，形成项目的“知识图谱”或“摘要数据库”。
问答/执行阶段：当你提出问题时（如“这个支付模块是如何处理退款异常的？”），智能体不是去实时搜索所有文件，而是先查询它预先构建的“摘要数据库”，快速定位到相关模块，再根据需要去精读具体的代码文件。这大大提高了处理大型项目的效率和准确性。

Clippy 的深度集成：这里说的 Clippy 不是 Office 助手，而是一些实验性项目（名称可能变化）中提到的概念，它指的是深度集成在IDE中、能对当前编辑会话进行持续学习的智能体。

会话级记忆：它能记住你在本次编程会话中创建或修改的所有文件、函数和变量。
实时推理：当你写一个新函数时，它能根据刚刚看过的你写的其他函数，推断出你可能的编码风格和意图，给出更精准的补全或建议。
跨文件理解：你正在A.py中调用B.py里的函数，它能同时理解这两个文件的上下文，确保建议的兼容性。

这种智能体不再是“一问一答”，而是成为了一个拥有“短期工作记忆”的结对编程伙伴。

实操心得与避坑指南：

索引的代价与收益：为大型代码库建立索引可能耗时很长（几分钟到几十分钟），并且会消耗大量LLM Token（用于生成摘要）。但这笔“一次性投资”对于需要长期维护该项目的人来说是值得的，因为它能换来后续极高的问答和修改效率。
摘要质量决定上限：索引阶段生成的摘要质量至关重要。过于简略会丢失关键信息，过于冗长则浪费资源且降低检索效率。好的项目会采用分层摘要策略：项目级概述、模块级说明、文件级功能描述、关键函数签名等。
动态更新问题：代码库是活的，会不断变更。如何增量式更新索引，而不是每次全量重建，是一个工程挑战。一些高级实现会监听文件系统变化，或者与Git钩子结合，在每次提交后更新受影响文件的摘要。
使用策略：对于新接手的、结构复杂的历史项目，先用这类工具跑一遍全量索引，然后让它为你生成一份项目架构报告，是快速上手的“作弊器”。在日常开发中，则更适合用来回答那些涉及多个模块的、架构性的问题，而不是简单的语法修改。

从对话到工具调用，从单智能体到多智能体协作，再到代码库专家，我们看到了智能体能力的层层递进。然而，要让这些智能体真正可靠地工作，还有一个无法回避的底层挑战：如何让它们稳定、高效地执行代码？这引出了最后一个关键项目类别。

8. 项目深潜六：E2B / Windsurf — 安全沙箱与云端工作空间

项目定位：为AI智能体提供安全、可复现、功能完整的代码执行环境。这是所有“会动手”的代码智能体赖以生存的基础设施。E2B（原名E2B Code Interpreter）和 Windsurf 是这方面的专业解决方案。

为什么需要专门的执行环境？想象一下，你让一个AI智能体去修复一个Bug，它给出的方案是运行rm -rf /或者pip install一个恶意包。在你自己电脑上直接执行这些命令是灾难性的。因此，沙箱隔离是首要需求。其次，智能体需要环境的一致性。它写的代码在它“想象”的环境里能运行，但在你的本地可能因为依赖版本、系统库不同而失败。因此，需要可配置、可复现的环境。最后，一些智能体操作（如安装依赖、启动服务）可能耗时较长，或者需要GPU资源。一个托管式的、可随时创建销毁的云端工作空间就非常合适。

E2B 的核心能力： E2B 提供了一个云服务API，你可以瞬间启动一个包含指定语言和工具链（如Python, Node.js, Go）的容器环境。智能体通过API向这个环境发送执行指令（如Bash命令、Python代码），并获取结果（输出、错误、甚至生成的文件）。它的特点是：

安全隔离：每个环境都在独立的容器中，进程、文件系统、网络都是隔离的。
预装丰富：环境预装了从编译器、解释器到常用CLI工具（git, curl, vim等）的整套开发套件。
文件持久化：在会话期间，工作空间内的文件变化可以保留，支持多轮交互式操作。
资源可控：可以限制CPU、内存使用量。

Windsurf 的集成体验： Windsurf 更进一步，它试图提供一个“云端IDE”级别的体验。它通常提供一个Web界面，你可以在浏览器中直接看到一个文件浏览器、终端和代码编辑器。AI智能体可以在这个界面中自由操作，就像它是一个真实的远程开发机。这对于演示、教育或需要复杂交互的任务非常有用。

实操心得与避坑指南：

成本意识：云工作空间按运行时间计费。虽然单次执行成本很低，但如果你构建的智能体频繁创建环境或长时间运行，费用会累积。在设计智能体时，要考虑环境的复用和及时销毁。
网络与权限：沙箱环境通常有出网限制。如果你的任务需要访问外部API或下载资源，要确保沙箱网络策略允许，或者预先在环境镜像中配置好代理和凭证（需注意安全）。
状态管理难题：智能体的多次操作需要在同一个环境中保持状态（如已安装的包、已修改的文件）。你需要精心设计会话管理逻辑，确保智能体在后续步骤中能连接到正确且状态一致的环境。
超时与错误处理：智能体执行的命令可能挂起或失败。你的后台服务需要有健全的超时机制和错误捕获逻辑，并将清晰的错误信息反馈给智能体，让它能调整策略。
作为开发工具：即使不构建AI智能体，E2B这类服务本身也是强大的工具。你可以用它来安全地运行不可信的代码片段、构建在线的代码评测系统、或者作为CI/CD中一个干净的测试环境。

9. 构建你自己的代码智能体：从模仿到创造

看完上面六个各具特色的项目，你可能已经摩拳擦掌，想打造一个属于自己的智能体了。别急，我们先来梳理一下思路，避免从入门到放弃。

第一步：明确你的核心需求这是最重要的。不要一开始就追求大而全。问自己几个问题：

场景：是用于日常编码辅助（像Cursor），还是自动化特定任务（如自动生成API文档），或是教育/演示（像ChatDev）？
集成度：需要深度嵌入现有IDE/工作流，还是作为一个独立的命令行工具或Web服务？
能力范围：只需要编辑代码文件，还是需要运行命令、安装依赖、执行测试？
代码库规模：主要针对单个文件、小型项目，还是需要理解拥有数十万行代码的大型遗留系统？

你的答案将直接决定技术选型。例如，一个只为个人在小型项目上做重构的智能体，用 Smol-Agent 模式足矣；而要做一个能处理公司内部复杂中间件的智能体，就必须考虑 GPT Engineer 那样的代码库索引能力。

第二步：技术栈选型与组合现在，你可以像搭积木一样，从上述项目中汲取灵感：

大脑（LLM）：Claude 3.5 Sonnet 在代码和推理上目前是顶级选择，但成本较高。GPT-4o、DeepSeek Coder 也是强有力的候选。对于简单任务，Claude 3 Haiku 或 GPT-3.5-Turbo 性价比更高。关键：根据任务复杂度权衡效果与成本。
骨架（框架/模式）：
- 轻量任务型：直接借鉴 Smol-Agent 或 Aider 的简洁架构。一个主循环，一个工具列表，一个精心设计的系统提示词（Prompt）。
- 复杂任务型：参考 OpenDevin 的规划器-执行器模式。规划器LLM用能力强的模型（如Sonnet），执行器逻辑自己实现。
- 代码库专家型：引入向量数据库（如Chroma, Pinecone）存储代码片段嵌入，或像 GPT Engineer 一样用LLM生成结构化摘要。在智能体行动前，先进行语义检索，注入最相关的上下文。
手脚（工具与环境）：
- 基础工具：文件读写、命令执行是核心。务必做好路径安全校验和命令白名单过滤，防止越权操作。
- 高级工具：可以考虑集成git操作（像Aider）、调用 linter/formatter（如black,eslint）、运行特定测试框架命令。
- 执行环境：对于高风险或需要纯净环境的操作，务必集成 E2B 这样的沙箱。本地执行只留给最安全、最确定性的操作。