Subagent Compilation Checker

大型编码任务通常涉及多个独立组件（例如微服务、库）。若让主Agent在上下文范围内处理每个组件的编译与错误检查，会引发以下问题：

• 大幅增加上下文长度：将完整构建日志或字节码纳入prompt并不现实。
• 拖慢推理速度：在上下文内发送完整构建命令并解析冗长输出会消耗过多token。

此外，当Agent的单一“编译-运行”步骤失败时，若缺乏更精细化的方法，将难以定位是哪个子模块引发了错误。

生成专用的「编译子代理」，由它们独立构建并验证每个代码子模块，仅返回以下内容：

1. 错误摘要：文件路径、行号以及错误信息。 2. 二进制产物（如有需要）：引用标识（例如编译后目标文件的路径），而非原始二进制文件。

工作流

• 主代理请求：「编译auth-service模块」。
• 生成CompileSubagent(auth-service)
  • 子代理执行mvn clean install或go build ./auth-service命令。
  • 返回结构化的错误列表或编译产物的存储位置。
• 主代理：将简洁错误报告（例如[{file: "auth_controller.go", line: 85, error: "undefined: UserModel"}]）更新至自身context中。

• 子代理定义：每个子代理是一个轻量级容器或进程，配备适配的运行时环境（例如，Java代码对应JVM，JavaScript对应Node）。
• 在RL循环中的集成：将每次子代理调用视为RL环境中的一次工具调用。
• 错误驱动的奖励机制：若错误列表非空，则分配与错误数量成比例的负奖励（例如，reward = −len(error_list)），以此激励Agent快速修复编译错误。

• 优点：
  • 模块化隔离： 主Agent无需将完整构建日志加载至其context中。
  • 并行构建： 多个Subagent可并行编译不同模块，加快端到端工作流的执行速度。
• 缺点/注意事项：
  • 基础设施开销： 需要具备能够启动和销毁多个构建环境的机制。
  • Subagent同步： 若某一模块依赖另一模块的构建产物，则必须制定协调策略以确保遵循正确的构建顺序。