我搭建的 8-Agent iOS 流水线：哪部分真正有效

多 Agent 系统在常见框架中的失败率高达 41-86%。这不是博眼球的论断，而是 MAST 研究的结果——该研究分析了 1642 条真实的多 Agent 执行轨迹，发现 32.3% 的失败来自 Agent 之间的对齐问题，而非模型质量。另一项 2025 年的研究发现，非结构化的 Agent 网络会将错误放大到单 Agent 基线的 17 倍。

所以当我着手构建一个让 Claude Code 完整掌控 iOS 应用全生命周期（从需求文档到合并上线）的流水线时，我是从这些失败数据出发的，而不是从"看看模型能做什么"出发的。

Pragma 是一组 Claude Code 斜杠命令，将 iOS 功能从想法变为生产环境：

人工审批只在两个节点发生：/spec 之后和 /plan 之后。其他所有阶段都作为 Agent 运行。/feature 按任务逐步实现，遵循严格的 TDD（先写一个失败的测试，确认它因为正确的原因失败，实现，再运行完整测试套件，提交）。/gates 在 PR 打开之前验证构建、测试和架构合规性。/review 和 /test 在 PR 上线后运行。

关键点在于：执行检查不信任 Agent 的自我报告

这是我认为大多数"规范驱动"工具做错的地方。规范模式可以生成一个很棒的 plan.md，但仍然可以交付违反规范的代码，因为没有任何独立于产生它的 Agent 之外的东西来重新检查输出。

Pragma 的 /gates 在 PR 打开之前本地运行一组检查。这些检查在 PR 上线后会在 GitHub Actions 中独立重新运行。这不是冗余，而是真正的要点：CI 的执行机制不会被用不同的提示词重新运行 Agent 来绕过。如果 Agent 说"测试通过了"而 CI 说没通过，CI 说了算。

还有一点我之前没预料到它会那么重要：记忆层。.claude/context/invariants.md、decisions.md、feature-log.md 和 rejections.md 在每个会话边界之间持久化。每个 Agent 在行动之前都会读取这些文件。这与一个带着好提示词的全新模型不同，更接近于制度性记忆：什么是不可违反的，什么是已经决定了的，什么已经尝试过并被否决了。

我是在 FinanceTracker 上构建的这个系统，这是一个真实的 SwiftUI + SwiftData 应用，不是玩具仓库。它追踪多个账户的支出，按类别设置月度预算并跟踪进度，计算资产和负债的净资产值，并通过三步流程从 CSV 导入交易（文件选择器、列映射、预览去重），通过日期 + 金额 + 收款人的哈希值来避免在重新上传时重复导入同一笔交易。

Dashboard：在一个视图中展示净资产值、本月支出和预算进度。

Transactions：跨所有账户可搜索，手动录入和 CSV 导入并存。

Budgets：每个类别每月限额，实时进度跟踪。

Accounts：资产和负债在一起，净资产自动计算。

94 个已合并的 PR，每个性功能都有早于其实现的规范和计划，可追溯到第一次提交。每个 PR 在合并前都有已批准的规范、已批准的计划和通过的 CI 运行，这些都可以在实际历史记录中查到，而不是在 README 中声称的。

哪些地方奏效了，哪些地方没有

行为正确性的问题（Agent 的代码是否真的做了正确的事，而不只是通过了我想到去写的检查）仍然是最难的部分。/test 加上 /gates 的覆盖率检查是我针对这个问题的具体尝试，我不认为它被解决了，更像是被约束住了。

层级分离规则（Views 不含业务逻辑、Domain Services 不导入 SwiftData、ViewModels 依赖协议而非具体类型）偶尔会被 Agent 违反，就像被初级工程师违反一样。不同的是 /review 每次都能 catch 到，因为它是一个固定的检查清单，而不是靠感觉判断。

/plugin marketplace add akshaypimprikar/pragma
/plugin install pragma@pragma
/pragma:init MyApp

流水线：github.com/akshaypimprikar/pragma

验证，FinanceTracker：github.com/akshaypimprikar/financetracker-ios

我真的想知道其他人是如何处理同样问题的，尤其是你必须独立重新验证一个 Agent 声称它做了什么的那部分，而不是信任它自己的成功报告。