RuleGo v0.36.0：当规则引擎长出 Agent 的骨骼

预计阅读时间：11 分钟

规则引擎和 AI Agent，听起来像两个世界的东西——前者是确定性的条件分支，后者是概率性的推理决策。RuleGo v0.36.0 把它们焊到了一起：rulego-components-ai 从组件库正式升级为声明式 AI Agent 开发框架，Server 模块也从示例项目蜕变为可部署的服务端。这意味着你不再需要在外部编排 Agent 调用链，再手动把结果喂回规则引擎——两者在同一套声明式体系里闭环了。

规则引擎的底子，Agent 的脑子

RuleGo 的核心抽象是规则链：一条 JSON 定义的有向图，节点是组件，边是关系分支（成功/失败/自定义路径）。物联网设备上报温度 → 过滤异常值 → 判断阈值 → 触发告警，整条链路声明在 JSON 里，运行时动态加载、热更新，不需要改 Go 代码。

v0.36.0 之前，rulego-components-ai 只是这条链上的几个节点：调 OpenAI、做文本分类、提取关键词。你得自己拼 Agent 的循环逻辑——记忆管理、工具调用、多轮对话——全靠外部胶水代码。

升级之后，框架直接在规则链层面提供了 Agent 所需的循环结构、记忆注入点和工具注册机制。一条规则链本身就是一个 Agent 的执行蓝图。

声明式 Agent：JSON 里写完一个推理循环

传统 Agent 框架（LangChain、AutoGen）用 Python 代码编排推理循环。RuleGo 的做法不同：Agent 的感知→推理→行动→记忆回路，全部声明在规则链 JSON 里。好处是——运行时可以热替换任意节点，不需要重启服务。

下面是一个最小但完整的"文档问答 Agent"规则链定义：

{
  "id": "doc_qa_agent",
  "name": "文档问答Agent",
  "nodes": [
    {
      "id": "user_input",
      "type": "mqtt",
      "configuration": {
        "topic": "agent/input/#"
      }
    },
    {
      "id": "memory_load",
      "type": "aiMemory",
      "configuration": {
        "scope": "conversation",
        "maxTokens": 4000
      }
    },
    {
      "id": "llm_reason",
      "type": "aiLlm",
      "configuration": {
        "provider": "openai",
        "model": "gpt-4o-mini",
        "systemPrompt": "你是一个文档助手。根据上下文和工具结果回答用户问题。如果需要查文档，调用 search_doc 工具。",
        "temperature": 0.3
      }
    },
    {
      "id": "tool_dispatch",
      "type": "aiToolCall",
      "configuration": {
        "tools": ["search_doc", "summarize"]
      }
    },
    {
      "id": "search_doc",
      "type": "aiTool",
      "configuration": {
        "name": "search_doc",
        "description": "在知识库中搜索相关文档片段",
        "endpoint": "http://localhost:8080/api/search"
      }
    },
    {
      "id": "summarize",
      "type": "aiTool",
      "configuration": {
        "name": "summarize",
        "description": "对长文本生成摘要",
        "endpoint": "http://localhost:8080/api/summarize"
      }
    },
    {
      "id": "memory_save",
      "type": "aiMemory",
      "configuration": {
        "action": "save",
        "scope": "conversation"
      }
    },
    {
      "id": "output",
      "type": "mqtt",
      "configuration": {
        "topic": "agent/output/${metadata.conversationId}"
      }
    }
  ],
  "edges": [
    {"from": "user_input",    "to": "memory_load",   "relation": "success"},
    {"from": "memory_load",   "to": "llm_reason",    "relation": "success"},
    {"from": "llm_reason",    "to": "tool_dispatch", "relation": "tool_call"},
    {"from": "llm_reason",    "to": "memory_save",   "relation": "direct_answer"},
    {"from": "tool_dispatch", "to": "search_doc",    "relation": "search_doc"},
    {"from": "tool_dispatch", "to": "summarize",     "relation": "summarize"},
    {"from": "search_doc",    "to": "llm_reason",    "relation": "success"},
    {"from": "summarize",     "to": "llm_reason",    "relation": "success"},
    {"from": "memory_save",   "to": "output",        "relation": "success"}
  ]
}

关键设计点：

循环结构在图里自然形成：tool_dispatch → search_doc → llm_reason → tool_dispatch，工具调用结果回到 LLM 重新推理，直到 LLM 输出 direct_answer 跳出循环。不需要 while 循环代码。
记忆节点独立：aiMemory 的加载和保存分属不同节点，你可以插入任意中间处理而不破坏记忆流。
关系分支即控制流：relation 字段决定走哪条边——tool_call、direct_answer、success，这比硬编码 if-else 灵活得多。

嵌入式启动：三行 Go 代码跑起来

RuleGo 是嵌入式引擎，不需要独立部署一个服务（当然 v0.36.0 的 Server 模块也可以独立跑）。最简嵌入方式：

package main

import (
    "fmt"
    "github.com/rulego/rulego"
    "github.com/rulego/rulego-components-ai"
)

func main() {
    // 加载上面定义的规则链 JSON
    chainDef := []byte(`...你的规则链JSON...`)

    // 创建引擎实例
    engine, err := rulego.New("doc_qa_engine", chainDef,
        rulego.WithComponentsAi(ai.Components()), // 注册 AI 组件集
    )
    if err != nil {
        panic(err)
    }

    // 模拟一条用户消息进入规则链
    ctx := rulego.NewContext()
    ctx.Metadata.Put("conversationId", "conv-001")
    msg := rulego.NewMsg("mqtt", []byte("如何配置RuleGo的规则链？"), rulego.JSON, ctx.Metadata)

    engine.OnMsg(msg)

    // 结果会通过规则链的 output 节点发出
    // 嵌入场景下可以注册回调接收
    engine.OnCreated(func(chain rulego.RuleChain) {
        fmt.Println("规则链已加载:", chain.GetId())
    })
}

运行前需要：

go mod init 并 go mod tidy 拉取 rulego 和 rulego-components-ai
配置 OpenAI API Key 环境变量：export OPENAI_API_KEY=sk-xxx
如果用了 MQTT 节点，本地跑一个 MQTT broker（比如 docker run -p 1883:1883 emqx/emqx）
知识库搜索和摘要接口需要自己实现，或者把 search_doc/summarize 节点换成其他内置组件

Server 模块：从示例到生产骨架

v0.36.0 另一个变化是 Server 模块不再只是"怎么用 RuleGo 的 demo"。它现在提供了：

REST API 端点管理规则链的 CRUD 和热更新
Webhook 触发器，接收外部事件注入规则链
内置的 AI Provider 配置管理（OpenAI / Azure / 本地模型统一配置）

快速启动 Server：

# 克隆仓库
git clone https://github.com/rulego/rulego.git
cd rulego/server

# 配置 AI Provider
cat > config/ai.yml << 'EOF'
providers:
  openai:
    apiKey: "${OPENAI_API_KEY}"
    baseUrl: "https://api.openai.com/v1"
    defaultModel: "gpt-4o-mini"
EOF

# 启动
go run main.go

# 通过 API 加载规则链
curl -X POST http://localhost:8080/api/chain \
  -H "Content-Type: application/json" \
  -d @doc_qa_agent.json

什么时候该选这条路

RuleGo 的声明式 Agent 不是万能方案，它的优势边界很清晰：

适合的场景： - 物联网 / 边缘计算——设备事件驱动，规则链天然适配流式数据 - 数据集成管道——ETL 逻辑频繁变更，热更新比改代码再部署快得多 - 多工具 Agent——工具种类多、调用组合多变，图结构比线性代码好维护 - 需要运行时动态调整 Agent 行为——比如 A/B 测试不同 prompt 或工具组合

需要斟酌的场景： - 纯对话型 Agent——如果只有一轮 LLM 调用加记忆，LangChain 的 Python 链更简单 - 复杂推理规划——需要 Tree-of-Thought、MCTS 等搜索策略时，规则链的图结构表达力不够 - 团队全是 Python 选手——Go 嵌入式引擎的学习成本需要考虑

落地前的检查清单：

检查项	说明
AI Provider 配置	OpenAI / Azure / 本地模型的 API Key 和 BaseURL 是否就绪
工具端点可用性	Agent 调用的每个外部工具接口是否可达、超时设置是否合理
记忆存储后端	`aiMemory` 默认用内存，生产环境需要切换 Redis 或数据库
规则链版本管理	JSON 定义纳入 Git，热更新走 API 但要有回滚机制
循环深度限制	工具调用回环可能无限循环，设置 `maxIterations` 防护

RuleGo v0.36.0 做了一件有意思的事：它没有另起炉灶造一个 Agent 框架，而是让已有的规则引擎图结构长出 Agent 的循环和记忆能力。如果你已经在用 RuleGo 处理业务规则，现在可以在同一条链上接入 LLM 推理——不需要两套系统、两种编排语言。如果你是第一次接触，从上面的 JSON 规则链开始，三行 Go 代码嵌入，比大多数 Agent 框架的起步成本要低。