#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），如果心动那就试试，反正不满意十五天内还有全额退款。
