基于NativeAOT的 OpenClaw.NET 深度刨析

引言：自主智能体架构的演进与原生运行时的瓶颈

大型语言模型（LLM）的快速成熟引发了软件工程领域的底层范式转移。行业焦点已从基于静态提示词（Prompt）的问答系统，全面转向具备自主规划、工具调用与长程逻辑推理能力的自主智能智能体（Autonomous AI Agents）。在这一生态系统中，最初由 TypeScript 与 Node.js 构建的 OpenClaw（其前身为 Clawdbot 与 Moltbot）凭借其极为广泛的通道支持与工具扩展性，迅速崛起为开源界最具影响力的智能体编排引擎之一，在 GitHub 上积累了超过 24 万的星标 。
然而，随着 AI 智能体从极客的实验桌面走向企业级任务关键型（Mission-Critical）环境与边缘计算（Edge Computing）节点，原生 OpenClaw 架构中基于单体 JavaScript 运行时的局限性暴露无遗。高达数百兆的空闲内存占用、Serverless 环境中难以忍受的冷启动延迟、跨平台进程管理中的系统级错误，以及最为致命的——缺乏物理隔离导致的供应链安全漏洞，共同构成了制约大规模生产部署的物理与安全边界。
在此背景下，由开发者 clawdotnet 领导构建的 OpenClaw.NET 项目，代表了该生态乃至整个 AI 智能体领域迄今为止最为宏伟、对技术栈应用最为透彻的架构重构。该项目并非是对原有系统外围 API 接口的简单 C# 封装，而是一个完全由 C# 13 从零构建的、独立且自我托管的网关与智能体运行时框架。通过全面拥抱 NativeAOT（提前编译）技术、引入微软官方 Microsoft.Extensions.AI 抽象库以彻底解耦大模型供应商 SDK，并创造性地在操作系统进程级别应用“绞肉机模式”（Strangler Fig Pattern）来桥接原生 Node.js 插件生态，OpenClaw.NET 成功解决了内存膨胀、安全隔离弱以及生态碎片化这三大原生痛点。
本文将对 OpenClaw.NET 的底层架构决策、内存与冷启动优化机制、工具调用契约的抽象逻辑，以及其卓越的插件桥接与物理沙箱安全模型进行详尽的剖析。通过解构这些工程智慧，本文旨在为下一代企业级 AI 编排系统的架构设计提供权威的理论与实践参考。
原生 JavaScript 智能体架构的物理与安全极限

要深刻理解 OpenClaw.NET 所带来的技术颠覆，必须首先对原生 TypeScript/Node.js 版本在资源调度与安全模型上的系统性缺陷进行诊断。原生 OpenClaw 的核心是一个持续运行的认知循环（即 ReAct 循环——推理与行动），该循环负责解析用户输入、维持包含历史会话与系统状态的庞大上下文窗口、分发 API 请求，并执行本地或远程工具。
V8 引擎的内存膨胀（Memory Bloat）效应

Node.js 所依赖的 V8 引擎虽然在处理高并发异步 I/O 方面表现出色，但其在维持有状态的、极耗内存的 AI 认知循环时却显得力不从心。原生 OpenClaw 倾向于在每次会话启动时将海量的系统提示词、数百个工具的 JSON Schema 定义以及完整的长程对话历史加载至内存堆中 。
V8 引擎的即时编译（JIT）机制与垃圾回收（GC）策略在面对这种包含超大字符串与深层嵌套 JSON 对象的场景时，会产生严重的内存膨胀。基准测试表明，原生 OpenClaw 运行时的空闲内存占用通常盘旋在 390MB 至 400MB 之间，这甚至是在未进行任何实质性 LLM 推理与工具执行的前提下。在云原生微服务架构或边缘计算（如 Raspberry Pi、廉价 VPS 实例）中，这种内存密度直接摧毁了节点的单机多租户承载能力，使得横向扩展的成本极其高昂。
Serverless 部署中的冷启动惩罚

在现代企业架构中，系统的高可用性与弹性伸缩高度依赖于 Serverless 函数（如 AWS Lambda）或容器的快速拉起。然而，Node.js 庞大的依赖树解析与 JIT 编译的预热需求，导致了不可忽视的冷启动（Cold Start）延迟。对于一个需要通过 WebSocket 或即时通讯渠道（如 Telegram、WhatsApp）进行低延迟实时交互的 AI 智能体而言，数秒钟的冷启动时间会引发严重的超时断连与极差的用户体验。
操作系统级进程调度的脆弱性

除了内存与启动速度，原生架构在与底层操作系统交互时也面临稳定性挑战。例如，在 macOS 环境下运行较新版本的 Node.js（如 v22+）时，原生 OpenClaw 在频繁调用本地 Shell 脚本或执行进程级工具时，会遭遇持续性的 EBADF（Bad File Descriptor，错误文件描述符）崩溃。这种系统底层的管道调度异常，直接瘫痪了智能体执行本地命令的能力，暴露出单体脚本语言运行时在处理密集型系统资源分配时的天然缺陷。
供应链安全与“致命三要素”

原生架构最为核心的隐患在于其毫无物理隔离的执行环境。网络安全研究人员指出，自我托管的 AI 智能体天然具备“致命三要素”（Lethal Trifecta）：即对本地私有数据的访问权、暴露于不可信的外部输入（如提示词注入攻击），以及执行外部第三方代码的能力。
在原生 OpenClaw 中，持有核心网关通信 Token、各家 LLM API 密钥以及用户系统最高权限的主控运行时，与从 ClawHub 下载的不可信第三方社区插件，运行在同一个 Node.js 进程的同一块内存空间中。如果第三方开发者由于疏忽引入了原型链污染漏洞，或者恶意攻击者通过修改社区代码（如 Cisco 审计中发现的隐蔽数据外发行为）进行供应链投毒，恶意代码将能够毫不受限地访问网关内存，甚至执行崩溃系统与溢出攻击。这种完全违背“最小权限原则”的单体架构，是企业级应用不可逾越的红线。
C# NativeAOT 范式：重塑内存与冷启动的物理边界

面对上述瓶颈，OpenClaw.NET 并非简单地将 TypeScript 语法翻译为 C#，而是对整个底层运行时基建进行了手术刀式的切除与重构。该框架的核心编排层（涵盖 ReAct 认知循环、工具分发引擎、WebSocket 守护进程以及 Webhook 路由）完全使用 C# 13 编写，并深度针对 NativeAOT（提前编译）技术进行了优化。这一决策从根本上重塑了智能体运行时的物理边界。
极致的体积压缩与部署敏捷性

NativeAOT 技术在编译阶段不仅将 C# 中间语言（IL）直接转换为目标操作系统的原生机器码，还包含了一个高度激进的剪裁（Trimming）过程。编译器会进行全程序的静态依赖分析，将所有未被实际调用的框架代码、反射元数据与冗余库彻底剔除。
结果是，整个 OpenClaw.NET 智能体与网关被打包成一个独立的、无外部运行时依赖的二进制执行文件。基于 Ubuntu Chiseled 构建的生产级 Docker 镜像，其整体体积被惊人地压缩至大约 15MB。相较于动辄包含数百兆 node_modules 文件夹的标准 Node.js 镜像，这种极简的产物体积使得在 Kubernetes 集群中的镜像拉取、节点迁移与扩缩容操作能在毫秒级完成，极大地提升了云原生环境下的调度敏捷性。
消除 JIT 开销：零冷启动与内存确定性

由于 NativeAOT 产物已经是针对 CPU 架构优化后的机器码，应用程序在启动时彻底免去了传统.NET CLR 或 V8 引擎所需的即时编译（JIT）开销。基准测试数据表明，NativeAOT 架构能将冷启动延迟缩减 70% 以上，实现亚秒级甚至几十毫秒级的瞬时启动。这一特性使得 OpenClaw.NET 成为在 AWS Lambda 或 Azure Functions 等 Serverless 架构中部署按需 AI 智能体的完美解决方案。
在内存管理方面，预编译机器码配合 C# 现代的垃圾回收机制，赋予了系统极高的内存分配确定性。OpenClaw.NET 的空闲内存占用仅为 Node.js/V8 等效版本的零头。这种极致的资源效率，不仅让企业能够在一台普通服务器上高密度地并发托管成百上千个独立的智能体实例，还使得将完整智能体运行时塞入树莓派（Raspberry Pi）等廉价物联网边缘节点成为可能，真正实现了“无处不在的智能智能体”。
原生级遥测与深度可观测性

在追求极致轻量化的同时，OpenClaw.NET 并未牺牲企业级应用所必需的可观测性（Observability）。C# 核心利用依赖注入（DI）与中间件管道机制，开箱即用地集成了 OpenTelemetry。这意味着基础设施运维团队可以实时获取包含内存分配速率、ReAct 循环延迟、工具执行耗时在内的颗粒度健康指标，并将其无缝接入 Prometheus、Grafana 或 Datadog 等企业监控大盘。
架构特性对比原生 OpenClaw (Node.js/TS)OpenClaw.NET (NativeAOT C#)架构与业务启示执行引擎V8 即时编译 (JIT)预编译原生机器码 (AOT)彻底消除运行时编译开销，性能极度可预测。空闲内存 footprint~390 MB - 400 MB极低（Node.js 的零头）实现高密度多租户托管，大幅降低云基础设施成本。容器分发体积> 200 MB~15 MB (Ubuntu Chiseled)契合云原生伸缩需求，提升 CI/CD 流水线效率。冷启动延迟较长（因模块解析与预热）极速（毫秒级别）完美适配 Serverless 按需计费模型。底层 IO 稳定性容易触发 EBADF 文件描述符耗尽 4依赖稳健的.NET 线程池与 IO 调度高并发本地工具调用与进程生成的稳定性呈指数级提升。解构厂商锁定：Microsoft.Extensions.AI 的深度抽象
在 AI 智能体的架构演进中，生态碎片化是最为棘手的系统性难题之一。当下的 LLM 市场群雄逐鹿，OpenAI、Anthropic、Google Gemini 以及主导本地开源生态的 Ollama 各自为政。在原生 TypeScript 版本的 OpenClaw 中，为了适配不同厂商的模型接口，开发者被迫在代码库中维护一套错综复杂的适配器（Adapter）模式 。由于各家厂商在流式输出、特别是“工具调用”（Tool Calling/Function Calling）的 JSON 结构定义上存在细微且频繁变动的差异，这种硬编码 SDK 的方式导致框架的维护成本呈指数级上升，任何一家 API 契约的微调都会引发智能体系统的大面积宕机。
OpenClaw.NET 以前所未有的架构优雅度解决了这一痛点。它做出了一个极具远见的工程决策：彻底移除对各家独立 SDK 的硬编码依赖，全面且深度地接入微软官方发布的 Microsoft.Extensions.AI 抽象库。
将推理能力转化为标准化契约

通过引入 IChatClient 接口，Microsoft.Extensions.AI 在底层大模型与上层智能体逻辑之间建立了一道坚不可摧的防波堤。OpenClaw.NET 将 LLM 的推理能力从特定的网络请求实现，彻底转化为高度标准化的接口契约。
这一抽象带来了立竿见影的配置灵活性。开发者无需修改任何 C# 业务代码，只需在 appsettings.json 配置文件中，或是通过操作系统环境变量（如 MODEL_PROVIDER_KEY）修改极少量的键值对，即可在云端 GPT-4o、Azure OpenAI 部署的 GPT-5.2-codex，或是本地运行的 Qwen 之间实现无缝的热切换。
JSON
{
"OpenClaw": {
"Llm": {
"rovider": "openai",
"Model": "gpt-4o",
"ApiKey": "env:MODEL_PROVIDER_KEY",
"Temperature": 0.7,
"MaxTokens": 4096
}
}
}
表 1：OpenClaw.NET 标准化的大模型路由配置片段，展现了底层 SDK 被彻底抽象后的极简运维体验。
深入认知循环骨髓的中间件管道

这种抽象的伟大之处不仅在于网络层的路由，它更深入到了智能体认知循环的内部，通过类似于 ASP.NET Core 的 ChatClientBuilder 机制，允许框架动态注入中间件。

• 可观测性注入：通过 UseOpenTelemetry 中间件，系统自动遵循生成式 AI 系统的 OpenTelemetry 语义约定，将每一次 LLM 会话的延迟、Token 消耗隐式埋点上报。
  
• 审计与日志：利用 UseLogging 中间件，所有的提示词与模型响应都可以被标准化的 ILoggerFactory 捕获，满足金融级应用的合规审计需求。
  
• 分布式缓存：通过 UseDistributedCache，对相同的确定性推理请求进行缓存，大幅降低了自主规划阶段的高频 API 计费成本。
  

解决生态命门：动态 Schema 转换与前向兼容

在智能体系统中，让 LLM 准确理解并调用本地工具是最核心的机制。原生系统需要针对 OpenAI 和 Anthropic 分别编写不同的 JSON Schema 序列化逻辑。而在 OpenClaw.NET 中，Microsoft.Extensions.AI 统合了工具定义的序列化与模型回调的解析。
当开发者使用 C# 定义一个拥有强类型参数与 XML 注释的本地方法（如查询数据库或发送邮件）时，抽象库底层的 UseFunctionInvocation 与反射机制会自动将这一 C# 方法签名实时翻译为模型能够理解的标准化 JSON Schema。当大模型决定调用该工具时，抽象库又会自动拦截模型生成的 JSON 文本，将其反序列化为 C# 对象并精准触发本地方法的执行。
这种将“契约转换”下放至微软官方抽象层的设计，极大地减轻了 OpenClaw.NET 框架维护者的负担。它使得系统具备了真正意义上的“前向兼容”（Forward Compatibility）能力——未来无论涌现出何种具有颠覆性的新型大模型或奇异的参数结构，只要微软的基础抽象库进行了适配，OpenClaw.NET 就能在不修改一行核心代码的前提下，开箱即用地支持这些全新模型。
绞肉机模式（Strangler Fig Pattern）与生态隔离

在大型开源软件的重构史上，最致命的陷阱莫过于“生态孤岛效应”。一个基于全新语言和优越架构的系统，即使在各项基准测试中遥遥领先，如果无法兼容原有系统积累的海量第三方插件，最终也注定会被开源社区无情抛弃。
原生 OpenClaw 能够从众多智能体框架中脱颖而出，其护城河恰恰在于 ClawHub 上由全球数千名开发者贡献的 700 多个高度活跃的 TypeScript/JavaScript 技能（Skills）与插件。这些插件涵盖了前端自动化开发、云原生运维指令、智能家居协议控制、网页信息抓取等包罗万象的领域。如果 OpenClaw.NET 要求用户或开发者用 C# 将这几百个复杂逻辑重新实现一遍，该项目将毫无悬念地走向死胡同 。
为了跨越这道生态鸿沟，OpenClaw.NET 的顶级架构师展现了惊艳的工程智慧：他们在操作系统层面设计了一套名为“插件桥接”（Plugin Bridge）的机制，这实际上是微服务架构中“绞肉机模式”（Strangler Fig Pattern）在进程调度级的一次微观演绎。
桥接机制的微观架构：避免 CLR 解释器的陷阱

在面对多语言互操作时，平庸的设计通常会尝试在宿主语言中嵌入目标语言的解释器（例如在 C# 的 CLR 中嵌入 V8 引擎）。这种做法不仅会重新引入严重的内存开销，还会导致各种难以调试的类型转换灾难。
OpenClaw.NET 完全摒弃了这种做法。当用户在配置中启用插件系统（OpenClawlugins:Enabled=true）时，系统绝不尝试在.NET 内存空间内解释 JavaScript。相反，C# 编写的主控网关会作为操作系统的父进程，利用 --experimental-vm-modules 参数，在底层环境中动态生成一个经过高度精简、专用的 Node.js 子进程（要求 Node.js 18+）。
这个被独立出来的 Node.js 子进程，唯一的工作就是加载、挂载并执行原始的 TypeScript 或 JavaScript 插件代码（通过引入 jiti 库实现对 TS 文件的即时编译支持）。
跨进程通信：基于本地管道的高频 JSON-RPC

为了在这个 C# 父进程与 Node.js 子进程之间建立低延迟的数据交换，架构师建立了一套基于操作系统本地管道（Local Pipes，即 stdin 和 stdout）的高性能双向通信通道。
在这条本地管道之上，运行着标准且轻量的 JSON-RPC 协议 。整个桥接调用的生命周期如下：

• 意图识别与路由：当.NET 智能体的大模型通过推理，决定调用某个基于 JS 编写的社区技能（例如 web-search 或 notion-sync）时，C# 网关会拦截这一请求。
  
• 序列化与投递：C# 运行时将工具参数序列化为符合 JSON-RPC 规范的请求字符串，瞬间通过本地管道压入 Node.js 进程的 stdin。
  
• 沙箱执行：Node.js 子进程读取 stdin，找到对应的 JS 函数并执行具体的业务逻辑。
  
• 结果回传：JS 脚本异步执行完毕后，将结果包装回 JSON-RPC 格式，通过 stdout 管道沿原路返回。
  
• 反序列化与闭环：C# 主进程监听并读取到返回结果，将其反序列化并注入智能体的下一次认知循环中。
  

由于所有数据交换均在同一台机器的内存通道中完成，规避了网络层的 TCP 握手与协议栈拆包，这种“绞肉机模式”的跨进程 IPC 通信延迟几乎可以忽略不计，确保了桥接插件在响应速度上与 C# 原生工具高度一致。这种设计带来了一个堪称奇迹的效果：百分之百的生态兼容性。用户可以在不修改任何一行代码、甚至不需要感知底层是用 C# 运行的前提下，直接在 OpenClaw.NET 的扩展目录中挂载并执行原生生态中的数百个社区插件。
解决流污染的工程创举：stderr 劫持与遥测打通

利用标准输入输出（stdio）进行 JSON-RPC 通信，面临着一个致命的工程陷阱：第三方开源社区编写的 JS 代码往往极不规范，充斥着大量的调试信息输出。如果某个 JS 插件在执行时随意调用了 console.log() 或 console.info()，这些调试文本将被直接混入 stdout 管道。当 C# 宿主进程尝试将这些包含乱码的文本作为 JSON-RPC 进行解析时，会导致灾难性的反序列化崩溃。
为了彻底阻断这种数据流污染，OpenClaw.NET 的桥接层实施了一项精妙的拦截机制。在 Node.js 子进程初始化阶段，桥接脚本主动劫持并覆写了全局的 console.log 与 console.info 对象，强制将所有日志输出重定向至操作系统的标准错误管道（stderr）。
随后的设计更是神来之笔：.NET 父进程并没有简单地丢弃这些 stderr 输出，而是开启了一个专门的异步线程对其进行读取。一旦监听到 JS 插件发出的日志，C# 网关便将其原生路由接入底层的 Microsoft.Extensions.Logging 管道体系中。如此一来，系统不仅完美保护了 JSON-RPC 管道的纯洁性，还让原本处于黑盒状态的 JavaScript 插件直接获得了 C# 企业级结构化日志体系（Structured Logging）的全面支持。运维人员可以在单一的监控面板中，无缝追踪 C# 核心引擎与底层 Node.js 插件的综合运行状态。
物理级别的沙箱安全与供应链投毒防御

在实现零代码修改兼容海量生态的同时，OpenClaw.NET 的双进程架构意外地（或者说必然地）解决了原生系统最大的梦魇——安全隔离。这种架构从物理级别强制执行了零信任（Zero Trust）与最小权限原则。
在这一模型下，不可信的第三方 JS 代码被永远囚禁于一个独立的子进程沙箱之中。这个 Node.js 进程只负责执行具体的工具逻辑，它没有权限读取上层网关的环境变量，无法触碰包含 OpenAI/Anthropic API 密钥的敏感配置，也绝对拿不到用于与 Telegram、Discord 维持连接的网关通信 Token。
限制爆炸半径（Blast Radius）

如果系统遭到供应链投毒攻击——例如某个广受欢迎的 ClawHub 插件被黑客注入了恶意代码，试图通过内存溢出攻击（OOM）崩溃系统，或是进入无限死循环消耗 CPU 资源——受损的仅仅是这个 Node.js 子进程。
当 Node 进程崩溃或失去响应时，C# 主控网关凭借着底层的异常捕获机制，能够瞬间感知到管道的中断。由于 C# 主进程拥有完全的确定性且稳如泰山，它不仅不会随着插件崩溃，反而可以记录安全警报、切断异常会话，并在毫秒级重新孵化（Spawn）一个新的 Node.js 子进程来恢复服务 。这种架构将曾经能够导致整个 AI 智能体系统瘫痪的致命攻击，成功降维成了一个可随时被重启隔离的子进程故障，极大地降低了企业在生产环境中应用开源 AI 能力的风险。
强化的默认安全态势（Hardened Defaults）

为了配合底层的进程沙箱，OpenClaw.NET 的 C# 核心层还实施了严苛的安全拦截规则。对于可能引发灾难性后果的系统级原生工具（如能够执行终端命令的 shell 工具），系统默认要求显式的操作审批（RequireToolApproval: true）。更为严谨的是，当智能体被配置为绑定在公网 IP（Public Bind）提供服务时，系统会默认拒绝挂载任何使用通配符授权的目录路径，甚至直接在启动阶段禁用高危工具，以此彻底杜绝远程提示词注入（Prompt Injection）演变为任意代码执行（RCE）的路径。
架构经济学与未来展望

综上所述，由 clawdotnet 构建的 OpenClaw.NET 展现了当代软件架构中极为罕见的设计深度与工程平衡感。通过运用 C# 13 与 NativeAOT 技术，它在一举扫除了原生 Node.js 系统内存膨胀与冷启动延迟的同时，极大地提升了系统在边缘设备与 Serverless 环境中的资源经济学与部署密度。
通过引入 Microsoft.Extensions.AI 的深度抽象机制，它不仅瓦解了各家大模型厂商 SDK 的强绑定，实现了高度标准化的接口契约流转，更将复杂的 JSON Schema 序列化下放至底层，赋予了系统面对未来无限模型变局的“前向兼容”能力。
最令人瞩目的是其在生态兼容与安全隔离之间的巧妙破局。凭借精妙的“插件桥接”与 JSON-RPC 本地管道通信，OpenClaw.NET 在完美继承原生生态中七百多项开源结晶的同时，彻底封锁了第三方代码对核心网关的内存访问与权限窃取，确立了物理级别的沙箱屏障 3。
OpenClaw.NET 的成功不仅是对一个流行开源工具的高性能重构，更是向整个生成式 AI 行业发出的强烈信号：AI 智能体的探索期已然结束。当企业级用户开始追求确定性、安全性与极致性能时，以 C# 与 AOT 为代表的静态编译型微服务范式，正成为承载下一代自主智能基础设施的不二之选。
引用的著作

• Deep Dive into OpenClaw: Architecture, Code & Ecosystem | by John Ding - Medium https://medium.com/@dingzhanjun/deep-dive-into-openclaw-architecture-code-ecosystem-e6180f34bd07
  
• The Claw Family: Top 5 OpenClaw Variants Compared to the Original - Medium https://medium.com/@pchojecki/the-claw-family-top-5-openclaw-variants-compared-to-the-original-64d8342712dd
  
• Openclaw.net | Hacker News https://news.ycombinator.com/item?id=47107820
  
• [Bug]:spawn EBADF error on macOS with Node.js 22+ preventing child process execution (Exec tool failure) #8021 - GitHub https://github.com/openclaw/openclaw/issues/8038/linked_closing_reference?reference_location=REPO_ISSUES_INDEX
  
• Consider memory-efficient architecture for lightweight deployment · Issue #18947 - GitHub https://github.com/openclaw/openclaw/issues/18947
  
• OpenClaw.NET Tool Guide - GitHub https://github.com/clawdotnet/openclaw.net/blob/main/TOOLS_GUIDE.md
  
• Built a comparison: OpenClaw vs memory-first local agent [results inside] - Reddit https://www.reddit.com/r/LocalLLaMA/comments/1qy2fwe/built_a_comparison_openclaw_vs_memoryfirst_local/
  
• Reduce serverless .NET cold start times by up to 70% with Native AOT : r/dotnet - Reddit https://www.reddit.com/r/dotnet/comments/v2kc8g/reduce_serverless_net_cold_start_times_by_up_to/
  
• AWS Lambda battle 2021: performance comparison for all languages (cold and warm start) https://filia-aleks.medium.com/aws-lambda-battle-2021-performance-comparison-for-all-languages-c1b441005fd1
  
• OpenClaw security: architecture and hardening guide - Nebius https://nebius.com/blog/posts/openclaw-security
  
• [Bug]:exec tool fails with "spawn EBADF" - child process PIPE leak in Gateway - GitHub https://github.com/openclaw/openclaw/issues/16008
  
• Running OpenClaw safely: identity, isolation, and runtime risk | Microsoft Security Blog https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/
  
• How to Enable Native AOT in .NET 8: A Step-by-Step Guide with Performance Benchmark https://www.avidclan.com/blog/how-to-enable-native-aot-in-dot-net-8-a-step-by-step-guide-with-performance-benchmark/
  
• OpenClaw.NET— AI Agent Framework for .NET with TypeScript Plugin Support | Looking for Collaborators : r/dotnet - Reddit https://www.reddit.com/r/dotnet/comments/1rn54rq/openclawnet_ai_agent_framework_for_net_with/
  
• Building .NET Lambda functions with Native AOT compilation in AWS SAM - AWS Serverless Application Model - AWS Documentation https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/build-dotnet7.html
  
• Should I convert .Net Web Api to native AOT ? : r/dotnet - Reddit https://www.reddit.com/r/dotnet/comments/19cbpy0/should_i_convert_net_web_api_to_native_aot/
  
• Microsoft.Extensions.AI libraries - .NET https://learn.microsoft.com/en-us/dotnet/ai/microsoft-extensions-ai
  
• Integrating LLMs into .NET Applications with Microsoft.Extensions.AI | by Vaishnavi Akkewar https://medium.com/@vaishnaviakkewar19/integrating-llms-into-net-applications-with-microsoft-extensions-ai-96fbae2b2b3d
  
• Microsoft.Extensions.AI.OpenAI 10.3.0 - NuGet Gallery https://www.nuget.org/packages/Microsoft.Extensions.AI.OpenAI
  
• openclaw.net/USER_GUIDE.md at main · clawdotnet/openclaw.net · GitHub https://github.com/clawdotnet/openclaw.net/blob/main/USER_GUIDE.md
  
• Integrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration https://techcommunity.microsoft.com/blog/educatordeveloperblog/integrating-microsoft-foundry-with-openclaw-step-by-step-model-configuration/4495586
  
• ChatClientBuilder Class (Microsoft.Extensions.AI) https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.ai.chatclientbuilder?view=net-10.0-pp
  
• openclaw repositories - GitHub https://github.com/orgs/openclaw/repositories
  
• OpenClaw Setup Guide: 25 Tools + 53 Skills Explained | WenHao Yu https://yu-wenhao.com/en/blog/openclaw-tools-skills-tutorial/
  
• Designing Architectural Jaywan Domestic Card Scheme Integration for a UAE Banks | by Seyhun AKYÜREK | Medium https://medium.com/@seyhunak/designing-architectural-jaywan-domestic-card-scheme-integration-for-a-uae-banks-002181f68680
  
• Modernising Enterprise Systems Without Breaking Production: Strangler Fig, Parallel Run, and Gateway Traffic Modes in Practice - Medium https://medium.com/towardsdev/modernising-enterprise-systems-without-breaking-production-strangler-fig-parallel-run-and-38bd49a812e5
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！