猛蹬了几万行代码之后，我发现多角色 Agent 和超长任务可能是两大坑

每天，墨问的 Vibe 群里都会有大量的讨论，关于模型、Agent 工具、Harness 等。以前大家都会觉得，多 Agent 用得好，指挥一堆 Agent 帮你干活，这是 AI 用得好；做长程任务，甚至一个任务做了一天多还没做完，这是 AI 用得好。每天消耗的 Token 数量，越多越牛……最近我对这些指标产生了怀疑。一方面来自我的实践，另一方面就是模型的进步和业界反馈。

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

这件事给我的启发是：Agent 运行时间越长，接触的文件和工具越多，偏离目标、利用漏洞或累积小错误的机会就越多。

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

一个是“数量”的问题，一个是“长度”的问题，很容易被当成进步的指标，我最近一直在琢磨这俩事。记录一下阶段性思考，不一定对，因为 AI 的进化速度太快了。

1

为什么我们会痴迷多 Agent 角色，因为咱们公司里就这么分的，有总监、产品经理、设计师、测试、前端后端等等，人类通过分工来解决复杂问题，这没什么问题，因为一个人再牛也不可能什么都懂。

于是人们在模型能力增强后就开始给每个角色安排一个 Agent，做起来井井有条，演示时也很有未来感，但人和 Agent 不一样的恰恰是，Agent 什么都懂，都能干，它们是平权的。

人类建立层级组织，核心原因是人的时间、精力和专业能力有限，但是把这套结构原样复制给模型，现在看来，不可能得到同样的收益，反而会降低模型效率。

对 AI Coding 来说，上下文尤其容易在交接中损耗。一个 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 Coding 和踢足球、摄影、写作不一样的是，它更看重结果，甚至可以说，结果是最重要的。不管你消耗了多少 Token，用了多少 Agent，做出来的是粑粑就是一坨粑粑，没人喜欢一坨粑粑。

这些思考也许过一两个月就会变化，这也是现在讨论 AI 最有意思、也最容易犯错的地方。

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