stdlib only
内核零外部依赖。
9 个稳定根只 import Go 标准库。没有传递依赖风险，没有被迫升级，你的 module graph 里不会引入任何版本冲突。
go get github.com/spcent/plumego 单一 import 路径，无依赖树 stdlib only · 零外部依赖 · v1.1.0
AI agent 和你的团队都能读懂的 Go HTTP 框架。
路由注册、中间件顺序和依赖装配全在一个显式文件里——每次代码评审都能直接看到。机器可读规范给 AI 编程助手和资深评审者提供同一套操作模型。兼容 net/http：现有 handler 无需修改即可接入。
cd reference/standard-service && go run . or go get github.com/spcent/plumego@latest func (a *App) Routes() http.Handler {
r := router.New()
// middleware order is explicit, not hidden
r.Use(middleware.RequestID)
r.Use(middleware.Logger(a.log))
// route ownership visible in one file
api := r.Group("/api/v1",
middleware.Auth(a.cfg.JWTSecret))
api.Get("/users/:id", a.users.Get)
api.Post("/users", a.users.Create)
api.Get("/items", a.items.List)
return r
}显式 wiring
每条路由在一个文件里，每次评审可见。
路由注册、中间件顺序和依赖装配全在 internal/app/routes.go 里。评审者无需打开任何包就能看到完整请求地图。
func (a *App) Routes() http.Handler { … } 所有路由在一处声明 Agent-ready
机器可读规范引导每一次变更。
specs/task-routing.yaml 在写下第一行代码前就把工作路由到正确模块。specs/dependency-rules.yaml 在 CI 中执行边界约束。Agent 和人共享同一套操作模型。
specs/ · tasks/ · module.yaml 人与 Agent 均可读取的控制平面 Agent-ready
为现代团队的工作方式而生。
本节讨论的是 AI 编码助手——Copilot、Claude、Cursor——帮助写代码或评审代码的工具。这不是关于构建 AI agent 服务的内容；那是 x/ai 模块的范围。
当 AI 编程助手承担越来越多的执行工作时，关键问题变成了：你的仓库是否给了它们清晰的操作模型——还是让它们猜测？Plumego 的控制平面给 Agent 提供了资深评审者同样的路由信号。
specs/task-routing.yaml 任务路由 将工作类型映射到归属模块。Agent 在写任何代码前先读这份文件。
specs/dependency-rules.yaml 边界执行 import 违规由机器捕获，不依赖评审者的记忆。
<module>/module.yaml 模块级 scope 每个模块自声明检查命令。Agent 只运行相关的验证。
选择一个场景，看看它会路由到哪里
为 HTTP 端点添加限流
路由规则
middleware 归属模块
middleware/ 原因 传输层横切关注点，不需要引入 x/* 模块。稳定根完全可以处理。
两分钟内跑起来。
安装，写一个 handler，运行。完整的 canonical 服务结构见 reference/standard-service 。
package main
import (
"log"
"net/http"
"github.com/spcent/plumego/contract"
"github.com/spcent/plumego/core"
plog "github.com/spcent/plumego/log"
)
func main() {
app := core.New(core.DefaultConfig(),
core.AppDependencies{Logger: plog.NewLogger()})
if err := app.Get("/ping", http.HandlerFunc(
func(w http.ResponseWriter, r *http.Request) {
if err := contract.WriteResponse(w, r,
http.StatusOK,
map[string]string{"status": "ok"}, nil); err != nil {
log.Printf("write: %v", err)
}
})); err != nil {
log.Fatal(err)
}
if err := app.Prepare(); err != nil {
log.Fatal(err)
}
srv, err := app.Server()
if err != nil {
log.Fatal(err)
}
log.Println("listening on :8080")
srv.ListenAndServe()
}$ go mod init myservice
$ go get github.com/spcent/plumego@latest
$ go run .
$ curl localhost:8080/ping
{"data": {"status": "ok"}}预期响应
从哪里开始
下一步去哪里。
先评估适用性，再深入技术细节。在模块总览中找到合适的 x/* 家族。看看 Plumego 与 Gin、Echo、Chi 的横向对比。
fit
为什么选择 Plumego
当问题是 Plumego 是否适合你的团队、服务形态和评审预期——而不是技术细节时，从这里开始。
判断是否适合 →agent-first
Agent 工作流
了解机器可读规范如何在写代码前就把 AI 助手路由到正确模块，在 CI 中执行边界约束，与人工评审者共享同一套操作模型。
查看 Agent 模型 →extensions
x/* 扩展家族
按成熟度层级浏览所有 x/* 能力家族。7 个 API 冻结的 beta 家族，加上用于产品能力工作的实验性家族。
浏览扩展家族 →comparison
框架横向对比
Gin、Echo、Fiber、Chi 与 Plumego 的 handler 签名、响应 contract、stdlib 兼容性、迁移成本与基准数据，诚实并列呈现。
查看对比 →