Coding at Agent-Speed

最近我用 Code Agent 高强度地构建了一款安全产品——基于 eBPF + PostgreSQL 的 LLM Security Insight 平台。技术栈很杂：eBPF、React、Go、Docker、Kubernetes、PostgreSQL、DuckDB。React 和 eBPF 我完全是新手，但一个月后项目竟然跑通了。

VS Code -> Cursor -> Gemini -> VS Code -> Codex -> VS Code -> Claude Code -> OpenCode -> OhMyOpenCode -> VS Code

我是个 VS Code 老用户。最早接触的是 VS Code Copilot —— 指定文件、说明改动、生成 Patch。叫 Code Assistant 更准确，就是结对编程。在熟悉的领域用起来确实舒服，代码提示 + 结对编程，编程就应该是这样。

2025 年 3、4 月份接触 Cursor。它的 Agent 模式和多文件编辑让我眼前一亮。当时很多人吐槽：习惯了结对编程，多文件编辑让 Review 时间变长，模型生成的代码也不敢直接 Approve。但 Cursor 敢做第一个吃螃蟹的人。随着 Claude Sonnet 模型的能力提升，Cursor 彻底癫狂。

有意思的是，2025 年初 Cursor 联合创始人 Sualeh Asif 给我们团队工程师 keming 发邮件，聊可复现开发环境 infra（envd）。可见当时 Cursor 已经预见 Agent 大规模落地会遇到一致性问题。他们用向量数据库 + Turbopuffer 解决多租户场景的代码检索，这思路和我们做 VectorChord 如出一辙。不过 Cursor 免费额度锐减后，我没信用卡续费，就换赛道了。

Gemini CLI 来了。Google 的资源和 Infra 确实给力，慷慨的免费 Quota 吸引了大量用户。当时我还在负责 VectorChord Cloud，只能用它修修小 Bug、写写 Test。人肉上下文（Context）工作得很好，但依然没有 Agent 的感觉 —— 还是结对编程。

Quota 用完后我又回到 VS Code。GitHub Copilot 免费订阅 + VS Code Agent 模式 + 支持多厂商模型（OpenAI、Claude、Google），Enterprise Quota 足够我用。但我更习惯多文件编辑，每一行代码还是心里有数。

直到 Claude Code 出现，我才真正体会到 Agent 的感觉。模型能力飞跃带来的代码质量提升 + Plan/Auto/Edit 模式的丝滑切换，让我可以规划、有节奏地实现目标。

不过 Claude 对 Region 限制太厉害，我只有通过特殊途径搞到 Token。后来 GLM 出来后，大家反映代码能力和工具调用能力很强，用上后确实丝滑。

后来在推特上看到大家对 OpenCode 的口碑不错，简单试用后感觉还可以。紧接着 OhMyOpenCode 插件在 X 上火了起来，它对于拥有多厂商模型的用户来说确实是个好东西——可以无缝切换不同模型，统一工作流。不过模型迭代快，插件更新也频繁，订阅多个模型、跟踪每个模型的更新、记住每个插件的用法 —— 也是真够累的。

最后我为什么又回到 VS Code？因为我一直用 VS Code Remote 连接开发机，Claude Code 和 Codex 都在 VS Code 上有官方 Extension，还能输入图片（这个场景我经常遇到）。类似 Conductor 这类 Agent Orchestration 工具我就没怎么用上。

我的选择

工具选择

模型选择

多模型协同是趋势。不同模型擅长不同领域，组合使用效果最好。

我的用法

对于文章开头的项目，我基本上是用 Agent 方式完成的：

1. 维护 Project Context

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

~/llm-observability/context/
├── agent-protocol-research.md
├── analyze.sql
├── llm_prompt_injection_analyzer_pg.py
├── pencil-designs/
├── security-product-research.md
└── designs/
    ├── architecture.md
    ├── frontend.md
    ├── mcp.md
    └── ...

所有调研、设计、工具代码都丢进这个文件夹。Agent 能直接读取，效率很高。

2. Global Context 参考 Xuanwo 的实践，我的 Global Context 是 agents.md —— 定义了 Agent 的工作方式、约束条件、Best Practices。所有项目共享这份配置。

3. Design First 和 Agent 一起打磨设计文档，确定技术选型和架构。设计文档就是 Agent 的说明书，写得越清楚，产出越靠谱。

4. Validate Before Build 先让 Agent 写验证性代码，确认方案可行。之前有个 PostgreSQL Schema 设计，Agent 生成的 DDL 我不确认能否工作，于是先跑 Demo 验证。

5. Full Implementation 方案确认后，Agent 完整实现。中间会遇到 Agent 自己搞不定的 Case，比如 eBPF 的某些内核兼容性问题。这种 Case 我会切换到 Claude Sonnet 4.5，让它带着上下文直接 Debug，效率很高。

Git Worktree 是我的救星。Agent 在独立分支折腾，出了篓子不影响主分支。但数据库 Schema 变更是个痛点 —— Docker 跑的单机 PG 无法并发修改 Schema，只能串行。

另外，我对 Git 曾经有点不放心，害怕 Agent 误操作删除调教很久的代码。但随着 Agent 代码质量越来越高，这个心智负担越来越小。

Thoughts

Fork 是刚需

• 代码/文件级别：Git 解决了。
• 运行环境级别：Docker/envd 解决了个人用户需求，但大规模 Agent 运行时的调度还没有完美方案。Unikernel 可能是个方向，但 Firecracker 这类技术还不够成熟。
• 数据库级别：ACID 特性让 Fork 很困难，分布式数据库一旦 Fork 必然有数据冗余和一致性问题。PostgreSQL 这种单体数据库反而有优势。通过 PITR + JuiceFS Snapshot 可以实现 PG 的 Fork，工具如 piglet。

多模型协同是未来

Skill Best Practice + MCP 是生产力放大器

Context/Memory 的演进和共享是核心战场

All in AI

Next Step

• 升级开发机配置
• 全自动化：DNS 配置、域名注册、Agent Notification 等
• 更好的 Global Context + Memory 管理方案
• 大规模 Agent 运行时 Infra 研究