最近在群里讨论 Sparse Agent，有人问，编程怎么成为一项长期工作？我们平时使用 Claude Code，也就是 CC，或者 Codex，通常会交代一个需求，让它读代码、修改、测试，再看结果。这种方式已经很有效。但如果我交出去的任务是“未来三个月持续改善一个报表服务的线上性能”，工作就会跨过许多次代码交付。
一个版本上线以后，效果可能要到第二天，甚至几天后才能看出来。性能没有改善，需要重新找原因；暂时变好了，还要观察数据量增长以后是否依然有效。过去，这些后续工作往往靠人记着。有人在群里说，人很容易遗忘。这恰好说中了让编程 Sparse 化的价值：把持续观察、判断和改进的职责交给 Agent，让它在需要的时候接着推进。
先把这项工作交代具体。假设我要改善的是每天早上生成的经营报表，就需要说明关注哪条处理链路、采用什么数据规模、从哪里获取耗时和错误信息，以及怎样判断一次修改有效。还需要约定正确性、资源使用和预算要求，明确它可以自行修改和测试哪些内容，发布到线上又需要满足什么条件。这样，Agent 才知道自己要改善的是什么，以及能够采取哪些行动。
三个月是这份职责持续的时间，下一次运行则可能安排在明天，也可能等到新版本完成一个业务周期之后。两者需要分别考虑。写清长期目标以后，还要让 Agent 根据当前进展，决定下一轮什么时候值得开始。
这里就能看出 Dense 与 Sparse 的分工。读代码、定位问题、修改和测试，需要在当前任务中集中推进，我把这种方式称为 Dense。围绕同一个目标，在不同时间开展工作、等待反馈、再继续推进，我把这种方式称为 Sparse。这里的“稀疏”描述执行在时间上的分布，与模型内部的稀疏参数无关。一个 Sparse 目标，可以包含许多轮集中的 Dense 编程。
每轮需要做事时集中执行；等待期间保留目标、进展和下次检查安排。图中的间距不代表真实耗时。
以报表性能为例，第一轮可以先测量现状，定位一个值得处理的问题，完成修改和测试，再按约定推进交付。做完以后，Agent 要留下这一轮改了什么、对应哪个版本、用什么数据验证、结果如何，以及还有哪些问题需要继续观察。后续判断要能接上这些记录。
接下来，工作进入观察期。讨论里有人提到，数据相关的修改经常需要等到第二天才能看到反馈。如果新版本的数据还不够，就安排在合适的时间复查。在结果尚未变化时，无须为了显得忙碌而反复检查同一个结果。如果还有独立且值得推进的工作，也可以在已有授权内先做。
下一次复查时，Agent 需要结合原来的目标、先前的结论和新的运行数据作出判断。假如耗时没有下降，就需要检查原来的判断，重新定位原因；如果耗时下降了，也要确认测量口径一致，结果正确，而且没有引入新的问题。一次测试通过、一次代码交付和整个性能目标达到要求，分别需要判断。
借用群里讨论的假设数字，一项任务从 100 秒缩短到 60 秒，可以说明这一轮有了进展。这只是示例，并非实际测得的成绩。下一步是否继续优化，要看事先约定的目标，以及继续投入的价值。如果还没有达到要求，就选择下一项值得处理的问题；如果已经达到阶段要求，就进入观察、维护或收尾。
这样，一次次代码修改就接成了一项持续的工作：修改之后要看效果，效果又影响下一次修改。一项改进完成后，还要说明哪些问题已经解决，哪些地方需要继续观察。后续工作以实际结果为依据，持续向原来的目标推进。
一轮代码交付之后，继续观察真实效果。效果不足时调整方案，达到阶段要求时可以转入维护、暂停或完成。
让这套工作方式成立，人的交代方式也需要改变。如果今天检查什么、明天要不要再看、上线以后何时复查，仍然由我逐次安排，那么持续跟进的职责还在我身上。让编程 Sparse 化，需要把目标、判断进展的方法和行动范围一起交出去，让 Agent 组织这些已经授权的日常工作。
这也是讨论中 Sparse Agent 的价值所在。周期报告、日志巡检和安全扫描都可以成为它的工作内容，但它还需要根据结果安排后续行动。发现的问题有没有处理，上次修改是否有效，今天是否值得继续，都应该接着考虑。例行报告可以帮助人了解进展；已经授权的工作，也不应因为人没有回复每一份报告就自动中断。遇到超出授权范围的事，再交给人决定。
从使用者的角度，重点是把持续跟进的职责交出去：一次修改完成后，Agent 继续关注实际效果，遇到新的问题时再推进改进。具体项目仍需明确观察哪些指标、怎样判断修改有效，以及哪些发布动作可以自主完成。是否真正改善了性能，要以项目的运行结果来判断。
再回头看 CC、Codex，就比较容易理解我在讨论里的分类。它们常规的编码会话属于 Dense：集中完成当前这一轮任务，可以自主走很多步骤，也可以持续执行相当长时间。把这样的编码能力放进上述流程，它就能承担 Sparse 工作中的定位、修改和验证。
这个分类取决于实际工作方式。Claude Code 已经提供循环和定时执行能力，Codex 的自动化也支持周期性工作和继续已有对话，分别可以看 Claude Code 的调度文档和 Codex 的自动化文档。当一套配置已经能围绕长期目标持续跟进，并根据反馈调整行动时，就应当按它实际承担的职责判断。定时执行是可用的基础，还需要把各次结果接起来，决定继续、等待还是改变方法。
人交代目标、验收方式和授权范围；Agent 安排持续跟进，并在需要时集中完成本轮编码工作。
群里还谈到什么时候停下来。有人提出，资源有限，希望优化一期以后先停，把资源用到别处。这个要求完全合理。长期工作也要有阶段安排，可以在达到要求以后转入低频维护，可以按预算暂停，也可以结束这份职责。停止时保留已完成的工作、未解决的问题和当前状态，以后需要时再接着做。
长期服务仍然有使用成本。安排过密，或者反复研究同一个问题，照样会浪费资源。因此，什么时候工作、什么时候等待、什么时候停止，本身就是这份职责的一部分。每次投入是否带来有用的进展，也需要持续检查。
让编程也 Sparse 化，最终要落实到这样的变化：代码交付以后，Agent 仍然记得为什么做这次修改，会在合适的时候查看结果，再决定下一步。人交代一个持续的目标，Agent 在约定范围内把它分成一轮轮具体工作。我希望交出去的这份职责，从写代码一直延伸到观察效果和继续改进。