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，挺能代表它的思路：

1. using AgileAI.Abstractions;
2. using AgileAI.Core;
3. using AgileAI.DependencyInjection;
4. using AgileAI.Extensions.FileSystem;
5. using AgileAI.Providers.OpenAICompatible.DependencyInjection;
6. using Microsoft.Extensions.DependencyInjection;
8. var services = new ServiceCollection();
10. services.AddAgileAI();
11. services.AddOpenAICompatibleProvider(options =>
12. {
13.     options.ProviderName = "openapi";
14.     options.ApiKey = Environment.GetEnvironmentVariable("OPENAI_COMPATIBLE_API_KEY")!;
15.     options.BaseUrl = Environment.GetEnvironmentVariable("OPENAI_COMPATIBLE_BASE_URL")!;
16.     options.RelativePath = "chat/completions";
17. });
19. var serviceProvider = services.BuildServiceProvider();
20. var chatClient = serviceProvider.GetRequiredService<IChatClient>();
22. var toolRegistry = new InMemoryToolRegistry()
23.     .RegisterFileSystemTools(options =>
24.     {
25.         options.RootPath = @"D:\workspace\MyProject";
26.         options.MaxReadCharacters = 12000;
27.     });
29. var session = new ChatSessionBuilder(chatClient, "openapi:gpt-5.4")
30.     .WithToolRegistry(toolRegistry)
31.     .Build();
33. var response = await session.SendAsync(
34.     "Use search_files to find mentions of AgileAI.Studio, then use read_files_batch to inspect the best matching files and summarize them.");
36. 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。


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