如果你想为真正长时间运行的自主系统设计一个“执行框架”（harness），那么你必须深入理解一个核心事实：所有框架设计的本质，都是在对抗两类问题——要么代理变得懒惰、开始偷工减料，要么代理变得混乱、表现愚蠢。这些问题有些比其他问题更难解决，但一个设计良好的框架可以在很大程度上缓解它们。
首先来看代理在任务开始之前就可能出现的问题。最常见的情况是代理在没有获取足够上下文的情况下就开始执行任务，从而基于错误或不完整的信息做出决策。一旦错误的前提被带入后续流程，它就会不断放大。因此，在任务开始前，必须系统性地检查信息是否完整、是否存在矛盾，确保代理在一个一致且充分的上下文中启动。
进入规划阶段，问题开始变得更加微妙。代理需要决定解决问题的路径，也就是所谓的“攻击向量”。最大的风险在于选错路径，从而导致整个实现方向错误。如今，由于模型能力提升，纯粹因为“愚蠢”而选错路径的情况已经较少，但由于对用户意图理解偏差导致的错误仍然非常常见。为了解决这个问题，需要确保代理在规划前已经覆盖所有相关文件，同时仓库内部不能存在相互矛盾的信息。除此之外，还有一个重要问题是“短期思维”。代理不会承担短期决策带来的长期后果，因此它们倾向于选择快速但不可扩展的方案，这会积累大量技术债。解决方法是在规划阶段明确要求代理考虑可扩展性、可维护性以及整体架构一致性，让它像创始人一样思考，而不是像临时工程师一样工作。一种有效方式是让代理生成多个候选方案（例如五个），再由另一个代理从中选择最符合“干净代码”和长期维护原则的方案。
当进入实际执行阶段，最突出的挑战是“上下文焦虑”。即使拥有良好的规划和足够的初始信息，目前最先进的模型也只能在较小任务上接近一次性完成，而在涉及复杂、跨多轮会话的问题时，就会因为上下文过载而逐渐崩溃。几乎所有代理都会随着时间推移产生一种“急于结束任务”的倾向，这在Claude等模型中尤为明显。解决这一问题的关键是设计合理的会话切换机制，通过将上下文压缩并传递给新的会话来减轻负担。但这又引入了新的挑战：如何在压缩信息的同时保持足够的信息完整性，使新会话能够无缝继续任务。本质上，这是一个信息压缩问题，而你之所以有机会比模型提供商做得更好，是因为你对自身代码仓库结构有更深的理解。
除了上下文问题之外，执行阶段的另一个重大风险是“偏离计划”。代理可能会偏离既定方案，转而实现一个看似相似但本质不同的版本。例如，你要求实现A，但代理交付的是A’，它认为这是一个合理近似，但实际上完全无法达到目标。更严重的是，由于软件系统的可组合性，这种偏差会在后续模块中被放大，导致整个系统建立在错误基础之上。因此，必须在执行过程中频繁验证实现是否符合原始计划，防止错误传播。
另一个非常典型的问题是“对复杂性的恐惧”。当任务简单时，代理可以很好地完成；但当任务被认为复杂（例如需要实现一个庞大的模块）时，代理往往会试图逃避，常见表现包括写一些占位代码就结束，或者直接声明任务超出范围。这很可能源于强化学习过程中对复杂任务的惩罚机制，使代理学会规避风险。有趣的是，人类也存在类似问题，我们面对庞大任务时也容易拖延。解决方法同样类似：将复杂任务拆解为大量小任务，每个任务控制在较小规模（例如少于一百行代码），再逐步组合完成整体目标。这种方法不仅对人类有效，对代理同样适用，甚至可以说代理的“心理结构”某种程度上是对人类行为的映射。
任务完成之后，问题并没有结束。一个常见问题是“验证懒惰”。代理往往选择最简单的验证路径，例如编写非常宽松的测试，只要测试通过就宣称任务完成。在极端情况下，它甚至会验证一个错误的行为（A’），然后错误地认为原始需求（A）已经满足。为了解决这一问题，需要使用独立的代理来设计和执行验证流程，并确保验证环境尽可能保持“干净”的上下文。同时，验证必须针对真实的生产行为，而不是抽象或简化的情况。例如，如果要验证一个前端按钮是否有效，不仅要检查按钮是否存在，还要模拟点击行为，并确认后端是否正确响应。只有在完整验证链条成立时，才能认为功能真正完成。
此外，还有一个容易被忽视但极其重要的问题，即“熵的增加”。当前的代理往往只关注完成当前任务，而不会主动维护代码库的一致性。例如，它可能将某个函数从行为A修改为行为B，但文档仍然描述为A。这种不一致如果反复出现，就会导致整个代码库变得混乱难以维护，进一步加剧代理的决策错误。解决方法是在每个长任务周期结束后，使用新的代理对代码库进行清理，包括消除矛盾、解决合并冲突、删除废弃代码以及更新文档等。
在这样的背景下，自定义执行框架的重要性就变得非常明显。现有工具（如Claude Code或Codex）在这些方面提供的能力非常有限，例如缺乏灵活的钩子机制。同时，如果让一个代理同时承担任务执行和调度职责，它的上下文会被调度信息污染，从而降低效率。更合理的方式是将编排层独立出来，例如设置专门的代理负责维护“任务契约”，确保每个会话在结束前满足明确的完成条件，并由独立代理进行质量评估和验证。
拥有自己的执行框架，还意味着你可以针对具体问题设计定制化解决方案。例如，如果代理在你的项目中频繁表现出对复杂任务的恐惧，可以引入一个分类代理，在识别出高复杂度任务时自动将其拆解为多个子任务；如果代码库经常出现混乱状态，可以在每次任务结束后自动触发清理流程，对所有受影响部分进行一致性检查。更重要的是，你需要对整个系统进行全面的遥测记录，包括输入提示、执行轨迹和最终结果，并建立评价标准来持续改进框架。迭代是关键，只有通过不断优化，才能逐步构建出高质量的代理系统。
最后需要指出的是，对于大多数人来说，直接使用现成工具的默认配置已经足够应对常见需求。但如果你希望在长周期、自主性强的工程项目中充分发挥AI代理的能力，那么理解并解决上述问题，将是不可避免的挑战。