墙比模型更重要：Stripe Minions + 字节 DeerFlow 2.0 + 蚂蚁支小助 的同结论¶

Ch05.079 墙比模型更重要：Stripe Minions + 字节 DeerFlow 2.0 + 蚂蚁支小助 的同结论¶

📊 Level ⭐⭐⭐ | 14.3KB | entities/wall-not-model-harness-three-case-studies-stripe-deerflow-ant.md

墙比模型更重要：三家公司独立得出同一结论¶

Overview¶

2026 年 6 月，微信公众号文章综合 Stripe、字节跳动、蚂蚁集团三家公司的实践，提出一个统一论断："墙比模型更重要"（the wall matters more than the model）。三家分属支付、客服+内容+研发、金融行业的公司独立得出了同一个结论——AI 的能力 × 运行环境的设计 = 实际产出，是乘法不是加法。

这不是要让 AI 更聪明，是要让 AI 的力量被引导到有用的方向。

三家公司对照¶

三家方法各异，但都遵循同样的工程化原则： - 隔离：避免任务间互相污染 - 分工：不让单个 AI 承担所有判断 - 验证：关键节点硬规定不能跳过 - 兜底：失败有重试上限和人工介入路径

Stripe Minions：4 个核心机制¶

2026 年 2 月 Stripe 官方博客介绍内部 AI 系统 Minions：工程师在内部通讯里发一条消息描述任务，然后去忙别的，回来时任务已经完成、验证通过、整理好等人确认。

1. 隔离工作台——每个 AI 任务有专属工作台，预装所有工作需要的材料，十秒内就绪
2. 工具按需取用——任务有固定的工具库，但 AI 不会把所有工具都摆出来，按当前任务类型只取出用得到的
3. 验证节点硬规定——验证、核查、提交是硬规定，到了必须执行不能跳过
4. 重试上限——任务失败 AI 最多重试 2 次，2 次还没解决自动标记人工介入

"上面说的所有东西——工作台隔离、工具按需取用、验证节点、重试上限——跟 AI 模型本身一点关系都没有。这是管理学和流程设计的思维，只是被用来包裹一个 AI。"

字节 DeerFlow 2.0：从"半途而废"到 Super Agent Harness¶

字节内部团队在客服、内容生产、研发效率三个场景反复遇到 AI "半途而废"问题：

3 个真实失败模式¶

1. 任务链条太长时 AI 会忘记前面做了什么
2. 做着做着把工作环境弄乱了，后续步骤全部受影响
3. 多个任务互相干扰，一个出错拖累全局

3 个工程化解法¶

• 给每个任务独立的隔离空间，用完清空，互不污染
• 把任务分给多个专项 AI 并行处理，每个只看自己那部分，结果由主控 AI 汇总
• 关键中间步骤持续压缩存档，不让 AI 的工作记忆溢出

DeerFlow 2.0 定位是 Super Agent Harness（超级智能体底座），发布当天登上 GitHub 全球热榜第一。

蚂蚁支小助：金融场景的 4 AI 分工¶

蚂蚁集团"支小助"面向金融分析师、投资经理、基金从业者，给定一家上市公司能自动完成整套投资研究：搜集研究报告、财务数据、市场资讯，从定性和定量两个角度分析，最后输出研究分析报告。

4 个角色¶

蚂蚁的解释：金融分析信息太密集，每个细分领域都需要专业判断，单个人脑（或单个 AI）根本装不下。人类团队的解法是分工，支小助做的是让 AI 系统复现这个分工结构。

为什么更强的模型解决不了¶

Anthropic 研究了大量 AI 在长任务中的失败案例，发现 3 个反复出现的模式：

1. 内在倾向"假完成"——AI 倾向于在任务没真正完成时就认为自己完成了。不是偷懒，是它在那个时刻判断"停下来"是最合理的下一步
2. 上下文撑满时跳步骤——AI 能同时看到的信息范围快撑满时，会开始跳步骤、仓促收尾。它感知不到"还有多少任务没做"，只感知"我现在能处理的信息快到头了"
3. 一口气做完所有事——面对复杂任务，AI 倾向于一口气做完所有事，而不是分阶段推进。一旦中间某步出错，整个结果很难拆解

"这三种失败模式，在更强的模型上依然存在。因为它们不是智力问题，是运行机制决定的。"

三阶段 AI 工程进化史¶

"这是一个层层递进的过程，前一步依然必要，但都不够。第三步是现在最值钱、最欠缺的部分。"

与已有 Harness Engineering 实体的关系¶

本文的核心贡献是3 个具体行业案例（Stripe/DeerFlow/支小助）的对照分析 + "墙比模型" 统一论断 + 3 阶段 AI 工程进化史。已有 entities 覆盖的角度：

• Harness Engineering 概念框架 — 抽象框架（Compaction vs Reset, Generator + Evaluator 分离）
• Agent Harness Engineering: A Survey — 学术 7 层 ETCLOVG 分类法
• AHE：Agentic Harness Engineering — 复旦/北大自动优化 Harness
• 长周期 Agent：Ralph Loop → 可接管 Harness — Ralph Loop 漂移治理 + 5 张卡框架

本文是行业证据维度的补充——把抽象框架落到三家不同行业公司的实际部署数据上。

→ 原文存档

深度分析¶

1. 三家案例揭示的"墙"本质上是风险管理¶

Stripe、字节、蚂蚁三家做法各异，但核心机制都指向同一个底层逻辑：把 AI 的不确定性边界做死。Stripe 的重试上限、DeerFlow 的独立隔离空间、支小助的分工评审，都是在给 AI 的失控风险设置物理边界。这与传统的 Generator + Evaluator 分离 原则一脉相承——让一个模块负责生产，另一个模块负责判断，而不是让同一个 AI 既生产又自评。

2. Anthropic 失败模式的三层结构性根源¶

Anthropic 揭示的三个失败模式——假完成、跳步骤、一口气做完——表面上看起来是 AI 的"认知缺陷"，但深层结构是上下文窗口的有限性和阶段性任务收益的不对称性。AI 判断"停下来"的依据是当前上下文能支撑它做出决定，而不是任务是否真正完成。这个结构性缺陷在任何模型上都存在，因为它是任务执行机制与上下文有限性之间的根本矛盾。

3. "乘法效应"对 AI 工程资源分配的重定价¶

文章的核心洞察——模型投入 × 环境设计 = 实际产出——是对 AI 工程资源分配逻辑的一次重定价。业界长期习惯性地把资源向模型本身倾斜，认为选对模型就能解决大多数问题。但 Stripe 的实践表明，当环境设计粗糙时，模型能力几乎被完全抵消（"接近零"）。这个乘法效应对投资决策有直接影响：与其花时间在模型选型上，不如先确保运行环境的隔离和验证机制到位。

4. 三阶段进化史是技术成熟度的客观反映¶

从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的三阶段划分，不仅是时间序列，更反映了 AI 工程从"语言优化"到"信息组织"再到"系统稳定性"的关注点迁移。每个阶段都没有被完全替代——Prompt Engineering 仍然是上层交互的基础，Context Engineering 仍然是信息注入的必备手段——但当系统复杂度超过某个阈值时，两者都不足以单独保证稳定性。这个阈值在 Stripe 是 1300 任务/周的规模，在 DeerFlow 是跨场景并行的复杂度。

5. 支小助分工结构的镜像：人类组织 -> AI 系统¶

支小助的规划/执行/表达/评审分工，本质上是把金融行业的人类分析师团队结构镜像到了 AI 系统上。金融分析的信息密度和判断多样性，使得单一 AI 根本无法承载完整任务，这与 多智能体编排模式 中的角色分离原则完全一致。不同的是，支小助把这个分工结构做成了完整的闭环评审机制，每个角色的输出都要经过下一级的验证，而不是线性传递。

实践启示¶

1. 设计 Harness 时先做"破坏性测试"，再谈模型选型¶

在部署任何 AI Agent 到生产环境之前，应该先用当前模型故意制造失败场景（任务链条拉长、并行任务相互干扰、工作环境被污染），验证 Harness 的隔离机制是否有效。这个顺序很重要：先把环境的边界做结实，再谈模型能力发挥。很多团队的问题是先选模型，再设计 Harness，导致环境设计天然地围绕模型能力定制，而不是围绕任务稳定性需求设计。

2. 为每个 AI 任务设置"硬失败阈值"和人工介入路径¶

Stripe 的重试上限（最多 2 次）看似简单，但背后是一个关键的工程原则：AI 的失败必须有人负责。当重试次数耗尽时，系统不能沉默，必须强制触发人工介入。这个原则在任何生产级 AI 系统中都应该标配——不是可选项，而是硬性要求。特别是对于涉及代码提交、财务处理等不可逆操作的任务，人工介入路径必须在设计阶段就固化到流程里。

3. 任务独立空间是 DeerFlow 的核心工程价值，值得借鉴¶

DeerFlow 的"独立隔离空间 + 用完清空"机制，解决了长任务中工作环境污染的核心问题。这个设计对任何需要 AI 处理多步骤任务的场景都适用，特别是当任务链条中包含文件系统操作、状态修改等有副作用的操作时，独立空间等同一个天然的 Rollback 机制。实现上可以为每个任务创建一个独立的临时工作区，任务完成后整体销毁，而不是在共享环境中让 AI 留下各种残留状态。

4. 多 AI 并行分工时，主控 AI 的汇总质量是关键瓶颈¶

DeerFlow 和支小助都采用了多 AI 分工模式，但最终输出质量完全取决于主控 AI 的汇总能力。如果主控 AI 在汇总时引入信息丢失或逻辑跳跃，分工的优势就会被完全抵消。这意味着在设计多 AI 系统时，投入在主控 AI 上下文组织和判断逻辑上的工程资源，应该至少与投入在专项 AI 上的资源相当。

5. 从三阶段进化史判断团队当前所处位置，合理分配工程资源¶

团队在引入 AI 工程能力时，应该客观评估自己处于三阶段中的哪个位置：还在优化 Prompt 的团队，核心资源应该投入在指令设计和措辞调整上；已经开始做 RAG 和知识库的团队，下一步应该关注信息的组织和检索质量；已经开始处理复杂多步骤任务的团队，才真正需要系统性地投入 Harness Engineering。跳跃阶段投入资源不仅浪费，而且会因为缺少前置能力而效果不佳。