文章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

文章来源:https://www.cnblogs.com/kklldog/p/19827135/agile-ai
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！