200K（约20万词元）上下文并没有自动解决编码智能体的“失忆”问题：一次鉴权任务中，智能体忘记已有白名单逻辑，反而重写代码。我们注意到，大模型能装下的信息越来越多，但可用上下文仍取决于预算分配。

作者把这归因于系统提示、工具定义、代码片段、构建日志和历史对话共同挤占窗口。这个案例的价值，不在于四条技巧本身，而在于它暴露了智能体从“能写代码”走向“稳定交付”时必须补上的工程能力。

这是什么

上下文管理，是决定智能体每次任务能获得哪些信息、如何组织信息的管理工作。作者提出四条规则：构建日志先裁剪再传入；每个任务开启新会话；把稳定的项目约定写入文件；限制每次检索的文件数量。其目标不是让模型知道得更多，而是减少无效信息，避免关键约束被淹没。

其中，日志裁剪把一次调用的输入从约3万词元降至约400；固定检索范围则让智能体从读取40个文件收缩到3个。上下文窗口（模型单次能够接收的信息容量）再大，也需要像内存调度一样管理输入、缓存与落盘。

行业怎么看

这支持一个明确判断：编码智能体的竞争重点正在从单次代码生成质量，转向任务执行的可控性。上下文管理、工具权限和项目规则，将决定智能体能否进入长期维护流程，而不只是完成演示任务。

但这套方法仍偏个人经验，不能直接等同于企业级方案。限制文件数量可能漏掉关键依赖，新开会话也可能丢失尚未沉淀的决策；日志过滤若过于激进，同样会掩盖关联错误。更现实的风险是，多数团队会把上下文问题误判为模型能力不足，反复换模型却没有改善输入质量。

对普通人的影响

对企业 IT：部署编码智能体时，应同步建设项目规则、日志规范和检索策略，并设置人工复核，避免把未经治理的智能体接入核心代码库。

对个人职场：会使用智能体的人将不只靠“会提问”，还会更擅长拆分任务、沉淀规则和筛选证据；这些能力会逐渐进入软件岗位的协作要求。

对消费市场：面向消费者的智能应用也会遇到同类问题，只是表现从代码遗漏变成漏读条款、忽略偏好，后续产品体验会更依赖后台的上下文治理。