Codex中转站配置核心：config.toml详解与协议网关实践

1. 项目概述：为什么 config.toml 是 Codex 接中转站的“心脏文件”

Codex 接中转站——这个说法在当前技术社区里已经不是新鲜词，但真正能把它跑通、调稳、用熟的人，远比想象中少。我接触过不下二十个团队，其中超过一半卡在第一步：config.toml 写不对。不是语法报错，而是服务启动了、日志看着正常、请求却像石沉大海——根本没进业务逻辑。后来发现，问题全出在 toml 文件里那几行看似简单的配置上。

核心关键词就三个：Codex、中转站、config.toml。Codex 在这里不是指 GitHub 的那个大模型 API，而是某开源 Agent 框架中定义的一套标准化通信协议规范，它规定了 Agent 如何注册、如何被发现、如何接收指令、如何返回结构化响应。而“中转站”，是实际部署时承担路由分发、协议转换、负载均衡、元数据注入等职责的中间服务层。AgentRouter 就是这类中转站的一个典型实现，它不处理业务逻辑，只做“交通指挥”——把来自不同入口（Webhook、MQTT、HTTP API）的原始请求，按规则翻译成 Codex 协议格式，再转发给后端真正的 Agent 实例；反过来，再把 Agent 返回的 Codex 响应，还原成调用方能理解的格式。

config.toml 就是 AgentRouter 的“操作手册+身份证明+交通图谱”三合一文件。它不光告诉 AgentRouter “我是谁”（服务名、监听地址）、“我听谁的”（上游接入点配置）、“我找谁干活”（下游 Agent 注册中心或直连列表），更关键的是定义了“怎么翻译”——即请求体字段映射、状态码转换规则、超时重试策略、鉴权头透传方式等。写错一行，整个链路就断在协议层；写漏一个字段，下游 Agent 收到的就是残缺请求，直接返回 400；写反一个布尔值，比如把enable_header_passthrough = false写成true，可能让敏感 token 泄露到不该去的地方。

适合谁看？如果你正在搭建一个支持多类型 Agent 协同工作的系统，或者需要把旧有服务快速接入 Codex 生态，又或者你刚接手一个跑着 AgentRouter 却总出诡异 502 的线上环境——这篇就是为你写的。它不讲抽象理论，只讲实操中每一行 toml 背后的真实含义、踩过的坑、以及为什么非得这么写。

2. 整体设计思路与方案选型解析：为什么是 TOML，而不是 YAML 或 JSON？

2.1 为什么 AgentRouter 选 TOML 作为主配置格式？

第一反应可能是：YAML 更流行，JSON 更通用，为啥非得用 TOML？这不是增加学习成本吗？我一开始也这么想，直到在某次灰度发布中，因为 YAML 的缩进空格多了一个，导致整个路由规则失效，排查了三小时才发现是编辑器自动把 Tab 换成了 4 个空格，而 YAML 解析器对缩进极其敏感。TOML 的优势，在真实运维场景里才真正凸显：

• 无缩进依赖，靠显式键名嵌套：[upstream.http]和[upstream.mqtt]这种写法，完全规避了缩进歧义。你用 Notepad++、Vim、甚至 Windows 记事本打开，只要键名拼写正确，结构就不会乱。
• 原生支持内联表和数组，表达力强：比如定义一组重试策略，retry = [{max_attempts = 3, backoff_ms = 100}, {max_attempts = 2, backoff_ms = 500}]，比 YAML 的序列化写法更紧凑，比 JSON 更易读。
• 注释友好，生产环境可维护性强：# 此处为 Webhook 入口，仅接受 application/json 格式这类注释，上线后依然保留在配置里，新同事接手时一眼就能懂上下文。而 JSON 不支持注释，YAML 的注释在某些解析库中还容易被意外丢弃。
• 解析性能高，启动快：TOML 解析器（如 go-toml）在 Go 生态中非常成熟，解析速度比 YAML 快 3~5 倍。AgentRouter 启动时需加载并校验全部配置，毫秒级的差异在微服务集群里就是可观的冷启动时间节省。

所以，这不是为了标新立异，而是基于“降低人为错误率”和“提升系统稳定性”的务实选择。当你面对的是一个要承载日均百万级请求的中转站时，配置格式的鲁棒性，本身就是 SLA 的一部分。

2.2 AgentRouter 的核心架构定位：它到底不做什么？

很多新手一上来就想让 AgentRouter 干太多活，结果配置越写越复杂，最后自己都看不懂。必须先划清边界：

• 它不负责 Agent 的生命周期管理：AgentRouter 不会去启停、监控、扩缩容你的 Agent 实例。它只管“找得到”和“连得上”。Agent 的注册，要么通过 Consul/Etcd 这类服务发现组件自动上报，要么靠静态配置列表硬编码。
• 它不处理业务逻辑的编排：你不能指望它像 Airflow 那样串起 A→B→C 三个 Agent。它的路由是单跳的：一个请求进来，根据规则匹配到一个目标 Agent，转发过去，拿回响应，结束。复杂的编排必须由上游服务（比如一个 Python 编写的调度器）来完成。
• 它不提供 UI 管理界面：所有配置变更，必须修改 config.toml 并重启（或触发热重载，这取决于版本）。没有后台管理页，没有点击式配置。这是为了极致的轻量和确定性——配置即代码，版本控制、灰度发布、回滚，全部走 GitOps 流程。

明白了这点，config.toml 的设计思路就清晰了：它只描述“连接关系”和“转换规则”，不掺杂任何业务语义。比如，你不会在里面看到business_logic = "order_processing"这样的字段，只会看到target_service = "order-agent-v2"和request_mapping = { "order_id" = "body.order_id", "user_token" = "header.X-User-Token" }。

2.3 为什么以 AgentRouter 为例？它代表了什么范式？

AgentRouter 不是一个孤立的工具，它是“协议网关化”这一架构演进趋势的典型载体。在传统微服务里，服务间调用是 HTTP/REST 或 gRPC，大家约定好接口文档就行。但当系统里混入了 LLM Agent、IoT 设备 Agent、甚至浏览器端 JS Agent 时，它们的通信协议五花八门：有的用 WebSocket 心跳保活，有的用 MQTT QoS1 发布，有的只认特定的 JSON Schema。Codex 就是试图统一这些“方言”的标准语。而 AgentRouter，就是那个站在门口的“翻译官”。

选择它作为例子，是因为它的配置结构极具代表性：

• 它有明确的上游（upstream）和下游（downstream）划分；
• 它必须处理协议转换（protocol translation）；
• 它天然需要路由规则（routing rules）来决定请求去向；
• 它对安全控制（security）有强要求（token 透传、签名验证）；
• 它的可观测性（observability）配置直接影响问题排查效率。

所以，吃透 AgentRouter 的 config.toml，等于掌握了绝大多数协议中转类服务的配置方法论。后面换成别的中转站，比如叫 ProxyX 或 GatewayZ，你只需要替换掉字段名，逻辑结构是相通的。

3. config.toml 核心字段逐行解析与实操要点

3.1 全局基础配置：service、logging、server

这是 config.toml 的“顶梁柱”，决定了 AgentRouter 自身的运行姿态。很多人只改了路由规则，忘了调这个，结果服务启动后根本连不上。

# [service] 区块：定义本服务的身份和元信息 [service] name = "agent-router-prod" # 服务名，必须全局唯一，注册到服务发现时用 version = "v1.8.3" # 版本号，用于灰度发布和指标打标 environment = "production" # 环境标识，影响日志级别和告警策略 # id 是自动生成的，无需手动填写，但要知道它由 name + hostname + timestamp 组合生成 # [logging] 区块：日志是线上问题的第一现场 [logging] level = "info" # 可选 debug/info/warn/error。生产环境严禁 debug，日志量爆炸 format = "json" # json 格式便于 ELK/Splunk 解析；text 格式适合本地调试 output = "/var/log/agent-router.log" # 必须是绝对路径，且确保 agent-router 进程有写权限 # 关键技巧：加一个 rotation 配置，避免单个日志文件过大 [logging.rotation] max_size = 100 # MB max_age = 7 # 天 max_backups = 5 # 保留几个历史文件 # [server] 区块：监听地址和基本行为 [server] http_addr = "0.0.0.0:8080" # 监听所有网卡的 8080 端口。测试环境可写 127.0.0.1:8080 grpc_addr = "0.0.0.0:9090" # gRPC 管理端口，用于健康检查和配置热更新（如果支持） read_timeout = "30s" # HTTP 读超时，必须大于下游 Agent 的最长处理时间 write_timeout = "60s" # HTTP 写超时，包含响应体传输时间 idle_timeout = "120s" # 空闲连接超时，防止大量 TIME_WAIT

提示：read_timeout和write_timeout是最容易被忽视的致命参数。我遇到过最典型的案例：下游 Agent 处理一个复杂订单要 45 秒，但read_timeout只设了 30 秒。结果 AgentRouter 在 30 秒时主动断开连接，Agent 却还在默默执行，最终返回结果时发现连接已关，只能打日志报错。此时上游调用方收到的是 504 Gateway Timeout，但 AgentRouter 日志里只有http: proxy error: context deadline exceeded，完全看不出是自己配置太短。务必根据你的 Agent SLA 来设定，留出至少 20% 的缓冲余量。

3.2 上游接入配置（upstream）：定义“谁可以调用我”

upstream 是请求的入口。AgentRouter 支持多种协议接入，但生产环境最常用的是 HTTP 和 MQTT。我们重点拆解这两个。

# [upstream] 区块：定义所有可能的请求来源 [upstream] # [upstream.http]：标准 Webhook 入口 [upstream.http] enabled = true # 路径前缀，所有 HTTP 请求必须以 /webhook/ 开头，否则 404 path_prefix = "/webhook/" # 支持的 Content-Type，严格校验，防垃圾请求 allowed_content_types = ["application/json", "application/x-www-form-urlencoded"] # 请求体大小限制，防止恶意大包打爆内存 max_body_size = "2MB" # 关键：认证方式。生产环境必须开启！ [upstream.http.auth] type = "bearer_token" # 可选：none / bearer_token / api_key / hmac # 如果是 bearer_token，指定从哪个 header 读取 token_header = "Authorization" # token 白名单，生产环境建议对接 Redis 或数据库动态校验，此处是静态示例 valid_tokens = ["prod-webhook-key-abc123", "prod-webhook-key-def456"] # [upstream.mqtt]：物联网设备常用入口 [upstream.mqtt] enabled = true broker_url = "tcp://mqtt-broker.internal:1883" client_id = "agent-router-mqtt-client" username = "router_user" password = "router_pass_2024" # 订阅的主题列表，支持通配符 # topics = ["device/+/status", "device/+/command"] # MQTT QoS 级别，QoS1 保证至少一次送达，QoS2 保证恰好一次，但延迟高 qos = 1 # MQTT 消息到 Codex 协议的映射规则，这是核心！ [upstream.mqtt.mapping] # 将 MQTT 主题中的 device_id 提取出来，作为 Codex 请求的 target_agent_id target_agent_id = "topic[1]" # device/{device_id}/status -> topic[1] = device_id # 将 MQTT payload 解析为 JSON，并映射到 Codex 的 request.body request_body = "json(payload)" # 添加固定元数据 [upstream.mqtt.mapping.metadata] source = "mqtt" protocol_version = "1.2"

注意：upstream.http.auth的valid_tokens在生产环境绝不能硬编码！这只是演示。真实做法是：type = "external"，然后配置一个auth_url = "http://auth-service/internal/validate"，AgentRouter 会把收到的 token 转发给这个 URL 做实时校验。这样 token 可以随时在 auth-service 里吊销，无需重启 AgentRouter。

3.3 下游目标配置（downstream）：定义“我要找谁干活”

downstream 是出口，决定了请求最终发给谁。AgentRouter 提供两种模式：服务发现（推荐）和静态列表（简单场景）。

# [downstream] 区块：定义所有可调用的 Agent 目标 [downstream] # [downstream.discovery]：通过服务发现动态获取 Agent 列表（生产首选） [downstream.discovery] enabled = true # 服务发现类型，Consul 是最常用的 type = "consul" address = "http://consul.internal:8500" # Agent 在 Consul 中注册的 service 名称前缀，AgentRouter 会查找所有匹配的服务 service_name_pattern = "codex-agent-*" # 健康检查间隔，Consul 会定期探活，AgentRouter 只用健康的实例 health_check_interval = "10s" # 缓存 TTL，避免每次请求都查 Consul，减轻其压力 cache_ttl = "30s" # [downstream.static]：静态 IP 列表，仅用于开发或极简场景 [downstream.static] enabled = false # 如果启用，下面的列表生效 [[downstream.static.targets]] name = "order-agent-dev" address = "http://10.0.1.10:8000" # Codex 协议版本，必须与 Agent 实现一致，否则解析失败 codex_version = "1.0" [[downstream.static.targets]] name = "user-agent-dev" address = "http://10.0.1.11:8000" codex_version = "1.0" # [downstream.load_balancing]：负载均衡策略，配合 discovery 使用 [downstream.load_balancing] # 可选：round_robin / least_conn / random / hash strategy = "round_robin" # hash 策略下，用哪个字段做 hash key？比如 user_id，保证同一用户总打到同一台 Agent hash_key = "request.body.user_id"

实操心得：Consul 的service_name_pattern务必设计好。我们曾用codex-agent作为 pattern，结果把一个叫codex-agent-metrics的监控服务也拉进来了，它不处理业务请求，导致大量 404。后来改成codex-agent-[a-z]+，用正则精确匹配。另外，cache_ttl不宜设得太长（比如 5 分钟），否则 Consul 里某个 Agent 挂了，AgentRouter 要等 5 分钟才感知到，期间请求全失败。

3.4 路由规则配置（routing）：定义“谁的请求该去哪”

这是 config.toml 的灵魂所在。没有它，AgentRouter 就是个哑巴。路由规则是数组，按顺序匹配，第一条命中即执行，后续规则不再检查。

# [routing] 区块：定义请求分发规则 [routing] # 规则 1：所有 /webhook/order/* 路径的请求，发给 order-agent [[routing.rules]] id = "route-to-order" # 匹配条件：必须同时满足所有条件 [routing.rules.match] # HTTP 方法和路径前缀 method = "POST" path = "^/webhook/order/.*$" # 正则匹配，注意转义 # 来源 IP 白名单，增强安全性 source_ip = ["192.168.10.0/24", "2001:db8::/32"] # 请求头中必须包含特定字段 headers = { "X-Service-Name" = "order-system" } # 执行动作：转发到哪个下游 [routing.rules.action] # target_type 决定了去哪里找目标：service（查 discovery）或 static（查 static 列表） target_type = "service" target_name = "codex-agent-order" # 超时设置，可覆盖全局 server.timeout timeout = "45s" # 重试策略，针对网络抖动 [routing.rules.action.retry] max_attempts = 2 backoff_ms = 500 # 规则 2：MQTT 主题为 device/+/command 的消息，发给 device-agent [[routing.rules]] id = "route-to-device" [routing.rules.match] # 匹配 upstream 类型 upstream = "mqtt" # 匹配 MQTT 主题 mqtt_topic = "^device/.+/command$" # 匹配 payload JSON 中的字段 json_path = "$.command_type" json_value = ["reboot", "update_firmware"] [routing.rules.action] target_type = "service" target_name = "codex-agent-device" timeout = "20s" # 规则 3：兜底规则，所有未匹配的请求，返回 400 [[routing.rules]] id = "fallback-400" [routing.rules.match] # match_all = true 表示无条件匹配 match_all = true [routing.rules.action] # action_type = "return" 表示不转发，直接返回 action_type = "return" status_code = 400 body = '{"error": "no matching route found"}'

关键细节：path和mqtt_topic都用正则，但写法有区别。HTTP 的path是完整路径（如/webhook/order/create），而 MQTT 的topic是主题字符串（如device/abc123/command）。json_path使用的是 JSONPath 语法，$.command_type表示取根对象下的command_type字段。json_value是一个数组，表示只要command_type的值是reboot或update_firmware就匹配。这种细粒度的条件组合，是实现精准路由的基础。

3.5 协议转换配置（translation）：定义“怎么把请求翻译过去”

这是 Codex 中转站最核心的价值。Codex 协议有严格的字段定义，而上游请求千奇百怪，translation 区块就是干这个“翻译”的。

# [translation] 区块：定义请求和响应的字段映射 [translation] # [translation.request]：上游请求 → Codex 请求 的映射 [translation.request] # Codex 标准字段：agent_id，指定要调用哪个 Agent 的能力 agent_id = "routing.rules.action.target_name" # Codex 标准字段：request_id，必须全局唯一，用于链路追踪 request_id = "uuid()" # 内置函数，生成 v4 UUID # Codex 标准字段：timestamp，时间戳，单位毫秒 timestamp = "now_ms()" # Codex 标准字段：body，核心业务数据，从上游提取 [translation.request.body] # 从 HTTP POST 的 JSON body 中提取 user_id = "json(body).user_id" order_items = "json(body).items" # 从 HTTP Header 中提取 user_token = "header(X-User-Token)" # 从 MQTT topic 中提取 device_id = "topic[1]" # 从 MQTT payload JSON 中提取 command = "json(payload).command" # 添加固定字段 [translation.request.body.metadata] source_upstream = "upstream.type" received_at = "now_iso8601()" # [translation.response]：Codex 响应 → 上游响应 的映射 [translation.response] # HTTP 响应状态码映射 [translation.response.status_code] # Codex 响应里的 status 字段值，映射到 HTTP 状态码 "success" = 200 "partial_success" = 206 "failure" = 500 "invalid_request" = 400 # HTTP 响应体映射 [translation.response.body] # 将 Codex 响应的 result 字段，直接作为 HTTP body 返回 result = "json(codex_response).result" # 将 Codex 响应的 error 字段，包装成标准错误格式 [translation.response.body.error] code = "json(codex_response).error.code" message = "json(codex_response).error.message" # 添加响应头 [translation.response.headers] X-Request-ID = "codex_response.request_id" X-Response-Time = "elapsed_ms()"

实操难点：translation.request.body的映射路径写错，是导致下游 Agent 收到空body的最常见原因。比如，上游是application/x-www-form-urlencoded，你写了json(body).user_id，那肯定取不到——因为body不是 JSON，是key=value&key2=value2格式。正确写法是form(body).user_id。AgentRouter 内置了json()、form()、xml()、query()等解析函数，必须根据upstream.http.allowed_content_types来选。我建议在开发环境，先用curl -v把上游请求打一遍，用logging.level = "debug"看 AgentRouter 的 debug 日志，里面会打印出它解析后的原始body结构，再据此写映射路径，事半功倍。

4. 完整实操流程与核心环节实现

4.1 从零开始：一份可直接运行的最小化 config.toml

别被上面的长篇大论吓住。我们从一个能跑起来的最小配置开始，逐步叠加功能。这是我在某次紧急上线时用的“保命模板”，删掉了所有非必要字段，只保留核心骨架。

# config.minimal.toml - 最小可运行配置 [service] name = "agent-router-minimal" version = "v1.0.0" environment = "development" [logging] level = "info" format = "text" output = "stdout" [server] http_addr = "0.0.0.0:8080" read_timeout = "30s" write_timeout = "60s" [upstream.http] enabled = true path_prefix = "/" allowed_content_types = ["application/json"] max_body_size = "1MB" [downstream.static] enabled = true [[downstream.static.targets]] name = "echo-agent" address = "http://localhost:8000" codex_version = "1.0" [routing.rules] id = "echo-all" [routing.rules.match] method = "POST" [routing.rules.action] target_type = "static" target_name = "echo-agent" timeout = "10s" [translation.request] agent_id = '"echo-agent"' request_id = "uuid()" timestamp = "now_ms()" [translation.request.body] raw_payload = "json(body)" [translation.response] [translation.response.status_code] "success" = 200 "failure" = 500 [translation.response.body] result = "json(codex_response).result"

操作步骤：

1. 新建文件config.minimal.toml，粘贴上面内容；
2. 启动一个简单的 echo Agent（比如用 Python Flask 写一个，监听 8000 端口，接收 Codex 格式 JSON，原样返回{"result": "echo: " + request.json.get("raw_payload")}）；
3. 启动 AgentRouter：./agent-router --config config.minimal.toml；
4. 发送测试请求：curl -X POST http://localhost:8080/ -H "Content-Type: application/json" -d '{"user_id": 123}'；
5. 观察 AgentRouter 控制台输出，应该能看到请求日志和转发成功的提示。

这个最小配置跑通了，证明你的 AgentRouter 二进制、网络、基础配置都没问题。接下来，才是往里面加功能。

4.2 加入服务发现：从 static 切换到 consul

假设你已经有了一个 Consul 集群，并且你的 Agent 已经按规范注册了。切换步骤如下：

1. 停掉 AgentRouter；
2. 修改 config.toml：
   • 将[downstream.static]的enabled = true改为false；
   • 将[downstream.discovery]的enabled = true；
   • 填写正确的address和service_name_pattern；
3. 验证 Consul 连通性：在 AgentRouter 服务器上执行curl http://consul.internal:8500/v1/health/service/codex-agent-order，确认能返回健康实例列表；
4. 启动 AgentRouter，观察日志。正常情况下，你会看到类似discovery: found 3 healthy instances for codex-agent-order的日志；
5. 发送请求测试，确认路由成功。

注意事项：Consul 的 ACL（访问控制列表）经常是坑。如果 AgentRouter 启动后日志里一直报failed to query consul: permission denied，大概率是它用的 token 没有service:read权限。去 Consul ACL 管理页，给这个 token 加上对应 policy 即可。另外，service_name_pattern必须和 Agent 注册时的Service.Name完全一致，包括大小写和特殊字符。

4.3 实现复杂路由：基于请求内容的动态分发

现在，我们让路由规则更智能。假设你有一个user-agent，它有两个版本：user-agent-v1（处理老用户）和user-agent-v2（处理新用户，ID 为 10000 以上）。我们需要根据user_id动态选择。

[[routing.rules]] id = "route-to-user-v1" [routing.rules.match] method = "POST" path = "^/webhook/user/.*$" # 使用 json_path 提取 user_id，并判断是否小于 10000 json_path = "$.user_id" json_value = "lt(10000)" # lt 是内置比较函数 [routing.rules.action] target_type = "service" target_name = "codex-agent-user-v1" timeout = "15s" [[routing.rules]] id = "route-to-user-v2" [routing.rules.match] method = "POST" path = "^/webhook/user/.*$" json_path = "$.user_id" json_value = "ge(10000)" # ge 是大于等于 [routing.rules.action] target_type = "service" target_name = "codex-agent-user-v2" timeout = "15s"

关键技巧：json_value字段支持多种内置函数，不只是lt/ge。还有in(["a","b"])、regex("^prefix.*")、exists("$.field")等。你可以把复杂的判断逻辑，封装成一个函数调用，而不是在 toml 里写一堆嵌套的 if-else。这大大提升了配置的可读性和可维护性。实测下来，用json_value = "in([\"vip\",\"premium\"])"来匹配会员等级，比写正则^vip$|^premium$清晰得多。

4.4 配置热重载：如何不重启服务更新路由规则

频繁重启 AgentRouter 在生产环境是不可接受的。幸运的是，较新版本的 AgentRouter 支持通过 gRPC 端口推送新配置，实现热重载。

1. 确保server.grpc_addr已启用（如0.0.0.0:9090）；
2. 编写一个简单的配置推送脚本（Python 示例）：

   import grpc import agent_router_pb2 import agent_router_pb2_grpc channel = grpc.insecure_channel('localhost:9090') stub = agent_router_pb2_grpc.ConfigServiceStub(channel) # 读取新的 config.toml 内容 with open('config.new.toml', 'r') as f: new_config = f.read() # 调用 gRPC 接口 response = stub.ReloadConfig(agent_router_pb2.ReloadRequest(config=new_config)) print(response.message) # 应该是 "success"

3. 将此脚本集成到你的 CI/CD 流程中，每次配置变更，自动触发推送。

注意：热重载不是万能的。它只重新加载routing.rules、translation等运行时配置。像server.http_addr、logging.output这类影响进程基础行为的配置，仍然需要重启。所以，规划配置时，要把“静态”和“动态”部分分开。server和logging属于静态，routing和translation属于动态。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的三个深坑与独家避坑技巧

坑一：path_prefix的双重作用被忽略

upstream.http.path_prefix不仅用于路由匹配，还用于剥离前缀后再交给 translation 处理。比如，你设了path_prefix = "/webhook/"，那么一个请求POST /webhook/order/create，在translation.request里看到的path是/order/create，而不是/webhook/order/create。很多新手在写routing.rules.match.path时，还带着/webhook/，结果永远匹配不上。

避坑技巧：在routing.rules.match.path中，永远写剥离path_prefix后的路径。如果path_prefix = "/api/v1/"，那么匹配订单的正则应该是^/order/.*$，而不是^/api/v1/order/.*$。可以在 debug 日志里搜索matched path字段，确认 AgentRouter 解析出的路径是什么。

坑二：header函数的大小写陷阱

header(X-User-Token)能取到值，但header(x-user-token)就取不到。HTTP Header 名是大小写不敏感的，但 AgentRouter 的header()函数是大小写敏感的。这是因为底层解析库为了性能，做了简单字符串匹配，没做 case-insensitive 转换。