把自己的编码智能体做成一件长期作品

2026 年 6–9 月。做这件事的动机很直接：现成的编码智能体在"通用"上做得很好，但我要的一些东西——持久记忆、以中小型模型驱动的多智能体工作流、目标驱动的长任务执行——要么没有，要么不可控。

先说结论

• 在开源底座上做增量移植（只保留真正需要的特性）比重写更好维护；
• 客户端协议要按任务语义设计，而不是套用通用移动端规范；
• 自研的价值在于可控：记忆、工作流与执行方式都由自己定义。

一、改造而不是从零写

我以开源编码智能体为底座重写了自己的版本，关键取舍是只移植真正需要的增量特性（最后一共保留 9 项），其余保持上游结构。这样做的好处是可维护：上游更新时冲突面小，出问题时容易定位是"我改的那部分"还是"底座的问题"。

补上的三类能力：

• 持久记忆：跨会话保留结论与约束，而不是每次重新交代；
• 多智能体工作流：面向中小型模型（不是顶配模型）设计分工，让便宜模型也能完成需要多步推理的任务；
• 目标驱动执行：给一个目标，让它自己拆解、推进、在中断后续跑。

二、发布与文档

项目发布到 npm（含版本号与变更记录），并配了独立的文档站（VitePress）——文档站不是装饰：把"为什么这样设计"写清楚，下次自己要改的时候能省一半时间。

三、客户端协议设计

为安卓端做了一套 agent-bridge 协议：21 个请求、18 个事件。设计过程中的一次否决值得记录——最初想直接套用现成的移动端设计规范（Material 3），后来否掉了：终端类 agent 的交互语义（流式输出、长任务进度、会话恢复）与常规移动应用差别很大，套用现成规范会让"等待与中断"这类关键状态表达不清。

四、顺带补上的两块基础设施

模型服务：为自托管推理写过一个 vLLM 的 out-of-tree 插件，把某个模型族的模型实现、Transformers 配置与工具调用解析器以插件形式接回框架，不改动 vLLM 源码。这样做的好处是框架升级时不用重新打补丁。

随身入口：把自建的一组网页服务聚合成一个安卓应用（Flutter），手机上可以直接访问自己的服务，不必记一堆地址。

五、体会

编码智能体是少见的"自己会被自己用到"的软件：我用它写过其它项目，也用它改过它自己。这种自举关系会暴露很多平时被忽略的问题——记忆该怎么存、任务中断了怎么续、多个角色怎么不互相踩脚，这些都是把它当"工具"时不会认真对待的问题。