时至今日，LLM 的发展仍然深受 Scaling Laws 的影响，OpenAI、Anthropic 每隔一段时间都会发布更强大模型，AI 取代人类的声音越来越多，难道 LLM 会一直这样发展下去？人类应该处在何种地位？这些问题在今天变得尤为重要，LLM 的特殊之处在于它已经逐渐具备了复杂系统的特性，智慧从复杂中涌现，人类无法准确的预测它的上限。
一个具备人类智慧的 AI 天然带着迷人的魅力，我们可以畅想这如何改变人类的生活、推动社会的进步，谁不想拥有一个有正子脑的机器人或者 HAL 呢？
虽然我认为 LLM 已经在某些方面超越了人类并且短时间内仍会继续进化，但我同样也认为在很多方面人类都能保持绝对的优势，甚至按照目前 LLM 的架构可能永远也无法超越人类。
LLM 的基本运行原理
目前 LLM 的运行仍然是无状态的，它不会记住任何关于用户的信息，每次对话对它来说都是一个全新的开始，现有产品关于记忆方面的功能也都是工程上的优化。
比如跟 ChatGPT 聊天时虽然它能回忆起用户之前的对话内容以及用户的一些信息，但这不意味着模型记住了你，只是 ChatGPT 在将你的对话发给模型之前会检索跟本轮对话相关的内容，然后整理出一份最终的 prompt 交给模型。
或者在跟 CC/Codex 对话时，即使是在同一个 Thread 内对话，用户发送的每一条消息也仍然是独立的，只不过 Codex 会将这个 Thread 内的历史对话和本轮对话一起整理成一个最终的 prompt 交给模型。
当然模型很多时候自行检索互联网内容或者本地文件，但这也都是模型利用 tool call 来丰富最终的 prompt 从而提高回答的准确率。
模型是没有记忆的，每轮对话都是独立的，所以 Context Window（上下文窗口）就变得尤为重要。
Context Window/Stateless
实际上今天我们看到的许多 LLM 工程实践都是在弥补 context-window limitations 以及模型无状态（Stateless）的缺陷，比如 Memory、RAG、Context Engineering 等等。
Context Window 是指 LLM 单次输入可接受的最大 Token 数量，不同模型的 Context Window 都有所不同，token 计数方式也有区别，一般来说一个英文单词约等于 1.5 个 Token，一个汉字是一个 Token。GPT5.6 的 Context Window 现在长到了 353k tokens。
LLM 的 Stateless（无状态）是指模型本身是一个无状态系统，输入的 prompt 不会改变其内部状态，有点像纯函数，但模型也具备一些复杂系统的特征，简而言之就是模型并没有任何关于用户或者历史对话的信息，每次输入都是一个全新的开始。
使用 LoRA 提高领域知识
LoRA（Low-Rank Adaptation）是一种参数微调技术，可以在不重新训练原有模型的基础上使其附加一些特定领域的知识、能力或者行为模式，本质上是新增了少量的参数，从而改变模型的行为。
理论上我们可以将代码仓库、知识文档、需求文档、业务文档等内容整理成训练数据并训练一个 LoRA 然后再交给模型，使模型具备项目的一些基本知识，从而更好的帮助我们解决问题。
不过实际情况是目前主流的模型提供商（比如OpenAI、Anthropic）都不支持 LoRA，未来会不会支持也很难说，目前这些并不是他们的重心。一些开源模型一般是支持的，但是需要自己部署，有一定的使用成本，而且开源模型的性能目前还达不到顶尖水准。
另外训练 LoRA 也是需要成本的，而且有点麻烦的是业务和代码是一直在变化的，所以 LoRA 需要持续更新和训练，LoRA 和模型也是强绑定的，这意味着换了模型就要重新训练新的 LoRA。
如果未来模型能力达到了天花板，开源模型的水平也追了上来，自部署模型很可能会成为很多公司的选择，而那个时候使用 LoRA 技术来解决上下文限制和模型无状态问题或许是个不错的办法。
复杂任务仍需更长的上下文
在很多商业公司中，软件的代码质量和开发效率都持续处在漫长的拉锯战中，业务的快速迭代是主要目标，代码质量的价值要如何体现？
Uncle Bob 在整洁架构中说过代码质量的核心价值是降低未来的维护成本，这也是行业共识，但"未来的维护成本"难以被量化，放在 OKR 中也不够亮眼。
有意思的是，前段时间有篇论文将代码质量是否会影响 Coding Agents 作为课题进行了深入研究。得出的结果和人类几乎一致：无论代码质量如何，Agents 都可以准确的完成工作，但对于代码质量较差的仓库消耗的 Token 显著增加。因此降低维护成本这件事情即使放到 Agents 上也是完全成立的。
现在我们可以光明正大的说，重构是为了省钱了。
言归正传，一个大型代码仓库都包含着复杂的业务逻辑，代码之间有着千丝万缕的联系，历史抉择和未来规划隐藏在代码的细节和人类的大脑之中，所以对于代码仓库中的每个决策都应该尽可能慎重。
我在使用 Agents 做复杂任务时经常会遇到撑爆上下文的情况，很多情况下要解决任务A时发现需要先解决任务B，然后 Agents 就会像个 ADHD 一样开始忘记初心，然后随着上下文压缩彻底失控，即使用了 sub-agents 也不能解决所有的问题。因此我现在几乎只会在边界清晰的特定任务上使用 Agents。
这也意味着软件开发还是要人类参与的，人类要做的就是解决这些复杂性以及做出正确的选择。
正确的选择不仅包括历史问题，也包括未来规划，历史问题往往不会出现在文档中，可能表现只是一段奇怪的代码。未来的规划就更加虚无缥缈了，可能会有一些 roadmap，也可能只有产品经理才知道。
人类与 AI 协同工作
我目前写代码其实主要还是手工编程比较多，Agents 给我打辅助。
很多时候有个悖论是，如果我希望 Agents 完全按照要求实现某个逻辑，那么我就需要输入包含了全部逻辑的 prompt，那么这个 prompt 就会巨长，并且自然语言的信息密度低于代码，那我不如直接写代码。
但有一些情况我很喜欢用 Agents，比如具备固定模式的任务、复杂但目标清晰的函数、独立的小模块或者组件、完全不在乎质量的一次性代码、我不擅长的任务、简单的脚本等等。总的来说，这些都是不需要很多上下文的任务。
架构设计包含很多方面，不管是一个简单的页面还是一个业务模块都值得仔细斟酌，不同的业务、历史、现状、工期、规划都会对决策有所影响，想要让 Agents 搞清楚这些还是没这么容易的，反而是人类来做比较好。不过在设计阶段我也可能会和 GPT 聊天，主要目的还是查漏补缺，或者找出更好的方案。
另外对于客户端开发来说，UI/UX 的验证要复杂一点，目前还没有合适的工具帮助 Agents 验证效果，比如一些动画效果需要分析连续帧，也就意味着需要分析视频，如果要追求细节的话 Agents 就有点力不从心了。
人类的上下文管理还有一个优势是人类大脑具备时间参数，软件的演化过程本身也是很重要的信息，而 Agents 更像是从某个时间切片开始工作。而且大脑会持续内化所有的信息，但 LLM 在这方面是静态的。
ADR 文档
ADR(Architecture Decision Record) 文档是指架构决策记录，用于记录某个架构或设计的决策原因和背景。
ADR 文档并不是为了 Agents 开发而出现的技术，但它可以很好的解决上面说的问题。如果能建立起一个完善的 ADR 文档系统确实能很好的帮助 Agents 开发出优质代码。
目前关于 ADR 文档并没有一个统一的标准，有些仓库会选择把所有的决策都放在一个 decisions.md 文件内，但我之前看过一篇博客的 ADR 实践感觉也挺不错。
我觉得 ADR 文档确实可以解决很多决策类问题，但是给一个老项目建设 ADR 系统也是很麻烦的，如果设计得当确实能让 Agents 工作的更出色。
现在 GPT 有着出色的上下文压缩能力，Claude Code 有着 1M 的上下文，未来可能仍然会继续增加，但我觉得这仍然不能解决根本问题。
但随着 Context Window 的堆积，真正与当前任务相关的信息占比会越来越低，干扰噪音越来越多，这些因素会导致 LLM 的推理更加困难。Transformer 的 self-attention 机制使 token 之间可以建立全局关联，但随着 Context Window 增大，需要处理的 Token 关系数量快速增长，在更大的 Attention 空间中定位与任务相关的信息会变得更加困难。
所以这是个机制问题，短时间内很难有什么有效的解决办法，而这个问题也是我们作为人类的优势，我们可以充分利用人类大脑的超长上下文和 LLM 的超绝推理一起完成更加出色的任务。