用 Pi Durable 做移动设备上的 Agent，是怎样的开发体验？

Transcript

1. 00:03大家好，我是小毛头。
2. 00:05最近我们分享了不少关于pi durable的内容。
3. 00:09那么在移动设备上是否能基于pine durable开发一个智能体呢？
4. 00:14今天我就来聊聊最近我的事验。
5. 00:17我用point durable开源了一个移动应用加Mose。
6. 00:21我最初想要体验的就包括了对话重复任务检查点、通过url安装skill以及基本的文件读写工具，这些基本功能在移动设备上的知持情况究竟怎么样呢，也是我感兴趣的。
7. 00:37Mo我已经在L的模拟器中完成了基本的集成和任务执行的测试。
8. 00:45我做这个项目主要有两个目的，一个是体验用durable搭建agent它整个的开发过程，看看绘画任务工具这些接口实际放进应用是怎样组合的。
9. 00:59另一个呢是尝试移动设备在agent上的能力边界。
10. 01:03Boo的做法是把point durable的核心放在移动应用里运行，对话任务的状态都通过本地数据库保存，文件工具则通过设备接口访问工作区。
11. 01:17那接下来我就围绕这几个能力点分享框架提供了什么，以及应用还需要负责什么。
12. 01:26先看核心与平台的分工mo直接在手机上运行point dro的核心逻辑，我为手机应用设置专门的打包入口，把数据库和文件操作接到了expo，并在构建时检查，避免引入依赖。
13. 01:45No的实现这里首先解释几个名词，her是React Native使用的JavaScript引擎负责在手机上执行JavaScript代码，pjob的核心逻辑也就在这里运行，但JavaScript引擎并不提供no的文件系统和子进程结构，所以这些能力需要另外接入。
14. 02:10在Morela负责界面，pdurable负责绘画模型调用、工具调用和任务的状态管理，expose circle light提供了数据库网络接口，负责发送模型请求并接受流式的响应，文件系统和密钥存储呢也分别通过对应的平台模块来接入。
15. 02:34所以手机本地运行的是agent，它的核心和状态的管理模型，请求仍然发给所选的服务商，这个区别呢也帮助我判断每一项能力应该放在哪一层，任务和对话是我体验pdurable开发方式的主要入口。
16. 02:53保存一段聊天记录，主要看聊天历史能否重新打开。
17. 02:58保存一个重复的任务，还要知道执行了几次，现在是在运行还是等待，本轮请求有没有提交mo把重复任务分成了运行和等待两个阶段，每一轮都使用一个稳定的请求I D如果提交需要重试，就继续使用这个ID避免重复入队。
18. 03:18提交成功后保存进度再等待下一次。
19. 03:22假设任务间隔一分钟，应用中断了十分钟重新打开时，当前实现只补捉一次，再计算下一轮的时间，它并不会一次提交所有错过的轮次。
20. 03:38任务的中断或停止也要区分对象，停止重复，这种是停止的。
21. 03:45后续的调度已经提交的回答需要在对话里面。
22. 03:49另外的停止任务主要在前台执行，从开始，从保存的状态继续，我关心的开发体验就是这些运行状态怎样交给框架管理，又怎样通过应用的界面来表达清楚。
23. 04:06Mo目前只做了基础的skill指令加载，提供一个htps的U L应用，下载单个的skill。
24. 04:14Md文件保存在本地，在选择是否对当前的绘画启用，但安装的指定文件并不代表这个skill的全部能力都能运行。
25. 04:26当前的版本中还没有像bush或需要的支持，也不能执行Python note等脚本，也不能安装他们需要的依赖skill配套的脚本，参考文档和其他资源也不会一起下载，所以如果关键步骤依赖这些能力呢，当前就无法完整的执行，其中独立的文字指令依然是有用的，连接模型也是应用负责的一部分。
26. 04:54Boo支持A P I，我也探索了实验性的接入chagpt的订阅。
27. 05:02它也支持设备码的方式。
28. 05:04设备码方式呢由用户在浏览器缓存授权应用轮询结果。
29. 05:10浏览器毁调方式则通过手机本机的临时监听接受毁调，密钥交给secure store来完成保存。
30. 05:18整体上ui界面保持了简洁空间转流给消息和输入检查点。
31. 05:24在菜单里重新发送呢则是通过长按消息后的选项来实现。
32. 05:33文件读写属于我最初的需求，也是构建移动端执行环境的原因，关键的问题是p已经有了像read、write、edit这些工具，那么怎样让他们使用手机上的文件系统呢？
33. 05:48派的做法是通过execution emb，也就是执行环境接口来访问底层的文件，工具负责参数和结果，那么执行环境则负责实际的读取和写入，因此m复用了pa的三个工具文件，在下面接入了expo file system模型，发起工具调用快处理工具逻辑，再通过execution。
34. 06:14Env把文件操作交给X O工具注册里面就是常规的创建read，write和edit工作区环境由平台侧来创建。
35. 06:26在注入运行时，这样呢工具的逻辑就可以复用，设备文件的访问有明确的接入位置，绘画管理也不需要直接依赖某个原生的文件接口。
36. 06:42文件操作接通以后，还要确定它属于哪个绘话mo为每个对话分配一个独立的工作区模型，看到的路径统一从workspace开始，比如workspace下面的notes目录，再到to do md，实际目录位于应用still存储中。
37. 07:01通过绘画ID来区分模型，不需要知道，比如iOS上的完整路径不同。
38. 07:07对换呢也有各自的目录。
39. 07:10例如可以要求把准备下期视频写入note tes下面的to到M D再读取内容，随后把内容改成完成下一期视频的选题就能用到写入、修改和读取三个工具，关闭并重开原来的绘画仍然会选择同一个工作区，文件也会保留。
40. 07:32那对于我来说呢，这也是观察设备能力的一条非常具体的路径。
41. 07:38模型提出需求，提出要执行的任务工具，执行结果呢回到规划中，内容保存在了设备上。
42. 07:48这次也想分享一个可以复用的N片包，叫pdriable x box env，它就是为使用pdurable的X O应用提供基于设备文件系统的执行环境。
43. 08:01如果另一个应用也使用durable，它同样需要把execution接到移动设备的文件接口，那这个包就负责其中的适配，包括了工作区的目录、文件的读写以及对应接口的行为。
44. 08:17Loo则负责自己的产品规划，比如每个规划对应哪个目录像模型开放哪些工具以及用户从哪里使用这些功能包，并不需要知道mo斯的聊天布局应用，也不需要重新实现派文件工具的参数和结果逻辑，这也是我希望把它单独整理出来的原因。
45. 08:40其他的expo项目可以复用设备文件访问这一层在保留自己的应用设计接入这个包可以按三个值得理解，第一，包来负责创建基于expo system的工作区执行环境。
46. 08:57第二，应用按绘画或者项目选择工作区，把环境提供给pdriable。
47. 09:04第三，工具注册决定项模型开放哪些动作或哪些功能，news选择按对话来分配工作区，再来注册read、write、edit这些工具。
48. 09:15其他产品可以按照自己的绘画或项目的规则来分配目录复用相同的适配层，这个分工呢我更容易判断哪些是框架已经提供的功能，哪些是移动设备的适配，哪些就是自己应用的规则。
49. 09:33包的使用方法和接口也可以结合说明文档来看，在mo中也能找到世界接入位置，供你参考如何使用这个包。
50. 09:43最后来聊一个很容易混淆的问题，检查点保存了什么？
51. 09:48Most的检查点保存对话。
52. 09:50历史恢复时，从那段历史创建一个新的绘画，原绘画保留，因为文件目录按绘画分配新分支获得的是一个空的工作区。
53. 10:01所以可能出现这样的情况。
54. 10:03历史消息里面还写着已经创建to do md但新绘画的工作区里并没有这个文件。
55. 10:10这是因为消息历史与磁盘内容保存的两类状态，历史记录描述曾经发生了什么事情，新绘画的目录则按自己的规则创建。
56. 10:20原绘画文件呢依然保留，可以记住三种操作，重开源绘画，历史和文件都存在都保留。
57. 10:29创建新绘画呢使用新的历史和空的工作区。
58. 10:33恢复检查点则沿用检查点的历史来创建一个分支，但分支的工作区是空的，这是目前在mo中关于工作区、关于绘画、关于历史的管理规则。
59. 10:46在未来的开发中也会根据实际的使用体验和反馈呢来做调整。
60. 10:54因此应用里说恢复时要让用户知道恢复是哪种状态，消息任务进度和工作目录需要分别决定怎样保存和恢复。
61. 11:04这是我来体验到持久化agent的时候呢一个很具体的设计问题。
62. 11:12如果你也想体验这套开发方式，可以从一个小流程观察启动应用，完成一段对话，保存并且重新打开。
63. 11:21再调用文件工具写入、修改和读取一个文件，重开源绘话来检查其中的内容，再增加一个新绘话以及一次检查点的恢复，就能看到绘画与目录的关系了。
64. 11:35重复任务和skill也可以分别观察哪些状态被保存，重新打开后会发生什么界面，怎样把规则表达给用户，这些操作就对应着核心存储和执行环境的几个接口。
65. 11:49对于我来说呢，开发体验就体现在他们能否组合起来，以及应用自己的规则能否放在明确的位置。
66. 11:58现在回到这个项目最初的目的，我想体验派driable怎样支持agent开发，也想继续尝试移动设备上的能力。
67. 12:07文件工具是其中一个非常具体的实践。
68. 12:11搜索当然可以连接到网络服务，语音也可以连接到对应的设备接口，需要终端的任务则可以选择合适的执行环境。
69. 12:20这些呢都是接下来可以继续探索尝试的方向。
70. 12:24每接入一个功能都能继续观察框架接口怎样复用，以及移动应用需要补充一些什么。
71. 12:32最后我想把一个自己使用中意识到的用户体验方面的问题分享给大家，提交一个常试执行的任务之后，如果需要一直留在应用里等它完成，那这样的移动agent离日常使用还有多远呢？
72. 12:48当前mo主要在前台执行，因此切换应用或锁屏后，任务可能短暂继续。
73. 12:54但也可能因为系统挂起或回收应用而中断判durb，当然了，它保存了状态，这为重新打开后的恢复提供了基础，但恢复状态和离开界面后的持续执行需要分别解决。
74. 13:09因此移动agent除了能调用哪些工具，还要考虑执行过程由谁来承载。
75. 13:15界面关闭后，负责推理和调度的运行时是否仍然存在。
76. 13:21如果中断，哪些步骤能继续，哪些结果要重新核查呢？
77. 13:26一种选择是保留本地运行接入系统提供的长任务能力。
78. 13:32比如安卓有它的前台服务，iOS有continued processing这些机制，他们需要和实际的运行时代连接，处理进度取消和系统接触任务的情况，这些还是mo有待验证的方向。
79. 13:51Expo它的background task解决的是可以延后由系统选择时间执行的工作。
80. 13:58它不能直接理解成给当前A键的循环打开一个持续运行的开关。
81. 14:04那么另一种选择呢是让独立的远程host来承载agent它的运行时。
82. 14:10手机只负责提交任务和查看状态，将样要重新考虑设备文件密钥和同步了，只把工具放在远程，还要确保后续的调度和推理能够继续运行。
83. 14:23我还并不确定这个问题上的最佳方案是什么，如果是，你会更希望agent留在手机本地接受系统调用并加强恢复呢？
84. 14:33还是把长任务交给独立的host？
85. 14:37你有实践过本地的后台方案吗？
86. 14:40欢迎分享你遇到的限制和你的解决方案，如果你在这方面已经有一些经验，欢迎在评论区来分享你的看法吧。
87. 14:49如果你对这类ag见的实践感兴趣，也欢迎继续关注我们频道，也欢迎大家一键三连吧。
88. 14:56我是小魔头，我们下期见。