我看到很多用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里的某个程序，只要它能接受文本输入。
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 (https://blog.shukebeta.com)，还会有更大的惊喜。欢迎大家多转发，有钱的捧个钱场，没钱的捧个人场。
如果有个人开发者有需求但钱紧，欢迎私信我，我可以友情提供首年的更高折扣。
一个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里的某个程序，只要它能接受文本输入。
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 (https://blog.shukebeta.com)，还会有更大的惊喜。欢迎大家多转发，有钱的捧个钱场，没钱的捧个人场。
如果有个人开发者有需求但钱紧，欢迎私信我，我可以友情提供首年的更高折扣。
