[email protected] @shukebeta

mat （my-ai-team） 的 backends.json：一个订阅，拆出一整支 AI 团队 my-ai-team 使用backends.json来管理所有的worker。每个worker有一个nick，这个nick用来确认使用哪个agent，什么方式授权，哪个模型，多大思考深度，以及使用多大的context window。 它的基本设计原则是：secret使用元数据，不放具体值——authvar 只存环境变量名，真正用到的值由 launcher 从 ~/.bashrc.secret 读取。 这个设计里我最得意的一点，是同一个订阅可以拆成多个 worker。model 和 effort level 都是启动时通过命令行传给 agent 的，所以多个 nickname 可以共用同一个 configdir，而 model 和 thinking level，以及context window size则可以随心设置。（这里configdir的值只是agent config home的目录前缀，不同角色会缀在这个configdir后面，最终得到如claude-dev，claude-plan这样的目录名，以确保不同角色拥有独一无二的system prompt 不会串），请看下面这个例子片段： { "backends": [ { "nickname": "claude", "configdir": "claudew", "authvar": "CLAUDECODEOAUTHTOKENCCW", "promptfile": "CLAUDE.md", "kind": "claude", "defaulteffort": "medium", "contextwindowsize": "256k", "defaultmodel": "opus[1m]" }, { "nickname": "sonneth", "configdir": "claudew", "authvar": "CLAUDECODEOAUTHTOKENCCW", "promptfile": "CLAUDE.md", "kind": "claude", "defaulteffort": "high", "contextwindowsize": "256k", "defaultmodel": "sonnet[1m]" }, { "nickname": "opus48“, "configdir": "claudew", "authvar": "CLAUDECODEOAUTHTOKENCCW", "promptfile": "CLAUDE.md", "kind": "claude", "defaulteffort": "high", "contextwindowsize": "256k", "defaultmodel": "claude-opus-4-8[1m]" } ... ] } 三个 worker 共用同一个订阅的授权令牌（claude setup-token可以生成长达一年的仅使用订阅额度的“API”key，从而避免了不时要求登录的麻烦）但分别是 opus/medium、sonnet/high、opus-4-8/high——一个订阅，按任务贵贱分配算力：日常活给 sonnet，重活给 opus，探索给低 effort。 主动控制上下文窗口：同样的订阅，更经用 1M 长上下文的模型有个陷阱：任务稍大就轻松突破 400k，账单随之激增——token 额度在不知不觉中被快速烧掉。 mat 的解法是 contextwindowsize 字段，每个 worker 声明自己的有效窗口。 launcher 在启动时把它翻译成各家族的原生机制——Claude 的 CLAUDECODEAUTOCOMPACTWINDOW、Codex 的 modelautocompacttokenlimit、OpenCode 的 per-model limit override——在窗口触顶前主动压缩，而不是放任它涨到 1M 上限。256k 的活就只付 256k 的钱。 我的配置里几乎每个条目都带着 "contextwindowsize": "256k"，用1m能力的模型，但主动把contextwindow_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 现在购买首年五折。如果你有更好的想法和建议，欢迎评论或者私信。谢谢！

之所以有兴趣查这个，是因为同事突然和我彪法语。我这才知道法语里中国的拼写是 Chine。 （发音是不是秦我不知道，但我就当是“秦”了哈哈）

“China”名称的演变过程 秦地初传：公元前221年，秦始皇统一中国建立秦朝，其声威远播周边邻国。 南亚音译：早在1500多年前，古印度语中便出现“Chin”（支那）一词，用来指代秦朝所统治的中国。 丝路西传：通过陆上和海上丝绸之路，这个发音流传到中亚、西亚及欧洲各国的语言中。 西方定型：葡萄牙等欧洲商人来到东方后，将此音转写为“China”，并在西方世界广泛使用。“China”名称的演变过程“China”名称的演变过程“China”名称的演变过程。

@use_kibble That's what we have to pay if we want to own an independent reviewer, who could find more defects than sharing the same context. It does produce better quality based on my practice.

我看到很多用agent已经很熟练（因为他们的订阅都很大！)的人在问怎么让不同的模型协同工作，怎么让不同订阅协同工作。订阅都这么大了，还亲自去蹬，这不科学。我今天来给同学们科普一下（说得不对的地方欢迎打脸）。 一个claude code或者一个codex，pi，都只有一个输入框（当然可以开多个tab，这样就有多个输入框，不过即使这样，也只是你一个有在不同的窗口里和agent对话，累死人）。我最初也是如此。直到我了解了 tmux send-keys。tmux本来跟ai agent 没啥关系，它是给喜欢命令行并讨厌开新tab的geek们提供的在一个terminal窗口里开多个子窗口（pane）的工具。每个pane里都可以跑一个程序（比如claude)。妙的地方在于，使用 tmux send-keys可以从一个pane发内容到另一个pane的shell或者运行在那个pane里的某个程序，只要它能接受文本输入。到了AI agent时代，tmux获得了新的机遇（其实只是workaround)，变得更加流行。 agent可以调用工具，那agent自然就可以调用tmux send-keys。给agent适当的宪法和协议，一个pane里的agent(planner 或者developer）就能在完成必要的事情时主动发送plan或者实现报告给住在另一个pane里的agent审核(reviewer)，而审核者批准或者要求继续整改都可以发消息回去。做到这里，一个harness harness的harness的雏形就有了。 my-ai-team能够转起来就靠这个。当然了，tmux这个功能并不是百分百可靠，有时候消息发出去对方没收到，这就需要机制检测这些断点并及时弥补。另外，为了从源头上解决tmux不够可靠的问题，my-ai-team还开发了自己的接力引擎baton。利用baton，多个agent可以不通过tmux就实现彼此对话，接力把事情完成。 ai能自动转起来干活这很好，但活从哪里来？你知道领导都怎么布置任务吧，很多人和ai对话也差不多。但领导布置任务一个特点就是“有这么一个事，你得去办一下，得办好啊！”，好像说得挺清楚，但问题具体定义，可选方案和如何验收完全没提。我们人类和agent对话常常也是如此。所以一个任务或者一个需求，我们和ai聊，就是把细节弄规范化的过程。这个过程是可以重复的，也可以用一些skill来确保agent产出规范的票。 在my-ai-team里，有一个专门的agent叫explorer（命令explore)。它的宪法里约定了它的职责就是认真听取人类的要求，必要时反问和调研，好好写票，把票写好。这样，我们人类输入模糊不清的需求，经过explorer加工之后就得到了一张或多张非常规范的github issues。 在my-ai-team里，最初我手工把issue id或者链接扔给 planner由它启动整个循环。但做完一个我就得手工扔给它另一个太累了，而且，这不是另一种babysit吗？因此不久之后，my-ai-team的delivery agents就有了自己从github 上找票的功能。做完一张票，还能自我重生，再主动接下一张票。如果给一张票求 priority:high label，框架就会优先把高优先级的票喂给delivery agent。 有时候开票的agent很积极，很快积攒了几十张票。只让一个ai team来干活效率太低了，我就考虑让my-ai-team支持多个ai team在同一个repo上工作。这个问题是怎么解决的呢，让每一个delivery team拥有一个独一无二的worktree。这样下来，票消化的速度就大大提高了（你的token也烧得更快了！）。 也许有同学好奇我是如何让ai主动去github上领ticket的。其实也不难，不论是claude code还是codex，或者其他主流agent，大都支持通过命令行来传递initial prompt。买过my-ai-team的同学都知道，如果我们启动 duo cluade codex 这个命令，claude同学一启动就会收到这样一个prompt "Run mat next-work and act on the directive it prints"。没错，是 mat next-work 命令主动去github拿到open票列表并找出符合条件的票给delivery agent。指令可能是 "implement #123, 也可能是 refine #124"或者“resume #125"等等。 有同学问了，你就这么放心让ai自动干活，中间出了问题卡住了怎么处理？没错，可能会卡住的地方就一定出现卡住的情况（不然next-work里就不会有resume这个动词了）。机器可能会死机，agent也可能死心眼（一个任务跑了48个小时的情况也发生过，不过基本上还是要怪人类对票的scope把关不严）。my-ai-team自带telegram relay支持，agent不仅会在关键节点主动通报进度，更会在遇到不能自决的问题时主动给你发消息请求帮助。你不必跑回控制台来救火，你直接在telegram回复agent消息就好。 有同学说了，你这个东西好是好，就是烧token太快。活干到一半token烧完了，不一样卡住。那是肯定会卡住的。这就是 agent quota gateway 项目的职责范围了，我有时间会专门开话题再讲。 有同学说了，你这个东西代码全是AI写的，Review也全是AI自己做的，合代码也是AI。你的质量靠什么保障？首先，我们得承认AI已经能够稳定地产出比senior工程师更好的代码。我们有什么理由不相信AI Review的结果呢。没错，合并之后的代码也会有bug，人工Review过线上爆炸的时候也不少啊。更不用说，my-ai-team还配备了不眠不休帮你找bug的auditor（命令audit) agent。audit审核合并之后的代码。它自我感知到有新PR合并，就会用挑剔的眼光主动扫描新合进来代码。即使没有新PR，它也会从不同角色（如坏味道，重复代码，测试覆盖等等）来扫描仓库，并在有所发现时主动开票。 不但my-ai-team是my-ai-team写的，我现在所有的产品都是my-ai-team在写。它正在一天一天变得更强大，更方便。 my-ai-team是soho开发者，创业者的好助手。雇人很贵，买了大订阅，那就把它用到实处。my-ai-team让你专注于需求和难收，把delivery放手交给agent们。现在购买首年五折(折扣码 50OFF)。购买链接 mat.shukelabs.com 文档站在 mat-docs.shukelabs.com 。如果你经常阅读我的blog (blog.shukebeta.com)，还会有更大的惊喜。欢迎大家多转发，有钱的捧个钱场，没钱的捧个人场。 如果有个人开发者有需求但钱紧，欢迎私信我，我可以友情提供首年的更高折扣。

#网友语录 饭不否 "忘了时间的事、别人总找你帮的事、没好处也愿意做的事”，这三件事的交集，就是你的天赋领域。

限制之美 把一个刚生下来的人送到天堂，他感受不到幸福。在要啥有啥的共产主义社会里，人们也不会幸福。 我想说什么？我想说，多亏这个世界上那么多东西都有限，这个世界才有趣。 不是么？

@guansi 我都是主动设置上下文天花板256k，账单能减一半。

今天给潜在顾客H公司上门安装my-ai-team和agent quota gateway，得到了好评。my ai team让一个订阅能分成多个worker，同时自动协同工作：让sonnet做dev，opus做reviewer。还能方便设置初始effort level。更不用提配合agent quota gateway还能实现把公司几个人的claude订阅做成一个池子，只要错峰使用，相当于每个人的五小时额度都大了几倍。 mat-docs.shukelabs.com 有全套文档，更不用说还有首年5折discount！

@Luyalaolao 我可能是因为免费用户的原因，总是让我点宝箱，试用会员，最近的广告又全是temu。

我停止了我的多邻国打卡，在坚持了大约1900天之后。我只是不想再忍受那些shit。没有必要的互动太多了！ 我只是想多说一点英语多听一点英语。我已经给我的NewWords app增加了小故事朗读，听写，和口语练习，我没必要再受多邻国的气了！

人还是得运动。前一阵子身体不好就停止了每晚的2km 跑步，可别小看这个2km，停了这些天，明显感到自己白天的精力不济，呵欠连天，总想躺。 今晚起恢复跑步，先慢慢小跑。

@Luyalaolao 大部分司机都挺好，但总有个别的。我朋友碰到过几次挥手车不停的情况，投诉也没用，司机的理由是当时车里已经人满了。

今天在公司喜迎两名新同事，都是华人，其中一位是我在基督城读书时的同学，他现在就坐在我的旁边。基督城是个小城市。同事R介绍我公司里的ABCD都曾经在另一个公司工作过。大家就在这几个大一点的IT公司里跳来跳去哈哈哈。

我的公开笔记现在能同步发表到我的twitter账户了，而我HappyNotes这边一行代码也没改。当然凭空实现是不可能的，我通过taiscale共享了一点基础设施给自动发推服务。还是挺开心的。