上一篇简单说了一年以来到现在的变化我想现在可以把我现在使用agent 进行日常开发的细节说一下。现在主要是用zcode, 模型基本上只用 glm 5.3 flash。这个模型本身是多模态的不太需要切换。而且执行过程比较稳一般不会乱来。glm 5.3 可能强点但有限我觉得没有很大差别。每天只在对话中管理任务其实不止任务包括查找打印机浏览器操作压缩文件等基本上所有的任务都是在工具中用对话完成。从形式上的确是只通过文本就可以实现几乎所有的操作了。所以我觉得 5.3 flash 这个模型是很有意义的 因为这个过程模型可以不要很聪明但是要很稳不要出岔子。这个特性比其他花里胡哨的功能重要100倍这个既和模型有关也和harness有关。就目前来说这个还是比较稀缺的。就开发来说占了我80%以上的时间。开发最重要的文件形态是git,所以我有一个专门的git 项目用来管理多个git项目。我的第一个比较重要的改变在git项目里每个git项目都是一个agent。项目的根文件除了传统的README.md ,我主要放了AGENTS.md并且针对agent工作的特点设计了一套文件和管理系统来支持。比如有memory文件夹用于记忆locate 专门用来定位项目内各功能模块的位置避免agent搜全文而项目的主体在project 子文件夹下面。所以最大的不同是以agent为中心项目是agent管的项目。为什么非得这样做 因为开发的时候是agent 维护的时候也是agent这是一个非常长期的过程。agent的核心能力是状态机状态机的核心能力之一是上下文保持。通过这种agent化的设计我们能够保证在长时间的维护过程中有点类似下载中的断点续传可以基本保持稳定。因为agent现在默认的一个范式是逐层递进的去读AGENTS.md,越贴近目标层的优先级越高所以这天然就形成了一个总分结构。即使我是在本地客户端工作也可以用类似去告诉 xxx 项目有个xxxbug进行修复虽然agent的发起端是在本地可是一旦目的地有另一套agent设置就会带入那边的身份和记忆继续。对开发工作来说相当于有一个镜像分身永远留在了项目里随时可以接续。仅仅有agents.md 是不够的还要有配套规范项目要推进不能只靠软的规则约束需要有一些强的技能约束。这点是很花心思的部分我想这也是很多人即使拿着同样的工具和模型效果也差很多的地方。或者可以打个比方都是一样的车在不同的人手里开出来的感觉可能就天差地别。规范或者说方法论类别的东西我自己也在一直去抽取和塑形。现在并没有一套特别标准的做法但我相信如果有个神能把所有人有效的方法都看一遍并总结那么一定会有很多大的原则是相同的。现在我的项目管理是我把以前项目中的角色抽象和规范出来的这个技能我叫agent-team。现在我是采用戴帽法也就是不给每个角色独立自己的space,而是把问题分成若干类型在流程中戴帽子。其中pm负责项目管理。包括了当用户提出需求需要生成PRD版本号如何编写需要怎么验收等。还有dev, test 等负责开发和测试。最近我还加了一个 andy representative(代表一般性的审核问题这个戴帽子的agent就替我批复了。还有就是项目的架构设计。我基于图的思想要求项目基于数据节点来创建和管理。人最多只能做到审核这些节点来判断项目的方向和产出对不对然后代码的核心部分一般都是状态机设计。这种高度结构化的设计基点会约束住大模型避免他们跑偏。这些也是在我的技能里agent 在进入项目中会被AGENTS.md 指引做任务的时候会自动套用。最后是模块化思维。即使方法对了每次让agent重新去设计也是不稳定、不经济的。我做了两个模块一个是app的一个是web的。前者主要用于后端服务组件的复用后者则用于前端组件的复用。这些组件都遵循 datanode 的约定pydantic)所以在对接时是比较规范的。现在组件里最重要以前欠缺的有两个1、影子采样(shadow sampler) 2、事件遥测(data-io-eventlog)影子采样(shadow sampler)这个组件是基于检验的角度设立的。以前的处理通常是不留痕的特别是微服务化的功能。这样会有一些问题尤其是在调试和迭代的时候。所以影子采样约定可以以一个采样率将数据采集并按日期放在一个地方包含了input-output 的pair。然后按照日期7天滚动删除旧数据。如果有具体的测试那么这批数据是可以被再采样和锁定测试集的。锁定的测试集不会被自动按过期删除的方便未来基于同样的测试集反复重测。事件遥测(data-io-eventlog)这个组件的外部依赖ELK栈同时约定了基本的系统事件然后应用应该增加自己的业务事件。以文件方式追加滚动日志。这里是datanode契约应用最明显的点服务只要遵守组件的约定写日志就可以了后续的事情不用管等开发好了之后外部会启动一个filebeat,把日志读到elk。这两个组件保证了服务总是可迭代且可监控的基于遥测数据可以统计还可以追溯以上是最近实操方面我觉得比较精彩的部分。关于我的agent系统其实粗的规划已经有了之后会基本平铺过来。上面提的是核心的应用场景。我的agent系统里第一核心的当然是 agent harness我称为 abc(andybot core)基本是对标zcode、codex、opencode 这样的定位去做的。之前做过网页版但是底子感觉没有做透我觉得先做cli形态是对的所以重构了一次。大概长这个样子总体上还是不错的。目前我直接用的不多还在影子测试阶段。让abc去和zcodeopencode 到同样的环境下去完成同样的任务 目前表现还是挺好的。这里也有一个影子测试机制。现在每个项目如果有开发或者hotfix的需求会通过技能建任务卡。任务卡放在一个专门的中央仓库里面指明了对应任务的项目位置环境需求测试等一系列要求其中包括分支起点、终点和容器环境。这样其他的影子测试可以切到同样的环境和代码起点往前进一步看看结果如何。按照准确、可靠、效率、成本等进行综合评分。之前说还可以是已经经过了3个卡的多影测试整体上是还不错的。所以最终的我agent系统这么规划1 andybot : 核心的agent harness 这个借鉴了 openclaw, lanchain, zcode)2 messenger : 用于连接人与agent 的双向IM (借鉴了openclaw, zcode3 deamon : 用于多个agent的集中管理每个运行环境都会有deamon),这个借鉴了 multica4 andy_skills : 技能仓库5 dual-tmux: 多agent任务的管理按trigger 和 bullet 两个角色一个站用户端一个站容器端6 agent-beats: 用于每个节拍来确认各事项与目标的差距7 andy-method: 放成型的方法论这是比组件高一层的指导方法8 andy-app-components/web-components 后端与前端的组件9 andy-q : 任务队列10 evidence-view: 相当于私有的slack11 shadow-mode: 集中对影子测试管理现在看起来还是有点散乱的未来几个月我会逐渐的进行整理。从方向上说1 有一个自己的agent harness, 效率和可控性都更好且具备真正意义的记忆具备自学习能力。2 agent 和人之间通过 messenger 进行即时交互3 对于容器的分布式管理使用deamon进行统一管理4 对agent的使用设两级一级在项目本地符合agent的默认假设避开环境以及ssh干扰另一级在用户侧相当于应用助手5 agent-beats 是为了执行更长程的任务并且预防agent 停摆、走偏而存在的6 组件库是为了让 agent可以更高效的开发不重复造轮子尽量复用实在不行才造造了新的轮子也会放在组件库从某种程度上说很快就会毕竟没有新增7 证据服务是为了让agent可以更好的把做的东西进行交流让人理解和相信证据和卡片其实是一对相辅相成的组件卡片是正式的很重的部分可以由任何agent签发 任何agent完成证据则显得零碎但是内容简单人也可以看。8 影子测试时最有野心的部分。通过这个测试我先能确定abc能否上线使用其次大量的进行影子测试我可以知道什么问题分派给什么agent做最好。希望这些分享对你有点用ai的变化很快拭目以待。