https://github.com/DukeEnglish/miniagent
背景
我认为大模型最重要的并不是生成，而是理解。 ——鲁迅
你自己都不清楚的事情，让别人去做，你怎么可能验证的了做的好坏呢？ —— 鲁小讯
偷懒是人类的天性，如果想要偷懒，那就需要确定性；但大模型的工作就是不确定，所以我们想要它做那些不精确的不得不做的事情。 —— 我自己
大胆假设，然后就需要做各种理论分析和求证了。其实意义不大，凭心而论，日常自己尝试下来就会发现，想要让一个大模型不断的生成内容本身就很难。这个和实际的训练方式以及现在的长文本训练方式有关。
我们在什么时候希望有人来教？对于技术工作者来说，大多数情况下是阅读别人的代码的时候！这个和读文章，读论文不一样
- 好的文章，当然是直接去读论文的话，核心是希望llm帮我总结一下，么？其实是让帮你翻译一下（?），如果关键，最终还是中英对照自己看一下代码！这个可不是，llm如果帮忙总结一下，或者分析一下代码结构，函数结构，那可是大大加快阅读屎山的速度。等于有了一份完善的README文件，这可太好了。对于很多没有README的工程来说，这种工程要不是因为发工资，谁愿意去读啊。（更何况，代码有时候可真的不需要再去读了，只要知道它干啥的知道怎么跑起来，那就够了）
好了！这个时候我们就可以清晰的知道让大模型读代码，可以提高我们的工作效率！
展示
如下图所示，我们将github的链接贴在这里，并输入必要的api key/sec key等，即可实现对指定github的解析和阅读
项目介绍
如何实现流式输出
这个还是有点头疼的，前后端自己做，完全没有头绪。这个时候就依赖大模型来帮我操作这个事情，这个过程里面我发现，kimi比之前的时候（五月之前吧）笨了一些，GPT4o确实牛啊，GPT4也是一样，整体体感GPT4和o的实际体感还是更好。
涉及技术点：SSE，基础的html/css/js/后端python。
- 如果完全不懂一点点前端，他们给出来的代码写到死可能都出不来，比如我想要实现的效果，是在给定的代码基础上，增加右下角的一个框，或者流式输出的效果不符合预期。此时不断的问，她很容易在之前本身有瑕疵的代码基础上不断的加入新的内容。这个问题就会一直存在，所以需要自己找到去修改，虽然实际代码量不多，但依然存在问题。大模型适合完成整块的逻辑明确的工作，不擅长完成复杂逻辑或者跨文件（即项目）级别的生成，要不就需要付出特别特别多的精力去调试。这个ROI属实不高，都不如我自己学会来修改一下。
如何实现项目代码阅读
你猜为什么现在很多项目并不支持，这是因为移动端！没有人会看代码！
但是，这玩意儿当前移动端是版本答案么？不是！我觉得不是！移动端连字都懒得看了人们，语音对话那慢吞吞的，真的比抖音刷起来带劲么（狗头
所以我们来看看PC端的主要客户群体！他们的主要诉求：
- 帮我写文章/做PPT，分析见上，另外当前的制作ppt的其实和大模型关系不大，早就有了帮我做我原来做不了的事情。不可能，你都不懂怎么调试和验收提高我接受信息的效率！版本答案。搜索已经是大多数情境下的解决方案了，但开放域的信息收集一定是越多越好，也没听说你只采访一个专家。但是封闭域的信息收集和理解，那就不需要越多越好了。
封闭域：就是在有限上下文场景下，并且 大模型 可以大大缩短你的时间，让你不需要关心内容细节，即可直接完成工作。一个代码项目不就是天然的，只要搞懂大概流程和启动流程，就可以直接run了啊！
问题定义
封闭域：就是在给定项目代码工程内
任务：根据用户需求，在给定项目代码的基础上，回答用户问题
prompt设计
将所有的代码组织到prompt中，整体作为system prompt（或者第一个prompt的前缀）。这里有点小技巧，可以用markdown格式。
项目设计
如上所述，就这样。
疑问
好奇，我觉得挺有用的，但是没有人做。我觉得是程序员太苦了，所以没人心疼
代码结构组织
整体设计
本项目以图作为驱动器进行设计使用，目的是降低服务的运维成本，且加强可控和可用性。我认为llm和non-llm都可以直接抽象为agent，所有的问题都以agent为基础单位进行操作，人为对agent进行编排，然后让其完成相应的工作即可。
这样设计，将需要理解能力和泛化能力的部分交给llm；其他部分交给non-llm，由用户作为上帝用图的形式进行编排。（再加一个图形化编排界面就更爽了）。
初版代码我直接实现了 hhh 偷懒，第二版的时候我会优化，将相关的节点设计开发好。设计之初觉得会有很多节点复用，但实际开发的过程中，复用情况更多存在于部分prompt的调整优化而导致的节点复用，我需要再寻找一个场景来验证设计想法。
web前端
当前web前端使用已经有的
- 使用Git子模块（Submodules）
Git子模块允许你将一个Git仓库作为另一个仓库的子目录。这种方法的优点是可以保持子项目的独立性，并且可以单独对其进行提交、拉取和推送。
添加子模块的步骤：
- 在你的主项目中，进入你想要添加子模块的目录。使用以下命令添加子模块：
git submodule add git@github.com:DukeEnglish/agent_web.git web/- 这会克隆远程仓库到指定的路径，并在
.gitmodules文件中记录子模块信息。提交.gitmodules文件和子模块的初始化提交：git add .gitmodules web/git commit -m "Add submodule"维护子模块：
- 更新子模块：定期更新子模块到最新提交。
git submodule update --remote- 切换子模块分支：如果需要切换子模块的分支。
cd web/git checkout <branch-name>cd ..git add web/git commit -m "Switch submodule to branch <branch-name>"- 同步子模块引用：如果子模块有新的提交，需要同步到主项目中。
复制git add web/git commit -m "Update submodule <submodule-name>"一些想法
思维和技能
很多做工程的同学会基于当前的大模型api做很多尝试和工程应用，特别是需要和现有系统结合，或者需要大量其他数据输入输出的情况；还有一部分做算法工程优化，推理或者训练
很多非技术同学会基于大模型构思产品应用；
算法同学既有和上面一样的，也有研究大模型本身性能优化的
理想情况：知道大模型怎么训练出来的，知道他的推理原理和优化原理，然后设计好产品应用，再进行实现。技能可以学习和掌握，这里背后的最大区别则是驱动行为的思维以及遇到困难后的应对方案，这个将会决定最终产出的产品本身的品质。
资源置换
只有当事情还没有被想清楚的时候，才有非资源性的机会。当事情已经被看清楚，此时考验的就是谁更有钱，谁更能扎的下去，是一个规则明确的玩法。
上周一个创业的同学和我沟通投广ROI的问题，结论是当前大模型已经进入到了过去移动互联网成熟的竞争模式，那这种事情做起来既没有意义，也没有意思。
