【Komari 接手第二天】agent 架构重构完成，服务端采用features方式组织

用来探测服务器性能指标的 agent（探针）部分架构已经整理完成。

目前还是处于对原项目的重构阶段，重构完成之后，增加更多探测指标。

服务端目录结构

根目录按 Go 社区的标准约定分成三大块：

• cmd —— 命令行解析入口


• internal —— 核心业务逻辑


• pkg —— 可被外部复用的公共工具包

internal 内部：按 features 组织

internal 下面不是按技术分层（controller/service/model 那一套），而是按 features（功能模块）组织的：每一个 feature 就是一个相对独立的业务单元，自己的业务逻辑、数据结构、接口定义都收在自己目录里。模块之间尽量解耦，彼此不直接依赖对方的内部实现，需要协作时通过接口通信。

除了各个 feature，还有一个 platform 模块，放的是多个 feature 模块共用的工具函数、数据结构、接口定义——避免每个模块都各写一套差不多的东西。

新logo

自己设计了一个logo，符合Komari Probe转向纯探针的方向

有个问题

现在就算用 AI 做 vibe coding，难道不会关注架构问题吗？

项目小的时候怎么写都可以，但规模上去之后，如果一直不管架构，会不会担心以后加功能、做维护、排查 bug 的时候，就算让AI写也会很困难吧？