随着Agent需求的复杂化，SOP也会复杂化。动作的执行不再只是线性，需要支持CoT、ToT、GoT等技术，使用 ActionNode 可以实现统一抽象。
之前的Action，我们是用结构化的prompt形式，用markdown文本输入一个很长的文本信息，然后在action的run方法中解析LLM返回的信息，这种方式的灵活性是比较差的。
而对于LLM的请求，实际上都可以拆解为结构化的填槽：指定问题的上下文、需求、目的、输出格式。
对于写出一个有 SOP 且完整的文档，人类的撰写方式实际上是分解文档的子标题，对子标题进行动作的编排以及填槽。而通俗的来看SOP应该在被规划进行逐一执行，而不是硬编码在prompt当中要求llm一次性进行返回。我们平常用llm写文章的时候就会发现生成的回复往往是各个章节均衡的。对于写代码而言，llm往往能够生成一个60-75行左右的详细代码，而对于复杂的系统级需求，它生成的代码往往只能提供一个结构和部分注释。
ActionNode，实现了结构化填槽，使LLM请求和返回都更加标准化。
参考文档：
前面的教程中，沃恩实现了OSS订阅智能体，将Github Trending的信息由智能体总结之后，通过discord或者微信的渠道发送给了我们。
订阅智能体的实现过程，要分别完成SubscriptionRunner运行需要的三个要素：Role、Trigger、Pusher。
Trigger是触发器，我们实现了一个定时触发器；Pusher是推送器，我们实现了将消息发送到discord/微信；Pusher，Trigger这二者比较固定，实现后可以复用。
比较特殊的是Role的实现，订阅智能体设计思路基本就是源数据获取+信息提取+总结分析，我们的OSS订阅智能体就是：aiohttp爬取Github Trending -> bs4解析html提取榜单信息 -> LLM总结分析。
通过自己写智能体的方式虽然完成了订阅智能体的功能，但是这个智能体的作用是被局限在某一特定领域的，当我们需要订阅另外一个数据源的分析结果时，我们需要手动再写一个Role。基于上面的分析，我们知道，Role并不能像Pusher，Trigger这样通用，这就会让我们的订阅智能体实现起来需要较多的开发成本。
那有没有什么办法让Role变得通用呢？可以有两个思路：
思路一：我们实现一个智能体，它可以爬取我们要求的任意网站，然后进行数据的分析，最后再总结。
思路二：实现一个可以写订阅智能体代码的智能体，这个智能体可以浏览我们需要爬取的网页，写爬虫和网页信息提取的代码，生成Role，甚至根据我们的订阅需求，直接完整调用SubscriptionRunner，实现我们的订阅需求。
在Linux系统中，为了增强安全性，避免不适当的使用，有时需要限制特定用户或用户组的命令行访问。
常用的限制方法包括 profile限制、authorized_keys限制、rbash限制，本文我们就来学习一下这些方法。
参考文档：