从跑通到放弃：我的 Cloud Agent V1开发历程

2026年5月30日 18点热度 0人点赞 0条评论

📰 来源: 博客园

Vibe Coding，启动

2026年1月，我在各种SNS上看到越来越多的关于Vibe Coding的经验分享。上家公司我曾对接过一些AIGC的场景，也了解过cursor、copliot这些工具，起初并未在意。但当我看到有人说“并发开10个Agent——5个写代码、3个测试、1个工作汇总、1个写文档，下班回家睡一觉，第二天来公司代码就写好测完可上线”时，还是有点震惊，AI Coding的能力已经进化到这种地步了吗？处于尝鲜，我安装了Trae，让它接手了我业余时间编写的一个小应用，效果还不错，耳目一新。

等到年后开工，我尝试用Trae处理新分配的需求并编写代码。不过项目还没开始，公司就安排了一个调研任务——一个财务领域的 AI 助手要怎么实现？我也紧跟潮流安装了Claude Code，接入glm-5模型，开始编写代码。

Vibe Coding初体验

如何通过Vibe Coding从零构建一个Agent？对于LLM和Agent，我之前只是粗浅地了解过，没有相关的技术背景，但是既然SNS上把Vibe Coding吹的神乎其神，叠加此时的养龙虾热，我自然是信心满满。

打开对标的产品，先体验其交互，然后告诉Claude Code：“我要有XXX功能，这个功能需要XXX”/“页面布局为XXXXX”等等等等。

等Claude Code写代码

我启动服务器，进行测试，发现有bug就让Claude Code继续改

不出意外，遇到了很多问题：

前端交互改起来很费时间，我毕竟是后端出身，对于前端没有那么了解

同一个bug，反复改很久才改好。有时还会出现：bug1修了1天修好了，开始修bug2，bug2修好了bug1又重现了。

大模型限流。虽然是公司提供的coding plan，但是用的太狠还是限流。

但说来也怪，尽管各种不顺，Vibe Coding 会让人上瘾。一旦开始写代码完全停不下来，有点像刚毕业那会儿大展拳脚的感觉——把想法丢给 AI，看着代码在面前长出来，那种即时反馈让人沉迷，甚至游戏都不香了。

V1：跑通了，跑不动了

经过一点一点探索和尝试，还真的把 Agent 写出来了，也就是 Cloud Agent V1。它用 Python FastAPI 搭建，6 周时间、170 个commit（多次squash，实际更多）、约 1.7 万行代码，纯 Vibe Coding，没有手写一行代码。V1 的核心是 LLM 输出带 XML 标签的 Python 脚本，正则解析后在沙箱环境执行。能对话、能操作文件、能执行脚本、能加载 Skill、能调用 MCP，跑通了完整链路。3 月份的各种产品演示都靠它撑了下来，但每次演示前心里都在打鼓——怕 LLM 输出跑偏，怕对话突然卡死。

能跑，但没有任何优势。CherryStudio、Openclaw 这类开箱即用的 Agent 同样能对话、能操作文件、能接 MCP，V1 没有差异化。更要命的是，V1 已经改不动了，继续加功能只会让它更不可控。下面说致命的部分。

致命伤一：XML 标签当协议

这是 V1 最根本的架构问题。系统不是通过 API 原生的 tool_use / function calling 机制执行操作，而是让 LLM 用 XML 标签包裹生成的Python代码，用正则匹配提取后在python沙箱执行。流程可以简化为两阶段：

用户输入
  │
  ▼
┌─────────────┐
│ Judge 阶段   │  轻量 LLM 调用 → 决定加载哪些 Skill、文件
└──────┬──────┘
       ▼
┌─────────────┐
│ 处理阶段     │
│             │
│  ◄── 循环 ──┤  LLM 生成 <script> → 正则提取
│             │    → 沙箱执行 → 结果回传 → 下一轮
│             │    最多 50 轮
└─────────────┘
       ▼
    返回结果

自由代码无约束。 LLM 生成的是任意 Python 脚本，不是带 schema 的函数调用。参数是凭空捏的，函数名是幻觉出来的，文件路径是猜的。代码语法错误、import 不存在、变量未定义，全靠沙箱报错才知道。

一个脚本干所有事。 LLM 倾向于把多个操作塞进一个 <script> 块：先读文件、再算逻辑、最后写结果。中间任何一步崩了，整个脚本失败，而且不知道崩在哪一步。

代码错误 vs 业务失败无法区分。 沙箱返回一个 traceback 或一个 None，系统分不清是"脚本写错了"还是"查询的数据确实为空"。两种场景下游处理完全不同，但 V1 都当成"再试一次"。

正则解析脆弱。 LLM 输出的 <script> 标签稍有偏差——少个闭合、think 块里混入了类似标签，代码里碰巧包含 </script> 字符串，解析就断了。唯一的恢复手段是让 LLM 再试一次，但它不知道哪错了，只能反复生成代码、反复失败，直到运气好成功、轮数耗尽或用户放弃。

沙箱文件复制的开销。 每次执行脚本前，先把相关文件复制到隔离沙箱，安全但每轮多一次 I/O。多轮任务跑下来，大量时间耗在文件搬运上，实际计算反而占比不高。

致命伤二：上下文管理混乱

历史消息不做 token 精算，唯一的措施是只保留最近 N 轮，更早的直接丢弃。简单粗暴，但结果是两个方向都崩：保留太少，聊几轮 LLM 就忘了开头说过什么，反复追问用户已经回答过的问题；保留太多，一轮交互轻松破 10 万 token。模型也就 200K 的上下文窗口，几轮就烧完了。要么触发 API 400 直接拒绝，要么 LLM 静默丢弃早期上下文，同样是失忆。根本不存在一个稳得住的平衡点。

核心循环最多跑 50 步，每步无条件追加 assistant 响应和脚本执行结果反馈到消息列表。加上聊天历史，全部按轮数硬裁，没有优先级、没有摘要压缩、没有关键信息标记。前面讨论的业务背景、确认过的文件路径，几轮之后就跟从来没出现过一样。

系统提示词约 200 行，硬编码在 Python 源码里。每次 LLM 调用动态拼接：基础提示词 + MCP 工具描述（含完整 JSON Schema）+ 项目文件预览（Excel 表名、列名、数据样本）+ Skill 指令全文。一次普通业务调用，提示词本身烧掉 1-2 万 token。而且每次从头构建，没有缓存复用。这意味着 Skill 指令也是跟着上下文一起膨胀：花大量时间和用户一轮轮调试优化 Skill 的触发条件和提示词，但优化完之后塞进已经臃肿的上下文里，LLM 到底有没有按指令走、触发是否准确，完全不可知。优化了一整天，效果全凭感觉。

治错地方的优化：两个失败的 token 节省策略

Judge Phase

开发和测试中，我意识到了上下文问题，设计了一个 Judge 阶段来解决它，这也是 V1 里我的原创设计。想法不复杂：每次执行任务前，先做一次轻量级 LLM 调用，判断用户要处理哪些文件、需要加载哪些 Skill，然后只把筛选后的内容注入完整上下文。

想法没问题，但忽略了一个基本账本：多一次 LLM 调用，用户就多等一轮。每次操作都要先等 Judge 返回，再等执行结果，响应速度直接被拖慢。如果能用轻量模型来做，消耗倒不至于太大。但

🔗 原文链接: 点击阅读原文