企业官网建设流程全解析

上一篇简单说了一年以来到现在的变化，我想现在可以把我现在使用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去和zcode，opencode 到同样的环境下去完成同样的任务 ，目前表现还是挺好的。这里也有一个影子测试机制。现在每个项目，如果有开发或者hotfix的需求，会通过技能建任务卡。任务卡放在一个专门的中央仓库，里面指明了对应任务的项目位置，环境，需求，测试等一系列要求；其中包括分支起点、终点和容器环境。这样其他的影子测试可以切到同样的环境和代码起点，往前进一步，看看结果如何。按照准确、可靠、效率、成本等进行综合评分。之前说还可以是已经经过了3个卡的多影测试，整体上是还不错的。

所以，最终的我agent系统这么规划：

• 1 andybot : 核心的agent harness （这个借鉴了 openclaw, lanchain, zcode)
• 2 messenger : 用于连接人与agent 的双向IM (借鉴了openclaw, zcode）
• 3 deamon : 用于多个agent的集中管理（每个运行环境都会有deamon),这个借鉴了 multica
• 4 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: 相当于私有的slack
• 11 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的变化很快，拭目以待。