人脑几 k 上下文能对抗 300k 的 agent？

1.成果好坏解释权归人类所有
2.因为人脑的判断优先级更高，所以上下文压缩知道哪些是垃圾可以遗忘，哪些是重点建立索引
3.人脑因为上下文短缺严重，注重发展了卓越的注意力机制
4.数字化的资产里的细节可以被遗忘，但绝对不会丢失。人脑基于卓越的注意力机制，实现了卓越的 RAG

人类为了将复杂问题装入生物计算有限的上下文中,在多个计算单元间做同步，发明了很多方法：抽象建模,领域术语和具有固定格式的文档。

@0d 总信记忆息量很大，思考具体问题的时候激活的信息不多。

或许是因为人脑永远都在进行训练，学过的东西直接内化，不占用运行时的上下文

人脑只抓关键点，需要细节，才会去把细节放大成下一个关键点

居然拿一个死板的概率拟合表达式去对比一个基于复杂生化反应甚至量子效应的计算装置吗

人脑是分层存储，online nearline offline ，还有 external

多细胞动物的神经系统的演化保底 6 亿年，
AI 才发展几十年，
怎么碰瓷演化了 6 亿年的神经系统。

@ATKLLL ai 写了一小时代码，4w 行，真的没法 review ，产出速度溢出了，认真 review 得猴年马月🐶

没办法，要么自己去看 AI 的代码，要么就全部相信 AI ，测试测试，没啥大问题就行了

@xyooyx
ai 也可以分层记忆主脑子里只记目录
然后需要哪类先内存找某细类加载然后 硬盘找完整结果
记忆没问题了 同时用多少是问题

attention is all you need

我是在不断提高自己的架构设计能力，并把当下要解决的问题，实事求是的看完行业内其他一些公认的细节并跑通（这些当然可以利用 ai 加速赋能），但是源码的过一遍和品味人家架构的设计等等事情，ai 只能帮助整理，然后自己逐个去验证，学和思结合去理解或者思考是否可以优化。 最终得到自己的"道可道，非常道"或者说自己的第一性原理。

后面实际去解决上面提的"当下的问题"时，自己也慢下来，最起码互相隔离的每个项目要慢些，把自己当成架构师，和 code reviewer 即可，不断的将对话，将上下文

精简成 没有 ai 时代时的 人类做的开发日志，细节，问题，决策， 这些文件必须都极其的精简，一个字，词，句子都不能将就，做到当时自己能维护的最好状态，不能 ai 想怎么写就怎么写，自己维护记忆系统，自己不看或者大概扫一下，这样会导致任何一句没有对齐的内容，不断成长为比程序员写出的屎山更可怕的屎山。

这样 OP 的 300k ，会被精简的少特别多，不管是给未来的自己还是给下一个模型，都远比完全放任式的 agent 自己 loop 闭环要好的多。

而一些我们只要结果的一些暴力任务，给客户的 POC ，确认这个是能做的（背后不管是暴力还是啥，提前听完 ai 汇报，就让他去跑，跑通，能给客户看即可（如果是收费的 POC 源码可能就不能这么草率了，但替自己的技术决策做个忠诚的验证和执行者 绰绰有余））找到庞大的邮件箱的某些相关的主题），在人不在的时候监控某些事情， 调研某些 课题， 这些看结果即可， 有问题自己看祂大致的方向流程，找到需要深入的流程某个环节，然后去纠正来做即可

……

这是一个「飞机要翅膀扇多快才能赶上鸟类」式的问题；而且 AB problem ；而且「放平心态，随遇而安？还是认真负责？」 两个预设分支都没什么建设性。

先说第一个点：LLM 的记忆结构与人类相去甚远，attention 机制让机器能够建立逻辑关联，但这个逻辑关联还不能通过可视材料（我原本想说「文本」）以外的任何方式训练强化 —— 但众所周知人类学会逻辑的途径远比可视材料庞杂得多，而且人的记忆系统记住的不是文本，而是信息本身。attention 解决了知识提取的问题，但并没有解决知识存储的问题。


----

第二个点：你遇到的问题是在一个工程迭代中 LLM 拉出的速度远大于人类理解的速度，但任务排布节奏却以 LLM 的速度为基准，根本不是以任务完成的实际耗时为参考，这与标题的「对抗 agent 」根本不相关。

我在半年前还是坚定的手动 review 派，因为那时候 copilot 是最好的 coding plan ，有最好的 GUI 和 quota （高额免费），可以分层（对话轮次、checkpoint 轮次、文件层次、git 历史层次） review+即时参与修改，非常方便。在工程约束和代码质量上直到今天仍然完爆所有的 YOLO 放养式和 TUI 交互。只不过 copilot 没余粮并且偷懒的人越来越多了，导致 vibe 不看代码的情况越来越严重。 我最近新玩的几个小项目也尝试了完全放养 —— 都是些我不太熟悉的技术栈和框架，更重要的是，都是些不重要的项目。所以解决这个问题的思路是这样的：

- 你是否严苛地要对代码质量负责
- 你是否有清晰的、必须要求 LLM 遵守的架构方向
- 你是否在熟悉或学习成本比较小的技术栈范围内工作

如果是，那么我非常建议扔掉 TUI 坚持只用 Editor 和插件，真正让自己参与写代码。如果否，那么目前击鼓传花坐等 LLM 写爆的大环境下，产出才是成绩，不如同流合污否则身心受损很吃亏。


----

第三个点：放平心态和负责不是互斥的。LLM 是与互联网和云计算同等分量的基础设施革命，并不受个人情感倾向所左右。人们要选择的是对 LLM 的使用方法，遇到阻力要去推动的也是对 LLM 的用法，而不是调整态度。古法编程的每个项目都有一套专门的代码规范文档，在 LLM 时代假如没有 LLM 使用规范和约束文档，那是一种倒退且匪夷所思的。如果仍是人在主导项目，那必定还是以人的能力为边界，这个标准不会改变。有这个认识就不会产生「躺平还是对抗」的迷茫。

楼主 review 上下文这种操作有点奇怪。你不要管他上下文多少，只看输出，你可以控制节奏，分多个步骤，第一步完成检查一下，优化一下，然后继续第二步。不要因为大模型输出速度快，就把自己搞得那么焦虑。

As @chtcrack said "光现实世界的超级高清图像,声音,嗅觉,温度感知" 这些大脑一直在收集的，但是最终激活参数就另说了，上下文都被填满就没办法满足活下去这个最终目标了。
对于 Agent 写出代码的话，可以多尝试画出 mermaid diagram, 然后把 architecture 转换为你更舒服的 DSL (even build your own)