受控的 AI 辅助开发：独立评审，由人做决定
- 任务
- 聊天式 AI 助手写代码很快，但没有项目记忆、没有独立评审、也没有审计记录；需要一个可以放心用于生产系统的流程。
- 我做了什么
- 我搭建了自己的平台：智能体负责规划和编写代码，另一个评审模型为结果打分，变更只能通过我批准的合并请求进入主分支，对生产服务器的操作需要我确认。
- 之后
- 这是我日常的工作环境，用于实际项目。
AI 智能体平台：智能体负责规划、编码和评审——合并与生产操作由人审批
一个自托管平台：AI 智能体把任务变成经过评审的 Pull Request。独立评审模型（LLM 评审）把关质量，私有 RAG 为智能体提供项目记忆，生产操作须经人工审批。
~40项服务运行于一台服务器（规模背景）
27B本地模型，单 GPU，A/B 后约 80 token/s
PR only变更只能经带评审分数的 Pull Request 进入主分支；生产操作须经审批卡片
背景与规模
自 2025 年起是我承接客户和自研项目的日常工作环境。运行在一台配备 RTX 3090 Ti 的家用服务器上，并结合云端模型。
问题
基于聊天的 AI 编程速度快但不可靠：项目之间没有记忆、没有独立评审、没有审计记录，而且敏感代码会被发送到云端。
分析与方案选择
纯云端智能体（搭建快，但代码和数据离开边界）与纯本地模型（私密，但难题能力较弱）。最终选择混合：日常任务用本地模型，配置和难题用云端模型。
架构
用户
负责人 / 评审人
系统
控制台与核心 APIPython · MCP
智能体执行器planner · coder · judge
私有 RAGPostgreSQL · pgvector · bge-m3
本地 LLMllama.cpp · Qwen 27B · RTX 3090 Ti
Git 服务器与 CIForgejo · protected main
外部系统
云端 LLM
Telegram（审批）
主要数据流
- 任务 → 规划者（从 RAG 获取项目上下文）→ 编码者 → 测试 → 评审打分 → Pull Request。
- 按项目规则，主分支只能通过由负责人合并的 Pull Request 变更。
- 对生产服务器的操作以审批卡片形式发起，负责人确认后才执行。
关键决策与取舍
- 评审与作者分离. 由另一个模型在独立上下文中评审；阈值在评估前确定，不根据结果调整。
- 模型更换须经 A/B 测试. 更换本地模型前比较速度、知识与智能体任务；最近一次更换达到约 80 对 43 token/s，知识测试 29/30。
- 修正指令，而非单次会话. 智能体出错时，把规则写入项目指令或技能，下一次运行就不会重犯。
具体工作
- 智能体角色，架构决策记录为 ADR；交接文件保证工作跨越上下文限制延续。
- 在自托管 Forgejo 中提交 Pull Request；人工评审前由测试和评审分数把关。
- 跨项目的私有 RAG、平台核心的 MCP 工具，在 Telegram 中审批与通知。
成果
一个人即可借助智能体工作流交付平台级的工作：带评审分数的 Pull Request，合并与生产操作由人审批。
经验与改进
曾有两个智能体同时在一个代码库上工作而互相覆盖文件；现在并行工作一律放在独立的分支或工作树中。