如何让代理运行数小时，以及哪些架构真正对代理友好？#深度探讨 #氛围程序员问题

这主要针对那些无法或不想每10分钟就指导一次代理的氛围程序员。我的两个最大问题是：1. 如何让一个编码代理至少持续工作1小时，理想情况下是8到20小时，而无需不断告诉它继续？2. 对于集成多种现有技术并具有大量实时性流程的本地应用，哪种语言/框架/架构真正对代理友好？ 第一个问题是实际急迫的问题。人们到底是怎么让这些代理持续运行的？除非我写一个脚本监视终端并不断发送：«继续，除非你完全完成；如果完全完成，最后说DONE»，或者除非我在代理周围构建一个服务器钩子/自动化循环，否则它总是会停止。它在我希望它完成的时候不做完。它在计划中途报告。它在没有可评估的有用信息时请求输入。所以我非常实际地询问：现在人们是怎么让代理真正长时间工作的？ 第二个问题关于架构。我想弄清楚哪些架构真正适合AI维护的本地应用，尤其是那些最终可能达到数万行代码并协调多个本地组件/进程的系统。我原本认为事件驱动架构可能适合。我尝试使用NATS风格的通信朝这个方向前进。但我目前的印象是代理并不擅长此道。也许我做错了什么，但一旦所有事情都通过事件进行，感觉代理在系统推理方面变得非常糟糕。如果代理必须通过阅读事件日志、追踪ID并从消息流中重建因果关系来理解系统，这似乎不太匹配。也许这根本就不是对代理友好的方式，至少对于一个单人/氛围编写的本地应用来说不是。所以更深层次的问题是：«什么架构能让AI代理异常擅长维护和扩展项目？»不是理论上优雅的架构。不是高级工程团队最优的架构。而是什么架构对于模型来说最容易推理、测试、调试和扩展？ 我想要的粗略工作流程是：1. 将模型置于超高思考模式。2. 给它一堆杂乱的项目材料：旧规格、笔记、部分仓库、失败的想法、设计思考、待办事项、架构草图等。3. 让它花费大量精力将其组织成可用的知识库。4. 我审查/修正该知识库。5. 然后让它花费大量精力编写实施计划。6. 我审查/修正计划。7. 然后让它在沙箱中长时间执行，而不频繁停止并让我说«继续»。大致是：«1小时知识组织，1小时实施规划，20小时执行»。确切数字不是重点，重点是深度和连续性。我不希望模型花5分钟写计划，10分钟编码，然后报告«完成»。 第一个问题是混乱的上下文。如果我给LLM一堆文件、旧规格、旧想法和之前的尝试，它通常会把所有内容都视为今天写的且同样有效。但其中一半材料可能已经过时、矛盾、废弃、实验性或来自失败的尝试。模型不会神奇地知道每段知识的状态。所以我觉得需要一个明确的中间阶段：不是编码，不是规划，而是知识组织。类似于：\\- 当前需求 \\- 旧需求 \\- 过时的想法 \\- 失败的尝试 \\- 未解决的问题 \\- 架构约束 \\- 实现细节 \\- 仍有用的笔记 \\- 被后续笔记反驳 \\- 需要用户确认。然后我可以在模型开始规划之前修正知识图谱。这似乎比将50个文件扔进上下文并希望模型«理解»要有用得多。有人正在使用真正做好这一点的工具/工作流程吗？ 第二个问题是浅层计划模式。当前许多«计划模式»工作流程感觉很浅显。模型问两三个问题，写一个简短的计划，然后表现得好像已经足够对齐了。但那不是我想要的。我希望模型在编写代码之前真正投入精力思考系统。人们总是说：«5分钟的计划可以节省1小时的工作。»好吧。有人真的用LLM编码代理实现了这一点吗？因为现在很多代理规划感觉只是一种形式。它问几个问题，写一个计划，然后立刻想开始编码。或者它一遍又一遍地重写整个计划，而不是先深入思考再写一个稳定的计划。也许缺失的工作流程不仅仅是«计划模式»。也许是这样的：«规划计划 → 组织知识 → 提出真正的问题 → 编写实施计划 → 执行直到计划实际完成» 第三个问题是过早报告。这大概是我最大的问题。模型写了一个实施计划。我审查了实施计划。然后它开始实施。然后它中途停止并报告。为什么？如果我已审查实施计划，为什么它需要我不断说«继续实施计划»？如果它没有遇到根本性障碍，如果计划没有失效，如果还没有什么真正有用可供我评估的内容，那它为什么要报告？很多完成报告基本上就是把实施计划改成过去时：«我添加了X。我实现了Y。我更新了Z。»这对我没用。对于一个氛围程序员，我不想检查一堆修改过的文件。我不想看计划的过去时总结。我不想看到一个虚假的检查点，仅仅因为代理决定停止而存在。我想要的是以下之一：1. 一个我能实际运行的可用东西。2. 一个清晰的展示层，能给我看到一些具体的东西。3. 如何测试以及查看什么的精确指令。4. 一个真正重要且会改变计划的问题。5. 一个阻碍进展的真正障碍。6. 或者，如果以上都不适用，就继续执行。如果当前工作仍然主要是模拟、脚手架、内部连线或抽象架构，那么可能还没有什么可供评估的有用内容。在这种情况下，为什么要停止？为什么不先完成计划的实施，然后在我真正有东西可评估时再让我测试和评估？谁的时间更宝贵：我的还是代理的？我并不是说代理永远不该停止。它应该在以下情况停止：\\- 计划根本错误 \\- 需要做出重大架构决策 \\- 无法解决的障碍 \\- 它有真实可测试的东西可以展示 \\- 继续下去明显会浪费大量工作。但如果仅仅因为它完成了«一些步骤»就停止，那感觉毫无用处。 第四个问题是让代理真正长时间工作。人们实际上是如何高效地花费他们的token预算的？通过一些订阅和API设置，可能的用量是巨大的。但在实践中，我发现很难好好利用，因为代理不断停止、请求输入或生成没有帮助的报告。你怎么让代理执行一小时、八小时或整夜？你现在真的能以有用的方式做到吗？你使用自动发送继续提示的脚本吗？你使用钩子吗？你在某种监督进程中运行代理吗？你使用已经解决这个问题的特定工具吗？还是答案仅仅是当前的代理在没有外部自动化的情况下还不能真正做到这一点？我已经尝试或研究了OpenCode、OpenClaw、Gemini、Claude、Codex、Pi以及一堆看板式工作流程。我目前的印象是，使用Docker沙箱的OpenCode是比较实用的设置之一。终端UI对我来说比许多GUI代理设置更可靠，而且Docker沙