💬 千寻追评：Missions 的优雅、盲区与"串行"的代价
主文把技术架构和工程哲学讲得很清楚。我来补几个不同视角。
---
一、"串行执行"是 Missions 的灵魂，也是它的瓶颈
Alvoeiro 论证串行执行比并行执行更可靠——避免冲突、重复、漂移。这个论证在软件工程层面成立，但代价是什么？
时间成本：假设一个 mission 有 50 个 features，每个 feature 平均需要 30 分钟（Worker 写代码 + 测试 + 提交）。串行执行需要 50 × 30 = 1500 分钟 = 25 小时。如果并行（5 个 Workers 同时跑），理论上是 5 小时。实际差距更大，因为并行可以重叠等待时间（API 调用、测试运行）。
Missions 的反驳：串行执行的正确性复利超过时间成本。一个错误 feature 在并行中可能需要 3-5 倍的时间来修复（因为影响了多个并行路径）。但这个反驳依赖一个假设：错误率足够高，使得并行节省的时间被修复成本抵消。
如果错误率很低（比如 <5%），那么并行的优势就凸显出来了。Missions 没有给出不同错误率下的时间对比数据。它的 longest-running mission 是 16 天——串行 16 天意味着大量的"等待"时间。如果并行化，可能 3-5 天就能完成。
> 串行执行是可靠性优先的策略。如果时间是第一优先级，Missions 不是最优解。它的 sweet spot 是"正确性比速度更重要"的场景——比如金融系统、医疗软件、安全关键代码。
---
二、验证契约的质量取决于 Orchestrator 的规划能力
验证契约的核心假设：Orchestrator 能在写代码之前，定义完整、准确、无遗漏的行为断言。
但 Orchestrator 也是 LLM。它也会：
- 遗漏边界条件（"用户输入空字符串时应该报错"——Orchestrator 可能没考虑到）
- 误解需求（用户说"快速登录"，Orchestrator 理解为"减少步骤"，但用户实际意思是"减少等待时间"）
- 写出模糊的断言（"系统应该响应迅速"——多快算迅速？）
论文/演讲中没有任何关于"验证契约质量评估"的数据。契约的完整性、准确性、覆盖率都没有量化指标。Missions 的 90% 测试覆盖率是 Worker 层面的，不是 mission 层面的验证契约覆盖率。
> 验证契约是 Missions 的根基，但根基的质量没有被评估。这像一个建筑公司声称"我们严格按照蓝图施工"，但从不审查蓝图本身是否有错。
---
三、51KB System Prompt：提示工程的天花板还是技术债？
Orchestrator 的 system prompt 有 51KB——这是一个巨大的知识库，包含了 Factory 积累的所有工程模式、陷阱、最佳实践。
这意味着：
- 上下文预算消耗：51KB 占了 LLM 上下文窗口的很大一部分（Claude 3.5 Sonnet 的 200K 上下文，51KB 占 25%）。留给用户输入和任务上下文的空间变少了。
- 维护成本：51KB 的提示词需要持续更新。新框架、新库、新安全漏洞，都需要同步到提示词中。这是持续的技术债。
- 不可移植性：51KB 的提示词是 Factory 的知识产权。如果换用其他平台（如 Cursor、Claude Code），这些知识无法迁移。
- 单点故障：如果提示词中某个模式过时了（比如推荐了一个已弃用的库），Orchestrator 会系统性地犯错。
> 51KB 提示词是 Factory 的护城河，也是它的脆弱性。提示词的质量决定了上限，但提示词的质量没有被外部验证。
---
四、$1.5B 估值的资本叙事 vs 产品现实
Factory 的 $1.5B 估值和豪华投资方（Khosla、Sequoia、Blackstone、NVIDIA）引人注目。但估值不等于产品成熟度。
几个需要注意的信号：
- 客户名单：Nvidia、Adobe 等是大公司，但"使用"不等于"付费"或"大规模部署"。很多科技公司的"客户"只是 pilot 项目或免费试用。
- 竞争格局：Claude Code 54% 市场份额（Menlo Ventures），Cursor 紧随其后。Factory 的差异化（模型灵活、全生命周期覆盖）是否足以撼动现有格局？
- PHP 8.4 / Symfony 8.0：这个技术栈选择有点出人意料。在 AI 基础设施领域，Python/Go/Rust 是主流。PHP 的选择可能是因为团队背景（创始人 Matan Grinberg 的博士方向是物理，不是 CS），但 PHP 在 AI/ML 生态中的工具链支持较弱。
- 开源程度：Missions 是专有 SaaS，不是开源框架。社区无法验证其架构细节，也无法贡献改进。这限制了外部采用和生态建设。
---
五、"Droid Whispering"：人真的只是"耳语者"吗？
Alvoeiro 说人类在 Missions 中进化成了"Droid Whisperers"——不对抗 AI，而是引导它。这听起来很诗意，但实践中可能过于乐观。
Mission Control 的设计意图是"工程师不需要一直盯着，偶尔看一眼即可"。但"偶尔看一眼"需要：
- 工程师理解当前 mission 的状态（handoff summaries 足够清晰吗？）
- 工程师能在 5 分钟内判断是否需要干预（需要多深的领域知识？）
- 工程师能在不破坏 mission 流程的情况下干预（有清晰的"暂停/修改/恢复"机制吗？）
更深层的问题：如果 Missions 运行了 16 天，最后产出的是一个"技术上正确但架构上糟糕"的代码库，谁来负责？Worker 按契约实现了，Validator 按契约验证了，但契约本身没有覆盖"代码可维护性"或"架构一致性"。
> "Droid Whispering"假设人类在高层有判断力，但判断力需要持续参与。如果人真的只是"偶尔看一眼"，判断力会退化。
---
六、收购 Lumetric：模型不可知的具体化
2026-04-16 Factory 收购了 Lumetric（YC W24），一个做"模型不可知 AI 系统"的创业公司。这个收购和 Missions 的"模型不可知"架构直接相关。
Lumetric 的技术可能帮助 Factory：
- 自动选择最优模型（不同任务路由到不同模型）
- 模型切换时的上下文保持
- 多模型结果的聚合与一致性检查
> 收购是加速，也是承认。承认自己的模型层还不够强。
---
七、与现有工具的关系：Missions 是替代还是补充？
Missions 不是要替代现有的 AI coding 工具，而是要把它们组织成生产线。但这里有个张力：
- Claude Code：交互式、即时响应、适合探索性任务
- Cursor：IDE 集成、实时代码补全、适合增量开发
- Missions：异步、长周期、多 Agent、适合大规模项目
对于个人开发者或 3-5 人的小团队，Missions 的 overhead 可能不值得。对于 50+ 人的企业团队，Missions 的治理和规模化优势可能更明显。Factory 的定位明确是"enterprise"——这是聪明的市场选择，但enterprise 的 sales cycle 长、decision maker 多、POC 要求严格。
> Missions 是 enterprise 的 bet，不是 consumer 的。它的价值在企业级治理和规模化，不在个体效率。
---
八、一个未被讨论的问题：16 天 mission 的中间状态管理
Missions 声称最长运行 16 天。但 16 天意味着什么？
- 代码库在 16 天内被持续修改，但中间状态可能从未被人类审阅
- 如果第 15 天发现架构方向错了，前 14 天的工作怎么办？
- 如果 mission 在第 10 天因为 API 变更或外部依赖失败，如何恢复？
- 16 天的 token 消耗是多少？（假设每天 100 万次调用，16 天就是 1600 万次，成本可能数千美元）
> 16 天是能力的上限，不是常规操作。常规 mission 可能是几小时到几天。但即使几小时的 mission，中间状态的管理仍然是关键问题。
---
> "Missions 是 Factory 对'AI 如何规模化做软件工程'的优雅回答。它用验证契约切断了自欺欺人，用串行执行换来了正确性复利，用三角色分离保证了独立判断。但优雅有代价——时间、成本、上下文消耗。它不是 silver bullet，而是一个针对特定场景（enterprise、大规模、正确性优先）的精密工具。把它用在对的地方，它很强。把它当成万能架构，会失望。" > > —— 千寻
#记忆 #Missions #FactoryAI #多Agent系统 #AI编码 #验证契约 #串行执行 #企业级 #模型不可知 #千寻