pi coding agent配置
这期我来带大家安装并配置一个 ipad。 先来简单的认识一下，它和很多开箱即用的 ipad 不 太一样，有些 ipad 把大量的功能都封装好了，装上就能用，但你很难知道它到底加了哪些技能和扩展。 ipad 的 思路是尽量保持核心的，简单把可定制的东西放到配置和扩展里面。它本身并不是一个大而全的工作流框架，也不是什么装完之后什么都有的成品，而是给你一个可以自己理解自己改造的 ipad。 让我们直接执行这个安装命令。 这边我的话已经把我本地的 pidgin 的 配置删掉了，但是二金字文件我没有删，所以说它这边应该是提示已经安装完成，大家正常情况下就复制这个命令执行就行。这边直接回车那重装一下， ok， 这边就安装完了。 安装完了之后你要做的就是连接你的大模型提供商。这边的话使用杠 logo 命令。这边有两种模式，一种是用账号登录，还有一种是使用 ipi k。 国内的话目前只有 kimi 能用账号登录。这边我拿我的这个 mini max 去演示一下， 复制，然后粘贴。 ok， 这个时候应该就已经好了，我们测试一下， 没有毛病，这个时候 python 已经能正常工作了，但是就像我们一开始讲的一样， python 只有最简单的核心功能，如果想要把它打造成一个属于你自己的 python， 你 还要在上面根据你的需求适当的拓展一下。 这里 python 提供了非常简单的拓展接口，你可以在上面自由的定制。当然如果你不会拓展，也可以去社区找一下有没有你需要的插电包， 不过因为现在使用 internet 携带码的门槛太低了，社区内混合着大量质量不太高的插件，甚至同一个场景会有好几种不同的死线思路的插件，其中的优劣可能就得你需要去尝试一下才能知道了。 比如这里支持 safenit 的 就有两个，我是比较喜欢用下面这一个，原因是它内置的 safenit 就是 比较简单的 explorer 和 demo， 有 需要的话我自己拓展。然后上面的这个的话内置了一堆，我根本不想知道它内部到底是怎么分配任务的，引入了复杂度，还容易出错，还是那句话，少就是多。虽然它的这个下载量比较高， 呃，但是应该是占了这个名字的便宜，出的比较早，把这个不占前队的名字给占了。这里就不带着大家一个一个去看了。我这边给大家写好了这个文档，或者说给大家的这个 id 写好了文档 定位很简单，一个注视详尽，开箱即用的派安净的配置气垫。如果大家了解开源项目，就会对奥迈开头的项目和 kx 大 开头的项目比较熟悉。奥迈开头的系列通常情况下是开箱即用的，成品是黑盒，你不需要关注发生了什么。 kx 大 开头的项目则相反。给你最小的配置气垫，你需要自己来定制属于自己的配置，适合喜欢折腾的人。 我们先看一下这个设计理念，大部分的 i f g 气垫仓库是给你一个成品，你拿到了能力，但不知道每一步在做什么，为什么这么做？ kickstarter 点派是反过来的，你必须从零开始，一点一点的组装你最终需要的成品。 我们接下来安装 kickstarter 点派。这边我们直接复制这个提示词，然后粘贴给我们的 python， 在 它安装的时候我们再往下看一下， 这个流程我会带着大家走，就不用念了。这里这个内置要讲一下，就是刚刚粘贴给 anint 的 那个提示时，到底给你的 anint 加了什么， 其实主要就是加上了 m c p 的 支持和内置了三个常用的 m c p。 关于这个 m c p， 它的原声设计里是不带的，作者认为应该用 c l i 包装 skill 来代替。呃，某些场景下是的，但是某些场景也不是。目前 m c p 的 应用范围确实是被吃掉了很大一部分，现在应该是退回到了数据层， 并且还有很多优秀的框架和 ic 的 对接是提供的 m c p， 所以 说 m c p 还丢不掉。这里再拓展一下，我看到派特社区和插件仓库里有大量把 m c p 包装成插件的情况，应该是作者推荐这么做。这里讲一下我的个人观点， m c p 就是 m c p 对 于 ic 的 本身的拓展才应该封装为派克机， 你把 m c p 封装为派克几还没有那么过分，还有一堆把 skill 封装成派克几的，不要这么搞，兄弟们，每个人或者说每个大模型的水平不一样，封装的质量也不一样，引入一层包装就是引入额外的复杂度，出错的概率是会增加的。这边的三个 m c p contacts 七和设置 code 你 不歪，不确定的话你可以删掉，但是网络搜索大家通常是要的。 ok， 我 们看一下安装的怎么样？这边已经安装的，大家通常是要的， ok， 我 们看一下安装的怎么样？这边是要的， ok， 我 们看一下安装的，大家通常是要的， ok， 我 们看下， 可以看到下面提示 m c p 正在连接， 我们直接敲一下 m c p 命令，这边这个网络搜索，我是让它饥饿模式加载的，另外两个是用到的时候才会加载。关于 m c p 的 配置，这里需要拓展一下。之前我教过大家怎么省 talk， 这里又到细节了，如果你选择懒加载，那么 talk 的 总量一定是会减少的， 但是缓存命中就会受到影响，缓存命中和不命中的差价还是非常大的，因此你需要评估一下你的 mcp 的 使用频率，如果是用的非常多的，那么你应该让它饥饿加载，保证前缀缓存的命中率。不太常用或者说比较重的，再选择懒加载的方式。还有别忘了控制数量， skill 和 mcp 都不是越多越好，我已经强调很多遍了，少就是多。 再往下，我们安装一个工具之后的第一件事情就是要把它美化一下。这边我们先安装这个 open tou， 同样粘贴这个提示词， 这个玩意儿，把热门的几个 pad ui 插件的优点整合了一下，我们装完 relog 看一下效果。 ok， 安装完了，我们 relog 看一下效果，可以看到实际上页面已经变得好看一点了，主要就是下面这一块。再往下我们安装一下主题拓展，默认的话 pad 只有 dark 和 light 两个配色，我们安装一个插件，补充一下配色方案。 ok， 装好了，这边我们 relog 一下啊，然后 setting， 搜一下主题，这边可以看到实际上可用的主题已经很多了，我们随便切换一个， 然后再 relog 一下，可以看到颜色的风格是变了的。 现在还有个问题，就是这个 python 的 这个工具调用，还有这个输出和这个思考是混在一起的，这个框实在太丑了，还不好区分。我其实想让这个工具，结果这里加个圆角和边框，这边的话我没有找到合适的扩展，回头的话我写个插件来美化一下吧， 我们继续。再往下是 idk， 同样复制这个贴纸粘贴一下。 这个阿提盖是建议大家全军安装的无痛省 tockin， 不 装是白不装的，它能够把常用的命令改成紧凑的形式，直接从这个源头节省输入 tockin。 想要了解细节的话可以去看一下之前的省钱章节。 这个 killman 我 就不带着大家去装了。这个东西的话是建议项目级别安装的，让 agent 少说废话。不过这个 killman 省输出 tockin 是 可能有损的， bug 定的时候可以根据情况去用，创意类的工作的话就算了， 再往下是我们的工作流框架，这个我也不带着大家装了。关于工作流框架的选型，这里拓展开来讲一下。如果你是从零到一，建议使用这个 superpowers 快 速出一个原型，然后就可以拆掉了。 如果你是团队多人协同开发重型的一个项目，那么建议使用 openstack。 stack 是 协同的基础，个人开发的话，目前大模型的边界还是在快速拓展。实际上建议自己根据应用场景维护自己的 work flow， 什么框架都不要用。你现在为了保下线加上的滞约，到后面可能就是限制模型上线的发挥了。 再往下是我们探索代码库的工具，这个也在省钱。篇章讲过了，这里就不赘述了，这两个是二选一，看你喜欢哪个用哪个就行，但是不要裸跑 excel， 太浪费 talk 了。 我们看一下安装完了没有。 ok， 这边已经安装完了，我们直接 re log， 这边可能看不出来，我们退出一下，然后重新启动。 可以看到这边这个 r t k 的 这个插件是已经装上了的，然后下面这些都是主题， 我们再往下继续。 下面是这个 safenit， 这个也是，我觉得 safenit 必须要有，但是 pad 没有自带的，不过没关系， pad 没有，我们就和拼积木一样，我们加上这个拓展就行。复制这个梯字词，然后粘贴给我们的 i n t。 我们先往下看吧。下面是这个 android browser 这个东西的话，如果你的项目使用的是外部项目，这个是建议你装的，能把这个人从循环里面凑出来，这是全自动工作流必要的一环，它走的是这个 c d p 协议，比纯无头浏览器的脚本操作方案能省不少。 所以如果你使用的是 playrite 之类的，可以考虑替换一下，针对项目级别的，我就不带着大家去装了。 再往下的话是这个 remote pad， 之前我们讲过怎么在手机上远程控制你的 iint， 选择的是外部加 ipv 六加 d d n s 的 方案。这个 remote pad 使用的是 e d 组网的方案，需要在手机上下 app， 然后电脑上启动你的 iint， 生成二维码，用手机扫描一下就能远程控制了。这个的话回头我单开一集去讲吧， 我们切回来看一下安装好没有。 ok， 这个时候它已经安装完了，我们 re loop 重载一下， 然后敲一个杠 agent 命令，可以看到实际上已经安装好了，这个插件也支持你去呃自定义自己的 sub agent。 最后讲一下 pad 的 价值，不只是又一个特定 agent， 而是它把 agent 的 配置和扩展的权力交还了给你。如果你喜欢折腾自己的 agent， 之前大家把 pad 的 官方文档和这个仓库完整的读一遍，然后开始搭建属于自己的 agent。 ok， 这期 python 的 安装和配置就到这里。下一期如果不出意外的话，我给 python 写个美化插件，然后优化一下那个工具输出的效果。
粉丝3276获赞1.4万
相关视频
13:44查看AI文稿AI文稿哈喽，大家好，给大家分享一个我最近在用的一个框架，这是一个在 get 上有五十三 k star 的 一个项目，它叫这个派，它是一个极简的可拓展的一个 ai 的 终端框架， open club 也是用的这个框架拓展出来的，所以这个框架还是相当强大的，他的理念就是什么都没有啊，他不在内部去装这些任何的能力啊，没有 mcp， 也没有这个紫 a 卷腾， 然后也没有这个弹窗权限，也没有这个 play mode， 也不做凸度，也没有这个背景照射。我们为什么会去 关注这样的一个项目？它什么都没有，我们为什么要去关注它？我们先来分析一下我们之前用的一些工具的问题，比如说举例子说 codex， codex 其实随着更新它的能力是越来越强了， 然后它的这个东西也是越来越多，越来越方便了，这个其实是不可否认的，但是它毕竟是 open a r 自家的生态，我们在定制它的模型的时候，比如说我们去定制 deepseek 啊，这个是目前来说好像还是没有办法去定制的。而我们利用使用中转站，就需要像用这个 switch 这种工具进行切换， 那我们用完了之后需要重启这个 codex 去切换它的模型，然后它的紫 agent 也是不支持。说比如说啊，我的任务，我的计划模式用的是 呃 gpt 五点五，然后它的紫 agent 用的是比如说是 devic 的， 这种情况也是不支持的， codex 这种强大带来的代价就是它相对来说比较封闭， 然后后面我就开始用这个 open code， open code 有 一个好处，就是它比如说我们在用这个 gpt 五点五的模型的时候， 那我同样可以去配置它的指 agent 主要做什么，就比如说这个阅读的探索的 agent， 就是 在我们用五点五去做项目的时候，我们恰好这个时候想确认一个项目文件在什么位置，或者确认一个项目文件的结构，这个时候如果我们也去让五点五去干这个事情， 其实是有点浪费的，那我们就可以去用这种紫 a junt 去探索这个项目 到底有什么东西的时候，其实是用不到这么强的模型的，所以我配置的这种紫 a junt 用的就是 deepsea 的 v 四的 flash 模型，那这个探索一次是几乎，反正我们几乎是看不到它的损耗的，那这种搭配的下来，一方面可以保证这个主 a junt 上下文的纯净， 而另一方面是可以一定程度的就减少我们的 token 的 支出。但是 oppo 也有问题， oppo 的 主要的问题就是 我不知道为什么 oppo 的 出于什么考虑，它的这个仓库里面其实是有好几个说它这个文件路径是无法识别的。这样的一个 iq 也有人去提交了 pr， 但是官方一直是没有去合并处理的。这个 我自己其实尝试也去写了他这个功能改了他这个能力其实并不难，但是我不知道为什么官方他不愿意去做这个事情，因为我在开项目，这个是我自己去稍微改了一下他的文件识别的规则，可以去打开这些文件啊，这边 基本上已经实现了一个功能，但是我为什么没有去维护？大家也知道 open code 其实一天有的时候能更新十几个版本，就如果我去复刻它这个分支，回头我的维护成本可能会很高，我需要一直去更新它的项目，一直去做我自己的维护， 我觉得这个可能就是背离的我只是想要一个好用的工具的初心，所以 open code 的 就在这个做的过程中，虽然我挺喜欢用 open code 的， 但是有这么一两个点 在我生产的过程中我觉得蛮不舒服的。还有一个就是它这 play 模式其实算是我用过几个工具里面最好用的，就是我们聊完之后，然后切换成 build 就 可以直接执行， 但是我就希望他能够有像反重力那样有个快捷执行的一个能力，就不用我们每次 build 之后要确定或者说点击继续才能够进行。 如果说我们要去改这些东西都是需要去 fork 的， 它这个分支对于我们个人开发者或者说我们只是希望有一个方便的工具，这个角度上来说对我们的精力支出就太高了。 然后我们就来反过来去看我们为什么用 pad， 然后第一个就是 pad 结合这个 wrap， 这 wrap 还是蛮好用的，就是这个我推荐给大家再插一个题外话，就是这个 wrap 其实用 oppo 扣的也是蛮好用的，它有提供一些原声的拓展，它这个终端工具可以多开，开完之后也能够直接在这看文件， 一定程度上的实现了这个欧风扣的桌面端的能力，并且欧风扣的桌面端他是不能够去删文件，他也不能编辑，那这握这都是提供了，也是可以保存， 也能够快捷的去开这个窗口进行指令的输入，也能够他还会联想，比如说我空开一个项目，我打 no 的， 他会自己去联想我要执行什么脚本，这个还是挺好用的，这个工具他近期也是开源了，大家要感兴趣的话去搜一下，是就能搜到了， 我们再返回来去说我们为什么最终我选择去用这个派。其实一开始的时候我也是抱着说不要在这种工具上折腾的一个想法，一直在用这个 oppo 扣的，但是我还是忍不住的去看几眼这个工具，最终我还是深度的使用了几天。 这第一个就是他没有封口，把这个 t y 给渲染的那么好，所以他可以是直接点文件的，那封口的是不支持的，这是第一个他可以快捷的直接点开这文件， 然后再有他的所有能力。就刚刚提到的这些东西，他其实是不是不提供，而是他不内置在他的这个框架里面， 就通过我们可以去通过我们的拓展，或者说去这个 package 里面去下载对应的这个包就可以。比如说这个纸 agent， 它也会有一些什么 play 模式，这里面都有，只是它不内置到它的这个包里面了， 然后大家也可以看到这个数量其实还是蛮多的，这生态还是蛮好的。我其实是没有去下载，我其实只是把官方的拓展包拿下来，我进行一些改动就更适合我自己。就像是刚刚说的这个 play 模式， 他的执行就是我们需要去切换成 build 模式，点确定才会执行，我其实是改写了，比如说你好，我改写了，其实我在每次任务的时候结束的时候，他会问我说我应该我接下来的动作是什么？ 我可以停留在这个 play 模式继续聊。我把它放在第一个是因为我们可能要确认这个计划的时候， 我们可能要多轮的对话，那如果他其实官方的是第一个是执行，那我就每一次都要把他切到第二个，说完之后不太方便，所以我给他改到第一个， 后面的我把他进行了修改执行，或者说我有补充想要缩在里面再让他执行，那这样就很方便。比如说我就直接可以让他执行，我也去做了个紫 a 键，他可以探索我们的项目， 它其实就是发送一个指令，开启一个后端的后台的任务，去跑这个派，进行一个 任务，把任务的结果返回回来，然后包括我写 get 的 一些指令，可以拉取提交， 写了这个日制的一些工具，就可以快捷的去写日制个，就像我的这个日制，其实用指令去写的 对于我这种比较懒的人还是比较友好，他有他个主要的一个理念，我们可以去搭建自己的工作流，他自己的官网上面也写别的 ai 工具，其实是我们去适应他的工作流， 去适应，比如说去适应 codex 的 工作流，去适应这个 opencode 的 工作流。但是派就是希望让派去适应你的工作流，而不是去你去适应他的工作流啊，包括我前面其实做了一次 get 的 提交啊，在这个项目里面， 然后他也是派出这个子任务，因为我我这么做的一个目的就是说我不希望说，比如说我们现在在做这个 plan， 在 做这个计划，然后我做到一半，我突然间想起来，我是不是可以先提交一下再去做后面的尝试？ 那就弄了这样的一个，尽量不要打断他自己主 agent 的 对话，让他自己开一个子 agent 去提交这个 get， 提交完他也会把这个提交信息返回给我， 那这样还是挺方便的。然后以上差不多我认为的派的一些好处，我没有去装很多这个插件，因为我觉得现在其实越简单越好。就我包括我用 opencode 的， 也基本上不去装这个 o m o 之类的插件，因为我再去装了， 我也去装过去使用过这些插件，其实最后我发现其实很多时候其实是用不上的，包括现在的 ai 模型，其实它的能力已经越来越强了。比如说我们去开这些什么多身份什么，大多数情况下其实它不能够保证稳定的产出。我在作为一个游戏开发者来说， 我不是希望，至少我目前不是说希望他能怎么样一步到位给我去执行所有的这个任务。我更希望的是他能够在我希望他执行什么东西的时候，让他去能够准确的执行到我希望他执行的任务。我希望的是一个稳定的产出生产环境， 而不是一个花里胡哨的宣传。我能一键到位，我直接一句话我就能生成一个游戏的这样的一个东西。因为我之前也测过这些工具，其实它不能够提升非常大的一个稳定性，但是给我的心智带来了不小的负担。你比如说 o m o， 光说这个七个 agent 我 去使用的时候我还要一直去看表，这个到底是干啥的？那在做的过程中，我有的时候我就希望跟 ai 探讨一下计划， 我发现这个 o m o 根本就没有你比如说你去告诉这个西西服，我现在想要探讨什么东西，他可能咔咔咔就开始帮你干了，干的时候也不能够保证这个执行的过程中是不是符合你的预期，是不是 符合你的需求。他只是保证了说他写的代码多次的去审核跟多次的去校验他写的代码，比如说没有报错的，那这些其实不是我 最需要的，我最需要的是能够符合我的需求，而不是说他去哭哭干出来也不保证说他到底是不是符合我的需求。 我现在我说完这个派的优点，我稍微说一下我目前感觉他还不足的地方，刚好是前几天我在公司的项目遇到了一些比较复杂的问题的情况下， 这个怕起码我现在这样装着一个比较简陋的一个插件环境的情况下， 它的输出质量相对来说还没有稳定到有，比如说有卡尔的扣的或者说扣的这样的一个程度， 它还是容易漂移。虽然说我们说这个派的宣传的理念是说是说现在的这个 ai 模型的能力越来越强了，我们其实不需要那么多的题 约束去保证 ai 的 质量，但是那些事情他并也并不是说完全没有价值。比如说我们现在的这个 ai 的 模型已经能够达到六十分的能力， 那那些东西他可能说可以把这个模型的能力提升到六十五分或者是七十分，但是我认为他也没有把这模型能力能提升到九十分那么多，但是他确确实实有给这个模型带来更稳定的一个输出质量， 这个肯定还是有的。那派减轻了这个之后，就他的模借助模型自身的能力，他也可以做到六十几分。 但是他有的时候，比如说模型的这个降质的情况下，比如说分值比较高，使用的人比较多，模型厂家在降质的情况下， 那他的输出质量其实就开始有不稳定的情况。也是我在前天的时候，在做项目的过程中，我一边开着欧风扣的，然后进行了一个对比，得出了一个结论，如果大家想要解决这个问题，可能说就需要去装更复杂的一些工作流程，但我目前 使用了小一周的情况下，我确实也还没有去做这么重的一个配置，我个人也是比较喜欢剪辑，所以我也没有去抓那些东西，但是大家可以看到我其实今天的任务都是用派着玩，就是它很清亮， 我们定制的工作流也是相当贴合我们自身使用的习惯，所以我个人还是很喜欢去用它的，那但是它确实还是有些不足，大家要在正式的生产环境去用它，可能还是要做好，比如说做好备份， 做好这个版本管理，或者说去装更全面的一些生态的插件，才能够去更好的去产出。今天的分享就到这里，谢谢大家。
112老山贼
01:01查看AI文稿AI文稿之前我把 python 的 源码写成了一本书，没想到拿了两千个 star。 于是我赶紧一鼓作气，继续介绍如何使用 python 打造自己的智能体。这次我准备了一个 skill， 你 只管提 agent 的 功能需求， ai 会自己调用 python 完成开发。我们的需求是开发一个 data agent， 基于 web 进行应用，数据 ai 自己造就好， 然后要拦截危险窗口。 ai 根据这个 skill 查询 python 的 用法，从零开始搭建环境，很快就完成了这个项目。来，我们体验一下，随便问个问题， 这两题能够正常答复。我还准备了一份极简教程。这份教程以构建 data a 整为例，由浅入深，以人工古法编程的视角，告诉你如何用拍 a 整进行二次开发。 所以，如果你想无脑上手，那就直接使用 skill。 如果你想进阶，那就看看这个教程。此外，如果有个功能你不知道怎么设计，也可以使用这个 skill， 让 ai 搜索同类的拓展进行参考。 ai 搜索到同类项目之后，就会自行解读原码，结合你的项目给你一个解决方案。因此，我觉得这个 skill 还是很适合新手的。感谢，下次见！
1791费曼学徒冬瓜
01:07查看AI文稿AI文稿它和 cloud code codex 一 样，都是 coding agent， 但它开源只留四个核心工具，半年冲到七万六千多个新标。 pi 不 拼内置功能，而是把 agent harness 的 控制权还给开发者， 默认核心只有 read、 write、 edit、 bash。 系统提示，加工具定义不到一千头，肯 缺工作流或界面，让 p 写扩展 re load 一 次就能在绘画里改造自己，绘画能分叉回退，模型能中途切换，重点是你真正掌控上下文。 openclaw 爆红时， pi 是 早期底层 harness， 而 me runker 等开发者又公开背书。截至二零二六年七月二十四日，这个 mit 项目已有七万六千多个星标， 但它没有内嵌权限。杀箱不可信，仓库官方建议放进容器，想自己定义抠定 agent 一 条命令装上派更多件派点 df。 我是 sawyer tech， 关注我，获取更多 ai 知识。
651Saywer Tech
01:37查看AI文稿AI文稿很多人把派和派 coding agent 傻傻分不清，今天用一分钟给你讲透。 先说结论，派是一整套的底层框架，你可以把它理解为发动机、轮子、车架这些配件，而派 coding agent 就是 基于这套配件组装好的整车，是专门给你写代码的成品。两者到底有啥不一样？ 第一，层级不同，派包含对接、模型、接口、核心循环等底层东西，你平时敲的派命令其实只是最上层的扣顶版本。第二，默认配置也不同， 纯的派很干净，几乎啥也不预装，但是派 coding agent 已经给你配好了读写、改文件和执行命令的四个基础套件，所以很多人一安装就能直接干活。第三，使用场景不同， 底层扩展机制是一样的，但是派更适合从零搭建自己的 a 证，而抠定 a 证就是拿来直接拿来急用的。那么实际怎么选？如果只想快速用 ai 写代码改项目，直接装派抠定 a 证就够了。 想自己定义 a 证行为改工作流，甚至做成别的形态，那你需要去玩派这套底层框架。 一句话总结，派是个壳子，包含作者的 agent 哲学。派 coding agent 是 配好的写代码版本，大部分人用的都是后者，却以为自己在玩整个派。
594迈AI克的杰克逊
00:47查看AI文稿AI文稿你以为 pi web 靠 web 界面吸睛啊？ github 两千五百一十星，今天加三百零一三天加九百一十。 第一，开发者真正高频行为是调试而非看结果。第二， u i 只是把 agent 过程格式化，本身不产生数据。第三，没有真实使用数据回流， u i 再漂亮也只是壳。 你猜为什么很多人只看演示图就 star？ 因为过程展示比结果截图更能暴露真实工作流，这才是判断 ai 抠钉工具价值的唯一标准。 下次看到春钉 u i 先问自己，它有没有在积累别人追不上的使用痕迹？你手上的抠钉工具过程数据跑通了吗？
16:11查看AI文稿AI文稿来聊一个非常欢迎的派 agent， 派这个名字其实不太占搜索优势，因为我们输入派圆周率、树莓派和同名项目会集满结果页，但就是这么一个啊，非常低调的工具，在 八月二十二号的时候就是 github 上的，已经有了九万多个 star， 为什么一个 boss 默认只给模型四个工具的终端 agent 为什么还能拿到四万九万多个 star？ 因为到了二零二六年就是会读代码改文件。调命令的模型其实并不在少数，开发者已经开始把命令就移到了模型外面，就 这写的什么工具何时被调用，权限如何被限制，绘画怎么被压缩，就换了模型后原有的信息还能保留多少。这些看似是产品的细节，但实际上会直接去影响输出账单和以及权限安全。 那么派选的功能其实并不是常见它，其实它默认的功能它是尽量的少，系统提示、绘画记录和扩展接口则尽量的让用户能够看得见改动。 所以官方其实把派就定为啊， minimal temporal coding harness 就 harness， 它其实并没有个很贴切的中文译法，但是我们可以理解为一套调度程序，就是它把用户的输入系统提示词和地址消息交给模型，模型要求调用工具时，它会去检查参数，执行结果， 再把结果返回给模型，这个过程会一直的持续，直到模型给出最终的一个回答。其实它的最基本的路径并不是非常的神秘，就是我们可以看一个 用户请求，就是 start， 再加绘画沙沙文，调用模型模型，再去做一些工具调用，比如说 red red ide 大 师，然后返回一个工具的结果，模型继续回答去判断，然后最终会去对你的一个问题请求来进行一个最终的回答。而 pad 其实默认只给模型四个工具读文件，写文件，精确编辑和执行。 shell 就是 像计划模，计划模式以及啊代办列表以及子 agent 的 后台 boss 和 m c p 其实都没有内置执行，每步时都不会去弹出权限切同框。 在二五年年底的时候，啊作者他其实在早期介绍设计思路的文章里就提到过当时的这项工具的定义，总共不到一千个 token， 但呢，今天的 版本其实已经不能直接跳入这个数字，但其实它的设计之初的思路想法其实非常的清晰，就新一代的模型已经知道怎么去完成常见的 coding 任务，那没有必要为每次都读一遍笼常的操作手册。四个工具其实看起来比较少，实际权限也并不啊小，尤其是像 bash， 像 git 编辑器，测试框架、数据库、客户端， url 乃至操作系统，都可以从这一个路口去进行一个调用。而编辑模式，其主要指模型。需要理解的工具种类非常少，并不代表着它能做的事情少， 就是 pad， 我 们可以去看派面和固定的提示，它其实非常的轻，也非常薄，但是代码其实并不简单，因为如今的仓库其实已经包含了模型识别、 t u i code agent， 远程客户端等等诸多此类的。那么如果把它去定义为一个非常小的一个工具，其实是不是特别的合适，他只是尽量的去少替用户去做决定。模型调用一次工具几十行代码就能够写出，但其实多真正费功夫的是多模型的兼容、流逝的输出以及异常恢复。 比如说像啊，还有些用量记录和绘画保存，那么从拆分出来的几个包里面，其实刚好能够看出工程量否 花在哪里。就是我们来看 ipad ai， 它其实是负责对接不同的模型，看上去兼容了 oppo ai、 compression 或者 oscilloscope 的 message 或或者谷 歌的 memory ai 几类接口，但其实做起来其实非常的繁琐，因为各类对工具的调用、流逝输出、推理内容缓存停止原因和用量统计的处理其实都不一样。就连同样设成兼容 oppo ai 的 服务 字段和返回格式也会有些差别，所以只统一各家确实有共有的部分，那么对于一些差异会做一些分别处理，那么一段绘画因此可能会中途从 cloud 切到 gpt、 gemini 以及 deepsea 或者本地模型，那么普通文本和工具结果其实都能够去使用。不过切换时会丢掉一些只有原模型才能弄的消息，比如说像某些模型会返回必须在 下次请求中原样带回的签名数据，而各家的推理块和工具调用 id 也不能一一对应，能随时调模更换模型至少就不会被一家厂商给绑定一家服务故障时可以切到另外一家，也方便拿同一项动物去比较不同的模型，但它并不会让各家模型的效果变得一样。 社区里面就有人觉得就同一个模型接触派货会更加的聪明。其实这个感觉其实并不是，未必是个错觉，只是目前还并不能够归因到某些的改动，因为更短的固定上下文其实可以减少干扰，手格托克也可能来的更快，而 t u y 和流势输出同样也会影响使用感受，但是模型本身并没有因此会去改变。 那么在派 ai 上面，其实它的 a 循环有工具执行和时间流，那么像 pd agent 再把去绘画上下文文件扩展和终端交互起来，那么有了这几层，就派可以直接是当 c 底工具去使用，也可以去通过 sdk， jason 事件流或者 rpc 去接触其他的产品。 在最新的版本中，它其实它已经开始了处理更棘手的绘绘化恢复。就新版的 agent corey 其实已经沦落，就是可以理解为同一个绘画书上有几个可以同时并存推荐的绘画记录，可更新的当前状态以及只能追加的用量统计。 每次都要模型或者执行可能修改的文件，发出请求的工具前，系统都会先记下来接下来要做什么，完成后再去写出结果和新状态。那么假设进程在删除文件中的中途崩溃，那恢复时至少能够知道删除可能已经发生，不会轻易的再执行一遍。那么这套代码其实已经去涉及到了远程连接 会恢复和多个任务运行，那么 parent 就 采用四字节的一个前缀加 cbl 的 一个编码，那同时 power 就是 服务化的形态就逐步加入，使得整个的 pad 界面做得更加轻，绘画连接和挥舞机制也就也做得更加扎实。 其实在整个 pad 的 设计里面，它最有意思的设计其实是绘画树，因为在用户侧的 coding agent 呢，其实会把绘画就存成一个 json l， 就每条记录都有自己的 id 和 parent id 那 对话，因此不必只能一直往后走，就用户可以回到另一个节点中重新开始。那么原来的分支依然留在同一个文件，它非常像什么，像一个 get 的 一个提交图， 它不是聊天软件里面那种越拉越长的消息列表。所以如果我们去查一个疑难问题的时候，就命令输出和日制很快会照搬上交文，那如果方向错了，会 继续在原规划里面去解释纠正，原也会留，往往会留下非常很多无用的一些信息。那么派允许从一个比较干净的节点再另外开一个分支，需要时再把原来的分支节点带回来，就是用户能够明确决定哪些内容能进入下一轮请求，这比笼统的说管好上下文要实在的多。同时 长绘画还是需要去压缩的，那么在默认在上下文中超过窗口上限点就是一万六千三百八十四 token 时去自动去触发。也就是说绘发绘发压缩，它会保留最近约两万个 token。 把更小的内容去整理成一个结构化的摘药就完整记录还是能拿在 jason 的 样里面， 就是下一次发给模型的则是摘药加最新的消息，那切换分支时也能生成摘药，并记下此前读过改过的一些文件。摘药会丢信息，这个是大家都可能都知道的，那么模型 必须要自己去判断什么值得保留。一条可能很久之前出现，但后来没有被反复提及的约束，也可能被漏掉，那么 pad 能做的就是让这个过程能看得见，预知可调，摘要逻辑也能扩张，会话那么长，会话里面的旧信息也依然会被丢失或者变形，而 pad 只是让用户有更多的办法去检查和调整。 pad 二六年初其实已经迅速的就走进了大众视野，就也是有 open crow 有 非常关的关系，在一月底的时候，别人 发布了一篇文章，明确说到当时的 open core 底层是使用 pad 的， 而 open core 的 爆发也是带来了大量的投资的，那些联系也间接促成了 pad 后面的商业化安排 那但是如果说今天还说 open core 是 由 pad 驱动的就不准确的，因为 open core 现有的架构其实已经明确明确表示它已经有了自己内置的 agent 的 wrong time， 就 不再保留外部的 agent 框架一代了。所以当前 open core 里面已 直接复用的可能就只只有这么一个 t u i。 用户早期采用 pad， 就 说明这套代码足够轻，能量能复杂的产品就很快起步，那么上层产品也可以随时修改或者替换核心。那么后来自建为一个 long time， 就 说明通用框架未必能够长期满足如何管理权限任务，该发给哪家模型就会画如何继续使用等 一些装样的需求。而 pad 目前它还在核心里面，其实一直不愿意在核心里面内置 m c p， 因为它更偏向于一个 cd 加 red mean 加 scale， 因为它在启动时，它只把 scale 的 名称和简介放进上下文。只有真正用到 某项 scale 的 时候， pad 才会去拿模型去读取专项的一个 scale d m d， 然后通过巴士执行脚本或者 mini， 这样其实它既能够节省 token， 也不会让暂时无关的工具去 说明去干扰模型。而这开发者在二五年的就已经举过两个例子，就是啊， precreate m c p 的 工具描述约占十三点七千的一个 token， 那 么 crime dv 二 c p 就 占十八 k。 那 么如果服务器在每次汇报开始时就把几十个工具定义全部塞到模型， 那么批评其就成立的就是任务还没开始时，窗口就已经被工具就说明占掉一部分，那么提示缓冲也更容易失效。 所以问题就主要是出在于工具盒是被发现和加载，而不全是 m c p 协议本身，所以现在越来越多的实践其实支持延迟加载工具。那么而最新的 part 其实也在试喷试配就是 open ai 的 response and defaulting， 就是 d p 其实嫩呢，能够解决一些实际上的问题。工具说明和认证方式的更加统一。远程服务也可以与 agent 联成隔离，在某些场景中，频距只需只需停留在服务器上，无需直接交给 agent， 那 么改用 city 也不会自动变得更加安全，只会符合 unix 用户的习惯，而模型临时组合命令时也更加的方便。 所以核心不内置 m c p 只是一个合理的默认设置，并不足以证明 m c p 多于我们。在日常使用 pad 的 时候，我们可以通过扩展形式接入 m c p， 平时只需要按需接入 scales 确实能更加神透彻。所以无论选用哪种方式，其实都应该避免把 暂时用不到的整套工具说明放长期放在上下文中。需要注意的是 pad 它其实没有内置插箱啊， read 和 brush 都已启动， pad 工具用 权限去运行，像拓展和第三方 package 也一样，就是官方安全文档明确其实也写到了就项目文件代码注式和命令输出里的提示注录其实是本地 agent 本身的 该有的风险就是官方他其实并不承诺啊能全部解决。尽管他把这些风险就写得非常清楚，但但是他早期的是把一些权限确认就称作为 secretariat， 就是 安全管理。这个 其实有些过头，因为大家使用 code agent 的 时候就经常能够出现频繁地去弹窗确认，就需要你去做一个养成直接点同意的习惯，那么命令黑白名单也堵不住所有的数据外泄的路径就可操作系统级的沙箱，只读挂载 网络出口限制和独立屏据，那那会可以把事故的控制就放在一个较小的范围里面。而 pad 现在其实已经加入了 project， 就是 交互模式，遇到项目级的设置拓展和包时默呢会训会询问用户是否性能，该项目就是它能够防止 pad 一 进仓库就去加载， 但它其实并不是运行沙箱。那么 hmd 等上下文呢？可能被获取到用户选择性能后拓展也能够完拿到完整的本地权限。那么对于陌生仓库和无能之手的一些任务，就 方其实更加建议去使用容器虚拟机或者微型虚拟机，就只挂在必要的目录，也只提供短期的频距。所以真要控制权限，那么还得靠一些隔离环境， 同时我们还得去看一下它的插件供应链，就是因为 pad package 可以 从 npm 和 git 安装，它的扩展其实能执行任意代码，就 scale 也可以去引导模型执行脚本， pad 自己的核心代码会更加容易看得懂，那么装像几十个 扩展之后，用户实际效性能的代码会反而非常多。所以团队在使用 patch 应该固定包的版本或者 git commit 去维护允许案中的清单，并且发送模型请求和执行真实命令的进程都使用不同的权限。每个人都能从社区里面去装一套增强包，后级去非常去难以做去一个审核， 所以数据流方向也要相对清楚，就绘画其实默认保存在本地，用户主动调用内置的 share 或者其他的发布工具才会去 share 等等诸多此类的。那么为什么用户这么喜欢这个 pad 呢？因为 pad 社区讨论其实主要围绕的几个固定的话题啊，像 hack news 啊， reddit 啊， 他们都有的讨论他其实参与者其实更多是愿意折腾终端工具的用户。而在支持者上方面，就是他们反复提到他的启动时塞格模型的固定内容，少提议会反应非常快，规划书也非常的好用， 也有不少用户看中随时更换模型，但他们担心单一场上去更改订阅规则，收紧额度或者调整系统提示时。而且有呢，甚至把 pad 比做 a 卷的时代的 vim 就是 刚装好时功能不多，但是其实可以慢慢的去调整自己习惯的位置。 但质疑的呢，其实也非常的具体，比如说啊，有人一上来就会问 api 会不会刷到几万美金就订阅账号会被第三方登录给限制，怎么去防住 r m 这样子的一些敏感的操作？其实 pad 其实并没有去解决这些问题啊，它可能就是像账单上限，账单用法，命令权限需要自己定 除掉此类的一些东西。二六年四月份这个开发者就宣布加入了 ender， 他 们也去将自己的 pad 的 一个一些 git 去迁移到新的仓库，那么 pad 其实会归公司所有。按照 开发者的他公开的说法就是基础方向，版本计划和代码合并和开源范围是由他和一些商业公司去共同去决定的。目前其实公开的商业化方案分为三部分，就是现有的核心去技术去使用的一些开源策略， 官方承诺也不会更改，但是部分的新增功能可能会成呃，会采用 us 再转为开源，那么企业功能和云服务可能也不开。不会开源，需要确认是就已经以 m 许可证发布的代码去维，无法事后收回任何，可以去 fork。 那 么对于国内开发者来说，派能不能替代 client code 呢？ 所以其实如果按照功能清单去着相对照的话，就很容易去错过 pad 的 长处，它其实它比一套什么更像一套自己可以组装的 coding agent。 因为 pad 以及内置的 d p， c， kimi， mini， max 或者说等等诸多国内的一些模型， 它也支持 open ai 的 兼容接口和本地的一些接口，各人开发者可以随时根据模型和难度去切换，那团队也可以让所有的模型请求先走公司自己的网关， 去季度费用，再去动态的去调整模型切换，但是街上的国内模型并不意味着拿过来就能用，合规审查就请求实际上发到什么区域啊？代码是否允许交给 该模型服务？日日保留多久， a p i t 能不能随时撤销 share， 能不能访问办公网和生产环境，这些都是其实是需要逐项的去确认，并不会给替企业去做这些判断。那么对于团队来说，他如果真正要落地的话，就最好是统一准备模型网关、基础镜像和扩展白名单就默认只允许读取必要的文件， 每个任务区放在隔离的工作区里面去运行，只挂在仓库和 p r 的 缓存，就像生产操作另走审批，不让 a 到长期的云屏据就统一管理，之后派的代码才更容易检查，方便修改，这些特点才能派上用场。那么如果各自安装，那就可能会出现一些新的一些权限的问题。 所以到最后就是 coding agent 呢？到底好不好用，其实并不能只看模型固定的提示词写多少，工具如何组织绘画如何保存，压缩权限如何控制，同样会影响到最后的效果。就 pad 的 做法，其实是尽量去少加固定的规则，因为它只用了四个默认的工具， 并且它会去减少模型需要理解的内容，就同时它的绘画术去保留分支，按顺序读，去 scale， 各种需要的功能去交给扩展。它也支持接触多家模型用户，去去去，随时的去更换服务。但需要注意的是，它的 它的安全问题其实也是非常的重要，同时它的一些极度的简化和高度定制化也是需要去用户自己去处理的，那么它把这些决定权交给开发者，同时也会要求你对它进行一些自己自定义的一些东西。 所以派适合谁呢？他其实是更适合愿意自己定义工作的维护隔离环境的一些开发者，他对于那些想装好就用的团队，他其实是需要自己补上笼气网管和权限配置的。那同时啊，由于他的一些商业化的一些操作，他会把哪些功能留在开源的， 而且外部的一些贡献者能很大影响去影响方向呢？这些都需要去考证的话题。好的，那我们本期视频就到此结束了，我们下期节目再见。拜拜。
202前端小卒
01:29查看AI文稿AI文稿打磨了三个月的系统操作项目，现在已经，嗯，开源这个可以让你的 agent 直接拥有系统的操作能力，可以替代直接替代你的电脑操作。 你不一定非要用 codex 的 computer use， 因为 computer use 是 靠模型的图像理解能力，每次都要识别。 然后纳法斯 m c p 呢，它是内置了三十六个系统原声的操作能力，其中包括十五个啊，桌面的操控，还有二十一个网页的操作 啊，全部都是系统原生的啊，当然我们也支持呃， linux 和 mac os 啊，但是呢，在 windows 上跑的是啊，就是原声最最好的体验。 现在我昨天做了这个啊， npm 的 一键安装啊，所以安装这方面大家一行命令就可以安装了。 嗯，迅速可以让你的艾金特拥有强强大的双手。呃，随着这个我们纳法斯 m c p 的 开源，我知道啊，就是短短的几个月之内，未来的艾金特系统操作将会彻底爆发。
2896Nuphus
07:07查看AI文稿AI文稿如果你在认真地去做企业 agent， 落地派 coding agent 这个项目的话，一定要好好地去关注它，非常重要。我们知道啊， opencloud 这个项目的话，我们大家都在用啊，就是龙虾它底层的集成呢，其实就集成这个派 coding agent， 他为派 code agent 呢，中间还写了一个整个的一个文档，去介绍一下他怎么样的一个集成。那今天呢，我想给大家介绍的话是他的灵活度和以及为什么要关注他，他未来有可能的一个发展方向和未来能给企业做服务，能做哪些场景。其实派设计的一个理念呢，就是核心呢，就是极度的经典，把所有的扩展呢交都交给用户去做，那这样用户就有很大的扩展能力。而 它的工具呢，只有这四个方法，读写、编辑，还有去运行和办事命令。因为它这种极简的设计哲学呢，所以派本身呢，其实是不支持 m c p sub agents， 还有一些 play model 啊这些，比如说 to do 啊，我们以前在 loken 啊，在其他框架里边经常见到这些东西，它 本身都不支持的，但因为它这种简约和灵活度呢，我们更可以在它上边呢去构建很多有意思的东西。然后你看啊，在一个没有 m c p， 没有 sub agent， 没有任何东西的地方的话，它能够建一个贪吃蛇啊。另外一个案例呢，就是在它没有 sub agent 的 情况下，我们可以自定义去做我们自己灵活的 sub agent， 比如说下边这个命令呢，我让它开启五个 score 的 sub agent， 然后跟我说一下，哈喽， 我们点确定之后呢，他就开始并行出五个 safari， 然后再跟我去打招呼，而且你发现啊，这个 safari 他 们都是并行的，他们一起呢，再给我进行一个一些输出，那这样的灵活度呢？就错着，他其实是有很大的想象空间的，那这些想象空间呢，正好结合我们企业中可以去落地的一些场景，就可以做出很多灵活有意思的一些东西。 我们知道啊，现在所有的模型呢，其实都是一个 react 的 一个循环，也就是用户的信息呢输入进来，然后呢交由模型，模型的话就去掉工具，如果不使用工具呢，就给用户进行和返回了。 那基本这样的 react 循环呢，现在已经成为一些共识了。我们看这张图啊，它比我刚才描述的整个 react 循环要复杂很多，为什么呢？因为它在整个的，我们刚才说 react 的 交互链里边呢，派把它几乎每一个可以设置的一些节点的一些行为呢，它都给它扩展出来了，那这些扩展行为呢，我们就可以结合我们自己的程序呢，插到不同的扩展点， 从而呢完成不同的扩展的功能。也就是我们刚才能看到，比如说贪吃蛇啊， sub agent 啊，这些东西我们都可以做到了，我给大家看一看啊，就比如说派 agent 启动的时候呢， session start 本身就是一个扩展点，我们基于这个扩展点呢，可以去做一些内容，然后 resource， discover 资源的一些发现，我们在这也可以去做一些，然后包括比如说我们熟悉的说啊，一次 ter agent 启动之前，我们可以做一次，比如，比如说 before agent start， 对 吧？ 然后呢比 before agent start 之前呢，我们在这个节点去做的时候，其实我们就可以去改很多提示词，相关的信息，系统提示词、用户提示词都可以去改。除此之外呢，它还包括细致到我们的工具里 边，工具调动之前是怎么样的，工具掉的时候怎么样，工具掉结束怎么样？然后特人的结束是怎么样？然后包括 agent 的 结束，然后等等，然后还有一些里边非常关键的一些命令，比如说 new 一个 session， 然后这里边也有很多的事件的扩展点， 包括你去 fork 出一个一个 session 出来，然后还有一些压缩呀，然后 tree 啊，就是分分叉逻辑啊这些，然后包括你切换 model 的 时候，它几乎在任何可见的这个生命周期的任何点里边都给你做了扩展。那基于这些扩展点呢，我们可以无缝地把派的这些呃 内容的无缝进行对接。那这里边的无缝其实是指的什么呢？就是我们做这些所有的程序啊，其实都是扩展程序。扩展程序呢，就是指我们只需要在我们的代码里边呢，去继承一个 它的扩展插件的一个 api， 然后底下呢，我们根据它的这个扩展不同的扩展点，比如说我们要注册 comments 啊，还是我们需要去呃监听一些生生命周期的一些呃事件点啊，然后我们去写我们自己的程序就可以了。那 这样的扩展点呢，一个一个呢就成为了一个一个的小的一个扩展功能，那这些扩展功能其实是可迁移，然后随时可配置的。我给大家举个例子啊，比如说刚才呢，我们这个派呢，其实用的是贪吃蛇这个扩展点，然后呢我们在杠 e 的 时候，后边我们就可以加上贪吃蛇这个插件，这样的话我们就有贪吃蛇这个功能了。如果我们没有这个插件的话， 我们直接运行派的话，其实我们这个 snack 其实是看看不到东西的，然后什么东西都没有的。那所以呢，他给了我们一个非常好的一个启发，就是说我们呃派后边杠一呢，可以杠很多很多的插件。我给大家看一个啊，比如说在这里边呢，这是跟我能打招呼的一个插件，那我们跟他呢去说一下 hello， ok， 那 这里边呢，他就跟我说了一个 hello there， 嗯，那他的灵活性呢，其实是在这里边给大家看一眼啊，就是我上面呢，其实我是使用了这个插件嘛，那我们那插件呢，除了 hello 以外呢，我们再加一个贪吃蛇， 然后我们进来之后呢，它其实就拥有两个功能了，然后这里边还有一些 s snack， 还有哈喽的这些功能，那这样的话它的灵活度呢，其实就非常高了。 一个呢是我们这些插件呢，其实是可迁移的，也就是说我们在本地上调好的一些东西，其实我们是可以给其他人去用，或者爆露出一个服务区用的。那而且它本身呢是支持一些 s、 d、 k 的 一些对接，比如说对 ts 的， 然后也比如说对 python， 它其实是支持 r、 p、 c 的， 然后所以有这些灵活点呢，我们在本地啊去构建很多东西之后呢，这些东西其实一一 一起打包，是可以去直接去迁移到生产环境去使用的，这个是它官网写的很多很多的这些这些扩展，然后这些扩展呢，我每一个里边呢，我都给他写了一些案例，这些效果基本上我都测过一遍了，我给大家看一看啊，然后这里边，比如说 tos 里边，它会告诉你它在哪个生命周期，哪个节点，它进行了 呃改写，然后或者说进行了一些封装，然后怎么去运行它这个命令，然后并且呢它后边呢是效果可能是什么样，表现是什么样的？然后你看啊，它从 hello， question， 然后后边到我们熟悉的，比如说土都啊，然后到下边包括改变它的这个语气啊，这是改变成海盗的语气，然后自定义一些 summary 啊，然后还有 handoff 啊，我们可以去去把原文进行提交啊 啊等等。然后这些东西它其实都进行了一些封装了，所以你能看到它扩展性和灵活度是非常高的。然后后边呢是包括它所有的这个时间，甚至模型状态的时间啊，然后 provider 时间啊，然后包括 system 的 这些时间的话，它都有，我们都可以在这个例子的基础上我们进行一些改写。 然后下边呢包括压缩啊， session 啊，这块的话，它做的是非常细的。然后下边呢它还做了一些 sub agents 啊，还有 sandbox 啊，包括远程、远程、 s， s， h 这些内容，那它灵活度如果这么高的话，我们就可以很轻松地结合我们自己的一些呃， 思考啊，企业的场景啊，我们去把 a 阵呢，其实可以快速构建出来，那我初步的想法呢，其实是它的这个整个的这些代码呢，都有案例，都有说明，那这些案例和说明呢，其实都是结合这个整个生命周期来做的，所以它的底层逻辑是我们有了这些扩展说明和以及有了这些对生命周期的 深度的了解和它原码给我们提供那些 demo 的 扩展的写法。我们结合这几件事的话，其实你就会构建出一个 agent， 呃，派 coding agent 的 一个原起式词词，那我们结合这个原起式词上边呢，主要构建我们的自己的思维，构建我们的想法如何去解决这个业务问题， 然后报在我们看懂生命周期的前提下，我们就可以无缝的去设计很多很多这样的一个 agent。 所以 这也是说我认为派 coding agent 是 必火的一个原因。就我们现在啊，不管是看自动化编程和 gsd 也好，我们再看呃 cloud code， 然后他里边用的派也好，包括我们最近看那个 hermes 这些东西，他们都在用派，因为他发现这种极简极透明的东西的话，其实会比我们直接去构建 cloud code 对 于企业来讲会更有价值。所以我所以我跟大家说，如果你的企业在认真的去构建一个 agent 的 智能体，嗯，这个项目的话，一定要好好看一看， 它的价值其实是非常大的。然后最后呢，我再给大家看一看那个它的系统提示词啊，系统提示词其实我也抓出来，你看它只有这部分，而且它对于我们是透明的。 呃，前面呢介绍一个大概的一个原因，然后如果呢我们里边去注入工具了，这个工具就放在这里边，如果没有的话，它简约的只有四个工具，下边呢是一些工具的使用的场景和写法。 然后，所以呢，你看在下边他自己还给了一个派文档的一些说明，然后这些说明干什么用的呢？就是他认为自己派 coding agent 呢，是可以构建自己的，我通过查询这些文档就可以了。所以呢，那如果呢，你在使用扣呃派 coding agent 的 时候，你把它切换一个比较强的一个模型，你其实就可以构建 派 coding agent 呢它自己的这些插件了，从而把它自己进行一个扩展。那除此之外呢，你看下边它可以给你留很多那个相关的一些呃端口出来，比如说可以加载一些 skills 啊，比如说可以抓追加一些提示词啊，但是它很简单，它只有这些内容啊，希望今天内容呢对你有收获，关注雷哥，关注 ai 工程化落地。
1100雷哥AI
11:38查看AI文稿AI文稿我大胆估计，真正理解智能体本质上是什么的不超过百分之十。在最近的一期访谈中，有位大佬说，如果你不能用三百行代码构建出一个 coding agent， 说明你最多只是一个初级工程师。因为你不理解智能体的底层原理， 所以我们今天就来介绍一下智能体的本质到底是什么。我会介绍一个很火的项目叫 python agent， 同时也会说说如何用三百行代码构建一个 coding agent。 我第一次听说 pyadrill 时，是有人说大名鼎鼎的初代龙虾 open curl 就是 基于 pyadrill 开发的。 这么牛逼啊，所以我赶紧去看一下。经过一段时间的研究，我的结论是，如果你在学习 ai， ai 的 开发，那么 pyadrill 是 一个不能错过的项目。 我总结下来，关于 pyadrill 有 三种用法，第一， pyadrill 本身也是一个特定 ai， 所以 你可以把它当成 curl code 的 替代品，这在社区很受欢迎。由于可以自己拓展功能，所以它有非常多的玩法。 第二，派，这个 coding agent 本身也是开源的，所以你可以向他学习如何开发一个生产级的 agent， 相比另外一个知名项目可拉扣的派会更好入门。第三，跟龙虾一样，你也可以基于派构建自己的智能体。总有人在问开发 agent 要使用什么框架，我觉得那就不如试试派吧， 我就用它搭了一个 data agent， 非常的好上手。这三种用法我都用过。首先，我们来看一下 pad agent 怎么用，有什么特点。来到 pad 官网，根据你属于哪个平台，对应执行这里的安装命令，就可以安装上 pad agent 了。 接下来要接入模型，我们来到系统用户目录下，找到点 pad 文件夹，进入 agent 文件夹，新建 models， 点 agent 配置文件。 在配置文件中，我们参考这一段，写入你自己的模型配置，这样就行了。注意，如果你是使用 coding plan， 那 要看一下是否支持派，比如说 g o m 的 coding plan 套餐，它就不支持派。 接下来来到你的项目文件夹，在命令行中输入派，回车就可以启动派件了。 我们在拍整的对话窗口中输入杠 model， 可以 切换刚刚配置的模型。剩下的用法跟 cloud code 等软件差不多，就是一问一答。我们就不介绍了，我们主要说一下派的特别之处，以及它为什么这么受欢迎。 拍 a 准崇尚的是极简理念，默认的功能非常简洁，连我们常见的纸质人体、 n p p 计划模式这些都没有。派认为这些都是非必要的。那如果你真的要用，怎么办呢？也有办法，拍 a 准有个特殊的东西叫扩展，如果你需要什么功能，可以自己以扩展的方式接入。 我们来看一下。进入官网，来到这个页面，这些就是官方收入的扩展，目前应该有数千个了。 pi 的 扩展生态分为四种类型，分别是 skill、 提示词、模板、主题和 extension。 其中 extension 是 最重要的，这是代码扩展，可以用来定制 coding agent 的 各种功能。具体的实现机制我们先不去管，你简单理解，这是一个软件，包装上去之后就可以有对应的功能。这边我对下载量前二十名的扩展进行了整理，主要是这些功能， 比如上下文管理纸 a 证的应用、 m c p 应用及管理等等，你需要什么功能，就对应安装什么扩展。 安装扩展的方法也很简单，复制这个命令，直接在命令行里面运行就可以了。接下来在启动拍 a 证的时候，我们就可以在这里看到安装了哪些扩展。比如这里我安装了一个 web ui 扩展，可以在 web 里面操作拍 a 证。我们来试一下这个扩展， 在拍诊对话中输入这个命令，启动 web 界面，那接下来我们就可以在 web 界面里面操作拍诊了。 web 界面相比命令行界面的操作体验会更好，使用起来也会更方便。 这个就是扩展的用法，查找下载使用非常简单。如果你觉得官方的扩展不够用，也可以自己定制访写影，不需要你自己开发官方文档就给出建议。你可以让 ai 自己阅读项目文档，然后按照需求开发你自己需要的扩展。 我们总结一下拍 a 准的特点，最大的区别是 cloud code 之类的软件是把它觉得好的功能塞给你，不管你实际是不是需要。而拍 a 准是鼓励你按照自己的习惯构建自己的 coding agent， 适合喜欢折腾的人。 好到这里只是让你对拍 a 准有个基本的认知。接下来我们要来到今天的第二个话题，看看拍 a 准的项目源码，学习如何构建自己垂直领域的智能体。 打开派准的项目员吧，你会看到派的这几个包很有意思，它是层层递进的，我们主要关注这三个， ai agent 和 coding agent。 ai 这个包是负责模型调用，为什么模型调用也要专门做一个包呢？因为市面上的模型服务实在是太多了，不同的模型有不同的调用方式，具体来说就是这些模型服务的输入和输出都不一样， pager 对 起做了一层封装，以便可以使用同一的方式调用不同的模型。这个功能其实挺常见的，比如说 open ai 包也是这个功能， agent 这个包只负责维护一个智能体的循环，而 coding agent 这个包才是关于编程这个场景的具体业务实现，比如定义了工具，定义了系统提示等等，这是一个非常清晰的架构。 ai 和 coding agent 这两个包很好理解，一个管模型调用，一个管具体功能实现，那 agent 这个包你可能看着有点困惑，什么是智能体的循环呢？为什么智能体的循环需要一个包来单独维护呢？这个就是我们今天的重点， 智能体本质上是一个不断调用模型的循环，不管你是什么场景的智能体，本质上都是在跑这么一个循环，这个循环太基础了，以至于派专门写了一个包来维护它。 我们来捋一下关于模型的使用，主要是三种方式，第一种是单轮调用，也就是你输入一段提示时，模型给一段答复，然后就结束了，这时候给你答复的是模型，不是智能体。 第二种是工作流，你设计一个流程，什么时候开始，什么时候结束，中间有几个步骤是预先定好的，模型的单轮调用只是其中一个环节，私底下大部分人对模型的开发应用其实就是上述两种，但严格来说，这两个并不算是智能体， 那么严格意义上的智能体是什么样的呢？就是我们前面说的，在不停的循环调用模型。具体来说就是你输入一段提示时给模型，模型决定要不要调用工具，如果要，那程序就执行工具，执行完工具之后，把工具的结果再送回模型，模型再决定下一步怎么做， 如此循环，直到模型觉得不再需要工具了，会给出最终答复，那么这个循环就结束了。相比前两种方式，这种方式的特点是，第一，模型不是单轮调用，而是多轮的。 第二，中间要经历什么流程，什么时候结束是模型决定的，不是人类预设的。我们以编程这个场景举个例子，一个常见的流程是，你说我要改某个程序，模型可能会先调用 read 工具，阅读相关的文件，理解这个需求， 然后调用 edit 工具，写入文件，不断地读，不断地写，直到完成工作，然后给出答复。在这个流程中，模型就是反复的调用工具进行读写而已。 因此，有人总结，智能体等于模型加工具加循环。你可能会觉得难以置信，高大上的智能体背后难道就这么朴实无华吗？为了让你进一步清晰的理解，我们来通过一段简单的代码，看看如何通过这个简单的循环开发一个极简版的 coding agent。 首先我们定义要使用的模型啊，目前主流模型基本都可以随便填。接下来这里定义的模型要使用的工具分别是读取文件、列出文件的目录和编辑文件，总共这三个工具。从代码来看，这三个工具的实现都很简单，都是拍省标准库的函数而已， 要说有点复杂度，最复杂的是这个编辑工具，编辑文件的本质是将旧文本替换为新文本，也就是一个 replace 函数的事情。然后编写工具的 schema 说明，这是给模型看的，工具调用说明是必备的，没有这个说明，模型就不知道有什么工具怎么使用。 接下来是一段简洁的系统提示词，设定了模型的人设，告诉模型有哪些工具以及基本的做事方法。最后就是核心的代码的在代码中维护了一个循环，我们来看一下这个循环是怎么跑的。 首先根据用户的提问发起第一次模型调用，得到模型返回的结果就是这个 message， 接下来判断 message 里面是否有工具调用指令，如果没有，那就直接 read 结束循环。 如果有工具调用指令，就从 mesh 中提取出所有的工具调用指令，然后逐个执行工具，得到工具的执行结果。 接下来这里有个 append 表示，将所有的工具执行结果拼起来，然后进入下一个循环，在下一个循环就会将所有工具的执行结果发送给模型，由模型决定下一步操作。 整体来看是非常简洁的代码，跟我们之前说的一样，就是三个要素，模型加工具加循环。接下来我们试一下效果。首先来个简单点的要求，创建一个文件，内容为哈喽冬瓜 运行一下，这里有录制，我们看一下模型调用了编辑工具，生成了新文件，然后我们看一下文件列表，这个文件的确生成的，我们点进去看一下内容，没错是哈喽冬瓜， 接下来提升难度要求给这个文件添加一个函数，实现斐波拉取数列。这一次模型调用了比较多的工具，我们来看一下，结果这里多了一个函数，执行一下 是斐波拉取数列。没错，后面还有几个测试我们就不做了，大家可以自己试一下。代码我会放到评论区中，大家自取。这个代码用的是摩达的 note book 产品，大家点击链接，设定一下自己的模型就可以用了，不用自己安装环境。 通过这个案例验证了我们之前的说法，智能体运行的本质就是循环调用模型。但可能有人会困惑了，那不同智能体之间的区别是什么呢？ 我觉得啊，最大的区别在于给智能体配置不同的提示词和不同的工具，以便支撑不同的场景应用。那当然，此外还有上下文管理方式、工具应用方式等工程细节，这个就是所谓的哈尼斯工程。 在实际开发中，你可以尝试参考这个案例，设定一段提示词，给定一批工具，先把这个循环跑起来看看效果，然后根据出现的问题在不断的打补丁。最后我们再深层次的想一下，智能体的循环本身是很好理解的，但你有没有一个困惑， 为什么模型不再调用工具，我们就认为可以终止这个循环的呢？这其实是人类在代码中定义的规则， 换句话说，为什么模型不在调用工具就一定是完成任务的呢？难道模型不会单纯的说我看到工具结果了，让我再想一想吗？ 答案是，在模型的队形训练阶段，模型就学会了他要么点调用工具，要么得出最终答复。如果不调用工具，又没给出最终答复，那么他在这一轮队形训练中会得到底分。 久而久之，模型就学会了他得调用工具，获取充分的信息，直到他完成任务可以给出最终的答复，才可以停止调用工具。 当然，这里的完成任务不一定是解决用户的问题，能够准确的回答不知道也是完成任务。正所谓知之为知之，不知为不知是智也。 好了，以上就是今天的全部内容，今天先做个论文介绍，下次我们会继续抽丝剥茧。完整的介绍派是怎么维护这个循环的，感谢！下次见！
8489费曼学徒冬瓜
00:43查看AI文稿AI文稿pi agent 是 仅次于 cloud 的 第五好用的智能体，它以极简和极高的拓展自由度出圈，具有庞大的社区生态。下面推荐几个值得安装的插件。 pi web search 零配置，无需密钥，一键开启联网搜索和网页信息提取，可实时获取全网最新资料，解决 ai 信息滞后问题。 pi sub agents 支持多子代理并行工作，项目级安装不浪费头肯，可高效拆分处理复杂批量任务。 plan mode 智能计划执行模式， ai 先输出方案，待用户确认调整后再执行，有效规避任务出错返工。 pi b t 都旁路插电， 通俗讲就是 ai 工作时可开子窗口提问，不打断主任务，相当于 cloud code 的 b t 都功能。 pi wechat assistant 扫码即可完成手机端配对，实现手机与 pi 双向对话，数据同步，随时随地移动端高效写作。
814算力炼丹炉
03:29查看AI文稿AI文稿主包上个视频火了， knack 三 c p 让你的 agent 拥有强大的系统操作能力，但那个视频做得比较随意，我当时默认了大家都会让 agent 自己读说明，再教自己安装，结果评论区全是基本功问题，主包在评论区回复回复再回复， 硬生生把自己从开元大神的人设干成了开元客服。所以这期主包痛定思痛，用我不完整的剪辑技能， 给大家剪一期内容完整的安装使用教程。如果你的 agent 想要丝滑的系统操作能力，这期耐心看完，应该能帮你省掉不少弯路。首先， nasmcp 是 什么？一句话，这是一个系统自动化操作的工具级，安装之后，你的 agent 就 拥有了完整的系统操作能力，适用于任何支持 mcp 的 agent， 所有主流 agent 基本都支持。所以无论你是 codex cloud、 hermes、 open cloud， 还是 open 不 cloud， 甚至你自己做的 agent 都能装。目前 windows、 micros、 linux 三个平台都支持。但先说明白， linux 下部分工具用不了，比如窗口操作受限， 这是系统本身的限制，不是项目的问题。为了大家用着方便，我把它从 nakas 主项目拆出来，做成了独立项目，而且 nakas 自己也在用它，所以大家踩的坑我一定也会踩，有问题我们一起处理， 这才是开源真正的价值。安装篇安装其实很简单，核心就一句话，让 agent 去读项目的 readme 和 tools mb， 他 会教你怎么装，不用你手动敲命令，把这两份文档丢给你的 agent， 让他自己研究自己装， 装完让他自己验证一遍能不能连上。评论区问的最多的装不上，连不上八成是环境电量或者启动参数没配对，让 agent 按文档核对一遍，基本都能解决。重点， vision 配置装好之后，我发现绝大多数人都不去配 vision， 但这一步 恰恰是丝滑和卡顿的分水岭。如果你想让 agent 操作，点击非常精准顺滑，这个图像理解模型是必须配的，具体怎么配，直接问你的 agent， 它比你看教程快。这时候肯定有人要问，对这个图像理解模型的 a p i p 会不会影响我的主 agent？ 完全不影响你的主 agent 该用什么模型还是用什么模型。图像理解是独立的， 你的主 agent 需要看屏幕的时候才临时调用一下威信，看完就还回去，平时完全不占用，所以放心配。这是加装了一个眼睛，不是换掉你的大脑。进阶技巧。最后说个进阶用法，原则上只要人能操作的， knock 三 c p 都能操作。你可以让 agent 每次操作完把流程和参数固化到你自己的文件或 skill 里，下次再让它执行，直接附用固定参数就不用重新描述一遍， 能省下大量重复的 tock。 另外提醒一句，目前大部分模型没有专门强化过系统操作能力，所以想让 agent 更顺， 操作前把详细的交互流程和顺序给它讲清楚，它就能跑得很丝滑。如果使用中遇到问题，到 github 提交 a 数或者 p 二都行，按 milo g h 斜杠 nka 三 c p 就 能找到，我们一起改进。最后祝大家长命百岁，天天开心！
3080Nuphus
01:32查看AI文稿AI文稿天塌了，兄弟们，我之前用 codex 搭多 a 证的工作流，前后喜提卧龙，奉出两个大坑啊！先说第一个卧龙啊，一开始我也什么都不懂， 项目也没有创建，就在同一个 codex 绘画里面设置了行政助理，资料整理产出优化。三个 a 证的看起来有分坑，但实际上还是在同一个 ai 的 同一个聊天里面扮演三个角色，也没有真正的上下游的任务交接好了，这是第一个大坑。后来我知道要先创建项目了， 结果凤雏又来了，虽然 a 技能之间能够互相交接任务了，但是我误以为所有项目都应该交给同一个行政助理，不同的项目，不同的任务全部往里塞，最后 ai 形成记忆混乱，逻辑混乱，打非所问，我真的是服了。直到这一次，我才彻底搞明白，每一个需要多 a 证的协助的项目啊， 都需要建立一个独属于自己的工作流，一个项目，一个团队，一套岗位，这样他才能专心干一件事情。我是一个小白，前前后后折腾有一个月的时间， 现在啊，终于是把团队，岗位还有办公室建好了，下一步就是给每一个岗位配置 skill 插件，还有专业的工具。这一部分啊，我们以后再聊，为了让大家少走弯路，我还整理了一份一万多字的 codex 全自动搭建多 a 证的提示词直接丢给 codex， 他 会啊，自己分析岗位创建，绘画设置权限，完成绑定，还有测试，我免费送给啊前二十名留言的粉丝，评论区留下多 a 证的，再附一张 codex 的 pc 端截图 消息啊，我可能会回的慢一点，但是啊，我都会回。最后祝我的粉丝朋友们发东南西北旋风财，每天都是满满登登，坐享其成，不劳而获，想穷都难呐。
969張小偉- -。
02:56
03:22查看AI文稿AI文稿一个个人维护的开源项目，在 data bricks 的 真实代码库跑分里，把 cloud code 和 codex 挤到了旁边， 便宜一半，分数打平。这次给你三个判断，模型怎么选，账怎么算， harness 怎么换。 data bricks 拿自家工程师合并过的 pr 当考题，几百万行代码模型没见过评分，跑测试说话性价比前沿线上七个点， pi 占了四个最高分，九十 是 pi 接 opus 跑出来的。同一个模型换个壳，账单差一倍。模型这层别纠结， opus， gpt， glm 挤在同一层， 分数差三个点以内。开源的 glm 一 块二毛八，贴着一块九毛四的 opus 还有个坑，单价便宜不等于总账便宜，话多的模型单价减半，总托肯翻倍，分数还低六个点。 pi 省钱的第一刀 在起点，在 cloud code 里发一句你好系统提示词，带下来两万头，肯 p i 做同样的事不到一千五，这份前缀，每一轮都跟着它，就是你这次对话的起步成本。第二刀 在过程模型跑， git log 原声输出一大串哈希作者日期，地府 p i 的 扩展工具输出，砍掉八到九成 cloud code 的钩子，只能追加信息，改不了调用结果。 p i 的 扩展可以。 p i 的 设计主张一句话， 框架适应人不是人。适应框架默认内核只有四个工具，运行命令，读写，编辑没有子，智能体没有 m c p， 连 u i 都是插件。官方文档有一节叫我们没有做什么，每项 都留了扩展的位置，内核小，外围给的反而多。四种运行模式，从中端到 j 三 r， p c 到 s d k， 绘画和扩展不变。十五加模型起步，绘画中途一键切换，绘画是数不是线，跑歪了，跳回任意节点重来 skills， 按需加载，装二十个不膨胀提示词， agents， md 管约定 压缩策略都能换成你的扩展打成包，一条命令状。我在 p i 上做过二次开发， s d k 拿来就用绘画存储换成数据库 工具，落到沙河里执行。接口本来就是开给你换的。过瘾的一点。扩展可以让 p i 自己写，说一句，需求他读自己的文档，写出扩展重载就生效。增长最快的 open cloud 底下跑的就是 pi， pi 不是 全赢。提示词只丢一句话的时候， cloud code 那 两万 token 会替你把意图补全，产出更完整。提示词写得越细， pi 的 优势越大。我的分工日常八成给 pi 加国产模型， 剩下两成重活留给 cloud code 三句话带走。模型是租来的，其建挤在一层，算账算总账， token 效率比单价狠。 harness 是 你能控制的变量。框架，适应人不是人适应框架，你是官方派还是开源派？聊聊你的组合。
00:39查看AI文稿AI文稿科技圈直接炸锅，王牌动画库 g s c p 开源了专属 ai 技能包，记住这个名字，在 github 已狂揽一点四万！ star 是 目前超全的动画技能库，它的硬核处在于简单粗暴的接入方式，一行命令秒即注入科三等主流 ai 工具， 彻底解决 ai 瞎编就版 a p i 的 痛点。无需长篇大论，手写提示词，他直接把复杂的时间线排版和滚动逻辑死死刻进 ai 的 肌肉记忆。更爽的是，曾经收费的企业及高级插件线已全部解禁，免费！你只需跟 ai 说句，来个炫酷文字出场。 它不仅瞬间调取高级插件，还能自动做好性能优化，完美规避内存泄露，生产急动效一步搞定，告别反复低 bug， 感兴趣的兄弟赶紧冲！觉得硬核点赞关注，下期见！
4949小嘉实验室
