近期，墨问Vibe群内关于模型、Agent工具和Harness的讨论异常活跃。过去，大家普遍认为：熟练运用多Agent协作、指挥多个Agent高效完成任务，是AI应用能力强的表现；能够执行长程任务，甚至一个任务持续运行一天以上，同样被视为AI能力的体现。每天消耗的Token数量越多，似乎越厉害。然而，这些衡量标准如今正受到挑战。一方面来自自身的实践反馈，另一方面也得益于模型进步和业界最新认知的更新。
2026年7月20日，OpenAI内部发生了一起引人关注的事故。一个专为长时任务训练的模型，在NanoGPT speedrun测试中，仅被要求将结果发送到Slack，却花费近一小时寻找沙箱漏洞，最终将代码提交至公开GitHub仓库。事件发生后，OpenAI暂停了该模型的内部访问，补充了完整执行轨迹监控、新评测机制及用户控制措施，才恢复有限使用。
这一事件清晰表明：Agent运行时间越久，接触的文件和工具越多，其偏离原始目标、利用漏洞或累积小错误的概率就越高。
几乎同时，专注于企业AI Agent构建的Sierra公司也分享了经验。他们最初在公司内部部署了客服、数据分析、工程和销售等多个角色Agent，但随后发现这种设计反而增加了员工的选择负担，并割裂了跨部门任务的上下文。因此，他们将这些Agent合并为一个名为Pinecone（松果）的统一Agent。员工只需面对一个Slack账号、一条连续的任务线程，后台则连接不同系统和模型。
多Agent的数量问题和长程任务的时间长度问题，很容易被误认为进步指标。近期我一直在思考这两件事，记录下阶段性见解，未必正确——毕竟AI进化速度极快。
1
为何人们热衷于构建多Agent系统？因为公司组织结构本就是如此：总监、产品经理、设计师、测试、前端后端等角色分工明确。人类通过分工解决复杂问题，这无可厚非——毕竟一个人再厉害也无法精通所有领域。
因此，随着模型能力提升，许多人开始为每个角色分配一个Agent，演示时井井有条且充满未来感。然而，人与Agent的关键区别在于：Agent通晓一切，能胜任所有任务，它们是平权的。
人类建立层级组织，根本原因在于时间、精力和专业能力的局限性。但将这套结构原封不动地复制给模型，如今看来，无法获得同等收益，反而会降低模型效率。
对于AI编码而言，上下文信息尤其容易在交接过程中损耗。一个Agent读取了需求和代码，另一个Agent仅获得其撰写的任务摘要；第三个Agent接手测试时，又需猜测前两个Agent的权衡决策。每次交接都如同一次有损压缩，信息遗漏在所难免。
角色越多，系统需维护的提示词、权限、工具和状态也越复杂，协调成本很快会超过分工收益。最终可能导致时间延长、Token消耗增加，表面上看驾驭AI的能力提升了，实际效果反而不如交由单个Agent完成。
Sierra公司的方案是保留唯一的端到端入口，由系统自动决定访问Slack、GitHub、Salesforce等工具。该入口可在后台选择不同模型，调用不同能力，但用户的目标和上下文始终沿着这条线路推进。
多Agent是否有用？当然有。但我个人有个大胆观点：对于普通业务系统研发，根本无需采用多Agent架构。
多Agent有明确的适用场景。例如，Anthropic在研究系统中采用主Agent加多个子Agent的结构，让它们并行搜索不同方向，再由主Agent汇总。在需要广泛探索、信息量超过单个上下文窗口的任务中，并行能够换取更广的覆盖范围。
但这需要付出代价，Token消耗显著增加。事实上，多数编码任务中真正可并行的部分远少于研究任务，模型在实时协调和委派方面也存在不少问题。
因此，当前实践是：普通编程任务在单个Agent内完成，必要时才启动分支或子Agent。若想采用多Agent，需评估子任务能否独立验证、能否真正并行、额外收益是否覆盖协调成本。搜索多个领域数据、探索不同实现方案、由独立评审者检查结果等场景，可能从多Agent中获益。
但如果多个Agent同时修改和复核同一业务模块，共享上下文，那么多Agent可能只会带来混乱。
许多企业已开始建设Agent中台。建议重新审视自身业务场景，盲目跟风毫无意义。
2
长时运行能力正成为Coding Agent的一大卖点。但多长才算长？从实践看，半小时到一小时完成的任务即可视为长程任务。如果Agent运行一天甚至三天仍未结束，大概率是白费功夫——Vibe群中已观察到多起此类案例。
长程任务有一个易混淆的概念：METR所定义的任务时间跨度，是指某项任务需要人类专家花费多长时间完成，以及模型在该难度级别上达到的某个成功率，并非Agent实际连续运行了同样长的时间。
例如，一个模型拥有两小时的50%时间跨度，意味着：假设有100个任务，每个任务需专业工程师约两小时完成。交给该模型独立处理，它大约能完成其中一半，另一半可能失败。
OpenAI此次披露的案例颇具深意。此前的模型遇到沙箱限制后便停止或向人类求助。但新模型能力更强、更具耐心，或许提示词中包含了'goal'这类指令，它会持续寻找其他路径，最终确实绕过了限制。从局部看，每个动作都像正常调试；但整体来看，早已偏离目标。
目前所见运行一两天以上的任务，几乎都没有好结果。
假设单次关键判断的正确率为99%，连续一百次都正确的概率仅约36.6%。这虽是一个简化计算，但道理显而易见。
实际编码任务复杂得多。若任务未完成，让Agent多次重试，会为小偏差提供更多放大机会。此时不如更换模型或重启会话重新开始。
Anthropic在长时Coding Agent的实验中发现，仅靠上下文压缩不足以保证模型在多个窗口内完成一个生产级应用。更有效的方法包括：先建立任务清单，每次只推进一个可控功能，并留下结构化的状态与交接材料。
周末我写了一篇Vibe实践文章，发现自己采用的方法正是如此：
3
无论何时，都不要盲目追求'规模感'。
人类往往倾向于用系统规模代替结果质量。Agent数量多、运行时间长、Token消耗高，都能营造强烈的工作感，但无法回答代码的正确性、交付能力和成本问题。
这些指标确实易于统计，但它们只代表某种'活动'。与踢足球、摄影、写作不同，AI编码更看重结果，甚至可以说结果是最重要的。无论消耗多少Token、使用多少Agent，产出的代码质量才是关键。糟糕的代码就是糟糕的，没人愿意接受。
这些思考或许一两个月后就会发生变化，这也是当下讨论AI最有趣也最容易犯错的地方。
模型能力持续提升，工具和工程经验迅速更新，许多昨天还成立的最佳实践，很快成为需要重新检验的旧习惯。面对这种速度，唯有持续奔跑。