早上有群友发了这个关于 AI Agent 的帖子，深入的看了一下，收获颇多
AI Agents大爆发：软件2.0雏形初现，OpenAI的下一步
链接
同时也验证了 ChatPAN.ai 之前的一些假设，我从一些技术的角度也进行了一下验证
本篇可能有点技术向，大家自取
Agent 可以人为是一个工作的助手，可以简单的分成调度类和工作类。调度类的 Agent 进行任务分析，执行等，主要分成如下的一些任务
- 任务规划 Planning
- 记忆 Memory
- 工具使用 Tool Use
这里的难点在于任务规划，以及如何选择正确的工具，至于记忆，短期记忆靠Token数，长期记忆靠向量数据库
Auto-GPT 等项目便是其中的探索。
这个和 ChatPAN.ai 的规划不谋而合。 如果大家看过 ChatPAN 的接口 swagger，就可以看到房间 room 是可以包含多个助手的（虽然界面展示只有一个），这多个助手就是为了这种任务调度做准备。
我的思路如下
1. 使用主助手，也就是调度助手（Router Assistant）进行用户输入的第一时间承接，根据用户的输入，以及本房间的使用目的（以调度助手的背景信息为设置） ，进行任务规划
2. 提供本房间所有助手的描述，供调度助手使用
3. 每个任务，根据反馈的结果，被调度助手进行验证，然后确定是否向下执行下一个任务，还是重新规划新的任务
4. 记忆？这不就是 ChatPAN 的优势么
就这个思路，我做了一些简单的接口实验
调度助手的提示词见附件图1
其中我对工作助手（work assistant）的定义如下
There are serial work assistants. Each assistant has config like this
{ "name": "$assistant_name", "input": "$input", "summary": "$the summary about this assistant" }
the $input is a text, it may be user natural language or a JSON format for API use
the assistant output is another text, it can be read by human or as a new input to next assistant.
这也是我对 ChatPAN 助手（以及助手内部 Bot）的一个类似的描述，这种描述是可以串联工作的
如果把上面的 "name" 改成 "assistant_uuid" 就自然和 ChatPAN 已有的助手概念对上了
使用的结果如下，见附件图2
这个场景是我正在对接的一个复杂的客服的场景
当然是可以使用一些提示词来完成，但是更加优雅和强功能的解决方案则是多助手协同
到现在，只是一个非常粗浅的想法，还有很多工作要做，在这里抛砖引玉一下
