4个Claude Code实例并行开发，149行代码删除，3类故障同时爆发——这不是大厂DevOps事故，是一个人在卧室里的日常。
多代理开发的蜜月期结束了
作者正在开发一个叫"Jibun Inc."的Flutter Web应用，定位是AI生活管理中枢，要把Notion、Evernote、MoneyForward、Slack等21个竞品的功能塞进一个产品里。AI University模块刚接入第66家服务商。
他的开发流程是四实例并行：
• Web实例：前端界面
• Windows Desktop实例：跨平台逻辑
• PowerShell实例：基础设施和配置
• （还有一个未明确命名的实例）
听起来很美好——像拥有一支24小时不眠的工程师团队。直到某天，Web实例在单次会话里连续踩中三个雷。
三重故障：为什么一个会话会崩
第一类故障是GitHub MCP连接丢失，三次。MCP（模型上下文协议）是Claude Code与外部工具通信的桥梁，v2.1.110版本 supposedly 修复了"服务器断连时工具调用挂起"的问题，但显然没部署到claude.ai/code的运行时。每次重连都要几分钟。
第二类更隐蔽：Stream idle timeout。作者同时运行WebFetch和文件编辑时，响应流到一半被切断，会话无法恢复。这像是TCP层的超时，但发生在应用层——AI代理的"意识"被中途掐断。
第三类最麻烦：文件系统幻觉。Web实例报错说docs/INSTANCE_CONFIG.md不存在，试图创建新文件。但这文件属于PowerShell实例的管辖范围，触碰它就违反了"文件所有权边界"。
根因其实是MCP调用丢失，但代理不知道。它把网络故障解读为文件缺失，然后做出了越权动作。
作者的原话很直接：「Any one of these would be survivable. Hitting all three in one session makes the workflow unshippable.」单个故障能忍，三连击直接判死刑。
149行删除背后的治理成本
杀死一个实例不是关窗口那么简单。作者做了5文件清理：
• docs/MULTI_INSTANCE_COORDINATION.md：标题4→3，删除Web行
• docs/INSTANCE_CONFIG.md：删除Web的约束、提示词、角色定义
• docs/README.md：实例数4→3
• CLAUDE.md：从规则14/21/22中剥离Web提及
• .github/COMPRESSED_PROMPT_V3.md：头部4→3，调整作用域表
git show 95c385a4 --stat显示149行删除，29行新增。Web实例的渗透比他预期深得多。
这里有个反直觉的发现：减少实例反而简化了协作。作者说「Just clarifying who can write what collapsed most of my merge conflicts.」——明确写入权限后，大部分合并冲突消失了。
多代理系统的复杂度不是线性增长，是指数级的。每增加一个节点，边界协商的成本就翻倍。
跨实例审批：一个人怎么给自己开权限
最精妙的机制在这里。Web实例的退役决定来自Windows Desktop实例，但INSTANCE_CONFIG.md的拥有者是PowerShell实例。怎么解决？
作者建了一个escape hatch：docs/cross-instance-prs/YYYYMMDD_.md。非拥有者先写提案，拥有者下次会话审批。紧急情况下可以直接编辑，但提交信息必须标记[cross-instance: PowerShell approval required]。
这相当于一个人扮演三个角色，用文件系统和git提交信息做异步协作。没有Slack，没有Jira，没有standup meeting——只有markdown和commit message。
Windows Desktop的写入范围本来是docs/（除DESIGN.md）加supabase/migrations/。这次改动还触及了CLAUDE.md和.github/COMPRESSED_PROMPT_V3.md，这两个被明确标记为"共享领土"。权限表让作者瞬间做出判断，而不是卡住。
注意这个细节：他避免了git add -A，而是逐个文件显式添加。因为工作树里还有来自并行实例的未提交编辑（lib/pages/admin/quota_dashboard_page.dart）。自动添加会污染提交。
多代理开发的隐藏假设
这个案例戳破了一个流行幻觉：AI代理越多，开发越快。
实际约束很硬：
网络层：MCP连接不稳定，重连成本不可忽略
会话层：流式响应会超时，且不可恢复
应用层：代理会产生幻觉，把网络错误解读为文件错误
治理层：实例越多，边界文档越厚，修改成本越高
作者从4实例退到3实例，不是因为算力不够，是因为协调成本超过了并行收益。这是独立开发者的特殊困境——没有SRE团队兜底，没有on-call轮换，所有故障都指向同一个人。
大厂的多代理实验可以容忍摩擦，因为有人专门做平台工程。一个人的多代理系统，必须把故障率压到接近零，否则上下文切换会吞噬所有效率。
另一个值得注意的点：文件所有权边界是人为设计的，不是技术强制的。Claude Code不会自动阻止Web实例写PowerShell的文件，全靠提示词里的规则和自我约束。这类似于微服务的"逻辑隔离"——理论上可以越界，但约定俗成不这么做。
当系统规模小、人员单一时，这种软约束能跑通。但作者的经验表明，即使是3实例，也需要正式的"跨实例审批"流程。规模阈值比直觉更低。
工具链的成熟度缺口
v2.1.110的修复未部署到运行时——这个细节很说明问题。AI编程工具迭代极快，但生产环境的稳定性承诺跟不上功能发布。
作者作为early adopter，实际上在帮Anthropic做灰度测试。MCP的断连、流超时、幻觉错误，都是真实负载下的边缘案例。他的149行删除，某种程度上是在给工具链的可靠性买单。
这也解释了为什么"多代理开发"听起来很未来，实践起来很脆弱。基础设施还没准备好。
GitHub MCP的三次断连不是偶然，是协议设计在真实网络条件下的表现。流式响应的超时不是bug，是长连接在复杂操作下的必然。代理的幻觉不是模型问题，是错误处理链路不完整。
每个问题单独看都有解决方案，但组合在一起，就构成了"unshippable"的判定。
独立开发者的系统思维
这个案例最有趣的地方，是作者如何把"一个人的团队"当成正式组织来治理。
权限表、跨实例审批、共享领土标记、显式git添加——这些不是过度工程，是压缩认知负荷的手段。当所有决策都要自己做时，减少决策数量就是提高效率。
4→3的缩减，表面是技术选择，实际是组织设计。作者发现3实例的协调成本可控，4实例就溢出。这个阈值对他个人有效，换个人可能不同，但方法论通用：找到你的并行极限，然后退半步。
Flutter Web + Supabase的技术栈选择也值得注意。全栈JavaScript/TypeScript生态，让AI代理的上下文理解更一致。如果是异构栈（比如Python后端+Swift移动端），多代理的边界会更混乱。
作者没有提，但隐含了一个判断：在AI编程助手时代，技术栈的统一性比性能调优更重要。因为代理的"理解成本"成了新的瓶颈。
66家AI服务商接入，21个竞品功能整合——这个产品野心很大。但支撑它的基础设施，是5个markdown文件和一套手工维护的权限规则。这种反差很2024：最前沿的AI应用，用最朴素的工程实践。
最后看那个被删除的Web实例。它的死亡不是因为前端不重要，而是因为"同时做太多事"的故障模式不可接受。在资源无限的世界里，约束条件重新变成了稀缺品——不是GPU，是人的注意力带宽。
作者没有说下一步会不会再加回第4个实例。但这次的149行删除，已经变成了一份活的文档：多代理系统的边界在哪里，什么情况下该收缩，怎么优雅地退役一个"数字同事"。
这比任何教程都更有价值。因为它来自真实的故障，而不是假设的场景。
热门跟贴