【ai_agent】从零写一个agent框架（三）实现几个示例中的service：llm，tool等

前言

上一篇文章里我们实现了一个基本的运行时，能够将service按照plan执行起来，本文我们尝试实现一些基本节点，最终运行一个最简单的agent。

代码仓库

1. Openai-llm

我们这里还是接openai的llm能力。

先定义一下模型的基本配置，只需要prompt temperature tools context这些简单的参数。

pub  struct LLMNodeRequest {
    #[serde(default = "String::default")]
    pub prompt: String,
    #[serde(default = "LLMNodeRequest::default_model_35")]
    pub model: String,
    #[serde(default = "Vec::default")]
    pub tools: Vec<ChatCompletionTool>,
    #[serde(default = "Vec::default")]
    pub context: Vec<LLMContextMessage>,

    #[serde(default = "LLMNodeRequest::max_tokens_length")]
    pub max_tokens: u16,
    #[serde(default = "LLMNodeRequest::default_temperature")]
    pub temperature: f32,
    #[serde(default = "bool::default")]
    pub is_stream: bool,

    pub query: String,
}

然后实现一下servic，我们这里用上篇文章中包装好的解析层：

impl agent_rt::ServiceLayer  for OpenaiLLMService {
    type Config = CfgBound<LLMNodeRequest>;
    type Output = LLMNodeResponse;

    async fn call(
        &self,
        _code: String,
        ctx: Arc<Context>,
        cfg: Self::Config,
    ) -> anyhow::Result<Self::Output> {
        // wd_log::log_debug_ln!("start call code[{}.{}.openai_llm]",ctx.code,code);
 let cfg = cfg.bound(&ctx) ? ;
        let req = cfg.to_openai_chat_request() ? ;
        let mut stream = self.openai_client.chat().create_stream(req).await ? ;

        let mut resp = LLMNodeResponse::default();
        while  let  Some(msg) = stream.next().await {
            let msg = match msg {
                Ok(o) => o,
                Err(e) => return  Err(anyhow::Error::from(e)),
            };
            for i in msg.choices {
                //文本消息
 if  let  Some(s) = i.delta.content {
                    if  let  Some(s) = Self::try_send_to_channel(&ctx, s) {
                        resp.append_answer(s.as_str());
                    }
                }
                //工具调用
 if  let  Some(tools) = i.delta.tool_calls {
                    resp.append_tools(tools);
                }
            }
        }
        // wd_log::log_debug_ln!("over call code[{}.{}.openai_llm]",ctx.code,code);
 Ok(resp)
    }
}

2.Tool

我们这里还是做通用设计，并不做具体的tool实现，而是抽象一下：

//tool事件发生器
pub trait ToolEvent: Send {
    async fn call(&self, name: &str, args: String) -> anyhow::Result<String>;
}
//tool service实现的结构体
pub struct ToolService {
    loader: Box<dyn ToolEvent + Sync + 'static>,
}

同样的实现一下*ServiceLayer*，当然这里就比较简单了，我们直接将事件call出去就可以了。

impl ServiceLayer  for ToolService {
    type Config = CfgBound<LLMToolCallRequest>;
    type Output = LLMToolCallResponse;

    async fn call(
        &self,
        code: String,
        ctx: Arc<Context>,
        cfg: Self::Config,
    ) -> anyhow::Result<Self::Output> {
        let cfg = cfg.bound(&ctx) ? ;

        let LLMToolCallRequest {call_id,name,args} = cfg;
        wd_log::log_debug_ln!("code[{}] exec tool[{}] args:{:?}", code, name, args);

        let content = self.loader.call(name.as_str(), args).await ? ;

        let resp = LLMToolCallResponse { call_id, content };
        wd_log::log_debug_ln!("code[{}] exec tool[{}] result[{:?}]", code, name, resp);
        Ok(resp)
    }
}

具体的实现可能是本地的rust函数，也能是个api接口，也能是其他脚本，这里用个枚举定义。

pub  enum Tool {
    Http(ToolHttp),
    Python(ToolPython),
    Custom(Arc<dyn ToolFunction + Sync + 'static>),
}

2.1 http实现

在实现具体的tool之前，思考一下，虽然大模型function call的时候，直接给出执行哪个函数，但是我们的多个api通常是在一个服务里，并且有相同的鉴权和签名方式，所以对于http的接口，我们需要先按组(plugin)包装。

所以在调用一个具体的api之前，先找到plugin，这里还是做一个抽象。具体实现可能是数据库或者其他服务加载出来的。

//加载plugin的抽象
pub  trait  PluginSchedule: Send {
    async  fn schedule(&self, plugin_name: &str, tool_name: &str) -> anyhow::Result<Plugin>;
}
//plugin调度器的实现的结构体
pub  struct PluginControl {
    pub schedule: Box<dyn PluginSchedule + Sync + 'static>,
}
//实现上面提到的事件发生器
impl  ToolEvent  for PluginControl {
    async  fn call(&self, name: &str, args: String) -> anyhow::Result<String> {
        let  mut list = name.split('.').into_iter().rev().collect::<Vec<&str>>();
        let plugin_name = list.pop().unwrap_or("");
        let tool_name = list.pop().unwrap_or("");
        let plugin = self.schedule.schedule(plugin_name, tool_name).await ? ;
        plugin.call(tool_name, args).await
}
}

//plugin的定义，统一的鉴权或者代理
pub  struct Plugin {
    pub auth: Option<Oauth>,
    pub server: Option<(String, u16)>, //addr port
 pub tools: HashMap<String, Tool>,
}

http的具体实现：

impl ToolHttp {
    pub  async  fn call(
        self,
        host: String,
        port: u16,
        content: String,
        auth: Option<Oauth>,
    ) -> anyhow::Result<String> {
  ...//实现略，就是组装http并发起请求
  }
}

2.2 rust函数实现

我们还是定义一个trait，并且为所有符合的函数做一个默认实现，如果下；

//函数的抽象
pub  trait  ToolFunction: Send {
    async  fn call(&self, args: String) -> anyhow::Result<String>;
}
//所有符合这个triat的函数的默认实现
impl<T, Fut> ToolFunction for T
where
T: Fn(String) -> Fut + Send + Sync + 'static,
    Fut: Future<Output = anyhow::Result<String>> + Send,
{
    async  fn call(&self, args: String) -> anyhow::Result<String> {
        self(args).await
}
}

2.3 python脚本实现

在实现之前先考虑几个问题：

为什么是python？

思考：老实说我并不喜欢python，我更倾向于lua这种短小轻快的脚本。在我之前写的规则引擎rush里，就用的lua脚本写规则。并且我对比过多个脚本的性能，lua可以甩python几条街。

但是，python是大众的选择，被更多的人接受，没得选，只能是它。

这里有屌大的就要说了，为啥不用js，不用wasm，它们用的人也很多。其实从平台化的角度讲，长远来看这哥俩也是要支持的。

能用本地的python执行吗？

肯定是不能，一般在服务端运行的脚本都要有个沙盒环境。并且为了避免不同本地环境造成的版本差异，包的差异等等，都不能用本地python环境。

…

以后单开一篇讲吧，要吐的槽太多了。

3. 流程节点

因为我们实现的是流程图策略，所以还需要实现一些功能无关的service，也就是流程图里面的节点。

3.1 分支

先看分支的定义，非常简短，一个数组盛放判断条件和变量，成功走true_goto节点，失败走false_goto节点

pub  struct SelectorServiceConfig {
    //分支判断的条件：或，且
    pub condition: String, 
 //三段式 var1 [comparator] var2
 //comparator ==,!=,>,>=,<,<=,is_null,no_null,contain,no_contain
 // if comparator is [is_null,no_null], do not need var2
 pub vars: Vec<Value>,
    pub true_goto: String,
    pub false_goto: String,
}

具体实现，同样的ServiceLayer

impl agent_rt::ServiceLayer for SelectorService {
    type Config = CfgBound<SelectorServiceConfig>;
    type Output = Value;

    async fn call(
        &self,
        code: String,
        ctx: Arc<Context>,
        cfg: Self::Config,
    ) -> anyhow::Result<Self::Output> {
        let cfg = cfg.bound(&ctx) ? ;
        let mut result = false;
        let all_true = cfg.condition == "且";
        //循环判断条件是否成立
        let mut vars = cfg.vars.into_iter().collect::<VecDeque<Value>>();
        loop {
            ...
            //具体的判断函数，就是根据判断条件，判断条件是否成立，返回bool结果
            let ok = Self::judge(&mut vars) ? ;
            ... //结果检查
        }
        //找到下个执行的节点
        let go_next_node = if result {
            cfg.true_goto
        } else {
            cfg.false_goto
        };
        ctx.plan.update(
            ...//修改执行计划中selector的下一个节点
        ) ? ;
        Ok(Value::Null)
    }
}

3.2 注入

这是为了修改某个节点的配置，比如给llm追加上下文。实现也很简单

impl agent_rt::ServiceLayer for InjectorService {
    type Config = CfgBound<InjectorServiceConfig>;
    type Output = Value;

    async  fn call(
        &self,
        _code: String,
        ctx: Arc<Context>,
        cfg: Self::Config,
    ) -> anyhow::Result<Self::Output> {
        let InjectorServiceConfig {
            from, to, operate, ..
        } = cfg.bound(&ctx) ? ;
        if to.is_empty() {
            return anyhow::anyhow!("InjectorService: from and to must have a value").err();
        }

        //from:修改的结果
        //operate：按照什么方式修改，目前只实现了赋值和追加操作
        //to：修改位置，就是修改哪个变量？
        Self::update(to, &ctx, |x| Self::operate(x, from, operate)) ? ;

        Ok(Value::Null)
    }
}

3.3 变量

这种节点不做任何事情，就是生成一个变量，一般start节点和end节点都是变量节点。

impl agent_rt::ServiceLayer for VarFlowChartService {
    type Config = CfgBound<Value>;
    type Output = Value;

    async  fn call(
        &self,
        _code: String,
        ctx: Arc<Context>,
        cfg: Self::Config,
    ) -> anyhow::Result<Self::Output> {
        let var = cfg.raw_bound_value(&ctx) ? ;
        Ok(var)
    }
}

4. CfgBound

上面的所有节点配置，都用的同样的绑定方式CfgBound来进行绑定，解释一下它是干啥的？

如下图中的选择节点，其中{{llm.tools}}的部分，表示这个变量来自llm节点的执行结果里的tools字段。

这种引用的变量肯定不能每个service都自己实现，就是在CfgBound中进行的绑定。

测试

测试用例地址

启动服务

上面实现的内容都在wd_agent中，我们想要作为服务提供服务，还需要和agent_rt结合起来一起运行，通过grpc调用。

代码仓库地址，总纲如下：

pub async fn start(addr: &str) {
    //create service
    let openai_llm = wd_agent::rt_node_service::OpenaiLLMService::default();
    let var = wd_agent::rt_node_service::VarFlowChartService::default();
    let python = PythonCodeService::new("http://127.0.0.1:50001")
        .await
        .unwrap();

    //build agent runtime
    let rt = agent_rt::Runtime::default()
        .register_service_layer("openai_llm", openai_llm)
        .register_service_layer("python", python)
        .register_service_layer("flow_chart_selector", SelectorService::default())
        .register_service_layer("flow_chart_injector", InjectorService::default())
        .register_service_layer("workflow", WorkflowService::default())
        .register_service_layer("flow_chart_var", var);

    //启动rpc服务
    let app = serve_entity::AgentServeEntity::new(rt);

    let addr = addr.parse().unwrap();

    wd_log::log_debug_ln!("grpc.Server lister addr[{}]", addr);

    tonic::transport::Server::builder()
        .add_service(proto::agent_service_server::AgentServiceServer::new(app))
        .serve(addr)
        .await
        .unwrap();
}

尾语

本文简单演示了service的实现方式

​

如何学习大模型

现在社会上大模型越来越普及了，已经有很多人都想往这里面扎，但是却找不到适合的方法去学习。

作为一名资深码农，初入大模型时也吃了很多亏，踩了无数坑。现在我想把我的经验和知识分享给你们，帮助你们学习AI大模型，能够解决你们学习中的困难。

我已将重要的AI大模型资料包括市面上AI大模型各大白皮书、AGI大模型系统学习路线、AI大模型视频教程、实战学习，等录播视频免费分享出来，需要的小伙伴可以扫取。

一、AGI大模型系统学习路线

很多人学习大模型的时候没有方向，东学一点西学一点，像只无头苍蝇乱撞，我下面分享的这个学习路线希望能够帮助到你们学习AI大模型。

二、AI大模型视频教程

三、AI大模型各大学习书籍

四、AI大模型各大场景实战案例

五、结束语

学习AI大模型是当前科技发展的趋势，它不仅能够为我们提供更多的机会和挑战，还能够让我们更好地理解和应用人工智能技术。通过学习AI大模型，我们可以深入了解深度学习、神经网络等核心概念，并将其应用于自然语言处理、计算机视觉、语音识别等领域。同时，掌握AI大模型还能够为我们的职业发展增添竞争力，成为未来技术领域的领导者。

再者，学习AI大模型也能为我们自己创造更多的价值，提供更多的岗位以及副业创收，让自己的生活更上一层楼。

因此，学习AI大模型是一项有前景且值得投入的时间和精力的重要选择。