1. 从“能思考”到“能动手”为什么AI智能体需要执行代码最近在折腾一个基于.Net AgentFramework的AI智能体项目目标是让它不仅能理解我的指令、规划任务还能真正“动手”去执行一些具体的操作。比如我让它分析服务器日志它不能只是告诉我“第5行有个错误”而是应该能直接运行一个Python脚本把错误日志提取出来发到我的邮箱。或者我让它帮我处理一批数据它应该能调用写好的数据清洗脚本生成报告。这个“动手”的能力尤其是执行Python脚本和运行代码的能力是智能体从“参谋”升级为“执行者”的关键一步。很多朋友在接触AI智能体开发时容易陷入一个误区把大模型本身当成了万能工具箱。实际上大语言模型LLM的核心优势是理解和生成文本是“思考”和“规划”。它知道“应该做什么”但通常不具备“直接去做”的能力。比如它无法直接操作你的文件系统、调用外部API、执行复杂的数学计算或启动一个子进程。这就是为什么我们需要为智能体赋予“工具”Tools或“技能”Skills让它可以委托这些工具去完成具体的、原子性的任务。在.Net生态中AgentFramework这里通常指基于Semantic Kernel或类似理念构建的智能体框架提供了很好的抽象来集成这些工具。而Python作为数据科学、自动化脚本和快速原型开发的事实标准自然成为了我们扩展智能体能力的首选“瑞士军刀”。为智能体添加执行Python脚本的能力本质上是在.Net环境中搭建一个安全、可控的“Python执行沙箱”让智能体可以像调用一个普通C#方法一样去运行一段Python代码并获取结果。更进一步当我们谈论“后续可用于对接OpenClaw技能”时这意味着我们的智能体将获得一个更强大的技能库。OpenClaw是一个开源的AI智能体平台它本身集成了大量针对具体场景的“技能”Skill比如操作浏览器、读写数据库、发送邮件等。我们的智能体在具备了基础的代码执行能力后就可以更灵活地与OpenClaw这类平台的技能体系进行对接和组合实现更复杂的自动化工作流。例如智能体可以先用Python脚本处理数据再调用OpenClaw的“发送邮件”技能将结果发出。所以今天要聊的就是如何在.Net的AgentFramework里一步步地给AI智能体装上“Python之手”。我会从最核心的原理讲起涵盖环境准备、安全隔离、进程通信、异常处理最后再聊聊如何为对接OpenClaw这样的技能平台做准备。过程中会穿插很多我实际踩过的坑和总结的经验希望能帮你少走弯路。2. 核心架构设计在C#的怀抱中安全地运行Python在.Net应用中执行外部进程尤其是像Python这样的脚本语言绝不是简单地调用Process.Start(“python”, “script.py”)就完事了。对于AI智能体场景我们需要考虑得更周全安全性、资源控制、输入输出捕获、异步执行、错误处理以及最重要的——如何将这一套机制优雅地集成到AgentFramework的工具调用范式里。2.1 为什么需要“沙箱”而不仅仅是进程直接启动Python进程是最简单的方式但风险极高。想象一下AI智能体根据用户模糊的指令生成了这样一段Python代码import os; os.system(‘rm -rf /’)。如果直接执行后果不堪设想。因此我们的核心设计原则是隔离与限制。一个成熟的方案通常包含以下层次进程隔离在独立的子进程中运行Python避免污染主应用的运行时。权限限制在可能的情况下以低权限用户身份运行该进程。资源配额限制Python进程的CPU时间、内存使用量和运行时间防止恶意或 bug 脚本耗尽系统资源。模块白名单通过自定义的Python解释器环境或导入钩子import hook限制脚本只能导入我们允许的模块如json,math,datetime禁止导入os,subprocess,socket等危险模块。代码审计在执行前可以对生成的代码进行简单的静态分析或关键词过滤虽然这不是绝对安全但能挡掉大部分明显危险的操作。对于大多数内部或受信任环境下的AI智能体应用实现前三点进程、资源、权限是一个比较实用的安全基线。第四点和第五点可以根据安全要求的等级选择性添加。2.2 与AgentFramework的集成模式在AgentFramework以Semantic Kernel为例中一个“工具”通常以一个KernelFunction的形式存在。我们需要创建一个KernelFunction它内部封装了启动、管理Python进程的所有逻辑。这个函数应该接受参数主要是要执行的Python代码字符串或者脚本文件的路径以及可能的输入参数。返回结果Python脚本的标准输出stdout、标准错误stderr以及退出码。异步执行智能体的操作应该是非阻塞的因此工具函数必须是async的。可被Planner发现和调用需要通过适当的特性如[KernelFunction]和描述来装饰这个函数以便智能体的规划器Planner能理解它的用途并在合适的时候调用它。我们的架构目标就是构建一个名为ExecutePythonScript的KernelFunction它内部采用一个稳健的、带资源限制的进程管理器来运行Python代码。2.3 技术选型Python.NET vs. 原生进程调用这里有两个主流技术路径路径一使用Python.NET (pythonnet)这是一个连接.Net Common Language Runtime (CLR) 和Python运行时的桥梁。它允许你在.Net进程中直接加载Python解释器在同一个进程空间内调用Python代码对象可以在两者间直接传递性能极高。优点无进程开销通信效率极高可以直接操作Python对象。缺点隔离性差一个脚本的崩溃可能导致整个.Net应用崩溃资源限制实现复杂对Python版本和C库依赖非常敏感环境配置容易出问题。路径二使用System.Diagnostics.Process这是最经典的方式通过创建子进程来运行python解释器。优点隔离性好子进程崩溃不影响主进程利用操作系统机制实现资源限制相对容易环境配置清晰与系统安装的Python环境一致。缺点有进程创建和销毁的开销进程间通信IPC需要通过标准输入输出或其它方式有序列化/反序列化成本。我的选择与理由对于AI智能体场景我强烈推荐路径二原生进程调用。原因如下稳定性优先智能体可能执行来源不可完全信任的代码由LLM生成进程隔离是保障主服务稳定的最后防线。资源控制直观可以通过.NET的Process对象或操作系统命令如Linux下的ulimit、prlimit方便地设置内存、CPU限制。环境兼容性好直接使用系统或虚拟环境中的Python兼容所有原生库避免Python.NET可能遇到的原生库绑定问题。调试方便子进程的输入输出流清晰独立便于记录和排查问题。牺牲一点性能换来巨大的安全性和稳定性提升在智能体应用中是绝对值得的。因此下文将围绕System.Diagnostics.Process方案展开。3. 实现细节构建稳健的Python脚本执行引擎确定了使用进程调用的架构后我们来深入实现细节。我们将创建一个PythonExecutionService类它负责管理Python进程的生命周期、通信和资源限制。3.1 基础执行流程与封装首先我们定义服务的接口和基础实现。using System.Diagnostics; using System.Text; using System.Threading.Tasks; public interface IPythonExecutionService { TaskPythonExecutionResult ExecuteCodeAsync(string pythonCode, string workingDirectory null, CancellationToken cancellationToken default); TaskPythonExecutionResult ExecuteScriptAsync(string scriptPath, string arguments null, string workingDirectory null, CancellationToken cancellationToken default); } public class PythonExecutionResult { public string StandardOutput { get; set; } string.Empty; public string StandardError { get; set; } string.Empty; public int ExitCode { get; set; } public bool IsSuccess ExitCode 0; public TimeSpan ExecutionTime { get; set; } }ExecuteCodeAsync用于执行一段代码字符串ExecuteScriptAsync用于执行一个.py文件。PythonExecutionResult封装了执行结果。核心的ExecuteCodeAsync实现如下ExecuteScriptAsync类似但参数是文件路径public class PythonExecutionService : IPythonExecutionService { private readonly string _pythonExecutablePath; // 例如 “python3” 或 “C:\Python310\python.exe” private readonly TimeSpan _defaultTimeout; public PythonExecutionService(string pythonExecutablePath “python”, TimeSpan? defaultTimeout null) { _pythonExecutablePath pythonExecutablePath; _defaultTimeout defaultTimeout ?? TimeSpan.FromSeconds(30); } public async TaskPythonExecutionResult ExecuteCodeAsync(string pythonCode, string workingDirectory null, CancellationToken cancellationToken default) { var result new PythonExecutionResult(); var stopwatch Stopwatch.StartNew(); using (var process new Process()) { process.StartInfo.FileName _pythonExecutablePath; process.StartInfo.Arguments “-c \”” EscapePythonArgument(pythonCode) “\””; // -c 表示执行命令行代码 process.StartInfo.UseShellExecute false; process.StartInfo.RedirectStandardOutput true; process.StartInfo.RedirectStandardError true; process.StartInfo.CreateNoWindow true; process.StartInfo.WorkingDirectory workingDirectory ?? Directory.GetCurrentDirectory(); // 设置环境变量等可选 // process.StartInfo.EnvironmentVariables[“PYTHONPATH”] “...”; var outputBuilder new StringBuilder(); var errorBuilder new StringBuilder(); process.OutputDataReceived (sender, e) { if (e.Data ! null) outputBuilder.AppendLine(e.Data); }; process.ErrorDataReceived (sender, e) { if (e.Data ! null) errorBuilder.AppendLine(e.Data); }; try { process.Start(); process.BeginOutputReadLine(); process.BeginErrorReadLine(); // 等待进程退出支持超时和取消 var processExited await WaitForExitAsync(process, _defaultTimeout, cancellationToken).ConfigureAwait(false); if (!processExited) { // 超时尝试终止进程 TryKillProcess(process); result.StandardError “Execution timed out.”; result.ExitCode -1; } else { result.ExitCode process.ExitCode; } } catch (Exception ex) { result.StandardError $”Failed to start or manage process: {ex.Message}”; result.ExitCode -1; } finally { stopwatch.Stop(); result.ExecutionTime stopwatch.Elapsed; // 确保获取所有输出 result.StandardOutput outputBuilder.ToString().TrimEnd(); result.StandardError (result.StandardError errorBuilder.ToString()).TrimEnd(); } } return result; } private async Taskbool WaitForExitAsync(Process process, TimeSpan timeout, CancellationToken cancellationToken) { var delayTask Task.Delay(timeout, cancellationToken); var exitTask Task.Run(() process.WaitForExit(), cancellationToken); var completedTask await Task.WhenAny(exitTask, delayTask).ConfigureAwait(false); return completedTask exitTask; } private void TryKillProcess(Process process) { try { if (!process.HasExited) process.Kill(true); } catch { /* Ignore */ } } private string EscapePythonArgument(string code) { // 简易转义防止代码中的引号破坏命令行参数结构 // 对于复杂情况可能需要写入临时文件再执行更安全 return code.Replace(“\””, “\”\””).Replace(“”, “\”); } }注意上面的EscapePythonArgument方法非常基础。对于复杂的、包含多行和特殊字符的Python代码使用-c参数可能会遇到转义地狱。更稳健的做法是将代码写入一个临时文件然后让Python执行该文件。这样可以完美避免所有命令行转义问题。ExecuteScriptAsync方法天然就是这种模式。3.2 安全加固资源限制与模块沙箱基础执行有了接下来是加固。我们主要从两方面入手资源限制和模块限制。资源限制以Linux为例在Linux下我们可以利用prlimit或ulimit。一个方法是在启动Process时通过bash -c ‘ulimit …; python …’来包装。但更优雅的方式是使用ProcessStartInfo.ArgumentList和/bin/bash。// 在process.Start()之前修改启动信息以实现资源限制 if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux)) { // 使用prlimit命令包装执行 var limitedCommand $”prlimit --cpu10 --as104857600 python -c \”{EscapePythonArgument(pythonCode)}\””; // 限制CPU时间10秒内存100MB process.StartInfo.FileName “/bin/bash”; process.StartInfo.Arguments $”-c \”{limitedCommand}\””; // 注意需要确保系统安装了util-linux包以提供prlimit }在Windows上资源限制更复杂通常需要通过作业对象Job ObjectAPIP/Invoke调用CreateJobObject,SetInformationJobObject等来实现。考虑到复杂性初期可以只做超时控制这对于防止脚本死循环已经很有帮助。模块沙箱Python层面我们可以在传递给Python的代码外围包裹一个“沙箱”环境。例如创建一个安全的执行上下文覆盖__import__内置函数。我们可以准备一个Python“启动器脚本”safe_runner.py# safe_runner.py import sys import builtins _allowed_modules {‘math’, ‘json’, ‘datetime’, ‘re’, ‘collections’, ‘itertools’, ‘random’, ‘statistics’} # 白名单 class RestrictedImporter: def find_spec(self, fullname, path, targetNone): if fullname in _allowed_modules or fullname.split(‘.’)[0] in _allowed_modules: return None # 允许导入返回None让标准导入器处理 raise ImportError(f”Module ‘{fullname}’ is not allowed in the sandbox.”) sys.meta_path.insert(0, RestrictedImporter()) # 插入自定义导入器 # 执行用户代码 if __name__ ‘__main__’: user_code_file sys.argv[1] with open(user_code_file, ‘r’, encoding‘utf-8’) as f: user_code f.read() # 在全局和局部作用域均为空字典的上下文中执行 exec(user_code, {‘__builtins__’: {k: v for k, v in builtins.__dict__.items() if k in [‘print’, ‘len’, ‘range’, ‘str’, ‘int’, ‘float’, ‘bool’, ‘list’, ‘dict’, ‘tuple’, ‘set’]}}, {})然后在C#中不再直接执行用户代码而是先将用户代码写入临时文件然后执行python safe_runner.py temp_file.py。这样用户代码就被限制在了一个只能导入白名单模块、且内置函数也被限制的环境中。实操心得模块白名单的维护是个持续过程。你需要根据智能体实际需要完成的任务来动态调整这个名单。例如如果智能体需要处理HTTP请求你可能需要加入requests或urllib如果需要数据处理则需要pandas或numpy。永远采用最小权限原则只开放必要的模块。3.3 异常处理与结果解析Python脚本的执行结果可能成功也可能失败。失败又分几种情况进程启动失败Python解释器路径错误、权限不足等。通过捕获Win32Exception等异常处理。脚本语法错误/运行时异常这会在Python进程内部发生导致非零退出码错误信息会输出到StandardError。我们的服务需要能区分这类“业务逻辑错误”和系统错误。资源超限/进程被终止这是我们主动杀掉的进程ExitCode通常为非零我们会在StandardError中补充超时信息。脚本无输出这可能是正常的但需要和挂起区分。在PythonExecutionResult中我们可以增加一个方法来提供更友好的状态判断public class PythonExecutionResult { // ... 其他属性同上 public ExecutionStatus Status { get { if (ExitCode -1 StandardError.Contains(“timed out”)) return ExecutionStatus.Timeout; if (ExitCode ! 0 !string.IsNullOrEmpty(StandardError)) return ExecutionStatus.ExecutionError; if (ExitCode 0) return ExecutionStatus.Success; return ExecutionStatus.UnknownError; } } } public enum ExecutionStatus { Success, ExecutionError, Timeout, UnknownError }在集成到AgentFramework时我们需要根据Status和StandardError来构造给LLM的反馈。例如如果是ExecutionError可以将Python的traceback返回给LLM让它尝试修复代码如果是Timeout则提示LLM代码可能陷入了死循环需要优化逻辑。4. 集成到AgentFramework打造智能体的Python工具现在我们有了一个健壮的PythonExecutionService。下一步是把它包装成AgentFramework这里以Semantic Kernel为例能识别的KernelFunction。4.1 创建KernelFunction在Semantic Kernel中我们可以创建一个原生函数Native Function。using Microsoft.SemanticKernel; public class PythonExecutionPlugin { private readonly IPythonExecutionService _pythonService; public PythonExecutionPlugin(IPythonExecutionService pythonService) { _pythonService pythonService; } [KernelFunction, Description(“Executes a piece of Python code and returns the output. Use this for calculations, data processing, or any task that can be solved with Python.”)] public async Taskstring ExecutePythonCodeAsync( [Description(“The Python code to execute.”)] string code, Kernel kernel, // Semantic Kernel会自动注入 CancellationToken cancellationToken default) { var result await _pythonService.ExecuteCodeAsync(code, cancellationToken: cancellationToken).ConfigureAwait(false); if (result.Status ExecutionStatus.Success) { return string.IsNullOrEmpty(result.StandardOutput) ? “Code executed successfully (no output).” : result.StandardOutput; } else if (result.Status ExecutionStatus.ExecutionError) { // 将错误信息格式化便于LLM理解 return $”Python execution failed with error:\n\n{result.StandardError}\n\nExit code: {result.ExitCode}”; } else if (result.Status ExecutionStatus.Timeout) { return $”The Python code execution timed out after {result.ExecutionTime.TotalSeconds} seconds. It might contain an infinite loop or is too complex.”; } else { return $”An unknown error occurred during Python execution: {result.StandardError}”; } } }4.2 注册插件并测试在应用启动时将插件注册到Kernel中。using Microsoft.SemanticKernel; var builder Kernel.CreateBuilder(); // ... 配置LLM等 // 注册Python执行服务 builder.Services.AddSingletonIPythonExecutionService(sp new PythonExecutionService(pythonExecutablePath: “python3”, defaultTimeout: TimeSpan.FromSeconds(60))); builder.Services.AddTransientPythonExecutionPlugin(); var kernel builder.Build(); // 导入插件 kernel.ImportPluginFromObjectPythonExecutionPlugin(“python”); // 现在你的智能体就可以在规划中使用 python.ExecutePythonCodeAsync 这个工具了测试一下你可以手动调用这个函数或者让一个简单的智能体来使用它。// 手动调用测试 var pythonPlugin kernel.Plugins[“python”]; var function pythonPlugin[“ExecutePythonCodeAsync”]; var result await kernel.InvokeAsync(function, new KernelArguments { [“code”] “print(‘Hello from Python!’, 12*3)” }); Console.WriteLine(result.GetValuestring()); // 输出: Hello from Python! 7 // 通过Planner让智能体自主使用 // 假设你有一个目标“计算圆周率π的前10位小数” // Planner可能会自动规划并调用这个Python工具执行 import math; print(round(math.pi, 10))4.3 为工具提供更丰富的上下文为了让LLM更好地决定何时以及如何使用这个工具我们需要提供清晰、丰富的描述。上面的[Description]特性是基础。更进一步我们可以利用Semantic Kernel的KernelFunctionFromPrompt来创建一个“元工具”这个工具可以根据自然语言描述动态生成要执行的Python代码。但这属于更高级的“代码生成与执行”循环模式初期可以先让LLM直接生成代码字符串。一个实用的技巧是在工具的Description中提供一些示例Few-shot Example虽然Semantic Kernel的Native Function目前不支持在Description中嵌入复杂示例但你可以通过系统提示词System Prompt来为整个智能体提供使用Python工具的范例。5. 踩坑实录从理论到实践的关键陷阱在实际搭建和运行这套系统的过程中我遇到了不少预料之外的问题。这里分享几个最具代表性的“坑”希望能帮你提前规避。5.1 环境变量与路径问题找不到模块问题现象在C#中调用Python进程执行import pandas报错ModuleNotFoundError: No module named ‘pandas’但在命令行手动执行同样的Python解释器却可以。根因分析Process.Start创建的子进程默认继承父进程的环境变量。但是如果你的.Net应用是通过系统服务如systemd启动的或者是在IDE如VS Code的调试环境中启动的其环境变量PATH和PYTHONPATH可能与你的用户Shell环境不同。特别是当Python包安装在用户目录~/.local或虚拟环境venv中时。解决方案显式指定Python解释器绝对路径不要依赖”python3”而是使用完整路径如”/usr/bin/python3”或”C:\Users\YourName\.virtualenvs\agent\Scripts\python.exe”。显式设置环境变量在ProcessStartInfo.EnvironmentVariables中手动设置关键环境变量。process.StartInfo.EnvironmentVariables[“PATH”] “/path/to/venv/bin:” Environment.GetEnvironmentVariable(“PATH”); process.StartInfo.EnvironmentVariables[“PYTHONPATH”] “/path/to/custom/modules”;激活虚拟环境对于虚拟环境最可靠的方式是使用该虚拟环境下的Python解释器绝对路径。如果你必须使用activate脚本则需要通过bash -c ‘source /path/to/venv/bin/activate python …’的方式但这引入了对bash的依赖在Windows上不通用。我的经验为智能体项目专门创建一个独立的Python虚拟环境并在PythonExecutionService的配置中硬编码此虚拟环境中Python解释器的绝对路径。这保证了环境的一致性也便于依赖包的管理。5.2 死锁与输出缓冲区为什么我的脚本卡住了问题现象执行一个会输出大量数据的Python脚本例如打印一个很长的列表C#端的StandardOutput读取总是卡住直到进程结束才一次性收到所有输出甚至可能因为缓冲区满导致进程死锁。根因分析子进程的标准输出和错误输出是带有缓冲区的。当输出量超过缓冲区大小时如果父进程我们的C#程序没有及时读取子进程可能会在write调用上阻塞。如果我们使用process.StandardOutput.ReadToEnd()这种同步方法会等到流关闭进程结束才返回对于长时间运行的脚本你就无法获得实时输出。解决方案使用异步事件驱动的方式读取输出正如我们在PythonExecutionService实现中使用的BeginOutputReadLine和BeginErrorReadLine。这两个方法会开启后台线程在数据到达时立即触发事件避免了缓冲区阻塞。注意BeginOutputReadLine和BeginErrorReadLine必须在进程启动后、等待退出前调用且两者必须同时启用或者确保你读取了所有重定向的流否则仍可能导致死锁。我们的实现中在process.Start()后立即调用这两个方法是正确的。5.3 超时控制不生效进程成了“僵尸”问题现象设置了WaitForExitAsync的超时超时后也调用了process.Kill()但任务结束后发现系统里仍然存在Python进程。根因分析Process.Kill()是异步的它只是向进程发送了终止信号在Windows上是TerminateProcess。如果进程在收到信号后没有立即退出例如正在执行清理工作、等待子进程或者进程变成了“僵尸进程”Zombie已结束但父进程未回收那么它可能还会残留。解决方案使用Kill(true)在.NET Core 3.0和.NET 5中Kill(bool entireProcessTree)参数可以设置为true这会终止整个进程树包括可能由Python脚本创建的任何子进程。这能解决大部分子进程残留问题。等待并检查调用Kill后可以再等待一小段时间然后检查process.HasExited。如果仍未退出可以记录错误或尝试更强制的手段但这通常意味着系统状态异常。使用作业对象Windows如前所述在Windows上使用作业对象来管理进程组可以确保整个作业被干净地终止。我的经验在Linux下Kill(true)通常足够有效。在Windows下对于要求极高的场景确实需要考虑实现作业对象。对于大多数智能体应用Kill(true)加上合理的超时等待已经能处理99%的情况。关键是要在日志中记录这些强制终止事件以便后续分析脚本为何会失控。5.4 中文与编码问题乱码从何而来问题现象Python脚本打印的中文在C#端接收时变成了乱码。根因分析这是跨语言、跨进程通信中经典的编码问题。Python 3默认使用UTF-8编码但Windows控制台的默认编码可能是GBKcp936。当C#的Process使用默认设置读取输出流时如果没有指定正确的编码就会用系统默认编码如GBK去解码UTF-8的字节流导致乱码。解决方案在ProcessStartInfo和读取流时明确指定UTF-8编码。process.StartInfo.StandardOutputEncoding Encoding.UTF8; process.StartInfo.StandardErrorEncoding Encoding.UTF8; // 同时确保Python脚本也使用UTF-8输出。可以在执行的代码开头加上 // # -*- coding: utf-8 -*- // 或者设置环境变量 PYTHONIOENCODINGutf-8 process.StartInfo.EnvironmentVariables[“PYTHONIOENCODING”] “utf-8”;一劳永逸的方法无论在什么操作系统上都统一使用UTF-8编码。在C#服务端和Python脚本端都明确指定UTF-8可以彻底避免此类乱码问题。6. 进阶之路为对接OpenClaw技能做准备让智能体能执行Python代码已经打开了自动化世界的一扇大门。而对接像OpenClaw这样的技能平台则是将这扇门开得更大让智能体可以直接调用无数预先封装好的、更稳定更强大的技能。我们的Python执行引擎可以成为连接AgentFramework和OpenClaw技能的“粘合剂”或“适配器”。6.1 OpenClaw技能调用模式分析OpenClaw的技能Skill通常通过HTTP API、GRPC或特定的SDK进行调用。例如一个“发送邮件”的技能可能会暴露一个REST端点POST /api/skill/send-email。智能体需要构造符合该端点要求的JSON payload并发送请求。我们的Python执行能力在这里可以扮演两个角色技能调用封装器我们可以为常用的OpenClaw技能编写轻量级的Python封装函数。例如一个send_email(to, subject, body)的Python函数内部使用requests库去调用OpenClaw的API。然后我们的智能体只需要生成调用这个Python函数的代码即可无需关心底层的HTTP细节。复杂工作流编排器有些任务需要组合多个技能和逻辑判断。例如“监控日志如果发现错误则提取错误信息并发送邮件通知”。智能体可以生成一个Python脚本这个脚本内部按顺序调用多个封装好的技能函数并加入自己的逻辑如错误判断、信息提取。6.2 构建技能适配层我们可以创建一个专门的Python模块例如openclaw_client.py放在智能体可以访问的路径下或者打包进我们的Python沙箱环境。这个模块提供了对OpenClaw技能的友好封装。# openclaw_client.py (简化示例) import requests import json class OpenClawClient: def __init__(self, base_url“http://localhost:8000”, api_keyNone): self.base_url base_url.rstrip(‘/’) self.headers {“Content-Type”: “application/json”} if api_key: self.headers[“Authorization”] f”Bearer {api_key}” def send_email(self, to, subject, body): payload { “to”: to, “subject”: subject, “body”: body } resp requests.post(f”{self.base_url}/api/skill/send-email”, jsonpayload, headersself.headers) resp.raise_for_status() return resp.json() def query_database(self, query): # 假设另一个技能 payload {“sql”: query} resp requests.post(f”{self.base_url}/api/skill/query-db”, jsonpayload, headersself.headers) resp.raise_for_status() return resp.json()[“results”] # 为了方便可以创建一个全局客户端实例实际使用时应从环境变量等配置 # client OpenClawClient()然后在我们的安全执行沙箱中将这个模块路径加入sys.path或者直接将其代码注入到执行上下文中。这样智能体生成的代码就可以直接from openclaw_client import send_email了。6.3 在AgentFramework中创建高阶工具我们可以在PythonExecutionPlugin的基础上创建一些更具体、更面向业务的高阶工具这些工具内部固定使用我们封装好的OpenClaw技能。[KernelFunction, Description(“Sends an email using the configured OpenClaw service.”)] public async Taskstring SendEmailAsync( [Description(“The recipient email address.”)] string to, [Description(“The subject of the email.”)] string subject, [Description(“The body content of the email.”)] string body) { // 不再让LLM生成Python代码而是直接调用我们预定义的脚本模板 string pythonCode $” from openclaw_client import send_email try: result send_email(‘{EscapeString(to)}’, ‘{EscapeString(subject)}’, ‘{EscapeString(body)}’) print(f’Email sent successfully: {{result}}’) except Exception as e: print(f’Failed to send email: {{e}}’) “; var execResult await _pythonService.ExecuteCodeAsync(pythonCode); return execResult.StandardOutput; }这样做的好处是更安全、更可控。智能体只需要提供邮件内容等参数而调用技能的具体方式API端点、认证头等被隐藏在安全的预定义脚本中LLM没有机会生成恶意的系统调用。6.4 动态技能发现与调用更高级的模式是让智能体能够动态发现OpenClaw有哪些可用技能并根据发现的结果决定调用哪一个。这需要OpenClaw技能平台提供一个技能清单API例如GET /api/skills。我们的AgentFramework侧有一个工具或插件能调用这个API并将技能清单以某种格式如JSON Schema描述告知LLM。LLM根据用户请求和技能描述选择合适的技能并生成调用该技能所需的参数。这个过程可以完全由我们的Python执行引擎作为桥梁一个工具负责获取技能清单另一个通用工具负责根据技能名和参数调用技能。这实现了智能体与技能平台的松耦合技能可以随时在OpenClaw上增删改而智能体无需重新部署。7. 总结与最佳实践给.Net AgentFramework中的AI智能体添加Python脚本执行能力是一个从“思考”到“行动”的关键跨越。回顾整个实现过程以下几个最佳实践值得牢记安全第一隔离为先始终在独立的、受资源限制的进程中运行不可信代码。进程隔离是你的第一道也是最重要的防线。明确边界白名单控制不要给予Python脚本无限的权力。通过模块白名单、内置函数限制等方式构建一个最小权限的沙箱环境。需要什么功能就开放什么模块。异步与健壮性使用异步模式处理进程I/O妥善处理超时、取消和异常。确保即使子进程崩溃主服务依然稳定。编码与环境一致性明确指定UTF-8编码并使用绝对路径管理Python解释器和依赖环境避免“在我机器上好好的”这类问题。为集成而设计将Python执行能力封装成AgentFramework原生的、描述清晰的工具KernelFunction。良好的工具描述能极大提升LLM调用它的准确率。日志与监控详细记录每一次代码执行的元信息谁哪个会话/用户在何时执行了什么代码可哈希或摘要、用了多久资源、结果如何。这对于审计、调试和成本控制至关重要。循序渐进对接技能平台先从封装几个核心、稳定的OpenClaw技能开始创建高阶工具。待模式跑通后再考虑更动态、更复杂的技能发现与调用机制。最后我想分享一个我个人的深刻体会赋予智能体“行动力”的同时必须同步构建“观察力”和“反思力”。当智能体可以执行代码后它犯错的破坏力也变大了。因此除了技术上的安全加固在应用层设计上对于重要的、有副作用的操作如发送邮件、修改数据强烈建议加入“人工确认”环节或者至少要有非常详细的操作日志供追溯。让智能体成为你得力的助手而不是一个闯祸的“熊孩子”这其中的平衡需要我们开发者仔细拿捏。从简单的Python脚本执行开始逐步扩展其能力边界并在每一步都扎紧安全的篱笆这条路才能走得稳、走得远。