一个自主 AI 智能体在约 20 分钟内构建了一个完整的检索增强生成 (RAG) 技术栈，并在没有一行人工编写代码的情况下开启了一个草稿 Pull Request。
为什么“循环”至关重要
构建 RAG 技术栈通常意味着要将搜索引擎、嵌入模型 (embedding model)、语言模型和胶水代码缝合在一起。开发者往往会浪费数小时来调整 Helm charts、修复身份验证故障以及处理不匹配的模型名称。在本次测试中，该自主智能体遵循了一个五步循环流程，在编写任何代码之前，强制要求实现人机协作的一致性。
| 阶段 | 发生的内容 |
|---|---|
| 提议 (Proposal) | 智能体阅读提示词并起草一份具体的计划，但尚未生成代码。 |
| 确认 (Agreement) | 用户审查计划，批准或请求修改。 |
| 实现 (Implementation) | 智能体在新的分支上构建功能。 |
| 草稿门禁 (Draft Gate) | 智能体运行自身的 linting 和测试套件，并修复发现的错误。 |
| 草稿 PR (Draft PR) | 代码被推送，并开启一个 Pull Request 以供最终的人工审查。 |
大多数 AI 辅助编程工具会直接跳到实现阶段，往往会产生偏离目标的错误代码。通过插入一个明确的确认步骤，该循环阻止了盲目执行，让用户在任何提交 (commit) 落地之前就能掌控项目方向。
最终构建的技术栈
在 20 分钟内，智能体组装出了一个生产级的 RAG 流水线：
- OpenSearch 3.7 已配置为混合搜索（向量 + 关键词）。
- Local Ollama LLM 作为检索增强响应的生成引擎。
- FastMCP server 向语言模型暴露了四个自定义工具。
- Skaffold and Helm 脚本，实现了容器构建、Kubernetes 清单 (manifests) 和服务部署的自动化。
该流水线预置了 30 篇文章，从而可以立即进行端到端的检索和生成测试。开发者通常需要花上一整天的时间来配置每个组件；这种速度令人震惊。
差点让它崩溃的 Bug
智能体的能力受到了五种不同故障的考验，这些故障在人工部署中通常会导致停滞：
- OpenSearch 凭据错误 – 智能体提供了错误的密钥 (secret key)，导致集群拒绝连接。
- URL 中的正则表达式拼写错误 – 一个字符的错位将有效的端点变成了死链，导致数据加载器失效。
- 模型名称不匹配 – 连接器预期的 Ollama 模型标识符不同，导致“找不到模型”的错误。
- JVM 内存限制 – 批量索引耗尽了 Java 堆内存，触发了内存溢出 (out-of-memory) 崩溃。
- 误删模型分块 – 一个清理脚本将必要文件误认为重复文件并将其删除，威胁到了整个流水线。
当智能体陷入困境时，“loop-police”介入了
一个名为 loop-police 的伴随式看门狗负责监控循环的健康状况。当智能体在处理删除 Bug 时进入了一个无法终止的循环时，loop-police 检测到了停滞，中止了当前分支，并强制转向回“确认 (Agreement)”阶段。随后，智能体承认了错误，清理了损坏的状态，并从头开始重建流水线。除了最初的计划批准外，整个自愈周期在无需人工干预的情况下顺利完成。
这对开发者意味着什么
- 在不牺牲控制权的情况下提升速度。 该循环允许工程师指定意图，然后将执行交给一个遵循人工批准蓝图的自主系统。
- 内置安全网。 自动化的 linting、测试以及能够中断失控循环的看门狗，降低了静默失败的风险。
- 降低准入门槛。 缺乏深厚的 Helm、Kubernetes 或向量搜索专业知识的团队，可以通过使用自然语言描述需求来快速搭建起一个功能完备的技术栈。
这种方法并非万灵药。在“确认 (Agreement)”阶段，仍然需要具备专业知识的审查者来发现不切实际的预期或安全隐患。该循环并不会取代领域专业知识；它只是将重复性的底层构建工作封装成了一种可重复的模式。