前言
上一篇文章里我们实现了一个基本的运行时，能够将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的实现方式
