今天我踩了一个非常典型、也非常“AI时代”的坑。
用了一段时间的Qwen 后，趁着 Minimax 2.7以及马上要限额，感觉入手了Minimax 的Coding Plan，把 OpenClaw 的大模型从百炼换成了 Minimax。原本只是一次普通的模型替换，却让我的Agent运行报错-上下文超限。
原来不同模型的上下文长度还不一样。
Qwen支持1000k context，而Minimax、GLM、Kimi 大多只有200k左右。
这段时间一直使用Qwen，我几乎从未认真思考过上下文问题。因为“怎么塞都塞不满”。结果，当模型一换，问题立刻暴露——不是模型变差了，而是我的Agent设计早就失控了，只是之前被超大上下文掩盖了。
我回头打开自己的Agent.md，突然有点哭笑不得。
里面不只是Agent 的人格设定。
还有流程说明、历史案例、调试日志、设计演进记录、临时想法、补丁式规则……几乎所有东西，都被不断追加进去。
原因也很简单：在使用过程中，我不断提出新的要求，而AI 总是很“听话”地帮我把新规则补充进去。
我突然发现，规划和设计Agent，跟规划设计你的软件系统甚至是业务架构没有本质区别，虽然我写的不是代码，但是写的是Agent.md以及各种提示词。
这也让我踩到了传统软件项目的坑，没有真正的架构设计，没有清晰的边界定义，只是不断响应需求：
客户提一个需求→ 加一段逻辑
再提一个→ 再补一段规则
出现问题→ 打补丁
再出问题→ 再叠一层
最终形成的，就是我们熟悉的那个词：
屎山系统。
只不过这一次，代码不再是人写的，而是AI 帮我们“自动堆”出来的。
这件事让我产生了一个很强烈的感受：
很多人以为，进入AI 时代之后，工程能力的重要性会下降，因为“代码可以自动生成”。
但事实可能恰恰相反。
AI消灭的不是工程思想，而只是编码劳动。
设计能力、抽象能力、边界意识，反而变得更重要了。
因为AI 有一个危险的特性：
它不会拒绝你。
它不会说：“这个设计不合理。”它不会提醒：“系统正在变复杂。”它只会持续满足你的新要求。
于是，复杂度以一种前所未有的速度增长。
过去写代码，复杂度增长至少受限于人的体力与时间；现在，复杂度增长只受限于你的想法速度。
我后来重新审视自己的Agent 设计，发现问题的本质其实很简单：
我从一开始就没有真正“设计Agent”，而是在使用过程中让Agent自然生长。
这是一种非常诱人的方式，因为它短期效率极高。
但长期来看，它违背了一个几乎所有工程领域都验证过的原则：
奥卡姆剃刀。
不要增加不必要的实体。不要用更大的结构解决更小的问题。
在大上下文模型下，我们很容易产生一种错觉：
token
很便宜
context
很长
多写一点没关系
但系统复杂度从来不是按token 计费的，而是按认知成本计费的。
当一个Agent 的prompt 长到没人敢读、没人能改、没人理解时，它就已经进入不可维护状态。
无论它运行在多强的模型上。
这次上下文溢出，某种意义上反而是一件好事。
它像一次“强制重构”。
我开始把agent.md 拆开：
人格（Persona）只定义行为风格
流程（Process）独立成模块
案例（Examples）变成可调用知识
日志（Logs）彻底移出上下文
规则（Rules）最小化保留
Agent不再是一个不断膨胀的文档，而更像一个操作系统的内核——小而稳定，其余能力通过外部调用获得。
当结构变小之后，我反而发现：
Agent更稳定了，推理更清晰，成本更低，甚至效果更好。
这让我意识到一件事：
AI时代真正稀缺的，不是生成能力，而是克制能力。
模型会越来越大，token会越来越便宜，上下文会越来越长。
但优雅，从来不是算力的产物。
优雅来自约束。
来自对复杂度的敬畏。
来自在“可以更复杂”的时候，仍然选择简单。
也许未来我们不再亲手写代码，但软件工程的灵魂并不会消失。
架构仍然重要。抽象仍然重要。边界仍然重要。
因为无论系统由人写，还是由AI 生成：
混乱不会自动变成秩序。
而优雅，则是永不过时的品味，也是我们在AI时代能够做的主动选择。
