Coding Agents 阶段性总结

2026-08-24 · 4014 字 · 约 11 分钟

人工智能

# Coding Agents 阶段性经总结

我很早就开始把 AI 用在个人开发和学习中。本文是一份 Coding Agents 的阶段性使用总结与经验分享，大家也可以当流水账消遣。

由于时间跨度较大，开发环境多次迁移，其中许多细节已经模糊，时间顺序也可能存在一定的偏差。

# 1. 从网页对话到编辑器插件

最开始我是在 Windows 上使用 Coding Agents。那时 AI 刚出现，Agent 大多还停留在网页对话窗口，形态较为单一，就是常规的你问我答的方式。 在这之后 Coding Agents 以编辑器或者插件的形式，更深地融入到了开发流程中。我的主力编辑器是 VS Code，最早尝试的 Coding Agents 插件包括 GitHub Copilot、通义灵码、Mars、CodeBuddy 等。

字节的 Mars，后来应该改名 Trae 了。它运行时 CPU 狂转、内存占用也很高，所以很早就被我停用了。通义灵码用得最久，主要承担对话、需求补充和语法补齐的角色。灵码的「@」文件功能当时不太可靠，所以已有代码的实际修改，我常常交给 CodeBuddy 完成。

GitHub Copilot 是另一条线。我已经记不清最初从何时开始使用，只记得先试用了一个月，觉得体验不错，随后订阅了 Pro。当时的 Pro 套餐额度相对充沛，甚至还有一些免费模型，和现在消耗量巨大的 Credit 机制完全不同。

在这个阶段的后期接触到了 kilo，发现 Kilo 的过程也是很偶然：我在 OpenRouter 上闲逛时，发现当时的 Apps 调用列表里，它仅次于 OpenClaw，抱着「尝试探索」的心态体验了一下，随后发现了这个宝藏。

这一阶段的 Coding Agents 差不多是一个提高效率的工具：能回答问题、补全代码、处理局部修改。

# 2. Linux 与 CLI

Claude Code 等 CLI 形态的 Coding Agent 出现后，我也跟着尝试了一圈：Qwen Code、Gemini CLI、OpenCode、IFlow CLI、Claude Code，还有一些如今已经记不清的工具。最后留下来的是 OpenCode。

也是在这段时间，我转向 Linux / Windows 双系统，并把 Linux 作为开发主力。回头看，我当时会把 CLI 粗略分成两类：一类是 Qwen Code 那样比较传统的 TUI；另一类则像 Claude Code，试图把越来越多 GUI 式交互塞进终端。（当时的使用感受，今日未必一致）。

我最先尝试 Qwen Code，多少是因为通义灵码留下的情感因素，当时每日也有免费调用次数。但同为阿里千问的产品，Qwen 和灵码之间的配置、Skill、Agent 不能通用，难以发挥互补优势；并且 Qwen Code 当时还不支持非常火的 sub-agent、Agent Team 模式。与此同时，Kilo 插件早期在长上下文的场景存在比较严重的内存溢出问题。于是我需要功能更完整的 CLI，并在 GitHub Trends 上发现了 OpenCode，随后转向它。

OpenCode 当时给我的体验很好：支持 sub-agent，能接入大量第三方模型，并且更新频繁，可以不断尝试新的设计。当然，也能不断体验到新的 bug（哈哈）。

我后来在 Windows DevContainer 中继续用 OpenCode 作为主力，也短暂使用过 Claude Code，但两者给我的实际体验差别不大，所以没有形成足以迁移的理由。

# 3. 回到 VS Code：为了效率

双系统本身也有不少坑，显示器在 Linux 下的色彩配置一直异常。所以不得不回到 Windows，却又舍不得 Linux 的开发体验，于是在很长一段时间里用 Windows DevContainer 模拟 Linux，同时也可以把它作为 Agent 的沙箱。

随着 Agent 能力增强，我对开发效率的要求也越来越高。OpenCode 的 TUI 在纯文本 Markdown 阅读和交互上劣势变得越来越明显，尤其是 Mermaid 图表等需要高度依赖渲染的内容，在终端里总是隔着一层。

真正的转折点是 DeepSeek V4 Flash 预览版。当前期 PLAN 已经把设计拆清楚时，后续实施并不一定需要最强的模型，更需要的是稳定、快速、连续地执行。那时我已经开始多窗口并行开发，但 OpenCode 当时没有自动审批，白名单也有问题，常常需要中断工作流去批准命令。这直接抵消了 Flash 的速度优势，于是我把更多工作重新交回 Kilo。

工作流迁移到 Kilo 的过程也不顺利。当时它刚从 V5 过渡到 V7，索引功能一度缺失；而我的项目库不仅有代码，还有大量难以靠 grep 发现的项目文档、PLAN、Spec、Skill 和 AGENTS.md。为了弥补这一功能，我试过自己搭 embedding 索引，但阿里云 embedding v4 费用账单感人，本地跑 Qwen3-0.6B 后又受限于显存，显卡就干不了其他的活儿了，所以一边用着 Kilo，一边寻找替代方案。

我也试了灵码、CodeBuddy、Roo Code 和 Cline。前两者当时不支持 WSL 与 DevContainer，无法进入开发环境；Roo Code 的使用感不错，毕竟 Kilo V5 就是从它分叉出来的，但当时 Roo Code 公告了将停止维护的消息，所以没法作为长久之计。Cline 使用量很高，但在我的印象中它当时不支持多模型，Agent Prompt 数也有限，也不支持索引，浅尝几日后便放弃了。

那是一段典型的混用期，我尝试了大量 Coding Agents：GitHub Copilot 很好用，但 Pro 额度不够；Kilo、Roo Code、OpenCode 则轮流成为主力。随着 Kilo V7 逐步完善，它的占比越来越高。DevContainer 中 Kilo 的通知功能曾有 bug，我还为此自己写了飞书通知插件：agent-exo。

在这期间 DevContainer 的沙箱也确实发挥过巨大的作用。有一次运行 SCNet Coding Plan 中的 MiniMax 2.5 时，项目目录被清空；万幸隔离和备份仍在，最终恢复了数据。

# 4. 模型、套餐

模型和套餐并不是这篇文章的主角；但它们影响了我能以什么速度、把多少任务同时交给 Coding Agents，因此也是后续工作流和环境迁移的现实约束。

我最开始订阅的是阿里云的 Coding Plan 和字节跳动的 Coding Plan，以及试用 OpenRouter 上的免费模型。也正是为了接入更多第三方 Provider，我在 OpenRouter 上闲逛时偶然发现了 Kilo。

字节的 Coding Plan 体验非常的糟糕，我没有续费；阿里云的 Coding Plan 似乎续费了几次后就绝版下架了。之后我用过一段时间 DeepSeek V4 Flash API。缓存命中很便宜，但日均调用仍需花掉约二三十元，非常焦虑。这个时候小米提供了「Xiaomi MiMo Orbit-百万亿 Token 创造者激励计划」我申请拿到 MiMo 的 Token Plan Pro 套餐，MiMo 2.5 支持多模态，相比 DeepSeek V4 Flash 有诸多优势。但一开始 Pro 套餐的额度也不足，不过 MiMo 大幅降价后，勉强与 DeepSeek V4 Flash、GitHub Copilot Pro 共同支撑日常开发。

后来 GitHub Copilot 改为 Credit 机制，消耗速度惊人，所以终止了续费。同期我开始使用 OpenCode Go（OpenCode 的云托管版本），它提供 DeepSeek V4 Flash 和 MiMo 2.5，价格与官方相近（缓存命中非常便宜）。

MiMo Pro 到期后（感谢小米赠送的两个月额度），想试试新的模型，GLM 抢不到，并且不支持多模态，所以我选择了 Kimi Allegretto。我很早就想尝试 Kimi 了，但是 Kimi Allegretto 的额度不透明让我一直非常犹豫。不过周围好评率挺高的，所以最终选择了 Kimi Allegretto。

当初还是 Kimi 2.6，额度还是比较令我满意的，搭配 OpenCode Go、稍微减缓些开发速度，是够用的， 只是从 DeepSeek V4 和 MiMo 2.5 1M 的上下文，转到 Kimi 2.6 275k 的上下文，会有些不适，Kilo 的自动压缩也存在 bug。 Kimi 2.7 Code 应该在之后不久就出来了，似乎比 Kimi 2.6 更加省 token，所以之后很长时间的主力是 Kimi 2.7 Code。Kimi Allegretto 因为体验比较好，所以一直在续费。接着 Kimi K3 出来了，效果确实非常惊艳，但套餐消耗速度也同样惊艳，所以当时还购买了些 MiMo API 作为补充，形成 OpenCode Go 为主、Kimi 为辅的组合。

之后应该是 阿里云千问 Token Plan 的个人版推出（虽然和团队版一样，看文档感觉性价比不高），但是看着 Qwen 3.8 preview 夜间有 0.01 的折扣，仍然选择订阅了 Token Plan 的 standard 的版本。实际使用下来 Qwen 3.8 preview 虽然有 0.01 的折扣，但是额度消耗也高于我的预期，不过结合 OpenCode Go + Kimi Allegretto 这 3 个套餐合并，基本能满足我的开发需求。 并且这期间 Kilo provider 提供了 K3 275k 的选项，我发现 K3 不用满 1M 上下文，额度消耗似乎小了很多（不清楚是不是心理作用），算是一个小确幸吧。

接下去就是最近的事儿了， 千问 Token Plan 的个人版，过了三周左右取消了 Qwen 3.8 preview 并且 Qwen 3.8 夜间只有 5 折优惠了， 虽然期间提供了一周的免费重置，但是实际使用下来下完全不够用。 雪上加霜的是，这期间，8 月 17 日，DeepSeek V4 大幅度的涨价，瞬间两大支柱没了，当时我可慌了。

再加上早有耳闻隔壁 GPT 5.6 大幅降价，并且还时不时的额度重置，所以终止了 千问 Token Plan 个人版续费，订购了 ChatGPT Plus， 实测下来，ChatGPT Plus 相比 千问 Token Plan 个人版 standard 相同的价格，额度相对更多些，和第三方 Agent 兼容性也更好些，也没有夜间折扣，这种让需要昼夜颠倒的限制。

紧接而来的是 Meta 推出了新的模型 Muse Spark，也大幅降价，OpenCode Go 也收录了它；腾讯的 HY3 也在 OpenCode Go 提供了 8 倍额度，这大概就是我目前的模型与套餐情况。

Flash 让我看到实施阶段对速度的依赖，MiMo 的多模态能力则让我开始希望把浏览器、Playwright 和 GUI 可视化开发真正纳入 Agent 工作流。这也直接把开发环境推向了下一阶段。

# 5. Agent 把开发环境推向下一阶段

DevContainer + Kilo 的模式维持了很久，但随着模型多模态能力增强，我想要把浏览器、Playwright 和 GUI 可视化开发纳入工作流，DevContainer 的局限开始集中暴露。在容器中安装 Chrome、通过 Docker 输出浏览器页面时，遇到了很多问题例如，端口无法访问、MCP 无法认证、浏览器窗口难以关闭等。这些都是 Agent 实际操作浏览器时难以越过的工作流断点。

因此，2026 年 6 月初我开始把开发环境从 DevContainer 迁到 WSL。WSL 的 GUI 开发体验比 DevContainer 好许多，浏览器与可视化能力也都能正常使用。

随着 Spec 积累、我和 Agent 协作越来越熟练、并行任务越来越多，内存需求开始成倍增长。但我的物理机只有 32 GB 内存，即使给 WSL 分配了 Swap，仍多次发生 WSL OOM，甚至带着整个 Windows 系统崩溃 FAULTY_HARDWARE_CORRUPTED_PAGE (0x12B)。

到 2026 年 8 月初，多次崩溃后，我不得不切回 Windows 原生开发，并把 WSL 保留为 Docker 后端。切换后，系统没有再因 WSL OOM 崩溃，浏览器也能正常调用。但是 Windows 下的命令行体验远不如 Linux，尤其是 PowerShell 调服务器 Bash 命令、涉及 TTY 密码输入等操作；此外由于之前经历过工作目录被清空，我也始终对 Agent 直接操作文件系统保留戒心。只是以现有的财力、物力和稳定性要求来看，也只能接受如今的开发环境。

# 6. 跨 Harness 的 Spec 工程

因为开发环境和 Coding Agents 都在不断更换与探索，所以我也一直在寻找相对通用、能跨 Harness 迁移的 Spec 工程。

我早期探索过不同 Harness 的 Spec 机制，例如 GitHub Copilot 的 Instructions、Kilo 的 Rule 与 Workflow。后来我逐渐收束到 AGENTS.md、Agent Skills 和 MCP。插件由于定制性太强，不在此次讨论的范围内。

# 6.1. Rule

我花了很多时间尝试各种 Rule 方案（GitHub Copilot 中是 Instruction），最后还是放弃了全局 Rule。以 Kilo 为例，Rule 会在每次交互时注入。理论上这似乎最可靠，实际却有两个问题：

  1. 即使反复注入，Agent 仍可能不执行，且不同 Model 的服从程度差异很大。
  2. Rule 很容易膨胀，并让每个 Session 携带大量与当前任务无关的上下文。

同时，各个 Harness 的 Rule 格式和存放位置并不一致，而我通常会同时使用两个以上的 Harness。

对于 rule，我最终采用 AGENTS.md 配合 Agent Skills 的方案：简单、目录相关的约定放到对应层级的 AGENTS.md；复杂、可复用的流程写成 Skill，再由 AGENTS.md 建立索引。

使用下来比把所有 Rule 在每个回合硬塞进上下文更有效。如果仍不放心，我会在用户输入里明确写「请按照规范」或「请根据 Agent Skills」，大多数模型都会自行寻找项目中的 AGENTS.md 与 Skill。

# 6.2. AGENTS.md

我的 AGENTS.md 基本遵循通用设计：保持短小精炼，尽量不超过 150 行，包含目录结构和必要的文档、Skill 索引。

AGENTS.md 采用多层级的设计，较大的目录各自放一个 AGENTS.md，让 Agent 就近读取，而不需要在根目录的 AGENTS.md 里解释整个项目。实测下来，这种多层级嵌套能被大多数 Agent 兼容。

# 6.3. Agent Skills

Agent Skills 则统一放在 .agents/skills，这是大多数 Harness 都兼容的位置。

如果有第三方的 skills，我通常不会直接复制现成 Skill，而是让 Agent 先理解 Skills，再结合本地项目适配。

我最常用的三个 Skill 是：

  • grill-me：最初大概来自 https://github.com/mattpocock/skills。从使用 Agent 至今，我发现它们始终不太喜欢主动提问、指出疑点，用户的输入不管正确与否大多照单全收。所以尤其是在 PLAN 期间，我会多次用 grill-me 强行要求 Agent 主动提出问题。
  • plan-mode：我在每个需求、每次修改都会先创建 PLAN，再按 PLAN 审阅和实施。PLAN 本身经历过 Kilo 内置 Plan、项目内分散 PLAN、根目录 Sprint 化、再回归统一 PLAN 的过程。实践证明，分散 Plan，多文档 Sprint 对 Agent 太重、灵活性也不足，统一 PLAN 反而更适合多项目工作区。
  • session-retrospect：在每次 Session 结束时，让 Agent 回顾当前与关联历史 Session，将经验沉淀为文档、Skill、AGENTS.md 或记忆。它是整套 Spec Engineering 能不断自我修正的重要功臣。

# 7. 仍未解决的问题

现在的 Agent 已经非常的强大，但仍然有许多我认为可以改进的地方：

  • 多项目、多 Git 仓库支持仍然不足，特别是基于 worktree 的工作流，很难自然适配多仓库工作区。
  • 重载启动、长上下文加载的性能和内存消耗仍有明显优化空间。
  • 从工程角度看，日志、监控和后续审计评估能力仍不完善。
  • 命令行响应、自动压缩等细节也还会持续影响体验。

Coding Agent 这场探索显然还未结束，接下来我还会继续尝试 DSH、OMP 等 Harness，并探索更多模型和更多 Agent 协作方式。

Cheers!