人工智能大模型AI Agent提示工程AI 评测可观测性后端前端【免费下载链接】coze-loopNext-generation AI Agent Optimization Platform: Cozeloop addresses challenges in AI agent development by providing full-lifecycle management capabilities from development, debugging, and evaluation to monitoring.项目地址https://gitcode.com/gh_mirrors/co/coze-loop点击查看免费下载本文以 ARCHITECTURE.md 为骨架深入解析 coze-loop 这一开源 LLM 评测与可观测性平台的整体架构多语言单体仓库布局、Go 后端的 DDD 分层与依赖不变量、前端 Rush 单体仓库的分层与 Adapter 模式、Thrift IDL 共享契约以及代码生成、CI/CD 与 Git Hooks 等横切关注点。读完本文你将掌握该仓库从目录结构、模块边界到构建、测试、部署的全链路技术组织方式并能在实际开发中遵循其架构约束。全景视图一个仓库三层核心coze-loop 采用Go 后端 TypeScript/React 前端的多语言单体仓库Monorepo架构。仓库顶层按职责划分为若干一级目录其中三个目录构成了平台的核心frontend/Rush.js 管理的 SPA 单体仓库约 59 个包负责全部前端界面backend/Go DDD 服务包含 6 个业务模块提供 HTTP 与消息消费两类进程入口release/Docker / Helm 部署配置覆盖镜像构建、Docker Compose 本地部署与 Kubernetes 部署。三者通过idl/thrift/中的 Thrift IDL 形成共享契约IDL 既是后端 Kitex 生成 Go 代码的输入也是前端infra/idl/工具链转换为 TypeScript 类型的来源前后端围绕同一份契约演进。仓库还包含若干支撑设施common/存放由 Rush 管理的 Git Hookspre-commit、commit-msg、pre-push 等.github/workflows/承载 CI/CD 工作流根目录Makefile提供镜像、Compose、Helm 的快捷操作目标。整体布局如下摘自 ARCHITECTURE.md 的全景视图┌─────────────────────────────────────────────────────────────────┐ │ coze-loop 仓库 │ │ │ │ ┌──────────────┐ ┌───────────────┐ ┌────────────────────┐ │ │ │ frontend/ │ │ backend/ │ │ release/ │ │ │ │ Rush.js SPA │──▶│ Go DDD 服务 │ │ Docker / Helm │ │ │ │ 59 packages │ │ 6 业务模块 │ │ 部署配置 │ │ │ └──────┬───────┘ └───────┬───────┘ └────────────────────┘ │ │ │ │ │ │ └───────┬───────────┘ │ │ ▼ │ │ ┌────────────┐ │ │ │ idl/thrift/ │ Thrift IDL前后端共享契约 │ │ └────────────┘ │ │ │ │ ┌──────────────┐ ┌───────────────┐ ┌────────────────────┐ │ │ │ common/ │ │ .github/ │ │ Makefile │ │ │ │ git-hooks │ │ workflows/ │ │ image / deploy │ │ │ └──────────────┘ └───────────────┘ └────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘代码地图Backendbackend/后端是一个 Go 服务模块路径为github.com/coze-dev/coze-loop/backend。整个后端由 8 类目录组成每一类都有明确的职责边界与架构约束目录职责架构不变量cmd/服务入口main.go HTTP, consumer.go MQ只做启动编排不含业务逻辑api/HTTP 路由 handlerHertz 框架handler 只做参数校验和转发业务逻辑在 application 层modules/6 个 DDD 业务模块模块间不直接互调infra/共享基础设施DB, Redis, ClickHouse, MQ, HTTP, middleware被 modules 引用不引用 modulespkg/共享工具库errors, JSON, logging, context cache纯工具无业务依赖kitex_gen/Kitex/Thrift 生成代码自动生成禁止手动修改loop_gen/其他生成代码自动生成禁止手动修改script/代码生成脚本cloudwego, gorm_gen, errorx生成结果提交到仓库服务入口两个进程一个编排层cmd/目录下有两个入口文件分别对应 HTTP 服务与消息队列消费backend/cmd/main.go构建全部组件Redis、MySQL、ClickHouse、S3 对象存储、ID 生成器、MQ 工厂、限流器等随后调用api.Init组装 HTTP handler再通过registry.NewConsumerRegistryWithShutdown注册并启动 MQ 消费者最后以go api.Start(handler)启动 Hertz HTTP 服务并通过signal.NotifyContext监听 SIGTERM/SIGINT 实现优雅退出。backend/cmd/consumer.goMustInitConsumerWorkers一次性注册 evaluation、data、observability 三个模块的 MQ 消费者分别由各模块的infra/mq/consumer目录提供 Worker 构造逻辑。值得关注的是main.go中的基础设施配置全部通过COZE_LOOP_*环境变量注入如COZE_LOOP_REDIS_DOMAIN、COZE_LOOP_MYSQL_DOMAIN、COZE_LOOP_CLICKHOUSE_DOMAIN、COZE_LOOP_OSS_*等而log_level、ClickHouse 超时、ID 生成器server_ids等则来自 backend/conf/infrastructure.yaml 中infra配置段由 viper 配置工厂加载。这形成了敏感连接信息走环境变量、常规参数走配置文件的运维约定。Backend DDD 分层依赖单向领域干净每个modules/domain/内部遵循严格的 DDD 分层目录结构如下摘自 ARCHITECTURE.mdmodules/domain/ ├── application/ # 应用服务用例编排、Wire DI │ ├── wire.go # DI 定义 │ └── wire_gen.go # DI 生成代码 ├── domain/ # 领域模型entity, repo 接口, service │ ├── entity/ │ ├── repo/ # 仓储接口定义 │ └── service/ ├── infra/ # 基础设施实现repo 实现, RPC, MQ, storage │ ├── repo/ # 仓储接口实现 │ ├── mq/ rpc/ storage/ │ └── ... ├── pkg/ # 模块内工具errno, utils └── consts/ # 模块常量依赖方向api/ → application/ → domain/ ← infra/。即 domain 层只定义接口与领域模型infra 层负责实现如 MySQL/ClickHouse 的 DAO、RocketMQ 生产者、外部 RPC 客户端domain 层绝不引用 infra 层。这一约束保证了领域核心可独立测试、不被技术细节污染。以 backend/modules/prompt/application/wire.go 为例可以看到 Google Wire 如何将这套分层组织为依赖图promptDomainSet中既有领域服务service.NewPromptService、service.NewPromptFormatter也有仓储接口与 MySQL/Redis 实现repo.NewManageRepo、mysql.NewPromptBasicDAO、rediscache.NewPromptBasicDAO还有跨模块 RPC 客户端rpc.NewLLMRPCProvider、rpc.NewAuthRPCProvider、rpc.NewFileRPCProvider等。manageSet、executeSet、openAPISet等则分别组合出不同的应用服务入口最终由wire命令生成wire_gen.go。模块隔离不直接互调在 API 层装配架构文档强调模块间不直接互调而 backend/api/api.go 展示了这一约束的实际落地方式6 个模块的 handler 在 API 组装层通过loop_gen生成的 Local Service 适配器互相连接。例如loauth.NewLocalAuthService(foundationHandler.AuthService)把 foundation 模块的鉴权能力暴露给 prompt / llm / evaluation 等模块lodataset.NewLocalDatasetService(dataHandler.IDatasetApplication)让 evaluation 模块复用 data 模块的数据集应用服务lotrace.NewLocalTraceService(observabilityHandler.ITraceApplication)与lotask.NewLocalTaskService(...)以本地 RPC 客户端的形式让 evaluation 模块触发可观测性模块的 trace 查询与任务执行。模块之间通过接口契约解耦真正实现同进程、模块边界仍清晰的架构效果。api.go的Start函数还展示了 Hertz 服务的关键配置使用第三方 JSON 序列化器js_conv、绑定第三方 JSON Unmarshaler并将请求体上限设为 20MB。Backend 技术栈领域选型HTTPHertzCloudWeGoRPCKitexCloudWeGo ThriftORMGORMMySQL, ClickHouseDIWireGoogleLLMEino存储MySQL主存储、ClickHouse分析查询、Redis缓存/锁、RocketMQ异步消息其中可观测性模块对 ClickHouse 的依赖尤为突出在 backend/modules/observability/application/wire.go 中trace 数据通过ckdao.NewSpansCkDaoImpl/ckdao.NewAnnotationCkDaoImpl落盘 ClickHousespan 采集链路则由rmqreceiverRocketMQ 接收→queueprocessor队列处理→clickhouseexporterClickHouse 导出三段式 Collector 构成任务侧则注册了TaskTypeAutoEval自动评测处理器与StatusCheckTask、LocalCacheRefreshTask两类定时任务并通过lock.NewRedisLockerWithHolder保证调度互斥。代码地图Frontendfrontend/前端是由Rush.js 5.172.1管理、pnpm 10.27.0安装依赖的 TypeScript/React 单体仓库共 59 个包。包被组织为 6 个依赖层级层级目录包数职责Level-6apps/cozeloop/1主 SPAReact 18, Rsbuild, react-router, zustandLevel-5packages/loop-pages/5页面模块auth, evaluate, observation, prompt, tagLevel-4packages/loop-modules/1高阶业务模块evaluateLevel-3packages/loop-components/13UI 组件包 adapter 模式Level-2packages/loop-base/20基础库account, api-schema, hooks, components, env, i18n, stores, route...Level-1config/infra/10工具链配置 ESLint 插件 IDL 转换依赖不变量高层级只能依赖低层级禁止反向依赖。这与后端api → application → domain ← infra的单向依赖哲学一脉相承保证了包图无环、可独立升级。主 SPA 的组装frontend/apps/cozeloop/package.json 显示主应用cozeloop/community-base基于 React 18.2 react-router 6.22 zustand 4.4构建工具为 Rsbuild 2.x测试框架为 Vitest 3.x并提供了dev、build、build:prod、lint、test等脚本开发模式通过REGIONcn CUSTOM_VERSIONinhouse BUILD_TYPEoffline等环境变量区分部署环境。frontend/apps/cozeloop/src/app.tsx 展示了 SPA 的根组件CozeLoopProvider统一注入 i18n 与事件上报适配器Suspense PageLoading处理路由懒加载LocaleProvider负责多语言上下文最后由RouterProvider消费createBrowserRouter(routeConfig)渲染整个应用。Adapter 模式解耦商业版与开源版差异在 Level-3 的loop-components中平台采用 Adapter 模式隔离商业版与开源版的差异adapter-interfaces/ # 接口定义Level-3 ↑ *-adapter/ # 接口实现Level-3按 evaluate/observation 等分 ↑ components-with-adapter/ # 消费者Level-3架构不变量新增商业版/开源版差异必须走 adapter 接口不可在组件中硬编码条件分支。这使开源版可以替换为 noop 或社区实现商业版则注入完整实现组件消费方无需感知差异。代码地图IDLidl/thrift/idl/thrift/coze/loop/按模块组织 Thrift 定义apis/、data/、evaluation/、foundation/、llm/、observability/、prompt/另有extra.thrift与trajectory.thrift。以 idl/thrift/coze/loop/foundation/coze.loop.foundation.auth.thrift 为例可以看到 IDL 同时承载接口契约与序列化/校验细节api.body、api.js_conv、go.tag等注解被分别用于前端路由参数、JavaScript 类型转换和后端 Go 标签生成255: base.Base/base.BaseResp则统一了公共请求/响应结构。修改 IDL 后需分别运行两套生成后端执行 backend/script/cloudwego/ 下的脚本重新生成 Go 代码Kitex Hertz前端使用 frontend/infra/idl/ 工具链将 Thrift 转换为 TypeScript 类型。IDL 是名副其实的前后端共享契约一次修改、双端同步任何一方私自改接口都会在 CI 中被检出。代码地图Releaserelease/与 Makefile目录内容release/image/Dockerfile主服务, debug, python-faasrelease/deployment/docker-compose/Docker Compose 本地部署release/deployment/helm-chart/Helm Chart (Kubernetes 部署)根目录 Makefile 将三类部署方式封装为快捷目标支持从开发到发布的全流程镜像make image--login登录镜像仓库docker.io/cozedevmake image-version用docker buildx build构建并推送 amd64/arm64 双平台镜像make image-python-faas-bpush-version构建 python-faas 镜像。Compose提供make compose-up基础服务、make compose-up-dev基础 开发服务构建、make compose-up-debug调试模式以及对应的restart-*、down、down-v含删除卷系列命令up时使用--profile *拉起全部 profile。Helmmake helm-chart-deps构建 Chart 依赖、make helm-chart-bpush-version打包并以 OCI 推送make helm-up以--install --force方式部署到coze-loop命名空间另有helm-ctx、helm-ns、helm-pod、helm-svc、helm-ingress、helm-logf-app、helm-tpl-app等集群巡检与日志/模板调试目标make minikube-start/make minikube-tunnel则用于本地 minikube含 ingress addon验证。横切关注点代码生成仓库把生成代码提交入库作为统一策略——生成结果直接写入kitex_gen/、loop_gen/与各模块wire_gen.go任何人在 CI 中均可复现校验。四类生成物如下生成物触发方式输入kitex_gen/backend/script/cloudwego/idl/thrift/loop_gen/相关脚本IDL / schemawire_gen.go各 moduleapplication/目录下执行wirewire.gorouter_gen.goHertz 代码生成路由定义以 backend/script/cloudwego/kitex_tool.sh 为例生成流水线分为三步先遍历idl/thrift/下所有.thrift对含service的文件执行cloudwego_kitex -streamx -thrift ignore_initialismsfalse -thrift-plugin validator -deep-copy-apitrue生成 Kitex 代码再执行cloudwego_hz model生成 Hertz 模型随后运行loopgen生成以lo为前缀的本地服务适配层输出到loop_gen/最后将产物整体移动到backend/kitex_gen与backend/loop_gen并自动提交NO_PUSH_REMOTEtrue可跳过推送。backend/script/cloudwego/code_gen.sh 则是入口脚本先执行install.sh安装工具链再依次运行kitex_tool.sh与hertz_tool.sh。此外backend/script/gorm_gen/generate.go 负责 GORM DAO 生成backend/script/errorx/ 则基于各模块 YAML 定义如evaluation.yaml、observability.yaml生成错误码体系。横切关注点CI/CD.github/workflows/下共有 10 个工作流覆盖后端、前端、IDL、Schema、PR 规范与 License 等多个维度工作流触发作用backend-ci.yamlPR (backend/**)Go test lint Codecovfrontend-ci.yamlPR (frontend/**)Rush build Vitest lintfrontend-tsc-ci.yamlPR (frontend/**)TypeScript 类型检查idl.yamlPR (idl/**)IDL 变更检查mysql-schema-check.yamlPR数据库 schema 变更检查semantic-pull-request.yamlPRPR 标题规范检查license-check.yamlPRLicense 合规检查ai-cr-required.yamlPRAI 代码评审issue-sync.yaml/pr-sync.yamlissue/PR仓库协作自动化以 .github/workflows/backend-ci.yaml 为例后端 CI 在ubuntu-latest上安装Go 1.24.0先运行 golangci-lintv2.2.1配置为../.github/.golangci.yaml再执行go build -v ./...与带-race的单元测试并将覆盖率上传 Codecov。.github/workflows/frontend-ci.yaml 使用 Node 24通过install-run-rush.js install安装依赖、rush rebuild全量构建再以rush increment --action lint/style对变更文件做增量 lint 与样式检查并缓存 pnpm store 加速。.github/workflows/idl.yaml 则对所有 Thrift 文件逐一执行kitex -streamx语法校验确保任何 IDL 变更在合入前都是可生成的。此外semantic-pull-request.yaml强制 PR 标题符合 Conventional Commits 规范mysql-schema-check.yaml关注数据库 schema 变更的合规性。横切关注点Git Hookscommon/git-hooks/Git Hooks 由 Rush 统一管理包含pre-commit、commit-msg、pre-push、post-checkout、post-commit、post-merge六个钩子配合common/autoinstallers/下的rush-commitlint、rush-lint-staged等插件在本地提交阶段就完成提交信息规范检查与暂存区 lint-staged 校验与远端 CI 形成本地先拦截、远端再兜底的双重防线。具体接入与使用方式详见 CONTRIBUTING.md。小结架构约束即协作契约coze-loop 的架构价值不在于某一项技术选型而在于它把约束写进了目录结构与 CI后端domain ← infra的单向依赖、前端 Level 层级禁止反向引用、商业版/开源版差异只走 Adapter、生成代码禁止手改且必须入库、IDL 变更必须双端重新生成——每一条都能在源码与工作流中找到对应落地。理解了这套架构地图无论是新增一个业务模块、修改一个 Thrift 接口还是本地起一套 Docker Compose 环境都能沿着明确的边界行事而不至于破坏整体一致性。赞分享人工智能大模型AI Agent提示工程AI 评测可观测性后端前端【免费下载链接】coze-loopNext-generation AI Agent Optimization Platform: Cozeloop addresses challenges in AI agent development by providing full-lifecycle management capabilities from development, debugging, and evaluation to monitoring.项目地址https://gitcode.com/gh_mirrors/co/coze-loop点击查看免费下载相关推荐Yokai框架完整指南构建简单、模块化且可观测的Go后端应用Yokai框架完整指南构建简单、模块化且可观测的Go后端应用 Yokai是一个简单、模块化且可观测的Go框架专门用于构建生产级的后端应用程序。它让开发者能够OpenObserve架构演进从单体到分布式可观测性平台的完整指南OpenObserve架构演进从单体到分布式可观测性平台的完整指南 OpenObserve是一款高性能、低成本的可观测性平台作为Elasticsearch/可观测性日志分析指标监控链路追踪后端云原生终极指南如何用OpenObserve构建统一可观测性数据平台终极指南如何用OpenObserve构建统一可观测性数据平台 OpenObserve是一个高性能、低成本的可观测性平台作为Elasticsearch/Spl可观测性日志分析指标监控链路追踪后端云原生上一篇B站视频下载神器BilibiliDown 跨平台下载工具完全指南下一篇解锁FromSoftware游戏动画的创作密码DSAnimStudio深度探索创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考