mat （my-ai-team） 的 backends.json：一个订阅，拆出一整支 AI 团队
my-ai-team 使用backends.json来管理所有的worker。每个worker有一个nick，这个nick用来确认使用哪个agent，什么方式授权，哪个模型，多大思考深度，以及使用多大的context window。
它的基本设计原则是：secret使用元数据，不放具体值——auth_var 只存环境变量名，真正用到的值由 launcher 从 ~/.bashrc.secret 读取。
这个设计里我最得意的一点，是同一个订阅可以拆成多个 worker。model 和 effort level 都是启动时通过命令行传给 agent 的，所以多个 nickname 可以共用同一个 config_dir，而 model 和 thinking level，以及context window size则可以随心设置。（这里config_dir的值只是agent config home的目录前缀，不同角色会缀在这个config_dir后面，最终得到如claude-dev，claude-plan这样的目录名，以确保不同角色拥有独一无二的system prompt 不会串），请看下面这个例子片段：
{
"backends": [
{
"nickname": "claude",
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "medium",
"context_window_size": "256k",
"default_model": "opus[1m]"
},
{
"nickname": "sonneth",
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "high",
"context_window_size": "256k",
"default_model": "sonnet[1m]"
},
{
"nickname": "opus48“,
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "high",
"context_window_size": "256k",
"default_model": "claude-opus-4-8[1m]"
}
...
]
}
三个 worker 共用 claudew 的登录和 CLAUDE.md，但分别是 opus/medium、sonnet/high、opus-4-8/high——一个订阅，按任务贵贱分配算力：日常活给 sonnet，重活给 opus，探索给低 effort。
主动控制上下文窗口：同样的订阅，更经用
1M 长上下文的模型有个陷阱：任务稍大就轻松突破 400k，账单随之激增——token 额度在不知不觉中被快速烧掉。
mat 的解法是 context_window_size 字段，每个 worker 声明自己的有效窗口。
launcher 在启动时把它翻译成各家族的原生机制——Claude 的 CLAUDE_CODE_AUTO_COMPACT_WINDOW、Codex 的 model_auto_compact_token_limit、OpenCode 的 per-model limit override——在窗口触顶前主动压缩，而不是放任它涨到 1M 上限。256k 的活就只付 256k 的钱。
我的配置里几乎每个条目都带着 "context_window_size": "256k"，用1m能力的模型，但主动把context_window_size 压到 256k——一行配置，把"能力上限"和"成本上限"分开声明。任务再大也在 256k 处主动压缩，而不是一路涨到 1M 才收手。
配合独立审核，效果叠加：Reviewer 不需要重读全部上下文，它的窗口压力被审核机制本身缓解。综合下来：
- 质量仍然有保证 — 独立审核把关
- 同样的订阅更经用 — 主动压缩节省成本
- 产出更多 — 省下的token能有效完成更多轮次、更多任务
其他特点：一个配置管理所有agent家族（claude/codex/copilot/pi/opencode/grok）、tier 门禁（weak 后端被 explore/audit 拒绝，防止便宜模型产出烂 ticket）。
我自己的实际配置：40+ 后端，一个claude max订阅就可以有七八个worker( nickname)，如sonnetl, sonnetm, sonneth, opusl, opusm, opush, opus48等(l/m/h 表示effort）。
更多文档见 mat-docs.shukelabs.com 现在购买首年五折。如果你有更好的想法和建议，欢迎评论或者私信。谢谢！
my-ai-team 使用backends.json来管理所有的worker。每个worker有一个nick，这个nick用来确认使用哪个agent，什么方式授权，哪个模型，多大思考深度，以及使用多大的context window。
它的基本设计原则是：secret使用元数据，不放具体值——auth_var 只存环境变量名，真正用到的值由 launcher 从 ~/.bashrc.secret 读取。
这个设计里我最得意的一点，是同一个订阅可以拆成多个 worker。model 和 effort level 都是启动时通过命令行传给 agent 的，所以多个 nickname 可以共用同一个 config_dir，而 model 和 thinking level，以及context window size则可以随心设置。（这里config_dir的值只是agent config home的目录前缀，不同角色会缀在这个config_dir后面，最终得到如claude-dev，claude-plan这样的目录名，以确保不同角色拥有独一无二的system prompt 不会串），请看下面这个例子片段：
{
"backends": [
{
"nickname": "claude",
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "medium",
"context_window_size": "256k",
"default_model": "opus[1m]"
},
{
"nickname": "sonneth",
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "high",
"context_window_size": "256k",
"default_model": "sonnet[1m]"
},
{
"nickname": "opus48“,
"config_dir": "claudew",
"auth_var": "CLAUDE_CODE_OAUTH_TOKEN_CCW",
"prompt_file": "CLAUDE.md",
"kind": "claude",
"default_effort": "high",
"context_window_size": "256k",
"default_model": "claude-opus-4-8[1m]"
}
...
]
}
三个 worker 共用 claudew 的登录和 CLAUDE.md，但分别是 opus/medium、sonnet/high、opus-4-8/high——一个订阅，按任务贵贱分配算力：日常活给 sonnet，重活给 opus，探索给低 effort。
主动控制上下文窗口：同样的订阅，更经用
1M 长上下文的模型有个陷阱：任务稍大就轻松突破 400k，账单随之激增——token 额度在不知不觉中被快速烧掉。
mat 的解法是 context_window_size 字段，每个 worker 声明自己的有效窗口。
launcher 在启动时把它翻译成各家族的原生机制——Claude 的 CLAUDE_CODE_AUTO_COMPACT_WINDOW、Codex 的 model_auto_compact_token_limit、OpenCode 的 per-model limit override——在窗口触顶前主动压缩，而不是放任它涨到 1M 上限。256k 的活就只付 256k 的钱。
我的配置里几乎每个条目都带着 "context_window_size": "256k"，用1m能力的模型，但主动把context_window_size 压到 256k——一行配置，把"能力上限"和"成本上限"分开声明。任务再大也在 256k 处主动压缩，而不是一路涨到 1M 才收手。
配合独立审核，效果叠加：Reviewer 不需要重读全部上下文，它的窗口压力被审核机制本身缓解。综合下来：
- 质量仍然有保证 — 独立审核把关
- 同样的订阅更经用 — 主动压缩节省成本
- 产出更多 — 省下的token能有效完成更多轮次、更多任务
其他特点：一个配置管理所有agent家族（claude/codex/copilot/pi/opencode/grok）、tier 门禁（weak 后端被 explore/audit 拒绝，防止便宜模型产出烂 ticket）。
我自己的实际配置：40+ 后端，一个claude max订阅就可以有七八个worker( nickname)，如sonnetl, sonnetm, sonneth, opusl, opusm, opush, opus48等(l/m/h 表示effort）。
更多文档见 mat-docs.shukelabs.com 现在购买首年五折。如果你有更好的想法和建议，欢迎评论或者私信。谢谢！
