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

[richard001]

现行的 Agent 动不动就是 200k~300k ，一次性那么多上下文，根本无法 review ，古法编程时代头脑很清晰，现在头脑越来越模糊了，兄弟们是怎么解决的？当时间、需求相互碰撞时，感觉比以前累了很多倍。放平心态，随遇而安？还是认真负责？

[lm1368]

与其泛泛地说你的感觉, 不如列出具体问题, 大家也能帮你分析.

[xyooyx]

人脑有一套成熟的渐进式加载机制，擅长聚焦

[ATKLLL]

不存在无法 review,只不过越来越懒得 review

[getadoggie]

人脑很厉害的，远非大模型能比的。

[fredweili]

人脑是 rag 机制，还有感觉这种玄学

[chendy]

十多年前的时候少说 10m ，领导一周前开会说了啥都能记住，笔记软件啥的不存在的
现在 128k 都没有，同事上午说的事情下午就忘，只能随时开个 txt 往后 append

[sentinelK]

人脑的上下文缓存很小，但是模型规模很大。而且模型还能自训练。
所以人做事很多时候靠的是模型规模带来的直觉。很少用上下文长度来暴力穷举。

之所以累，就是因为你用 AI 擅长的方式来和 AI 协作。导致你需要同时处理太多上下文。
我理解，要么你就利用你的模型规模，给 AI 明确的技术方向，只让他负责执行，不负责判断。这样减少“你去判断 AI 的判断”这个步骤。

要么就直接撒手，不管任何决策细节，只管效果。

又身居高位又微操，是最忌讳的管理学形态。凯申同志已经无数次证明给我们看了。

[chtcrack]

人脑上下文几 K?光现实世界的超级高清图像,声音,嗅觉,温度感知等都不止几 K..

[molvqingtai]

梁子说，人类比 AI 聪明是因为人类有几十年的上下文

[Cruzz]

虽然人不可能每一行代码都记得，但是人会抽象，代码只是抽象逻辑的表达。根本不是一码事。

[rb6221]

300k 很多吗，我有时候光分析问题，追问好几轮，还没开始改代码就已经 200k 了，正常情况下这种问题还不是要靠人脑老老实实看的，虽不能说毫无压力，但是也属于正常范围

[loryyang]

就是这样，现在最大卡点就是 review 大模型一坨坨的 md 文档，现在只能抓重点稍微看下

[summertimesad]

@chendy 上下文管理机制退化了

[0d]

人脑上下文也不小了, 一个高三学生需要记忆语数外物化生,每科 6 本教材, 每本 20 万字. 36*200k=7.2M 这都还远达不到上限

[hipkomh]

本质上跟看一个大型项目差不多, 拆模块仔细看. 让 ai 生成流程图详细解释. 还有个问题是 ai 造各种奇葩个句子影响理解, 我平常是 claude 写的难看就让 gpt 读完讲一遍会好一点.

[aowugong]

人脑只能把握个总体走向，细节就由 AI 自己发挥吧。人脑啥事都管就第一个炸

[youyouzi]

同耗能相比，人脑子能比 ai 狗脑子都打出来。

[GyroZeppeli13]

人短期记忆不行不代表上下文不多啊。人脑短期记忆不行是 feature ，真要算上下文是很夸张的。例如人类的眼睛分辨率就非常非常高，如果按照这个计算，上下文怕是要用 PB 来衡量了，考虑到人类当中还有些人有超忆症。

[fanghaydn]

人脑是超级思考模式，就是有点慢，容易 timeout

[Rickkkkkkk]

人脑很明显是有好几层不同上下文的。

比如你要干一个活，脑子里是装着好多可调用工具的（但这些并不会在你第一层的注意力里）。但这些工具必须完整告诉 AI 才行的。

[xfl12345]

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

[zhangli2946]

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

[Nexora]

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

[soya2]

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

[Tink]

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

[artiga033]

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

[rming]

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

[zerovoid]

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

[supuwoerc]

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

[HotieCutie]

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

[lianyue]

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

[rocmax]

attention is all you need

[chjqpmain]

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

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

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

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

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

[GeruzoniAnsasu]

……

这是一个「飞机要翅膀扇多快才能赶上鸟类」式的问题；而且 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 使用规范和约束文档，那是一种倒退且匪夷所思的。如果仍是人在主导项目，那必定还是以人的能力为边界，这个标准不会改变。有这个认识就不会产生「躺平还是对抗」的迷茫。

[yidinghe]

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

[techmale]

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