让AI跑几天不如让它想清楚！我如何修复长期智能体的三大致命缺陷
你让智能体跑一个长期任务，比如“帮我做个能月入百万的软件”，最笨的方法就是让它在一个循环里反复跑同一个提示词。这玩意儿有个外号叫“拉尔夫循环”，因为像《辛普森一家》里那个傻小子拉尔夫，只会重复干同一件事。
但这个方法有个巨大问题：智能体每跑一圈就会自己瞎做一堆决定，这些错误会像滚雪球一样越滚越大，最后给你的东西完全不是你要的样子。我试过Codex团队刚推出的官方长期智能体功能，结果特别失望。
后来我自己折腾了几个月，发现真正好用的长期智能体必须做到三件事：先花时间把需求聊清楚、让多个智能体互相检查工作、给智能体一个公共记事本记下所有重要决定。下面我把踩过的坑和最终方案全部分享出来。
循环跑提示词会让错误像雪球一样越滚越大
你让智能体做一个完整的东西，从零开始写代码、搭界面、连数据库，它会在每一步都做出无数个小决定。比如你让它“做个记账软件”，它可能会自己决定用蓝色按钮还是绿色按钮，要不要加个图表，数据存本地还是云端。这些决定你根本没说过，但智能体自己就替你做主了。
问题是智能体没有审美，也没有常识。它选的颜色可能难看死了，设计的数据库结构可能以后根本没法扩展。更惨的是，这个错误决定会影响到后面所有的决定。如果智能体决定用SQLite存数据，但你的软件以后要支持一百万人同时用，那后面写的所有代码都白写了。
这就像你让别人帮你装修房子，你只说“要现代风格的”，结果对方把墙刷成荧光绿，地板铺成紫色，还觉得自己特别有创意。你气得要死，但人家会说“你不是说现代风格吗”。智能体就是那个装修工人，而且它不会跟你反复确认，直接就开干。
我在实验里发现，让一个智能体跑十五分钟，它大概会做几十个决定。其中至少有三到五个是你绝对不会做的。然后这些错误会传染给后面所有的代码。到最后，你得到的软件跟你想要的完全是两码事。
Codex的官方长期智能体功能/goal就是这么干的。它只是简单地在循环里重复一句话：“继续朝着目标工作”。它会记录花了多少秒，用了多少token，还剩多少预算，然后就没了。这就像你让一个实习生去做一个重要项目，不给任何指导，只说你继续干，别停。实习生当然会继续干，但干出来的东西大概率是垃圾。
更搞笑的是，Codex做这个功能是为了解决一个烦人的问题：之前的版本每十五分钟就会停下来问你“我可以继续吗”。这确实挺烦人的，就像你妈每隔十五分钟就问你“作业写完了吗”。但解决这个问题的方法不应该是让智能体闭嘴继续犯错，而是应该让它一开始就想清楚再动手。
所以我自己的方法完全不同。我在让智能体写任何代码之前，会先做一个设立阶段。这个阶段里，我会用我写的一个访谈指令，让智能体问我二十到五十个问题。这些问题特别细，比如“你希望用户怎么登录？要不要支持谷歌账号？”“数据要保存多久？用户能不能删除自己的记录？”“界面要支持手机吗？还是只在电脑上用？”
这些问题会逼着我想清楚很多事情。几乎每次做这个访谈，智能体都会问出我从来没想过的细节。比如有一次我做个论坛软件，智能体问我“要不要防止用户发重复内容？如果发了重复的怎么处理？”我根本没想过这个问题，但这确实很重要。如果不提前说清楚，智能体可能会自己决定删掉重复内容，或者完全不管，两种结果都会让用户很抓狂。
这个设立阶段大概花十到二十分钟，但是能省下后面几个小时甚至一整天的返工时间。就像盖房子之前先画好图纸，而不是一边盖一边改。你提前把每个房间多大、窗户朝哪、电线怎么走都想好了，工人直接照着干就行。如果你不画图纸，工人盖到一半你发现卧室太小了，那得拆了重盖，花的功夫多了十倍。
用一个总指挥带一群小弟干活比单打独斗强太多了
这个道理特别简单。你找一个最聪明的程序员去写一个大项目，他可能会因为太累或者太专注某个细节而犯错。但如果你让他带五个普通程序员，每个人负责一小块，然后互相检查代码，整体质量反而更高。
智能体也是一样。虽然让多个智能体一起跑会烧掉更多的token，但只要你不心疼电费，结果确实更好。这相当于你把原来给一个聪明智能体的token预算，分给好几个普通智能体，让他们一起想问题。
在我的工作流里，会有一个总智能体当指挥官。它不直接写代码，而是负责拆解任务。比如总任务是要做一个登录注册功能，它会拆成三个小任务：写数据库表、做注册界面、做登录逻辑。然后总智能体会为每个小任务临时组建一个小团队，每个团队通常有两个智能体：一个负责写代码，一个负责审查代码。
写代码的智能体先完成任务，然后把代码交给审查智能体。审查智能体是第一次看到这些代码，没有任何偏见，会非常客观地检查。它会找出一堆问题，比如变量命名不规范、缺少错误处理、性能有问题等等。然后两个智能体会来回修改，直到审查智能体满意了，才会报告给总智能体说这个任务完成了。
这个方法的好处是，审查智能体不会像写代码的智能体那样自我欺骗。智能体特别容易骗自己，尤其是当它的上下文窗口塞满了各种信息之后。它会觉得自己写的东西完美无缺，但实际上漏洞百出。而一个全新的审查智能体，带着干净的上下文窗口进来，一眼就能看出问题。
我用过Claude克劳德的设计功能做前端界面，然后用GPT5.5的最高智能模式做后端逻辑和其他所有事情。这两个智能体配合得很好，Claude克劳德做出来的界面漂亮，GPT5.5写出来的逻辑严谨。如果让一个智能体干所有事，它要么界面丑，要么逻辑有bug。
这个方案还有一个进阶玩法：并行处理。你可以用git worktrees这个技术，让多个小团队同时干不同的活，互不干扰。比如一个团队在写登录功能，另一个团队同时在写数据看板，总智能体负责协调，确保两边不会冲突。这样整个项目的完成速度快了好几倍。
给智能体配个公共记事本比让它自己记脑子靠谱多了
你肯定有过这种经历：同时做几件事的时候，脑子不够用，经常忘了之前做过什么决定。智能体更惨，它的上下文窗口每次刷新就可能丢掉之前的信息。就算它记性好，当上下文窗口越来越满，它处理信息的速度和质量都会下降。
解决办法特别简单：给智能体一个共享文件夹，里面放几个文本文件，所有智能体都必须读这些文件，并且随时更新。我用了四个文件，每个文件干一件事。
第一个文件叫目标点MD，里面写的是最高层级的目标。比如“做一个能在二十四小时内处理一百万条数据的分析工具”。这个文件是所有智能体的行动指南，每次开始干活之前都得先看一眼，确保自己没跑偏。
第二个文件叫标准点MD，里面写的是代码质量的硬性要求。比如“函数不能超过五十行”“必须给所有数据库查询写错误处理”“变量名要用英文不能用拼音”。这些要求是绝对不能妥协的，任何智能体写的代码都必须符合这些标准。
第三个文件叫实施点MD，里面写的是工作流程的具体规则。比如“每个任务必须先写测试再写代码”“代码完成后必须让审查智能体检查”“所有智能体必须每十分钟更新一次进度”。这个文件相当于操作手册，告诉智能体们应该怎么协作。
第四个文件叫进度点MD，这是一个不断更新的日志。每次有智能体做了一个重要决定或者完成了一部分工作，就必须追加到这个文件里。比如“数据库设计决定用三个表：用户表、订单表、产品表”“登录界面的颜色选了蓝色，因为老板喜欢蓝色”“API接口的返回值格式定为JSON”。后面进来的新智能体读完这个文件，就立刻知道之前发生了什么，不用重新做决定。
我会要求每个新智能体在开始干活之前，必须先读完这四个文件。这就像新员工入职第一天，你先给他看公司制度手册、项目计划书和之前的工作日志。他看完之后就知道该干什么、不该干什么、之前干到哪了。
当然智能体不一定每次都听话。尤其是当你给它塞了太多信息的时候，它会选择性忽略一些内容。所以这四份文件更像是指导原则而不是绝对规则。但即便这样，它们也确实帮了大忙。至少百分之八十的情况下，智能体会按照文件里的要求去做，这已经比什么都没有强太多了。
举个例子，我之前做一个项目，第一天决定用MongoDB数据库，第二天新来的智能体读完进度点MD知道这个决定，就不会再去选别的数据库。如果没有这个日志文件，新智能体可能会自己决定用PostgreSQL，然后写出来的代码跟之前的完全不兼容，整个项目就废了。
我也试过让智能体自己记这些事情，比如让它把重要决定存在自己的上下文里。但很快发现，当上下文窗口被各种代码片段、错误日志、调试信息塞满之后，智能体就会忘记那些早期的重要决定。而用外部文件的方式，信息永远在文件里，不会因为上下文窗口的变化而丢失。
完整工作流可以直接拿去用
我把上面说的所有方法打包成了一个技能文件，你可以直接把它塞进Claude或者Codex里面用。但我强烈建议你用Codex App里面的GPT5.5最高智能模式来跑这个技能，因为Codex的界面能很清楚地看到子智能体之间的协作过程，特别直观。
这个技能文件会自动帮你做几件事。首先它会运行访谈指令，问你二十到五十个问题来消除所有歧义。然后它会根据你的回答自动生成上面说的四个文件：目标点MD、标准点MD、实施点MD和进度点MD。接着它会启动总智能体，由总智能体拆解任务、组建小团队、分配工作。每个小团队的写代码智能体和审查智能体会自动来回配合直到质量达标。最后它还能用Git工作树让多个小团队并行干活，大大缩短总时间。
我拿这个技能跑了几个项目，效果都很好。比如有一次我要做一个博客系统，从零开始跑了一个晚上，第二天早上起来看，已经有了完整的用户系统、文章发布功能、评论系统和后台管理界面。当然有些细节需要手工调整，但骨架已经非常扎实了。如果我自己从头写这些代码，至少得花一个星期。
这个技能主要适合那些有明确目标、但不需要频繁人工干预的长期项目。比如做个内部工具、原型系统、数据处理管道之类的。如果你要做的是那种需要每天改需求的项目，那还是得人工介入。
长期智能体这个概念确实很疯狂。想想看，以后可能真的能对着电脑说一句“帮我做个能赚钱的软件”，然后智能体就跑几天，回来给你一个能直接上线的完整产品。这听起来像科幻小说，但按照现在模型进步的速度，这一天可能比我们想的要近得多。
我过去几个月一直在折腾这些东西，把学到的经验都发在网上。你要是对我的工作流感兴趣，直接去用那个技能文件就行，反正开源免费的。希望它也能帮你省下一大堆折腾的时间。