A Journal Through My Activities, Thoughts, and Notes
我如何用平庸模型轻松写出优质软件 -- 把好输入质量关
首先要自吹一把，我有经验。我非常懂古法编程。从2004年成为专职程序员，我对如何产出高质量的代码烂熟于心。my-ai-team只是把这些经验自动化应用到干活的agent身上。
我没有pro订阅。就是有，我也不会让fable/asta 去做delivery agent。好钢要用到刀刃上。我确实有fable可以用。公司提供给我的claude可以用Fable。但我仅用它来诊断架构层面的缺陷，或者让它找出当前系统里最值得改进的n个点来开票，一般是在7d reset临近，但我额度剩余还比较多的时候。
真正的delivery agent我用 gpt-5.6-luna，effort level我甚至不用开到max, xhigh已经很够用了。“你在吹牛B吧”，真不是。因为我的my-ai-team具备化“腐朽”为神奇的超能力。
说人家5.6-luna是“平庸”模型纯粹调侃。人家是便宜，不够卓越，但人家真不是垃圾。发挥稳定，皮实耐用。我两个企业seat（我年付，两个seat月NZ$66）账号，再加上我的z.ai订阅，minimax年订阅，还有freebuff的免费token加持，我的my-ai-team基本上能做到一周7天24小时干活不缺token。我可不是开一个两个agent，同时十几个agent干活是常态。看看这是我一台机器上的agent。我有n台机器都在跑my-ai-team。但这台是最heavy的。一台2020年老xps，32G内存。上面还跑一着一个windows虚拟机和一个github runner。
!图一
接下来我要分享的是干货。平庸模型如何稳定产出优质代码？
TLDR; 非要一句话来说的话，那就是我，或者说我开发的my-ai-team，从源头上保证了质量。
在my-ai-team里， delivery agent面对的不是一个个模糊的需求，“帮我修这个bug”，“帮我实现这个”。你不能要求这种输入给你好的结果，一击而中？就是中了你也不知道是如何中的，后面又如何维护？
大家Vibe 知道prompt的重要性，你的prompt越含糊，AI的发挥余地越大，输出结果就越不可控，更有可能烧了token却收获一肚子气。其实人与人交流又何尝不是如此呢？做为程序员，都愿意做需求描述一清二楚，验收条款明明白的票。Agent也是如此。
在my-ai-team里，你最重要的工作就是和 explorer agent“聊天”（输入），而explorer负责澄清你含糊的要求，确认当前的代码基础，找到真正可行的解决方案或者bug根因，最后输出一张或多张高质量的票。这些票是delivery agent的输入。这一步高质量地完成了，delivery agent只是按图索骥，因此不需要那么牛的模型。其实我大部分票也是和luna，glm5.3聊出来的。这引出了另一件重要的的输入，宪法 -- 也就是系统prompt。为什么explorer能写出好票，我和普通的claude，codex聊不也一样吗？不一样。因为普通的cluade/codex的内置system prompt为适应各种各样的任务，只能设置一些很常规很普遍的要求。术业有专攻，如果我们希望这个agent能开好票，那就要在宪法里提要求，并配合必要的hooks来确保这个agent遵守了这些要求。
!image
delivery agent拿到票的第一步，是做计划。票已经很高的质量，计划做起来就会容易，但容易的事情并不总是容易做好。agent也会有遗漏，也会有误判。这时独立Reviewer的价值就出来了。
计划是实现的输入，计划的质量决定实现的质量。让做计划的人自己审核计划，不是不行。这跟让球员同时当裁判的效果差不多。独立Reviewer拿一本确保自己能做好Review工作的宪法，它总是用挑剔的眼光审查计划。它有自己的检查清单，它有自己独立的判断标准。好，经过几轮碰撞，计划过关了。
现在输入到developer agent来做实现了。实现是PR的输入。Developer有自己的宪法，按照宪法原则照计划行事，不能少做，也不允许擅自扩大范围。但允许顺手修掉自己工作范围的小bug。“勿以善小而不为”是我写到每个agent宪法里的一句话。实现完了，同样有专门的勾子提醒它按照一份清单做自我批评。测试都通过了吗？这次是治表还是治里？开发者自己满意了，这才把建好的PR交到同一个独立Reviewer手里。这个Reviewer的上下文里只有审核通过的计划，接着审核实现再合适不过。即使developer声称测试都通过了，Reviewer也再要独立验证。除了本地测试，还要检查CI是红是绿。发现任何must fix都要打回Developer再来一轮。功能实现正确了，CI也是绿的，Reviewer也没有发现其他必改的缺陷，这时候才是自动合并PR的时机。完了吗？还没有。合并完PR的同时，my-ai-team会自动通知值班的auditor agent。auditor agent负责审查合并的代码，再多一双眼睛检查是否引入了新的缺陷。如果有所发现就会开票。如果缺陷严重，还会主动标priority:high。
这就是我用"平庸"模型写出高质量软件的"秘密"。根本没有秘密，只有好的实践。my-ai-team正在促销，首年年费5折，欢迎订阅。 mat-docs.shukelabs.com 只要$49.99，my-ai-team就会成为你的ai team。支持claude code, github copilot, codx, pi, opencode, grok, freebuff 以及 command code。一人公司也不必非要忙得昏天黑地，一人公司同样可以拥有高质量的生活。祝大家vibe愉快！写出好的作品，造福全人类。
我后面会分享my-ai-team里explorer的最新版本的宪法以及我们用到的skill给大家。太太喊我吃饭，就先写到这里。
首先要自吹一把，我有经验。我非常懂古法编程。从2004年成为专职程序员，我对如何产出高质量的代码烂熟于心。my-ai-team只是把这些经验自动化应用到干活的agent身上。
我没有pro订阅。就是有，我也不会让fable/asta 去做delivery agent。好钢要用到刀刃上。我确实有fable可以用。公司提供给我的claude可以用Fable。但我仅用它来诊断架构层面的缺陷，或者让它找出当前系统里最值得改进的n个点来开票，一般是在7d reset临近，但我额度剩余还比较多的时候。
真正的delivery agent我用 gpt-5.6-luna，effort level我甚至不用开到max, xhigh已经很够用了。“你在吹牛B吧”，真不是。因为我的my-ai-team具备化“腐朽”为神奇的超能力。
说人家5.6-luna是“平庸”模型纯粹调侃。人家是便宜，不够卓越，但人家真不是垃圾。发挥稳定，皮实耐用。我两个企业seat（我年付，两个seat月NZ$66）账号，再加上我的z.ai订阅，minimax年订阅，还有freebuff的免费token加持，我的my-ai-team基本上能做到一周7天24小时干活不缺token。我可不是开一个两个agent，同时十几个agent干活是常态。看看这是我一台机器上的agent。我有n台机器都在跑my-ai-team。但这台是最heavy的。一台2020年老xps，32G内存。上面还跑一着一个windows虚拟机和一个github runner。
!图一
接下来我要分享的是干货。平庸模型如何稳定产出优质代码？
TLDR; 非要一句话来说的话，那就是我，或者说我开发的my-ai-team，从源头上保证了质量。
在my-ai-team里， delivery agent面对的不是一个个模糊的需求，“帮我修这个bug”，“帮我实现这个”。你不能要求这种输入给你好的结果，一击而中？就是中了你也不知道是如何中的，后面又如何维护？
大家Vibe 知道prompt的重要性，你的prompt越含糊，AI的发挥余地越大，输出结果就越不可控，更有可能烧了token却收获一肚子气。其实人与人交流又何尝不是如此呢？做为程序员，都愿意做需求描述一清二楚，验收条款明明白的票。Agent也是如此。
在my-ai-team里，你最重要的工作就是和 explorer agent“聊天”（输入），而explorer负责澄清你含糊的要求，确认当前的代码基础，找到真正可行的解决方案或者bug根因，最后输出一张或多张高质量的票。这些票是delivery agent的输入。这一步高质量地完成了，delivery agent只是按图索骥，因此不需要那么牛的模型。其实我大部分票也是和luna，glm5.3聊出来的。这引出了另一件重要的的输入，宪法 -- 也就是系统prompt。为什么explorer能写出好票，我和普通的claude，codex聊不也一样吗？不一样。因为普通的cluade/codex的内置system prompt为适应各种各样的任务，只能设置一些很常规很普遍的要求。术业有专攻，如果我们希望这个agent能开好票，那就要在宪法里提要求，并配合必要的hooks来确保这个agent遵守了这些要求。
!image
delivery agent拿到票的第一步，是做计划。票已经很高的质量，计划做起来就会容易，但容易的事情并不总是容易做好。agent也会有遗漏，也会有误判。这时独立Reviewer的价值就出来了。
计划是实现的输入，计划的质量决定实现的质量。让做计划的人自己审核计划，不是不行。这跟让球员同时当裁判的效果差不多。独立Reviewer拿一本确保自己能做好Review工作的宪法，它总是用挑剔的眼光审查计划。它有自己的检查清单，它有自己独立的判断标准。好，经过几轮碰撞，计划过关了。
现在输入到developer agent来做实现了。实现是PR的输入。Developer有自己的宪法，按照宪法原则照计划行事，不能少做，也不允许擅自扩大范围。但允许顺手修掉自己工作范围的小bug。“勿以善小而不为”是我写到每个agent宪法里的一句话。实现完了，同样有专门的勾子提醒它按照一份清单做自我批评。测试都通过了吗？这次是治表还是治里？开发者自己满意了，这才把建好的PR交到同一个独立Reviewer手里。这个Reviewer的上下文里只有审核通过的计划，接着审核实现再合适不过。即使developer声称测试都通过了，Reviewer也再要独立验证。除了本地测试，还要检查CI是红是绿。发现任何must fix都要打回Developer再来一轮。功能实现正确了，CI也是绿的，Reviewer也没有发现其他必改的缺陷，这时候才是自动合并PR的时机。完了吗？还没有。合并完PR的同时，my-ai-team会自动通知值班的auditor agent。auditor agent负责审查合并的代码，再多一双眼睛检查是否引入了新的缺陷。如果有所发现就会开票。如果缺陷严重，还会主动标priority:high。
这就是我用"平庸"模型写出高质量软件的"秘密"。根本没有秘密，只有好的实践。my-ai-team正在促销，首年年费5折，欢迎订阅。 mat-docs.shukelabs.com 只要$49.99，my-ai-team就会成为你的ai team。支持claude code, github copilot, codx, pi, opencode, grok, freebuff 以及 command code。一人公司也不必非要忙得昏天黑地，一人公司同样可以拥有高质量的生活。祝大家vibe愉快！写出好的作品，造福全人类。
我后面会分享my-ai-team里explorer的最新版本的宪法以及我们用到的skill给大家。太太喊我吃饭，就先写到这里。
freebuff这么好的免费资源，一天20个小时的glm-5.3-flash，几乎就是不限量的token供应了，只需要一个美国IP就能用上。后面肯定会收紧，趁着能用就赶紧用！
用我的邀请链接注册还有其他奖励。
!image
<https://freebuff.com/get-started?ref=ref-c8c6249a-6878-40c2-abe9-05563bfaa795&referrer=David+Wei>
用我的邀请链接注册还有其他奖励。
!image
<https://freebuff.com/get-started?ref=ref-c8c6249a-6878-40c2-abe9-05563bfaa795&referrer=David+Wei>
搞了一个goat $1 月套餐，只是想试试整合command code 进my-ai-team。意外的发现即使是这个$1试水的计划，他们提供~~不限量~~(想多了，是每天100次CALL)的 LongCat 2.0模型。
让longcat 调查了一下整合command code 进my-ai-team的可行性，发现它智商相当在线。把command code整合进来...没准longcat可以是很好的worker。
让longcat 调查了一下整合command code 进my-ai-team的可行性，发现它智商相当在线。把command code整合进来...没准longcat可以是很好的worker。
my-ai-team now gets its own twitter account. <https://x.com/youraiteam>
新版本修了啥bug，改进了什么，加了砍了啥feature都会自动发布在这里。题图是 ChatGPT images生成的，你别说，它表达出了我想表达的。
我都没用啥提示词儿，我只是说，这个账号还缺个 banner。
新版本修了啥bug，改进了什么，加了砍了啥feature都会自动发布在这里。题图是 ChatGPT images生成的，你别说，它表达出了我想表达的。
我都没用啥提示词儿，我只是说，这个账号还缺个 banner。
是我一个人的错觉吗？dsv4.1f简直活成了opus5的模样。更快的opus5，但不靠谱劲儿也学过来了。我还是怀念初版dsv4f。
ta超过了dsv4pro？完全没感觉出来。高期待落空了。我换换别家的再看看，至少freebuff这个deepseek v4.1 flash给我的感觉更多是花拳绣腿。
ta超过了dsv4pro？完全没感觉出来。高期待落空了。我换换别家的再看看，至少freebuff这个deepseek v4.1 flash给我的感觉更多是花拳绣腿。
#mat 关于my-ai-team里各agent宪法的体积，我的意见是，多写什么场景下做什么，少解释或者不解释。模型越来越聪明，看到你的要求ta就知道你肚里的小九九，不必解释。并不意外，宪法文本也是agent写的。宪法需要修订时，我们同样走开票交付的流程，因为我们有很多测试用例要确保某些文本一定在宪法里。如果冲动手改，很容易把CI搞红。
当我留意到宪法体积开始膨胀时，我为各agent的宪法尺寸定了一个参考上限（留了余量），并在项目文档里约定，没有靠谱的理由，就不要调整上限。但接到新需求时，agent总能找到各种理由提高上限。当我留意到宪法尺寸一涨再涨时，我坐不住了。我和一个explorer agent敲定了一个相对合理的新上限 15k，这是一个硬上限。“如果宪法确实需要加字，那就同时必须从其他地方减字，不这样做，我们给每个agent的宪法就会厚成一本书。”
直到今天，这个限制依然在，依然是硬限制。15k，可以更短，但不可以更长。宪法确实时常有变更，很多时候是加内容，但我们也总能找到可以精炼的其他地方。
当我留意到宪法体积开始膨胀时，我为各agent的宪法尺寸定了一个参考上限（留了余量），并在项目文档里约定，没有靠谱的理由，就不要调整上限。但接到新需求时，agent总能找到各种理由提高上限。当我留意到宪法尺寸一涨再涨时，我坐不住了。我和一个explorer agent敲定了一个相对合理的新上限 15k，这是一个硬上限。“如果宪法确实需要加字，那就同时必须从其他地方减字，不这样做，我们给每个agent的宪法就会厚成一本书。”
直到今天，这个限制依然在，依然是硬限制。15k，可以更短，但不可以更长。宪法确实时常有变更，很多时候是加内容，但我们也总能找到可以精炼的其他地方。
联合国一个机构说，气候变迁已过临界点人类凭自己这点力量无法挽回。但人类已经整出了硅基智慧，虽然目前还很脆，但在人类灭绝之前，还是有希望由硅基智能体延续文明。
有好多网友希望搞快点，是希望亲身看到人类的毁灭和机器人的崛起吗？这么一想真是激动，连我也期待起来了。😄
有好多网友希望搞快点，是希望亲身看到人类的毁灭和机器人的崛起吗？这么一想真是激动，连我也期待起来了。😄
#mat 前面我介绍过my-ai-team里的explorer agent，ta是专门负责开票的。今天我来简要介绍下my-ai-team里的delivery team：
最早实现的delivery mode是 team。team 模式有三个独立的agent协同工作，它的使用方式是 team dev, plan, review 。至于顺序为什么是这样，并没有特别的理由，只是我当初划分tmux pane时把dev放进了第一个位置，palnner做到了并列的第二个位置，而把reviewer 放到了下面位置。
所有参数都可以省略。如果没有参数，三个实例都是默认的claude实例。如果提供一个参数，如pi, 则三个角色就都由pi来承担。如果提供两个参数，则第一个实例是developer, 后面角色的两个实例都是第二个参数定义的agent。如果你不怕麻烦，把三个写全当然系统也不会抱怨。其实写两个参数会有两种不同的解释，因为team a b 可以理解为 team a b b （正确） 也可以理解为 team a a b（错误），但写完整三个就铁定没有歧义了。
https://x.com/shukebeta/status/2097842135278231740?s=20
但windows下的tmux 支持是垃圾，而我工作的场合只能用windows。这催生了adhoc 模式的诞生。adhoc是一个agent打天下，它的宪法最复杂，因为它只有一个agent的上下文空间，却要做原本分派给三个agent做的事。为了保证质量，事先的做计划和事后的review，还有实现计划本身都是它一个实例承担。它仍然能自主工作，但产出的质量多少会打折扣 -- 因为到最后的 review 阶段，上下文已经被实现过程的有用没用的内容几乎占满了——试错、失败的测试、调试输出等等。当然my-ai-team在adhoc的宪法里也要求独立的工作包括最后的审查尽量派独立的sub agent去做，来减轻上下文压力，不过任务规模稍大，在一个delivery loop难免还是会一次甚至多次的上下文自动压缩发生。
Apple 刚刚发布了duo 手机。巧的是，在my-ai-team里，我最爱用的delivery 命令也叫 duo。让Planner, Developer和Reviewer 都是有独立上下文的agent的team 模式固然好，但烧起token来也是最快的。毕竟三方都要对同一个仓库做调查，同样的知识以不同的角度填充三个agent的上下文。因此在team模式诞生之后不久，我就添加了duo模式。
除了team（planner / dev / reviewer）模式最烧token的缺点之外，Planner辛苦制定了计划，但是在 plan 被Reviewer 批准之后它就没事了 -- 全程坐冷板凳——最懂怎么实现的人（planner写了计划，最懂怎么实现）却被换下场让我心有不甘；因此就有了duo模式。
duo命令接受两个参数，两个agent的分工原则是创作和审查。plan 和 dev 都是创作者（做计划和实现计划），两角合一；reviewer是审查者，它必须独立。于是
那 my-ai-team的delivery team今天就介绍到这里。 mat-docs.shukelabs.com 有更多文档。今天购买my-ai-team 享受五折优惠（折扣码50OFF），如果心动那就试试，反正不满意十五天内还有全额退款。
最早实现的delivery mode是 team。team 模式有三个独立的agent协同工作，它的使用方式是 team dev, plan, review 。至于顺序为什么是这样，并没有特别的理由，只是我当初划分tmux pane时把dev放进了第一个位置，palnner做到了并列的第二个位置，而把reviewer 放到了下面位置。
所有参数都可以省略。如果没有参数，三个实例都是默认的claude实例。如果提供一个参数，如pi, 则三个角色就都由pi来承担。如果提供两个参数，则第一个实例是developer, 后面角色的两个实例都是第二个参数定义的agent。如果你不怕麻烦，把三个写全当然系统也不会抱怨。其实写两个参数会有两种不同的解释，因为team a b 可以理解为 team a b b （正确） 也可以理解为 team a a b（错误），但写完整三个就铁定没有歧义了。
https://x.com/shukebeta/status/2097842135278231740?s=20
但windows下的tmux 支持是垃圾，而我工作的场合只能用windows。这催生了adhoc 模式的诞生。adhoc是一个agent打天下，它的宪法最复杂，因为它只有一个agent的上下文空间，却要做原本分派给三个agent做的事。为了保证质量，事先的做计划和事后的review，还有实现计划本身都是它一个实例承担。它仍然能自主工作，但产出的质量多少会打折扣 -- 因为到最后的 review 阶段，上下文已经被实现过程的有用没用的内容几乎占满了——试错、失败的测试、调试输出等等。当然my-ai-team在adhoc的宪法里也要求独立的工作包括最后的审查尽量派独立的sub agent去做，来减轻上下文压力，不过任务规模稍大，在一个delivery loop难免还是会一次甚至多次的上下文自动压缩发生。
Apple 刚刚发布了duo 手机。巧的是，在my-ai-team里，我最爱用的delivery 命令也叫 duo。让Planner, Developer和Reviewer 都是有独立上下文的agent的team 模式固然好，但烧起token来也是最快的。毕竟三方都要对同一个仓库做调查，同样的知识以不同的角度填充三个agent的上下文。因此在team模式诞生之后不久，我就添加了duo模式。
除了team（planner / dev / reviewer）模式最烧token的缺点之外，Planner辛苦制定了计划，但是在 plan 被Reviewer 批准之后它就没事了 -- 全程坐冷板凳——最懂怎么实现的人（planner写了计划，最懂怎么实现）却被换下场让我心有不甘；因此就有了duo模式。
duo命令接受两个参数，两个agent的分工原则是创作和审查。plan 和 dev 都是创作者（做计划和实现计划），两角合一；reviewer是审查者，它必须独立。于是
duo a b ≡ team a a b。这是我最爱的模式。my-ai-team四个月来的2000多个PR大部分是由 duo team完成的。在这个过程里，n多模型都参与过，我有z.ai/claude code/codex三个主要订阅，还有一个minimax年订阅（不大用，效果不好），也试过 opencode go, 当然freebuff的免费token也有在用。有好的工具，模型差一点不是大问题。其实就codex而言，我delivery主要都是用5.6-luna。好模型主要用来开票，好的input非常重要，它直接决定output的质量。那 my-ai-team的delivery team今天就介绍到这里。 mat-docs.shukelabs.com 有更多文档。今天购买my-ai-team 享受五折优惠（折扣码50OFF），如果心动那就试试，反正不满意十五天内还有全额退款。
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 现在购买首年五折。如果你有更好的想法和建议，欢迎评论或者私信。谢谢！
“China”名称的演变过程
秦地初传：公元前221年，秦始皇统一中国建立秦朝，其声威远播周边邻国。
南亚音译：早在1500多年前，古印度语中便出现“Chin”（支那）一词，用来指代秦朝所统治的中国。
丝路西传：通过陆上和海上丝绸之路，这个发音流传到中亚、西亚及欧洲各国的语言中。
西方定型：葡萄牙等欧洲商人来到东方后，将此音转写为“China”，并在西方世界广泛使用。“China”名称的演变过程“China”名称的演变过程“China”名称的演变过程。
之所以有兴趣查这个，是因为同事突然和我彪法语。我这才知道法语里中国的拼写是 Chine。 （发音是不是秦我不知道，但我就当是“秦”了哈哈）
秦地初传：公元前221年，秦始皇统一中国建立秦朝，其声威远播周边邻国。
南亚音译：早在1500多年前，古印度语中便出现“Chin”（支那）一词，用来指代秦朝所统治的中国。
丝路西传：通过陆上和海上丝绸之路，这个发音流传到中亚、西亚及欧洲各国的语言中。
西方定型：葡萄牙等欧洲商人来到东方后，将此音转写为“China”，并在西方世界广泛使用。“China”名称的演变过程“China”名称的演变过程“China”名称的演变过程。
之所以有兴趣查这个，是因为同事突然和我彪法语。我这才知道法语里中国的拼写是 Chine。 （发音是不是秦我不知道，但我就当是“秦”了哈哈）
