## AI偷懒，是谁的锅？ [邹老师](https://www.weibo.com/sdxinz)有一个《现代软件工程》课程，其中一个作业是让学生把上课感想和问题写成一篇 blog。一共有53个学生交了作业，他们的文章分散在不同的网站上。如果有一个靠谱的AI可以抓取、理解和概括他们的文章内容，甚至在这个基础上做出更抽象、更高层的分析，可以省掉老师很多时间。 这个问题看起来很简单，因为它是高度独立和可并行的。每个任务又很简单——不就是总结嘛。但其实它比看上去的更难。邹老师一开始试着用了DeepSeek来[做总结](https://www.cnblogs.com/xinz/p/19139660)，但是发现它的结果大都是幻觉。我也测试了各种Agentic AI工具，包括Cursor（Claude 4.5 Sonnet， GPT-5)，ChatGPT，Codex，Deep Research，Manus（非Wide Research），但大家都遇到了一个问题：偷懒。一共53篇文章，能输出10篇以上的就算厉害的AI了（比如Claude 4.5 Sonnet， GPT-5），Deep Research这种经过特化的产品和Codex CLI可以到将近20篇。但即便如此，离53篇的完美数量仍然差得很远。直到我们用了Manus的[Wide Research](https://manus.im/blog/introducing-wide-research)，或者用了我写的[这个repo](https://github.com/grapeot/codex_wide_research/)在Codex里面进行类似的Wide Research，才一下得到了数量完备、信息正确、分析有深度的[结果](https://yage.ai/software-engineering-report.html)。 在这篇文章里我们想解释，为什么这个看起来不需要什么智能的总结任务却这么难？为什么所有AI全都有这个问题？为什么用了Wide Research，一下就让AI又变聪明了，就能处理这种情况了？我们为什么要在Codex上构建这个Wide Research？Codex有什么特殊的？在这个过程中，我们用了怎样的设计原则，做了怎样的技术决策，才在一天内就实现了出来？这里面体现了怎样的AI使用技巧，可以让你以后也能识别出类似的问题，正确的估计它的难度，并且知道用什么方法来处理？ 要回答这些问题，我们首先要理解AI偷懒的原因是什么。偷懒这个词是一个很形象的拟人化描述，但同时它也掩盖了真正的技术本质。这个问题的本质不是AI真的像一个老油条一样想要偷懒，或者说不在于它的意愿。问题的核心在它能力的边界。当AI偷懒的时候，这种能力的边界是由两个相互交织的因素共同决定的：第一个是所有大模型都面临的架构性的约束，第二个是不同模型在执行力上的差异。 ### 架构性约束 LLM或者说AI的一大限制就是当输出长度到了一定程度，比如说占了输出context window最大长度的一半，有时候甚至20%的时候，它instruction following的能力就会开始下降。比如让它翻译一个东西，前面做得还挺认真，到中间就开始跳一句翻一句，到后面干脆就不原样翻译，而是一边做缩略一边做翻译。其中的原因可能是Transformer的全局注意力机制。经验上也确实是一个所有基于Transformer的LLM都有的普遍规律。 这种横跨了所有LLM的普遍约束，就是我们上面这个任务特别难的直接原因。因为这个问题所需要的输出特别长（53篇文章的缩略），LLM在中间输出的时候，前面几个甚至十几个文章还可以按部就班地抓取、解析和总结。但是随着输出规模的增长，它的注意力逐渐就被分散了。具体表现就是撂挑子不干，明明只干了三分之一，它也说我完成任务了。 但仔细想想，这种事情其实是可以避免的。既然问题的根源出在 LLM 被迫进行大规模的输出，我直接规避它不就好了？这也恰恰是 Manus Wide Research 的基本思路：当输入的问题像上面的例子那样，可以自然地分成独立的小问题时，Manus 就会使用多个轻量级的 LLM 来处理每个子问题。比如，使用 53 个 Gemini 2.5 Flash 来对每个独立的学生作业进行总结。因为这些问题规模很小，对智能的要求也不高，因此这些小 LLM 往往也可以把任务完成得相当好，同时速度和经济性都有保证。最后，这些子问题的答案会被汇总到一个地方，由主 LLM 进行润色和最终提交。这样在整个过程中，每个LLM都不会有大规模输出的情况，偷懒的问题也就自然解决了。 ### 执行力差异 与此同时，即使面临着同样大规模的输出，不同LLM在任务完成的质量上也是有差异的。这一方面是开始偷懒的时间不同，比如早期的GPT-4o-mini往往会从几百个字就开始偷懒，而现在的GPT-5和GLM-4.6则可以撑到两三千字。另一方面是，在Agentic AI时代，模型对工具的调用和思维习惯也有很大影响。比如Gemini不喜欢搜索，Codex每次做完事情会习惯性地复盘看一下有没有漏掉什么东西。这就导致就算它俩都从输出四千字的时候开始偷懒，最终完成任务的效果也不一样。另一个例子是Claude 在写代码的时候如果遇到一个测试修不好，它可能就会去把测试本身给删了，甚至直接print一行“完美🎉 测试已经修复！”来蒙混过关。但gpt-5-codex 从来没有发生过这样的情况。这也是为什么在重度使用各家Agentic AI产品之后，我目前停留在了Codex CLI上。 这种横跨所有LLM的架构性约束和不同LLM之间的执行力差异，共同导致Agentic AI产品的使用体验天差地别。我重度依赖Agentic AI工具，尤其是Manus的Wide Research，但在用Manus（似乎是基于Claude）的时候又很想念Codex的靠谱。同时因为Codex是订阅制，用得再多也不额外花钱，所以我就做了[这个repo](https://github.com/grapeot/codex_wide_research/)，在Codex环境下复刻了Manus Wide Research的功能，为Codex这个高执行力的模型，配上一套高可靠性的架构。 虽然这个小项目并没有商业化的Manus好用，但是这里面有很多如何与AI高效协作、如何设计AI原生工作流的思考和实践。我在这里分享出来，也是想回答一个问题：在AI时代，工程师的竞争力应该在哪里？ ## 面向AI构建的实践框架 现在我们有了清晰的理论组合：用Wide Research的架构设计来保证宏观上的可靠性，用Codex作为基础LLM来保证微观执行上的可靠性。但是从理论到实践之间还有一个大坑。并且这个坑不会因为 AI 帮我们写代码就得以解决。 ### 做一个Senior Manager来设计组织流程 具体地说，由于 Codex 本身是一个通用智能体，我们不能也没有必要去改变它内部的代码，所以我们对它的行为的影响主要是通过提示词来进行的。这有点像是你教一个新入职的 intern 应该怎么干活——我们只要给他一本 SOP，让他照着上面做就行了。这给我们的开发带来了极大的便利，因为只要跟 AI 嘴炮就行。但同时也带来了一个问题：和人类一样，AI是一个非确定性（non-deterministic）的系统。一方面，就算我在提示词里让它干什么事，它也未必就会这么干。另一方面，即使是同一个提示词，它多跑几遍，每次出来的结果也不一样。这种情况下我怎么知道我对提示词每次做的更改是有用的呢？会不会像狗熊掰棒子，做了很多改动，最后还是一场空呢？ 这个问题本身倒比较好解决。一般的实践是我们用 5 到 10 个，最好是更多典型的应用场景构建一个测试集合，不断地用我们的提示词来让 AI 完成这些任务。哪个提示词任务完成的质量高、速度快、更稳定，我们就选择它。但这虽然解决了结果的问题，却没有解决过程的问题。你可以发现这是一个非常吃手工（labor intensive）的过程。它需要我们去反复手动微调提示词、让 AI 执行任务、观察结果质量并且重复。这一方面迭代速度慢，一方面人也很累。 已经被 AI 和自动化宠坏的我当然是不愿意做这样的事情的。所以一个很自然的设计决策就出现了——我们把这个过程进一步利用 AI 来自动化。比如说，在它跑完所有任务之后，我们就直接反问它：刚才在你执行任务的过程中，哪些地方是速度和效果的瓶颈？有哪些经验教训你希望记录下来给过去的自己看？这样虽然它不能完全取代人类的洞察，但是很大程度上把体力活代理出去了。 比如在前几轮迭代中，我们发现 AI 完成任务成功率不高的一大原因，是 Codex CLI 最近做了一次大升级，但是AI 还在用老的界面去调用它。这就导致AI花了很久才反应过来：哦，我应该再去看一眼 Codex CLI 的命令行界面。这无谓地占用了大量的 context window，拉低了它的智力和任务成功率。而意识到 Codex 升级了，并且决定在prompt里强调这一点，并不需要特别聪明的 AI，也不需要人类的经验。像这种提示词的迭代，就特别适合 AI 自己来做。 从另一个角度看，我们在这里干的事情更像是在一个公司或者org里去设计组织流程和架构，担当的是一个 Senior Manager 甚至 Director 的角色。我们并没有去跟进一线员工（也就是 AI）的每一个 Work Item，去详细地评估它的质量、给它反馈。相反，我们是设定了一个流程，让它能够有效地自我迭代，通过数据驱动的质量评估和整个数据集上的自我反省，来让 AI 能够自我进步。 这个设计决策极大地节约了我们开发的人力成本，它给开发带来的好处要远远大于我们花更多的时间去跟着 AI 做十个项目并且给它直接反馈。有意思的是，这个工作流本身就是一个 Wide Research。我们把迭代提示词这件事分解成了比如十个独立的问题，每个问题都有一个 Sub-Agent 去执行项目、自我反思，给出提示词的修改意见。这些意见最终被汇总到主 LLM 手上，并且结合我的观察和经验，实际对提示词进行改动。 ### 用实现来加速设计决策 另一个非常关键的技术决策是，我们用来解决每一个子问题的 sub-agent 应该是什么样的形式。Manus 的 Wide Research 用的是代码的形式，它会写一个 Python 脚本去批量调用一个轻量级 LLM。这种形式的优势是显而易见的：它确定性高，透明度高，比如哪些 sub-agent 结束了、每个 sub-agent 内部跑到哪一步了，都能通过代码拿到所有信息。它的控制性更强，因为是自己写代码，所以我们可以完全控制给它什么工具、使用什么流程。同时它的稳定性也很好，因为调用API的时候可以用JSON mode来保证它的输出满足特定的JSON schema。 但是在我们这个具体的应用里，还有另外一个同样诱人的选项，就是我另起一个 Codex 进程，给它一个提示词来描述这个子问题，接下来让它自己忙去。这种方法有个非常独特的好处，就是它不花钱。目前 Codex 可以使用 ChatGPT 的订阅，而且在限额方面 OpenAI 给得非常慷慨。所以如果我们能 fork 很多 Codex 去做 wide research，疯狂白嫖 OpenAI 的话，这是一个非常独特的优势。 但相应的它也有代价：我们没办法深度定制工具也不能控制它的内部机理，而只能通过提示词来调优。与有 JSON Mode的 API 不同，Codex 没有任何保证说输出的结果一定是个 JSON。如果强行使用程序来保证这一点，不可避免又会引入大量的重试。同时，由于 Codex 本身的个性非常尽职尽责，它完成任务往往相比直接调用 API 也更慢。因此这是一个非常复杂且两难的设计问题。 要是在 AI 时代之前，我可能会花上几个小时仔细地做做调研和思考，然后做出决策。毕竟这是一个很重要的决策，一旦做错就可能意味着几个小时甚至几天的时间就浪费了。但是在 AI 时代，这个问题的分析突然变得前所未有的简单：我就让 Codex 把两个方法分别实现了一下，然后在测试集上比较了结果。全程花了 10 分钟 dev time，带等待时间一共一个小时。结果的对比很明显：用 Codex 更好。它可以在控制力、效果和成本上实现更好的平衡。 这是一个特别有意思的转变，它有点像《三体》里面说的探测比打击更昂贵。我有时间在这儿调研、分析、纠结，还不如现场用 AI 直接把它干出来快。而且基于这些第一手经验做出的决策质量也是特别高的，真是有种“大人，时代变了”的感觉。 ## 具体的技术决策 有了这两个设计决策，下面的实现就很简单了。但是我想尤其介绍一下两个更底层的技术决策。 ### 用Tavily进行网络访问 第一是，在进行多轮迭代之后，我发现 AI 反复掉进了一个坑，就是 Codex 对网络的访问摩擦特别大。这是可以理解的，它本身是一个编程工具，网络访问只是为了上网搜个 API、看个网页之类，并不是给你用来做网络调研的。因此，在我真的用它做 wide research 的过程中，Codex 大部分的时间都在和它的搜索工具搏斗。要不然搜出来的网页是 404，要不然当它访问网页的时候被 anti-bot 给 ban 了，要不然发现有 paywall，又得从头搜。这导致它迭代的初期，一个任务需要 40 到 60 分钟才能做完。 这个问题光靠 AI 自己是迭代不出来的。所以我给了它一个手工的建议，就是引入了一个网络操作层，让它做任何搜索和网页抓取的时候都不要使用自带的工具，而是通过 Tavily 进行。[Tavily](https://tavily.com/) 是为 LLM 设计的搜索和网页内容提取工具，它稳定、高效，能直接返回 Markdown。而且 Tavily 本身提供 remote MCP server，因此它和 Codex 的集成特别简单。当然 MCP 直接把 API key 明文放在URL，配置文件和命令行输出里的行为也是让我腹诽不已，但好歹是能用的。经过这个改造以后，调研类任务执行的速度一下提升了两三倍。 ### Multi-Agent的陷阱 我做的第二个角色更像是一个开放性的探索。在Wide Research这种设定下，它是一个典型的多智能体（Multi-Agent）的场景。一提到多智能体，大多数人的第一反应就是：我要有个PM Agent，有个Designer Agent，有个Engineer Agent。但是我觉得这种Multi-Agent的设定是不合理的，只是人类社会生硬的照搬，而并没有去思考里面的原因。 我们人类为什么需要有这种职业分化，主要是因为我们太弱鸡了。一个人没办法在短短的十几年的教育里又选择PM的职业路径，又选择Engineer的职业路径。所以我们只能在多个职业路径中选择一个专心发展。这也许是为什么我们看各个流行的Multi-Agent的实现的话，会发现它经常上来就说”你是一个资深的软件工程师”。因为从人类的角度来说，这是一句好话啊。资深工程师，厉害！ 但问题在于LLM本身就拥有所有职业路径的专业技能。他其实啥都懂，结果你现在让它只当一个工程师。因此这种Prompt反而是一种限制性的Prompt。它非但没有提升LLM的能力，反而是对它能力的削弱，把一个全能全知的LLM拉低到了和只能戴一顶帽子的弱鸡人类的水平。因此我觉得我们不应该为了模仿人类社会而用角色分割这种方式来利用Multi-Agent。相反，我们应该从Wide Research的底层逻辑出发，用Context Window的隔离来看待Multi-Agent。 在我们的场景里，我们不会给每个Sub-Agent说你是一个某某话题的调研专家，而只是通过单纯地把不同的调研子问题分给不同的Codex进程来保证它们之间不相互干扰。通信只发生在主Codex和子Codex之间，通过文件进行。当然，这种方式也不完美，因为在Sub-Agent处理任务的整个过程中，主Agent得不到任何进度汇报。这可能是Multi-Agent设计的一个重要挑战：如何摸索上下文隔离的度，来让每个子任务又不会被过多细节拖累质量，主任务又有足够的高层认知和进度汇报。 ## 结语 回到最初的问题：AI偷懒，是谁的锅？这个项目给出的答案是：这是架构的锅，也是我们与AI协作方式的锅。我们的解法也因此对症下药：通过Wide Research的分治策略解决架构性约束，选择Codex这个高执行力模型作为执行单元，并围绕它建立了一套AI原生的开发与决策流程，构建了一个不偷懒、适合做长时间大项目的Agent。 在开发的过程中，我们发现就算有AI编程的帮助，想要迅速向前推进迭代也是一件很难的事情。因此，我们并没有盲目地在战术上卷勤奋，而是先设计了一套AI自我反思、自我迭代的工作流程。在这个基础上，四两拨千斤，发现了网络访问的重大瓶颈，并且通过引入Tavily解决了这个问题。 与此同时，另一个重要的高层技术决策是我们的Sub-Agent到底应该用Python程序的形式，还是用Codex进程的形式。这个问题我们并没有遵循传统的调研和分析为主的决策流程，而是直接花了十分钟Dev Time把两个方向都做了出来，用直观的比较做出了高质量的决策。 我们的所有提示词也已经开源，可以在[这个Repo](https://github.com/grapeot/codex_wide_research/)访问。大家也不妨打开自己的Codex，跟着教程配置好Tavily MCP（它有免费的plan），然后复制Readme里的示例提示词体验一下Wide Research的威力。