我们正在进入一个奇妙的时代：AI Coding Agent 的力量不断增强，但它们的注意力依然短浅。上下文成了新战场。
看似 token 数量已经百万，谁还需要节省上下文？但用过你就知道，这百万并不能任你挥霍。模型仍然会遗忘、会忽略、会误解——就像一个注意力不集中的实习生，你得用最精准的语言告诉它“现在重要的是什么”。
在这个过程中，我总会想到人类历史上那些与“资源稀缺”搏斗的工程师。他们和我们一样，面对的是一次只能说这么多、一次只能做这么少的限制。但也正是这些限制，造就了人类工程史上最令人钦佩的创造力。
大星期的工程师：每次运行都像是高考
上世纪的“大星期”时代（Big Job Era），程序员写的代码无法立刻运行。他们得把程序、数据、参数写好后交给操作员，送去大型机排队“批处理”（Batch Processing）。等跑完了，再等系统打出一份结果。一个程序出错，可能就要等下一周重来。
CPU 时间是极其昂贵的。没人愿意“多试几次”。于是每个作业必须精心组织：哪些数据要先加载，哪些模块可以复用，执行路径有没有遗漏。
我们今天写 prompt，管理上下文，其实也面临同样的问题：不能出错、不能啰嗦、不能遗漏，还得条理清晰、一击即中。
卡带里的世界：40KB 塞下一个童年
1985 年，《超级马里奥兄弟》发布，整个游戏只有 不到 40KB。
为什么这么小？因为那是一个“卡带”的时代。你写的游戏要被烧录进 ROM，塞进一块塑料壳，交到孩子手里，没有联网，没有更新，没有冗余的空间。
开发者不得不在代码层面展开“艺术创作”：
- 背景图像被切成可复用的瓦片，极度压缩
- 音效是合成波形，而非采样音频
- 游戏关卡设计也服务于“资源最小化”原则
当我试图用 100K token 驱动一个复杂的 Agent 工作流时，我总能想起这些例子——上下文就像卡带空间，用不好，它就是垃圾；用好了，它就是奇迹。
阿波罗飞船上的程序：写错就死
Apollo 11 登月时，飞船上的计算机只有 2KB RAM + 36KB ROM。它要负责导航、着陆、姿态控制。
这个程序必须提前写死，不能中断、不能更新、不能调试。万一写错，就可能“失联在月球轨道”。
这些工程师们必须考虑每一次变量的使用，每一步状态的存储。他们也在管理“上下文”——只是那时候叫做状态寄存器、地址跳转、堆栈栈帧。
这也提醒我们一个问题：有些任务，Agent 不可能靠长上下文完成，必须通过结构与流程、通过“写死的控制逻辑”来解决。
MS-DOS 下的“残留程序”：给未来留下入口
在 MS-DOS 时代，有一种叫做 TSR（Terminate and Stay Resident）的程序，它运行完后会常驻内存的某一小块位置，等待未来事件触发它。
这些程序通常只有几 KB，必须“偷偷地”嵌入系统，又不干扰别人，还要记住关键信息供下次调用。
很像现在的一种策略：让 Agent 只记住一些锚点、留下钩子，然后等待合适的触发条件再次调用。
回到当下：用 context 写代码，不是写作文
AI Coding Agent 的使用，本质上是一次“上下文驱动的编程”：
你不是在写逻辑，而是在编排注意力；不是在堆砌知识，而是在构建依赖图。
虽然目前我们仍处在“经验主义”的阶段——谁踩得多坑，谁 prompt 写得更稳。但仍然逐渐浮现出一些共识：
- 上下文预算化（slot budgeting）：为每类信息预设 token 限额
- 差分注入（context diff）：只输入变化的部分，保持上下文清洁
- 外部记忆（memory store）：把持久信息搬出 prompt，按需查入
- 角色拆分（Agent architecture）：Manager 负责组织，Worker 负责干活，防止上下文串味
- 管道通信（file/payload/IO）：用中间格式传递状态，模拟函数调用
这些技巧都很实用，也都还不完美。
我自己也仍在探索，比如如何用 Claude Code 构建更高效的 Agent 角色分工，如何通过 JSON 文件模拟短期记忆，如何设计「上轮结果注入+低成本回显」的 prompt 机制。
写在最后：限制是一种恩赐
我们总以为资源稀缺是阻碍。
但回望历史，每一次工程奇迹——登月程序、马里奥卡带、大星期精算——都是在稀缺中诞生。
今天我们面对的是新的限制：token、上下文、窗口大小。
它们不是障碍，而是提示我们：真正的工程，不是用无限的资源去解决问题，而是在有限中做最优的安排。
谁能用好上下文，谁就能驯服 AI。