通用 AI 调度引擎：让任何桌面软件获得 AI 能力
个人项目 · 2026 年 5 月启动 · 原型验证通过 · 已全部开源
🔗 Gitee：https://gitee.com/GahooChan/ai_-scheduler 📜 License：MulanPSL-2.0
🎬 项目演示视频
我为什么做这个
我在 CAM / 工控领域干了几年，接触了大量制造业企业的软件团队。一个反复出现的痛点是：
企业有接入 AI 的强烈需求，但工程师搞不定。
不是不想做，是现实条件不允许。这些团队的现状通常是：
- 技术栈固定：主力语言是 C++，撑死再加个 C#（调用 COM 接口）。Python？没接触过。Node.js？听都没听过。
- 没有 AI 基建：公司不会为了一个 AI 功能专门招一个算法团队，也不会花几个月搭建 LLM 调度基础设施。
- 时间窗口极短：老板说"下个版本要支持智能操作"，给的时间是几天，不是几周。
- 业务不能停：现有软件还在维护、客户还在提需求，不可能停下来重构架构去适配 AI。
所以他们面临一个尴尬的选择：要么放弃 AI 功能，要么硬上——结果就是写出一堆不可维护的胶水代码，AI 调用全靠 if/else 硬编码，换个模型要改几十处。
我的框架解决的就是这个问题：让一个只懂 C++ 的工程师，用半天到两天时间，就能让自己的软件具备完整的 AI 能力。
不需要学 Python，不需要搭后端服务，不需要理解 Transformer 架构。你只需要实现 4 个回调函数（总共约 100 行代码），注册你的工具列表，剩下的——多轮对话调度、工具调用循环、去重校验、深度限制、MCP 协议对接、HTTP API 暴露——全部由引擎接管。
核心：AI 调度引擎
这是一个 260KB 的 C ABI DLL，零运行时依赖，嵌入你的软件后提供三个核心能力：
引擎不绑定任何 LLM，不绑定任何软件。 它只做一件事：调度——接收用户意图，驱动 LLM 推理，调用你的工具 API，把结果写回对话，循环直到任务完成。
三条通路：一个内核，三种接入方式
调度引擎对外暴露三条通路，共享同一套工具注册表，但会话上下文完全隔离：
通路一：内部对话（C ABI 直接调用）
在你的软件界面里嵌入一个聊天窗口，用户用自然语言下达指令，AI 自动调用你的软件 API 完成任务。
通路二：MCP 外接（标准协议）
外部 AI 工具（Trae、Cursor、Claude Desktop）通过 MCP 标准协议直接操控你的软件。
价值：开发者在自己熟悉的 AI 工具里，直接用自然语言操控目标软件。不需要切换窗口，说人话就行。
通路三：Skill 外接口（HTTP REST API）
低代码 AI 平台（Dify、Coze 等）通过 HTTP REST API 调用工具。
价值：上传一个 Skill 提示词文件（SKILL.md），Dify/Coze 就能自动识别你的软件能力，零代码集成。非技术人员也能通过对话式 AI 操控专业软件。
生态：多软件串联成业务工作流
这是框架最核心的想象力——不是让一个软件变聪明，而是让多个软件协同工作。
每款软件都嵌入了同一个 ai_core（Rust 编译出的 C ABI DLL），各自注册了自己的工具。上层的 AI 编排层通过 MCP 或 HTTP 协议，逐一调用各软件的工具，像搭积木一样把整个流程串起来。
为什么这个架构能成？
- 统一协议：所有软件通过同一套 MCP/HTTP 接口暴露能力，编排层不需要关心底层差异
- 会话隔离：每个软件的工具调用跑在独立的 Session 里，互不干扰
- 工具发现：编排层可以动态查询每个软件支持哪些工具，自动适配
- 零耦合：软件之间不直接通信，全部通过编排层调度，修改任一软件不影响其他
举几个例子
- 设计→仿真→优化：软件 A 建模 → 软件 B 仿真 → 分析结果 → 自动修改参数 → 再仿真 → 收敛到最优解
- 数据处理→报表：软件 A 采集数据 → 软件 B 清洗分析 → 软件 C 生成可视化报表
- 内容创作→发布：软件 A 编辑 → 软件 B 渲染 → 软件 C 发布到平台
- 办公自动化：软件 A 填表 → 软件 B 审批 → 软件 C 归档 → 软件 D 通知
任何场景，只要软件能嵌 DLL 并注册工具，就能接入这个 AI 工作流。
二次开发：半天到两天集成
集成框架只需做四件事，全部通过回调注入，不侵入你的原有代码：
1. 对接 LLM（stream_chat 回调）
int myStreamChat(void* user_data,
const char* messages_json, // 对话历史 JSON
const char* params_json, // 参数（temperature 等）
void (*on_chunk)(void* user_data, const char* chunk, int is_done),
const char** error_out)
{
// 把 messages_json 发给 OpenAI / Ollama / DeepSeek / 任何兼容 API
// 流式读取响应，每个 token 调一次 on_chunk(chunk, false)
// 结束时调 on_chunk("", true)
return 0;
}2. 对接软件 API（execute_tool 回调）
char* myExecuteTool(void* user_data, const char* tool_call_json)
{
// {"tool":"myapp.do_something","arguments":{...}}
// 解析 tool_call_json → 调你的软件 API → 返回执行结果 JSON
return strdup("{\"result\":\"done\"}");
}3. 注册工具（告诉 AI 你能做什么）
ai_core_register_tool(ctx, "myapp", "do_something",
"做什么事", // 简介
"参数: foo(类型), bar(类型)", // 帮助文档
R"({"type":"object","properties":{...},"required":[...]})"); // JSON Schema每注册一个工具，AI 就知道它可以调用这个操作，以及参数长什么样。工具注册后，自动通过 MCP 和 HTTP 接口对外暴露。
4. 启动服务
void* ctx = ai_core_init(&callbacks, config_json);
registerAllTools(ctx); // 注册你的工具
ai_core_start_mcp_server(ctx, 9876); // 开启 MCP 外部接入
ai_core_start_http_server(ctx, 9877); // 开启 HTTP Skill 外接
uint64_t sid = ai_core_create_session(ctx); // 创建对话
ai_core_send(ctx, sid, "帮我做XXX", nullptr); // 开始对话完整 C ABI 接口一览
// 生命周期
void* ai_core_init(const ai_core_callbacks_t* cb, const char* config_json);
void ai_core_destroy(void* ctx);
// 会话管理
uint64_t ai_core_create_session(void* ctx);
void ai_core_destroy_session(void* ctx, uint64_t session_id);
// 对话
char* ai_core_send(void* ctx, uint64_t sid, const char* msg, const char* tmpl);
void ai_core_cancel(void* ctx, uint64_t session_id);
void ai_core_clear_context(void* ctx, uint64_t session_id);
// 工具注册
void ai_core_register_tool(void* ctx, const char* module, const char* name,
const char* brief, const char* help_doc, const char* json_schema);
// 配置
int ai_core_update_config(void* ctx, const char* config_json);
// 外部接入
int ai_core_start_mcp_server(void* ctx, uint16_t port);
void ai_core_stop_mcp_server(void* ctx);
int ai_core_start_http_server(void* ctx, uint16_t port);
void ai_core_stop_http_server(void* ctx);
// 内存
void ai_core_free_string(char* s);支持的语言
C ABI 意味着任何能调 DLL 的语言都能集成：
- C / C++（原生）
- C#（DllImport + Marshal）
- Python（ctypes / cffi）
- Java（JNI）
- Go（cgo）
- Rust / Delphi / 任何 FFI 支持的语言
拿 AutoCAD 验证了什么
AutoCAD 是验证平台，用来证明框架能跑通所有通路。56 个工具覆盖了绘图创建、图元修改、选择查询、图层管理、块操作、视图控制、属性修改、文件操作、系统变量、样式管理十个分类。
| 验证项 | 状态 |
|---|---|
| 56 个工具注册并通过 MCP 调用 | ✓ |
| 内部对话完整链路（UI → 引擎 → LLM → 工具 → 回显） | ✓ |
| MCP 外部链路（Trae → bridge.py → 引擎 → 工具） | ✓ |
| HTTP REST API 链路（Dify/Coze → HTTP → 引擎 → 工具） | ✓ |
| 会话隔离（内部 / MCP / HTTP 各自独立上下文） | ✓ |
| 复杂多步任务（汽车侧视图、相切圆布局、多段线） | ✓ |
| 参数校验失败后 AI 自动重试 | ✓ |
为什么选这些技术栈
验证平台和工具链的选择背后有一些实际考量，分享一下：
为什么是 AutoCAD 2018？
AutoCAD 是一个现成的、功能丰富的软件平台，有大量已实现的操作（绘图、图层、块、标注等），不需要自己造轮子。拿它做验证，可以专心验证框架本身——调度循环、工具注册、会话隔离、通路切换——而不是被软件的功能实现分散精力。
选 2018 版本纯粹是因为我接触过 ObjectARX 2018 的二次开发，对它最熟悉。换个版本、换个 CAD 软件本质上没有区别，实现的 execute_tool 回调换一下就行了。
为什么 UI 用 Qt？
我本地只有 VS2026，而 AutoCAD 2018 的 ObjectARX SDK 需要 VS2015 的 MSVC 编译链。为了一个验证项目专门安装老版本编译链实在没必要。MFC 依赖那个特定版本的 MSVC，而 Qt 不挑编译器——Qt 5.15.2 + MSVC 2019 就能跑，跟 VS2026 的向后兼容性也很好。几行 CMake 配好，windeployqt 自动部署依赖，开发体验远好于 MFC。
说到底，UI 框架对框架本身不重要，Qt 只是刚好最省事。
命令怎么送到 AutoCAD？
execute_tool 回调收到工具调用后，通过 ARX 的 sendStringToExecute 直接发送原生命令字符串到 AutoCAD 命令行执行。原理很简单——就是把 AI 解析出的工具名和参数，翻译成 AutoCAD 能理解的命令文本：
AI 调用 cad.create_circle(center=[0,0], radius=200)
→ 翻译成 AutoCAD 命令: "CIRCLE 0,0 200"
→ sendStringToExecute 发送
→ AutoCAD 执行并返回结果没有 COM 自动化，没有额外的进程通信，就是最朴素的命令字符串。每个命令前加 ^C^C 前缀清除 AutoCAD 的残留命令状态，防止上一个命令没退出导致后续命令失败。
仓库结构
ai_scheduler/
├── CAD_Plugin/ # CAD 插件层（C++ / Qt / ObjectARX 2018）
│ ├── Arx/ # ObjectARX 实现（命令回调、MCP 回调、工具执行器）
│ └── PluginCore/ # Qt UI 层（聊天窗口、AI 桥接、设置面板）
├── ai_agent/ # AI 调度引擎（Rust，C ABI 导出）
│ └── src/
│ ├── agent.rs # 核心调度逻辑
│ ├── config.rs # 配置管理
│ ├── context.rs # 会话上下文
│ ├── mcp_server.rs # MCP 协议服务
│ ├── http_server.rs # HTTP REST 服务
│ └── tools.rs # 工具注册表
├── doc/ # 项目文档
│ ├── architecture.md
│ ├── mcp_interface_spec.md
│ └── plugin_development.md
├── tools/
│ └── mcp_bridge.py # Python MCP 桥接脚本
├── CMakeLists.txt # CMake 构建配置
├── CMakePresets.json # CMake 预设
└── LICENSE # MulanPSL-2.0语言占比：C++ 62.8% / Rust 25.4% / Python 10.2%
交付物
| 文件/目录 | 说明 | 类型 |
|---|---|---|
ai_agent/ | 核心调度引擎（Rust），零运行时依赖 | 开源 |
CAD_Plugin/ | AutoCAD 平台完整集成（56 工具，Qt UI + ObjectARX） | 开源 |
tools/mcp_bridge.py | MCP 桥接脚本，stdio ↔ TCP | 开源 |
doc/ | 架构文档、MCP 接口规范、插件开发指南 | 开源 |
SKILL.md | Skill 提示词模板，导入 Dify/Coze 即用 | 开源 |
与自研方案对比
| 用本框架 | 自己从零做 | |
|---|---|---|
| 调度循环 | 内置（去重、校验、深度限制、错误重试） | 自己写，逐个踩坑 |
| MCP 接入 | 内置，符合标准协议 | 自己实现 JSON-RPC + 工具发现 |
| HTTP Skill 外接 | 内置，一键开关 | 自己实现 HTTP Server + 路由 |
| 多会话 | 内置，自动隔离 | 自己设计 |
| 工具发现 | 自动，MCP 和 HTTP 同步暴露 | 手动维护 |
| 源码可读 | 全部开源，可直接参考实现 | — |
| 体积 | Rust 核心，轻量 | 取决于你写多少 |
| 集成周期 | 半天到两天 | 数周到数月 |
当前进度
- [x] 调度引擎 + 完整 C ABI 接口
- [x] 多会话架构 + 会话隔离
- [x] MCP Server + bridge.py 桥接
- [x] HTTP Server + Skill 外接口
- [x] AutoCAD 验证：56 工具全通路跑通
- [x] 复杂多步任务 + 外部 AI 平台接入验证
- [x] 项目已全部开源（Gitee）
- [ ] 多软件协同工作流 Demo
- [ ] 序列化快照（保存/恢复对话历史）
- [ ] 标准化错误码枚举
构建方式
# Rust 核心
cd ai_agent
cargo build --release
# CAD 插件（需要 ObjectARX SDK）
mkdir build && cd build
cmake ..
cmake --build . --config Release详细构建说明见仓库 README.md。
一些经验
- 不要让 AI 直接调 SDK。 中间加一层调度框架，做去重、校验、深度限制，否则 AI 会无限循环或者传错参数。
- 用回调代替硬编码。 LLM 和工具执行都通过回调注入，换模型、换宿主软件只需换回调实现。
- C ABI 是跨语言桥梁。 零序列化开销，零 IPC，任何语言都能调。
- System Prompt 比模型更重要。 工具的详细定义、参数说明、使用规则这些工程细节，比模型本身更影响效果。
- MCP 和 HTTP 同源。 两条通路共享同一套工具注册表，新增一个工具自动双端同步，不用维护两套代码。
- 多软件生态的本质是"统一协议"。 每款软件都嵌入同一个 DLL，对外暴露同一套接口，编排层不需要感知底层差异。
评论 (0)