AgileAI .NET AI库，如何实现高效处理？

AgileAI：在 SK、MAF 之外，我想做一个更顺手的 .NET AI 组件 如果把 .NET 生态里的 AI 组件放在一起看，大家最熟悉的通常还是 Semantic Kernel，去年开始微软也在持续推进 Microsoft Agent Framework（MAF）。但在我自己的实践里，这条路线虽然值得关注，却并不总是足够顺手：MAF 长期带着比较明显的 preview / prerelease 色彩，而真正拿它去快速拼一个能跑、能扩展、还能继续往产品层走的东西，体验也没有我期待得那么轻。 于是我开始想： 在 .NET 世界里，除了 SK 和 MAF 之外，能不能有另一种更轻量、更直接、更适合快速做 AI 应用和 Agent 的组件化方案？ 这就是 AgileAI 的起点。 对我来说，AgileAI 也是一次 AI 编程实验。整个项目从头到尾全部由 AI 完成，我本人没有手写一行代码。而它给出的答案是：可以，而且已经接近能持续演进的程度。 AgileAI 是什么？ 一句话说，AgileAI 是一个面向 .NET 的 AI SDK / Agent 组件，同时仓库里还自带一个本地优先的 AI 工作台 AgileAI.Studio。 懒的读文字的可以看视频 它大致分成两层： 第一层：底层 SDK / Runtime 这一层主要用来： 快速接入不同 LLM 管理对话和流式输出 支持 Tool Calling 管理 Session 持久化 支持 Skill 提供 Agent Runtime 第二层：上层产品 AgileAI.Studio 这一层主要负责： 可视化管理模型连接 创建 Agent 发起和保存对话 审批本地工具执行 展示工具/技能使用情况 作为一个真正的本地 AI 工作台运行 换句话说，它既可以被当成一个 .NET AI 开发组件，也可以被当成一个 完整可运行的本地 AI 产品原型。 AgileAI 能做什么？ 如果只看结果，AgileAI 主要做了两件事： 1）快速对接 LLM AgileAI 当前支持的 Provider 包括： OpenAI Chat Completions OpenAI-compatible Chat Completions Azure OpenAI OpenAI Responses API Gemini Claude 如果你在 .NET 里做 AI 应用，不想每换一个模型供应商就改一套代码，AgileAI 提供了一层统一抽象，让你可以用相对一致的方式发起请求、处理响应、接流式输出和工具调用。 它底层的核心接口围绕这些概念组织： IChatClient IChatModelProvider IChatSession IAgentRuntime 这套抽象的意义，不只是“写得优雅”，而是实实在在地降低了切 Provider、切模型和做统一封装的成本。 2）快速打造 Agent 除了“调用模型”，AgileAI 更想解决的是“怎么快速搭一个 Agent”。 所以它在核心层里内建了这些东西： 多轮对话 ChatSession 流式响应 Tool Calling Session 持久化 Skill 选择和延续 Middleware 风格的执行拦截 本地工具注册与调用 它不是只解决“问模型一句话”，而是解决“让 Agent 真正运行起来”的那一层。 一个最简单的使用示例 如果你想快速感受 AgileAI 的风格，可以看一个非常典型的用法：先注册 Provider，然后创建 ChatSession，最后直接发请求。 下面这个例子来自文件系统工具 sample，挺能代表它的思路： using AgileAI.Abstractions; using AgileAI.Core; using AgileAI.DependencyInjection; using AgileAI.Extensions.FileSystem; using AgileAI.Providers.OpenAICompatible.DependencyInjection; using Microsoft.Extensions.DependencyInjection; var services = new ServiceCollection(); services.AddAgileAI(); services.AddOpenAICompatibleProvider(options => { options.ProviderName = "openapi"; options.ApiKey = Environment.GetEnvironmentVariable("OPENAI_COMPATIBLE_API_KEY")!; options.BaseUrl = Environment.GetEnvironmentVariable("OPENAI_COMPATIBLE_BASE_URL")!; options.RelativePath = "chat/completions"; }); var serviceProvider = services.BuildServiceProvider(); var chatClient = serviceProvider.GetRequiredService<IChatClient>(); var toolRegistry = new InMemoryToolRegistry() .RegisterFileSystemTools(options => { options.RootPath = @"D:\workspace\MyProject"; options.MaxReadCharacters = 12000; }); var session = new ChatSessionBuilder(chatClient, "openapi:gpt-5.4") .WithToolRegistry(toolRegistry) .Build(); var response = await session.SendAsync( "Use search_files to find mentions of AgileAI.Studio, then use read_files_batch to inspect the best matching files and summarize them."); Console.WriteLine(response.Message?.TextContent); 这个例子很能说明 AgileAI 的定位： 先接上模型 再注册工具 然后直接进入 Agent 式调用 中间没有太重的 ceremony，也没有一大堆必须先理解完才能开始用的框架概念。它的目标很明确： 尽快跑起来。 内置 Tool：不仅能调用，还考虑了安全边界 AgileAI 里很值得单独拿出来说的一块，是它的 tool 系统。 文件系统工具 仓库里已经实现了一组本地文件系统工具，包括： list_directory search_files read_file read_files_batch write_file 除此之外，源码里其实还实现了更多文件操作工具，比如： create_directory move_file patch_file delete_file delete_directory 它不只是一个“让模型看文件”的小插件，而是已经开始具备比较完整的本地工作区操作能力。 run_local_command 这是 Studio 里最关键的一个工具之一。 它允许 Agent 请求执行本地命令，比如 shell / bash / pwsh 命令。 但这里最重要的不是“它能执行命令”，而是： 它不是直接执行，而是走审批流程。 也就是： 模型提出命令执行请求 系统暂停当前工具流程 用户看到待执行命令 用户手动批准或拒绝 批准后再继续后续执行 这个设计很关键。因为 AI Tool Calling 真正落地时，最大的风险之一就是本地执行能力。AgileAI 没有回避这件事，而是把它做成了显式审批流程。 web_fetch Studio 里还内置了一个 web_fetch 工具，可以让 Agent 拉取网页内容。 这类工具看起来简单，但很有用。只要进入 Agent 场景，你很快就会遇到“需要主动获取外部信息”的问题。与其让调用端自己绕很多逻辑，不如把它收敛成统一的 tool 能力。 Skill 支持：让 Agent 有“角色能力包” AgileAI 的另一个亮点，是它支持 Skill。 这里的 Skill，不是那种非常重的插件生态，而更像是： 一组基于本地文件、带有元信息和提示约束的能力包。 仓库里 Skill 的实现包括： 本地 Skill 文件加载 Skill Manifest 解析 Skill Registry Skill Planner Skill Continuation Policy Prompt-based Skill Execution AgileAI.Studio：全功能演示项目 如果说前面的 AgileAI 更像“底层能力”，那 AgileAI.Studio 就是它的产品化形态。 Studio 的技术栈很直接： 后端：ASP.NET Core + EF Core + SQLite 前端：Vue 3 + Vite + Pinia + Naive UI 通信方式：REST + SSE 流式响应 测试：Playwright 它目前已经能完成这些事情： 配置 Provider Connection 添加和测试模型 创建 Agent 管理会话 流式聊天 显示 Tool 使用记录 显示 Skill 使用状态 对 run_local_command 进行审批 用 web_fetch 拉网页内容 也就是说，Studio 已经不是一个“摆拍式 Demo UI”，而是一个有真实工作流的本地 AI Workspace 雏形。 几张 Studio 截图 仓库里已经带了几张 Playwright 生成的截图，正好能对应它现在的几个主要页面。 Models 页面 这里可以管理模型连接和模型配置。 如果你要做一个真正能切换不同 Provider 的 AI 工作台，这一页其实是基础中的基础。 Agents 页面 这一页是 Agent 的核心配置区。 你可以在这里定义： Agent 名称 Prompt 温度 最大 Token 可用 tools 可用 skills Chat 页面 这是 Studio 最像“产品”的部分。不仅能聊天，还能看到： 流式回复 Agent 当前使用的 skill 用过哪些 tools 工具审批状态 历史会话列表 结语 如果你最近正打算使用 .NET 来开发 Agent 或许可以试试这个新的框架 AgileAI 。有什么意见或者建议都可以给我提 Issue。 👉👉👉 https://github.com/kklldog/AgileAI