多智能体编程助手开发实战：15天单人AI协作全记录
单人15天，用AI打造多智能体编程助手Argus
过去一年，我深度体验了Cursor、OpenCode、Claude Code等主流AI编程工具。它们的能力确实强大，但在高强度日常使用中，一些顽固痛点逐渐暴露，影响了开发效率。
- 虚假完成：AI明确回复“任务已完成”，但实际并未生成文件或执行任何命令。
- 执行中断：任务处理到一半，AI陷入逻辑循环或丢失上下文，需要频繁手动干预才能继续。
- 环境失忆：每次对话都需要重复配置环境路径（如Go安装目录），AI无法形成持久记忆。
- 缺乏上下文感知：工具无法感知开发者的工作状态与时间，交互冰冷且机械化。
反复遭遇这些问题后，我决定构建一个更符合工程实践需求的解决方案。
Argus 的设计哲学：模拟高效工程团队协作
我的背景并非传统软件工程，而是电气与测试领域，长期使用LabVIEW等图形化编程工具。这种经历带来一个核心认知：复杂任务应由专业角色分工协作完成。
因此，Argus摒弃了单一AI代理模式，转而构建了一个由四个智能体角色组成的微型开发团队：
- PM（项目经理）：负责需求分析、任务拆解、工作分配与最终成果审核。
- SE（软件工程师）：执行PM分配的编码任务，具体负责文件创建、代码修改与命令执行。
- AP（独立审批人）：核心质量关卡。在SE完成后，AP独立于PM进行编译与测试验证，拥有对不合格产出的“一票否决权”。
- C（后台监控）：系统守护进程。持续监控PM与SE的运行健康度，自动处理进程卡死，并执行定时Git提交等后台任务。
用户（开发者）
↓ 自然语言指令
PM（项目经理）— 需求理解 → 任务拆解 → 分配至SE
↓ 任务分发与过程管理
SE（软件工程师）— 执行编码 / 文件操作 / 运行命令
↓ 产出提交 → PM初步审核
AP（审批人）— 独立代码审查 + 编译测试（一票否决权）
↑
C（监控者）— 健康检查 / Git自动提交 / 卡死检测（仅报告，不决策）
这一架构将开发流程转化为一个可观测、可追溯、具备自动恢复能力的工程闭环。开发者只需在聊天窗口输入“实现一个用户登录模块”，剩余工作便由这个微型团队自动流转：PM规划，SE实现，AP验证，C在后台确保流程稳定。
15天快速迭代：从零到发布的技术实践
项目开发周期高度紧凑。自5月1日启动，至5月16日发布v0.1.0，目前已更新至v0.1.1。项目累计代码约20万行，AI在生成基础代码框架和辅助调试方面发挥了关键作用。
技术栈选型基于以下考量：
- Go 1.22+：作为后端核心语言，看重其卓越的运行时性能与原生并发支持。
- Wails v2：采用Go结合前端技术构建跨平台桌面应用，最终生成的可执行文件仅约15MB，启动迅速。
- Vue 3 + TypeScript：用于构建前端用户界面，集成聊天区、代码编辑器、终端与文件树组件。
- Monaco Editor：集成与VS Code同源的代码编辑器，保障核心编码体验。
- xterm.js：为应用提供功能完整的终端模拟能力。
项目采用清晰的模块化设计，所有代码已在GitHub开源。
当前版本核心能力（v0.1.1）
功能特性
- 自然语言驱动开发：直接向PM描述需求，由其自动分解任务并驱动SE执行编码与命令。
- 独立多AI审批机制：AP使用独立于PM的模型进行编译与测试，杜绝“虚假完成”，并拥有一票否决权。
- SSE流式响应：AI的思考与生成过程通过流式传输实时显示，无需等待全部完成。
- 任务持久化与恢复：应用意外退出后重启，可自动恢复至上次中断的任务节点。
- 环境配置记忆：如Go路径等开发环境信息，一次配置即可持久化记忆。
- 钉钉集成：支持通过钉钉移动端远程触发开发任务。
- 完整桌面GUI：提供文件树、代码编辑器、集成终端、Git面板，并支持深色主题。
- 四角色协作流水线：完整实现了PM→SE→PM Review→AP Approval的自动化工作流。
- C监控系统：包含30秒健康检查、Git变更感知以及任务超时自动恢复机制。
- 消息去重：前后端双重过滤，确保消息流不会出现重复内容。
技术架构亮点
| 特性 | 说明 |
|---|---|
| 四角色架构 | PM/SE/AP/C角色分明，高度模拟真实软件工程团队的协作与制衡。 |
| AP一票否决 | 审批环节完全独立，确保质量评估的客观性与权威性。 |
| SSE流式推送 | 基于ai-stream-chunk / pm_message / ap_message等多通道的事件驱动模型。 |
| 消息ID追踪 | 每条消息分配全局唯一ID，确保前后端通信的严格顺序与一致性。 |
| 审计日志系统 | 后端自动生成完整的时间线操作日志，便于与前端状态对比排查问题。 |
| 状态机管理 | 明确定义idle（空闲）、running（运行中）、done（完成）、approved（已批准）四个核心状态及其转换逻辑。 |
| 限流熔断保护 | 内置API调用限流与熔断机制，防止过载导致的级联故障。 |
已知局限与未来路线图
当前版本仍处于MVP（最小可行产品）阶段，存在若干待优化项：
- 目前仅支持Windows平台，macOS与Linux版本已在开发计划中。
- 处理复杂多步任务时，偶发死锁情况（正在通过G49-G57多轮修复逻辑解决）。
- 测试覆盖率有待进一步提升。
- 需用户手动配置大模型API密钥。
尽管如此，最核心的工程闭环已能稳定运行。我正使用Argus进行其自身的迭代开发。
v0.2.0版本的核心规划包括：集成Ollama等本地模型、开发VS Code插件、完善自动化测试体系、提供插件开发SDK。
开源共建：邀请社区共同演进
项目已在GitHub完全开源。如果你也曾受困于AI编程工具的不可靠性，欢迎下载试用、提交问题反馈，或直接参与代码贡献。
独自探索，路径终将受限。而与社区同行，则能解锁无限可能。