做为一个云原生开发工程师,平时会花50%的时间在集群的运维和管理上,如果遇到集群和节点层面的故障问题,那排查和解决起来在原因未知的情况下就无法估计和控制时间。所幸之前就有了解和试用过 OS Copilot,他可以借助LLM的能力帮助我来执行和提供一些建议。
OS Copilot 现在有了新功能,支持了 -t -f | 等使用方式,所以我今天来试一试效果。
【使用】
首先是安装部分,安装功能的完成度比较高,几行命令的事,这里给大家放截图做个参考。
首先在阿里云 ECS 中安装 os-copilot
然后要在控制台对 ECS 做相应的角色授权
到这一步,co 已经能正常使用了,先来简单的打几个招呼,问些常规问题,对 OS-Copilot 有个初步了解:
可以看到 co 的 help 信息中已经为我们列出了参数的说明,让我们跟着一些实例试试效果:
这里我们先使用基础的 co 指令,做一些基本操作:
可看到似乎能理解,但是结果看起来不太准确,我们加上 -t 来让 copilot 调用专门的 agent 试试:
调用了 -t 之后,结果这回应该靠谱了,这就是 copilot 调用了工具,来执行得出的结果。
接下来在看看 -f 的作用:
我们在文件中写入要执行的任务:
接着让 os copilot 执行:
这里我们可以看到在 -t 的加持下,OS-copilot 似乎在一步步的思考,来看看最终结果
脚本确实是有了,看起来也没问题,可能因为我的环境比较健康,没有error,所以error的结果为空,但是这一些从写脚本到分析日志到生成文件,都是 co 替我做到的,这也太省时省力了。
最后一个管道符功能,这个功能的场景我最先想到的是让 copilot 来解释一些系统日志,我是这样做的:
错误日志直接输出给 co,co每一条都帮我做了分析和解释,但这里还有一些问题,我放在下个部分来讲我使用上的一些问题。
【问题总结】
- 在管道符使用场景中,体感上增添了许多方便,但我感觉 OS Copilot 得结果不够收敛:
每一条问题都有分析,但是每一条给的建议和结论又都接近,这里其实有很多数据的冗余,5条日志的信息我已经没耐心看完,所以如果 Copliot 能在问题的摘要和结论的收敛上做的更好,一语中的,那么体验直接飞升。 - 其实上面截图还反映一个问题,回答变英文了,其实这属于数据噪音问题,但是如果在系统提示词上加一些限制,那么我想也能一定程度避免这种情况发生。
我 顺利使用了/不知道如何使用/艰难地使用了 OS Copilot的 -t/-f/管道 功能,我的疑惑是(如有)(请提供截图)。 - 我在 -f 的场景中,其实试过一些稍微复杂的任务,当然也可能是我表达不准确,最终导致模型失败,具体看图
这个用例始终没有成功,我知道原因应该是多方面的,但其实这里还隐藏的一个细节问题是报错信息不明显,我如果有能力去参与copilot的调试,或许也能找出问题,但现在的信息只能让我放弃这个任务,无从下手去改进或优化。
【产品建议】
基于使用过程中遇到的一些问题,我也提供一些自己的想法和建议
- OS Copilot 的内部提示词可以再加强,比如控制输出的收敛程度,减少废话冗余,控制输出语言。
- 可以简单提供一些多轮对话能力,有一些问题肯定是需要多个步骤问答解决的,这个时候如果没有多轮对话能力,那么也会比较麻烦。
- OS copilot 可以尝试更开放一些,比如放出源文件,或者调试办法等,甚至只是再加强一下报错日志的内容也可以,好让用户知道问题出在哪里,进而改进,顺利使用。
暂时先想到这些,其他等深度使用之后再反馈