六个AI代理接力写提案，第一版就翻车了

客户发来一份需求，接下来要有人翻历史记录、查资料、写草稿、审一遍、发出去，还得记着跟进。人、工具、文档之间的这几次交接，往往就是工作卡住的地方。

开发者 saifmodan2006 为 Flip the Switch 黑客松做了 SwitchOps AI，把这些步骤放进同一个工作区：六个专职代理通过 Switch 协作，最后由人来控制发送动作。系统把客户记录、内部知识、提案、审批、任务和工作流追踪合在一起。

六个代理分工明确，由 Google Gemini 提供推理和结构化输出。官方 Switch 服务器在代理之间传递带地址的消息，Mattermost 提供协作空间。应用本身用 Next.js 和 FastAPI 搭建，PostgreSQL 存持久化的业务状态，Redis 支撑后台任务，MinIO 存放上传的知识文件，Mailpit 负责捕获沙箱邮件。

让交接过程看得见

开发者的一条核心要求是：专职代理之间的交接必须真的经过 Switch。代理干完活，就发出一条带地址的交接消息；接收方在预期事件通过 Switch 到达时才开始工作。应用会把回执、工作流状态变化和产出结果都持久化下来。

主链路是这样走的：

• Mattermost 里的客户请求 → Switch → 协调代理
• Switch 交接 → 客户情报代理
• Switch 交接 → 研究专员
• Switch 交接 → 沟通专员
• Switch 交接 → 质量审核员
• 精确版本的人工审批 → Mailpit 沙箱捕获
• Switch 交接 → 排期专员
• Switch 交接 → 协调代理收尾

这样一来，可以查清一个请求在各位专员之间是怎么流动的，而不是只看到一个最终答案。PostgreSQL 仍然是业务事实的来源，Switch 负责传递协作事件。

真正咬人的是集成问题

接上真实服务后，暴露出一些确定性测试没发现的毛病。

线上 Switch 的游标和连接代数超出了 PostgreSQL 32 位整数的范围，相关字段被迁移成 bigint，应用才能存下真实的协议值。代理注册也存在半途失败的风险：注册成功了，后续配置却撞上权限错误，一次性凭证必须能扛过第二次操作的失败。流程改成先保存身份和加密密钥，再尝试后续配置，支持的寻址策略则通过官方 Gateway 所有者接口来配置。另外，被打回修改的提案必须在连接中断和显式重试之后仍保留反馈内容，丢了上下文就等于把原来的错误再犯一遍。

这些都在提醒一件事：可靠的代理工作流，靠的不只是提示词，还有细致的状态管理。

第一版提案暴露了最大的问题

实测用了一个虚构客户 Acme Solutions，内部知识源也刻意做了限制。请求是准备一份非约束性的探索提案，覆盖需求受理、客户背景、归属、人工审核和跟进。定价、交付日期和投资回报率都是未知项，必须留作开放问题。

第一版提案里出现了关于自动化开通的、没有依据的说法。AI 质量审核员没有抓到。这是整场测试最重要的发现。

集成审查要求修改，沟通代理产出了去掉这些说法的第二版，随后又做了一次全新的质量审核。这也说明了为什么 AI 审核员应当辅助人的判断，而不是取代它。

审批在 SwitchOps 里绑定到具体的提案版本和对外发送内容。演示中，开发者明确批准了第二版提案，收件人是虚构地址 acme@example.test，走本地 Mailpit 沙箱。应用随后发送了这份已批准的内容，验证时把捕获的邮件正文与审核过的提案做比对，只对 SMTP 换行符做了归一化处理。Mailpit 里恰好只有一封邮件。

这证明的是沙箱捕获，而不是投递到了真实客户。跟进属于内部动作，没有对外发出日历邀请。

实测跑通了什么

完成的 Acme 工作流记录下了这些结果：

• 六个代理参与
• 10 次真实的 Gemini 模型调用
• 8 次 Switch 交接
• 一份经过修改并被明确批准的提案
• 一封被捕获的沙箱邮件
• 一个跟进任务和一个内部日历事件
• 仪表盘上显示工作流已完成

研究环节使用的是获授权的内部记录和上传的知识源，没有做公开网页浏览。

开发者还停掉官方 Switch 服务器，单独做了一次依赖测试。新请求明显被阻塞，模型调用为零，交接为零，已完成的记录仍然可读。恢复 Switch 后，通过带认证的应用端点恢复了已验证的连接，身份和持久化游标都保住了，六个代理全部重连，Mailpit 里仍然只有一封邮件。

最终检查包括 24 个通过的 Python 测试、一条覆盖持久化记录和移动端导航的浏览器流程，以及一次成功的生产构建。

离生产还差什么

本地沙箱工作流能跑，但投入生产还需要更多工作：更窄的代理归属权限、真实邮件服务商配置、运维加固，以及对生成内容的持续评估。

开发者从这次构建中得到的最大体会是，代理工作流需要看得见的边界：消息是谁发的、哪份来源支撑了某个说法、人批准的是哪个版本、之后实际发生了什么。SwitchOps AI 就是把这些边界变成日常业务工作一部分的一次尝试。