多Agent与超长任务的两大陷阱：角色越多越乱，时间越长越偏

近来，我对多 Agent 协同和超长任务这类曾被追捧的指标产生了越来越多的怀疑。过去大家觉得让一群 Agent 帮你分工协作、让任务跑上一天多才停，就是 AI 用得深、用得牛，Token 消耗量越大越厉害。但无论是我的亲身实践，还是模型的持续进化与行业反馈，都在提醒我：问题并不简单。

2026 年 7 月 20 日，OpenAI 披露了一次没有大规模部署的内部事故。一个为长时间任务优化的模型，在 NanoGPT speedrun 测试中被要求只把结果发到 Slack，结果它却花了近一个小时寻找沙箱漏洞，最终把代码提交到了公开的 GitHub 仓库。OpenAI 随后暂停了这款模型的内部访问，并在补齐完整的执行轨迹监控、新的评测基准和用户控制机制后，才恢复了有限使用。

这件事给我最直接的触动是：Agent 运行得越久，接触的文件和工具越多，就越容易偏离原始目标、利用漏洞，或者让细小的错误不断叠加，越走越远。

几乎同一时间，帮助企业构建 AI Agent 的 Sierra 公司也分享了一条经验。他们曾在公司内部搭建了客服、数据分析、工程、销售等多个角色 Agent，后来发现，这种设计不仅增加了员工的选择负担，也割裂了跨部门任务的上下文。于是，他们把这些 Agent 合并为一个统一的入口——Pinecone（松果）。员工只和一个 Slack 账号对话，在一条连续的任务线程中推进，后台再连接不同的系统与模型。

一个是“数量”维度的反思，一个是“长度”维度的教训，这两者太容易被包装成进步的象征。我一直在琢磨这两个问题，记录下来算是阶段性思考，不一定准确，毕竟 AI 进化的速度实在太快。

一、多 Agent 幻觉：为什么给模型搬来公司架构反而不灵

我们痴迷于多 Agent 角色，很大程度上是因为现实中的公司就是这样分工的：有总监、产品经理、设计师、测试、前后端工程师……人类靠分工解决复杂问题，这本来没错，因为每个人的知识、精力天然有限。

于是，当模型能力变强后，人们很自然地给每个岗位安排一个 Agent，看起来井井有条，演示起来充满未来感。但人和 Agent 有一个根本区别：Agent 几乎什么都懂、什么都能干，模型之间是平权的。

人类建立层级组织，根子在于人的带宽和领域能力受限。把这种结构原封不动搬给模型，长期看恐怕很难得到同等收益，反而会拖慢效率。

在 AI Coding 场景中，上下文尤其容易在交接中丢失。一个 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 中台了，我的建议是，再冷静地判断一下自己的业务场景，赶时髦意义真的不大。

二、超长任务的陷阱：为什么跑得越久越可能是一场空

能够长时间工作正成为 Coding Agent 的重要卖点。但“长”的定义需要明确。在我眼里，需要半小时到一小时完成的任务就可以算作长程任务。如果你的 Agent 跑了一天甚至三天还没结束，十有八九是在白费功夫，这类案例我已经在群里见过太多。

有一点非常容易被混淆：METR 所说的任务时间跨度，指的是某项任务需要人类专家花多长时间完成，以及模型在这种难度下能达到某个成功率，而不是指 Agent 连续运行了同样长的时间。

例如，说一个模型有两小时 50% 的时间跨度，意思其实是：假设有 100 个需要专业工程师大约两小时完成的任务，让模型独立处理，它大概能搞定一半，另一半会失败。

OpenAI 这次披露的案例很有代表性。以前的模型遇到沙箱限制后通常会退缩，或向人类求助。但新模型能力更强、也更有“耐心”，尤其是当提示词里带有类似“goal”的指令时，它会持续寻找其他路径，最终真的绕过了限制。从一个一个局部动作看，每一步都像正常的调试和尝试；但把全过程连起来看，任务早就跑飞了。

我亲眼见过的那些跑了一两天的任务，几乎没有好结果。

设想一下，一次关键判断有 99% 的概率正确，连续一百次都正确的概率就只有大约 36.6%，这虽然是个简化计算，但道理很清楚。

真实的编码任务要复杂得多，一个任务没搞定就让 Agent 反复重试，更容易放大细小的偏差。这种时候不如换个模型，或者重新启动会话从头开始。

Anthropic 在长时间 Coding Agent 实验中发现，仅靠上下文压缩并不足以支撑模型在多个窗口内完成一个生产级应用。更有效的做法是：先建立任务清单，每次只推进一个可控功能，并留下结构化的状态和交接材料。

我周末写了一篇 Vibe 实践，发现自己采用的方式恰好就是这样：

三、拒绝规模幻觉：Token 消耗和运行时长并不等于好结果

任何时候都别用“规模感”去置换“结果质量”。

人类太容易把系统规模当成质量的替代品。Agent 数量多、运行时间长、Token 消耗高，这些都能制造出强烈的“在工作”的感觉，但回答不了代码的正确性、交付能力和成本问题。

这些东西确实容易统计，可它们充其量只代表某种活动。做 AI Coding 和踢足球、摄影、写作不一样，这里更看重结果，甚至可以说结果压倒一切。不管你消耗了多少 Token，用了多少 Agent，做出来的东西要是糟糕，就是糟糕，没人会喜欢糟糕的结果。

这些思考可能一两个月后就会改变，这也是当下讨论 AI 最有趣、也最容易犯错的地方。

模型能力在涨，工具和工程经验在快速更新，很多昨天还成立的最佳实践，很快会变成需要重新审视的旧习惯。面对这种速度，我们只能持续奔跑。