从 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

长期来看，如何迭代计划（判断需要进化的依据？数据支撑是否合适？如何权衡记忆数据关联？）

大量任务

↓

发现规律

↓

自动生成 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。

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

欢迎讨论。