|
12 | 12 | 适合做什么 |
13 | 13 |
|
14 | 14 |
|
| 15 | +openai的库可以实现agent么? |
| 16 | +现在流行的agent的框架思想是怎样的,针对我的例子有没有什么比较好的方案 |
| 17 | +agent怎么实现,是否会遇到上下文超长,一般要怎么解决? |
| 18 | +比如agent分层的去理解,分摊任务给子agent去搜索理解多个文件 |
| 19 | +如何防止子agent重复搜索了母agent的任务从而死循环 |
| 20 | +是否有办法给他设计一个全局记忆, |
| 21 | +上下文超长,在我的例子里有什么解决方案? |
| 22 | + |
| 23 | +我的外部记忆的问题不是问你怎么存储,而是不管你怎么存,你总要放入模型的上下文里吧? |
| 24 | +不然agnet执行到一半超长了,会没办法继续运行,抛弃过去的记忆又会导致失忆不知道自己在干啥, |
| 25 | +或者重复做同一件事陷入死循环 |
| 26 | +你帮我想想解决方案 |
| 27 | + |
| 28 | + |
| 29 | +我给你提供一个设计,你看合理不 |
| 30 | +1.概览 |
| 31 | +1.1先提供一个总结工具, |
| 32 | +列出所有的文件路径,以及类名,以及函数名列表,变成一个总结文件 |
| 33 | +如果这个文件超长,就切块给大模型 |
| 34 | +同时提交的还有用户的需求 |
| 35 | +大模型根据需求,列出他感兴趣的文件名和函数名等 |
| 36 | + |
| 37 | +1.2.根据大模型列出的感兴趣的列表 |
| 38 | +提供一个搜索工具,把他感兴趣的文件以及函数相关内容节选汇总 |
| 39 | +如果超长,也切块,结合需求文本一起上传,让他再找感兴趣的点 |
| 40 | + |
| 41 | +1.3.直到大模型没有感兴趣的点(感兴趣的点本地也做缓存,如果有重复请求的感兴趣的点就忽略) |
| 42 | + |
| 43 | +2.分析阶段 |
| 44 | +逐个把兴趣点和需求上传,让大模型总结,也就概括缩短内容 |
| 45 | +把总结拼成一个大文本 |
| 46 | + |
| 47 | +3.深入分析 |
| 48 | +把上一阶段的总结大文本和需求上传,问大模型有结论么?或者有新的兴趣点 |
| 49 | +如果有新的兴趣点,回到1阶段 |
| 50 | + |
| 51 | +4.重复,直到大模型说可以有结论了,输出结论(怎么修改代码) |
| 52 | + |
| 53 | + |
| 54 | + |
| 55 | +你深入思考一下,这个设计有没有不合理的地方,如何改进 |
| 56 | +提一些建议 |
| 57 | + |
| 58 | +补充一点:我自己的经验如何看代码和改代码 |
| 59 | + 如果对工程已经有了解(以前曾经读过工程,做过一些笔记,或者有一些记忆),要先找到函数入口,或者和需求有关的流程上的某一环的代码,顺腾摸瓜找到入口 |
| 60 | + 可以先跳到自己熟悉的最近的函数入口,比如如果是某个服务器-客户端同步的问题,肯定是先找到服务器收包的地方。如果是游戏服务器的技能问题,就先找到接收客户端释放技能的上行协议收包入口等 |
| 61 | + 如果还是找不到入口,就从工程的main函数开始,先开初始化函数,找到相关功能的管理器代码。或者找到主循环,一路顺着找到可能和需求相关的调用链 |
| 62 | + 看代码的时候要BFS而不是DFS。也就是不要看到不确定的分支就进去递归的看。而是遇到分支,先做个笔记。 |
| 63 | + 这个笔记可以用缩进来做。从入口开始,每进行到下一个阶段,是并列级别的。如果遇到一个地方有几个不确定的分支,不知道哪个是有关的,先用缩进把他们都列出来。如果感觉他们不止主要流程,就先给他们打个问号,稍后再来看。先去看最可能得主流程下一阶段 |
| 64 | + 如果看完一遍流程,发现线索断了,就找到前面做过标记的那些分支,用相同的方法去看。并实时更新这个笔记。这是人类的方法。对计算机来说,可能就是一颗搜索树,每次只是标记出有疑问的节点,用bfs的方法。如果每有找到答案就继续遍历队列里留下的疑点,但是每轮只遍历一层 |
| 65 | + 直到找到答案才跳出 |
| 66 | + 用这种方法可以比较有条理的阅读大规模代码,理清楚脉络,且不会在某个分支上陷入太深而浪费时间。你可以借鉴这个方法 |
| 67 | + 诀窍就是要忍住好奇心,不要过早去阅读探索某个分支,即使他很有吸引力 |
| 68 | + 这个方法主要是用来收集信息,也就是修改代码的第一步,理解需求,对代码进行事态感知,能够有整体的了解 |
| 69 | + 人类的短期记忆比大模型的上下文还少,但是借助这个方法,就能处理复杂的问题,对作为大模型受限于上下文长度的你可能也有启发。 |
| 70 | + |
| 71 | + |
| 72 | +再深入思考,然后结合你的想法,给我设计一个同样目的的系统,可以改进我的设计,或者用你认为更合理的创新设计 |
| 73 | + |
| 74 | +尤其要注意,会不会出现上下文超上限,或者忘记了之前做的工作,导致死循环的问题 |
| 75 | + |
15 | 76 | 你对实际使用的场景不了解,我给你举个例子 |
16 | 77 | 有一个状态机调试工具(游戏npc状态机),是图形化的,以前的版本使用了一个称为EasyX的库来绘制所有的状态机图 |
17 | 78 | 以及UI、按钮(自己实现的按钮绘制和事件点击响应) |
|
27 | 88 | 怎么知道从哪里开始呢?连从哪个函数开始着手都不知道。也就是都没找到函数入口,流程怎么开始和经过哪些函数。这样怎么开始搜索呢?靠猜么?而且向量数据库对代码其实没啥用,因为代码并不是人类语言,放入向量数据库切块的时候早就丢失了很多上下文信息 |
28 | 89 | 靠谱的方法可能是一开始就把代码切块,逐个给大模型理解 |
29 | 90 | 然后把输出的理解总结和代码块一起嵌入向量反而是合理的,你觉得呢? |
30 | | -综合以上,你重新思考一下 |
| 91 | +综合以上,你重新思考一下 |
| 92 | + |
| 93 | +最好能给我代码以及配合提示词,怎么写这个agent |
| 94 | +提示词最好都是中文的 |
0 commit comments