我们构建了一个包含6个作用域代理、1个协调器和3个反馈循环的软件工厂

我们想看看在连接了代码生成相关部分后，端到端的代理工作流是什么样的。因此，我们使用TypeScript和Mastra构建了一个参考实现。它接收来自GitHub、Sentry、部署事件和手动请求的任务，然后将其通过分类、实现、验证、发布、文档和监控流程。 构建概览： - 6个作用域代理：分类、代码生成、验证、发布、文档和监控 - 1个协调器：在固定工作流不足时路由任务 - 7个类型化工作流：每个阶段一个，加上主SDLC路由器 - 3个反馈循环：开发、生产监控和文档漂移 - 3个工具组：GitHub、Sentry和工厂指标 - 1个共享LibSQL数据库：存储工作流状态、记忆、调度和跟踪 - 15分钟监控间隔：按计划检查生产健康 - 4个验证检查：正确性、安全、测试和性能 这是一个参考架构，所以我们不声称这些数字能带来吞吐量、成本或准确性的提升。 生产错误可以通过系统像这样流动：监控工作流拉取带有堆栈跟踪和事件上下文的Sentry问题。分类将其从P0到P3分级，检查是否重复现有工作，并进行路由。代码生成读取相关文件，编写更改及其测试，然后打开一个PR。验证为正确性、安全、测试和性能返回结构化判定。发布处理版本、变更日志、部署、健康检查和回滚。文档将合并的更改与现有文档进行比较，并在漂移时打开文档PR或新的分类项。完整路径大致如下：Sentry → 监控 → 分类 → 代码生成 → 验证 → 发布 → 文档 每个工作流步骤都有类型化的输入和输出模式。如果代理返回格式错误的数据，工作流会在此边界停止，而不是将错误上下文交给下一个代理。代理还获得不同的工具权限。代码生成可以读取仓库并打开PR，但不需要生产访问权限。验证审查PR，而不必是编写它的代理。监控可以读取生产健康状态并创建事件，但不能发布代码。 适用场景： - 具有良好Sentry上下文的重复性生产bug - GitHub问题和过时PR的分类 - 在已测试代码库中进行的小型、定义明确的更改 - 发布任务，如版本控制、变更日志、健康检查和回滚 - PR合并后的文档漂移 - 可以创建自己的事件工作的定期生产检查 需要人工介入的场景： - 架构决策 - 破坏性更改 - 验证失败 - SEV1事件 - 需要视觉审查的UX敏感前端更改 不适用的场景： - 需求每天都在变化的早期产品 - 没有有用测试套件的代码库 - 需要人工批准每个diff的受监管工作