很有幸能够比较早地体验了kOS上ACT的开发。我一直从事的是传统软件开发，在做了几个ACT以后，我觉得开发ACT的和开发传统软件需要在整个思路上有一个转变。这里就和大家分享一下。

我认为最大的转变就是需要利用好LLM的理解能力。用的方向有两个一个是理解用户意图，另一个是辅助做一些格式化转换。

理解用户意图

现在kOS的交互是用LUI，也就是用人类语言（Language）与系统交互了，而咱们传统是用命令行和GUI交互。这个改变引出的问题也是由语言的特性导致的，就是自然语言的不精确性。而kOS的核心也是想实现精确控制，那势必就要求将这种不确定性转成确定性。这个转换就要用LLM。

ACT能完成的功能是开发者自己定义的确定的几个。所以需要用LLM将用户的意图转换为自己定义的几个功能。我用我开发日程安排ACT作为例子说明一下。

日程安排的逻辑就和我们传统开发一样，它有增删改查功能。但用户使用时候是用自然语言呢，例如：

• 记下明天下午3点开开年会议
• 明天下午会议取消了吧
• 明天下午的安排都不要了
• 把明天下午的会议删了吧

这就需要用LLM识别出来，第一条是新增功能。后面3条都是删除功能。没有这个意图识别，自己开发的功能都对应不上，根本没法进行了。所以我认为这是最重要的思路改变之一。

辅助做格式化

辅助做格式化就是将非结构化的内容转换成我们程序逻辑能处理的结构化数据。举例说明一下就好了，还是日程安排：

• 记下明天下午3点开开年会议
• 记下大后天上午10点写工作计划
• 记下下周二去北京出差
• 3月20日去参加同学婚礼

这些例子，如果硬用传统编程方法解也能解出来。但是用LLM的话，他就能很容易地将这些转换成我们程序想要的格式。这是我用的提示词：

如果提供的是相对日期，例如，明天，后天，9天后，下个月，下下个月，则将它转换为数字相对值，并将类型设置为relative
如果提供的是绝对日期则提取出日期。先判断日期和时间是否满足这些要求，月份最大是12，日最大是31，小时最多是24，分钟最多60，秒最多60。
今年是2024年，是闰年，所以2月有29日。如果不正确则写明原因并标记结果为失败。正确则将类型设置为absolute
提取出时间和要安排的事情。
如果日期和时间都没有问题，则标记成功，否则标记失败。

对于第一条，他就可以给我输出如下JSON：

{
   "date_type": "relative",
   "day_offset": 1,
   "month_offset": 0,
   "date": "",
   "time": "15:00:00",
   "object": "开年会议",
   "result": true,
   "error_reason": ""
}

这是一个相对日期的例子，它正确解析出来这是一个相对日期，并且偏移量是1天。

对于第四条，它是一个绝对日期的例子，输出就是这样的：

{
   "date_type": "absolute",
   "day_offset": 0,
   "month_offset": 0,
   "date": "2024-03-20",
   "time": "",
   "object": "参加同学婚礼",
   "result": true,
   "error_reason": ""
}

它正确识别到这是一个绝对日期，并且把日期写到了date字段中了。这已经是我们熟悉的结构了，后续用编程语言处理就是了。

除此之外，例如URI的处理，忘了Python对应的方法了，直接输给LLM让它给解析出各个部分就好了，当然它速度可能不如用Python库快。

这是一个用编程语言还比较容易实现的例子，再发散一下，用ACT爬数据，是个分页的，需要找到下一页的连接，用Python可能找起来就比较麻烦了，那用LLM可能给给下面这个提示词就直接能找到了：

帮我在这段代码中找到分页连接，它的特点可能包含page关键字

因此，我认为这也是需要转变的一个开发思维。

结束

也写不少了，当然有理解不到位或者有更好的思路希望大家不惜指教。