我觉得我 vibe coding 遇到了瓶颈

从 Prompt 到 Agent Runtime：我的 Vibe Coder + vibe-code-loop + delx-memory 设计探索

一个关于 AI Coding Agent 长期运行、记忆、进化能力的架构实践与思考。

当前设计仍在探索阶段，希望借助社区力量讨论下一步演进方向。

1. 背景：AI Coding Agent 的下一阶段是什么？

过去一年，AI 编程工具快速发展。最初：```
用户
|
Prompt
|
AI
|
代码
```例如：

帮我实现一个登录页面

AI 根据上下文生成代码。后来：```
用户
|
AI Coding Agent
|
工具调用
|
代码修改
|
测试
```Agent 开始具备：查看代码、修改文件、执行命令、调试问题；但是在实际长期使用过程中，我发现一个问题：

Agent 能完成一次任务，但很难持续积累工程经验。

例如：第一次：修复一个 Vue 项目 bug（Agent 解决），第二次：遇到类似问题，Agent 仍然重新分析。它不知道：

- 之前为什么这样设计

- 哪些方案失败过

- 项目的隐含规则

- 用户个人偏好

这让我开始思考：下一代 Coding Agent 是否需要类似“工程经验系统”？

2. 我的核心理念

我认为未来 AI Coding Agent 的核心不是：更长的 Prompt，而是：Prompt + Workflow + Memory + Tools 的系统化组合。简单来说：```
普通 AI 使用：

Human
|
Prompt
|
AI

Agent 系统：

Human
|
Agent Workflow
|
Multiple Agents
|
Tools
|
Memory / Knowledge Base

3. 整体架构

目前我的设计包含三个核心部分：```
             User

              ↓

      Vibe Coder Prompt

    (Agent Identity)

              ↓

    vibe-code-loop Skill

    (Engineering Workflow)

    ┌─────────┴─────────┐

    ↓                   ↓

 Tools              delx-memory(sqlite mcp)

 执行能力             长期经验

4. Vibe Coder：定义 Agent 的工程人格

很多 Agent Prompt 的问题，把所有东西塞进去：角色、流程、规则、工具说明、记忆策略；最终 Prompt 越来越大。 我的理解，Prompt 应该更像Agent Kernel只负责：

4.1 身份

例如：```
你是一名高级软件工程 Agent。

目标不是快速生成代码，
而是交付可靠的软件。

4.2 工程原则

例如：

- 优先理解现有架构

- 避免无必要重构

- 优先验证再修改

- 尊重已有设计决策

---

4.3 决策方式

例如：面对需求，不再是`立即写代码`，而是```
理解问题
↓
评估影响
↓
选择方案
↓
执行

5. vibe-code-loop：让 Agent 从聊天变成工程流程

vibe-code-loop 采用骨架形态，真实 rule 采用 sqlite 进行获取、保存：```
vibe-coder-loop/

├── manifest.yaml # Skill 元数据（机器可读契约：版本/依赖/复杂度/优先级/成本）

├── kernel.md # R0 核心不可变原则

│

├── engine/ # 什么时候做

│ ├── state-machine.md # 状态机定义（S0-S14 全部状态与转移）

│ ├── complexity-gate.md # Task Complexity Gate（Level 0-4 分级 + Loop Depth）

│ ├── router.md # S4 Router 工作流选择（Quick/Standard/Full Loop）

│ └── transition.md # 状态转移规则（各阶段出口条件+防跳过）

│

├── policy/ # 不能做什么

│ ├── safety.md # R1 安全策略（不可逆操作/冲突仲裁/硬约束10项/归档格式/子agent加载包定义）

│ ├── lifecycle.md # 资产生命周期（Active→Deprecated→Archived→Removed）

│ ├── confidence.md # Confidence+Evidence 体系

│ └── priority.md # 优先级系统（Global Priority + Skill Conflict + Rule Hierarchy）

│

├── learning/ # 怎么进化（三层记忆体系 + Pattern + Metrics）

│ ├── reflection.md # 经验反思（触发条件+Reflection Card+5 Why+Pattern Fingerprint）

│ ├── memory.md # Memory 协议（唯一事实源：delx-memory+三层体系+Pattern Fingerprint+去重+评分+跨项目+批量确认）

│ ├── evolution.md # Skill 演化机制（Patch Proposal→Evaluation→Human Approve+Pattern-Driven Proposal）

│ └── skill-metrics.md # Skill 指标追踪（成功率/循环数/失败类型+增量Buffer+早期预警）

│

├── rules/ # 怎么做（强制加载，与 engine/transition.md 配合）

│ ├── intent.md # S1 Intent 目标三元组 + S3 Decision 冲突仲裁协议详表

│ ├── design.md # S6 Design 状态矩阵 + 先验证再假设 + 多页面镜像同步

│ ├── plan.md # S7 Plan Step 拆分 + 编排决策 + 角色人格化映射

│ ├── code.md # S8 Code 前置检查 + 生成要求 + 关键决策说明

│ ├── test.md # S9 Test 强制 subagent + Verifier 角色 + task spec

│ ├── review.md # S10 Review 硬约束检查表 + 五维度 + 情况 A/B/C 模板

│ └── orchestration.md # 多 subagent 编排（S7 编排决策为多 subagent 时条件加载）

│

└── references/ # 按需参考（非强制）

├── example.md # 完整示例

├── output-format.md # 输出格式细则

└── debug-mode.md # 调试模式触发条件
``Prompt 解决：Agent 是谁，Skill 解决：Agent 如何工作；我的设计类似一个工程状态机。``
S0 Idle
|
S1 Intent Understanding
|
S2 Context Preflight
|
S3 Decision
|
S4 Task Routing
|
S5 Clarification
|
S6 Design
|
S7 Planning
|
S8 Implementation
|
S9 Testing
|
S10 Review
|
S11 Reflection
|
S12 Memory Evolution
``核心思想，一次编码任务从：需求 -> 代码 到 需求理解 -> 上下文加载 -> 方案设计 -> 执行 -> 验证 -> 经验沉淀`

6. 为什么需要 Memory？

目前大多数 AI Agent 的记忆聊天历史，但工程场景需要工程经验；所以我设计了三层经验沉淀：```
Instance Memory
具体事件
例如：某次修复 React 状态问题

↓

Pattern Memory
通用模式
例如：该项目状态管理容易出现闭包问题

↓

Principle Memory
工程原则
例如：该项目禁止跨模块直接修改状态

7. delx-memory 的作用

我目前使用：delx-memory mcp（一个基于 sqlte 数据库操作的服务）作为本地 Memory MCP 服务。 它只负责：存储、查询、标签管理、生命周期管理。但是 Memory 系统真正困难的不是存储，而是 **什么值得记？**

例如：不应该保存`修改了 Button.vue`，应该保存`项目统一使用 Design System，禁止直接修改组件样式。`

所以未来需要`Memory Controller`用来负责：判断是否保存、判断保存级别、判断什么时候召回```
Agent
|
Memory Policy
|
delx-memory

8. 当前遇到的瓶颈

目前最大的困难：

1. Skill 是否过于复杂？

随着规则增加：leaning 成本也越来越高，如何找到平衡？```
更多规则
↓
更强约束
↓
更高 Token 消耗
↓
执行复杂度增加

2. Memory 如何自动进化？

目前：```
任务完成
↓
总结
↓
保存 Memory
```长期来看，如何迭代计划（判断需要进化的依据？数据支撑是否合适？如何权衡记忆数据关联？）

![图片](https://cdn3.ldstatic.com/optimized/4X/5/3/a/53ad057a66f1e690dd42e276230099b2dfc024f3_2_690x192.png)```
大量任务
↓
发现规律
↓
自动生成 Pattern
↓
优化 Skill

3. Agent 是否需要 Runtime？

现在：```
Prompt
*
Skill
*
Memory
``是否有必要去实现Agent Runtime````
Agent Runtime
负责：

• 状态管理
• 生命周期
• 调度
• 反馈
• 评估

希望大佬们给一些建议

目前我遇到一些设计瓶颈，希望听取大家意见。

Question 1

未来 Coding Agent 的核心应该是什么？

更强模型？更强 Prompt？更好的 Workflow？还是 Agent Runtime。

---

Question 2

Memory 系统应该如何设计？

应该偏：聊天记忆？知识库？工程经验库？还是自动进化系统。

---

Question 3

Skill 是否应该越来越复杂？

Agent Runtime 代理强规则上下文```
简单 Skill
* 
强 Runtime
```替代：```
复杂 Skill
* 
大量规则

Question 4

未来 Agent 是否需要类似操作系统的抽象？例如：```
Agent Kernel
Workflow Scheduler
Memory Layer
Tool Runtime
Evaluation System

目标不是让 AI 更快写代码。而是：

> 构建一个能够长期工作、积累经验、不断优化的软件工程 Agent。

这个方向仍然有很多未知，希望和社区的佬们一起探索。

欢迎讨论。